Änderungsprotokoll

oloproof 0.1.0a1 ist veröffentlicht, also beginnt der Golden Path mit pip install oloproof in einer sauberen Umgebung und führt direkt zu oloproof init und oloproof run. Releases werden aus einem getaggten Commit in der CI gebaut und über Trusted Publishing von PyPI veröffentlicht, ohne gespeichertes Token.

Ein Lauf oder ein Vergleich, der früh stoppt, zeichnet jetzt jeden Blick auf, den er geworfen hat, und die Workbench spielt sie ab: das jederzeit gültige Intervall, das sich bei jedem Blick gegenüber einem Schwellenwert verengt, der sich nicht bewegt, und den Blick, bei dem jede Regel entschieden hat. Sie zeichnet nur Intervalle, die die Engine aufgezeichnet hat. Ein Intervall mit fester Stichprobe wird nie so animiert, als wäre es live, denn wer eines beobachtet, bis es gut aussieht, hebt seine Garantie auf.

⌘K oder Ctrl+K listet jedes Ziel auf, das Sie sehen dürfen, und eine eingefügte Lauf-ID oder ein Vergleichs-Digest öffnet es. g und dann ein Buchstabe navigiert, j und k bewegen sich durch die Zeilen einer Tabelle, und ? listet alle Tastenkürzel auf. Ein Fall öffnet sich neben seinem Lauf, mit seiner Evidenzkette und den Personen, die ihn gelabelt haben. Bei reduzierter Bewegung stoppt jede Animation.

Die Workbench läuft jetzt auf oloproof.com, und der Golden Path hat dort Ende zu Ende bestanden: Ein Reviewer hat 80 Fälle gelabelt, die der Workspace gezogen hatte, 7 falsche Antworten gefunden, die der Judge durchgelassen hatte, und der Workspace hat auf seiner verifizierten Stichprobe auf Bestanden entschieden (91,2%, Intervall 74,5% bis 100,0%), wo der gepushte Lauf allein unzureichende Evidenz hatte. Zugang nur auf Einladung.

oloproof collect empfängt OTLP/HTTP von einem unveränderten OpenTelemetry SDK, setzt GenAI- und OpenInference-Spans zu inhaltsadressierten Traces zusammen und behält deren Inhalt auf Ihrem Rechner; ein Push folgt Ihrer Egress-Richtlinie. oloproof traces promote macht aus einem Trace einen Testfall mit seiner Herkunft und lehnt Duplikate ab.

Ihr Collector signiert stündlich eine Verpflichtung auf jeden Trace, den er versiegelt hat. Der Workspace zieht dann mit eigenem Zufall eine Stichprobe und prüft jeden gezogenen Trace gegen die Verpflichtung, sodass sich eine Stichprobe nicht durch Zurückhalten von Traces kuratieren lässt. oloproof traces evaluate bewertet die Stichprobe anhand ihrer aufgezeichneten Ausgaben, der Workspace entscheidet sie unter der Evaluierung, die ein Owner festgelegt hat, und eine Konfidenzsequenz verfolgt jede Metrik über die Stichproben hinweg auf der Production-Seite des Projekts.

Ein Owner oder Admin öffnet eine Warteschlange und weist Reviewer zu, die per Tastatur labeln: Pass oder Fail, ein Score auf einer deklarierten Skala oder eine blinde Präferenz zwischen zwei Läufen, jeweils pro Konto erfasst. Der Browser des Reviewers holt die Fallinhalte über ein signiertes Ticket mit fünf Minuten Gültigkeit von oloproof collect auf Ihrer Seite, sodass der Workspace sie nie hält.

Ein Lauf kann mit einem Runner-Schlüssel signiert werden, den ein Owner registriert hat, oder vom verwalteten Worker. Ein Owner legt die gesamte Evaluierung (Suite, Evaluatoren, Metriken und Baseline-Lauf) und ihre Gate-Richtlinie fest, und der Workspace entscheidet jede Systemversion bei ihrem ersten Lauf genau dieser Evaluierung, gegen den festgelegten Lauf. Menschliche Labels zählen nur von unabhängigen Labelern, gezählt pro Konto.

