검색을 붙였는데도 답이 틀립니다. 벡터 데이터베이스를 바꿔 보고, 임베딩 모델을 최신으로 올려 보고, 프롬프트를 몇 번이나 고쳐 봐도 같은 자리에서 같은 실수가 반복됩니다. 무엇을 고쳐야 하는지 모르기 때문입니다.

RAG를 다루는 자료는 많습니다. 그런데 대부분 특정 프레임워크의 사용법이거나, 몇 달 뒤면 이름이 바뀌는 최신 기법의 소개입니다. 청크 크기는 1024가 정답이라고 하고, 하이브리드 검색을 켜라고 하고, 리랭커를 붙이라고 합니다. 그 숫자와 기능이 왜 거기 있는지, 무엇을 대가로 무엇을 얻는지는 설명하지 않습니다. 그래서 도구가 바뀌면 처음부터 다시 배워야 합니다.

이 책은 반대 순서로 갑니다. 기능 목록이 아니라 문제의 순서를 따라갑니다. 1990년대 BM25가 왜 지금도 살아 있는지, 2020년 봄 몇 달 사이에 REALM과 DPR과 RAG 논문이 어떻게 한 구조로 합류했는지, 덴스 검색이 이겼다는 이야기가 이듬해 BEIR에서 어떻게 뒤집혔는지를 짚습니다. 그 다음에는 실무의 결정으로 내려옵니다. 문서를 어디서 자를 것인가, 무엇을 하나의 검색 단위로 만들 것인가, 두 검색기의 결과를 어떻게 합칠 것인가, 넓게 모은 후보를 누가 다시 읽을 것인가, 검색하기 전에 질문 자체를 바꿔야 하는가.

이 책의 중심은 13장의 실패 지도입니다. 같은 오답이 일곱 가지 다른 곳에서 시작될 수 있다는 것을 보여줍니다. 애초에 자료가 없었을 수도 있고, 청킹이 기본 규칙과 예외를 갈라놨을 수도 있고, 정답 문서를 찾았지만 37위라 컨텍스트에 못 들어갔을 수도 있고, 컨텍스트에 들어갔는데 모델이 무시했을 수도 있습니다. 이 위치를 구분할 수 있으면 고칠 곳이 보입니다. 구분하지 못하면 환각이라는 한 단어에 모든 문제를 묻어 버리게 됩니다. 14장은 그래서 평가를 하나의 점수로 합치지 말라고 말합니다. 두 시스템이 같은 80점을 받아도 고쳐야 할 곳은 정반대일 수 있습니다.

후반부는 지금 논쟁 중인 주제를 다룹니다. 컨텍스트 창이 길어지면 RAG는 사라질까. 넣을 수 있다는 것과 잘 쓸 수 있다는 것은 다른 문제이고, 비용과 권한과 출처 추적은 창 크기로 해결되지 않습니다. 작은 청크 몇 개로는 답할 수 없는 전역적 질문을 위해 RAPTOR와 GraphRAG가 무엇을 시도했는지, 그리고 그 구현이 유지보수 모드에 들어간 뒤에도 문제는 왜 남아 있는지를 봅니다. 마지막으로 검색이 파이프라인의 고정 단계에서 필요할 때 호출하는 도구로 옮겨 가는 변화를 다룹니다.

코드는 없습니다. 특정 제품의 화면도 없습니다. 대신 열일곱 장의 도해로 각 단계에서 무엇이 무엇으로 바뀌는지를 그렸습니다. 사내 규정과 출장비 같은 익숙한 예제 하나를 책 전체에서 반복해 쓰기 때문에, 청킹을 바꾸면 검색이 어떻게 달라지고 그것이 최종 답을 어떻게 바꾸는지 같은 문서 위에서 따라갈 수 있습니다.

개발자만을 위한 책은 아닙니다. RAG 프로젝트의 품질을 판단해야 하는 기획자, 왜 우리 챗봇이 틀리는지 설명해야 하는 실무자, 외주 결과물을 검수해야 하는 담당자에게도 필요한 것은 구현 코드가 아니라 실패의 위치를 짚는 언어입니다.

약속할 수 있는 것은 하나입니다. 이 책은 여러분의 RAG 정확도를 몇 퍼센트 올려 주지 않습니다. 그 숫자는 문서와 질문과 도메인에 따라 달라지고, 이 책은 그런 단정을 피합니다. 대신 새로운 이름이 나왔을 때 다섯 가지만 물으면 됩니다. 검색 대상을 바꾸는가, 검색 단위를 바꾸는가, 질문을 바꾸는가, 순위와 컨텍스트를 바꾸는가, 검색 여부와 반복 결정을 바꾸는가. 이 다섯 질문이 남으면 프레임워크가 몇 번 바뀌어도 처음부터 다시 시작하지 않습니다.