LLM 평가 데이터셋, 정답 예시와 평가 기준을 함께 만드는 방법
페이지 정보
본문
LLM의 프롬프트를 바꾼 뒤 답변이 더 좋아졌는지 판단하려면 비교할 질문만 모아서는 부족합니다. 어떤 답변을 좋은 결과로 볼지와 어떤 오류를 따로 세어야 할지도 정해야 합니다.
평가 데이터셋은 입력 사례를 담는 그릇이고, 평가 기준은 그 결과를 읽는 규칙입니다. 두 가지를 함께 설계해야 보기 좋은 답변 몇 개를 전체 성능으로 오해하지 않을 수 있습니다.
이 글은 주니어 개발자가 작은 평가 계획을 정리하는 데 필요한 개념과 예시를 설명합니다.
AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.
핵심 정리
입력·필요한 문맥·기대하는 조건·실패 기준을 함께 기록합니다. 정답 문장과 평가 규칙을 구분하고, 모델뿐 아니라 데이터셋과 평가자의 버전도 맞춰 비교합니다.
1. 무엇을 평가하는지 범위를 먼저 정합니다
문서 검색 결과를 평가하는지, 검색한 자료를 바탕으로 만든 답변을 평가하는지, 사용자의 업무가 실제로 완료됐는지를 구분합니다. LangSmith의 평가 개념 문서는 시스템 구성 요소와 품질 기준을 나누어 생각하는 방식을 설명합니다.
하나의 최종 점수만 보면 검색이 잘못된 것인지 답변 생성이 잘못된 것인지 알기 어려울 수 있습니다. 직접 만든 가상 예로 사내 문서 안내 기능이라면 관련 문서를 찾았는가와 찾은 문서의 내용을 정확히 설명했는가를 다른 질문으로 둘 수 있습니다.
여기서 제시하는 분류는 모든 앱에 맞는 표준이 아니라 자신의 기능을 작은 관찰 단위로 나누는 출발점입니다.
2. 입력만이 아니라 필요한 문맥도 남깁니다
같은 질문이라도 대화 이력이나 제공 문서가 다르면 기대 답변이 달라집니다. 평가 사례에는 사용자의 입력과 실제 실행에 제공할 문맥을 구분해서 기록합니다.
참고 정답이 있다면 그것이 모델에게 전달되는 입력인지 평가자가 비교할 자료인지 명확히 합니다. LangSmith의 예시 데이터 구조는 입력과 선택적 참고 출력, 메타데이터를 구분합니다.
정답을 비교에만 쓰려던 계획인데 입력에 함께 넣으면 평가하려던 조건이 달라질 수 있습니다. 가상의 사내 규정 질문이라면 적용 문서의 날짜와 제공 범위를 기록하면, 뒤에 규정 자료가 바뀌었을 때 모델 변경과 문맥 변경을 구분하기 쉽습니다.
3. 정답 문장과 통과 조건을 나눕니다
자유로운 설명형 답변은 같은 뜻을 여러 문장으로 표현할 수 있습니다. 미리 적은 문장과 글자까지 같아야만 통과하도록 하면 적절한 다른 표현을 실패로 볼 수 있습니다.
반대로 필수 정보가 빠졌는데 말투가 자연스럽다는 이유로 통과시키는 것도 문제입니다. 직접 만든 예로 도서 대출 안내라면 기간을 정확히 설명함, 대상 조건을 누락하지 않음, 자료에 없는 연장 규칙을 만들지 않음을 나눌 수 있습니다.
이 예시의 규칙 자체가 실제 도서관 정책을 뜻하지는 않습니다. 정답 예시는 기준을 이해하는 자료로 쓰고, 실제로 무엇을 확인할지는 평가 항목으로 적으면 결과를 설명하기 쉬워집니다.
4. 확정 규칙과 판단이 필요한 항목을 구분합니다
필수 필드가 있는지나 허용된 분류 값인지처럼 코드로 확인하기 쉬운 조건과, 설명이 충분한지처럼 해석이 필요한 조건은 다르게 다룰 수 있습니다. Anthropic의 평가 설명은 코드 기반, 모델 기반, 사람의 평가가 서로 다른 장점과 한계를 가진다고 설명합니다.
LLM을 평가자로 쓰는 경우에도 판단이 자동으로 정답이 되지는 않습니다. LangSmith의 LLM 평가자 문서는 평가 지시와 입력·출력·참고 자료의 연결을 설정하는 방식을 제시합니다.
어떤 정보로 무엇을 판단하게 했는지 남겨야 평가 결과를 다시 살필 수 있습니다. 단순히 더 큰 모델이 준 점수라는 이유만으로 사람의 검토가 불필요하다고 생각하지 않습니다.
5. 쉬운 사례와 실패하기 쉬운 사례를 나눕니다
직접 만든 연습 데이터셋이라면 평범한 질문만 모으기보다 문서에 답이 없는 질문, 조건이 빠진 질문, 표현이 모호한 질문도 포함할 수 있습니다. 다만 어려운 질문을 많이 넣었다는 사실이 실제 사용자 분포를 대표한다는 뜻은 아닙니다.
목적에 따라 일반 사용 사례와 취약점 확인 사례를 구분해 결과를 읽는 편이 좋습니다. 가령 일반 질문에서는 개선됐지만 답이 없는 상황에서 추측 답변이 늘었다면 평균 점수 하나로는 놓칠 수 있습니다.
범주별 실패 목록을 함께 남기면 어떤 행동을 바꿔야 하는지 논의하기 쉽습니다. 이 제안은 특정 개수의 사례가 충분하다는 보장이 아니라 작은 평가를 시작할 때 사용할 분류 예시입니다.
6. 반복 결과와 평가 근거를 함께 봅니다
LLM 출력이 달라질 수 있는 환경에서는 같은 입력의 한 번 성공을 항상 성공으로 해석하기 어렵습니다. Anthropic 문서는 평가 과제와 반복 시도를 구분하고 결과 상태를 확인하는 중요성을 설명합니다.
업무 수행 앱이라면 완료했다는 문장과 실제로 원하는 결과가 생성됐는지를 나누어 볼 수 있습니다. 평가를 설계할 때 반복 횟수와 실행 조건을 기록하고, 성공·실패의 이유도 살펴봅니다.
이 글은 모든 기능에 같은 반복 횟수를 권하는 것이 아닙니다. 변동이 어떤 판단에 영향을 주는지에 맞춰 계획해야 합니다.
평가자의 점수가 흔들리는 경우에는 모델 출력의 변화와 평가 기준의 불안정성을 구분해 조사하는 편이 좋습니다.
7. 데이터셋과 평가자의 변경도 버전으로 남깁니다
프롬프트만 바꾸었다고 생각했는데 비교 시점마다 질문이나 정답 예시가 달라졌다면 점수 차이를 해석하기 어렵습니다. LangSmith의 데이터셋 관리 문서는 사례 추가·수정·삭제에 따른 버전 관리와 특정 버전 평가를 설명합니다.
도구를 사용하지 않아도 파일의 버전이나 변경 기록을 남기는 원칙은 적용할 수 있습니다. 모델 설정, 제공 문서, 평가 기준, 평가자 설정을 함께 기록하면 비교 조건을 대조하기 쉽습니다.
오래된 정답에 오류가 발견되면 고치되 이전 실험과 같은 기준이라고 표시하지 않습니다. 실제 사용자 자료를 넣을 때는 사용 목적에 맞게 개인정보와 비밀정보를 제거하고 공유 범위를 검토해야 합니다.
8. 점수에서 다음 수정으로 이어지는 메모를 만듭니다
가상의 문서 안내 기능에서 새 프롬프트가 더 짧게 답하도록 바뀌었다고 가정합니다. 설명 길이는 줄었지만 필수 조건 누락이 늘었다면 간결성 점수만으로 개선이라고 결론 내리지 않습니다.
입력, 이전 출력, 새 출력, 실패한 기준을 묶어 몇 가지 사례를 살펴볼 수 있습니다. 수정한 뒤 같은 비교 조건에서 다시 평가하고 새로 추가한 어려운 사례의 결과는 별도로 표시합니다.
평가 데이터셋은 보기 좋은 점수를 만들기 위한 목록이 아니라 바뀐 행동을 설명할 수 있게 하는 자료입니다. 실제 사용에서 발견한 문제를 검토해 새로운 사례로 반영하되, 그때마다 무엇이 바뀌었는지 남겨야 이후 점수의 의미도 유지됩니다.
9. 자주 묻는 질문
Q1. 모든 질문에 정답 문장 하나가 있어야 하나요?
평가 목적에 따라 다릅니다. 정답 레이블처럼 정확한 비교가 가능한 과제도 있지만 설명형 답변은 필수 정보와 허용 조건을 기준으로 볼 수 있습니다.
참고 답변이 있더라도 글자 일치만을 유일한 판단 기준으로 삼을 필요는 없습니다.
Q2. 다른 LLM이 채점하면 객관적인 점수가 되나요?
자동화할 수 있다는 점과 판단이 항상 정확하다는 점은 다릅니다. 평가 지시와 입력 자료를 검토하고 사람의 판단과 어긋나는 사례를 확인해야 합니다.
평가자 모델과 기준이 바뀌면 비교 조건도 달라질 수 있습니다.
Q3. 평균 점수가 오르면 바로 배포해도 되나요?
평균만으로 중요한 실패가 가려질 수 있습니다. 기능에 필요한 조건과 범주별 결과, 새로 생긴 오류를 함께 살펴야 합니다.
실제 배포 여부는 서비스의 요구와 검증 기준에 따라 별도로 결정합니다.
Q4. 평가용 사례를 계속 추가해도 이전 점수와 비교할 수 있나요?
같은 데이터셋 버전인지 먼저 확인해야 합니다. 사례 구성이 달라졌다면 점수 차이에 데이터 변화가 섞일 수 있습니다.
공통된 기존 사례의 결과와 새 사례의 결과를 나눠 보는 방식도 검토할 수 있습니다.
참고 자료
- 이전글CI와 CD의 차이, 테스트 자동화와 배포 자동화를 나누어 이해하기 26.09.25
- 다음글컨테이너 볼륨과 쓰기 계층, 데이터가 남는 위치 이해하기 26.09.25
댓글목록
등록된 댓글이 없습니다.