[LLM Wiki 14] Rerank: 검색 후보를 다시 줄 세우는 기술

검색 시스템에서 Rerank는 1차 검색 결과를 다시 읽고, 질문에 더 잘 맞는 순서로 재정렬하는 단계다. 한국어로는 보통 후보 재정렬이라고 보면 된다.

핵심은 단순하다.

• 1차 검색은 넓게 찾는다.
• Rerank는 그중 정말 질문에 맞는 문서를 위로 올린다.
• Main LLM은 위로 올라온 문서만 읽고 답한다.

예를 들어 사용자가 “가격 때문에 막힌 고객 미팅 찾아줘”라고 물었다고 하자. 1차 검색은 “가격”, “비용”, “cost”, “pricing” 같은 단어가 들어간 문서를 넓게 찾는다. 그런데 여기에는 고객의 가격 불만뿐 아니라 서버 비용 최적화 회의도 섞일 수 있다. Reranker는 이 후보들을 질문과 다시 비교해 “고객이 가격 부담을 말한 미팅”을 위로 올리고, “서버 비용 절감 회의”는 아래로 내린다.

왜 Rerank가 필요한가

BM25와 vector search는 각각 장점이 있다.

BM25는 정확한 단어에 강하다. 고객명, 제품명, 약어, 날짜, 코드명처럼 글자가 정확히 맞아야 하는 검색에 좋다.

Vector search는 의미가 비슷한 표현에 강하다. “가격 부담”, “budget concern”, “too expensive”, “도입 비용이 높다”처럼 단어는 달라도 뜻이 비슷한 문서를 찾는 데 유리하다.

문제는 둘 다 1차 후보를 만드는 기술이라는 점이다. 1차 검색은 보통 정답을 놓치지 않기 위해 넓게 찾는다. 그러면 관련 없는 문서도 섞인다.

이때 Rerank가 들어간다. Reranker는 후보 전체를 새로 검색하지 않는다. 이미 찾은 후보 목록을 받아서, 질문에 맞는 순서로 다시 줄 세운다.

검색 품질을 두 단어로 나누면 이해하기 쉽다.

• Recall: 정답 후보를 빠뜨리지 않고 넓게 찾는 능력
• Precision: 위쪽 결과가 실제로 질문에 맞는 능력

BM25와 vector search는 recall을 확보하고, reranker는 precision을 끌어올리는 역할을 맡는다.

실제 검색 Flow

LLM Wiki나 회의록 검색에서 Rerank는 보통 다음 흐름에 들어간다.

첫째, 사용자가 자연어 질문을 던진다.

가격 때문에 막힌 고객 미팅 찾아줘

둘째, query expansion을 한다. 사용자의 질문은 짧고 표현이 부족할 수 있으므로 검색용 표현을 늘린다.

pricing objection
budget concern
too expensive
purchase delayed due to price
도입 비용이 높다
예산 문제

셋째, candidate retrieval을 한다. BM25, vector search, metadata filter를 사용해 후보를 넓게 모은다. 예를 들어 후보 50개나 200개를 가져올 수 있다.

넷째, reranker가 질문과 후보를 쌍으로 비교한다. “이 후보가 이 질문에 대한 답변 근거로 얼마나 좋은가”를 점수화한다.

다섯째, 상위 후보만 main LLM에 넘긴다. 보통 상위 5개, 10개, 20개처럼 제한한다. 그러면 LLM이 읽는 문서량이 줄고, 관련 없는 문서 때문에 답이 흐려질 가능성도 낮아진다.

Reranker는 어떻게 판단하나

Embedding 검색은 질문과 문서를 각각 벡터로 만든 뒤, 벡터 사이의 거리를 비교한다. 빠르고 넓게 찾는 데 좋지만, 질문과 문서의 세부 맥락을 직접 대조하는 능력은 제한적이다.

Reranker는 보통 query와 candidate를 함께 넣고 판단한다.

