digline

Open Source, Apache-2.0v0.15.0, vor 1.0Mit einem KI-Modell aus dem Englischen übersetzt. Englisches Original vom 2026-09-17

Du hast einen Prompt geändert.Was ist sonst noch schlechter geworden?

Ein neuer Prompt, eine Modellversion, ein Bibliotheks-Upgrade. Die Anwendung läuft weiter, und eine Antwort, auf die sich dein Kunde verlassen hat, ist jetzt falsch. digline sagt dir, welcher Fall betroffen ist, um wie viel, und ob der Abfall größer ist als das Rauschen des Judge selbst.

pip install digline

Benötigt Python 3.12 oder neuer

  • Der Schnelleinstieg braucht keinen API-Schlüssel
  • Kein Server, keine Telemetrie
  • Exit-Code für CI
digline comparesupport · exit 1

how-do-i-returnschlechter geworden

llm_rubric
1.00 → 0.40
contains
1.00 → 0.00
Ebenfalls schlechter
is-it-waterproof, where-is-my-order
prompt.md · +1 −1 Zeilen, seit der Referenz geändert
-Sign every reply as "— Northwind Support".+Sign every reply as "— the Northwind team".

6 checks sind schlechter geworden. CI stoppt hier.exit 1

Vorgefertigtes Modell und Judge, 1 Stichprobe pro Fall: das Judge-Rauschen wird in dieser Demo nicht gemessen. Aufgezeichnet mit digline 0.15.0, run 2026-09-17T13-40-13-686329… · home.json

Das Problem

Eine LLM-Anwendung kann schlechter werden, ohne dass etwas kaputtgeht.

Die Tests laufen durch, die Anwendung antwortet, die Demo funktioniert. Dann ändert eine Prompt-Änderung, eine Modellversion oder ein Bibliotheks-Upgrade eine Antwort, auf die sich dein Kunde verlassen hat, und nichts in der Pipeline sagt es dir.

Wie es meistens läuft

  • Die Evals erneut laufen lassen und auf den Durchschnitt schauen
  • Keine Möglichkeit, einen echten Abfall von einem schlechten Tag des Judge zu unterscheiden
  • Was freigegeben wurde und wann, steht in irgendjemandes Notizbuch
  • Der Kunde findet die Regression zuerst

Mit einer freigegebenen Referenz im Repo

  • Jede Änderung wird Fall für Fall verglichen
  • Das Rauschen des Judge wird gemessen, bevor ein Abfall festgestellt wird
  • Die Referenz ist eine Datei in einem PR, mit einem Commit und einem Namen dazu
  • CI stoppt früher als das Release

Wie es sich einfügt

Es liegt in deinem Repo, nicht auf einem Server.

Nichts, wofür man sich anmelden muss, und nichts zu hosten. Die Referenz ist eine Datei, und das Werkzeug ist ein Paket.

Die Referenz ist eine Datei in deinem Repo

Scores, Prompt- und Modellkonfiguration, neben dem Code eingecheckt. Sie ändert sich über einen PR, also gibt es zu jeder Freigabe einen Commit und einen Namen.

Eins Abhängigkeit, kein Provider-SDK

digline installiert jsonschema und sonst nichts Eigenes. Kein Server, keine Telemetrie, nichts Gehostetes. In CI ist der Exit-Code die gesamte Schnittstelle.

Provider

Je ein Plugin, das nur installiert wird, wenn du es nutzt.

  • Anthropicdigline-anthropic
  • OpenAIdigline-openai und jeden OpenAI-kompatiblen Endpunkt
  • Amazon Bedrockdigline-bedrock

Ausgearbeitete Beispiele

Eine echte Anwendung je Framework, mit der zugehörigen Suite.

Weitere Wege, es auszuführen

Im Container oder für einen Agenten.

Checks

Deterministisch zuerst, Judge zuletzt.

Heute 22 checks, in fünf Arten. Die Liste wächst; die Arten bleiben.

Ohne Referenz und mit Referenz

Derselbe Eval-run, auf zwei Arten gelesen.

Zwischen zwei runs hat sich eine Zeile des Prompts geändert. Links die Scores, die du ohne Referenz bekommst. Rechts das, was digline gegen die freigegebene Referenz ausgibt.

Der neue run für sich allein keine Referenz

