레슨 4: LLM 판정자: 루브릭, 출력 형식, 그리고 판정을 맡기면 안 되는 것

학습 목표:

• 자유 형식 텍스트 출력을 위한 다차원 루브릭을 쓰고, 각 차원의 질문을 명확하게 만들며, 하나의 성공 기준에도 여러 개의 루브릭이 필요한 경우가 많다는 점 이해하기
• 판정자의 출력을 프로그램이 다룰 수 있는 형태로 조이기 — 근거 먼저 점수 나중, 0.0–1.0과 통과/실패, 그리고 여러 판정자가 측면을 나눠 평가하는 것보다 단일 호출이 더 안정적인 경우가 많은 이유 설명하기
• 판정자의 세 가지 실패 양상 — 자기 작업을 채점하는 것, 문제를 찾으라고 시켜서 언제나 찾아내는 것, 에이전트의 자기 보고만 믿는 것 — 을 알아보고 각각에 대해 실행 가능한 완화책 제시하기

전제: 레슨 1–3, '종료 상태 우선' 평가와 결정론적 검증기를 앞세우는 원칙에 대한 이해 | 이전: << 레슨 3 | 다음: 레슨 5 >>

레슨 3이 한계에 부딪히는 지점, 그리고 LLM 판정자가 들어갈 자리

리서치 에이전트에게 과제를 하나 맡겼습니다. 지난 3년간 국내 전기차 충전 보조금이 어떻게 바뀌었는지 정리해서 2페이지짜리 브리프를 만들라는 과제입니다. 15분 동안 돌면서 검색 도구를 호출하고 PDF를 받아오더니 1,800단어를 썼습니다. 읽어 보면 그럴듯합니다.

이제 이것을 검증해야 합니다. 레슨 3의 결정론적 체크는 여기서 하나도 쓸 수 없습니다. 돌릴 테스트 스위트도 없고, 읽을 빌드 종료 코드도 없고, output == golden_answer를 위한 golden_answer도 쓸 수가 없습니다. 같은 브리프를 사람 애널리스트 두 명에게 맡겨도 똑같은 텍스트가 나오지는 않기 때문입니다.

이것은 상상력이 부족해서가 아닙니다. 이런 종류의 출력은 원래 이렇게 생겼습니다. Anthropic이 자사 멀티 에이전트 리서치 시스템을 돌아보면서 한 말은 직설적이었습니다. 리서치 결과물은 자유 형식 텍스트이고 정답이 하나로 정해지는 경우가 드물어서 프로그램으로 평가하기 어렵다, 이런 출력을 채점하는 데는 LLM이 자연스럽게 들어맞는다¹.

다만 브리프를 다른 모델에 툭 던져 놓고 '이거 어때?'라고 묻기 전에, LLM 판정자가 공식 순위에서 어디에 놓여 있는지부터 알아 두어야 합니다. 채점 방법을 고르는 원칙은 "fastest, most reliable, most scalable"(가장 빠르고, 가장 신뢰할 수 있고, 가장 잘 확장되는)입니다². 코드 기반 채점은 가장 빠르고 가장 신뢰할 수 있으며 확장성도 대단히 좋지만, 규칙 기반의 경직성을 덜어내야 하는 복잡한 판단에서는 뉘앙스가 부족합니다². LLM 기반 채점은 빠르고 유연하고 확장 가능하며 복잡한 판단에도 맞습니다. 그리고 공식 가이던스는 같은 문장 안에 전제 조건을 붙여 둡니다. 먼저 신뢰할 수 있는지 테스트하고, 그다음에 확장하라². 사람이 하는 채점은 가장 유연하고 품질도 높지만 느리고 비싸서, 가능하면 피하라고 되어 있습니다².

가운데 선택지에 붙은 그 전제 조건은 면책 문구가 아니라 강제 요건으로 취급하십시오. LLM 판정자는 '더 똑똑한 체크'가 아니라 모델 호출입니다. 틀릴 수 있고, 돈이 들고, 같은 입력에 대해 실행할 때마다 다른 점수를 줄 수도 있습니다. 그 가치는 단 하나입니다. 결정론적 체크가 닿지 못하는 곳에 닿는다는 것입니다.

