Context7 분석 (3) 서버 사이드 리랭킹

Context7 분석 시리즈
(1) 문서 특화 청킹 전략
(2) 코드 스니펫 vs 정보 스니펫
(3) 서버 사이드 리랭킹 ← 현재 글
(4) 5단계 품질 파이프라인
(5) 다층 품질 스코어링

RAG의 고질적 문제: 검색 결과가 너무 많다

RAG(Retrieval-Augmented Generation)의 기본 흐름은 간단합니다. 질문이 들어오면 벡터 데이터베이스에서 관련 문서를 검색하고, 검색 결과를 LLM의 컨텍스트에 넣어서 답변을 생성하는 방식이죠.

문제는 벡터 검색이 "대충 비슷한" 결과를 많이 가져온다는 것입니다. "Next.js 미들웨어 인증"을 검색하면, 정확히 관련된 3개의 청크 외에도 "Next.js 라우팅", "Express 미들웨어", "OAuth 인증 일반론" 같은 약간 관련 있지만 핵심은 아닌 청크가 10개, 20개씩 함께 딸려옵니다.

이 모든 걸 LLM 컨텍스트에 넣으면 어떻게 될까요?

• 토큰 낭비: 불필요한 문서가 컨텍스트를 차지해서 비용이 올라감
• 느린 응답: 컨텍스트가 클수록 LLM 처리 시간이 늘어남
• 정확도 저하: 노이즈가 많으면 LLM이 핵심 정보를 놓칠 수 있음 (이른바 "lost in the middle" 문제)

Context7의 초기 접근: LLM에게 필터링을 맡기다

Context7의 초기 버전은 많은 RAG 시스템이 그러하듯, 벡터 검색 결과를 그대로 LLM에 전달하고 LLM이 알아서 관련 있는 것만 골라 쓰게 했습니다. "너는 똑똑하니까 필요한 것만 골라서 답해줘"라는 전략이죠.

결과는?

지표	수치	문제
쿼리당 토큰 소모	~9,700 토큰	대부분이 "약간 관련 있는" 노이즈 문서에 소비됨
평균 응답 시간	24초	9,700 토큰의 컨텍스트를 처리하느라 느림
쿼리당 도구 호출	3.95회	LLM이 불충분한 결과에 만족 못해 반복 호출

특히 "도구 호출 3.95회"가 눈에 띕니다. 이것은 LLM이 첫 번째 검색 결과에서 답을 못 찾아서 "혹시 다른 문서에 있나?"하고 같은 도구를 여러 번 다시 호출한다는 뜻입니다. 불필요한 문서 때문에 핵심 정보가 묻혀버린 거죠.

전환: 서버에서 먼저 걸러주자

Context7 팀의 핵심 통찰은 이것입니다:

"문서를 필터링하고 순위를 매기는 작업은 범용 추론 모델(LLM)보다, 우리 인프라의 전용 리랭킹 모델에서 더 빠르고, 저렴하고, 예측 가능하다."

아이디어는 단순합니다. 벡터 검색 결과를 LLM에 넘기기 전에, 서버 사이드에서 전용 리랭킹 모델을 돌려 상위 N개만 골라내는 것입니다.

리랭킹이란?

벡터 검색(1차 검색)은 임베딩 간의 코사인 유사도로 후보를 빠르게 추립니다. 빠르지만 정밀하지는 않죠. 리랭킹(2차 검색)은 이 후보들을 더 정교한 모델로 다시 평가해서 순위를 재조정하는 과정입니다.

비유하자면, 벡터 검색은 "서류 전형"이고 리랭킹은 "면접"입니다. 서류 전형으로 100명에서 20명을 추리고, 면접으로 20명에서 5명을 고르는 것과 같습니다. 면접(리랭킹)이 더 정확하지만 더 느리므로, 전체 100명에게 면접을 볼 수는 없고 서류 전형 통과자에게만 실시하는 것이죠.

리랭킹 모델 vs LLM

"어차피 LLM도 필터링할 수 있는데 왜 별도 모델을 쓰나?" 좋은 질문입니다. 핵심 차이는:

	LLM 필터링	전용 리랭킹 모델
하는 일	코드 생성, 요약, 분석 등 범용 추론 + 부수적으로 필터링	오직 "질문-문서 관련성 점수 매기기"만 수행
모델 크기	수십~수백B 파라미터	수백M 파라미터 (훨씬 작음)
속도	느림 (범용이라 오버헤드 큼)	매우 빠름 (특화되어 있으므로)
비용	입력 토큰당 과금 (비쌈)	자체 인프라에서 실행 (거의 무료)
예측 가능성	프롬프트에 따라 결과가 달라질 수 있음	동일 입력에 항상 동일 점수

LLM에게 "이 20개 문서 중에서 관련 있는 것만 골라줘"라고 시키면, 20개 문서의 토큰을 모두 입력으로 넣어야 하고, 그 처리에 시간과 비용이 들고, 프롬프트 표현 하나에 따라 결과가 달라질 수 있습니다. 반면 전용 리랭킹 모델은 "질문 + 문서" 쌍에 0~1 사이 점수만 매기면 되므로 빠르고, 저렴하고, 일관적입니다.

결과: 극적인 개선

지표	변경 전 (LLM 필터링)	변경 후 (서버 리랭킹)	개선율
토큰 소모	~9,700	~3,300	65% 감소
응답 시간	24초	15초	38% 개선
도구 호출 수	3.95회	2.96회	30% 감소

토큰 65% 감소는 곧 비용 65% 절감을 의미합니다. 그런데 단순히 적게 보내는 것이 아니라, 더 관련 있는 문서만 보내기 때문에 답변 품질도 함께 올라갑니다. 도구 호출이 3.95회에서 2.96회로 줄었다는 것은 LLM이 첫 번째 결과에서 답을 더 잘 찾고 있다는 증거입니다.

자체 RAG에 적용할 때의 교훈

• 벡터 검색 결과를 LLM에 통째로 넘기지 마라: 반드시 중간에 필터링/리랭킹 단계를 두어라
• 리랭킹은 별도의 경량 모델로: Cross-encoder 기반 리랭킹 모델(예: ms-marco-MiniLM, bge-reranker)은 오픈소스로 쉽게 구할 수 있다
• 1차 검색은 넓게, 2차 리랭킹은 좁게: 벡터 검색으로 상위 20~50개를 가져온 뒤, 리랭킹으로 상위 3~5개만 LLM에 전달하는 것이 일반적인 패턴
• 비용 절감 효과가 크다: LLM API 비용은 입력 토큰에 비례하므로, 불필요한 문서를 줄이는 것만으로 운영비를 크게 낮출 수 있다

Context7 분석 시리즈
(1) 문서 특화 청킹 전략
(2) 코드 스니펫 vs 정보 스니펫
(3) 서버 사이드 리랭킹 ← 현재 글
(4) 5단계 품질 파이프라인
(5) 다층 품질 스코어링

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.