BM25 — AI가 도구 100개 중 3개를 정확히 찾아내는 방법

Tool Search Tool이 "build"를 검색하면 왜 build_app이 나오는가. 어떤 알고리즘이 100개 도구 카탈로그에서 관련 있는 3~5개만 골라내는가. 답은 BM25다 — 검색 엔진의 고전적 랭킹 알고리즘으로, Google 이전 시대부터 쓰인 방법이 AI 도구 검색의 핵심으로 돌아왔다. 이 글은 BM25가 어떻게 작동하는지, 왜 도구 검색에 잘 맞는지, 그리고 개발자가 여기서 어떤 설계 결정을 해야 하는지를 풀어낸다.

검색의 기초 — 역색인

BM25를 이해하려면 먼저 역색인(Inverted Index)을 알아야 한다. 역색인은 "어떤 단어가 어떤 문서에 있는가"를 미리 계산해 놓은 테이블이다. 일반 색인이 "문서 A에는 어떤 단어들이 있는가"를 저장한다면, 역색인은 방향을 뒤집어 "단어 X는 어떤 문서들에 있는가"를 저장한다. 검색어가 들어오면 테이블을 바로 참조하므로 전체 문서를 훑을 필요가 없다.

다이어그램 설명. 역색인 구축은 도구가 등록될 때 한 번만 실행된다. 이후 "빌드"를 검색하면 테이블에서 sdk_build_app을 즉시 찾는다. "디바이스"를 검색하면 세 도구가 모두 나온다 — 이 때 어떤 도구를 우선순위에 올릴지 결정하는 게 BM25의 역할이다.

TF-IDF — BM25의 전신

BM25를 이해하는 가장 빠른 경로는 그 전신인 TF-IDF를 먼저 보는 것이다. TF-IDF(Term Frequency–Inverse Document Frequency)는 "단어의 관련도 = 빈도 × 희귀도"라는 아이디어다. 이 문서에서 많이 나오는 단어이고(TF), 다른 문서에서는 잘 안 나오는 단어라면(IDF), 그 단어는 이 문서의 핵심 키워드다.

다이어그램 설명. IDF의 로그 함수가 핵심이다. "디바이스"가 100개 도구 중 50개에 등장하면 IDF는 log(100/50) = 0.3으로 낮다. "에뮬레이터"가 2개에만 등장하면 IDF는 log(100/2) ≈ 3.9로 높다. 희귀하고 특이한 단어에 높은 가중치를 주는 것이다.

그런데 TF-IDF에는 두 가지 약점이 있다.

▲ 약점 ① — 단어 빈도가 선형으로 점수에 반영됨

▲ 약점 ② — 긴 description이 불리하게 계산됨

다이어그램 설명. 두 약점이 실제로 의미하는 것은 이렇다. description을 상세하게 잘 쓰면 쓸수록 TF-IDF에서는 오히려 점수가 낮아질 수 있다. 개발자가 친절하게 긴 설명을 써준 도구가 짧은 설명의 도구보다 검색에서 밀리는 역설이다.

BM25 — 두 가지 개선으로 약점을 메운다

BM25(Best Match 25 — 25번째 실험에서 최고 성능을 낸 방식에서 이름이 왔다)는 TF-IDF의 두 약점을 각각 하나씩 해결한다.

▲ 개선 ① — 단어 빈도가 높아도 점수가 무한히 커지지 않음

▲ 개선 ② — description 길이와 무관하게 공평하게 점수 계산

다이어그램 설명. 두 개선이 합쳐지면 어떤 효과가 있는가. "빌드"를 상세하게 설명한 긴 description과 짧게 쓴 description이 있을 때, BM25는 "빌드"라는 단어가 각 description에서 얼마나 핵심적인가를 길이에 무관하게 평가한다. 상세한 설명이 더 좋은 점수를 받는 구조다.

Tool Search Tool에서 BM25가 동작하는 방식

Anthropic의 Tool Search Tool은 BM25와 Regex(정규표현식 기반 검색) 두 가지 방식을 제공한다. 기본 권장은 BM25다. LLM이 자연어로 쿼리를 만들기 때문에 — "빌드"가 아니라 "앱 빌드", "디바이스 배포용 빌드", "arm64 빌드" 같은 변형 표현이 나온다 — Regex보다 BM25가 훨씬 유연하게 매칭한다.

다이어그램 설명. 검색은 한 번의 라운드트립(LLM → Tool Search Tool → 카탈로그 → 결과)으로 끝난다. LLM이 "arm64 릴리스 빌드"라는 문장으로 검색하면, 세 단어 각각에 대해 역색인을 조회하고 점수를 합산한다. sdk_build_app은 세 단어 모두와 관련이 있어 높은 점수를 받고, 그 정의만 컨텍스트에 올라온다. 나머지 97개 도구는 이 대화에서 단 한 토큰도 차지하지 않는다.

BM25 vs Regex — 언제 어떤 방식을 쓰나

▲ BM25 — 자연어 쿼리, 관련도 랭킹 필요 시

▲ Regex — 도구 이름이 체계적인 패턴을 따를 때

