CI-Tests für Custom Language Models im Jahr 2026

Notizen aus dem Release-Zyklus — Teil 8 (Finale)

Sie liefern die Regressions-Suite aus Beitrag 7 aus. Sie funktioniert. Die Slice-bewussten Gates fangen echte Bugs. Der kalibrierte Judge hält stand.

Dann fragt Ihr Engineering Lead, wie viel es kostet, sie bei jedem PR laufen zu lassen. Sie rechnen nach: ~12 Minuten Judge-Inferenz pro PR, 60 PRs pro Tag, vier Dimensionen × siebzehn Slices — und die Rechnung wird zu echtem Geld. Schlimmer noch, jeder Entwickler wartet jetzt 12 Minuten auf einen grünen Haken für einen einzeiligen Prompt-Tippfehler. Die Velocity sinkt^[1], das Team murrt, jemand schlägt vor, „die Gates einfach nachts laufen zu lassen“ — was exakt der Weg ist, auf dem Sie alles aufgeben, wofür die Gates da waren.

Die Lösung ist nicht weniger Testen. Die Lösung ist Testen in Schichten, wobei der Großteil des Signals in den ersten neunzig Sekunden eintrifft. Dieser Beitrag handelt von dem, was unterhalb der Gate-Suite läuft: Sub-Sekunden-Contract-Tests, eine straffe Smoke-Schicht, eine kostenbewusste Flotte und ein zweiwöchiges Shadow-Fenster, bevor ein neues Gate irgendjemanden blockiert.

Das ist Beitrag 8, der letzte dieser Serie. Am Ende haben Sie das vollständige Bild — von der vierstufigen Pipeline bis hinunter zum Contract-Test-Fixture, das bei jedem Commit läuft.

Was bedeutet CI für ein Custom Language Model?

CI für ein Custom-LLM ist die Arbeit, die die Gate-Suite nicht wiederholen muss. Das Gate bewertet semantische Qualität; CI fängt alles ab, was den Score des Gates bedeutungslos machen würde, bevor das Gate einen einzigen Judge-Token ausgibt.

Contract-Tests laufen in Millisekunden und verifizieren, dass Prompt-Templates noch rendern, dass Tool-Call-Schemas noch parsen, dass Retrieval-Indizes noch antworten, dass das Manifest noch auf Hashes verweist, die tatsächlich existieren. Sie sind deterministisch, kostenlos und der einzige Grund, warum sich der Rest der Pipeline leisten kann zu existieren. Ein Pull Request, der das Prompt-Template kaputt macht, sollte in 200 ms fehlschlagen — nicht nach 12 Minuten Judge-Inferenz, die Unsinn bewertet.

Die Contract-Schicht ist der Unterschied zwischen einer CI-Rechnung, die linear mit dem PR-Volumen skaliert, und einer, die das nicht tut. Divincis CI-Runner verbringt > 90 % seines Judge-Budgets mit echter semantischer Evaluation, nicht mit PRs, die ohnehin an einer Schema-Prüfung gescheitert wären. Diese Quote ist die Kennzahl.

Warum traditionelle CI für LLMs versagt — durch die Kostenlinse

Die Beiträge 1 und 7 haben behandelt, warum deterministische CI bei einem generativen Modell scheitert. Die Version dieser Geschichte, um die es in diesem Beitrag geht, ist nicht die Existenz dieser vier Eigenschaften, sondern ihre Kosten.

Die CI-Architektur muss jeden dieser Punkte bezahlbar machen. Contract-Tests bewältigen Eigenschaft 1 und 3 günstig. Smoke-Tests bewältigen Eigenschaft 4 teilweise. Nur die vollständige Suite bewältigt Eigenschaft 2 — und nur bei den PRs, die sie wirklich brauchen.

Die CI-Schichttorte — Sub-Sekunde bis fünfundzwanzig Minuten

Die Architektur, die wir ausliefern, besteht aus vier Schichten, jede verdient ihre Rechenleistung damit, dass sie fängt, was die günstigeren Schichten darunter nicht können. Die Slice-bewusste Rahmung jeder Schicht folgt derselben Lektion, die das Tianpan-Semver-Lie-Postmortem explizit gemacht hat^[4]: Aggregatsignale lügen; Per-Slice-Signale fangen, was Aggregate verbergen.