Query:
가격 때문에 막힌 고객 미팅 찾아줘

Candidate:
ACME가 예산 문제로 도입을 다음 분기로 미뤘다. 담당자는 가격 정책 재검토가 필요하다고 말했다.

이 후보는 질문과 직접 맞다. 관련성 점수가 높게 나온다.

반대로 다음 후보를 보자.

Candidate:
이번 분기 서버 비용이 늘어 infra cost optimization을 논의했다.

여기에도 비용이라는 단어는 있다. 하지만 사용자가 찾는 것은 고객 미팅에서 나온 가격 장애물이다. 서버 비용 최적화 회의는 질문의 의도와 다르다. Reranker는 이런 후보를 아래로 내려야 한다.

이 차이가 Rerank의 핵심이다. 단어가 비슷한가만 보는 것이 아니라, 질문의 의도와 답변 근거로서의 적합성을 본다.

주요 컴포넌트

Rerank 시스템은 모델 하나만으로 끝나지 않는다. 주변 컴포넌트를 같이 봐야 한다.

Query는 사용자의 원래 질문이다. 질문이 너무 짧거나 모호하면 query expansion이나 의도 분류가 필요하다. “그거 찾아줘” 같은 질문은 이전 대화 맥락이 없으면 검색 품질이 낮다.

Candidate Pool은 1차 검색으로 모은 후보 묶음이다. 후보가 너무 적으면 정답이 빠질 수 있고, 너무 많으면 rerank 비용과 시간이 커진다. 회의록 시스템에서는 BM25, vector search, metadata filter를 함께 써서 후보를 만든다.

Chunk 또는 Passage는 reranker가 비교할 문서 단위다. 문서 전체를 넣을 수도 있지만 긴 회의록은 보통 작은 단위로 나눈다. 단, 너무 작게 자르면 앞뒤 문맥이 사라진다. 제목, 날짜, 프로젝트, 참석자 같은 metadata를 같이 붙이면 판단이 좋아질 수 있다.

Reranker Model은 query와 candidate를 함께 읽고 relevance score를 낸다. 구현 방식은 여러 가지다. cross-encoder 모델을 쓸 수도 있고, LLM judge 방식으로 점수를 매길 수도 있고, 검색 API가 제공하는 rerank 모델을 쓸 수도 있다.

Score와 Top-k는 최종 선택 단계다. 점수순으로 정렬한 뒤 상위 몇 개만 남길지 정한다. 점수가 너무 낮은 후보는 threshold로 버릴 수 있다.

Evaluation은 품질 점검이다. 사람이 “이 질문에는 이 문서가 정답”이라고 표시한 평가 세트가 있어야 모델과 파라미터를 바꿔도 품질이 좋아졌는지 알 수 있다.

Reranker와 Main LLM은 다르다

가장 흔한 오해는 reranker가 답변을 쓰는 모델이라고 생각하는 것이다. 아니다.

Reranker는 정렬 모델이다. 후보 문서를 읽고 “이 질문에 얼마나 관련 있는가”를 점수화한다. 답변을 예쁘게 쓰는 것이 목표가 아니다.

Main LLM은 답변 모델이다. reranker가 고른 상위 문서를 읽고 최종 답변을 만든다. 요약을 하거나, 비교를 하거나, wiki card를 갱신한다.

역할을 섞으면 시스템이 불안정해진다. Reranker가 답변까지 쓰게 하면 왜 이 문서가 선택됐는지 추적하기 어렵고, Main LLM이 모든 후보를 직접 읽게 하면 비용과 지연 시간이 커진다.

LLM Wiki에서 Rerank가 들어가는 위치

LLM Wiki에서는 Rerank가 검색 레이어의 품질 보정 장치가 된다.

회의록이 적을 때는 Obsidian 검색이나 파일명 탐색만으로도 충분하다. 하지만 회의록이 많아지면 질문 하나에 관련될 수 있는 파일이 너무 많다.

예를 들어 다음 질문을 보자.

