Ga naar de inhoud
Docs
WijzigingslogboekPrijzenConsole openen

Handleidingen

Van nul naar een oordeel over je eigen applicatie

Je hebt een Python-functie die vragen beantwoordt, en je wilt weten of die goed genoeg is om uit te brengen. Drie commando's brengen je van die functie naar een releasebeslissing, zonder met de hand geschreven YAML: oloproof init --system schrijft het project rond je functie, oloproof check zegt of het zal werken voordat er iets wordt uitgegeven, en oloproof run beslist. Alles draait op je eigen machine, zonder account en zonder modelaanroepen.

Elke uitvoer hieronder komt van het draaien van deze commando's op de getoonde functie.

1Je functie

Elke functie die één case aanneemt en een antwoord teruggeeft. Deze is bot.py, met een hulpmodule die hij importeert:

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

2Schrijf het project eromheen

Vanuit de map waarin bot.py staat:

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

De verwijzing wordt eerst geïmporteerd, en er wordt niets geschreven tenzij die naar een functie leidt; een fout in je module stopt hier, met het bestand en de regel. De functie wordt niet aangeroepen. Er verschijnen drie bestanden: oloproof.yaml (je functie en één controle), data/cases.jsonl (drie tijdelijke cases) en release.yaml (de lat). De invoer van de case is een string omdat de eerste parameter question heet; een parameter met de naam case, inputs of row, of geannoteerd als dict, krijgt in plaats daarvan een object.

De controle is contains: een case slaagt wanneer het antwoord de verwachte zinsnede van de case bevat. Het is een deterministische controle, dus hij hoeft niet tegen mensen gemeten te worden voordat hij mag beslissen. De gids over suites noemt elke andere controle en judge.

3Vul de cases in

Vervang de tijdelijke cases door echte vragen en de woorden die een juist antwoord bevat, één case per regel:

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

Drie cases kunnen een lat van 0,80 niet halen, zoals de tabel hierboven zegt: met drie is het beste antwoord INSUFFICIENT_EVIDENCE. De run hieronder gebruikt 30 cases zoals deze, tien per onderwerp, waarbij 29 geslaagde genoeg zijn.

4Controleer voordat je draait

oloproof check

Voordat het veld was ingesteld, zei het:

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.

Voeg dus field: reply toe onder de controle in oloproof.yaml, en controleer opnieuw:

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

Wat elk deel betekent:

  • Importeert en antwoordt: Het systeem wordt precies zo opgebouwd als oloproof run het opbouwt, en aangeroepen op de eerste case (--case ID kiest een andere, --no-call slaat de aanroep over). Als het een fout opwerpt, noemt de regel de fout en het bestand en de regel in je code.
  • Evaluators: Elke controle die geen model nodig heeft, draait op dat ene antwoord. Een veld dat hij niet kan vinden, wordt genoemd samen met de velden die het antwoord wel heeft. Slagen of falen hier is één case, geen resultaat. Een model-judge wordt nooit door check aangeroepen; het zegt dat, en een run roept hem aan.
  • Code: De bestanden waarvan de inhoud de versie van het systeem is: zijn module en de projectmodules die hij importeert, plus eventuele system.code_paths. Een projectbestand dat wordt geladen tijdens het importeren of aanroepen van het systeem en daar niet bij hoort (bijvoorbeeld een module die tijdens het draaien bij naam wordt geïmporteerd), wordt vermeld als niet gehasht: voeg het toe aan code_paths, anders hergebruikt een wijziging eraan verouderde antwoorden.
  • Wat het kan beslissen: Dezelfde tabel als oloproof plan. Zonder release.yaml zegt het dat een run in gewone woorden antwoordt en niets beslist.
  • CI: Elk model dat het project aanroept en het geheim dat een CI-job ervoor nodig heeft, ANTHROPIC_API_KEY of OPENAI_API_KEY tenzij api_key_env een ander noemt, en geen voor een server op deze machine.

check slaat niets op. Het eindigt met code 2 wanneer er iets moet worden verholpen en anders met 0, en oloproof check --json drukt dezelfde bevindingen af als één document.

5Draai het

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

Het rapport van de run is langer; dit zijn het oordeel en de regel van de controleregel. Alle 30 cases slaagden, en het bereik waarbinnen de score wordt gehouden begint bij 88,4%, boven de lat van 0,80, dus de regel zegt PASS en de gate staat de release toe. oloproof inspect latest leest het opnieuw.

Volgende stappen

  • Voeg de gate toe aan pull requests: oloproof init --ci github schrijft de workflow naast dit project (CI-gids).
  • Vervang de controle door een judge wanneer een zinsnede niet kan zeggen wat een juist antwoord is (gids over judges); oloproof check noemt dan de sleutel die CI nodig heeft.
  • Heb je de antwoorden al in een bestand in plaats van een functie? oloproof eval answers.jsonl controleert ze zonder enig project.