case               llm_rubric  containshow-do-i-return    0.40        0.00is-it-waterproof   0.40        0.00where-is-my-order  0.40        0.00Lagen die gestern bei 1.00? Hat sich etwas geändert?Hier steht nichts dazu.
keine baselinekeine Änderung festgehaltenkein Exit-Code

digline compare gegen die Referenz

6 checks got worse compared with the reference. Every case could be judged. No case is suspended. The suite is unchanged from the reference. 1 file under test changed since the reference.  prompt.md · +1 −1 lineshow-do-i-return · llm_rubric · Went from passing to failing (1.000000 → 0.400000).how-do-i-return · contains · Went from passing to failing (1.000000 → 0.000000).… 4 weitere Zeilenexit 1
jeder check benanntPrompt-Änderung erkanntexit 1

Beide Spalten stammen aus demselben aufgezeichneten run, digline 0.15.0. Links stehen nur die neuen Scores; rechts die Ausgabe des Vergleichs, an den markierten Stellen gekürzt.

Ausprobieren

Der Schnelleinstieg läuft ohne API-Schlüssel.

Du brauchst Python 3.12 oder neuer. Der Modellaufruf in der Anleitung ist vorgefertigt, du siehst also den ganzen Ablauf, bevor du einen echten Provider anbindest.

  1. digline run

    Führt die Suite aus und schreibt eine run-Datei.

  2. digline promote

    Ein Mensch gibt diesen run als Referenz frei.

  3. digline compare

    Jeder spätere run wird dagegen geprüft.

du tippst
digline gibt aus
$ pip install digline==0.15.0

      
$ digline run --suite support.py
2026-09-17T13-40-13-029556-00-00-282b0c02d6511fb4
$ digline promote --suite support.py --run latest
support baseline set to 2026-09-17T13-40-13-029556-00-00-282b0c02d6511fb4
$ digline compare --suite support.py --run latest
Nothing got worse compared with the reference. Every case could be judged. No case is suspended. The suite is unchanged from the reference.

Ausgabe aufgezeichnet mit digline 0.15.0, run 2026-09-17T13-40-13-029556…. Vollständige Anleitung

In einem agentischen Ablauf

Wo der check sitzt, wenn ein Agent die Änderungen vornimmt.

Der Agent ändert, digline entscheidet, ob die Änderung weiterlaufen darf.

Animiertes Diagramm von digline in einem agentischen Ablauf: Die Ausgabe eines Agenten läuft durch digline, ein gate in deinem Repository, das sie an einem noise floor und der freigegebenen baseline misst. Drift innerhalb des noise floor wird stillschweigend aufgefangen; eine echte Drift geht als Dossier an einen Menschen, und nur dessen Unterschrift aktualisiert die baseline. Wenn der Agent nach promote greift, antwortet der Server, dass es ein solches Werkzeug nicht gibt. Animiertes Diagramm von digline in einem agentischen Ablauf: Die Ausgabe eines Agenten läuft durch digline, ein gate in deinem Repository, das sie an einem noise floor und der freigegebenen baseline misst. Drift innerhalb des noise floor wird stillschweigend aufgefangen; eine echte Drift geht als Dossier an einen Menschen, und nur dessen Unterschrift aktualisiert die baseline. Wenn der Agent nach promote greift, antwortet der Server, dass es ein solches Werkzeug nicht gibt.

Roadmap

Wohin es geht

Ausgeliefert — Glaubwürdigkeit des Urteils: Ein Abfall ist erst dann eine Regression, wenn er das Intervall verlässt, das die baseline über ihre eigenen Stichproben gemessen hat; offen ist jetzt die Verbreitung.

Zwei Dinge werden nie auf der Roadmap stehen. Ein gehosteter Dienst, der deine Nutzdaten entgegennimmt — Prompts, Ausgaben und der Judge bleiben in deinem Perimeter. Und niemals das Sammeln von Nutzungsdaten.

die ganze Roadmap, Arbeitsstränge und gates statt Termine →

Pilotprojekte

Baust du LLM-Funktionen für Kunden?

Ich suche einige Pilotteams, die digline in echten Projekten einsetzen — besonders Teams, die KI-Lösungen für Dritte bauen und pflegen. Im Gegenzug bekommst du direkte Unterstützung und ein Mitspracherecht darüber, was als Nächstes entsteht.

Schreib mir: hello@digline.dev oder eröffne ein GitHub-Issue

Beginne mit einer Suite und einem freigegebenen run.

Für die Anleitung brauchst du keinen Schlüssel.

pip install digline