rastalion.dev
⌘K
DATABASE

RAG 평가 데이터셋: Gold·QA 구축부터 검색·답변 품질 평가까지

teinam 2026-09-27updated 09-28 12 MIN

시리즈 · 1. 데이터 범위·요건·전처리·피처 · 2. 평가 데이터셋과 품질 평가

관련 글 · 벡터 DB의 개념과 제품 · 선택 기준과 기능 비교 · AWS 전용 벡터 검색

사내 운영 문서를 검색하는 챗봇에 사용자가 “야간에 DB 장애가 나면 어디에 먼저 알려야 하나요?”라고 물었다고 해 봅시다. 답변이 틀렸다면 검색이 필요한 근거를 놓쳤는지, 가져온 근거를 모델이 잘못 읽었는지 구분할 수 있어야 고칠 곳을 찾을 수 있습니다.

앞선 글에서는 이 챗봇에 넣을 데이터의 범위와 요건, 전처리, 피처 설계를 정리했습니다. 이번에는 그 데이터로 만든 서비스가 제대로 동작하는지 확인할 평가 데이터셋을 만들고, 검색 품질과 답변 품질을 나눠 평가하는 방법을 살펴봅니다. 앞선 글에서 구분했듯이 검색 문서 집합(corpus), 모델을 학습할 데이터, 결과를 평가할 데이터는 목적이 다릅니다. 이미 학습된 임베딩 모델과 LLM을 사용하는 일반적인 RAG는 별도의 모델 학습 없이 구성할 수 있고, 필요에 따라 모델 학습을 추가할 수 있습니다.1 이 글은 세 가지 데이터 가운데 평가 데이터를 중심으로 다룹니다.

이 글의 조사 기준일은 2026년 9월 27일입니다. 평가 레코드 JSON의 운영 지침은 설명을 위해 만든 가상 예시이며, 평가 지표의 수치는 계산 예시입니다. 실제 서비스의 성능을 측정한 결과는 아닙니다.

1. Gold 데이터와 QA는 어떻게 만들까요

업무 전문가가 중요한 원천 자료를 골라 검토하고, 이를 바탕으로 LLM이 질문과 답변을 확장한 뒤 전문가가 다시 확인하는 흐름으로 질문·답변(QA)을 만들 수 있습니다. 실제 사용자 질문을 활용하고, 데이터 생성 전체를 검토 없이 자동화하지 않는다는 점이 핵심입니다.

이 글에서는 업무 전문가가 골라 검토한 중요한 원천 자료를 Gold 데이터, 정답 근거와 참고 답변까지 확정한 질문·답변을 평가 문항이라고 부르고 둘을 구분합니다. 원천 문서가 정확하더라도 그 문서에서 생성한 질문이 모호하거나 답변이 틀릴 수 있으므로, 문서를 승인한 것만으로 QA까지 승인된 것은 아닙니다.

대표 사례와 놓치면 안 되는 사례를 함께 고릅니다

자료를 업무별로 분류하고, 질문의 빈도와 실패했을 때의 영향을 함께 봅니다. 벡터 유사도로 비슷한 자료를 묶어 대표 사례를 찾는 방법은 선별을 도울 수 있습니다. 다만 중심에 가까운 문서만 고르면 드문 예외나 특이한 형식이 빠질 수 있으므로, 아래와 같은 사례를 별도로 넣는 편이 좋습니다.

  • 자주 묻는 용어·절차와 실제 Help Desk 질문
  • 표·그림·각주를 읽어야 답할 수 있는 질문
  • 둘 이상의 근거를 조합해야 하는 질문
  • 개정 전후의 내용이 달라지는 질문
  • 자료에 답이 없거나 추가 조건을 물어야 하는 질문
  • 사용자 권한에 따라 제공 가능한 정보가 달라지는 질문

RAG 평가 도구인 Ragas도 단일 근거로 답하는 질문과 여러 출처를 연결해야 하는 질문을 구분합니다. 질문의 말투만 바꾸는 것에 더해, 어떤 근거와 추론이 필요한지 달라지는 문항을 만드는 데 참고할 수 있습니다.2

질문 생성과 답변 작성 모두에 근거를 제공합니다

