Przejdź do treści
Dokumentacja
Dziennik zmianCennikOtwórz konsolę

Przewodniki

Od zera do werdyktu o twojej własnej aplikacji

Masz funkcję w Pythonie, która odpowiada na pytania, i chcesz wiedzieć, czy jest wystarczająco dobra, by ją wydać. Trzy polecenia prowadzą od tej funkcji do decyzji o wydaniu, bez ręcznie pisanego YAML: oloproof init --system tworzy projekt wokół twojej funkcji, oloproof check mówi, czy zadziała, zanim cokolwiek zostanie wydane, a oloproof run decyduje. Wszystko działa na twojej maszynie, bez konta i bez wywołań modeli.

Każdy wynik poniżej pochodzi z uruchomienia tych poleceń na pokazanej funkcji.

1Twoja funkcja

Dowolna funkcja, która przyjmuje jeden przypadek i zwraca odpowiedź. Ta to bot.py, z modułem pomocniczym, który importuje:

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"}

2Utwórz projekt wokół niej

Z katalogu, w którym leży bot.py:

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

Odwołanie jest najpierw importowane i nic nie zostaje zapisane, dopóki nie wskaże funkcji; błąd w twoim module zatrzymuje wszystko tutaj, z plikiem i wierszem. Funkcja nie jest wywoływana. Pojawiają się trzy pliki: oloproof.yaml (twoja funkcja i jedno sprawdzenie), data/cases.jsonl (trzy przypadki zastępcze) i release.yaml (próg). Wejście przypadku jest napisem, bo pierwszy parametr nazywa się question; parametr o nazwie case, inputs lub row albo z adnotacją dict dostaje zamiast tego obiekt.

Sprawdzenie to contains: przypadek przechodzi, gdy odpowiedź zawiera oczekiwaną frazę przypadku. To sprawdzenie deterministyczne, więc nie musi być mierzone względem ludzi, zanim będzie mogło decydować. Przewodnik po zestawach wymienia każde inne sprawdzenie i sędziego.

3Uzupełnij przypadki

Zastąp przypadki zastępcze prawdziwymi pytaniami i słowami, które zawiera poprawna odpowiedź, jeden przypadek na wiersz:

{"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"}}

Trzy przypadki nie mogą przejść progu 0,80, jak mówi tabela powyżej: przy trzech najlepszą odpowiedzią jest INSUFFICIENT_EVIDENCE. Uruchomienie poniżej używa 30 takich przypadków, po dziesięć na temat, gdzie wystarczy 29 zaliczonych.

4Sprawdź, zanim uruchomisz

oloproof check

Zanim pole zostało ustawione, mówiło:

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.

Dodaj więc field: reply pod sprawdzeniem w oloproof.yaml i sprawdź ponownie:

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

Co oznacza każda część:

  • Importuje się i odpowiada: System jest budowany dokładnie tak, jak buduje go oloproof run, i wywoływany na pierwszym przypadku (--case ID wybiera inny, --no-call pomija wywołanie). Jeśli zgłosi wyjątek, wiersz podaje błąd oraz plik i wiersz w twoim kodzie.
  • Ewaluatory: Każde sprawdzenie, które nie potrzebuje modelu, jest uruchamiane na tej jednej odpowiedzi. Pole, którego nie może znaleźć, jest wymieniane razem z polami, które odpowiedź ma. Zaliczenie lub niezaliczenie tutaj to jeden przypadek, nie wynik. Sędzia modelowy nigdy nie jest wywoływany przez check; mówi o tym, a wywołuje go uruchomienie.
  • Kod: Pliki, których treść stanowi wersję systemu: jego moduł i moduły projektu, które importuje, plus ewentualne system.code_paths. Plik projektu wczytany podczas importowania lub wywoływania systemu, który do nich nie należy (na przykład moduł importowany po nazwie w czasie działania), jest wymieniany jako niehaszowany: dodaj go do code_paths, inaczej zmiana w nim ponownie użyje nieaktualnych odpowiedzi.
  • Co może rozstrzygnąć: Ta sama tabela co w oloproof plan. Bez release.yaml mówi, że uruchomienie odpowiada zwykłymi słowami i niczego nie rozstrzyga.
  • CI: Każdy model, który projekt wywołuje, i sekret, którego potrzebuje do niego zadanie CI, ANTHROPIC_API_KEY lub OPENAI_API_KEY, chyba że api_key_env wskazuje inny, i żaden dla serwera na tej maszynie.

check niczego nie zapisuje. Kończy się kodem 2, gdy coś trzeba naprawić, a w przeciwnym razie kodem 0, a oloproof check --json wypisuje te same ustalenia jako jeden dokument.

5Uruchom

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

Raport z uruchomienia jest dłuższy; to jego werdykt i wiersz reguły. Wszystkie 30 przypadków przeszło, a zakres, w którym utrzymywany jest wskaźnik, zaczyna się od 88,4%, powyżej progu 0,80, więc reguła mówi PASS, a bramka dopuszcza wydanie. oloproof inspect latest odczytuje go ponownie.

Dalej

  • Dodaj bramkę do pull requestów: oloproof init --ci github zapisuje workflow obok tego projektu (przewodnik po CI).
  • Zamień sprawdzenie na sędziego, gdy fraza nie potrafi powiedzieć, czym jest poprawna odpowiedź (przewodnik po sędziach); oloproof check wskaże wtedy klucz, którego potrzebuje CI.
  • Masz już odpowiedzi w pliku zamiast w funkcji? oloproof eval answers.jsonl sprawdza je bez żadnego projektu.