리랭킹

1차 검색이 빠르게 가져온 후보 문서를 더 꼼꼼한 모델로 다시 채점해 순위를 새로 매기는 단계로, 서류 전형 뒤에 면접을 보는 것과 비슷하다. RAG에서 LLM에 넘길 문서를 고를 때 쓰며, 답변 품질을 높이는 가장 손쉬운 개선 지점으로 꼽힌다.

왜 두 단계로 나누나

벡터 검색은 질문과 문서를 한 번도 같이 읽지 않는다. 그래서 "파이썬 3.12에서 제거된 기능"을 물었는데 "파이썬 3.12의 새 기능" 문서가 1등으로 나오는 일이 생긴다. 리랭커는 둘을 함께 읽기 때문에 부정, 조건, 버전 차이 같은 것을 훨씬 잘 잡아낸다.

대신 리랭커는 질문이 들어올 때마다 후보 수만큼 모델을 돌려야 해서 전체 문서에 쓰기엔 너무 느리다. 그래서 빠른 검색으로 넓게 찾고, 리랭커로 좁히는 조합이 표준이 됐다.

검색 결과와 LLM 사이에 끼워 넣는다

구성은 단순하다. 벡터 검색과 키워드 검색(BM25)을 섞어 후보를 넉넉히 가져오고, 리랭커로 점수를 매긴 뒤 상위 몇 개만 LLM에 넘긴다.

표 형태 데이터는 YAML 문자열로 바꿔 넣는 것이 좋다(Cohere 문서 권장).

검색 실패가 눈에 띄게 줄어든다

Anthropic 실험에서 키워드 검색을 더하고 리랭킹까지 얹자 검색 실패율이 크게 떨어졌다. 후보 150개를 다시 매겨 상위 20개만 쓰는 구성이었다.

상위 20개 청크 안에 필요한 문서가 없었던 비율. 낮을수록 좋다.

후보 수와 점수 기준선은 직접 정한다

후보를 많이 넣을수록 정확해지지만 느려지고 비싸진다. 실시간 챗봇은 후보를 줄이고, 밤에 돌리는 배치 분석은 늘리면 된다. 효과는 실제 사용자 질문 50~100개에 정답 문서를 표시해 두고, 리랭킹 전후로 상위 5개 안에 정답이 들어오는 비율을 비교해 보면 알 수 있다. 약관이나 기술 문서처럼 비슷한 문서가 많을수록 효과가 크다.

점수가 낮은 문서는 버리는 게 좋다. 상위 5개를 무조건 넘기지 말고 relevance_score에 기준선을 둔다. 남는 문서가 없으면 "관련 자료를 찾지 못했다"고 답하게 하면 엉뚱한 근거로 지어낸 답이 줄어든다. 컨텍스트 창이 넓어져도 관련 없는 문서가 많으면 비용이 늘고 모델이 핵심을 놓치기 쉽다.

문서 기반 챗봇의 마지막 거름망으로 쓴다

가장 흔한 건 RAG 챗봇에서 LLM 직전에 끼우는 방식이다. 기존 검색은 그대로 두고 후보를 다시 줄 세우기만 하면 되니, 검색 품질이 아쉬울 때 가장 먼저 붙여 본다.