QA 작성 순서는 다음과 같이 잡을 수 있습니다.

  1. 근거를 고릅니다. 원천 문서의 버전과 답에 필요한 부분을 지정합니다.
  2. 질문을 만듭니다. 실제 질문을 우선 활용하고, 빈 유형은 LLM으로 보충합니다.
  3. 답변을 작성합니다. 질문과 함께 근거를 제공해 참고 답변과 필수 사실을 만듭니다.
  4. 형식을 맞춥니다. 요약, 목록, 절차, 출처 표기 등 서비스의 출력 요구를 반영합니다.
  5. 전문가가 확인합니다. 업무상 타당성, 원문과의 일치, 누락된 조건, 답변 가능 여부를 검사합니다.
  6. 이력을 남깁니다. 원본·생성 모델·프롬프트·검토 상태를 기록하고, 중복 문항을 정리합니다.

질문만 LLM에 주고 답을 만들게 하면 근거 밖의 지식으로 그럴듯한 정답을 만들어 낼 수 있습니다. 질문을 만드는 단계와 답변을 만드는 단계 모두에 승인된 자료를 연결하는 것이 좋습니다.

평가 문항을 만드는 흐름 A data-flow diagram generated by Archify. 01 / 입력 02 / 질문 03 / 답변 04 / 검토 05 / 확정 실제 사용자 질문 · Help Desk 등 · 01 / 입력 실제 사용자 질문 Help Desk 등 질문 생성 · 빈 유형은 LLM 보충 · 02 / 질문 질문 생성 빈 유형은 LLM 보충 승인된 근거 · 문서 버전 · 필요한 부분 · 02 / 질문 승인된 근거 문서 버전 · 필요한 부분 답변 작성 · 참고 답변 · 필수 사실 · 형식 · 03 / 답변 답변 작성 참고 답변 · 필수 사실 · 형식 전문가 확인 · 원문 일치 · 누락 조건 · 04 / 검토 전문가 확인 원문 일치 · 누락 조건 평가 문항 확정 · 원본 · 모델 · 검토 상태 · 05 / 확정 평가 문항 확정 원본 · 모델 · 검토 상태 우선 활용 질문 근거 같은 근거 QA 초안 확인 완료 범례 근거 제공 근거 · 확정 문항 작성 흐름
질문 생성과 답변 작성 모두에 승인된 근거를 넣고, 전문가가 확인한 QA를 평가 문항으로 확정합니다.

Few-shot 방식은 검토한 예제를 프롬프트에 넣어 새 QA의 형태와 수준을 안내하는 데 사용할 수 있습니다. 이때는 같은 질문의 표현만 바뀐 문항과 새로운 업무 상황을 다루는 문항을 구분합니다. QA 1개를 비슷한 질문 100개로 늘려도 서로 다른 업무 100개를 검증한 것은 아닙니다.

학습용이라면 Instruction·Input·Output 형태로 정리할 수 있습니다. 다만 이것은 자료를 정리하는 한 가지 형식이고, 실제 학습에 넣을 때는 학습 대상이 요구하는 스키마에 맞춰야 합니다. 평가용 레코드에는 이 세 값 외에 정답 근거와 기대 동작이 필요합니다.

2. 평가 데이터셋에는 무엇을 담을까요

평가 문항은 “질문 하나, 정답 문장 하나”보다 조금 더 풍부해야 합니다. 질문에 어떤 자료가 필요한지 알아야 검색 실패와 생성 실패를 구분할 수 있습니다. 다음은 특정 제품의 API 형식이 아닌, 직접 관리할 수 있는 평가 레코드의 예시입니다.

{
  "case_id": "ops-night-001",
  "question": "야간에 DB 장애를 발견하면 어디에 먼저 알려야 하나요?",
  "question_type": "single_hop",
  "as_of": "2026-09-27",
  "actor_groups": ["db-oncall"],
  "expected_behavior": "answer",
  "reference_answer": "발견 후 10분 이내에 당직 채널에 등록하고 담당 DBA를 호출합니다.",
  "required_facts": [
    "발견 후 10분 이내 당직 채널 등록",
    "담당 DBA 호출"
  ],
  "evidence": [
    {
      "document_id": "db-incident-runbook",
      "document_version": "v3",
      "section": "2.1 야간 장애 접수",
      "text": "야간 DB 장애 발견자는 발견 후 10분 이내에 당직 채널에 등록하고 담당 DBA를 호출한다."
    }
  ],
  "split": "test",
  "origin": "illustrative_example"
}