그래서 이 레슨은 '모델에게 출력을 점수 매기게 하는 법'에 관한 것이 아닙니다. 그건 쉽습니다. 아무 프롬프트나 던져도 숫자는 나옵니다. 이 레슨은 그 숫자를 믿을 만한 것으로 만드는 법에 관한 것입니다. 루브릭을 어떻게 구성하고, 출력을 어떻게 제약하고, 누가 판정자를 돌리고, 어떻게 망가지고, 언제는 아예 묻지 말아야 하는지입니다.

루브릭: '좋다'를 따로 답할 수 있는 질문들로 쪼개기

루브릭이라고 하면 거창하게 들립니다. 쉽게 말하면 채점표입니다. 막연한 '이거 괜찮은가'를 구체적인 질문들로 쪼개고, 각각을 따로 답하고, 각각을 따로 점수 매기는 것입니다.

왜 쪼갤까요. '이 브리프 괜찮아?'라고 물으면 모델은 막연한 칭찬이나 막연한 지적을 내놓습니다. '브리프의 모든 주장이 인용된 출처 안에 실제로 나오는가'라고 물으면 모델은 주장을 하나씩 확인할 수 있습니다. 대부분의 활용 사례는 여러 성공 기준에 걸친 다차원 평가를 필요로 합니다².

Anthropic의 리서치 에이전트는 다섯 개 차원의 루브릭을 썼고¹, 각 차원 뒤에는 실제 실패 양상이 하나씩 있습니다.

• 사실 정확도 — 주장이 출처와 일치하는가? 모델이 '2023년에 보조금이 30% 줄었다'고 하면, 인용된 문서에 정말 그 숫자가 있습니까? 이 차원이 환각을 잡습니다.
• 인용 정확도 — 인용된 출처가 주장과 맞는가? 앞 차원과 방향이 반대인데, 이 둘을 뭉뚱그리는 사람이 많습니다. 앞의 것은 '이 문장에 근거가 있는가'를 묻고, 이것은 '이 문장에 달린 링크가 정말 이 주제를 다루는가'를 묻습니다. 에이전트가 자주 저지르는 실패가 있습니다. 주장 자체는 멀쩡한데, 제목만 관련 있어 보이는 출처가 태그로 붙어 있는 경우입니다.
• 완전성 — 요구된 측면이 전부 다뤄졌는가? '지난 3년'이라고 했는데 작년 얘기만 썼거나, '변화'라고 했는데 현재 상태만 썼거나. 요구 사항을 하나씩 확인하는 것이지, 문장이 얼마나 예쁜지를 평가하는 것이 아닙니다.
• 출처 품질 — 1차 자료인가, 질 낮은 2차 자료인가? 이 차원이 가장 교묘한 문제를 잡습니다. Anthropic의 사람 테스터들이 발견한 것은 이렇습니다. 초기 에이전트들은 학술 PDF나 개인 블로그처럼 권위는 있지만 검색 순위가 낮은 출처 대신, SEO에 최적화된 콘텐츠 팜을 일관되게 골랐습니다¹. 출력은 완전히 정상으로 읽히는데, 토대가 썩어 있는 것입니다.
• 도구 효율 — 맞는 도구를, 납득할 만한 호출 횟수로 썼는가? 같은 답을 검색 3회로 얻느냐 30회로 얻느냐는 비용이 자릿수 단위로 다릅니다. 이 차원은 과정의 경제성을 평가하는 것이지 '내가 지정한 단계를 따랐는가'를 평가하는 것이 아닙니다. 후자가 왜 안 되는지는 레슨 2에서 설명했습니다.

