19장 — LLM 평가를 위한 골든 데이터셋

작성일 | 분류 , |
평가의 기준점이 되는 골든 데이터셋을 만듭니다. ground truth와 관련 문서·청크로 구성 요소를 나누고, 수집부터 검증까지 6단계 구축 절차를 따라갑니다. JSON이 이상적이지만 도메인 전문가가 못 쓰는 문제를 구글 시트와 노션으로 푸는 협업 전략, 그리고 회귀 테스트와 LLM Judge 자동 평가로 활용하는 법을 정리합니다.

18장에서 지표를 정했다면, 그 지표를 측정할 기준 데이터가 있어야 합니다. 그것이 골든 데이터셋(golden dataset) 입니다.

골든 데이터셋은 LLM 기반 시스템, 특히 RAG 시스템의 성능을 평가하는 데 사용하는 표준화된 참조 데이터셋입니다. 질문과 정답 쌍, 관련 문서, 문서 내 관련 청크 등 다양한 요소로 구성되며, 시스템의 성능을 객관적으로 측정할 수 있는 기준점 역할을 합니다.

19.1 무엇으로 구성되나

구성 요소 역할 어떤 지표를 재나
ground truth 각 질문에 대응하는 기준 정답. 머신러닝에서 쓰는 ‘모델이 생성해야 하는 정답’ 을 뜻한다. 도메인 전문가가 검증해야 하며, 세금 계산이라면 정확한 계산 방식·적용 세율·예외 사항이 포함되어야 한다 사실적 정확성
관련 문서 목록 각 질문에 답하는 데 필요한 정보를 포함한 문서들의 목록 검색 정확도·재현율
문서 내 관련 청크 질문과 직접 관련된 특정 청크나 항목. 종합부동산세 문서가 여러 항목(과세 대상·과세표준·세율·신고 및 납부)으로 되어 있다면, 계산 방법을 묻는 질문에는 과세표준과 세율 청크가 관련성 높은 것으로 표시된다 청크 정밀도·MRR
다양한 질문 유형 단순 사실 / 계산 / 비교 / 조언 요청 상황별 성능
메타데이터 난이도, 예상 검색 결과 수, 질문 도메인 분류 세부 분석

메타데이터의 쓸모가 구체적입니다. 특정 질문이 ‘고난도’로 분류되면, 이 질문에서 시스템 성능이 저조하게 나타나도 이해할 수 있습니다. 또한 특정 도메인이나 질문 유형별로 성능 패턴을 파악하는 데도 도움이 됩니다.

질문 유형 네 가지의 실제 예시는 이렇습니다.

단순 사실: 2024년도 종합부동산세 세율은 얼마인가요?
계산    : 10억 원 상당의 집 두 채를 보유하고 있다면, 종합부동산세는 얼마인가요?
비교    : 작년과 비교했을 때, 올해 종합부동산세가 변경된 부분이 있나요?
조언 요청: 종합부동산세를 줄일 수 있는 합법적인 방법이 있나요?

19.2 구축 방법 여섯 단계

① 관련 문서 수집 및 전처리 → ② 다양한 질문 설계 → ③ 질문별 관련 문서 및 청크 식별
→ ④ ground truth 작성 → ⑤ 평가 항목 설정 → ⑥ 검증 및 개선

① 관련 문서 수집 및 전처리

평가하려는 시스템의 도메인과 관련된 문서를 수집합니다. 이 문서들은 시스템의 지식 베이스를 구성하는 문서들과 유사하거나 동일해야 합니다. 전처리 시 고려할 사항은 표와 그림의 적절한 변환(마크다운 형식), 포매팅 일관성 유지, 중복 내용 제거, 문서 메타데이터(출처·날짜) 보존입니다.

7장에서 표를 마크다운으로 바꿨던 그 작업이 평가 데이터셋에서도 똑같이 필요합니다.

② 다양한 질문 설계

질문은 실제 사용자가 물을 법한 것이어야 하며, 다양한 난이도와 유형을 포함해야 합니다. 고려 사항은 넷입니다.

  • 질문 유형의 다양화: 사실 및 계산, 비교, 조언 요청 등
  • 균형 있는 난이도 분포: 쉬운 질문부터 어려운 질문까지
  • 질문의 명확성: 명확하고 구체적이어야 하지만, 실제 사용자 질문의 모호성을 반영할 수도 있다
  • 도메인 커버리지: 시스템이 다루는 모든 도메인 영역을 포괄

③ 질문별 관련 문서 및 청크 식별