Die Kostenform ist das Design. ~74 % der PRs geben nie einen Judge-Token aus — Contract oder Smoke reichen. Die PRs, die die Full-Suite erreichen, sind diejenigen, die einen Prompt, eine Modellkonfiguration, einen Retrieval-Index oder Evaluation-Code berührt haben — genau die Änderungen, bei denen die Gate-Suite das einzige vertrauenswürdige Signal ist. Release Candidates sind der kleine Anteil, der Schicht 4 erreicht.

Contract-Tests — der unfaire Vorteil

Contract-Tests sind die erste Linie, die günstigste Linie und die Linie, die die meisten Teams überspringen, weil sie sich unter der Würde einer „KI-Evaluations-Pipeline“ zu befinden scheint. Sie sind aber auch die Schicht, in der 30–40 % der potenziellen Regressionen in den Suites unserer Kunden tatsächlich scheitern, bevor ein einziger Judge angerufen wurde.

Die Contract-Schicht prüft fünf Dinge und nichts anderes:

1. Prompt-Template-Render. Jedes Template rendert gegen ein kanonisches Fixture ohne ungebundene Variablen, Endlosschleifen oder kaputte Jinja-Style-Includes.
2. Tool-Call-Schema. Das Argument-Schema jedes deklarierten Tools parst, das JSONSchema ist valide, und der gerenderte Prompt verweist tatsächlich auf alle erforderlichen Slots.
3. Manifest-Integrität. Jeder SHA im Release-Manifest — Modell, Prompt, Retrieval-Index, Judge, Dataset — entspricht einem Artefakt, das in der Registry existiert. Dangling Pointers scheitern hier, nicht drei Schichten weiter.
4. Index-Lebendigkeit. Der Retrieval-Index antwortet im Budget auf eine bekannte Query. Ein neu gebauter Index, der das Retrieval leise zerstört hat, tritt hier zutage, nicht in Produktion.
5. Denylist & Token-Budget. Jedes Prompt-Template, das ein verbotenes Token eingeführt hat, das Per-Call-Token-Budget gesprengt hat oder über das Kontextfenster hinaus gerendert hat, scheitert hier. Heuristisches Semantische-Ähnlichkeits-Scoring^[6] ist ebenfalls günstig genug, um in der Contract-Schicht zu laufen — für Fuzzy-Match-Denylist-Abdeckung, bei der literales String-Matching nicht ausreicht.

# Ein repräsentativer Contract-Test-Aufruf — läuft in etwa 600 ms
divinci ci contract \
  --manifest release/staging.yaml \
  --check schema,template,manifest,index,denylist \
  --fail-fast \
  --json-out /tmp/contract-report.json

Keiner dieser Aufrufe spricht einen Judge an. Keiner ist nicht-deterministisch. Keiner kostet messbares Geld. Und jeder einzelne von ihnen schließt eine ganze Klasse von „Die Gate-Suite sagt, der Medical-Slice ist regressiert“-Alarmen aus, die ansonsten volle 12 Minuten Judge-Inferenz verschwendet hätten, um Output zu bewerten, den das Modell von vornherein nicht korrekt hätte erzeugen können.

Die Smoke-Schicht — 90 Sekunden, ~$0,05 pro PR

Wenn die Contract-Schicht der günstige unfaire Vorteil ist, ist die Smoke-Schicht diejenige, die tatsächlich Regressionen für weniger als den Preis eines Kaffees fängt. Zwanzig bis dreißig Fälle, gezogen aus den umsatzstärksten Slices, bewertet nur auf Task Completion und Safety — keine Faithfulness, keine Latenz, keine Retrieval-fundierten Checks. Jeder PR durchläuft das. Es dauert etwa 90 Sekunden, weil die Fälle in einen einzigen Judge-Call mit Structured-Output-Schema gebündelt werden und weil der Judge der günstige kalibrierte Judge ist — nicht der vollqualitative, der für Release Candidates verwendet wird.

Wir verfolgen in einem Regressions-Log, welche Schicht jeden ausgelieferten Fix gefangen hat, und das Histogramm war in den letzten sechs Monaten in Kunden-Deployments konsistent:

