임베딩 재대결: BM25와 텍스트 임베딩 비교 분석

이전 Shortlist Decides First 실험은 제가 해결하겠다고 약속한 한 가지 조건 하에 끝났습니다. 당시 실험에서 사용된 검색기(retriever)는 BM25라는 어휘 일치 방식(lexical matcher)이었고, 이로 인해 의역된 요청(paraphrased requests)에 대한 치명적인 5%의 재현율(recall)이 나왔는데, 이는 어휘 일치 방식이 보여야 할 전형적인 실패 사례였습니다. 만약 의미론적 검색기(semantic retriever)를 사용한다면 판결이 바뀔까요? 이것은 측정 가능한 질문이므로, 여기 재대결 결과를 가져왔습니다: 동일한 100개의 도구, 동일한 200개의 작업, 동일한 네 가지 설명 조건 및 k-sweep을 유지하되, 한 가지만 변경했습니다. BM25 대신에, 검색기는 모든 도구 문서와 모든 요청을 Azure OpenAI의 text-embedding-3-small로 임베딩하고 코사인 유사도(cosine similarity)로 순위를 매깁니다. 하네스(harness)는 동반 리포지토리의 measure/eval_recall_embed.py에 있으며, 다른 것은 변경되지 않았습니다.

결과

설명 조건 및 작업 종류별 정확한 도구의 쇼트리스트 재현율:

승리: 임베딩이 의역(paraphrase)을 구제하다

BM25는 k=5인 의역 요청에서 5%를 기록했습니다. 반면, 임베딩 방식은 동일한 작업과 설명 조건에서 76%를 기록했습니다. 이것이 재대결의 핵심 내용이며, 이론이 말하는 바로 그 지점에 정확히 도달합니다:

k-sweep의 동작 방식도 이제 다르게 나타나므로 주목할 가치가 있습니다. BM25를 사용할 경우, 후보군(shortlist)을 3개에서 10개로 늘리자 패러프레이즈 재현율(paraphrase recall)이 3%에서 10%로 증가했습니다. 이는 올바른 도구가 보통 순위 상위권에 위치하지 않았기 때문입니다. 임베딩(embeddings)을 사용할 경우, 같은 후보군 확장이 59%에서 94%까지 끌어올립니다. 의미적 누락(Semantic misses)은 근접한 실패였지만, 어휘적 누락(lexical misses)은 애초에 누락이 아니었습니다. 리트리버가 적어도 의미적으로 주변 영역에 위치한다면, 더 긴 후보군을 확보하는 것은 실제로 무언가를 구매하는 것입니다.

놀라운 점: 서술의 풍부함이 마침내 가치를 가지며, 정확성은 비용을 초래한다

후보군 분석(shortlist post)은 설명 토큰 수를 늘리는 것이 커버리지를 높이는 것은 아니라고 결론지었기 때문에, BM25는 설명 토큰을 두 배로 늘려도 패러프레이즈 재현율에 변화가 없었습니다. 이번 비교 분석은 이 주장을 수정하도록 강요합니다: 이는 어휘적으로는 사실이지만, 의미적으로는 덜 사실입니다. 임베딩의 경우, 서술이 풍부한 설명(verbose descriptions)이 모든 k 값에서 간결한 설명보다 패러프레이즈 성능이 좋았습니다 (k=5일 때 82 대 73). 이는 추가적인 문장 하나하나가 질의 벡터가 도달할 수 있는 의미적 표면(semantic surface)을 추가하기 때문입니다. 서술이 풍부한 것은 여전히 좋은 거래는 아니지만, 이전처럼 '0'은 아닙니다.

반대의 놀라운 점은 어휘(vocabulary) 열에서 나타납니다. 도구 자체의 어휘를 반영하는 요청에 대해 BM25는 k=3일 때 97%에서 100%의 점수를 받았고, 임베딩은 91%에서 97%의 점수를 받았습니다. 임베딩은 정확한 일치(exact matches)를 모호하게 만듭니다. 사용자가 설명에 있는 단어들을 정확히 말할 때, 그 단어들을 문자 그대로 일치시키는 것보다 더 좋은 것은 없으며, 의미적 리트리버는 가끔 유사하게 들리는 형제(sibling)가 정확한 히트보다 높은 순위를 차지합니다. 두 리트리버는 정반대의 작업 집단에서 실패하며, 이는 하이브리드 검색(hybrid retrieval)에 대한 교과서적인 논거이며, 이제 이 시리즈를 통해 그 수치를 얻었습니다.