이 예시의 10분과 연락 절차는 가상의 규정입니다. 실제 문항에는 원문 근거를 넣고 검토자·검토 상태·평가 데이터셋 버전도 관리합니다. actor_groups는 테스트에서 설정하는 사용자 조건이며, 서비스에서는 클라이언트가 보낸 문자열을 그대로 신뢰하지 않고 인증된 신원으로 결정해야 합니다.3

reference_answer와 required_facts, evidence는 평가기가 사용할 기준입니다. 평가 실행 때 서비스에 정답을 함께 전달하지 않습니다. 서비스에는 질문과 필요한 사용자 조건을 넣고, 실제 검색 결과·LLM에 전달한 컨텍스트·생성 답변을 별도의 실행 결과로 저장합니다. question_type에는 질문 유형을 적습니다. 예시의 single_hop은 1절에서 본 단일 근거 질문입니다. as_of는 질문의 기준일을, split은 이 문항이 3절의 어느 데이터 구분에 속하는지를 적는 필드입니다.

정답 근거는 청크 ID에만 묶지 않습니다

청크 분할 방식을 바꾸면 청크 ID와 경계가 달라질 수 있습니다. 그러므로 문서 ID·버전·절·근거 구절을 기준으로 정답을 남기고, 실행 시점의 청크가 그 근거를 포함하는지 대응시키는 방식을 제안합니다. 문서 단위 평가라면 같은 문서의 여러 청크를 중복 정답으로 세지 않는 규칙도 필요합니다.

이 방식은 평가 질문을 특정 검색기의 결과에 종속시키지 않기 위한 것입니다. Microsoft도 합성 질문 생성에 쓰는 일회성 분할과 실제 솔루션의 청크 분할을 구분하도록 안내합니다.4

현재 검색기의 Top-k에서만 근거를 고르고 질문을 역으로 만들면, 현재 검색기가 놓치는 자료는 평가 문항에도 나타나지 않을 수 있습니다. 검토한 원문에서 질문·근거를 만들고, 각 검색기가 그것을 찾아내는지 비교하는 편이 이 편향을 줄이는 데 도움이 됩니다.

질문에 필요한 근거 수와 검색할 k도 구분합니다. 청크를 여러 개 가져왔다고 모두 정답 근거인 것은 아니며, 비슷한 문단을 모았다는 것만으로 여러 근거를 연결해야 하는 질문이 만들어지는 것도 아닙니다.

답하지 않아야 하는 질문도 평가합니다

상황 평가할 기대 동작
자료에 답이 없음 근거 부족을 알리고 답을 지어내지 않음
제품·버전 등 조건이 부족함 필요한 조건을 되물음
권한이 없는 자료가 필요함 제한된 내용을 노출하지 않고 서비스 정책에 맞게 안내
문서끼리 충돌함 적용 시점·승인 상태로 판단하거나 충돌을 알림
문서에 모델을 조종하려는 지시가 있음 문서 속 지시를 실행 규칙으로 따르지 않음

답이 없는 문항에는 reference_answer: null, expected_behavior: "abstain"(답변 유보)처럼 의미를 명시할 수 있습니다. 서비스 범위에 따라 확인 질문은 clarify, 접근 제한은 deny 등으로 나눌 수 있습니다. 이름 자체보다 기대 동작과 통과 기준을 합의하는 것이 중요합니다.

외부 문서에 들어 있는 지시가 모델의 행동을 바꾸는 것은 간접 프롬프트 인젝션의 한 형태입니다. OWASP는 문서·웹페이지 등의 외부 입력과 시스템 지시를 구분하고 권한을 제한하도록 안내합니다.5 따라서 보안 문항은 최종 답변뿐 아니라, 제한된 자료가 LLM에 전달됐는지와 허용하지 않은 도구 호출이 발생했는지도 확인해야 합니다.

3. 학습·개발·최종 평가 데이터는 어떻게 나눌까요

데이터를 나누는 목적은 새 질문에 대한 성능을 평가하는 데 있습니다. 모델을 학습하지 않는 RAG라도 프롬프트, 청크 크기, 검색 파라미터를 같은 문항에 반복해서 맞추면 그 문항에 유리한 설정을 고를 수 있습니다. 최종 평가 데이터를 설정 선택에 계속 사용하지 않는다는 원칙이 필요합니다.6

