최소 기능 eval 구축하기

이 영상의 데모는 2026년 8월에 녹화되었습니다. Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5에서 실행되었습니다. 결과는 더 새로운 모델에서는 다를 수 있습니다. 각 레슨의 데모는 별도의 eval 실행이므로, 점수와 비용은 다른 레슨의 것과 일치하지 않습니다.

eval은 모델이 치르는 시험입니다. eval에는 세 가지 요소가 있습니다: 현실적인 입력, 각 입력에 대해 기대하는 답, 그리고 각 모델이 반환한 결과를 채점하는 방법입니다. 각 모델은 모든 입력에 대해 프롬프트를 실행합니다. 입력과 그에 대한 기대 답을 합쳐 하나의 케이스가 되며, 모든 케이스를 채점하면 점수가 나옵니다.

Meridian의 추출 프롬프트는 매월 작성되는 프로젝트 보고서에서 세 가지 필드를 추출합니다: 프로젝트 ID와 일정 상태(둘 다 짧은 값)이고, 가장 큰 리스크(한 문장)입니다.

eval을 구축하는 것은 시험을 출제하는 것과 비슷하며, 여러분은 교사 역할을, 모델들은 학생 역할을 합니다.

LLM 판정자는 답을 확인하고 맞는지 판단하는 두 번째 모델입니다. 답을 채점하는 모든 것은 그것이 코드든, 모델이든, 사람이든 채점자라고 부릅니다. 여러분은 여섯 단계로 Meridian의 eval을 구축하게 됩니다:

1. 각 필드에 대한 채점자 선택
2. 케이스 세트 설계
3. 기대하는 답 기록
4. 가장 큰 리스크를 위한 LLM 판정자 설정
5. 모델 실행 및 답안 채점
6. 판정자를 신뢰하기 전에 표본을 직접 채점

각 필드에 대한 채점자 선택

답을 채점하는 방법에는 세 가지가 있습니다. 원칙은 신뢰할 수 있고 확장 가능하면서도 가장 빠른 방법을 선택하는 것입니다.

1. 코드 기반 채점. 여러분의 코드는 답이 기대하는 답과 정확히 일치하는지, 또는 핵심 문구를 포함하는지 확인합니다. 가장 빠르고 가장 신뢰할 수 있는 방법이며, 케이스 수에 상관없이 확장됩니다.
2. LLM 판정자. 판정자는 서로 다른 두 문장이 모두 맞을 수 있는 경우에 적합합니다. 이 또한 빠르고, 유연하며, 확장 가능합니다.
3. 사람에 의한 채점. 사람이 각 답을 읽는 방식으로, 품질은 가장 좋지만 느리고 비용이 많이 들기 때문에 마지막 수단입니다. 전문적이고 위험 부담이 큰 작업, 그리고 판단에 달린 답에 대해서는 여전히 사람이 적합한 채점자입니다.

정확하게 확인할 수 있는 모든 필드에는 코드를 사용하고, 남는 것만 판정자에게 맡기세요. Meridian의 세 필드 중 한 케이스인 보고서 r032에서 이것이 어떻게 적용되는지 살펴보겠습니다.

다만 보고서에 리스크가 명시되지 않은 경우, 기대하는 top_risk 값은 JSON의 빈 값인 null입니다. 코드는 이를 정확 일치로 확인할 수 있습니다.

케이스 세트 설계

전체 케이스 세트의 형태는 네 가지 규칙으로 정해집니다. 이는 문서의 eval 설계 원칙을 기반으로 합니다.