6월에 가격정책 때문에 고객 도입이 미뤄진 사례를 모아줘.

이 질문은 단순 키워드 검색으로 풀기 어렵다. “가격정책”, “예산”, “도입 지연”, “purchase delayed”, “budget”, “pricing objection”이 섞여 있을 수 있다. qmd 같은 검색 레이어가 후보를 찾고, reranker가 그중 실제 사례에 가까운 문서를 위로 올린다. 그다음 Main LLM이 상위 후보를 읽고 사례를 정리한다.

이 구조를 쓰면 LLM이 모든 회의록을 처음부터 끝까지 읽지 않아도 된다. 검색 계층은 읽을 문서를 찾고, LLM Wiki 계층은 그 결과를 사람이 검토할 수 있는 카드와 요약으로 남긴다.

좋은 Rerank를 위한 설계 포인트

첫째, 후보 수를 적절히 잡아야 한다. 1차 후보가 10개뿐이면 정답이 빠질 수 있다. 반대로 1,000개를 매번 rerank하면 비용과 지연 시간이 커진다. 처음에는 50200개 후보를 가져오고, 상위 520개를 LLM에 넘기는 식으로 시작할 수 있다.

둘째, metadata를 버리지 말아야 한다. 회의록 검색에서는 본문만큼 날짜, 프로젝트, 고객명, 참석자, 문서 타입이 중요하다. Reranker 입력에 제목과 metadata가 함께 들어가면 판단이 좋아진다.

셋째, chunk 크기를 조정해야 한다. 너무 긴 chunk는 비용이 크고, 너무 짧은 chunk는 근거가 끊긴다. 회의록은 발언 단위보다 “주제 블록”이나 “결정/액션 주변 문맥” 단위가 더 나을 때가 많다.

넷째, 평가 질문 세트가 필요하다. “가격 부담 고객 미팅”, “SSO 때문에 막힌 사례”, “오픈 액션”, “결정이 바뀐 이유” 같은 실제 질문을 모아두고, 기대 문서를 표시해야 한다.

다섯째, rerank 결과를 그대로 믿지 말아야 한다. Reranker도 모델이다. 표현이 애매하거나 문서가 부실하면 틀릴 수 있다. 중요한 답변은 source 링크와 원문 확인 경로를 함께 남겨야 한다.

한계

Rerank는 검색 품질을 올리지만 모든 문제를 해결하지는 않는다.

첫째, 1차 검색에서 정답 후보가 빠지면 reranker는 복구할 수 없다. Rerank는 후보 목록 안에서 순서를 바꾸는 기술이지, 없는 문서를 새로 찾아오는 기술이 아니다.

둘째, 긴 문서 전체를 제대로 이해하지 못할 수 있다. 후보 chunk를 어떻게 자르느냐에 따라 점수가 달라진다.

셋째, 비용과 지연 시간이 늘어난다. 후보 200개를 rerank한다면 query와 candidate 쌍을 200번 평가하는 셈이다.

넷째, 관련성 점수는 절대 진실이 아니다. 점수가 높다고 항상 답변 근거로 완벽하다는 뜻은 아니다. 최종 답변 단계에서는 인용, source, 버전, 원문 링크가 필요하다.

Rerank는 LLM Wiki에서 꽤 중요한 기술이다. 하지만 위치를 정확히 잡아야 한다. Reranker는 지식 저장소도 아니고 최종 답변자도 아니다. 넓게 찾은 검색 후보를 질문 기준으로 다시 정렬해, Main LLM이 읽을 문서를 더 잘 고르게 해주는 품질 보정 단계다.

참고 자료

• Cohere Rerank documentation: https://docs.cohere.com/docs/reranking
• Pinecone reranking guide: https://docs.pinecone.io/guides/search/rerank-results
• Elasticsearch reranking overview: https://www.elastic.co/search-labs/blog/elasticsearch-relevance-engine-reranking
• qmd: https://github.com/simonw/qmd