이 다섯 차원은 리서치 과제용입니다. 과제가 다르면 필요한 차원 집합도 달라집니다. 여기서 가져갈 것은 쪼개는 방법입니다. '이 출력이 망가진다면 어떤 식으로 망가지는가'에서 출발해 거기서 차원을 끌어내고, 실패 양상 하나에 차원 하나를 두는 것입니다. 하나 더 놓치지 마십시오. 특정 활용 사례, 심지어 그 사례의 특정 성공 기준 하나만 두고도, 전체를 보려면 여러 개의 루브릭이 필요할 수 있습니다². 채점표 하나가 전부를 덮어 주기를 기대하지 마십시오.

출력 형식: 한 번의 호출, 하나의 점수, 하나의 통과/실패

먼저 판정의 형태입니다. Anthropic은 여러 판정자가 서로 다른 구성 요소를 평가하는 방식, 즉 구성 요소마다 판정자를 하나씩 두는 방식을 시도해 봤습니다. 결과는 이랬습니다. 단일 프롬프트로 0.0-1.0 점수와 통과/실패 등급을 내놓는 단일 LLM 호출이 가장 일관되고 사람의 판단과도 가장 잘 맞았습니다¹.

공정하게 덧붙이면, 평가를 여러 번의 LLM 호출로 쪼개고 호출마다 한 측면씩 평가하는 것 자체는 공식 가이던스가 이미 설명한 평가 자동화 패턴입니다³. 어느 쪽도 틀리지 않았습니다. 차이는 '단일 호출이 더 낫다'가 Anthropic이 자기네 실제 시스템에서 비교해 얻은 결과라는 데 있습니다¹. 권장하는 접근은 이렇습니다. 단일 호출로 시작하고, 쪼개는 편이 정확도를 높인다는 증거가 있을 때만 쪼개십시오.

다음은 출력을 얼마나 세게 조일 것인가입니다. 판정자 프롬프트에 대한 공식 가이던스는 "empirical or specific"(경험적이거나 구체적일 것)입니다. 예를 들어 LLM에게 'correct' 또는 'incorrect'만 출력하게 하거나, 1–5 척도로 판정하게 하십시오. 순수하게 정성적인 평가는 빠르게, 그리고 대규모로 다루기 어렵습니다². 쉽게 말해, 판정자가 '전반적인 품질은 수용 가능하나 일부 세부 처리가 다소 거칠다'라고 돌려주면 당신 손에는 아무것도 남지 않습니다. 그런 응답 200개를 평균 낼 수도 없고, 오늘이 어제보다 나은지도 알 수 없고, 결국 하나씩 다 읽어야 합니다. 그러면 판정자에게 물어본 이유가 무엇입니까.

결정적인 기법은 근거를 먼저 쓰고 점수를 나중에 매긴 뒤, 그 근거는 버리는 것입니다. 공식 가이던스가 명시적으로 말합니다. LLM에게 평가 점수를 내기 전에 먼저 추론하게 하고, 그 추론은 버리십시오. 이것은 평가 성능을 높이며 특히 복잡한 판단이 필요한 과제에서 효과가 큽니다². '버린다'는 말은 보지 말라는 뜻이 아닙니다. 그 추론은 판정자를 받쳐 주는 비계입니다. '3문단의 주장이 트랜스크립트의 어느 구간에 대응하는지'를 써 봐야 정확하게 판정할 수 있습니다. 다만 그 텍스트가 당신의 하류 통계로 들어가서는 안 됩니다. 리포트에는 점수와 통과/실패가 들어가고, 추론은 로그로 가서 점수가 미심쩍을 때 당신을 기다립니다.

주관적인 차원은 어떻게 할까요? '이 브리프의 톤이 고객에게 보내기에 적절한가' 같은 차원은 이분법으로 만들 수 없습니다. 공식 가이던스는 도구를 하나 제공합니다. LLM 기반 리커트 척도는 주관적인 태도나 인식을 LLM으로 판정하는 방식입니다². 리커트 척도란 '전혀 그렇지 않다 / 그렇지 않다 / 보통이다 / 그렇다 / 매우 그렇다'처럼 눈금이 고정된 설문 형식을 말합니다(눈금을 몇 개로 할지는 설문 설계의 관행이지 공식이 정한 것이 아닙니다). 핵심 원칙은 그대로입니다. 고정된 눈금을 주고, 자유 서술을 허용하지 마십시오.