구분 사용 목적 관리 방식
학습용 모델 파라미터 학습 실제 학습을 할 때 준비
개발용 프롬프트·청크·검색 설정 비교, 오류 재현 실패 사례를 추가하며 반복 사용
최종 평가용 선택한 구성의 성능 확인 조정에 쓰지 않고 별도로 보관

나누는 단위도 중요합니다. 원문 하나에서 만든 질문 20개를 무작위로 나누면, 학습·개발 쪽과 최종 평가 쪽에 사실상 같은 내용이 들어갈 수 있습니다. 같은 문서 계열이나 티켓, 거의 같은 질문에서 파생된 문항은 그룹으로 묶는 방식을 고려합니다. 그룹 구조가 있는 데이터는 그룹별로 나눠야 새로운 그룹에 대한 성능을 평가할 수 있습니다.6 앞의 그룹 묶기는 이 원칙을 RAG의 QA에 적용한 것입니다.

다만 최종 평가 질문의 근거 문서를 검색 문서 집합에서 무조건 빼라는 뜻은 아닙니다. 검색형 QA에서는 근거가 검색 대상에 있어야 정상적으로 답할 수 있습니다. 분리해야 하는 것은 평가 질문·참고 답변을 학습이나 설정 조정에 사용하는 경로입니다. 처음 보는 문서에 대한 일반화까지 평가하려면 문서 그룹도 나눕니다. 최종 평가용 문항은 학습·개발에 쓰지 않은 문서 그룹에서 만들고, 평가할 때는 그 문서를 검색할 수 있게 구성합니다.

시간에 따라 바뀌는 업무라면 질문의 기준일과 당시 사용 가능한 문서 버전도 맞춥니다. 과거 질문을 재현하면서 당시에는 없었던 후속 보고서를 근거로 제공하면 실제보다 쉬운 시험이 됩니다. 시간 순서가 있는 데이터의 평가에서 미래 정보를 섞지 않는 원칙을 문서 스냅샷에도 적용하는 것입니다.6

4. 검색과 답변을 어떻게 따로 평가할까요

최종 답변만 보면 왜 틀렸는지 알기 어렵습니다. 도입부의 야간 장애 질문처럼 답이 틀렸다면, 검색이 근거를 놓쳤는지 모델이 근거를 잘못 읽었는지부터 나눠 봐야 합니다. Amazon Bedrock도 검색만 평가하는 작업과 검색·생성을 함께 평가하는 작업을 나눕니다.7

검색 평가와 답변 평가를 나누는 구조 A data-flow diagram generated by Archify. 01 / 평가 레코드 02 / 검색 03 / 답변 생성 정답 근거 · 문서 · 버전 · 절 · 구절 · 01 / 평가 레코드 정답 근거 문서 · 버전 · 절 · 구절 질문 · 사용자 조건 · 서비스에 넣는 값 · 01 / 평가 레코드 질문 · 사용자 조건 서비스에 넣는 값 참고 답변 · 필수 사실 · 기대 동작 포함 · 01 / 평가 레코드 참고 답변 · 필수 사실 기대 동작 포함 검색 · Top-k 결과 · 02 / 검색 검색 Top-k 결과 검색 평가 · Precision@k · Recall@k · MRR · nDCG · 02 / 검색 검색 평가 Precision@k · Recall@k · MRR · nDCG 답변 생성 · LLM · 03 / 답변 생성 답변 생성 LLM 답변 평가 · 정확성 · 충실성 · 인용 · 03 / 답변 생성 답변 평가 정확성 · 충실성 · 인용 질문 컨텍스트 검색 결과 답변 · 컨텍스트 평가 전용 평가 전용 범례 실행 결과 평가기 전용 평가 기준 서비스 실행
서비스엔 질문·사용자 조건만, 정답 근거는 검색 평가에만, 참고 답변·필수 사실은 답변 평가에만 씁니다.

검색 평가: 필요한 근거를 얼마나, 어떤 순서로 찾았나요

아래는 사람이 관련성을 판정한 문서나 근거 단위를 기준으로 한 지표입니다. MRR은 Mean Reciprocal Rank, nDCG는 normalized Discounted Cumulative Gain의 약자입니다.8

