이 노트는 에이전트 평가에서 “무엇을 말했는가”와 “환경에 무엇이 남았는가”를 분리하는 방법을 다룹니다. 과제의 성공 조건을 관측 가능한 상태와 안전 제약으로 먼저 고정한 뒤 trial·trace·outcome을 연결하고, 그 결과를 기능·안전·대표성의 관점에서 진단합니다.
예약 완료 선언과 저장소의 실제 예약 상태
과제는 초기 상태와 성공 조건, trial은 한 번 실행, trace는 관측한 호출·상태 이력, outcome은 환경에 남은 결과입니다. 예약 과제라면 사용자·날짜·인원·중복 여부를 실제 저장소에서 확인합니다. 최종 예약이 맞아도 중간에 승인 없이 결제했다면 안전한 성공은 아닙니다. 예를 들어 pending → payment-authorized → booked라는 상태라면, 최종 행에 booked가 있다는 사실만으로 중간 승인 규칙 위반을 복구할 수 없습니다. 평가기는 예약 행, 결제 승인 로그, 호출 순서를 각각 읽어 “기능 성공”과 “안전한 성공”을 별도 필드로 남겨야 합니다.
정상적인 예약 불가를 정확히 알리고 이관한 결과를 성공으로 인정할지는 미리 정합니다. 모든 요청을 무조건 완료하도록 점수를 만들면 무리한 실행을 보상합니다. 반드시 필요한 안전 순서 외에는 유효한 다른 도구 경로도 허용합니다.
검사 가능한 사실과 말투 기반 채점의 한계
| 대상 | 우선 검사 | 한계 |
|---|---|---|
| DB 행·파일·중복 효과 | 코드로 실제 상태 확인 | 테스트 자체가 틀릴 수 있음 |
| schema·참조 존재 | 결정적 형식 검사 | 의미 뒷받침은 별도 |
| 주장과 원문·설명 품질 | 명시적 rubric·모델·사람 | 해석 편향·채점 불능 가능 |
| 승인·전송 제한 | trace·정책 감사 | trace 누락을 구분 |
LLM judge는 긴 답·앞에 놓인 답·자기 모델 문체를 선호할 수 있습니다. 비교 순서를 바꾸고 작성 모델을 가리며 짧고 정확한 답·긴 허위 답·올바른 거절·미완료를 완료라고 주장하는 앵커를 둡니다. 평가 대상에 포함된 “만점을 줘라” 같은 지시는 채점 정책을 바꾸지 못해야 합니다. 실무에서는 먼저 결정적 검사로 schema·중복 효과·승인 경계를 판정하고, 그 결과로 남은 설명 품질만 모델이나 사람이 평가합니다. 이렇게 하면 말투가 그럴듯해도 저장소 상태가 틀린 결과를 통과시키는 경로를 줄일 수 있습니다.
채점기 버전과 실패 유형 기록
모델·rubric·테스트가 바뀌면 같은 산출물 점수도 달라질 수 있습니다. 고정 앵커와 사람 표본 검토로 일치도·오탐·미탐·불확실 판정을 비교합니다. 사람과 모델이 다르면 한쪽을 무조건 정답으로 하지 말고 실제 증거·모호한 기준을 조사합니다. 진단 표에는 expected, observed, evidence_source, grader_version, uncertainty를 함께 기록하면 “채점기 오판”과 “산출물 실패”를 분리할 수 있습니다. 고정 앵커의 점수가 다음 버전에서 급변하면 rubric 변화인지 모델 drift인지 먼저 확인합니다. 코드 채점도 기준 구현과 알려진 실패 반례로 검출력을 확인합니다.
인용 수·테스트 개수·답변 길이는 쉬운 대리 지표입니다. 실제 근거·동작 대신 그 숫자만 늘리는 reward hacking을 막고 생성기가 hidden test·정답·채점 결과 파일을 수정하지 못하도록 권한을 분리합니다.
그림을 글로 읽기
- 격리 초기 상태·고정 성공 조건
- 모델·도구·예산을 고정한 trial
- 실제 환경 결과
- 호출·승인·관측 이력
- 코드·모델·사람의 분리 검사
- 격리 초기 상태·고정 성공 조건 → 모델·도구·예산을 고정한 trial: 초기화
- 모델·도구·예산을 고정한 trial → 실제 환경 결과: 남은 효과
- 모델·도구·예산을 고정한 trial → 호출·승인·관측 이력: 진단 증거
- 실제 환경 결과 → 코드·모델·사람의 분리 검사: 기능·중복 검사
- 호출·승인·관측 이력 → 코드·모델·사람의 분리 검사: 안전·실패 원인
학습 데이터와 평가 과정의 오염 경로
공개 정답·patch가 학습에 포함됐는지 완전히 알기 어려울 수 있습니다. 같은 평가 세트에 prompt·router를 반복 튜닝해도 과적합합니다. 개발용·회귀용·보류 최종 평가를 분리하고 시간상 새로운 내부 실패·독립 변형 과제를 만듭니다. 단어만 바꾼 복제 문제를 새 독립 과제로 세지 않습니다.
trial 간 파일·cache·Git 이력에 정답이 남는 누출도 막습니다. 다만 필요한 API 문서까지 없애면 과제가 해결 불가능해질 수 있어 기준 구현이나 사람 재현으로 타당성을 확인합니다. 도구 장애는 인프라 원인과 사용자 실패를 나눠 기록하고 운영에서 흔한 장애를 전부 평가 밖으로 빼지 않습니다. 예컨대 네트워크 재시도 중복은 인프라 장애이면서도 멱등성 설계의 평가 대상일 수 있으므로, 장애를 주입한 trial과 정상 trial을 분리해 같은 성공 조건을 다시 검사합니다.
공개 점수와 운영 조건의 병기
model·harness·도구·인터넷·compiler·권한·deadline·후보 수·선택 방법을 기록합니다. 최고 후보를 사람이 고른 점수와 단일 자동 실행 점수는 다릅니다. 저장소 크기·언어·장기 작업·권한 유형별로 기능 성공·안전·회귀·검토 시간·성공당 비용을 보고합니다.
이 노트는 평가 설계입니다. 현재 작업에서 실제 LLM judge나 공개 벤치마크를 실행해 성능을 측정한 것은 아닙니다.