쉽게 이해하기

크로스 인코더는 질의와 문서를 따로 보지 않고 한 번에 붙여 읽는 재랭킹 모델입니다. 입력은 보통 [CLS] 질의 [SEP] 문서 [SEP]처럼 만들고, Transformer가 질의 단어와 문서 단어를 모두 서로 비교하게 합니다. 그래서 “말은 다르지만 뜻은 같은 문서”나 “단어는 비슷하지만 맥락이 다른 문서”를 더 잘 구분합니다. 대신 후보 하나마다 모델을 한 번씩 실행해야 하므로, 전체 문서 저장소를 직접 검색하기보다는 1단계 검색기가 가져온 top-K 후보를 다시 정렬할 때 씁니다.

비유와 예시

• 시험 답안 재검토: 1차 채점기가 후보 답안을 빠르게 골라오면, 크로스 인코더는 문제와 답안을 나란히 놓고 다시 읽는 채점자처럼 더 정밀하게 순서를 매깁니다.
• 고객지원 검색: “비밀번호 재설정 메일이 안 와요”라는 질의와 “계정 인증 이메일 문제 해결” 문서를 함께 읽어, 표현은 달라도 같은 문제인지 판단합니다.
• RAG 문서 선택: 벡터 검색이 후보 문단 100개를 가져오면, 크로스 인코더가 질의와 각 문단을 직접 비교해 최종 5-10개 근거 문서를 고릅니다.

한눈에 비교

	Cross-Encoder	Bi-Encoder	BM25
주 역할	후보 재정렬	빠른 의미 검색	빠른 키워드 검색
입력 방식	질의+문서를 함께 입력	질의/문서 따로 임베딩	토큰과 통계
장점	정밀한 문맥 판단	대규모 검색에 빠름	설명 가능하고 저렴함
단점	후보 수만큼 추론 필요	미묘한 상호작용 약함	동의어/의미 검색 약함

어디서 왜 중요한가

• RAG 품질: 최종 컨텍스트에 들어갈 문서를 더 정확히 고르는 데 유용합니다.
• 검색 UX: top-10 결과 순서가 사용자의 체감 품질을 크게 좌우할 때 효과가 큽니다.
• 운영 경계: 1단계 검색 recall이 낮으면 크로스 인코더도 정답 후보를 볼 수 없습니다.
• 비용 관리: 후보 수 K, 입력 길이, 배치 크기, fallback 모델을 함께 정해야 합니다.

자주 하는 오해

• ❌ 오해: 크로스 인코더로 전체 코퍼스를 검색하면 된다 → ✅ 실제: 후보마다 추론이 필요해 1차 검색기 뒤의 재랭킹에 적합합니다.
• ❌ 오해: 재랭커만 좋으면 검색이 해결된다 → ✅ 실제: 1단계 검색기가 정답 후보를 가져오지 못하면 재랭커도 복구할 수 없습니다.
• ❌ 오해: 후보 K는 클수록 무조건 좋다 → ✅ 실제: K가 커지면 비용과 지연도 커지므로 품질-지연 곡선을 보고 정해야 합니다.

대화에서는 이렇게

• "BM25+벡터로 top-100을 가져오고, Cross-Encoder로 top-10만 다시 정렬합시다."
• "p95 latency(요청 95%가 끝나는 시간)가 넘으니 K를 100에서 50으로 줄인 A/B를 보겠습니다."
• "NDCG@10(상위 10개 순위 품질 지표)은 올랐지만, 1단계 recall도 같이 확인해야 합니다."
• "긴 문서는 chunk 단위로 재랭킹하고, 문서 단위 집계 규칙을 따로 두겠습니다."

함께 읽으면 좋은 용어

• 기초
  BM25 — 크로스 인코더 앞단에서 후보를 빠르게 가져오는 키워드 검색.
• 기초
  벡터 검색 — 의미 기반 1차 검색.
• 유사
  Bi-Encoder — 대규모 후보 검색에 적합한 분리 인코딩 방식.
• 유사
  ColBERT — 토큰 단위 late interaction으로 속도와 정밀도를 절충하는 방식.
• 심화
  Re-ranking — 크로스 인코더가 주로 쓰이는 2단계 검색 절차.