RAG는 마법풀이 아니야

RAG는 일단 search 문제

RAG는 종종 "모델이 너의 데이터 읽을 수 있어"로 묘사돼서 마법처럼 들려. LLM 위에 search 문제를 bolt on한 거야: relevant chunk retrieve, 프롬프트에 패킹, 모델한테 그 chunk만 써서 답하라고 요청. retrieval이 쓰레기 가져오면 모델이 citation 박힌 잘 쓰인 쓰레기를 만들어. bottleneck은 거의 항상 retrieval quality, LLM 아니야.

다섯 조각

Chunking — 문서 어떻게 split.
Embedding — chunk가 vector 되는 법.
Index — vector 사는 곳 (FAISS, Chroma, Postgres pgvector, dedicated DB).
Retrieval — query → top-K chunk. 종종 hybrid (dense + BM25).
Synthesis — chunk를 답으로 바꾸는 LLM call.

대부분 RAG 시스템이 실패하는 곳

Chunk가 너무 큼 (LLM이 답 받지만 chunk가 무관 content로 가득).
Chunk가 너무 작음 (retrieval이 둘러싼 argument 놓치는 keyword match).
Top-K가 무작정 (default 5, 가끔 50이 도움, 가끔 1이 정답).
초기 retrieval 후 reranking 없음.
Synthesis 프롬프트가 제공된 chunk만 citation 강요 안 함.

tuning 전에 진단

output 틀리면 체크: 맞는 chunk가 retrieve됐나? Yes면 synthesis 프롬프트 fix. No면 retrieval fix. retrieval 깨진 채로 LLM call tuning은 낭비.

Code

grounded 답 강요하는 synthesis 프롬프트·markdown

# System
Answer the user's question using only the chunks in <context>.
For each factual claim, cite the chunk id in square brackets, e.g. [chunk-7].
If no chunk supports the claim, prepend "Unverified:" to that sentence.
If the question cannot be answered from <context>, return:
  {"status": "insufficient_context", "missing": ["<topic>", ...]}

# User
Question: {{question}}

<context>
[chunk-1] ...
[chunk-2] ...
...
</context>

RAG는 마법풀이 아니야

RAG는 일단 search 문제

다섯 조각

대부분 RAG 시스템이 실패하는 곳

tuning 전에 진단

Code

External links

Exercise

Progress

댓글 0