Zum Inhalt springen
Doku
ÄnderungsprotokollPreiseKonsole öffnen

Anleitungen

Von null zu einem Urteil über Ihre eigene Anwendung

Sie haben eine Python-Funktion, die Fragen beantwortet, und möchten wissen, ob sie gut genug für eine Veröffentlichung ist. Drei Befehle führen Sie von dieser Funktion zu einer Freigabeentscheidung, ohne handgeschriebenes YAML: oloproof init --system legt das Projekt um Ihre Funktion herum an, oloproof check sagt, ob es funktionieren wird, bevor etwas ausgegeben wird, und oloproof run entscheidet. Alles läuft auf Ihrem Rechner, ohne Konto und ohne Modellaufrufe.

Jede Ausgabe unten stammt aus der Ausführung dieser Befehle mit der gezeigten Funktion.

1Ihre Funktion

Jede Funktion, die einen Fall entgegennimmt und eine Antwort zurückgibt. Diese hier ist bot.py, mit einem Hilfsmodul, das sie importiert:

from prompts import GREETING


def answer(question):
    text = question.lower()
    if "refund" in text:
        reply = "Refunds are available within 30 days of purchase."
    elif "ship" in text:
        reply = "We ship to the US and Canada."
    else:
        reply = "A support agent will follow up within one business day."
    return {"reply": f"{GREETING} {reply}", "topic": "support"}

2Das Projekt um sie herum anlegen

Aus dem Verzeichnis, das bot.py enthält:

oloproof init --system bot:answer
Initialized Oloproof project in . around bot:answer
  Each case's input is a string, read from the function's first parameter.

Fill in before a run means anything:
  data/cases.jsonl  3 placeholder cases: give each a real input and, as its expected
                    phrase, words a right answer contains. Add more: see below.
  oloproof.yaml     the check reads the whole answer; if your function returns an
                    object, add `field:` naming the key that holds the text.
  release.yaml      a placeholder bar of 0.80; set the one your release needs.

What this suite can decide, if every case is measured:
  mentions-floor (mentions_expected at least 0.8, 3 cases):
    1 or more pass: INSUFFICIENT_EVIDENCE (not established yet); 0: FAIL
    (ruled out). With 50 cases, PASS from 46; with 100, from 89.

Next: oloproof check, then oloproof run

Die Referenz wird zuerst importiert, und nichts wird geschrieben, solange sie sich nicht zu einer Funktion auflöst; ein Fehler in Ihrem Modul hält hier an, mit Datei und Zeile. Die Funktion wird nicht aufgerufen. Drei Dateien entstehen: oloproof.yaml (Ihre Funktion und eine Prüfung), data/cases.jsonl (drei Platzhalterfälle) und release.yaml (die Schwelle). Die Eingabe des Falls ist eine Zeichenkette, weil der erste Parameter question heißt; ein Parameter namens case, inputs, row oder einer, der als dict annotiert ist, erhält stattdessen ein Objekt.

Die Prüfung ist contains: Ein Fall besteht, wenn die Antwort die erwartete Phrase des Falls enthält. Sie ist eine deterministische Prüfung und muss daher nicht an Menschen gemessen werden, bevor sie entscheiden darf. Der Leitfaden zu Suiten listet jede andere Prüfung und jeden Judge auf.

3Die Fälle ausfüllen

Ersetzen Sie die Platzhalter durch echte Fragen und die Wörter, die eine richtige Antwort enthält, ein Fall pro Zeile:

{"id": "refund_01", "input": "Can I get a refund?", "expected": {"phrase": "30 days"}}
{"id": "ship_01", "input": "Do you ship to Canada?", "expected": {"phrase": "US and Canada"}}
{"id": "other_01", "input": "My order is late", "expected": {"phrase": "follow up"}}

Drei Fälle können eine Schwelle von 0.80 nicht erreichen, wie die Tabelle oben sagt: Mit dreien ist die beste Antwort INSUFFICIENT_EVIDENCE. Der Lauf unten verwendet 30 solche Fälle, zehn pro Thema, bei denen 29 bestandene genügen.

4Vor dem Lauf prüfen

oloproof check

Bevor das Feld gesetzt war, sagte es:

