Guías

De cero a un veredicto sobre su propia aplicación

Tiene una función de Python que responde preguntas y quiere saber si es lo bastante buena para publicarla. Tres comandos le llevan de esa función a una decisión de publicación, sin YAML escrito a mano: oloproof init --system escribe el proyecto alrededor de su función, oloproof check dice si funcionará antes de gastar nada, y oloproof run decide. Todo se ejecuta en su máquina, sin cuenta y sin llamadas a modelos.

Cada salida de abajo proviene de ejecutar estos comandos sobre la función mostrada.

1. Su función

Cualquier función que reciba un caso y devuelva una respuesta. Esta es bot.py, con un módulo auxiliar que importa:

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

2. Escribir el proyecto alrededor de ella

Desde el directorio que contiene 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

La referencia se importa primero, y no se escribe nada a menos que se resuelva en una función; un error en su módulo se detiene aquí con su archivo y su línea. La función no se llama. Aparecen tres archivos: oloproof.yaml (su función y una comprobación), data/cases.jsonl (tres casos provisionales) y release.yaml (el umbral). La entrada del caso es una cadena porque el primer parámetro se llama question; un parámetro llamado case, inputs, row o anotado como dict recibe en cambio un objeto.

La comprobación es contains: un caso pasa cuando la respuesta contiene la frase esperada del caso. Es una comprobación determinista, así que no necesita medirse frente a personas antes de poder decidir. La guía de suites enumera todas las demás comprobaciones y jueces.

3. Rellenar los casos

Sustituya los casos provisionales por preguntas reales y las palabras que contiene una respuesta correcta, un caso por línea:

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

Tres casos no pueden superar un umbral de 0.80, como dice la tabla de arriba: con tres, la mejor respuesta es INSUFFICIENT_EVIDENCE. La ejecución de abajo usa 30 casos como estos, diez por tema, donde basta con que pasen 29.

4. Comprobar antes de ejecutar

oloproof check

Antes de definir el campo, decía:

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.

Así que añada field: reply bajo la comprobación en oloproof.yaml y vuelva a comprobar:

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

Lo que significa cada parte:

Importa y responde: El sistema se construye exactamente como lo construye oloproof run, y se llama sobre el primer caso (--case ID elige otro, --no-call omite la llamada). Si lanza una excepción, la línea nombra el error y el archivo y la línea de su código.
Evaluadores: Cada comprobación que no necesita modelo se ejecuta sobre esa única respuesta. Un campo que no encuentra se nombra junto con los campos que tiene la respuesta. Un aprobado o un fallo aquí es un caso, no un resultado. check nunca llama a un juez basado en modelo; lo dice, y una ejecución lo llama.
Código: Los archivos cuyo contenido es la versión del sistema: su módulo y los módulos del proyecto que importa, más cualquier system.code_paths. Un archivo del proyecto cargado al importar o llamar al sistema que no esté entre ellos (un módulo importado por nombre en tiempo de ejecución, por ejemplo) se lista como no hasheado: añádalo a code_paths, o un cambio en él reutiliza respuestas obsoletas.
Lo que puede decidir: La misma tabla que oloproof plan. Sin un release.yaml, dice que una ejecución responde con palabras sencillas y no decide nada.
CI: Cada modelo que llama el proyecto y el secreto que necesita un job de CI para él, ANTHROPIC_API_KEY u OPENAI_API_KEY salvo que api_key_env nombre otro, y ninguno para un servidor en esta máquina.

check no almacena nada. Sale con 2 cuando hay algo que corregir y con 0 en caso contrario, y oloproof check --json imprime los mismos hallazgos como un único documento.

5. Ejecutarlo

oloproof run

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

El informe de la ejecución es más largo; estos son su veredicto y la línea de la regla. Los 30 casos pasaron, y el rango al que se sujeta la tasa empieza en 88,4 %, por encima del umbral de 0.80, así que la regla dice PASS y la puerta permite la publicación. oloproof inspect latest lo vuelve a leer.