AI가 AI를 채점하면 평가를 믿어도 될까: LLM 평가자와 평가셋을 검증하는 법

정답표부터 검토해야 할 때

LLM 평가자는 생성 결과에 대한 지시 준수, 설명의 명확성처럼 규칙만으로 판단하기 어려운 항목을 대량으로 볼 때 도움이 됩니다. 업무가 맞게 완료됐는지는 실제 시스템의 기록으로 검사할 수 있고, 지침이 모호할 때는 업무 전문가가 판정 기준부터 확정해야 합니다. 목표는 평가자를 통과시키는 답변을 만드는 데서 벗어나, 점수가 어떤 실패를 검출하는지 검증하는 것입니다.

답변을 검수하려면 당시 사용자의 조건에서 어떤 결과가 맞았는지 설명할 수 있어야 합니다. 약관, 업무 규정, API 계약, 결정 기록 같은 근거에 식별자나 버전을 붙이고 문서가 유효한 날짜와 예외 범위를 저장합니다. 정답표에는 한 문장으로 고정된 모범 답안 외에 필수 요소, 허용되는 표현이나 행동, 절대 포함하면 안 되는 주장, 자료 부족 시 기대하는 보류를 기록할 수 있습니다. 당시 정답과 현재 정답이 모두 필요하면 해당 날짜를 사례의 전제에 넣습니다.

가상의 교환 기준에서 회원 등급에 따라 예외가 달라지는 업무를 생각해 봅시다. 검수표는 모든 고객에게 신청일로부터 7일이라고 적었지만 승인된 특정 등급의 문서에는 품목 조건을 만족한 경우 14일이라는 절이 있습니다. 두 모델이 모두 일반 조항을 충실히 인용해 7일이라고 했고 평가자가 이를 통과시켰다면, 모델과 채점기는 잘못된 정답표에 합의했습니다. 먼저 업무 담당자가 적용 판본과 사례의 등급·품목을 확인하고 정답을 교정합니다. 잘못된 참조가 들어간 평가 결과의 영향 범위를 확인하고 정정된 동일 기준으로 기존 모델과 후보 모델을 다시 평가합니다.

근거가 상충하거나 담당자가 아직 예외를 정하지 않았다면 사례를 판정 불가로 남깁니다. 이때 시스템이 모른다고 답하고 상담원에게 넘기는 것이 이미 승인된 업무 요구라면 그 답변은 성공할 수 있습니다. 사례 자체의 정답을 아직 만들 수 없는 상태와, 제품이 모른다고 응답하는 행동에 대한 판정을 구분합니다. 이런 구분에 필요한 근거와 변경 연결은 요구사항–테스트 추적성에서 시작할 수 있습니다.

모델 평가자에게 맡길 일을 정합니다

평가 기준을 묶으면 표현이 좋은 답변의 업무 오류를 놓치기 쉽습니다. 환불을 실제로 실행하는 서비스라면 상담 문장의 품질과 별개로 승인 상태, 금액, 결제 원장의 변경 여부를 확인합니다. 데이터베이스나 테스트 도구로 확정할 수 있는 조건은 코드로 판정하고 표현의 자연스러움이나 설명의 충분성은 근거 문서에 따라 모델 평가자에게 맡길 수 있습니다. 안전성이 높은 업무에서는 한 가지 위반이 다른 점수로 상쇄되지 않도록 별도 실패 조건을 둘 수 있습니다. Anthropic의 실무 자료도 코드·모델·사람 채점기가 기록과 결과의 서로 다른 부분을 확인하며 모델 채점에는 사람을 통한 보정이 필요하다고 설명합니다. Anthropic 에이전트 평가^[1]

평가자 설정에 모델 식별자, 프롬프트 버전, 평가 기준 버전, 참고 자료의 판본, 모델 파라미터, 결과 파서 버전과 실행 시각을 기록합니다. 평가자의 출력은 검사 항목별 판정과 근거 구절을 담게 합니다. 평가 중에 참조 문서를 가져오는 구성이라면 원문 버전을 동결하고 어떤 부분이 입력으로 주어졌는지 함께 저장합니다. 호출 오류나 파싱 실패가 나면 평가자의 실패로 기록하며 재실행은 원래 실행과 연결합니다. 미리 정하지 않은 방식으로 성공한 실행만 골라 점수를 합치면 비교가 흔들립니다.

