RAG의 첫 문제는 검색이야
RAG는 흔히 “모델이 내 자료를 읽게 해준다”라고 소개돼서 마법처럼 들려. 실제로는 LLM 앞에 검색 절차를 붙인 구조야. 질문과 관련된 청크를 찾고, 프롬프트에 담은 뒤, 모델에게 그 청크만 근거로 답하게 하지. 검색이 쓰레기를 가져오면 모델은 인용까지 단 잘 쓴 쓰레기를 만들어. 병목은 거의 언제나 LLM이 아니라 검색 품질이야.
RAG를 이루는 다섯 조각
- 청크 나누기 — 문서를 어떤 단위로 자를지 정해.
- 임베딩 — 각 청크를 벡터로 바꿔.
- 색인 — FAISS, Chroma, Postgres pgvector, 전용 벡터 DB처럼 벡터를 보관할 곳이야.
- 검색 — 질문으로 상위 K개 청크를 찾아. 밀집 검색과 BM25를 섞기도 해.
- 종합 — 찾은 청크를 LLM 호출로 답변으로 엮어.
RAG가 흔히 무너지는 자리
- 청크가 너무 커서 답은 들어 있지만 무관한 내용에 파묻혀.
- 청크가 너무 작아서 핵심 주장과 그 근거가 갈라지고 낱말만 맞아.
- Top-K를 근거 없이 5로 고정해. 어떤 질문에는 50이 필요하고 어떤 질문에는 1이면 충분해.
- 첫 검색 결과를 더 정밀하게 재순위화하지 않아.
- 종합 프롬프트가 제공된 청크만 인용하도록 강제하지 않아.
조정하기 전에 고장 난 층부터 찾아
답이 틀렸다면 먼저 알맞은 청크가 검색됐는지 봐. 맞는 청크가 있었다면 종합 프롬프트를 고치고, 없었다면 검색을 고쳐야 해. 검색이 망가진 채 LLM 호출만 만지는 건 낭비야.