RAG 가 잘못된 답일 때

RAG 가 해치는 경우

RAG 는 사적 데이터 위 LLM 앱 대부분의 옳은 default. 잘못된 도구일 때:

코퍼스가 context window 에 들어감. KB 가 50 페이지면 그냥 stuff. retrieval 빌드는 낭비된 노력.
질문이 전체 코퍼스 위 구조화 추론 요구. '우리 문서 중 compliance 언급한 게 몇 개?' 는 SQL query, 벡터 검색 아냐.
유저가 lookup 아니라 변환 원함. '이거 번역해' 또는 '이거 요약해' 는 retrieval 안 필요 — 입력 이미 있어.
Latency 가 killer 제약. 각 retrieval 호출이 50–500ms 추가. 자동완성 스타일 UX 면 너무 많음.
데이터가 재임베딩보다 빠르게 update. Live trading 데이터, 센서 stream — 모델에 직접 push, 임베딩 시도하지 마.

긴 context vs RAG

200K-1M 토큰 context window 면 line 이 움직여. ~150K 토큰 미만 코퍼스에는 전체 KB 를 context 에 stuff 하는 게 RAG outperform 가능 (더 좋은 종합, retrieval miss 없음) — 호출당 비용 더 높음. 본인 데이터로 측정 — universal 답 없어.

Code

결정 sketch·text

코퍼스 ≤ 50 문서?              → context 에 stuff, retrieval skip
질문이 구조화?                  → SQL 또는 필터, 벡터 검색 아님
질문이 변환?                    → retrieval 불필요
Latency budget < 100ms?         → retrieval 너무 느림
데이터가 임베딩 파이프라인보다 빠르게 update? → 직접 주입
그 외                           → RAG

RAG 가 잘못된 답일 때

RAG 가 해치는 경우

긴 context vs RAG

Code

External links

Exercise

Progress

댓글 0