에이전트 결과를 다른 LLM이 채점하게 하려 합니다. 코드 채점·모델 채점·사람 검토를 어떻게 조합하나요?

정확하게 프로그램으로 검사할 수 있는 결과는 코드 채점기를 우선 사용하고, 설명의 명확성·근거의 적절성처럼 해석이 필요한 부분에 모델 채점을 사용하겠습니다. 사람 검토는 기준을 정하고 자동 채점기를 보정하는 데 필요합니다. LLM-as-judge는 빠른 평가 도구이지만 객관적인 정답 판정기나 실행 증거의 대체물이 아닙니다.

평가 대상에 맞는 검사

파일 존재·테스트 통과·DB 행·중복 결제 부재는 실제 환경을 읽어 검사합니다. 출력 문자열에 '성공'이 있는지 검사하는 방식으로 대신하지 않습니다. 반면 문서의 핵심 주장과 근거 관계는 rubric을 나누어 모델이나 사람이 판단할 수 있습니다. 스키마 검사는 형식을, 환경 검사는 실행 결과를, 의미 평가는 내용의 적합성을 맡게 하겠습니다. 하나의 종합 점수로 이 차이를 숨기지 않습니다.

모델 채점에는 평가 기준·필요한 원문·허용되는 대안·불확실 상태를 제공합니다. 긴 답변을 선호하는 편향, 답의 위치나 작성 모델에 대한 편향, 그럴듯한 말투에 속는 문제를 표본으로 확인합니다. 비교 평가에서는 순서를 바꾸어 일관성을 보고, 블라인드 인간 평가와 불일치 사례를 분석합니다. 평가 대상의 텍스트가 채점 지침을 바꾸려는 인젝션도 고려해야 합니다.

채점기도 버전 관리합니다

모델·rubric·테스트 코드가 바뀌면 같은 산출물의 점수가 바뀔 수 있습니다. 고정된 앵커 사례와 정답·오답·애매한 사례를 유지하고 판정 일치도와 유형별 오탐·미탐을 측정합니다. 사람이 항상 완벽한 것도 아니므로 중대한 불일치는 기준을 명확히 하는 계기로 사용합니다. 채점 불능과 실제 실패를 구분하고 근거 없는 확정 점수를 강요하지 않습니다.

에이전트가 채점 기준을 읽고 그 수치만 최적화하면 실제 목표와 멀어질 수 있습니다. 인용 개수 대신 뒷받침, 테스트 개수 대신 동작 검증, 말의 길이 대신 필요한 설명을 평가합니다. 생성기가 테스트를 삭제하거나 숨겨진 정답에 접근할 수 없도록 권한을 분리합니다. 최종 배포 판단에서는 자동 점수와 함께 실제 안전 위반·비용·운영 실패를 봅니다. 좋은 채점 체계는 높은 점수를 만드는 장치가 아니라 어떤 종류의 성공과 실패를 측정했는지 설명할 수 있는 체계입니다.

실행 사례로 확인합니다

채점기의 오류가 알려진 작은 집합을 두면 모델 업데이트 뒤 기준이 흔들리는지 볼 수 있습니다. 예를 들어 근거 없는 긴 답, 짧지만 정확한 답, 올바른 거절, 실제로는 미완료인데 완료라고 말하는 답을 함께 넣습니다. 이때 정답 예시의 표현만 그대로 외우게 하지 않고 여러 유효한 결과를 허용합니다. 코드 채점도 잘못된 테스트라면 정확한 구현을 실패시킬 수 있으므로 과제의 기준 구현과 실패 반례로 검출력을 확인합니다. 모델 채점의 점수와 사람 판단이 다를 때 무조건 사람이나 모델 중 한쪽을 맞다고 정하지 않고 누락된 조건·모호한 rubric·실제 환경 증거를 대조하겠습니다.