평가 세트 만드는 법 — 개선이 정말 됐는지 숫자로 증명하는 RAG·Text-to-SQL·에이전트 평가 가이드

요약 — 앞선 두 글(프롬프트·RAG·파인튜닝 선택 기준, 사내 DB 데이터를 LLM에 서빙하는 방법)에서 “먼저 평가 질문 30~50개를 만든다”고 거듭 말했습니다. 이 글은 그 평가 세트를 어디서 모으고, 정답과 채점 기준을 어떻게 정하고, 몇 개가 필요하며, 어떻게 채점하고, 파이프라인 단계별로 어떻게 나눠 재고, 어떻게 운영하는지를 정리합니다. 평가 세트는 모델이 아니라 우리 팀이 “좋아졌다”고 말할 자격을 만들어 주는 장치입니다. (사례는 일반화한 가상 시나리오이고, 예시 수치는 설명용입니다.)

0. 먼저 결론: 한 장 요약

핵심 원칙: 평가 세트가 없으면 개선은 “느낌”이고, 있으면 “증거”입니다.

1. 이야기의 이어짐 — “좋아진 것 같아요”의 함정

앞선 글들의 팀은 몇 주 사이에 많은 것을 바꿨습니다. 프롬프트를 다듬었고, 사내 규정 문서를 RAG로 연결했고, DB 질문을 영역별 플로우로 옮겼고, 오케스트레이터에 분류 모델도 붙였습니다. 주간 회의에서 이런 대화가 오갑니다.

• 개발자: “프롬프트를 바꿨더니 답이 훨씬 자연스러워졌어요.”
• 현업 담당: “그런데 어제 휴가 이월 규정을 물었더니 틀린 숫자가 나왔어요.”
• 팀장: “그럼 좋아진 건가요, 아닌가요?”

아무도 답하지 못합니다. 바꾼 것은 많은데 전후를 같은 기준으로 잰 적이 없기 때문입니다. 한 건이 좋아 보이면 개선 같고, 한 건이 틀리면 퇴보 같은 상태에서는 어떤 변경이 도움이 됐는지, 어떤 변경이 다른 곳을 망가뜨렸는지 알 수 없습니다.

2. 평가 세트란 무엇이고 왜 먼저 필요한가

평가(eval) 는 AI 시스템에 입력을 주고, 출력에 채점 기준을 적용해 성공 여부를 재는 테스트입니다. 입력과 정답 기준을 묶은 문항을 모은 것이 평가 세트입니다. 공개된 에이전트 평가 가이드(Anthropic)도 평가를 이렇게 정의하고, 기능 개선을 위한 역량 평가와 퇴보를 막는 회귀 평가를 구분합니다.

역량 평가에서 통과율이 충분히 높아진 문항은 회귀 평가로 승격합니다. 세트가 계속 같은 점수만 내면 더는 개선 신호를 주지 못하므로(포화), 어려운 문항을 새로 추가해야 합니다.

평가 세트와 학습·예시 데이터는 분리합니다. 프롬프트의 few-shot 예시나 파인튜닝 데이터로 쓴 질문을 평가에도 쓰면, 시스템이 “문제를 미리 본 것”이라 점수가 부풀려집니다. 평가용 문항은 따로 떼어 두세요.

3. 질문은 어디서 모으나

처음부터 완벽한 세트를 만들 필요는 없습니다. Anthropic의 가이드는 20~50개의 단순한 과제로 시작하라고 권하고, 새로 상상해 내기보다 이미 하고 있는 수동 점검과 실제 실패 사례에서 가져오라고 합니다.

균형도 중요합니다. 시스템이 “해야 할 때 하는가”뿐 아니라 “하지 말아야 할 때 하지 않는가” 도 재야 합니다. 예를 들어 DB 도우미라면 범위 밖 질문을 거절하는지, 권한 없는 데이터를 요청받았을 때 막는지를 문항에 넣습니다. 한쪽만 재면 한쪽으로만 최적화됩니다(항상 검색하려 드는 시스템처럼).

4. 좋은 평가 문항의 조건

가장 중요한 기준은 “두 명의 도메인 전문가가 같은 판정을 내릴 수 있는가” 입니다. 같은 답을 두고 전문가끼리 합격과 불합격이 갈리는 문항은 모호한 문항입니다. 시스템이 계속 0%로 실패하는 문항이 있다면, 시스템보다 문항이 잘못됐을 가능성을 먼저 의심하세요.

문항 한 건의 구성 예

{
  "id": "hr-014",
  "area": "인사",                    // 영역 (분류 평가용)
  "type": "db_number",               // doc_lookup | db_number | mixed | out_of_scope | safety
  "risk": "high",                    // 오류 비용 (의사결정용 여부)
  "question": "A팀의 이번 달 휴가 사용률은?",
  "expected": {
    "sql_result": [{"dept": "A", "rate": 0.42}],   // 검증된 SQL의 실행 결과
    "must_cite": ["leave_policy_v3"],              // 문서 근거가 필요하면
    "should_refuse": false
  },
  "notes": "사용률 정의는 시맨틱 레이어의 '휴가 사용률' 기준"
}