정리하면 판정자의 출력은 대략 이런 모양입니다(예시는 앞의 세 차원만 보여 줍니다. source_quality와 tool_efficiency도 모양이 같아 지면상 생략했습니다). 프로그램은 score와 verdict를 읽고, reasoning은 검토를 위해 보관합니다.

일한 쪽이 판정자가 될 수는 없다

여기까지 오면 솔깃한 지름길이 하나 보입니다. 에이전트에게 마지막에 스스로 채점하게 하는 것입니다. 자기가 방금 무엇을 했는지는 자기가 제일 잘 아니까요.

그 유혹을 누르십시오. 이유는 두 가지입니다. 첫째, 공식 경험입니다. 한 모델 인스턴스는 사용자 질의를 처리하고 다른 인스턴스는 부적절한 내용이나 요청을 걸러 내는 식으로 가드레일을 구현하면, 같은 LLM 호출이 가드레일과 본 응답을 함께 처리하게 하는 것보다 대체로 더 잘 동작합니다³. 이 경험은 원래 콘텐츠 검열을 설명한 것이지만(한 인스턴스가 응답하고 다른 인스턴스가 거른다), '같은 호출에 두 모자를 씌우지 말라'는 원칙은 여기에도 그대로 적용됩니다. '같은 호출'이라고 되어 있다는 점에 주목하십시오. 문제는 공유된 컨텍스트이지 지능 부족이 아닙니다. 둘째, 메커니즘입니다. Claude Code 공식 문서는 이런 관행을 설명합니다. 새 서브에이전트 컨텍스트에서 돌아가는 리뷰어는 diff와 당신이 준 기준만 볼 뿐 그 변경을 만들어 낸 추론은 보지 못하며, 그래서 결과 자체를 놓고 평가합니다⁴.

이것을 거꾸로 읽으면 자기 채점이 왜 실패하는지가 보입니다. 그 출력을 만들어 낸 추론의 사슬이 아직 컨텍스트에 걸려 있습니다. 모델은 방금 '이렇게 쓰는 게 맞다'고 스스로를 설득했는데, 곧바로 '이게 맞아?'라고 물으면 같은 논리를 되풀이할 가능성이 높습니다. 당신이 받는 것은 독립적인 판단이 아니라 자기 복창입니다.

판정자가 너무 무르거나 너무 빡빡한 것이 걱정된다면, 공식 가이던스가 조절 손잡이를 하나 제공합니다. 어떤 콘텐츠가 부적절한지 평가할 때 여러 프롬프트로 서로 다른 측면을 평가하게 하거나 투표 임계값을 다르게 요구해서 거짓 양성과 거짓 음성의 균형을 맞추는 것입니다³. 검증 시나리오에서 거짓 양성은 '멀쩡한 것을 망가졌다고 표시하는 것'이라 거짓 경보에 시달리게 되고, 거짓 음성은 '망가진 것을 통과시키는 것'이라 불량품이 나갑니다. 판정자 셋 중 둘이 fail이라고 해야 fail로 치는 설정은, 판정자 하나가 fail이라고 하면 fail인 설정보다 무릅니다. 어느 쪽을 고를지는 당신 시나리오에서 어느 종류의 에러가 더 비싼가에 달려 있습니다.

판정자는 어떻게 망가지는가

인스턴스를 따로 띄웠고 루브릭도 썼는데, 판정자는 여전히 망가집니다. 망가지는 방식은 예측 가능합니다.