도메인 전문가가 수행하는 것이 가장 정확하지만, 시간과 자원의 제약이 있을 때는 초기 단계에서 자동화된 방법으로 후보군을 추출한 후 전문가가 검증하는 방식을 씁니다.

  1. 키워드 매칭이나 임베딩 기반 검색을 활용해 후보 문서 및 청크 추출
  2. 도메인 전문가가 후보군을 검토하고 관련성 평가
  3. 각 질문에 대해 관련 문서와 청크 목록 작성
  4. 문서와 청크에 관련성 점수 부여(0~5 등의 척도)

이 과정에서 질문마다 ‘답변에 필요한 문서와 청크는 무엇인지’ 확인할 수 있는 참조 데이터가 만들어집니다.

④ ground truth 작성

도메인 전문가가 작성하는 것이 이상적이며, 관련 문서와 청크의 정보를 기반으로 정확하고 완전한 응답을 제공해야 합니다. 고려할 사항은 정확성(모든 사실 정보는 검증된 출처에서), 완전성(질문의 모든 측면), 명확성(이해하기 쉽고 구조화된 형태), 인용(정보의 출처를 명확히 표시)입니다.

⑤ 평가 항목 설정

여기서 중요한 원칙이 나옵니다.

모든 질문에 모든 평가 지표를 적용할 필요는 없습니다. 질문의 특성에 따라 특정 지표가 더 중요해질 수 있기 때문입니다.

질문 유형 중요한 지표
사실 사실적 정확성, 인용 정확성
계산 사실적 정확성, 응답 관련성, 명확성
조언 요청 유용성, 관련성

평가 항목 설정은 각 질문-답변 쌍의 메타데이터에 포함시켜 평가 과정에서 참조할 수 있게 하는 것이 좋습니다.

⑥ 검증 및 개선

여러 전문가의 검토를 거치고 파일럿 테스트를 진행해 품질을 확인합니다. 점검 체크리스트가 명확합니다.

  • 질문이 명확하고 실제 사용 사례를 잘 반영하는가?
  • ground truth가 정확하고 완전한가?
  • 관련 문서와 청크가 적절하게 식별되었는가?
  • 평가 항목이 각 질문의 특성에 맞게 설정되었는가?
  • 데이터셋이 시스템의 성능을 효과적으로 측정할 수 있는가?

골든 데이터셋은 고정된 것이 아니라 시스템과 요구 사항이 달라질 때마다 지속적으로 발전해야 합니다. 새로운 사용 사례, 법률 변경, 시스템 기능 확장 등에 맞춰 데이터셋을 업데이트하는 것이 중요합니다.

19.3 구조화와 협업 — 이 장의 핵심

JSON의 이점과 한계

소프트웨어 엔지니어링 관점에서는 JSON이 이상적입니다.

{
  "questions": [
    {
      "id": "q001",
      "text": "10억 원짜리 집 2채를 보유했을 때 종합부동산세는 얼마인가요?",
      "type": "calculation",
      "difficulty": "medium",
      "domain": "property_tax",
      "relevant_documents": [
        {
          "doc_id": "d123",
          "title": "종합부동산세법",
          "relevance_score": 5,
          "relevant_chunks": [
            {"chunk_id": "c456", "text": "제9조(세율) 주택에 대한 종합부동산세는…", "relevance_score": 5},
            {"chunk_id": "c457", "text": "제8조(과세표준) 주택에 대한 종합부동산세의 과세표준은…", "relevance_score": 5}
          ]
        }
      ],
      "ground_truth": {
        "text": "10억 원짜리 집 2채를 보유했을 때, 종합부동산세는 다음과 같이 계산됩니다…",
        "sources": ["종합부동산세법 제8조", "종합부동산세법 제9조"]
      },
      "evaluation_metrics": ["factual_correctness", "completeness", "groundedness", "clarity"]
    }
  ]
}

그런데 문제가 있습니다.

그러나 이러한 JSON 형식은 도메인 전문가가 직접 작업하기에 어려울 수 있습니다. 소프트웨어 엔지니어는 시스템에 대한 기술적 이해는 있지만, ‘LLM이 생성해야 할 올바른 답변’에 대한 도메인 지식이 부족할 수 있습니다. 특히 세금 계산, 법률 해석, 의료 자문 등의 전문 분야에서는 더욱 한계가 드러납니다.

즉 정답을 아는 사람은 JSON을 못 쓰고, JSON을 쓰는 사람은 정답을 모르는 구조적 문제입니다.

협업 도구가 갖춰야 할 조건

  • 도메인 전문가가 별도의 기술 학습 없이 사용할 수 있어야 한다
  • 구조화된 데이터 관리가 가능해야 한다
  • 실시간 협업과 버전 관리가 지원되어야 한다
  • 프로그래밍 환경과의 연동이 용이해야 한다

구글 시트와 엑셀

