RAFT는 검색 결과가 늘 정확하다고 가정하지 않고, 정답 문서와 그럴듯한 방해 문서를 함께 보여 주며 필요한 근거를 골라 답하도록 파인튜닝하는 방법입니다.
RAFT는 검색 결과를 더 잘 만드는 retriever가 아니라 검색된 문서 중 어떤 근거를 써야 하는지 reader를 훈련하는 방법입니다. 따라서 Oracle 문서가 없는 검색 실패와 Oracle이 있어도 Distractor에 끌리는 읽기 실패를 분리해야 합니다.
RAG가 엉뚱한 문서를 찾는다면? RAFT의 Distractor 학습법
일반 RAG가 놓치는 것은 검색 뒤의 선택이다
RAG는 외부 문서를 검색해 최신 또는 도메인 지식을 답변에 넣을 수 있지만, 검색 상위 문서가 모두 질문에 유용한 것은 아닙니다. 키워드가 비슷할 뿐 정답을 포함하지 않은 문서가 섞이면 모델은 어느 근거를 써야 할지 다시 판단해야 합니다.
도메인 파인튜닝만 하면 학습 데이터의 지식은 익힐 수 있어도, 실제 RAG 입력처럼 여러 문서 중 하나를 고르는 상황을 충분히 연습하지 못합니다. RAFT는 이 간극을 “오픈북 시험에 맞춘 연습”으로 봅니다. 모델에게 답만 외우게 하는 대신, 정답 문서와 Distractor를 함께 읽는 형식 자체를 학습시킵니다.
Oracle 문서와 Distractor를 한 세트로 만든다
논문의 데이터 구성은 질문 Q, 정답 근거를 담은 Oracle 문서 D, 정답과 무관한 문서 D1부터 Dk, 정답 A로 요약할 수 있습니다.
- 일부 학습 예에는 D*와 여러 Distractor를 함께 넣습니다.
- 나머지 예에는 D*가 빠진 문서 묶음을 넣어 검색 근거가 없을 때의 상황도 노출합니다.
- 답변에는 결론뿐 아니라 사용한 문서의 구절과 결론까지의 추론을 담습니다.
중요한 설계 변수는 Oracle 문서를 포함하는 비율 P와 Distractor의 난이도입니다. 너무 쉽게 구분되는 방해 문서만 넣으면 실제 검색 오류를 견디는 능력을 시험하기 어렵고, 정답 문서가 항상 있다고 가정하면 검색 실패 상황과 달라집니다.
근거 인용은 검증 단서이지 정답 보증이 아니다
HotpotQA 예시에서 모델은 영화 Evolution의 각본가를 묻는 질문에 대해 관련 문서 구절을 집어낸 뒤 David Weissman이라는 답을 도출합니다. 이런 Chain-of-Thought 형식은 모델이 어떤 문서를 사용했는지 살펴볼 단서를 줍니다.
하지만 인용 형식이 있다고 해서 그 구절이 질문을 실제로 뒷받침한다는 보장은 없습니다. RAFT를 적용할 때는 최종 답의 정확도뿐 아니라 선택한 문서가 Oracle인지, Distractor를 근거로 잘못 인용하지 않았는지, 답에 필요한 여러 근거를 빠뜨리지 않았는지를 따로 평가해야 합니다.
성능표는 데이터셋별 기준선과 함께 읽는다
논문에 정리된 결과는 데이터셋에 따라 차이가 큽니다.
| 모델 | PubMed | HotPotQA | HuggingFace | Torch Hub | TensorFlow Hub |
|---|---|---|---|---|---|
| GPT-3.5 + RAG | 71.6 | 41.5 | 29.08 | 60.21 | 65.59 |
| LLaMA2-7B + RAG | 58.8 | 0.03 | 26.43 | 8.60 | 43.06 |
| DSF + RAG | 71.6 | 4.41 | 42.59 | 82.80 | 60.29 |
| RAFT (LLaMA2-7B) | 73.3 | 35.28 | 74.00 | 84.95 | 86.86 |
RAFT는 PubMed와 세 가지 API 문서 데이터셋에서 표의 다른 LLaMA2 또는 DSF 기준선보다 높지만, HotPotQA에서는 GPT-3.5 + RAG의 41.5보다 낮은 35.28입니다. 특정 기준선과의 차이만 골라 모든 환경에서 우월하다고 결론 내리면 안 됩니다.
RAFT가 특히 맞는 경우는 도메인 문서 집합과 대표 질문을 확보했고, 실제 검색기가 가져올 법한 Distractor까지 훈련 데이터로 구성할 수 있을 때입니다. 검색 품질이 바뀌거나 문서가 자주 교체되는 환경이라면 Retriever 평가와 학습 데이터 갱신도 함께 필요합니다. RAFT는 검색기를 없애는 방법이 아니라, 불완전한 검색 결과를 읽는 모델을 그 환경에 적응시키는 방법입니다.
학습 한 건을 어떻게 구성하는가
도메인 질문 하나에 정답을 뒷받침하는 Oracle 문서와 주제가 비슷하지만 답은 주지 않는 Distractor를 함께 넣습니다. 출력은 결론만 쓰기보다 어느 문장의 근거를 사용했는지 드러내는 형태로 만듭니다. 예를 들어 API의 특정 option을 묻는다면 같은 library의 다른 version 문서나 비슷한 함수 설명이 현실적인 Distractor가 될 수 있습니다.
너무 무관한 문서를 넣으면 모델은 키워드만으로 쉽게 제외해 실제 검색 환경을 배우지 못합니다. 반대로 정답과 모순되는 문서를 무작정 넣으면 질문보다 출처 우선순위를 암기할 수 있습니다. 실제 retriever가 상위에 가져오는 오답 문서를 수집하고, 왜 그 문서가 그럴듯한지 기록해야 훈련과 운영 분포가 가까워집니다.
Oracle이 항상 포함된 데이터만 학습하면 실제 검색에서 정답 문서가 없을 때도 억지로 답할 수 있습니다. 일부 예제에는 답할 근거가 없다는 상태를 넣고, 모델이 부족한 근거를 명시하도록 평가해야 합니다. “모른다”를 허용하지 않으면 근거 인용 형식이 오히려 환각을 더 설득력 있게 만들 수 있습니다.
검색기와 Reader를 따로 평가한다
첫 단계는 recall입니다. 정답 문서가 top-k 안에 들어오는 비율을 측정합니다. 두 번째는 선택입니다. Oracle과 Distractor가 함께 있을 때 올바른 문장을 고르는지 봅니다. 세 번째는 답변입니다. 선택한 근거로 결론을 정확히 만들고 인용 위치가 실제 문장과 일치하는지 검사합니다.
이 세 지표를 합치면 오류 원인을 잃습니다. retriever recall이 낮으면 RAFT reader를 더 학습해도 정답을 볼 수 없습니다. recall은 높지만 선택이 낮다면 Distractor 구성과 reader 학습을 고쳐야 합니다. 선택은 맞는데 답이 틀리면 답변 형식이나 추론 문제가 남은 것입니다.
문서가 갱신되는 서비스에서는 version과 유효 날짜도 중요합니다. 오래된 문서가 키워드 일치 때문에 상위에 오르면 훈련 당시에는 정답이었던 근거가 현재는 Distractor가 됩니다. index 갱신과 evaluation set의 version을 함께 관리해야 합니다.
RAFT 도입을 판단하는 실험
기본 RAG, domain SFT, RAFT를 같은 retriever와 질문 세트에서 비교합니다. 정확도뿐 아니라 잘못 인용한 답, 근거 없음인데 답한 비율, 인용을 사람이 확인하는 시간을 기록합니다. top-k와 Distractor 수를 바꿔도 성능이 유지되는지 보면 특정 문서 수에 과적합했는지 알 수 있습니다.
RAFT가 적합한 환경은 문서 집합이 비교적 명확하고 대표 질문과 실패 검색 결과를 모을 수 있는 경우입니다. 공개 웹처럼 출처와 내용이 계속 바뀌는 환경에서는 학습 데이터 유지 비용이 커질 수 있습니다. 검색기의 품질, reader의 선택 능력, 문서 갱신 절차를 함께 운영할 수 있을 때 비로소 근거 선택 학습의 이점이 남습니다.
함께 읽으면 이해가 이어지는 글
- PageIndex는 벡터 DB 없이 긴 문서를 잘 찾을까: 트리 검색 검증법 — PageIndex가 문서의 목차와 섹션을 트리로 만들고 LLM으로 탐색하는 원리, 벡터 검색과의 비용, 정확도 비교 및 설치 예시를 정리합니다.
- 민감한 문서를 NotebookLM에 올리기 어렵다면? Open Notebook 점검표 — Open Notebook의 문서 Q&A, 요약, 다중 화자 오디오 기능을 살펴보고 로컬 LLM을 써도 외부 전송이 남을 수 있는 지점과 설치 전 확인 사항을 정리합니다.
- Firecrawl: 웹사이트를 LLM 전용 마크다운 데이터로 변환하는 오픈소스 웹 스크래퍼 — Firecrawl은 복잡한 동적 웹사이트, PDF, 문서를 AI 모델이 바로 소비할 수 있는 깨끗한 마크다운과 구조화된 JSON 데이터로 변환해주는 오픈소스 웹 데이터 API입니다. JavaScript 렌더링, 프록시 순환, 노이즈…
잘못된 인용을 모으는 Error Set
정답 문서를 인용했지만 문장 뜻을 반대로 해석한 경우, 오래된 version을 사용한 경우, 여러 문서의 조건을 섞은 경우, 인용 위치에 실제 근거가 없는 경우를 따로 저장합니다. 새 학습 뒤에는 전체 정확도뿐 아니라 이 네 오류가 줄었는지 봅니다.
질문이 모호하면 검색과 답변 전에 필요한 version, 환경을 되묻게 할 수 있습니다. 잘못 정한 전제로 문서를 많이 읽는 것보다 짧은 확인 질문이 비용과 환각을 줄일 수 있습니다. RAFT reader에도 근거가 부족하거나 질문 조건이 빠진 상태를 판별하는 예제를 포함해야 합니다.
평가 질문에는 정답이 문서 한 곳에 있는 경우와 여러 문서를 결합해야 하는 경우를 나눠 넣습니다. 후자는 각 조건의 출처를 따로 인용하게 해야 어느 문서에서 오류가 시작됐는지 확인할 수 있습니다. 문서 간 모순을 발견했을 때 임의로 하나를 고르지 않고 차이를 보고하는지도 봅니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.