LLM 평가셋을 만든다고 하면 많은 팀이 먼저 잘 나온 데모 질문부터 모읍니다. 그런데 그 방식은 초반엔 기분이 좋지만, 운영으로 가면 자주 무너집니다. 실제 사용자는 발표 슬라이드처럼 깔끔하게 묻지 않기 때문입니다.
그래서 평가셋의 목적은 점수를 예쁘게 만드는 것이 아니라, 실제 운영에서 깨질 질문을 미리 드러내는 것에 있어야 합니다. 이 글에서는 positive set, negative set, boundary case, retrieval fail case, regression set 기준으로 실무형 구조를 정리합니다.
LLM 평가셋이 먼저 실패하는 이유
문제는 모델이 아니라 평가셋일 때가 많습니다. 잘 풀리는 질문만 모으면 쉬운 문제만 잘 푸는 상태를 확인하게 되고, 실제 운영에서 자주 등장하는 애매한 질문이나 정책 충돌 질문은 거의 보이지 않게 됩니다.
- 질문 의도가 명확한가
- 정답 근거가 문서에 그대로 있는가
- 표현이 표준적이라 검색이 쉬운가
- 안전 정책과 충돌하지 않는가
- 여러 조건이 섞여 있지 않은가
Anthropic의 Building Effective AI Agents 글도 실제 운영형 시스템에서는 단순한 흐름과 검증 가능한 구조가 중요하다고 설명합니다. 한 번 예쁘게 나온 데모보다 반복 검증 가능한 구조가 더 중요하다는 뜻입니다.
좋은 LLM 평가셋은 무엇을 보려고 만드는가
좋은 LLM 평가셋은 단순 정답률만 보지 않습니다. 정상 질문에는 잘 답하는지, 답하면 안 되는 질문은 멈추는지, 애매한 경계에서 무너지지 않는지, 검색 단계가 먼저 흔들리지 않는지, 그리고 한 번 고친 뒤 다시 안 깨지는지를 함께 봐야 합니다.
- positive set
- negative set
- boundary case
- retrieval fail case
- regression set
이 다섯 묶음이 있어야 점수보다 실패 패턴이 보이기 시작합니다.
positive set: 원래 잘 풀어야 하는 질문 묶음
positive set은 보기 좋은 질문이 아니라 실제 운영에서 자주 나오고 성공해야 하는 질문 묶음이어야 합니다. 예를 들어 사내 문서형 도우미라면 휴가 신청, 비용 정산, 온보딩 절차처럼 반복 빈도와 성공 가치가 높은 질문이 여기에 들어갑니다.
- 실제 사용자 로그에서 반복 등장하는가
- 답변 성공 시 만족도가 높은가
- 실패 비용이 큰가
- 문서 근거가 명확한가
즉 positive set은 성공 사례 모음이 아니라, 반드시 안정적으로 성공해야 하는 핵심 시나리오 묶음입니다.
negative set: 틀려야 하거나 멈춰야 하는 질문 묶음
실무에서는 정답을 맞히는 능력만큼이나, 모르거나 답하면 안 되는 상황에서 제대로 멈추는 능력이 중요합니다. negative set은 없는 사실을 지어내기 쉬운 질문, 정책상 제한해야 하는 요청, 기밀 정보와 충돌하는 질문을 모아 시스템이 과잉 자신감을 보이는지 확인합니다.
- 문서에 없는 정책을 단정적으로 묻는 질문
- 내부 기밀이나 민감 정보를 직접 요구하는 질문
- 근거 없이 추정 답변을 유도하는 질문
- 정책상 답변 제한이 필요한 의료·법률·보안형 질문
negative set이 빠지면 데모는 좋아 보여도 운영 신뢰는 쉽게 무너집니다. 사용자는 ‘대답은 했는데 믿을 수 없다’는 인상을 받게 됩니다.
boundary case: 경계에서 무너지는 패턴을 잡는 묶음
boundary case는 완전히 새로운 질문보다, 원래 되던 질문이 경계 조건에서 얼마나 흔들리는지 봅니다. 질문이 너무 짧거나 너무 길거나, 내부 용어와 공식 용어가 섞이거나, 날짜와 버전 조건이 함께 들어갈 때 특히 흔들립니다.
- 질문이 너무 짧아 의도가 모호한 경우
- 질문이 길어 핵심 조건이 묻히는 경우
- 동의어와 조직 내부 용어가 섞이는 경우
- 여러 조건이 한 질문에 같이 들어오는 경우
- 버전·날짜·정책 기준 시점이 섞이는 경우
boundary case는 모델의 똑똑함을 재는 테스트라기보다, 사용자가 실제로 느끼는 ‘애매한데 왜 갑자기 이상해졌지?’를 먼저 보여주는 장치입니다.
retrieval fail case: 문서는 있는데 못 찾는 상황을 따로 봐야 한다
RAG나 문서 기반 LLM에서는 생성 모델보다 retrieval 단계가 먼저 깨지는 경우가 많습니다. 정답 문서가 있는데 검색 상위에 안 뜨거나, 오래된 문서가 먼저 잡히거나, chunk가 잘못 나뉘어 근거가 분산되면 답변 품질은 쉽게 흔들립니다.
- 정답 문서가 있는데 검색 상위에 안 뜬다
- 비슷한 제목의 오래된 문서가 먼저 잡힌다
- 동의어 때문에 엉뚱한 부서 문서가 나온다
- chunk가 잘못 나뉘어 답 근거가 분산된다
- 최신 정책보다 오래된 FAQ가 먼저 노출된다
이런 사례는 일반 negative set에 묻어두지 말고 retrieval fail case로 따로 관리하는 편이 좋습니다. 그래야 프롬프트 문제인지, 검색 쿼리 생성 문제인지, chunking 문제인지, reranker 문제인지 원인을 분리할 수 있습니다. 관련해서 RAG에서 chunking은 왜 중요할까와 RAG는 왜 기대보다 자주 실망스러울까를 같이 보면 흐름이 더 잘 이어집니다.
regression set: 고친 뒤 다시 안 깨지는지 보는 안전장치
regression set은 실무에서 가장 과소평가되지만 가장 중요한 묶음 중 하나입니다. 프롬프트, 모델, 검색 설정, chunking, reranker, policy를 조금만 바꿔도 예전 성공 질문이 다시 흔들릴 수 있기 때문입니다.
OpenAI Cookbook의 Getting Started with OpenAI Evals 문서도 evals가 코드와 모델 변경에 대한 안정성 장치가 된다고 설명합니다. 한 문제를 고친 뒤 다른 문제가 다시 안 깨지는지 보는 것이 바로 regression set의 역할입니다.
- 프롬프트를 더 엄격하게 바꿨더니 정상 질문도 과하게 거절한다
- chunk size를 바꿨더니 긴 문서는 좋아졌지만 FAQ는 나빠진다
- reranker를 붙였더니 최신 문서는 좋아졌지만 용어 변형 질문은 더 약해진다
평가셋을 실제로 만들 때 추천하는 순서
- 운영 로그에서 실제 질문을 먼저 모은다
- 질문을 성공형·제한형·경계형·검색실패형·회귀감시형으로 나눈다
- 정답 기준을 핵심 사실·근거·제한 동작 중심으로 정의한다
- 자동 채점과 사람 검토를 질문 유형별로 섞는다
- 릴리스마다 regression set을 함께 돌린다
초반에는 질문 1000개보다 80개를 잘 나눈 평가셋이 더 유용할 때가 많습니다. 중요한 것은 숫자가 아니라 대표성입니다.
마무리
LLM 평가셋은 단순한 질문 모음이 아니라, 운영에서 어디서 깨질 수 있는지를 먼저 보여주는 실패 지도에 가깝습니다. 그래서 positive set만으로는 부족하고, negative set, boundary case, retrieval fail case, regression set이 함께 있어야 합니다.
결국 좋은 평가셋의 기준은 점수 한 줄이 아니라, 운영 실패를 얼마나 빨리 드러내고 얼마나 안정적으로 다시 확인할 수 있는가입니다. 관련 글로는 LLM 평가가 어려운 이유, 프롬프트 템플릿이란 무엇인가, RAG 평가셋 만드는 법을 함께 읽어보면 좋습니다.