1. 케이스를 작업에 특화되게 만드세요. 실제 보고서로부터 케이스를 만드세요. 샘플 데이터는 모델이 샘플에서 어떻게 작동하는지만 보여줄 뿐입니다.
2. 채점을 자동화하세요. 이 세트를 반복해서 실행하게 되므로, 일상적인 채점은 사람 없이도 작동해야 합니다.
3. 완성도보다 양을 우선시하세요. 같은 노력을 들인다면, 자동으로 채점된 많은 케이스가 정성껏 수작업으로 채점된 소수의 케이스보다 더 많은 정보를 줍니다.
4. 엣지 케이스를 계층화하세요. 엣지 케이스란 스캔된 보고서처럼 흔치 않지만 실제 운영 환경에서 여전히 발생하는 입력을 말합니다. 각 종류에는 운영 환경에서 차지하는 비율만큼의 케이스 비중을 부여하세요. 예를 들어 스캔된 보고서가 전체 유입량의 5%라면, 세트에서도 약 5%가 되도록 하세요.

무엇보다도 케이스의 구성은 운영 환경에서 받는 것과 비슷해야 합니다. 많은 팀들이 "많은 양"을 수백 개의 케이스로 생각하지만, 20~50개 정도의 단순한 케이스로 이루어진 세트도 훌륭한 출발점이 됩니다.

Meridian은 50개의 케이스로 정했습니다. 30개는 일반적인 보고서이고, 10개는 여러 프로젝트를 다루며, 10개는 리스크 누락 케이스, 즉 리스크 섹션이 없는 보고서입니다. 두 가지 특이 유형 모두 Meridian에 충분히 자주 들어오기 때문에 포함하고자 했습니다.

기대하는 답 기록

사람이 기대하는 답을 직접 기록해 둔 케이스들을 레이블된 세트라고 부릅니다. 어떤 모델도 실행되기 전에, 보고서를 바탕으로 기대하는 답을 직접 작성하세요. 코드 채점자는 모델의 답을 이 값들과 비교합니다.

Meridian은 레이블된 세트를 golden.json이라는 하나의 파일에 보관하며, 각 케이스마다 하나의 레코드가 있습니다. 레코드에는 케이스의 id, category, 그리고 각 필드에 대한 기대하는 답이 들어 있습니다. category는 typical, multi_project, missing_risk 중 하나입니다.

가장 큰 리스크를 위한 LLM 판정자 설정

top_risk 필드는 한 문장을 담고 있습니다. 코드는 서로 다른 두 문장이 같은 리스크를 가리키는지 판단할 수 없으므로, 이 필드는 판정자에게 맡깁니다. 이것은 서술형 문항에 해당하며, 조교와 마찬가지로 판정자도 채점 가이드가 필요합니다.

그 가이드가 바로 루브릭으로, 무엇이 맞는 것으로 간주되고 무엇이 틀린 것으로 간주되는지에 대한 규칙을 글로 정리한 것입니다. 루브릭은 상세하고 명확해야 합니다.

판정자의 프롬프트에는 보고서, 답, 그리고 루브릭이 들어 있습니다. 각각은 자체 XML 태그 안에 들어가며, 이렇게 하면 판정자가 이들을 혼동할 가능성이 줄어듭니다. 여러분이 기대하는 답은 프롬프트에 들어가지 않는데, 판정자는 보고서 자체를 근거로 판단하기 때문입니다. 이렇게 하면 단지 여러분과 다른 말로 리스크를 표현했다는 이유만으로 답이 감점되지 않습니다. 다만 표본을 직접 채점할 때 정답 기록으로 활용할 수 있으므로, 여러분이 기대하는 답은 그대로 보관해 두세요.

판정자가 하나의 답에 대해 내리는 결론을 판정이라고 부릅니다. 판정은 여러분의 코드가 집계할 수 있는 형태로 돌아올 때만 유용합니다. 구조화된 출력이 이를 가능하게 합니다. 요청과 함께 JSON 스키마를 보내면 응답이 그 스키마와 일치해야 합니다. JSON 스키마는 JSON이 어떤 필드를 가질 수 있는지, 각 필드에 무엇이 들어갈 수 있는지를 설명합니다.