Die 3 %, die entwischen, sind der Grund, warum der Instant-Rollback aus Beitrag 5 existiert. Die Gates versprechen keine null Escapes; sie versprechen eine enge Obergrenze und eine schnelle Wiederherstellung für das, was durchkommt.

CI-Flottendimensionierung — wie die 12-Minuten-Suite günstig bleibt

Die Full-Suite-Schicht ist der Punkt, an dem die Rechnung aufgehen muss. Eine naive Implementierung ruft den Judge einmal pro Fall-pro-Dimension auf, lässt sie sequenziell laufen, und die Rechnung skaliert linear mit der Fallzahl. Drei Optimierungen leisten den Großteil der Arbeit, um das handhabbar zu halten:

Embedding-Cache. Der Retrieval-Kontext-Fingerprint für jeden Golden-Dataset-Fall wird gehasht; wenn sich der Fall nicht geändert hat und sich der Retrieval-Index nicht geändert hat, bleibt das gecachte Embedding gültig und der Retrieval-Schritt entfällt. Die Hit-Rate liegt nach der ersten stabilen Woche in unseren Kunden-Deployments konstant über 90 %.

Judge-Batching. Der kalibrierte Judge wird mit Structured Output aufgerufen und bündelt 8–16 Fälle pro Call. Die Per-Token-Kosten des Judges bleiben gleich; der Per-Case-Overhead sinkt, weil sich der System-Prompt über den Batch amortisiert. Der Schwellenwert für sicheres Batching wird durch die kalibrierte Übereinstimmung des Judges bei dieser Batch-Größe gesetzt^[2] — wir messen dies während des wöchentlichen Judge-Kalibrierungs-Passes (Beitrag 7).

KV-Cache-Wiederverwendung über Fälle hinweg. Bei Modellen, bei denen derselbe System-Prompt und dieselben Tool-Definitionen jedem Call vorangestellt sind, wird der KV-Cache für dieses Präfix einmal pro Suite-Run berechnet, nicht einmal pro Fall^[3]. Bei Open-Weights-Deployments ist das geradeaus; bei Closed-API-Modellen hängt es vom Prefix-Caching-Support des Providers ab.

Der kombinierte Effekt landet die Full-Suite ungefähr bei den Kostenzahlen aus dem Schichttorten-Diagramm oben. Die exakten Zahlen sind intern, aber die Quote ist die öffentliche Aussage: ~74 % der PRs verbrauchen null Judge-Dollar; ~22 % verbrauchen Cents; die verbleibenden 4 % verbrauchen ein paar Dollar für das hochkonfidenteste Pre-Rollout-Signal, das wir zu produzieren wissen.

Shadow-CI — einschalten, ohne das Team zu zerstören

Der eine Fehler, den wir bei Teams am häufigsten beobachtet haben, ist, ein neues Gate am ersten Tag von „aus“ auf „blockierend“ zu schalten. Die Schwellenwerte sind auf gestrigen Daten getuned, die False-Positive-Rate ist unbekannt, und beim ersten Auslösen des Gates hat das Team keine Kalibrierung dafür, ob es echt oder ein Fehlalarm ist. Der On-Call-Eval-Engineer wird gepiept, das Gate wird deaktiviert, das Vertrauen ist weg, das Projekt ist tot.

Die Lösung ist Shadow-CI: Lassen Sie das neue Gate zwei Wochen lang nicht-blockierend laufen, posten Sie das Ergebnis als Bot-Kommentar an jedem PR und überprüfen Sie wöchentlich die False-Positive-Rate, bevor Sie es auf blockierend schalten. Der Divinci-CI-Runner hat genau dafür ein --shadow-Flag. Der PR-Kommentar sieht genauso aus wie die spätere blockierende Version — gleiche Diff-Anzeige, gleiche Per-Slice-Aufschlüsselung — nur dass er den Merge nicht gatet.

divinci ci run --layer=full --shadow --duration=14d --report-as=bot-comment

Wenn die False-Positive-Rate über das Fenster nachhaltig unter 5 % liegt, flippen wir es. Wenn nicht, ziehen wir die Per-Slice-Schwellen an, rekalibrieren den Judge und shadown erneut. So oder so wird das Team nicht von einem neuen Gate überfallen, das am ersten Tag feuert.