하나: 문제를 찾으라고 시킨 리뷰어는 언제나 문제를 찾아냅니다. 가장 직관에 어긋나고 가장 비쌉니다. 공식 문서는 분명히 말합니다. 빈틈을 찾으라고 지시받은 리뷰어는 작업이 멀쩡할 때도 대개 뭔가를 보고하는데, 그것이 자기가 지시받은 일이기 때문입니다⁴. 결과는 '쓸모없는 제안 몇 개'로 끝나지 않습니다. 같은 대목이 짚습니다. 모든 지적을 쫓아다니면 과잉 설계로 이어집니다. 추상화 계층이 늘고, 방어 코드가 붙고, 일어날 수 없는 경우를 위한 테스트가 생깁니다⁴. 당신의 에이전트는 자가 증식 루프에 들어갑니다. 리뷰어가 세 가지를 제안하고, 당신이 고치고, 다시 리뷰하면 세 가지가 또 나오고, 코드는 두꺼워지고, 진짜 문제는 그대로 남습니다.

이런 리포트를 본 적이 있을 것입니다. 'parseDate에 빈 문자열 방어를 추가하라' — 그런데 상류에서 이미 비어 있지 않음을 보장합니다. '이 상수 세 개를 설정으로 빼라' — 그런데 3년째 바뀐 적이 없습니다. '네트워크 타임아웃 재시도 테스트를 추가하라' — 그런데 이 경로에는 네트워크 호출이 없습니다. 셋 다 틀린 말은 아니고, 셋 다 할 가치는 없는데, 리뷰 리포트에 섞여 들어가면 진짜 문제와 똑같아 보입니다.

공식 가이던스가 완화책을 제공합니다. 리뷰어에게 정확성이나 명시된 요구 사항에 영향을 주는 빈틈만 표시하게 하고 나머지는 선택 사항으로 취급하게 하십시오⁴. 이 문장을 판정자 프롬프트에 그대로 쓰고, '그 밖의 제안'이 갈 자리를 만들어 주십시오. optional_notes 필드를 하나 두고 채점에 참여하지 않는다고 명시하는 것입니다. 쓸 자리가 있으면 스타일 취향을 감점 사유에 욱여넣을 이유가 없어집니다.

둘: 에이전트의 자기 보고는 증거가 아닙니다. 많은 사람이 지름길을 택해 에이전트의 최종 요약만 판정자에게 넘깁니다. '권위 있는 출처 세 곳을 확보해 교차 검증한 뒤 보조금 비율을 확정했습니다.' 판정자가 읽고 과정이 탄탄해 보인다고 판단해 높은 점수를 줍니다. 그러나 이 진술은 증거가 아닙니다. 도구 평가에 관한 공식 가이던스가 짚는 지점입니다. 에이전트가 피드백과 응답에서 빠뜨린 것이 넣은 것보다 더 중요할 때가 많습니다. LLM이 늘 자기가 의도한 대로 말하지는 않습니다⁵. '세 출처를 교차 검증했다'고 말하지만 검색은 한 번만 호출했을 수도 있습니다. 언급하지 않은 실패한 재시도, 빈 결과를 받고도 계속 지어내던 순간, 그것이 당신이 가장 봐야 할 것입니다. 해법도 직설적입니다. 원본 트랜스크립트(도구 호출과 도구 응답 포함)를 검토해서 에이전트의 사고 사슬에 명시적으로 기술되지 않은 행동을 잡아내십시오⁵. 해법으로 옮기면 이렇습니다. 판정자의 입력에는 자기 보고뿐 아니라 원본 로그가 반드시 들어가야 합니다. 특히 '도구 효율' 차원이 그렇습니다. 실제 호출 횟수와 호출이 옳았는지를 평가하는데, 그 정보는 로그에만 있습니다.

셋: 질문 자체가 모호한 경우입니다. 엄밀히 말하면 판정자가 망가진 것이 아니라 당신이 망가진 질문을 준 것입니다. 평가 설계에 관한 공식 가이던스는 피해야 할 범주를 하나 지목합니다. 사람끼리도 평가 합의에 이르기 어려운 모호한 테스트 케이스입니다². 판정자를 검증할 때 이런 것이 눈에 들어옵니다. 당신과 동료가 같은 출력을 판정했는데 결론이 반대로 나오는 것입니다. 판정자 프롬프트를 서둘러 고치지 마십시오. 판정자가 '부정확한' 이유는 이 질문에 정확한 답이 없기 때문입니다. 사람이 합의할 수 있을 때까지 기준을 다듬든지, 아니면 이 케이스를 빼십시오. 이걸로 판정자의 일치율을 계산해 봐야 자기기만적인 숫자만 나옵니다.