평가 대상 답변에 지시처럼 보이는 문자가 들어가도 채점 지시로 해석되지 않도록 답변 경계를 구조화하고 형식 위반과 답변 내용에 이끌린 오판을 시험합니다. 평가자가 볼 수 있는 도구와 자료를 줄여 예상치 못한 읽기·실행이 생기지 않게 합니다. 사람이 결과를 읽을 때는 평가자가 쓴 판정 사유와 실제 답변의 근거가 일치하는지 대조합니다. 승인된 기대 결과부터 확인하는 실무는 AI 생성 테스트 케이스 검수와 이어집니다.

응답 이름을 가리고 순서를 바꿉니다

비교 평가에서는 기존 답변과 후보 답변의 공급사명, 모델명과 생성 시각처럼 결과에 불필요한 정보를 평가자 화면에서 가립니다. 같은 업무의 두 답변과 같은 기준 문서를 사용해 처음에는 한 순서로, 이어서 반대 순서로 배치합니다. 실제 답변 식별자는 내부 기록에 유지해 어느 답변이 선택됐는지 다시 계산할 수 있게 합니다. 점수 합산에서 동률과 순서 불일치는 각각 남기는 편이 원인 파악에 도움이 됩니다. 2023년 Zheng 등의 원 논문은 MT-Bench 등의 조건에서 위치와 장황함의 영향을 시험하고 순서를 바꾸어 비교하는 방법을 제안했습니다. 자기 응답 양식을 선호하는 효과는 가능성을 논의했지만 해당 표본만으로 확정하지 않았습니다. Zheng 외의 원 연구^[2]

가상의 상담 답변 두 개가 승인된 예외를 모두 포함한다고 가정합니다. 한 답변은 한 단락이며 다른 답변은 같은 조건을 네 번 반복합니다. 길이가 다른 답변에서 점수 차이가 나면 길이와 실제 필수 요소를 각각 대조합니다. 다음에 같은 입력에서 짧은 답변과 긴 답변의 위치를 바꿔 결과가 항상 첫 번째로 바뀐다면 우열을 보류합니다. 두 차례 같은 응답을 선택했더라도 전문가가 실제 규정을 빠뜨렸다고 판정하면 그 이유를 확인합니다. 반복이나 순서 시험 자체는 채점 안정성의 근거로 쓰이고 맞는 답인지는 별도의 근거로 판단합니다.

표현 양식을 최대한 같게 하면 형식의 영향을 줄이는 시험을 구성할 수도 있습니다. 다만 답변을 다듬는 과정에서 내용까지 달라지면 어떤 차이 때문에 채점이 변했는지 알기 어려워집니다. 원본 응답으로 실제 비교를 하고 별도 편향 시험에서는 같은 사실을 유지한 변형에 ID를 부여합니다. 평가자가 만든 응답을 더 높게 채점한다는 의심이 들면 생성 출처 정보를 가리고 여러 출처의 답변을 균형 있게 넣으며, 업무 전문가에게도 같은 기준으로 평가하도록 합니다.

평가 체계 감사표

아래 표는 품질 보고서를 승인하기 전에 평가 체계 소유자가 제출할 증거의 예시입니다. 특정 모델의 총점과 함께 표본 수, 평가자 판정 불가, 위험한 실패를 잘못 통과시킨 사례를 같은 자료에서 살펴봅니다.

가상의 보정 표본 100건 중 전문가가 20건을 품질 실패로 판정했다고 가정합니다. 모델 평가자는 그중 15건에 실패를 표시하고 5건을 통과시켰습니다. 전문가가 통과시킨 나머지 80건 중 78건을 맞게 통과시키고 2건을 실패로 봤습니다. 총 일치는 93건으로 93%입니다. 그런데 전문가가 실패라고 한 20건 중 5건을 놓쳤으므로, 이 표본에서 실패를 통과로 판단한 비율은 25%입니다. 오류 유형별 분모와 실제 영향이 중요합니다. 이 5건에 승인되지 않은 지급이나 잘못된 권한이 하나라도 포함된다면 전체 일치율이 좋아도 그 분야의 최종 승인은 보류합니다.