난이도는 쉬운 것, 보통, 어려운 것을 섞습니다. 어려운 문항이 없으면 세트가 금방 포화됩니다.

5. 몇 개가 필요한가 — 숫자로 보는 오차

“20~50개면 시작할 수 있다”는 말은 시작의 기준입니다. 통과율이 80%라고 나왔을 때, 문항 수에 따라 그 숫자를 얼마나 믿을 수 있는지가 달라집니다. 정규 근사로 계산한 95% 신뢰구간의 대략적인 폭은 다음과 같습니다.

읽는 법 – 50문항에서 “78% → 82%”는 오차 안의 흔들림일 수 있습니다. 작은 차이는 개선이라고 단정하지 마세요. – 같은 문항으로 전후를 비교하는 짝지은 비교는 서로 다른 문항을 비교할 때보다 오차가 작아집니다. 변경 전후에 항상 같은 세트를 쓰는 이유입니다. – 평가 결과에 불확실성(오차 범위)을 함께 적자는 제안이 있습니다(Miller, 2024). 비교하는 두 점수가 오차 범위에서 겹치면 “차이가 있다”고 말하기 어렵습니다. – 문항 수를 늘리는 것만이 답은 아닙니다. 영역별로 쪼개면 영역당 문항 수가 줄어 오차가 다시 커집니다. 위험이 큰 영역은 문항을 더 두텁게 만드세요.

(위 폭은 단순 비율에 대한 정규 근사이며, 문항 수가 적거나 통과율이 극단적이면 다른 방법이 더 정확합니다.)

6. 채점 방법 — 코드, 모델, 사람

모델 채점을 쓸 때 알아 둘 것 – 연구(Zheng 외, 2023)는 강한 모델 판정자가 사람의 선호와 80% 이상 일치해 사람끼리의 일치 수준과 비슷했다고 보고합니다. 동시에 위치 편향, 장황함 편향, 자기 선호 편향 같은 한계도 분석했습니다. 순서를 바꿔 두 번 채점하거나, 길이에 휘둘리지 않도록 기준을 명시하는 식으로 완화합니다. – 판정자에게 “판단 불가(Unknown)” 를 선택지로 주면 억지 판정이 줄어듭니다. – 모델 채점은 사람이 매긴 표본과 주기적으로 비교해 보정합니다. 사람과 어긋나는 문항 유형에서는 채점 기준 문장을 고칩니다. – 결과를 채점하고 경로를 채점하지 마세요. 정답에 이르는 길이 하나가 아닐 수 있습니다. 여러 부분으로 이뤄진 과제는 부분 점수를 줍니다.

7. 파이프라인 단계별로 분리해서 잰다

종단 정확도 하나만 재면 어디가 문제인지 모릅니다. 앞선 글들의 구조대로 단계를 나눠 각각의 지표를 둡니다.

• 검색 지표의 nDCG@10은 정보검색 벤치마크 BEIR에서 주 지표로 쓰이며, 순위를 고려하고 이진·단계형 관련도를 모두 다룰 수 있다는 이유로 선택되었습니다. 다만 BEIR 같은 공개 벤치마크는 참고용 점검이고, 실제 의사결정에는 우리 도메인의 작은 평가 세트가 더 중요합니다.
• RAG 평가 프레임워크 Ragas는 검색이 집중된 관련 구절을 찾았는지, 생성이 그 구절에 충실한지, 생성 품질이 어떤지를 정답 라벨 없이 재는 지표 모음을 제안합니다. 이런 자동 지표는 빠른 점검에 유용하지만, 최종 판단은 사람이 만든 정답 문항으로 확인하는 것이 안전합니다.
• 오케스트레이터에 결정 모델을 쓴다면 분류 평가 세트를 따로 두고, 확률 값이 실제 정답률과 맞는지(보정) 자체 데이터로 확인하세요.

8. 결과가 매번 달라질 때 — 비결정성 다루기

LLM은 같은 질문에도 매번 다른 답을 낼 수 있어서, 한 번 돌려 본 결과로는 부족합니다. 같은 문항을 여러 번(k번) 시도하는 두 가지 지표가 쓰입니다.

예를 들어 한 번 시도의 성공률이 90%여도, 시도들이 서로 독립이라고 가정하면 5번 모두 성공할 확률은 0.9의 5제곱, 약 59%입니다. 사용자가 매번 안정적인 답을 기대하는 서비스라면 pass^k 관점으로 봐야 실제 체감과 가까워집니다.

또한 평가 하네스를 안정적으로 만드세요. 시도마다 깨끗한 상태에서 시작해야 이전 시도의 흔적이 결과를 왜곡하지 않습니다.

9. 운영 — 한 번 만들고 끝이 아니다