ok   System: callable bot:answer imports.
ok   Called on case refund_01: it answered {"reply": "Thanks for writing in. Refunds are available within 30 days of purchase.", "topic": "support"}

Evaluators on that answer (one case, not a result):
ok   mentions_expected (contains) can read the answer; it passed this case.
note   It reads the whole answer object; `field:` can name one of reply, topic.

Fügen Sie also field: reply unter der Prüfung in oloproof.yaml hinzu und prüfen Sie erneut:

ok   System: callable bot:answer imports.
ok   Called on case refund_01: it answered {"reply": "Thanks for writing in. Refunds are available within 30 days of purchase.", "topic": "support"}

Evaluators on that answer (one case, not a result):
ok   mentions_expected (contains) can read the answer; it passed this case.

Code: the system's version hashes bot.py, prompts.py. Edit one and the next run calls the system again.

What this suite can decide, if every case is measured:
  mentions-floor (mentions_expected at least 0.8, 30 cases):
    29 or 30 pass: PASS (established); 19 to 28: INSUFFICIENT_EVIDENCE (not
    established yet); 18 or fewer: FAIL (ruled out). With 50 cases, PASS from
    46; with 100, from 89.

CI: no model key is needed for the evaluators. Keys your own function reads are not checked here.

Ready. Next: oloproof run

Was jeder Teil bedeutet:

  • Importiert und antwortet: Das System wird genau so gebaut, wie oloproof run es baut, und mit dem ersten Fall aufgerufen (--case ID wählt einen anderen, --no-call überspringt den Aufruf). Wirft es eine Ausnahme, nennt die Zeile den Fehler sowie Datei und Zeile in Ihrem Code.
  • Evaluatoren: Jede Prüfung, die kein Modell braucht, läuft auf dieser einen Antwort. Ein Feld, das sie nicht findet, wird zusammen mit den Feldern genannt, die die Antwort hat. Ein Bestehen oder Scheitern hier ist ein Fall, kein Ergebnis. Ein Modell-Judge wird von check nie aufgerufen; es sagt das, und ein Lauf ruft ihn auf.
  • Code: Die Dateien, deren Inhalt die Version des Systems ist: sein Modul und die Projektmodule, die es importiert, dazu alle system.code_paths. Eine Projektdatei, die beim Importieren oder Aufrufen des Systems geladen wird und nicht darunter ist (etwa ein zur Laufzeit per Namen importiertes Modul), wird als nicht gehasht aufgeführt: Fügen Sie sie zu code_paths hinzu, sonst verwendet eine Änderung daran veraltete Antworten wieder.
  • Was es entscheiden kann: Dieselbe Tabelle wie oloproof plan. Ohne release.yaml sagt es, dass ein Lauf in einfachen Worten antwortet und nichts entscheidet.
  • CI: Jedes Modell, das das Projekt aufruft, und das Secret, das ein CI-Job dafür braucht, ANTHROPIC_API_KEY oder OPENAI_API_KEY, sofern api_key_env kein anderes nennt, und keines für einen Server auf diesem Rechner.

check speichert nichts. Es endet mit 2, wenn etwas behoben werden muss, und sonst mit 0, und oloproof check --json gibt dieselben Befunde als ein Dokument aus.

5Ausführen

oloproof run
Gate: ALLOW (exit 0)
mentions-floor:
  100.0%, range 88.4% to 100.0% (exact binomial interval); 30 of 30 cases

Der Bericht des Laufs ist länger; dies sind sein Urteil und die Zeile der Regel. Alle 30 Fälle haben bestanden, und der Bereich, auf den die Rate festgelegt ist, beginnt bei 88,4 %, über der Schwelle von 0.80, also sagt die Regel PASS und das Gate erlaubt die Freigabe. oloproof inspect latest liest ihn erneut.

Weiter

  • Das Gate zu Pull Requests hinzufügen: oloproof init --ci github schreibt den Workflow neben dieses Projekt (CI-Leitfaden).
  • Die Prüfung durch einen Judge ersetzen, wenn eine Phrase nicht sagen kann, was eine richtige Antwort ist (Leitfaden zu Judges); oloproof check nennt dann den Schlüssel, den die CI braucht.
  • Sie haben Antworten bereits in einer Datei statt in einer Funktion? oloproof eval answers.jsonl prüft sie ganz ohne Projekt.