Anleitungen
Was heute funktioniert
Was Sie heute mit Oloproof evaluieren können, wie Sie es erreichen (Python SDK, oloproof.yaml und die CLI oder der Browser) und was nicht gebaut ist. Die Seite stützt sich auf das Fähigkeitsaudit vom 8. Oktober 2026, eine interne Prüfung, die jede Zeile am Code und an seinen Tests geprüft hat statt an Plänen.
So lesen Sie diese Seite
„SDK“ bezeichnet das Python-Paket (import oloproof). „YAML“ bezeichnet ein Projekt, das Sie mit oloproof run aus oloproof.yaml ausführen. Das ist nicht dieselbe Oberfläche: Einige Evaluatoren gibt es nur in einer davon, und diese Seite sagt, in welcher. „Browser“ bezeichnet die gehostete Workbench, die zeigt, was Sie mit oloproof push hochladen; sie führt keine Evaluierungen aus, die Sie nicht in Code oder YAML definiert haben.
Oloproof ruft Ihr System auf; es hostet, isoliert oder setzt es nicht zurück. Ihre Anwendung verwaltet während eines Laufs ihren eigenen Zustand, ihre Sitzungen und die Nebenwirkungen ihrer Tools.
Nach Art des Systems
| Ihr System | Was funktioniert | Wo | Nicht gebaut |
|---|---|---|---|
| Klassifikator oder strukturierte Ausgabe | Exakte Übereinstimmung, enthält, Regex, JSON-Schema, Rubrik-Judge, Wahrscheinlichkeits-Judge, Modell-Klassifikator; Bestehensraten mit Intervallen | SDK und YAML; model_classifier, probability_judge und cascade nur in YAML | n/a |
| Textgenerierung, Zusammenfassungen, Extraktion | Dieselben Prüfungen über freien Text, Rubrik-Judges, Übereinstimmung des Judges mit menschlichen Labels, paarweise Präferenz | SDK und YAML; Präferenz ist der Befehl oloproof prefer | BLEU, ROUGE oder Embedding-Ähnlichkeit (schreiben Sie eine mit @evaluator) |
| RAG, das Sie als Blackbox betreiben | Trefferquote, Recall, MRR, nDCG, Zitatgültigkeit, Judges für Fundierung und Zitatstützung, aus Retrieval-Artefakten, die Ihr System aufzeichnet oder zurückgibt | SDK und YAML | Diagnose: diagnose braucht ein gestuftes System |
| RAG in Stufen gebaut | Alles oben Genannte, Caching pro Stufe und oloproof diagnose mit Gold-Kontext, Änderungen an Top-k oder Reranker neben einer Kontrolle | SDK @rag_system, YAML system.rag, CLI diagnose | Interventionen über diese drei hinaus |
| Agent mit Tools | Schrittlimits, erforderliche und verbotene Tools, Tool-Reihenfolge, Schleifen, Einschränkungen, aus einer aufgezeichneten Trajektorie | SDK und YAML | Eine von einem LLM beurteilte Prüfung der Trajektorienqualität |
| Multi-Agenten-System | Routing, Tool-Berechtigungen pro Agent, Übergabelimits | SDK und YAML | n/a |
| Agenten-Replay | Einen Fall ab einem Checkpoint erneut ausführen, um einen Schritt als nötig oder unnötig zu kennzeichnen | Nur SDK (replay_case), für ein System, das Checkpoints unterstützt | Ein CLI-Befehl |
| Binäres Klassifikationsmodell | Accuracy, Precision, Recall, Brier, Log Loss, Ranking (AUC) | SDK und YAML predictive: | n/a |
| Mehrklassenmodell | Ein Block pro Klasse (eine gegen den Rest) | SDK und YAML | Makro- oder Mikro-Mittelwerte |
| Regressionsmodell | Absoluter Fehler innerhalb eines deklarierten target_range | SDK und YAML | Quadratischer Fehler, R-Quadrat, unbeschränkter Fehler |
| Gespräch über mehrere Runden | Ob jede vorgegebene Runde beantwortet wurde, und ein Rubrik-Judge über das ganze Gespräch | Nur SDK (ConversationCompleted, ConversationJudge) | YAML-Typen, Bewertungen pro Runde, ein Nutzersimulator, Gesprächs-Replay |
| Bilder, Audio, Video | Nichts nativ: Ein Fall kann eine URL oder eine kodierte Datei durch Ihr System tragen, und @evaluator kann die Ausgabe prüfen | n/a | Judges sehen nur JSON-Text; keine Medienartefakte oder Darstellung |
Ein Behelf für mehrere Runden: Machen Sie jede Runde zu einem Fall und geben Sie den Runden eines Gesprächs dieselbe group_id, damit die Analyse sie als Cluster behandelt (Geclusterte Fälle). Jede Runde ist dann ein eigener Aufruf, kein aufgezeichneter Dialog.
Ihr System anbinden
- Python-Callable: @system im SDK oder system.callable: module:function in YAML. Es erhält den input des Falls und gibt ein Dictionary zurück. Synchrone und asynchrone Funktionen funktionieren beide.
- HTTP: system.http mit url, method, output_path, artifacts und timeout_s. Die Eingabe des Falls wird als JSON-Body gesendet und die Antwort als JSON gelesen. Header und Authentifizierung lassen sich noch nicht konfigurieren; stellen Sie einen Endpunkt, der einen Schlüssel braucht, hinter ein Callable, das ihn hinzufügt.
- Benutzerdefinierte Evaluatoren: @evaluator im SDK. oloproof.yaml kann noch keinen benennen.
Arbeitsabläufe
| Arbeitsablauf | Was funktioniert | Nicht gebaut |
|---|---|---|
| Zwei Versionen vergleichen | Gepaarte Überlegenheit, Nicht-Unterlegenheit und Äquivalenz; Slices mit Multiplizitätskontrolle | n/a |
| CI | Exit-Codes von oloproof gate nach dem block_on Ihrer Policy, Freigabe, signierte Datensätze; eine Pull-Request-Zusammenfassung (--summary markdown) | n/a |
| Menschliche Prüfung | Labels aus einer Datei oder dem Terminal; eine Prüfwarteschlange im Browser mit zugewiesenen Prüfern in einem gehosteten Workspace | Eine Prüfwarteschlange im Browser für ein lokales Projekt |
| Workbench im Browser | Läufe, Fälle, Vergleiche, Diagnosen, Evaluatoren, Prüfung und Traffic, nach oloproof push | Datensatzimport, Erstellen von Judges, Zeitpläne, Warnungen und Postmortems (als geplant angezeigt) |
| Lokaler Browser | n/a | Kein CLI-Befehl stellt die Workbench lokal bereit; sie ist gehostet |
Was getestet wurde, und wie
Jede Familie oben hat automatisierte Tests, die auf Fixtures und simulierten Anbietern laufen. Läufe gegen echte Systeme mit echten Modellen sind für RAG, einen einzelnen Agenten und ein Gespräch über mehrere Runden aufgezeichnet; noch keine für prädiktive Modelle oder Multi-Agenten-Systeme. Statistische Methoden, die über Releases entscheiden, sind jeweils durch ihr eigenes Audit zugelassen; eine Metrik ohne zugelassenes Intervall entscheidet keine Regel anhand eines Intervalls, und eine Regel, die eines bräuchte, liefert MANUAL_REVIEW oder INSUFFICIENT_EVIDENCE mit ihrem Grund.