본문 바로가기
C.W.K.
Stream
Lesson 04 of 05 · published

RAG가 알맞지 않을 때

~18 min · rag, design, tradeoffs

Level 0Scout
0 XP0/41 lessons0/10 achievements
0/120 XP to next level120 XP to go0% complete

RAG가 오히려 해가 되는 경우

RAG는 비공개 데이터로 LLM 앱을 만들 때 대체로 좋은 기본 선택이지만, 다음 상황에는 알맞지 않아.

  • 코퍼스 전체가 문맥 창에 들어가. 지식 베이스가 50페이지라면 그냥 모두 넣어. 검색 시스템을 만드는 건 낭비일 수 있어.
  • 질문이 전체 코퍼스에 대한 구조화 계산을 요구해. '준법을 언급한 문서가 몇 개인가?'는 SQL 쿼리로 풀 문제지 벡터 검색 문제가 아니야.
  • 사용자가 조회가 아니라 변환을 원해. '이걸 번역해 줘'나 '이걸 요약해 줘'는 입력이 이미 있으므로 검색이 필요 없어.
  • 지연 시간이 가장 중요한 제약이야. 검색 호출마다 50–500ms가 더해질 수 있어. 자동 완성 같은 화면에는 너무 느릴 수 있어.
  • 데이터가 재임베딩보다 빨리 바뀌어. 실시간 거래 데이터나 센서 스트림은 모델에 직접 넣고 임베딩하려 들지 마.

긴 문맥과 RAG 사이의 선택

문맥 창이 200K–1M토큰으로 늘어나면 경계도 달라져. 약 150K토큰보다 작은 코퍼스는 전체 지식 베이스를 문맥에 넣는 편이 RAG보다 종합을 잘하고 검색 누락도 없을 수 있어. 대신 호출당 비용은 더 커져. 보편적인 답은 없으니 직접 가진 데이터로 측정해.

Code

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

External links

Exercise

팀이 만들고 있거나 검토 중인 앱을 나열하고 각각에 위의 결정 기준을 적용해. RAG가 과하거나 알맞지 않은 앱을 표시해 봐. 벡터 저장소가 정말 필요 없는 경우가 절반 가까이 나올 수도 있어.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.