앤트로픽, 맥락 검색 발표: RAG 검색 실패율 최대 67% 감소

RAG(검색 증강 생성)를 구축해 본 개발자라면 누구나 한 번쯤 겪는 골칫거리가 있습니다. 긴 보고서를 수백 토큰 크기의 청크로 잘라 벡터 데이터베이스에 넣었는데, 시스템이 정작 중요한 순간에 엉뚱한 정보를 가져오는 현상입니다.

원인은 허무할 정도로 단순합니다. 잘려 나간 텍스트 조각에는 '회사의 전 분기 대비 매출이 3% 증가했다'고 적혀 있지만, 앞뒤 맥락이 잘려 나가 어느 회사의 몇 년도 실적 이야기인지 식별할 정보가 통째로 증발했기 때문입니다.

Anthropic은 9월 19일 이 문제를 해결하기 위한 '문맥적 검색(Contextual Retrieval)' 기법을 공개했습니다. 발상은 매우 직관적입니다. 각 텍스트 청크를 임베딩하거나 색인화하기 전에, 전체 문서의 맥락을 설명하는 50~100 토큰 분량의 설명을 청크 맨 앞에 미리 덧붙여 두는 방식입니다.

작은 모델로 청크마다 명찰을 달아주다

문서를 잘게 쪼개는 전통적인 RAG 파이프라인에서는 청크 하나하나가 고립된 섬이 됩니다. Anthropic은 Claude 3 Haiku를 활용해 전체 문서를 한 번 읽게 한 뒤, 각 청크가 문서 내에서 어떤 위치와 배경을 갖는지 설명하는 짧은 문맥을 자동으로 생성하도록 했습니다.

주어 없던 매출 문장 앞에 '이 내용은 ACME 사의 2023년 2분기 SEC 제출 보고서에 속함'이라는 설명이 붙는 식입니다. 이렇게 문맥이 보강된 청크를 바탕으로 벡터 임베딩과 전통적인 키워드 검색 알고리즘인 BM25 색인을 함께 만듭니다.

오래된 기술인 BM25를 버리지 않고 결합한 점도 실전적입니다. 벡터 임베딩은 문맥의 의미를 파악하는 데는 탁월하지만, 'TS-999' 같은 고유 오류 코드나 부품 번호처럼 정확한 일치 검색이 필요할 때는 종종 빗나갑니다. BM25가 정확한 문자열을 잡고 임베딩이 의미를 잡도록 조합한 것입니다.

코드베이스, 논문, 소설 등 다양한 도메인에서 테스트한 결과, 문맥 임베딩만 단독 적용해도 상위 20개 청크의 검색 실패율이 35% 줄었습니다. 여기에 문맥 BM25를 결합하면 실패율이 49% 감소했고, 리랭킹까지 추가하자 실패율이 무려 67%까지 떨어졌습니다.

프롬프트 캐싱으로 전처리 비용을 1달러 선으로 묶다

수십만 개의 텍스트 청크마다 LLM을 호출해 앞머리에 문맥을 붙이는 작업은 이전 같으면 API 비용 때문에 엄두를 내기 어려웠습니다. Anthropic은 최근 출시한 프롬프트 캐싱 기능으로 이 비용 장벽을 무너뜨렸습니다.

모든 청크를 처리할 때마다 원본 문서를 새로 전달할 필요 없이, 원본 문서를 캐시에 한 번 올려두고 반복 참조하는 방식을 썼습니다. 8000 토큰짜리 문서를 800 토큰 단위로 나눈다고 가정할 때, 100만 문서 토큰의 문맥을 생성하는 일회성 비용은 약 1.02달러에 불과합니다.

지식 베이스 전체 크기가 20만 토큰(약 500페이지) 미만이라면 RAG 자체를 쓸 필요도 없다는 설명도 덧붙였습니다. 프롬프트 캐싱을 이용해 전체 지식 베이스를 프롬프트에 통째로 올려두면 지연 시간은 절반 이하로 줄고 비용은 최대 90%까지 아낄 수 있습니다.

왜 중요한가

사내 문서 검색이나 고객 상담용 AI를 만드는 팀이라면 지금 당장 검토해 볼 가치가 충분합니다. RAG 성능 개선의 가장 큰 병목이던 '청크 분할 시 주어 유실' 문제를, 100만 토큰당 단 1달러 남짓의 전처리 비용으로 해결해 실패율을 절반 이하로 낮출 수 있다는 점은 가성비 면에서 압도적입니다.

업계 전반으로 봐도 복잡도만 높이던 RAG 기술 트렌드에 균형추를 맞췄습니다. 지난 1년 동안 문맥 유실을 막겠다며 GraphRAG나 복잡한 에이전트 파이프라인을 도입하느라 시스템이 지나치게 무거워졌는데, Anthropic은 저렴한 소형 모델과 수십 년 된 BM25 알고리즘의 결합이라는 담백한 데이터 전처리로 더 강력한 결과를 증명해 보였습니다.

우리는 이 접근법이 매우 영리한 공학적 실용주의라고 판단합니다. 다만 한계도 명확해 보입니다. 이 방식은 데이터가 비교적 고정된 정적 문서군에 가장 유리하며, 실시간으로 내용이 계속 수정되거나 추가되는 동적 데이터베이스 환경에서는 매 변경마다 문맥 생성 모델을 다시 호출해야 하므로 파이프라인 관리 비용이 만만치 않을 수 있습니다.