1. 변경할 때마다 같은 세트로 돌린다. 프롬프트, 모델, 청킹, 임계값, 플로우 중 무엇을 바꿨든 전후를 같은 세트로 비교합니다. 한 번에 하나씩 바꿔야 원인을 알 수 있습니다.
2. 실패를 원인별로 분류한다. 분류 오류 / 검색 누락 / 근거 무시 / 컬럼 오해·조인 오류 / 권한·거절 오작동 / 채점 오류. 분류가 곧 다음 개선 과제입니다.
3. 기록(트랜스크립트)을 직접 읽는다. 실패가 시스템의 실수인지, 채점자가 정당한 답을 불합격 처리한 것인지 확인합니다. 실패가 억울해 보이면 점수를 믿기 전에 평가부터 고칩니다.
4. 통과율이 높아지면 어려운 문항을 추가한다. 100%가 계속되면 신호가 사라집니다.
5. 소유자를 정한다. 평가 세트는 누군가 관리하지 않으면 시스템이 바뀌는 동안 낡습니다. 현업과 제품 담당이 문항을 기여할 수 있는 경로를 열어 두세요.
6. 새 실패를 문항으로 바꾼다. 운영 중 발견한 오답은 바로 평가 세트에 추가해 같은 실수가 돌아오지 않게 합니다.
7. 기밀을 다룬다. 실제 질문에서 가져온 문항은 개인정보와 회사 기밀을 일반화·익명화한 뒤 저장합니다.

10. 사례로 구성해 보기 — 60문항 세트

앞선 글들의 사내 AI 도우미를 위한 첫 평가 세트는 이렇게 구성할 수 있습니다. (문항 수 배분은 설명용 예시입니다.)

결과를 읽는 가상 예시 (설명용 수치)

이렇게 단계별로 보면 “프롬프트를 바꿨더니 좋아졌다”는 인상이 아니라 어느 변경이 어느 지표를 얼마나 움직였는지가 보입니다. 변화가 없는 항목(근거 충실성)은 다음 개선 과제를 알려 줍니다.

11. 시작 전 체크리스트

• [ ] 평가 세트를 학습·예시 데이터와 분리했다
• [ ] 문항을 실제 질문·실패 기록·현업 인터뷰에서 모았고 익명화했다
• [ ] 두 전문가가 같은 판정을 내릴 수 있도록 정답 기준을 명확히 했다
• [ ] 영역·유형·위험도 태그를 붙였다
• [ ] “해야 할 때”와 “하지 말아야 할 때” 문항을 모두 넣었다
• [ ] DB 질문은 SQL 문자열이 아니라 실행 결과로 채점한다
• [ ] 코드 채점을 기본으로 하고, 모델 채점은 사람 표본으로 보정한다
• [ ] 단계별 지표(분류·검색·생성·DB·안전)를 분리해서 본다
• [ ] 결과에 오차 범위를 함께 적고, 작은 차이를 개선이라 단정하지 않는다
• [ ] 변경 때마다 같은 세트로 전후 비교하고, 통과율이 높아지면 어려운 문항을 추가한다
• [ ] 세트의 소유자를 정했다

12. 정리

• 평가 세트는 모델이 아니라 “좋아졌다”고 말할 자격입니다. 개선에 앞서 먼저 만드세요.
• 20~50개로 시작하되, 작은 차이를 가리려면 더 필요하고 오차 범위를 함께 봐야 합니다.
• 정답은 두 전문가가 같은 판정을 내릴 만큼 명확하게, DB 질문은 실행 결과로 채점합니다.
• 코드 채점이 기본이고, 모델 채점은 편향을 알고 사람 표본으로 보정하며, 사람은 표본과 분쟁에 씁니다.
• 종단 점수 하나가 아니라 분류·검색·생성·DB·안전을 분리해서 재야 어디를 고칠지 보입니다.
• 평가는 한 번이 아니라 운영입니다. 변경 때마다 돌리고, 실패를 분류하고, 새 실패를 문항으로 바꾸세요.

다음 편 제안: 오케스트레이터와 영역 플로우의 실제 구현(분류 프롬프트, 확신도 임계값, 범위 밖 처리).

13. 참고 자료

본문의 근거는 아래 자료를 읽고 저자가 요약·해석한 것입니다. 수치와 표현은 원문을 직접 확인하세요.

• Anthropic, Demystifying evals for AI agents — 평가의 정의, 역량·회귀 평가, 20~50개로 시작, 채점 방식, pass@k와 pass^k, 로드맵
• Zheng 외, Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023 — 모델 채점과 사람 선호의 일치, 편향
• Es 외, Ragas: Automated Evaluation of Retrieval Augmented Generation, EACL 2024 — 정답 라벨 없는 RAG 평가 지표 모음
• Thakur 외, BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021 — nDCG@10 등 검색 평가
• Miller, Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations, 2024 — 평가 결과의 오차 범위
• Li 외, BIRD: Can LLM Already Serve as A Database Interface?, NeurIPS 2023 — 실행 결과 기반 Text-to-SQL 평가

이 글의 방법은 공개된 일반적인 실무 지침과 저자의 정리에 기반하며, 예시 수치는 설명용입니다. 조직의 데이터·위험 수준에 맞게 검증한 뒤 적용하세요.