지표 측정하는 것 해석할 때 확인할 사항
Precision@k 상위 k개 중 관련 결과의 비율 관련 결과의 순서는 반영하지 않음
Recall@k 전체 관련 결과 중 상위 k개에서 찾은 비율 정답 목록이 불완전하면 해석도 제한됨
MRR@k 첫 관련 결과 순위의 역수를 질문별로 평균 여러 근거를 모두 찾았는지는 알 수 없음
nDCG@k 관련성 등급과 순서를 함께 반영한 순위 품질 관련성 등급과 이상적인 순위의 정의가 필요

예를 들어 정답 근거가 A, B, C이고, 검색 순서가 X, A, Y, B, Z라면 다음과 같습니다. X, Y, Z는 관련 없는 결과라고 가정합니다.

Precision@5 = 2 / 5 = 0.40
Recall@5    = 2 / 3 ≈ 0.667
RR@5        = 1 / 2 = 0.50

마지막 값은 이 질문 하나의 reciprocal rank(RR)입니다. 여러 질문의 RR을 평균한 것이 MRR입니다. 상위 k개 안에 관련 결과가 없으면 해당 질문의 RR은 0으로 계산합니다.

이 글의 Precision@k는 분모를 k로 두고, k개를 채우지 못한 자리는 관련 결과가 없는 것으로 계산하는 규칙을 사용합니다. 도구를 사용할 때는 실제 반환 수를 분모로 쓰는지, 관련성을 판정하지 않은 결과(미판정 결과)를 제외하는지 확인해야 합니다. 정답 근거가 없는 문항의 Recall은 분모가 0이므로 일반 검색 Recall 평균에서 제외하고, 별도의 답변 유보 평가에 포함합니다.

정답 목록에 없는 검색 결과를 모두 오답으로 확정하는 것도 조심해야 합니다. 새로 찾은 문서가 실제로 유효한 근거일 수 있습니다. 미판정 결과를 구분하고 검토한 뒤 동일한 평가 데이터셋 버전으로 다시 비교하는 것이 좋습니다.8

여기서의 Recall@k와 근사 최근접 이웃(ANN) 검색의 recall@k는 기준이 다릅니다. ANN recall은 정확한 최근접 이웃 검색 결과를 얼마나 재현했는지를 보고, 업무 검색 Recall은 사람이 관련 있다고 판정한 근거를 얼마나 찾았는지를 봅니다. 가까운 벡터를 잘 찾는 것과 업무상 필요한 문서를 잘 찾는 것은 구분해야 합니다.9

Context 지표는 이름보다 정의를 확인합니다

Ragas의 LLM 기반 Context Recall은 참고 답변의 주장 가운데 검색한 컨텍스트로 뒷받침되는 비율을 봅니다. 같은 문서의 ID를 찾았다는 것과 필요한 내용을 실제로 포함했다는 것은 다르므로, ID 기반 Recall과 구분해서 읽어야 합니다.10

Ragas의 순위 기반 Context Precision도 앞의 단순한 Precision@k와 다릅니다. 관련 청크가 나타난 각 순위까지의 precision을 이용하므로 순서가 점수에 영향을 줍니다. Ragas의 ID 기반 구현은 반환한 ID 가운데 관련 ID가 차지하는 비율을 사용합니다. 결과표에는 지표 이름과 함께 구현·입력·버전을 남기는 것이 좋습니다.11

답변 평가: 근거를 바르게 사용했나요

답변은 다음 항목을 나눠 확인할 수 있습니다. Bedrock의 평가 지표 역시 정확성·완전성·근거 충실성·인용을 구분합니다.7

항목 확인할 내용
정확성(correctness) 질문의 조건과 업무상 정답에 맞는가
완전성(completeness) 질문이 요구한 필수 사실과 예외를 빠뜨리지 않았는가
근거 충실성(faithfulness) 답변의 주장이 제공된 근거로 뒷받침되는가
인용 정확성 인용한 구절이 연결된 주장을 실제로 뒷받침하는가
인용 범위 근거가 필요한 주장에 인용이 빠지지 않았는가
기대 동작 준수 답변·확인 질문·유보·접근 제한을 상황에 맞게 수행했는가

