RAG를 기본 설정으로 선택해서는 안 되는 이유

Vector RAG는 "모델에 더 많은 컨텍스트를 제공하라"는 요구에 대한 반사적인 해답이며, 제가 실제 서비스용 튜터링 AI를 구축했을 때도 저 역시 이를 선택했습니다. 제품은 간단합니다. 학생이 문제 사진을 업로드하면, 우리의 튜터가 단계별로 설명하고 정답을 생성합니다. 고객사는 또한 이미지로 저장된 방대한 과거 문제 데이터베이스를 보유하고 있었고, 당연히 우리는 이를 활용하고 싶었습니다. 그래서 시스템은 가장 유사한 과거 문제를 검색하여 그 정답과 함께 모델에 입력함으로써 솔루션 생성을 도왔습니다. 너무나 당연한 조치였기에 저는 한 번도 의문을 품지 않았습니다.

결과는 좋지 않았습니다.

저는 흔히 의심되는 원인인 검색 품질 (retrieval quality)을 찾아 나섰습니다. 문제 설명에 기반한 매칭부터 이미지 콘텐츠에 기반한 매칭까지 다양한 검색 전략을 시도했습니다. 단일 벡터 (single-vector)부터 후기 상호작용 (late-interaction) 방식까지 다양한 임베딩 모델 (embedding models)을 벤치마킹했습니다. 하지만 그 어떤 것도 상황을 개선하지 못했습니다. 검색 품질이 문제라면, 버그는 어디에 있는 걸까요?

Vector RAG는 텍스트나 이미지를 임베딩 공간 (embedding space)에 표현하고, 쿼리 (query)와 의미가 가장 가까운 저장된 청크 (chunk)를 반환합니다. 다시 말해, 이는 정확히 한 가지, 즉 이미 저장된 내용과의 의미론적 유사성 (semantic similarity)을 최적화합니다. 그 안에는 하나의 조용한 가정이 숨겨져 있습니다. 바로 '가장 유사하게 저장된 항목이 모델에 필요한 항목일 것'이라는 가정입니다. FAQ나 문서 조회 (document lookup)의 경우 이 가정은 성립합니다. 가장 유사한 구절이 실제로 올바른 구절이기 때문에, RAG는 그 상황에서 결코 틀리지 않으며, 이를 사용하는 것이 매우 자연스럽게 느껴져 그 가정이 수면 위로 드러나지 않습니다. 도구 자체는 문제가 아닙니다. 도구는 주장하는 바를 정확히 수행합니다. 진짜 질문은 '가장 유사함 == 필요한 것'이라는 공식이 당신의 사례에도 성립하는가이며, 당신은 이를 활용하기 전에 반드시 확인해야 합니다.

제 경우에는 그렇지 않았습니다. 저는 답변 정확도를 높이기 위해 가장 유사한 문제를 찾고 싶었고, 그래서 멀티모달 이미지 검색 파이프라인(multimodal image-retrieval pipeline)을 구축했습니다. Qdrant에 인덱싱된 과거 문제들을 대상으로 Colpali/ColQwen 및 Jina 멀티 벡터 검색(multi-vector retrieval)을 서로 벤치마킹했습니다. 하지만 결과는 모두 일반화 성능이 떨어졌습니다. 제1원리(first principles)부터 차근차근 생각해보니, 이 접근 방식에는 두 가지 근본적인 문제가 있다는 것을 깨달았습니다.

첫째, 검색(retrieval) 문제 자체가 잘못 설정되었습니다(ill-posed). 우리의 작업에서 '유사함'은 시각적 또는 의미론적 유사함이 아니라, '풀이 방법의 유사함'을 의미해야 했습니다. 그리고 그런 종류의 유사성은 문제 이미지 하나만으로는 정의하는 것이 거의 불가능합니다. 싱글 벡터(single-vector) 방식이나 후기 상호작용(late-interaction) 방식 모두 검색 품질을 개선하지 못한 것은 당연했습니다. 저는 검색기(retriever)에게 이미지에 아예 인코딩되어 있지 않은 정보를 요구하고 있었던 것입니다.

둘째, 완벽한 검색기가 있었다 하더라도 도움이 되지 않았을 것입니다. 모델에게 유사한 문제와 그 정답을 제공하더라도, 모델은 이를 적용하기 전에 해당 예시로부터 풀이 방법을 역공학(reverse-engineer)해야 합니다. 즉, 추가적인 추론 단계(reasoning hop)가 필요합니다. 소규모 정성 평가(~10개 문제) 결과, 유사한 문제와 정답을 입력값으로 넣어도 의미 있는 성능 향상은 나타나지 않았습니다.

두 문제 모두 동일한 지점을 가리키고 있었습니다. 모델에게 실제로 필요한 것은 풀이 방법 그 자체였습니다. 유사한 문제 이미지는 잘못된 단위였으며, 기껏해야 간접적인 방식일 뿐이었습니다.

그래서 우리는 RAG를 완전히 버렸습니다. 대신, 풀이 방법을 재사용 가능한 지식으로 사전 구조화(pre-structured)하고, LLM이 관련 방법을 선택하여 직접 적용하도록 했습니다. 답변의 질은 눈에 띄게 좋아졌습니다. 모델은 더 이상 방법을 사용하기 전에 추론할 필요가 없었고, 그냥 바로 사용하게 되었습니다. (대체 방식에 대해 공식적인 벤치마크를 수행하지는 않았으므로, 이는 수치가 아닌 정성적인 결과로 받아들여 주시기 바랍니다.)

더 큰 성과는 운영 측면에서 나타났습니다. 우리는 클라이언트가 LLM이 의존하는 지식을 직접 편집할 수 있는 웹 인터페이스를 구축했습니다. 각 변경 사항이 모델의 동작에 즉시 반영되기 때문에, 클라이언트는 실시간으로 실험하고 반복하며 결과를 확인할 수 있습니다.

그리고 이를 수행하기 위해 엔지니어가 필요하지 않습니다. 기술적 지식이 없는 사용자들도 직접 플레이북 (playbook)을 업데이트할 수 있습니다. 이는 모델의 동작이 임베딩 (embeddings)과 검색 파이프라인 (retrieval pipeline) 안에 갇혀 있었을 때는 결코 불가능했던 일입니다. 시스템은 출시 후에도 계속해서 개선되며, 지식 플레이북 (knowledge playbook)은 RAG 스택 (RAG stack)보다 유지보수가 훨씬 더 쉽다는 것이 증명되었습니다. 보너스로, 우리의 검색 인프라 (retrieval infra) 비용도 절감되었습니다.

이번 사례를 통해 저는 RAG를 기본 설정 (default)으로 취급해서는 안 된다는 교훈을 얻었습니다. RAG를 사용하기 전에 한 가지 질문을 던져보세요. '저장된 가장 유사한 항목이 여기서 모델이 가장 필요로 하는 것과 동일한가?' 만약 그렇지 않다면, 모델이 실제로 무엇을 필요로 하는지 파악하고 그것을 제공하십시오. 검색 (Retrieval)은 필요의 단위 (unit of need)에 관한 설계 결정 (design decision)이지, 무심코 선택하는 기본 설정이 아닙니다.