다들 RAG가 쉽다고 하지만, 실전은 그냥 고장 난 검색 파이프라인 뒤치다꺼리하는 수준임
nobody tells you that RAG in production is mostly just babysitting a broken retrieval pipeline
핵심 요약
RAG 튜토리얼은 쉽지만, 실전에서는 검색 파이프라인의 고질적인 문제들 때문에 고생한다는 현실적인 고찰.
- 검색 파이프라인 — 튜토리얼과 달리 실전에서는 검색 단계에서 모든 문제가 발생함
- 의미론적 검색의 한계 — 벡터 검색이 버전 번호 같은 구체적인 차이를 구분하지 못해 엉뚱한 문서를 가져옴
- 청킹 전략의 부작용 — 고정 크기 청킹이 문장을 잘라먹어 LLM이 잘못된 정보를 생성하게 만듦
- 인덱스 관리 — 문서 업데이트 시 재인덱싱을 놓치면 잘못된 정보가 계속 제공됨
모든 튜토리얼은 문서를 임베딩하고 쿼리하면 끝이라고 말함. 3일 만에 뭔가 "작동하는" 걸 만들고는 내가 다 이해했다고 착각했음.
그러다 글을 쓰려고 더 깊이 파고들었는데, 표면 아래에서 얼마나 많은 게 조용히 고장 나 있었는지 깨달음.
검색 단계가 모든 게 죽는 지점임. 모델도 아니고, 프롬프트도 아님. 모든 튜토리얼이 "직관적"이라며 건너뛰는 바로 그 부분임.
LLM이 환각을 일으킨다고 생각하며 너무 많은 시간을 허비했음. 아니었음. 잘못된 문서를 기반으로 정확하게 답변하고 있었던 거임. 벡터 검색이 버전 번호가 뭔지 모른다는 사실을 간과하고 계속 모델 탓만 했음. 의미론적으로 가깝다고 해서 정답은 아님. 임베딩 모델한테는 "v2.3 릴리스 노트"와 "v1.8 릴리스 노트"가 거의 똑같아 보이니까.
청킹도 문제임. 고정 크기 청킹은 문장을 반으로 잘라버리고, 그중 절반만 검색해오면 모델은 자신 있게 생각을 완성해버림. 이게 바로 RAG로 해결하려던 문제인데, 정작 내 솔루션 안에서 벌어지고 있음.
인덱스 방치도 문제임. 문서를 업데이트하고 재인덱싱을 까먹으면, 누군가 알아차릴 때까지 사용자들은 자신 있게 틀린 답변을 받게 됨. 어려운 문제도 아닌데, 아무도 이게 존재한다는 언급조차 안 함.
이제 여러 프로젝트를 거치며 이 파이프라인을 몇 번이나 겪어봤음. 튜토리얼마다 각기 다른 20%만 해결해 줄 뿐임.
다들 이 시스템이 안정적이라고 느끼는 단계에 도달했음? 아니면 그냥 영원히 불타고 있는 거임?