Ein GitHub-Actions-Workflow, der tatsächlich komponiert

Das Stück, das die Schichttorte mit Ihrer bestehenden CI verbindet, läuft in .github/workflows/llm-ci.yaml. Die Schichten sind so verdrahtet, dass die günstigen schnell scheitern und die teuren nur dann laufen, wenn sie müssen — needs:-Ketten und pfadgefilterte Trigger erledigen die Arbeit^[5].

name: LLM CI
on:
  pull_request:
    paths:
      - 'prompts/**'
      - 'config/models.yaml'
      - 'eval/**'
      - 'retrieval/**'
      - 'manifests/**'
jobs:
  contract:
    runs-on: ubuntu-latest
    timeout-minutes: 2
    steps:
      - uses: actions/checkout@v4
      - run: divinci ci contract --manifest manifests/staging.yaml --fail-fast
  smoke:
    needs: contract
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4
      - run: divinci ci run --layer=smoke --post-pr-comment
        env:
          DIVINCI_API_KEY: ${{ secrets.DIVINCI_API_KEY }}
  full:
    needs: smoke
    if: contains(steps.changes.outputs.paths, 'prompts/') || contains(steps.changes.outputs.paths, 'config/models.yaml')
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - run: divinci ci run --layer=full --post-pr-comment --gate
        env:
          DIVINCI_API_KEY: ${{ secrets.DIVINCI_API_KEY }}

Drei Dinge, die zu beachten sind. Die Schichten verketten sich über needs:, sodass Smoke nicht bei einem kaputten Contract läuft und Full nicht bei kaputtem Smoke. Der full-Job ist pfadgefiltert auf die Änderungen, die tatsächlich einen 12-minütigen Lauf rechtfertigen — eine Tippfehler-Korrektur in der README löst die Gate-Suite nicht aus. Das --post-pr-comment-Flag ist das, was den Per-Slice-Diff sichtbar macht, ohne GitHub verlassen zu müssen.

Die Failed-PR-Debug-Schleife

Die andere Hälfte von „das Gate hat gefeuert“ ist „zeig mir, warum.“ Eine Regressions-Suite-Ausgabe von medical slice task-completion dropped 0.04 ist ohne die Fälle, die sie verursacht haben, nicht handlungsfähig. Wir blenden die fünf schlechtesten Per-Slice-Diffs im PR-Kommentar ein, mit dem Original-Input, dem Baseline-Output, dem Candidate-Output und der Reasoning-Spur des Judges. Die Debug-Schleife soll Sekunden dauern, nicht Minuten:

# Die 5 schlechtesten Fälle ziehen, die das Medical-Slice-Gate auf diesem PR ausgelöst haben
divinci ci diffs --pr 1247 --slice medical --dimension task_completion --top 5

Das ist dieselbe Diagnoseoberfläche wie der Sieben-Schritte-Baum aus Beitrag 6, verdrahtet in die CI-Feedback-Schleife. Der Engineer, der den PR geöffnet hat, sieht die Fall-Level-Evidenz direkt im PR; er muss kein separates Eval-Dashboard öffnen.

Versionierungsdisziplin — Prompts, Datasets, Judges als Code

Prompt-Templates, Golden-Datasets und Judge-Prompts leben alle im Repo, Hash-gepinnt im Release-Manifest. Das Manifest ist das einzelne Objekt, das die Suite an einen spezifischen, reproduzierbaren Zustand bindet:

# manifests/staging.yaml — jeder CI-Run hasht dieses
release_id: rel-staging
model:     { sha: 0c1f9…, weights: r2://models/custom-v7.2,  open_weights: true }
prompt:    { sha: c4a8e…, template: prompts/support/v3.4.j2 }
retrieval: { sha: b21f0…, index: r2://indices/kb-2026-04 }
judge:     { sha: d8e21…, rubric: eval/rubrics/v7.yaml }
dataset:   { sha: a90b1…, file:   eval/datasets/golden-2026-04.jsonl }

Wenn ein CI-Run einen Score postet, wird der Score mit diesem Manifest-Hash getaggt. Wenn ein Score sich bewegt, hat die Frage „welcher Input hat sich bewegt“ eine direkte Antwort: Manifest diffen, und die Schicht, die gefeuert hat, sagt Ihnen, welche Dimension Sie zuerst betrachten sollten. Das ist die Schleife, die die vierstufige Pipeline aus Beitrag 1 und die Vindex-Quittung aus Beitrag 4 gemeinsam schließen: Das Manifest ist das Audit-Primitiv, auf das alle acht dieser Beiträge in unterschiedlichen Rahmungen hingearbeitet haben.

Was das nicht löst

Dieselben drei ehrlichen Einschränkungen, die wir in jeden Beitrag dieser Serie geschrieben haben.

1. CI testet nicht, was nicht in der Suite ist. Egal wie klug die Schichttorte ist — die einzigen Regressionen, die sie fängt, sind die, die irgendein Fall im Golden-Dataset markiert hätte. Die Replay-Schicht mildert das für Verhaltens-Drift, aber neuartige Queries, die nie zuvor gesehen wurden, entwischen weiterhin, bis sie in der Produktion auftauchen. Das System muss mit Produktions-Monitoring gepaart werden.
2. Kostenzahlen verschieben sich mit dem Modellpreis. Jede Kostenzahl in diesem Beitrag hängt von Judge-Token-Raten, Embedding-Raten und Inferenz-Raten ab, die sich quartalsweise verschieben. Die Quoten — 74 % / 22 % / 4 %, 31 % / 27 % / 28 % / 11 % / 3 % — sind die tragenden Aussagen; die Dollar-Zahlen sind illustrativ für einen Moment in der Zeit.
3. Provider-seitige Checkpoint-Änderungen sind weiterhin schwierig. Wenn ein Closed-API-Provider das Modell hinter einem stabilen Namen leise aktualisiert, kann die Contract-Schicht das nicht fangen; nur die Gate-Suite kann es, und nur im Nachhinein. Wir mildern es ab, indem wir explizite Checkpoint-Identifikatoren pinnen, wo der Provider das unterstützt, und indem wir den Tag, an dem ein Checkpoint angekündigt wird, als Trigger für ein vollständiges Suite-Re-Baseline behandeln. Wir können das zugrundeliegende Problem nicht verhindern.

Abschluss der Serie

Das ist Beitrag 8 von 8. Der vollständige Bogen:

1. How to Build an LLM CI/CD Pipeline With Divinci AI — die vierstufige Pipeline (Register / Gate / Roll / Observe), in der seither alles gelebt hat.
2. 10 CI/CD Release Failures in Custom Language Models — die benannten Failure-Modes von 2026, jeder gemappt auf die Stufe, die ihn hätte fangen sollen.
3. 12 QA and Release Management Capabilities for LLMs — die Capability-Matrix und das Drei-Lager-Venn, das Divinci gegenüber den Alternativen positioniert.
4. Validating and Releasing Custom LMs in Regulated Fields — die Compliance-Tiefenanalyse, das Regulator-zu-Stage-Mapping, die Vindex-Quittungen.
5. Automated LLM CI/CD Pipelines With Instant Rollback — die operative Schicht, das Automatisierungs-Spektrum, die Auto-Rollback-Quittung.
6. How to Diagnose Custom LLM QA Failures in 7 Steps — der diagnostische Entscheidungsbaum; das Modell ist ungefähr in einem von sieben Alarmen die richtige Antwort.
7. Automated Regression Testing for Custom LLMs in 2026 — Slice-bewusste Spearman-Gates, kalibrierte Judges, Closed-Loop-Production-Trace-Replay.
8. Dieser Beitrag. Die CI-Infrastruktur, die alles oben Genannte bei jedem PR handhabbar macht.

Die Teile komponieren: Das Manifest ist das Audit-Primitiv, die Gates sind die Sicherheitsschicht, der Diagnose-Baum ist die Wiederherstellungsschleife, die Vindex-Quittung ist der externe Anker, und die Schichttorte ist das, was das Ganze bezahlbar macht, um es bei jedem Commit laufen zu lassen. Wenn Ihr Custom-LLM-Release-Prozess diese fünf nicht gemeinsam hat, ist die Lücke das, worum es in diesen acht Beiträgen ging.

FAQ

Was ist der günstigste Test, den ich bei jedem Commit laufen lassen kann?

Eine Prompt-Template-Render-Prüfung. Sie läuft in Millisekunden, erfordert keinen Judge, fängt einen überraschend großen Anteil an Defekten und kostet nie einen messbaren Cent. Wenn Sie sie noch nicht ausführen, ist sie das CI-Stück mit dem höchsten ROI, das wir empfehlen können.

Mit welchen Kosten muss ich für eine Custom-LLM-CI-Pipeline rechnen?

Cents pro typischem PR, niedrige einstellige Dollarbeträge pro Release-Candidate-PR. Die Quote hängt vom Judge-Preis und davon ab, welcher Anteil Ihrer PRs Prompts oder Modellkonfiguration berührt. Der oben genannte 4-%-Anteil an Release Candidates ist typisch; bei Produkten mit häufiger Prompt-Iteration steigt der Anteil und der Durchschnitt klettert entsprechend.

Soll ich die Full-Suite bei jedem Commit laufen lassen?

Nein. Pfadfiltern Sie auf PRs, die Prompts, Modellkonfiguration, Retrieval oder Eval-Code berühren. Für alle anderen Änderungen reicht Contract + Smoke, und eine 12-minütige Wartezeit auf einen README-Tippfehler kostet Sie innerhalb eines Sprints das Vertrauen des Teams. Die Full-Suite ist kostbar; geben Sie sie dort aus, wo die Änderung plausibel eine Qualitätsdimension verschieben kann.

Wie führe ich ein neues Gate ein, ohne alle zu blockieren?

Zweiwöchiges Shadow-Fenster, nicht-blockierend. Justieren Sie die Schwellenwerte anhand der False-Positive-Rate, die während des Shadows beobachtet wird. Schalten Sie nur dann auf blockierend, wenn die nachhaltige False-Positive-Rate unter Ihrer Toleranz liegt (wir verwenden 5 %). Alles andere ist der Weg zu einem Gate, das alle gelernt haben zu ignorieren.

Welche einzelne Zahl soll ich verfolgen, wenn ich nur eine verfolge?

Den Anteil bestätigter Regressionen, die vor der Produktion gefangen werden. Das Histogramm in diesem Beitrag setzt diesen in reifen Divinci-Deployments bei ~97 % an. Die 3 %, die entwischen, sind der Grund, warum Instant-Rollback existiert. Die 97 % sind, wofür die Suite da ist.

Referenzen

1. DORA / Google Cloud. „Accelerate State of DevOps — CI-Velocity, Change-Failure-Rate und Time-to-Restore-Service." Die branchenübergreifenden Baselines, die „12 Minuten pro PR ist zu langsam" zu einer vertretbaren Aussage statt einer Meinung machen.
2. Zheng et al. „Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685. Die empirische Evidenz dafür, dass gebatchte LLM-as-Judge-Calls die Kalibrierung bei den in der Smoke- und Full-Schicht verwendeten Batch-Größen erhalten können — der Grund, warum die Kostenzahlen in diesem Beitrag erreichbar sind.
3. Pope et al. „Efficiently Scaling Transformer Inference." arXiv:2211.05102. Die im Abschnitt zur CI-Flottendimensionierung zitierten KV-Cache-Wiederverwendungs- und Prefix-Sharing-Techniken.
4. Pan, Tianpan. „The Semver Lie: how a minor LLM update broke production." 29. April 2026. Der 2026 benannte Failure-Mode für rein aggregat-basierte Regressions-Suites; der Grund, warum die CI-Schichttorte durchgehend Slice-bewusst ist.
5. GitHub. „GitHub Actions — Verkettung von Jobs mit `needs:` und bedingter Ausführung." Das Primitiv, gegen das die .yaml-Datei in diesem Beitrag komponiert.
6. Zhang et al. „BERTScore: Evaluating Text Generation with BERT." arXiv:1904.09675. Die heuristische Semantische-Ähnlichkeits-Metrik, die als Alternative zu LLM-as-Judge für die günstigeren Schichten referenziert wird; nicht das, was wir zur Gate-Zeit ausführen, aber nützlich in der Contract-Schicht für die skalierbare Erkennung verbotener Phrasen.