세무사, 회계사, 법무 전문가들은 업무에서 엑셀이나 구글 시트를 자주 사용하므로, 별도의 학습 곡선 없이 바로 데이터 입력 작업에 참여할 수 있습니다. 이는 프로젝트 초기 단계에서 전문가의 참여 의지를 높이는 중요한 요소입니다.

종합부동산세 데이터셋이라면 시트 네 개로 구성합니다.

시트 담는 것
시트 1: 질문 목록 ID, 질문 텍스트, 질문 유형(계산형·설명형·절차형), 난이도(1~5), 도메인 세부 분류(종부세·소득세·재산세), 예상 소요 시간, 작성자, 작성일, 검토 상태
시트 2: ground truth 질문 ID, 정답 텍스트, 정답 유형(단답·장문·계산 과정), 출처 문서, 출처 페이지 및 조항, 정답 신뢰도, 검증자, 검증일
시트 3: 관련 문서 질문 ID, 문서 ID, 문서 제목, 문서 유형(법령·해석 사례·계산 예시), 관련성 점수(1~5), 관련성 설명, 문서 경로
시트 4: 관련 청크 질문 ID, 문서 ID, 청크 ID, 청크 텍스트, 청크 위치(페이지·문단), 관련성 점수, 관련성 이유, 핵심 키워드

여기에 실시간 공유·편집, 댓글을 통한 토론, 변경 기록 추적, 조건부 서식으로 검토가 필요한 항목이나 불완전한 데이터를 시각적으로 강조하는 기능이 더해집니다. 파워 쿼리와 매크로로 자동화하거나, 질문 텍스트 길이가 범위를 벗어나면 경고를 표시하거나 정답 형식이 올바르지 않으면 자동 플래그를 세울 수도 있습니다. CSV/엑셀로 내보내 판다스로 처리하기도 쉽습니다.

노션

노션은 구조화된 데이터베이스와 자유로운 문서 작성을 하나의 플랫폼에 결합할 수 있는 것이 가장 큰 장점입니다. 종합부동산세 계산 문제라면 단계별 계산 과정을 표로 정리하고, 관련 법령 조항을 인용하며, 실제 계산서 양식을 이미지로 첨부할 수 있습니다.

관계형 데이터베이스 기능으로 질문·정답·문서·전문가 간의 복잡한 관계를 명확히 설정할 수 있고(하나의 질문이 여러 문서와 관련되는 다대다 관계), 롤업(rollup) 기능으로 한 질문과 관련된 모든 문서의 평균 관련성 점수를 자동 계산하거나 특정 전문가가 작성한 질문 수를 집계할 수 있습니다.

데이터베이스는 넷으로 구성합니다 — 질문 DB, ground truth DB, 문서 DB, 평가 결과 DB. 특히 평가 결과 DB는 평가일, 모델 버전, 질문(관계형), 시스템 응답, 정확성·관련성·완전성 점수, 평가자 의견을 기록해 시간에 따른 성능 변화를 추적합니다.

노션 API를 쓰면 프로그래밍 환경에서 직접 접근할 수 있고, 자동화(automation) 기능으로 특정 조건을 만족할 때 담당자에게 알림을 보내거나 상태를 자동 변경하는 워크플로를 만들 수 있습니다.

파이썬 코드와 현업 전문가의 연결 전략

단순한 데이터 이동이 아니라 두 그룹 간의 지속적인 협업 사이클을 만드는 것이 목표입니다.

  1. 추출 자동화: 구글 스프레드시트는 gspread 로 접근하거나 API로 실시간 동기화하고, 엑셀은 pandas의 read_excel() 을 쓰되 각 시트의 구조를 사전에 정의한다.
  2. 노션 API: 데이터베이스 내용을 JSON으로 추출한다. 이때 노션의 리치 텍스트 형식을 일반 텍스트로 변환하고, 관계형 속성의 참조를 해결해 완전한 데이터셋을 구성해야 한다.
  3. 검증과 정제: 도메인 전문가가 입력한 데이터에는 오타, 일관성 없는 형식, 누락된 필드가 있을 수 있다. 필수 필드 누락, 데이터 타입, 텍스트 길이, 선택 속성 값, 관계형 참조 유효성을 자동으로 검사한다.
  4. 표준화: 날짜 형식 통일, 앞뒤 공백 제거, 대소문자 일관 처리, 그리고 ‘종합부동산세’와 ‘종부세’를 하나로 통일하는 식의 동의어 표준화.
  5. 양방향 피드백 루프: 단방향 추출에 그치지 않고 시스템 평가 결과를 다시 구글 시트나 노션으로 내보내 전문가가 검토할 수 있게 한다. 각 질문 옆에 시스템 응답, 정확성 점수, 오류 유형을 추가해 한눈에 파악할 수 있게 한다.
  6. 구조화된 피드백 수집: 댓글 기능으로 의견을 받고, 이를 다시 코드로 추출해 데이터셋 개선에 반영한다.
  7. 버전 관리: 깃(Git) 으로 데이터셋의 각 버전을 추적하고, 각 버전에서의 시스템 성능을 비교 분석해 어떤 변경이 성능 향상에 기여했는지, 어떤 변경이 예상치 못한 부작용을 가져왔는지 파악한다.

