가이드
처음부터 내 앱의 판정까지
질문에 답하는 Python 함수가 있고, 그것을 출시해도 될 만큼 좋은지 알고 싶다고 합시다. 손으로 쓴 YAML 없이 세 개의 명령으로 그 함수에서 릴리스 결정까지 갑니다. oloproof init --system은 함수를 둘러싼 프로젝트를 만들고, oloproof check는 무엇이든 쓰기 전에 그것이 작동할지 알려 주며, oloproof run이 결정합니다. 모든 것이 내 머신에서 실행되며, 계정도 모델 호출도 필요 없습니다.
아래의 모든 출력은 보여 준 함수에 이 명령들을 실행한 결과입니다.
1. 내 함수
케이스 하나를 받아 답을 돌려주는 함수라면 무엇이든 됩니다. 이 예는 bot.py이며, 가져오는 보조 모듈이 있습니다.
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. 그 주위에 프로젝트 만들기
bot.py가 있는 디렉터리에서 실행합니다.
oloproof init --system bot:answerInitialized 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참조를 먼저 가져오며, 함수로 확인되지 않으면 아무것도 쓰지 않습니다. 모듈에 오류가 있으면 그 파일과 줄을 보여 주고 여기서 멈춥니다. 함수는 호출되지 않습니다. 세 개의 파일이 생깁니다. oloproof.yaml(함수와 검사 하나), data/cases.jsonl(자리표시 케이스 세 개), release.yaml(기준)입니다. 첫 번째 매개변수 이름이 question이므로 케이스의 입력은 문자열입니다. 이름이 case, inputs, row이거나 dict로 주석된 매개변수는 대신 객체를 받습니다.
검사는 contains입니다. 답에 케이스의 기대 문구가 들어 있으면 그 케이스는 통과합니다. 결정적인 검사이므로 결정에 쓰이기 전에 사람과 대조해 측정할 필요가 없습니다. 다른 모든 검사와 심사기는 스위트 가이드에 있습니다.
3. 케이스 채우기
자리표시를 실제 질문과 올바른 답에 들어가는 단어로 바꿉니다. 한 줄에 케이스 하나입니다.
{"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"}}위 표가 말하듯 케이스 세 개로는 0.80 기준을 통과할 수 없습니다. 세 개로는 최선의 답이 INSUFFICIENT_EVIDENCE입니다. 아래 실행은 이런 케이스를 주제마다 열 개씩 30개 사용하며, 이때는 29개 통과로 충분합니다.
4. 실행하기 전에 검사하기
oloproof check필드를 설정하기 전에는 이렇게 나왔습니다.
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.그래서 oloproof.yaml의 검사 아래에 field: reply를 추가하고 다시 검사합니다.
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각 부분의 의미는 다음과 같습니다.
- 가져오기와 답: 시스템은 oloproof run이 만드는 방식 그대로 만들어지고 첫 번째 케이스로 호출됩니다(--case ID는 다른 케이스를 고르고, --no-call은 호출을 건너뜁니다). 예외가 나면 그 줄이 오류와 내 코드의 파일과 줄을 알려 줍니다.
- 평가기: 모델이 필요 없는 각 검사를 그 답 하나에 실행합니다. 찾지 못한 필드는 답이 가진 필드와 함께 알려 줍니다. 여기서의 통과나 실패는 케이스 하나이지 결과가 아닙니다. 모델 심사기는 check가 절대 호출하지 않습니다. 그렇다고 알려 주며, 실행이 호출합니다.
- 코드: 그 내용이 시스템의 버전이 되는 파일들입니다. 시스템의 모듈과 그것이 가져오는 프로젝트 모듈, 그리고 system.code_paths가 있다면 그것까지입니다. 시스템을 가져오거나 호출하는 동안 읽힌 프로젝트 파일 가운데 여기에 없는 것(예를 들어 실행 중에 이름으로 가져오는 모듈)은 해시되지 않은 것으로 나열됩니다. code_paths에 추가하세요. 그러지 않으면 그 파일을 바꿔도 오래된 답을 재사용합니다.
- 결정할 수 있는 것: oloproof plan과 같은 표입니다. release.yaml이 없으면 실행이 쉬운 말로 답하고 아무것도 결정하지 않는다고 알려 줍니다.
- CI: 프로젝트가 호출하는 각 모델과 그것을 위해 CI 작업에 필요한 비밀입니다. api_key_env가 다른 이름을 지정하지 않는 한 ANTHROPIC_API_KEY 또는 OPENAI_API_KEY이며, 이 머신의 서버에는 아무것도 필요 없습니다.
check는 아무것도 저장하지 않습니다. 고쳐야 할 것이 있으면 2로, 그렇지 않으면 0으로 종료하며, oloproof check --json은 같은 결과를 하나의 문서로 출력합니다.
5. 실행하기
oloproof runGate: ALLOW (exit 0)
mentions-floor:
100.0%, range 88.4% to 100.0% (exact binomial interval); 30 of 30 cases실행 보고서는 더 길며, 이것은 그 판정과 규칙의 줄입니다. 30개 케이스가 모두 통과했고, 비율이 놓인 범위는 88.4%에서 시작해 기준 0.80보다 높습니다. 그래서 규칙은 PASS이고 게이트는 릴리스를 허용합니다. oloproof inspect latest로 다시 읽을 수 있습니다.