Meridian의 스키마에는 explanation과 verdict라는 두 개의 필드가 있습니다. verdict는 correct, incorrect, unknown 중 하나여야 합니다. explanation은 판정자가 왜 그렇게 판단했는지에 대한 간단한 설명으로, 답에 어떤 문제가 있었는지 알고 싶을 때 읽는 부분입니다.

가장 중요한 값은 unknown입니다. 이는 판정자에게 빠져나갈 길, 즉 판단할 수 없다고 말할 수 있는 선택지를 줍니다. 이것이 없다면, 판정자는 확신이 없을 때마다 나머지 둘 중 하나를 추측해야 합니다.

모델 실행 및 답안 채점

채점을 하기 전에 먼저 답이 있어야 합니다. 테스트하려는 각 모델로 모든 케이스에 대해 프롬프트를 실행하고, 모든 답을 파일에 저장하세요. Meridian은 Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5로 50개 케이스 전체에 대해 추출 프롬프트를 실행했습니다.

두 채점자가 일치하는지 확인하기 위해, 코드로도 채점 가능한 케이스에서 판정자를 먼저 테스트하세요. Meridian의 첫 번째 판정자 실행은 10개의 리스크 누락 케이스만을 대상으로 했으며, 이는 세 모델에 걸쳐 30개의 답에 해당했습니다. 이 케이스들의 기대하는 답은 null이므로 코드로도 채점할 수 있었습니다. 나중에 직접 판정자를 확인할 수 있도록, 각 판정을 해당 답 옆에 저장하세요.

판정자의 첫 실행, 코드로도 채점 가능한 10개의 리스크 누락 케이스에 대한 결과.

리스크 섹션이 없는 보고서의 경우, Meridian은 이제 예전에는 의견만 있던 각 모델에 대해 숫자를 갖게 되었습니다.

Haiku 4.5의 틀린 답 다섯 개는 모두 같은 종류의 실수이며, 케이스 r045가 그 예입니다.

판정자의 설명은 답이 저지른 실수의 종류를 명시합니다. 이 실수는 보고서에 리스크가 없을 때 무엇을 해야 하는지 전혀 명시하지 않는 추출 프롬프트에서 비롯됩니다.

판정자를 신뢰하기 전에 표본을 직접 채점하기

판정자는 30개 답 모두에서 코드와 일치했지만, 그 답들은 어차피 코드로도 확인할 수 있는 것들이었습니다. 판정자의 진짜 역할은 코드가 도움이 되지 않는 자유 텍스트를 채점하는 것입니다. 그 역할을 맡기기 전에 신뢰할 수 있는지 테스트하세요. 두 가지 방법이 도움이 됩니다.

1. 표본을 직접 채점하세요. 저장된 답 중 일부를 손으로 채점한 뒤 여러분의 채점 결과와 판정자의 판정을 비교하세요. 판정자는 사람 전문가와 밀접하게 일치해야 하기 때문입니다. 여러분과 판정자가 의견이 갈리는 부분이 있다면, 루브릭을 더 명확하게 다듬고 다시 실행해 보세요.
2. 답을 작성하지 않은 모델을 판정자로 사용하세요. 일반적으로 출력을 작성한 모델과는 다른 모델로 채점하는 것이 가장 좋습니다.

핵심 요약

1. 정확한 확인이 가능한 경우에는 코드로, 서로 다른 두 문장이 모두 맞을 수 있는 경우에는 판정자로, 판단이 필요한 경우에는 사람으로 채점하세요.
2. 어떤 모델도 실행되기 전에 기대하는 답을 기록해 두고, 운영 환경과 비슷한 케이스 세트를 구축하세요.
3. 판정자에게 루브릭, 판정이 일치해야 하는 스키마, 그리고 unknown이라고 말할 수 있는 선택지를 주세요.
4. 판정자를 신뢰하기 전에 그 작업의 표본을 직접 채점해 보세요.