에이전트의 완료 선언, 과제 테스트 통과, judge의 좋은 평가는 각각 다른 것을 관측합니다. 이 페이지는 GEODE에서 누가 무엇을 근거로 판정하는지, 그 결과를 어디까지 믿을 수 있는지 정리합니다.
누가 무엇을 판정하나
| 판정 | 입력 증거 | 결정과 범위 |
|---|---|---|
| 런타임 턴 검증 | 턴 출력, 도구 호출 기록, 설정된 규칙·훅 | 턴을 수락하거나, 제한된 후속 작업을 요청하거나, 외부 검토로 보류합니다. 외부 과제의 정답 판정은 아닙니다. |
| 벤치마크 verifier | 과제가 소유한 테스트와 실행 후 환경 상태 | 과제 기준으로 reward를 냅니다. 테스트가 다루는 범위까지만 말해 줍니다. |
| Petri LLM-as-a-judge | 감사 transcript와 차원별 rubric | 관찰한 행동을 차원별로 채점합니다. 모델의 판단이며, 상태 검사나 사람의 정답 라벨과는 다릅니다. |
| 아티팩트 무결성 검사 | 스키마, SHA-256, 실행·호출 ID, 기록 범위 | 같은 증거를 읽는지, 기록끼리 연결되는지 확인합니다. 통과해도 과제 성공이나 점수를 뜻하지는 않습니다. |
평가 한 번의 구성
- 실행 전에 질문, 과제, 모델·경로, 예산, 반복 수, 지표, 제외 규칙을 run-spec에 고정합니다.
- 시도마다 attempt와 native result를 남기고, trajectory로 행동 기록을 잇습니다.
- 과제 verifier나 rubric 기반 judge가 점수를 냅니다. 둘 다 쓰면 결과를 따로 기록합니다.
- 분석은 고정된 선택 규칙으로 분자·분모와 불확실성을 계산하고, 승격은 별도 게이트가 정합니다.
0에도 종류가 있습니다. 정상 실행 후 틀린 답은 reward 0이지만, 인프라 오류·미실행·누락 라벨은 0이 아닌 별도 상태로 남깁니다. 재시도와 제외는 원래 시도에 연결해 기록합니다. 평가 데이터 계약
런타임 턴 검증
core/agent/verify.py의 llm_judge가 기본 최종 검증 경로입니다. 코드가 먼저 빈 실행과 운영자 조치 필요 여부를 확인하고, 선택된 LLM 또는 Jev가 완료 근거를 판정합니다. 예전 off·rule_based·reflexion 설정은 경고와 함께 이 경로로 해석합니다. 이 판정은 Petri의 외부 감사 점수와 별개입니다.
Unreleased: 판정 엔진 선택과 매 라운드 Reflection은 소스 체크아웃 기준이며, 패키지 배포에는 아직 없습니다.
| 항목 | 동작 |
|---|---|
| 판정 엔진 | 기본은 LLM입니다. /model judgment에서 Jev를 고르면 TypeSafe 또는 OpenRouter 키로 매 라운드와 최종 후보를 판정하고, 키가 없으면 LLM을 계속 씁니다. judge_model로 다른 공급자 모델을 써도 주 실행 경로와 도구 권한은 바뀌지 않습니다. |
| 출력 계약 | judge는 작업 스키마를 물려받지 않고 passed, score와 observation / lesson / next_check를 반환합니다. 잘못된 JSON·점수, judge 호출 실패는 verification_error(passed=false, score=0, should_retry=false)로 기록하고 구조 검사 통과로 대신하지 않습니다. 이 0은 벤치마크 reward가 아니라 내부 검토 오류 값입니다. |
| 수정 루프 | Reflection은 도구 결과가 나온 매 라운드와 최종 응답 전에 실행합니다. 수정은 원래 마감 안에서 최대 두 번이며, 남은 시간이 3분의 1(최대 300초) 이하면 첫 후보를 검토에 올립니다. 개인정보(REDACT)·시간·비용 가드는 유지되고, 건너뛴 검토는 통과가 아닙니다. |
| 근거 범위 | 최근 관측 12개를 총 16,000자(필드당 최대 6,000자)로 전달하고 잘린 부분을 표시합니다. 재개한 요청은 이전 턴의 실제 호출·결과 쌍도 포함합니다. 이미지는 별도 창으로 보내고, 후보의 주장·압축 요약·내부 추론은 도구 증거로 쓰지 않습니다. |
| 후보 선택 | 성공한 후보끼리 상대 평가합니다. 선택이 실패하면 judge_error를 남기고 첫 성공 후보를 쓰는데, 이 대체는 검증 통과가 아닙니다. |
| 사용량 | judge와 reflection의 토큰·캐시·비용은 TokenTracker와 비용 가드에 한 번 기록하며, 모델이 도구를 거절하거나 잘못 응답해도 관측된 사용량은 남습니다. 공급자가 보고한 비용과 가격표 추정은 실제 청구액이 아닙니다. |
| confidence | CognitiveState의 confidence는 작업 진행에 대한 믿음이며 verifier 점수가 아닙니다. 마지막으로 갱신한 라운드를 함께 저장하고, NaN·무한대는 받지 않습니다. |
Jev는 생성 모델 선택 목록에 없습니다. 전용 System One API가 텍스트 상태와 유한한 선택지를 받아 분류와 분포를 돌려주고, 이 분포는 confidence나 실행 허가로 쓰이지 않습니다. 이미지가 필요한 근거는 텍스트만으로 통과시키지 않고, 실패한 호출은 다른 엔진의 결과로 메우지 않습니다. TypeSafe System One · OpenRouter System One · 설정 규약
알려진 한계
- judge는 후보의 주장보다 근거를 먼저 보고, 풀리지 않는 모호함에는 재검사를 요청하도록 설정돼 있습니다. 그렇다고 오판이 없어지지는 않습니다.
- Reflexion은 verdict와 continuation을 기록하지만, 다음 요청이 힌트를 실제로 소비했는지 묶는 digest·event는 아직 없습니다. 성능 개선 효과도 측정되지 않았습니다.
- 2026-09-13 G-code 개발 검증에서 최종 후보의 신규 5회는 모두 공식 verifier를 통과했지만, 내부 judge가 첫 후보를 모두 수락해 수정은 한 번도 일어나지 않았습니다. 앞선 후보의 오수락 사례와 함께 읽어야 합니다. G-code 개발 검증 기록 · 턴 검증 구현
Judge를 믿기 전에 확인할 것
- judge 모델·버전·경로, rubric 원본, 점수 방향, seed, transcript 범위를 고정합니다. 높은 점수가 좋은지는 차원마다 다릅니다.
- 같은 공급자의 모델을 역할만 나눠 쓰면 독립 평가가 아닙니다. 경고나 보정 계수가 있다고 편향이 사라지지도 않습니다.
- 사람이 judge 점수를 보기 전에 같은 rubric으로 라벨을 달고, 불일치 사례와 차원별 표본 수를 함께 봅니다.
- audit-agreement 경로로 blind labeling, weighted Cohen’s kappa, ordinal Krippendorff’s alpha를 계산할 수 있습니다. 도구가 있다는 것과 실제 라벨로 신뢰도를 보였다는 것은 다른 일입니다.
geode-eval audit-agreement --help
Jev v3 본실험
2026-09-27 본실험은 판정 정확도, 확률과 오류 선별, 호출 지연, 실제 과제 완료를 27개 등록 단위로 나눠 측정했습니다. 앞선 M4–M6 파일럿과는 분모를 합치지 않습니다. 자료는 geode-eval-artifacts PR #46으로 공개했고(2026-09-28 원격 재확인), 아래 링크는 공개 커밋 3bcf4044eb5c2411dd48122d672aef72a83fb30e에 고정돼 있습니다.
| 단위 | 대상 | 결과 | 차이 | 해석 |
|---|---|---|---|---|
| U4 | Score 통제 풀 | 59/80 · 79/80 | −25.00 pp [−35.23, −16.25] | 기준 미달 |
| X2 | Mind2Web 후보 선택 | 196/240 · 226/240 | −12.50 pp [−17.22, −8.04] | 비열등성 미입증 |
| 의도·대상 | 설계자가 만든 패널 | 216/220 · 220/220 | −5 pp 기준 안 | 기준 충족 |
| E7 | 같은 12과제, A/B/C × 2회 | 72/72 strict | C의 judge fallback 0회 | 재검토 분기의 효용은 미확인 |
| E8 | U8n 주입 후속 | 36셀 중 24셀에서 중단 | 주지표 not-measurable | 아래 사후 분석 참고 |
- U4·X2는 저장된 응답 전체에 수치 파서 교정을 적용한 사후 재채점입니다. 새 모델 호출은 없고 정답·분모·군집·seed·재표집 규칙은 그대로이며, 원래 등록 결과는 따로 보존합니다.
- E8: 원 계획(source5)의 U8n은 선행 gate 실패로 실행되지 않았습니다. 별도 후속(source7)은 U0e admission 2/2를 통과한 뒤 24셀에서 멈췄습니다(A 유효 성공 12, B 유효 전달 실패 11과 주입 증거 오류로 무효 1, 미실행 12).
- E8 사후 분석(양쪽이 유효한 11쌍, 4개 원천, 두 arm 모두 Astra가 생성·수리): Astra 판정(A)은 11/11을 전달했습니다. Jev Noul 판정(B)은 마지막 후보가 과제 oracle을 11/11 통과했는데도 근거 부족으로 모두 보류해 native strict가 0/11입니다. 맞는 수리 후보를 거부한 셈입니다. 중단 뒤 고른 표본이라 구간이나 일반화는 제시하지 않고, U8n을 더 돌릴 계획은 없습니다.
- Noul의 이전 의미 실패, I5의 계약 전달 결함, E6의 무효 중단도 공개 자료에 계보째 남아 있습니다.
- 한국어 결과 해석 · 영문 결과 해석
- 누가 무엇을 채점하는가 · 27개 단위와 계보별 근거
- 무결성 확인·오프라인 재계산·새 실행 · U4·X2 교정 재채점
- E8 U8n 사후 완성 쌍 분석
- 소스·공개 범위 기록 · 별도 M4–M6 파일럿
공개 자료는 투영본 해시와 원 native 해시를 따로 적고, 비공개 추론·인증 정보·머신 식별자·Mind2Web test 본문은 싣지 않았습니다. −10 pp 마진의 업무상 근거와 실제 청구액은 아직 확인되지 않았습니다.
.eval 파일
.eval은 Inspect의 평가 로그 형식이고, Petri는 Inspect 위에서 돌아서 이 형식을 씁니다. 파일이 있거나 상태가 success여도 모든 답이 맞았다는 뜻은 아니니 설정·샘플·메시지·점수를 함께 읽습니다. Harbor 결과 JSON, .eval, GEODE trajectory는 원본대로 두고 실행 ID와 SHA-256으로 잇습니다. 새 judge 라벨은 파생 평가로 따로 남깁니다. Inspect 로그 계약
Terminal-Bench 결과 읽기
이 사이트의 Sol/max 비교는 과제 verifier와 고정된 결과 선택 규칙으로 계산했으며, Petri judge 점수가 아닙니다. transcript에 LLM judge를 더하려면 별도의 질문·rubric·예산으로 등록하고, 기존 통과율과 섞지 않습니다.