사람의 판정도 의견이 갈릴 수 있습니다. 업무 전문가 두 명이 같은 질문을 독립적으로 보고 먼저 본인의 판정과 근거를 남기게 합니다. 불일치가 있으면 기준 문장이나 기대 결과를 조정할 책임자가 결론과 차이를 같이 기록합니다. 자동 평가가 어려운 유형은 계속 사람에게 보내는 비용을 계획에 반영합니다. 여러 평가 모델이 모두 같은 오류를 낼 수 있으므로 다수결과 사람의 대조 검사를 분리합니다. 공통 학습 자료, 판정 기준의 모호함, 잘못된 참조가 남아 있으면 모델 수를 늘려도 원인 자체는 남습니다.

판정 불일치 분석 양식

보류 사례의 분석 단위는 평균 점수가 아니라 사례 ID와 구체적인 관측 기록입니다. 아래 형식을 사용하면 채점기의 오류를 고칠지, 평가셋을 정정할지, 제품을 고칠지 결정한 뒤 영향을 받은 결과를 찾을 수 있습니다.

개발·최종평가·회귀 자료의 쓰임을 다르게 둡니다

개발에 쓰는 평가 사례는 프롬프트와 검색 설정을 바꾸는 데 도움을 줍니다. 결과와 기대 답안을 여러 번 봐도 되는 대신 점수를 새로운 업무의 성능 추정치로 읽기 어렵습니다. 최종평가 자료는 출시 결정 시 볼 별도 사례를 가리고 보존하는 데 씁니다. 제품팀이 결과를 보고 즉시 조정하는 일이 반복되면 해당 묶음을 개발 자료로 표시하고 최종평가 표본을 새로 확보합니다. 회귀 자료는 이미 막았던 구체적인 결함이 되살아나는지를 확인합니다. 개발팀이 문제와 기대 결과를 알고 있어도 목적이 분명하고 반복 실행할 수 있으면 쓸 수 있습니다. Google 책임 있는 AI 평가 안내^[3]와 Anthropic 에이전트 평가 방법^[1]은 개발 중 시험, 독립 검증, 회귀 평가에 서로 다른 역할을 둡니다.

겉으로는 요청 문장이 달라도 같은 지원 티켓을 요약한 입력이 개발과 최종평가에 동시에 들어갈 수 있습니다. 데이터의 출처, 고객·문서·시나리오 그룹을 기준으로 분리하고 정규화한 텍스트나 해시로 정확히 같은 입력을 찾습니다. 표현만 바꾼 사례는 유사도 검토나 표본 확인으로 점검할 수도 있습니다. 합성한 사례도 어떤 원본을 참고했는지 기록합니다. 일부 공개 벤치마크 연구는 학습 자료와 시험 문항이 겹쳤을 가능성을 조사하는 방법을 제시했습니다. 모델 제공자의 전체 훈련 자료를 볼 수 없는 상태에서는 점검한 경로와 그 한계를 함께 기록하고 사내 업무가 반영된 독립 표본을 평가에 추가합니다. Deng 외의 벤치마크 오염 조사^[4], NIST 생성형 AI 프로파일^[5]

새 모델의 점수가 눈에 띄게 오르면 먼저 두 결과에 같은 평가자와 같은 근거가 쓰였는지 확인합니다. 평가자나 정답표가 바뀌었다면 고정된 두 답변 묶음을 이전·현재 채점기로 다시 비교해 측정 변화와 사례의 실제 개선을 추적합니다. 평가셋의 노출이나 중복이 확인되면 영향받은 결과를 정정하고 교체 표본을 사용합니다. 출시 회의에는 어떤 유형의 성능 개선을 확인했고, 어떤 유형은 아직 사람이 판단해야 하는지를 표본과 함께 올립니다.