답을 쓰는 AI 옆에 채점하는 AI를 두어 점수나 피드백을 주게 하는 구조로, 답변이 너무 많아 사람이 다 검토할 수 없을 때 품질을 자동으로 재고 고치는 데 쓴다. 채점만 따로 쓰면 LLM-as-a-Judge라고 부르고, 생성·평가·수정을 반복하면 평가자-최적화자(evaluator-optimizer)라고 부른다.
| 채점 방식 | 하는 일 | 이럴 때 쓴다 |
|---|---|---|
| 직접 채점 | 답 하나를 기준에 따라 통과·실패로 판정 | 사실 충실도, 정책 위반 |
| 쌍 비교 | 두 답 중 나은 쪽 고르기 | 말투·설득력, 프롬프트 A/B 결정 |
| 참조 기반 | 모범 답안과 얼마나 가까운지 보기 | 정답이 있는 과제 |
어떤 방식이든 크리틱 하나에 기준 하나만 맡기는 게 좋다. 판정이 선명해지고, 점수가 떨어졌을 때 원인도 바로 보인다.
강한 모델을 심사위원으로 쓰면 사람 평가와 꽤 잘 맞지만, 버릇이 있어서 보정해야 한다.
| 버릇 | 내용 | 보정법 |
|---|---|---|
| 위치 편향 | 특정 순서의 답을 더 좋게 봄 | 순서를 바꿔 두 번 돌려 같을 때만 인정 |
| 장황함 편향 | 긴 답을 선호 | 길이에 점수를 주지 말라고 기준에 적기 |
| 자기 선호 편향 | 자기가 쓴 답을 높게 봄 | 다른 계열 모델을 심사위원으로 |
판정 전에 근거부터 쓰게 하고, 잘된 예와 잘못된 예를 몇 개 보여주기만 해도 판정이 훨씬 일관된다.
기준이 모호하면 크리틱 점수도 흔들린다. 도메인 전문가가 실제 출력 수십~수백 개에 통과·실패와 이유를 적고, 이를 예시로 프롬프트를 만든 뒤, 크리틱이 전문가와 얼마나 같게 판정하는지 재며 다듬는다. 점수 척도보다 통과·실패 이진 판정이 더 일관된다.
일치율은 단순 정확도 말고 "실패를 실패로 잡은 비율"을 따로 본다. 실패가 드물면 무조건 통과라고 해도 정확도가 높아 보이기 때문이다. 프롬프트 예시와 검증 데이터는 나누고, 모델을 바꾸면 같은 절차로 다시 맞춘다. 크리틱은 사람을 대신하는 게 아니라 전문가 한 명의 기준을 수만 건에 똑같이 적용해 주는 도구다.
평가 파이프라인에서는 RAG 챗봇이라면 "답의 모든 주장이 검색된 문서에 있는가"를 묻는 크리틱을 만들고, Langfuse나 Braintrust 같은 도구에 연결해 운영 트래픽 일부를 자동 채점한다. 프롬프트나 모델을 바꿀 때마다 같은 테스트 세트에 돌리면 그대로 회귀 테스트가 된다.
에이전트 안에서는 생성과 비판을 루프로 묶는다. 번역 초안을 크리틱이 짚고 고친 결과를 다시 평가하거나, Claude Code에 리뷰 전용 서브에이전트를 두고 코드를 고칠 때마다 요구사항과 엣지 케이스를 검토하게 한다.
| 쓰는 곳 | 어울림 | 이유 |
|---|---|---|
| 배포 전 검증, 사후 샘플링 채점 | 잘 맞음 | 느려도 괜찮다 |
| 실시간 응답을 막는 가드레일 | 덜 맞음 | 근거까지 쓰는 호출은 무겁다 |
루프에는 반복 횟수 상한과 통과 기준을 꼭 정해 둔다. 그렇지 않으면 크리틱이 사소한 지적을 끝없이 만들어 비용만 늘어난다.