최종 판결: 별칭 문장(alias sentence)이 여전히 승자다

마지막 행을 보세요. 도구당 13토큰의 별칭 문장을 사용했을 때, 모든 k 값에서 재현율은 99%에서 100%에 달하며, BM25를 사용할 때도 100%였습니다. 이 시리즈 전체에서 가장 저렴한 개입(intervention)이 리트리버 선택을 무의미하게 만듭니다.

이는 임베딩 인덱스가 무엇을 제공하는지 재정의합니다. 만약 도구 설명을 직접 제어할 수 있다면, 별칭(alias) 문장만으로 도구당 약 13 토큰으로 완벽한 재현율(recall)을 얻고 인프라 비용은 전혀 들지 않습니다. 반면, 임베딩 파이프라인, 임베딩 모델, 인덱스 구축 및 요청마다의 조회 과정은 설명문을 수정할 수 없는 경우 패러프레이즈(paraphrase)에 대해 5%에서 76% 사이의 성능을 제공합니다. 이는 게이트웨이나 다른 팀의 MCP 서버를 전면에 내세우는 카탈로그의 정확한 상황입니다. 두 답변 모두 맞지만, 서로 다른 소유권 질문에 답하고 있습니다.

'The Model Was Never the Problem'에서 나온 엔드투엔드(end-to-end) 곱셈 결과도 이에 맞춰 업데이트되었습니다. 실제 설명문을 사용한 패러프레이즈 요청의 재현율과 선택률을 비교하자면 다음과 같습니다: BM25는 5% * 93%로, 대략 5%의 작업이 올바른 도구 호출로 이어졌습니다. 임베딩은 76% * 93%로, 대략 71%입니다. 별칭(Aliases)은 100% * 97%로, 대략 97%이며, 이 경우 어떤 검색기(retriever)를 사용하든 동일합니다.

솔직한 한계점 (Honest limits)

text-embedding-3-small 같은 단일 임베딩 모델이나 더 큰 모델 또는 하이브리드 레스칼(lexical)-플러스-벡터 랭커가 두 격차를 좁힐 가능성이 높으며, 이 프레임워크는 사용자가 원한다면 모든 Azure OpenAI 임베딩 배포를 처리할 수 있습니다. 패러프레이즈 문장은 템플릿으로 생성되었기 때문에 체계적이지만 실제 사용자 구어체보다는 덜 자연스럽습니다. 카탈로그에는 100개의 도구가 포함되어 있으며, 만약 이 숫자가 1,000개로 늘어나면 별칭 규율을 팀 전반에 걸쳐 적용하기가 더 어려워지기 때문에 임베딩 인덱스가 더욱 매력적이게 됩니다. 그리고 이것은 검색(retrieval)만을 측정한 것이며, 선택(selection) 단계는 별도로 측정되어 곱해집니다.

핵심 요약 (The takeaway)

재대결 결과는 검색기(retriever)가 올바른 용의자였고 설명(description)이 여전히 적절한 해결책이었음을 확인시켜 주었습니다. 임베딩은 패러프레이즈 회상률을 재앙에서 세금 납부 수준으로 끌어올렸습니다 (5%에서 76%로). 그리고 설명이 다른 사람의 것이라면, 임베딩이 정직한 권장 사항입니다. 하지만 설명이 당신의 것이라면, 도구당 별칭 문장 하나가 전체 벡터 파이프라인보다 우수하며 운영 비용은 그 만분의 일에 불과합니다. 먼저 단어를 수정하세요. 단어가 더 이상 당신의 것이 아닐 때 인덱스를 추가하여 수정하십시오.

두 검색기(retrievers)와 전체 결과는 companion repo에 있습니다: BM25의 경우 measure/eval_recall.py, 재대결의 경우 measure/eval_recall_embed.py.