Ein PPI-Intervall korrigiert einen Judge mit einer Zufallsstichprobe menschlicher Labels, und seine Garantie braucht eine Stichprobe, die niemand ausgewählt hat. Der Workspace zieht diese Stichprobe jetzt, nachdem die Evidenz des Laufs dort eingefroren ist, behält den Seed für sich und prüft das korrigierte Intervall mit seiner eigenen Engine. Die Laufseite zeigt, ob der Workspace ein Intervall verifiziert hat; eine auf Ihrem eigenen Rechner gezogene Stichprobe bleibt als guter Glaube gekennzeichnet.

Eine Richtlinie mit early_stopping: true führt Fälle in geseedeten Batches aus und stoppt einen Lauf, oder einen Kandidaten und seine Baseline im Gleichschritt, sobald jede Regel entschieden hat, erfasst als DECIDED_EARLY zusammen mit den Fällen, die nicht nötig waren. Gestoppte Raten verwenden ein jederzeit gültiges Betting-Intervall, sodass ein Blick nach jedem Batch die Garantie erhält. Die Pass-Rate eines Judges kann über ein PPI-Intervall gegatet werden, das den Judge mit einer blinden Zufallsstichprobe menschlicher Labels kombiniert, angezeigt neben den Intervallen nur aus dem Judge und nur aus Menschen.

Vier Benachrichtigungen, jede eine Kategorie, die ein Mitglied direkt aus der E-Mail abschalten kann: ein verwalteter Job ist fertig oder fehlgeschlagen, ein gepushter Lauf oder Vergleich, dessen Gate ein Release blockiert, eine Nutzung von 80% und 100% des kostenlosen Kontingents, und ein Mitglied ist beigetreten. Eine Gate-E-Mail zitiert die gespeicherte Entscheidung und verlinkt auf den Lauf, ohne Fallinhalte. Nur E-Mail: kein Slack, kein Pager, kein Webhook.

Anmeldung mit E-Mail-Adresse und Passwort sowie über einen Anbieter, mit verifizierten Adressen und Zurücksetzen. Eine Person kann ihr eigenes Konto löschen: Der Nutzer und jeder Workspace, dem nur er angehörte, verschwinden auf einmal, und der Worker löscht die Evidenz dieser Workspaces.

Ein Judge kann eine typisierte Frage (ja oder nein, eine Auswahl, ein Score gegen Stufen) mit einer Wahrscheinlichkeit für jede Antwort beantworten, gelesen aus den Token-Wahrscheinlichkeiten eines lokalen Modells in einem einzigen Forward Pass. Seine Kalibrierung wird gegen menschliche Labels gemessen und in seinem Registry-Eintrag erfasst, und eine Kaskade schickt nur die Fälle, bei denen ein günstiger Judge unsicher ist, an einen stärkeren. Auch ein trainierter Klassifikator kann ein Evaluator sein, ohne Schlüssel und ohne Netzwerk.

Labeln Sie die Fälle eines Laufs aus einer Datei oder im Terminal, und testen Sie einen Judge-Entwurf gegen diese Labels, bevor Sie ihn übernehmen. Ein Judge meldet seinen Bias neben seiner Übereinstimmung, einer, dessen Bias eine deklarierte Marge überschreitet, darf kein Gate entscheiden, und eine Validierung zählt nicht mehr, sobald sich das gemessene Modell ändert. Label-freie Proben prüfen, ob sich ein Urteil bewegt, wenn sich nichts Relevantes geändert hat, und paarweise Vergleiche werden in beiden Reihenfolgen gestellt, sodass eine Antwort, die nur wegen ihrer Position bevorzugt wird, auffällt, ohne dass jemand labelt.

Eine Trajektorie zeichnet auf, welcher Agent jeden Schritt ausgeführt hat, und jede Übergabe. Evaluatoren bewerten das Routing (erreichte die Anfrage den Agenten, der sie bearbeiten soll), Tool-Berechtigungen (hat ein Agent ein Tool aufgerufen, das ihm nicht zustand) und Agenten, die die Kontrolle hin und her reichen, statt fertig zu werden, und Slices gruppieren Fälle nach Route.

Eine Suite kann jeden Fall mehrfach messen. Replikate werden vor jedem Intervall pro Fall aggregiert, Vergleiche paaren sie als Anteile, und der Lauf meldet, wie viele Fälle sich selbst widersprochen haben. Ein System kann einen Fehler als transient markieren, damit der Runner ihn wiederholt: Bei einem live laufenden RAG-System holte das 18 von 22 fehlenden Fällen zurück und verengte das Intervall um 39%.