검토-수정 루프를 언제 만들 것인가

판정자가 끝나면 거기서 끝인가, 아니면 그 피드백을 에이전트에게 먹여 다시 쓰게 하고 또 판정할 것인가. 이 루프는 솔깃하고, 토큰을 태우는 영구 기관이 되기도 쉽습니다.

공식 가이던스는 이 워크플로가 정말 맞는 경우를 알려 주는 신호 두 개를 제시합니다³. 첫째, 사람이 피드백을 언어로 표현했을 때 LLM의 응답이 눈에 띄게 개선된다는 것. 둘째, LLM이 그런 피드백을 스스로 제공할 수 있다는 것. 같은 대목은 전제 하나를 덧붙입니다. 이 워크플로는 평가 기준이 명확하고 반복적인 다듬기가 측정 가능한 가치를 줄 때 특히 효과적입니다³.

이 두 조건을 입장 시험으로 쓰십시오. 방법은 간단합니다. 먼저 당신이 판정자가 되어 에이전트에게 피드백을 써 주고, 수정 후에 실제로 나아지는지 보십시오. 사람이 쓴 피드백으로도 움직이지 않는다면, LLM이 쓴 피드백으로는 더 움직이지 않습니다. 그 시점에 고칠 것은 프롬프트나 도구이지 검토 계층을 하나 더 얹는 것이 아닙니다. 반대로 사람 피드백이 확실히 먹힌다면 두 번째 조건을 확인하십시오. LLM에게 루브릭에 비추어 피드백을 쓰게 하고 당신 것과 비교하는 것입니다. 둘 다 통과하면 그 루프는 만들 가치가 있습니다.

비례성: 판정자도 모델 호출이다

레슨 3의 순위로 돌아갑시다. 채점 방법을 고르는 원칙은 가장 빠르고, 가장 신뢰할 수 있고, 가장 잘 확장되는 것입니다². 코드 기반 채점은 이 셋 모두에서 LLM 기반 채점보다 앞섭니다². 그러니 판정자는 결정론적 체크가 닿지 못하는 곳으로 가는 것이지 그 대체재가 아닙니다. 같은 브리프에 대한 올바른 계층화는 이런 모양입니다.

1계층 (결정론적, 밀리초, 비용 0)  유효한 JSON / Markdown인가? 길이가 요구 범위 안인가?  인용 링크가 살아 있는가 (HTTP 상태)? 인용 개수 >= 3인가?  하나라도 실패 → 즉시 fail, 판정자 부르지 않음
2계층 (LLM 판정자, 초 단위, 토큰 과금)  다섯 차원 루브릭 점수 + 통과/실패  입력: 과제 요구 사항 + 출력 + 원본 로그(도구 호출과 응답)
3계층 (사람, 느리고 비쌈, 표본 점검만)  판정자는 fail이라 했는데 미심쩍을 때  판정자가 pass라 한 것 중 무작위 표본 — 체계적인 관대함을 막기 위해

1계층이 잡을 것을 2계층으로 보내 돈을 내지 마십시오. 형식조차 유효하지 않은 출력은 모델 호출로 확인해 줄 필요가 없습니다. 3계층은 건너뛸 수 없습니다. 에이전트를 테스트하는 사람은 평가가 놓치는 엣지 케이스를 찾아냅니다¹. 앞서 나온 '콘텐츠 팜을 일관되게 선호하는' 편향도 사람 테스트가 잡아낸 것입니다¹.

이 레슨의 경계: 평가 세트(eval set)를 어떻게 구성하고 이 판정자를 몇 개의 케이스에 돌릴 것인지는 레슨 5입니다. 판정자를 반복 실행 가능한 평가 하네스에 연결해 리포트를 뽑는 것은 레슨 6입니다. 이 레슨은 한 번의 판정을 믿을 만하게 만드는 문제만 다룹니다.