다이어그램 설명. 실제로 LLM이 만드는 쿼리는 거의 자연어이므로 BM25가 기본 선택이다. Regex는 도구 이름이 sdk_, db_, aws_ 같은 서비스별 접두사로 철저하게 구분된 경우, LLM이 접두사로 검색 범위를 좁힐 때 유리하다.

실측 효과 — 49%에서 74%로

Anthropic이 공개한 수치를 보면, BM25 기반 Deferred Loading의 효과가 뚜렷하다. 5개 서버·50개 도구 기준 실험이다.

▲ 적용 전 — 도구 전부 노출, 컨텍스트 낭비 + 정확도 저조

▲ 적용 후 — 관련 도구만 JIT 로드, 토큰 절감 + 정확도 급등

다이어그램 설명. 두 수치가 함께 움직인다는 점이 흥미롭다. 토큰이 줄었는데 정확도가 올랐다 — 역설적으로 보이지만 인과관계가 있다. LLM이 50개 도구 정의를 한꺼번에 받으면 비슷비슷한 도구 사이에서 혼동이 생긴다. 3~5개만 보여주면 선택지가 명확해진다. BM25가 "관련 있는 것만" 올려주기 때문에 가능한 결과다.

도구 이름·description 설계가 BM25 정확도를 결정한다

BM25는 역색인 기반이다. 역색인에 키워드가 없으면 검색에서 나오지 않는다. LLM이 "배포"를 검색했는데 description에 "배포"가 없고 "설치"만 있다면, BM25는 그 도구를 찾지 못한다. description에 없는 단어는 존재하지 않는 것과 같다.

다이어그램 설명. ④번이 의외로 효과적이다. sdk_deploy_to_device의 description에 "sdk_build_app 실행 후 사용"이라고 쓰면, "build"로 검색할 때 deploy 도구도 함께 올라온다. 빌드 다음에 배포가 자연스러운 흐름이고, 그 흐름을 LLM이 description에서 읽어낼 수 있다.

반대로, description이 짧고 모호하면 어떻게 되는지 보면 이렇다.

다이어그램 설명. 같은 도구인데 description 하나로 검색 성공률이 갈린다. BM25는 description에 있는 단어만 보기 때문에, description이 풍부할수록 다양한 쿼리 패턴에 응답할 수 있다. 좋은 description은 사람이 읽기 좋을 뿐 아니라 BM25가 인덱싱하기도 좋다 — 둘이 같은 방향이다.

BM25가 AI 도구 검색에 맞는 이유

BM25가 2024~2025년 기준 수십억 달러짜리 신기술을 제치고 Anthropic의 Tool Search Tool 기본 알고리즘으로 채택된 이유는 뭘까. 세 가지다.

첫째, 예측 가능성이다. BM25는 결정론적(deterministic) 알고리즘이다. 같은 입력에 항상 같은 결과가 나온다. 벡터 임베딩(문장을 고차원 벡터로 변환해 유사도를 계산하는 방식)은 의미적으로 더 풍부하지만, 어떤 도구가 올라올지 예측하기 어렵다. 도구 개발자 입장에서 BM25는 description에 키워드를 넣으면 그 키워드로 반드시 검색된다는 보장이 된다.

둘째, 속도다. 역색인 조회는 O(1) 수준으로 빠르다. 벡터 임베딩은 문장을 수백 차원의 벡터로 변환하고 코사인 유사도를 계산하는 GPU 연산이 필요하다. Tool Search Tool이 한 요청 안에서 여러 번 호출될 수 있다는 걸 생각하면, 빠른 알고리즘이 전체 지연에 미치는 영향이 크다.

셋째, 해석 가능성이다. 검색이 실패하면 이유를 알 수 있다. "description에 이 단어가 없어서 안 찾아진다"고 바로 진단된다. 벡터 임베딩 기반 검색이 실패하면 왜 안 찾아지는지 설명하기 어렵다.

다이어그램 설명. BM25의 약점은 단어 수준의 매칭이라는 것이다. "배포"와 "설치"는 의미적으로 비슷하지만 BM25에서는 전혀 다른 단어다. 이 약점은 description 설계로 보완된다 — description에 "설치"와 "배포"를 모두 쓰면 어떤 표현으로 검색해도 찾힌다. 약점이 있지만, 개발자가 통제 가능한 약점이다.

BM25는 설계의 문제다

BM25가 "AI 도구 검색"이라는 새로운 용도에 쓰인다는 것이 흥미롭다. 1994년에 공개된 알고리즘이 30년 후 LLM 도구 검색의 핵심이 됐다. 이유는 단순하다 — 빠르고, 예측 가능하고, 디버깅이 쉽다.

개발자가 여기서 가져갈 인사이트는 알고리즘이 아니라 설계의 방향이다. BM25는 도구 이름과 description에 있는 단어를 그대로 인덱싱한다. 검색 품질은 알고리즘이 아니라 텍스트 설계가 결정한다. 도구를 잘 설명하는 것이 곧 검색이 잘 되게 만드는 것이고, 검색이 잘 되면 LLM이 도구를 정확히 선택한다. 이 세 단계는 연결된 하나의 체인이다.

---

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