인공지능/논문 리뷰 or 진행

DoGe 관련 논문 조사 6 - Synthetic QA Data, SELF-ROUTE

이게될까 2025. 7. 8. 15:28
728x90
728x90

https://arxiv.org/abs/2002.09599

 

Training Question Answering Models From Synthetic Data

Question and answer generation is a data augmentation method that aims to improve question answering (QA) models given the limited amount of human labeled data. However, a considerable gap remains between synthetic and human-generated question-answer pairs

arxiv.org

이 것도 다른 내용의 논문이라...

QA 학습 데이터를 만드는 내용이네요

 

문제 상황 고성능 QA 모델 학습에는 대량의 정답이 달린 질문 데이터가 필요하지만, 인간 주석 데이터는 비용이 크고 양이 부족함.
연구 목적 인간 주석 없이도 QA 모델을 고성능으로 학습할 수 있도록, 전적으로 생성된 합성 데이터만을 사용하여 SQuAD 성능을 넘는 방법 제안.
방법론 개요 대형 언어 모델(GPT-2, BERT 등)을 활용하여 다음과 같은 3단계 파이프라인을 구성함:
1. Answer Generation: BERT 기반 모델로 문장에서 정답 후보(span) 생성
2. Question Generation: GPT-2 기반 모델로 정답과 문맥을 기반으로 질문 생성
3. Roundtrip Filtration: QA 모델로 질문을 다시 풀어 원래 정답과 일치하면 유효한 QA쌍으로 간주
데이터 소스 - 실제 Wikipedia
- 완전 합성된 Wikipedia-like 문서 (8.3B GPT-2로 생성)
실험 세팅 - BERT-345M 모델을 QA 모델로 사용
- 합성 데이터만 사용하여 학습한 후, SQuAD1.1/2.0 Dev set에서 평가
- 모델 크기(117M~8.3B), 질문/정답 생성 방법, 필터링 전략 등에 대해 ablation 진행
주요 결과 - 합성 데이터만으로 SQuAD1.1 Dev Set에서 88.4 EM / 94.1 F1실제 데이터 학습보다 우수한 성능
- 합성 Wikipedia 텍스트 기반 QA 데이터로도 88.4 EM / 93.9 F1 달성
- 이후 실제 SQuAD 데이터로 파인튜닝 시 89.4 EM / 95.2 F1까지 증가
- SQuAD2.0에서도 이전 합성 QA 방법보다 2.8 EM 상승
기여 ✅ 합성 데이터만으로 인간 수준의 QA 모델 훈련 가능성 입증
✅ 모델 크기 및 pretraining이 성능에 미치는 영향 정량화
✅ overgeneration & filtration 기법으로 낮은 precision 문제 완화
한계 - paragraph-level 정답 추출에서 성능 저하
- Roundtrip filtering은 valid한 QA쌍도 일부 버림 (recall 감소)
- 정답 추출 성능이 전체 성능의 병목임

 

https://arxiv.org/abs/2407.16833

 

Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach

Retrieval Augmented Generation (RAG) has been a powerful tool for Large Language Models (LLMs) to efficiently process overly lengthy contexts. However, recent LLMs like Gemini-1.5 and GPT-4 show exceptional capabilities to understand long contexts directly

arxiv.org

RAG는 LLM이 Long-Context를 처리할 수 없을 때 효율적이었지 지금과 같이 100k ~ 1M 까지 토큰이 가능할 때는 비효율적이다.

-> RAG한 Context를 주고, 이거 풀 수 있는지 라우팅을 시켜서 못 푼다고 하면 Context를 통째로 주는 방법이네요 

Cost도 저감되고, 성능도 지키는 것을 볼 수 있습니다.

Gemini가 성능이 좋은 건 받을 수 있는 Context 길이가 엄청 길고 여기서 LC라고 해봤자 그렇게 길지 않을 것이기 때문일 것 같네요 ㅎㅎ..

 

문제 상황 기존 RAG는 긴 문맥을 LLM이 처리할 수 없을 때 효율적이었지만, 최근 LLM (예: GPT-4, Gemini-1.5)이 수십만~백만 토큰의 문맥을 직접 처리할 수 있게 되며, RAG vs Long-Context LLM (LC)의 성능 및 비용을 비교할 필요가 생김.
주요 질문 1. 최신 LLM에서는 RAG보다 LC가 더 좋은가?
2. 성능과 비용 측면에서 어떤 전략이 최적인가?
3. 둘을 혼합하면 장점만 취할 수 있을까?
방법론 - LC vs RAG 정량 비교 실험 (LongBench, ∞Bench, 3개 LLM)
- SELF-ROUTE 제안: LLM이 스스로 해당 질문이 RAG로 가능한지 판단하여 RAG 또는 LC로 분기
→ “unanswerable”이라고 판단되면 LC 사용
실험 세팅 - 모델: Gemini-1.5-Pro, GPT-4O, GPT-3.5-Turbo
- 리트리버: Contriever, Dragon
- 데이터셋: NarrativeQA, Qasper, MultiFieldQA, HotpotQA, 2Wiki, MuSiQue, QMSum, En.QA, En.MC
- 평가 지표: F1, Accuracy, ROUGE 등
주요 결과 - LC가 전반적으로 성능 우위 (최대 +13.1%)
- RAG는 비용 효율성이 뛰어남 (토큰 수 기준 30~60% 절감)
- SELF-ROUTE는 LC와 유사한 성능을 달성하면서 비용은 RAG에 가깝게 절감
SELF-ROUTE 세부 결과 - Gemini-1.5-Pro 기준 평균 토큰 사용량: 38.6%
- LC 대비 성능 손실 거의 없음 (-2.2%)
- GPT-3.5에서는 LC보다 오히려 성능 ↑
RAG 실패 원인 분석 1. 멀티스텝 추론 필요
2. 질문이 일반적/모호함
3. 질문이 길고 복잡
4. 질문이 문맥 전체 이해 필요
→ RAG는 단편적 추출에 강하나, 복잡한 문맥 연계에는 약함
추가 분석 - k (top-k chunks) 증가시 성능 ↑, 비용 ↑ → sweet spot은 보통 k=5
- 합성 데이터셋 (PassKey)에서는 문제 설정의 민감성 주의 필요
기여 ✅ 최신 LLM에 기반한 RAG vs LC의 체계적 비교
SELF-ROUTE라는 실용적 하이브리드 방식 제안
비용-성능 트레이드오프에 대한 실증적 가이드 제공
한계 - 데이터셋 누출 문제 완전히 해결되지 않음
- "based only on passage" 프롬프트로 제한했지만 모델 내부 지식 배제 한계 존재
- SELF-ROUTE는 "answerable 판단" 성능에 의존

 

728x90