💻 연습

정리

• 자유 형식 텍스트 출력은 정답이 하나로 정해지지 않아 프로그램으로 평가하기 어렵고, 이런 출력을 채점하는 데는 LLM이 자연스럽게 들어맞는다¹. 다만 LLM 기반 채점에 대한 공식의 자리매김은 '빠르고 유연하고 확장 가능하며 복잡한 판단에 적합 — 전제는 먼저 신뢰할 수 있는지 테스트하고 그다음 확장'이다. 사람 채점은 가장 유연하고 품질도 높지만 느리고 비싸서 가능하면 피한다².
• 루브릭은 '좋다'를 따로 답할 수 있는 질문들로 쪼갠다. 리서치 과제를 위한 기성 분해는 다섯 차원이다. 사실 정확도, 인용 정확도, 완전성, 출처 품질, 도구 효율¹. 특정 활용 사례, 심지어 그 안의 성공 기준 하나에도 전체를 보려면 여러 루브릭이 필요할 수 있다².
• 출력의 형태에 관해서는, 단일 프롬프트로 0.0-1.0 점수와 통과/실패 등급을 내는 단일 LLM 호출이 실측에서 가장 일관되고 사람의 판단과도 가장 잘 맞았다¹. LLM에게 'correct'/'incorrect'나 1–5를 출력하게 하고, 순수하게 정성적인 평가는 빠르게 대규모로 다루기 어렵다². 평가 점수를 내기 전에 먼저 추론하게 하고 그 추론은 버린다. 평가 성능이 올라가며 특히 복잡한 판단에서 그렇다². 주관적인 차원에는 LLM 기반 리커트 척도를 쓸 수 있다².
• 일한 쪽이 판정자가 될 수 없다. 한 모델 인스턴스는 질의를 처리하고 다른 인스턴스는 거르는 가드레일이, 같은 호출이 둘 다 처리하는 것보다 대체로 더 잘 동작한다³. 새 컨텍스트의 리뷰어는 출력과 당신의 기준만 볼 뿐 그 출력을 만들어 낸 추론은 보지 못해서 결과 자체를 놓고 판정한다⁴. 투표 임계값을 둔 다중 프롬프트 평가는 거짓 양성과 거짓 음성의 균형을 잡는다³.
• 빈틈을 찾으라고 지시받은 리뷰어는 작업이 멀쩡할 때도 대개 뭔가를 보고하고, 모든 지적을 쫓아다니면 과잉 설계로 이어진다. 해법은 정확성이나 명시된 요구 사항에 영향을 주는 빈틈만 표시하게 하고 나머지는 선택 사항으로 취급하는 것이다⁴.
• 판정자에게 에이전트의 자기 보고만 먹이지 않는다. 빠뜨린 것이 넣은 것보다 중요할 때가 많고, LLM이 늘 자기가 의도한 대로 말하지는 않는다⁵. 원본 트랜스크립트(도구 호출과 도구 응답)를 검토해 자기 서술에 없는 행동을 잡아낸다⁵.
• 검토-수정 루프를 만들 가치가 있는지는 두 신호에 달려 있다. 사람이 피드백을 언어로 표현했을 때 LLM 응답이 눈에 띄게 개선되는가, 그리고 LLM이 그런 피드백을 스스로 제공할 수 있는가³.
• 판정자도 모델 호출이라 비용과 잡음이 있다. 채점 방법을 고르는 원칙은 가장 빠르고, 가장 신뢰할 수 있고, 가장 잘 확장되는 것이며 코드 기반 채점이 이 셋 모두에서 앞선다². 결정론적 체크가 잡을 수 있는 것을 판정자에게 보내지 않는다. 자동 평가 너머로 사람의 표본 점검이 여전히 필요하고, 에이전트를 테스트하는 사람은 평가가 놓치는 엣지 케이스를 찾아낸다¹.

>> 레슨 5: 평가 세트: 실제 과제 20개에서 시작하기