예를 들어 구버전 지침에 “30분 이내 보고”라고 쓰여 있고 모델이 그대로 답했다면, 제공된 컨텍스트에는 충실할 수 있습니다. 하지만 현재 승인된 지침이 “10분 이내 보고”라면 업무상으로는 틀린 답입니다. 근거 충실성 점수가 높아도 원천 자료의 최신성이나 사실성을 보증하지는 않습니다. Ragas의 정의도 답변과 제공된 컨텍스트 사이의 일관성을 측정합니다.12

LLM 채점도 검증 대상입니다

LLM-as-a-judge는 많은 답변을 평가하는 데 사용할 수 있지만, 채점 모델의 판정이 곧 정답은 아닙니다. MT-Bench 연구는 답변 순서, 장황함, 자기 답변 선호 등의 편향을 다룹니다. 이 연구의 결과를 특정 한국어 업무 RAG의 채점 정확도로 그대로 적용할 수는 없습니다.13

사람이 판정한 일부 문항으로 채점 기준을 점검하고, 사람과 모델의 판단이 다른 사례를 검토하는 방법을 권합니다. 문서 ID·권한·출력 형식처럼 명확한 조건은 규칙으로 확인하고, 의미 판단이 필요한 부분에 LLM 평가를 사용합니다. 같은 모델로 QA를 만들고 답변하고 채점한 점수만으로 품질을 확정하지 않습니다.

5. 작은 평가 데이터셋으로 시작해 어떻게 운영할까요

평가는 개발이 끝난 뒤로 미루지 않는 편이 좋습니다. 초기의 작은 평가 데이터셋으로 문제를 찾으면서 테스트·이행 단계로 갈수록 범위를 넓혀 가는 방식입니다. 초기 문항 수를 일률적으로 정하기보다는 지원할 업무와 문서 유형을 얼마나 포함했는지 확인합니다.

이 원칙을 적용한 작업 순서는 다음과 같습니다.

단계 할 일 남길 결과
분석·설계 업무와 데이터 유형별 대표 자료·질문을 함께 선정 범위 조사표, 요건, 초기 평가 문항
개발 단순한 검색 구성을 기준으로 분할·임베딩·검색 설정 비교 개발용 평가 결과, 오류 분류
테스트·이행 고정된 최종 평가 데이터셋으로 품질·부하·권한·개정 반영 확인 통과 여부와 실패 문항, 실행 설정
운영 실제 질문과 실패 사례를 검토해 다음 평가 데이터셋에 반영 회귀 사례, 새 평가 데이터셋 버전, 변경 이력

평균 점수와 함께 질문 유형별 점수와 표본 수를 봅니다. 예를 들어 100문항 중 90문항이 통과했어도, 실패한 10문항이 모두 권한 제한이나 문서 개정에 관한 질문이면 통과율 90%만으로 합격으로 보기 어렵습니다. 일반 질문의 품질 목표와 별개로 권한 위반처럼 허용하지 않을 실패 조건을 정해야 합니다.

실패한 문항은 데이터 경로를 따라 확인합니다

아래는 문서 추출, 검색, 컨텍스트 구성, 답변 생성 순서로 데이터 경로를 따라가는 진단표입니다. 관찰한 현상에서 먼저 확인할 지점을 정하는 용도이며, 원인을 하나로 단정하는 표는 아닙니다.

관찰한 현상 먼저 확인할 지점
원문에는 답이 있지만 추출한 텍스트에는 없음 파서·OCR·표·각주 처리
추출한 텍스트에는 있지만 검색 결과에는 없음 청크 분할·질문 표현·임베딩·필터·검색 파라미터
검색했지만 LLM에 전달한 컨텍스트에는 없음 재순위화·중복 제거·토큰 예산
필요한 근거를 전달했는데 답변이 틀림 프롬프트·모델의 해석·상충하는 근거
답변은 맞는데 출처가 엉뚱함 문서·청크·인용 구절의 연결
개정·삭제된 문서가 계속 나옴 동기화·버전 필터·캐시 무효화

비교 실행에는 문서 스냅샷, 파서·청크 설정, 임베딩·재순위화·생성 모델, 검색 설정, 프롬프트와 평가 데이터셋·평가기의 버전을 남깁니다. 검색 결과와 실제 전달한 컨텍스트도 기록해야, 같은 질문에서 결과가 달라졌을 때 어느 단계가 바뀌었는지 확인할 수 있습니다.