무엇보다 중요한 것은 이 과정이 일회성이 아닌 지속적인 개선 사이클이라는 점입니다. 시스템이 발전하고 도메인 지식이 업데이트됨에 따라 데이터셋도 함께 진화해야 하며, 이를 뒷받침하는 효율적인 협업 인프라가 성공의 열쇠가 됩니다.

19.4 활용 방법 다섯 가지

골든 데이터셋은 단순히 시스템 성능을 측정하는 도구를 넘어, AI 에이전트를 개발하고 운영하는 전 과정에서 핵심적인 역할을 하는 전략적 자산입니다. 마치 의학 연구에서 대조군이 실험의 신뢰성을 보장하는 것처럼, 골든 데이터셋은 LLM 기반 시스템의 품질과 신뢰성을 보장하는 기준점 역할을 합니다.

활용 내용
① 시스템 개발 및 튜닝 검색 알고리즘, 청킹 전략, 프롬프트 설계를 최적화하는 참조 기준. 다양한 청킹 크기를 테스트해 어떤 설정이 가장 높은 청크 정밀도를 달성하는지, 어떤 프롬프트가 가장 높은 사실적 정확성과 근거성을 주는지 확인할 수 있다
② 회귀 테스트 새 기능이나 모델 업데이트가 기존 기능에 부정적 영향을 미치지 않는지 확인한다. 임베딩 모델을 업데이트할 때 이전 모델과 새 모델의 성능을 비교해 검색 정확도가 향상되었는지 확인할 수 있다
③ 시스템 간 비교 동일한 골든 데이터셋으로 여러 시스템을 평가해 강점과 약점을 파악한다. 키워드 기반 검색, 벡터 검색, 하이브리드 검색의 성능을 비교해 도메인이나 질문 유형에 가장 적합한 방식을 고른다
④ LLM Judge 자동 평가 LLM을 판단자(judge) 로 활용해 응답을 자동 평가한다. 골든 데이터셋의 ground truth, 관련 문서, 평가 지표를 기준으로 삼는다
⑤ 지속적인 데이터셋 확장 사용자가 자주 묻는 질문, 시스템이 잘 처리하지 못하는 질문을 식별해 데이터셋에 추가한다

LLM Judge가 수행하는 평가는 넷입니다.

  • 시스템 응답과 ground truth를 비교해 사실적 정확성 평가
  • 시스템 응답이 관련 문서에 근거하는지 확인해 근거성 평가
  • 사용자 질문과 시스템 응답의 관련성 평가
  • 응답의 명확성·완전성 등 품질 측면 평가

이를 통해 인간 평가자의 개입 없이도 대규모 평가를 자동화할 수 있으며, 시스템 개발 과정에서 빠른 피드백 루프를 구축할 수 있습니다. 특히 CI/CD 환경에서 코드가 변경될 때마다 자동으로 품질 검증을 수행할 수 있어 유용합니다. (17장의 ‘품질 게이트’가 이렇게 구현됩니다.)

골든 데이터셋은 정적인 평가 도구가 아니라 시스템과 함께 진화하는 살아 있는 자산입니다.

정리

  • 골든 데이터셋은 ground truth + 관련 문서 + 관련 청크 + 질문 유형 + 메타데이터로 구성된다. 각 요소가 재는 지표가 다르다.
  • 구축은 여섯 단계다. 문서 수집·전처리 → 질문 설계 → 문서/청크 식별 → ground truth 작성 → 평가 항목 설정 → 검증.
  • 모든 질문에 모든 지표를 적용하지 않는다. 사실형은 인용 정확성, 계산형은 명확성, 조언형은 유용성이 중요하다.
  • 진짜 문제는 형식이 아니라 사람이다. 정답을 아는 전문가는 JSON을 쓰지 않는다. 그래서 구글 시트(친숙함)와 노션(구조 + 자유 서술)을 다리로 쓴다.
  • 연결은 양방향이어야 한다. 데이터를 추출만 하지 말고 평가 결과를 다시 전문가에게 돌려보낸다.
  • 데이터셋도 Git으로 버전 관리한다. 어떤 변경이 성능을 올렸는지 추적하려면 필요하다.
  • 활용은 튜닝·회귀 테스트·시스템 비교·LLM Judge 자동 평가·지속 확장이다. 데이터셋은 고정된 정답지가 아니라 함께 자라는 자산이다.