문서 갱신은 적재 완료 표시만 보고 끝내지 않습니다. 실제 질의에서 새 내용이 검색되고, 삭제된 내용이 사라지는지 확인합니다. 예를 들어 Bedrock Knowledge Bases는 원천 자료의 추가·수정·삭제 뒤 동기화가 필요하며, 저장소에 따라 동기화 완료와 검색 가능 시점 사이에 지연이 생길 수 있다고 안내합니다.14

권한 변경도 별도로 검증해야 합니다. 인덱스에 저장한 권한 정보를 이용한다면 원천 권한이 바뀌어도 동기화 전에는 이전 값으로 판단할 수 있습니다. Azure AI Search의 권한 문서도 이 동기화 경계를 명시합니다.3 긴급한 접근 철회가 필요한 서비스라면 검색 시 현재 권한을 다시 확인하는 등 서비스 요구에 맞는 보완 방법을 정합니다.

정리

평가 데이터셋은 질문과 정답 문장만으로 끝나지 않고, 정답 근거와 기대 동작을 함께 담습니다. 질문에 필요한 근거를 알아야 검색 실패와 생성 실패를 나눠서 확인할 수 있고, 최종 평가 문항을 설정 조정에 쓰지 않아야 새 질문에 대한 성능을 잴 수 있습니다.

처음에는 대표 질문과 정답 근거가 연결된 작은 평가 데이터셋으로 시작할 수 있습니다. 그 평가 데이터셋으로 문서 추출, 검색, 컨텍스트 구성, 답변 생성을 차례로 확인하면 다음에 고칠 지점이 드러납니다. 문항 수를 늘릴 때도 같은 질문을 반복하기보다, 새로운 업무 유형과 실제 실패 사례를 추가하는 것이 좋습니다.

참고 자료

  1. AWS — What is Retrieval-Augmented Generation?. 외부 자료 검색과 프롬프트 보강, 모델 재학습 없이 구성하는 RAG의 역할. ↩

  2. Ragas — Testset Generation for RAG. 단일·복수 근거 질문, 구체·추상 질문과 시나리오 기반 생성. ↩

  3. Microsoft — Document-Level Access Control. 호출자 신원에 따른 검색 제한, 청크 권한 메타데이터, 원천 권한 변경과 인덱스 동기화의 경계. ↩ ↩2

  4. Microsoft — Develop a RAG Solution: Preparation Phase. 문서 유형·구조·권한 분석, 질문·근거·답변의 연결, 독립적인 합성 질문 생성과 전문가 검토. ↩

  5. OWASP — LLM Prompt Injection Prevention Cheat Sheet. 외부 문서를 통한 간접 인젝션, 지시와 데이터의 분리, 최소 권한과 도구 호출 검증. ↩

  6. scikit-learn — Cross-Validation: Evaluating Estimator Performance. 개발·최종 평가 분리, 그룹·시간 기반 평가. 본문의 문서 계열·티켓·문서 스냅샷 사례는 이 원칙을 RAG에 적용한 제안. ↩ ↩2 ↩3

  7. Amazon Bedrock — Use Metrics to Understand RAG System Performance. 검색·검색+생성 평가의 구분, 정확성·완전성·충실성·인용 지표. ↩ ↩2

  8. Elasticsearch — Ranking Evaluation, Manning·Raghavan·Schütze — Evaluation of Ranked Retrieval Results. Precision@k, Recall@k, MRR, DCG·nDCG와 관련성 판정, 미판정 결과 처리. ↩ ↩2

  9. Sentence Transformers — Semantic Search. 질문·문서의 벡터 공간, 대칭·비대칭 검색, 인코딩 경로, ANN의 recall·속도 절충. ↩

  10. Ragas — Context Recall. 참고 답변의 주장 기반 평가와 ID 기반 평가의 차이. ↩

  11. Ragas — Context Precision. 순위를 반영하는 구현과 ID 기반 비율의 차이. ↩

  12. Ragas — Faithfulness. 생성 답변의 주장이 제공된 컨텍스트로 뒷받침되는지를 평가하는 정의. ↩

  13. Zheng 외 — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023. LLM 평가자의 순서·장황함·자기 선호 편향과 평가 한계. ↩

  14. Amazon Bedrock — Sync Your Data with Your Knowledge Base. 문서 추가·수정·삭제의 증분 동기화와 검색 반영 시점. ↩

Advertisement
Comments