에이전트 검색에서 30년 된 BM25가 놀랍도록 강력한 이유

URL: https://www.youtube.com/watch?v=yNPS1Z64wQM 날짜: 2026-09-21 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==30년 된 어휘 기반 점수 함수 BM25는 변하지 않았지만, 더 빠르게 입력하고 더 많이 읽으며 질의를 재구성할 수 있는 LLM 에이전트가 새로운 사용자로 등장하면서 에이전트 검색의 강력한 기본 프리미티브로 다시 부상했다.==

• LLM은 기업명·인물명·날짜·우편번호·SKU처럼 정확한 문자열이 중요한 지식을 이미 파라미터 안에 갖고 있으므로, 어휘의 정확 매칭을 활용하는 BM25 질의를 풍부하게 만들 수 있다.
• 에이전트는 사람보다 훨씬 많은 질의를 연속 실행하고, 결과를 읽은 뒤 질의를 재구성하며, 긴 구문과 검색 연산자를 직접 사용할 수 있다.
• BM25는 결과가 왜 검색됐는지 모델이 이해하기 쉽고, grep·ripgrep·sed·awk·파일시스템과 결합할 수 있으며, 임베딩 추론 인프라보다 단순하고 저렴하다.
• 성능과 품질은 BM25라는 이름만으로 결정되지 않는다. 구현, 파라미터, 긴 문서 처리 방식에 따라 같은 BM25라도 결과가 크게 달라진다.

에이전트 검색은 코딩·심층 조사 같은 작업을 수행하는 에이전트의 루프 안에 검색을 넣는 방식이다. 좋은 시스템에는 도구를 사용하고 질의를 만들 수 있는 모델, 검색 기능을 모델에 노출하는 하니스(harness), 수십억 개 문서에서도 효율적으로 검색하는 검색 엔진이 모두 필요하다. BM25는 이 세 요소를 연결하는 저비용·설명 가능·정확 매칭 중심의 기반으로 기능하며, 검색 결과를 파일시스템형 작업공간에 놓으면 모델의 코드 도구 사용 능력까지 활용할 수 있다.

1. 에이전트 검색의 정의와 시스템 구성

에이전트 검색의 핵심은 검색을 독립적인 한 번의 질의가 아니라 작업 수행 루프 안의 반복 도구로 취급하는 데 있다.

1.1. 검색이 필요한 에이전트 작업

1. 작업 안에 포함된 정보 요구

   1. 코딩 작업: 에이전트가 코드를 작성하거나 수정하려면 관련 문서, 저장소 파일, API 정보가 필요하다.
   2. 심층 조사: 여러 출처를 찾고 읽어 사실을 조합해야 하는 연구형 작업도 검색 루프를 필요로 한다.
   3. 일반 작업: 특정 과업을 성공적으로 끝내려면 현재 문맥에 들어오지 않은 외부 정보를 찾아야 한다.

2. 단발성 검색과 다른 실행 방식

   1. 질의 실행: 에이전트가 검색 문자열을 만들고 검색 도구를 호출한다.
   2. 결과 해석: 반환된 스니펫이나 문서를 읽고 정보가 충분한지 판단한다.
   3. 반복·재구성: 답이 부족하면 질의를 바꾸거나 확장해 다시 검색한다. 이 과정이 답을 찾거나 컨텍스트 창을 채울 때까지 이어진다.

1.2. 좋은 에이전트 검색 시스템의 세 요소

1. 능력 있는 모델

   1. 도구 사용: 검색 같은 외부 기능을 호출할 수 있어야 한다.
   2. 질의 작성: 필요한 정보를 검색어로 구체화하고, 결과에 맞춰 다음 질의를 만들 수 있어야 한다.
   3. 일반 지식 활용: 엔티티, 회사, 날짜와 같은 배경지식을 질의에 반영해야 한다.

2. 모델과 검색 사이의 하니스

   1. 도구 호출(tool calling): 검색 기능을 명시적인 도구로 모델에 제공하는 방식이다.
   2. 코드 모드(code mode): 모델이 코드와 셸 도구를 사용해 검색·파일 읽기·문맥 관리를 조합하는 방식이다.
   3. 노출 방식의 중요성: 같은 검색 엔진이라도 모델이 어떤 인터페이스로 접근하는지에 따라 질의와 문맥 관리가 달라진다.

3. 검색 엔진

   1. 대규모 처리: 잠재적으로 수십억 개 문서에서 검색을 효율적으로 실행해야 한다.
   2. 상위 K개 검색: 모든 문서를 점수화하는 개념적 방법을 실제 시스템에서 빠르게 수행하도록 수십 년간 다양한 top-K 가속 알고리즘이 개발됐다.
   3. 기본 프리미티브: BM25는 최종 제품 전체가 아니라 대규모 검색 시스템을 구성하는 강력한 기본 요소다.

2. BM25의 원리와 변하지 않은 점

BM25는 새로운 알고리즘으로 바뀐 것이 아니라, 같은 점수 함수가 더 강력한 사용자와 결합하면서 쓰임새가 달라진 사례다.

2.1. 이름과 점수의 의미

1. Best Match 25

   1. 명칭의 배경: 연구자들이 여러 실험을 진행했고, 25번째 실험이 가장 좋은 결과를 보여 Best Match 25라는 이름이 붙었다.
   2. 실체: BM25는 쿼리와 문서 사이의 상호작용을 계산해 관련성의 대리 지표가 되는 점수를 만드는 함수다.

2. 점수 계산의 직관

   1. 쿼리 항: 사용자가 찾고 싶은 단어와 구문이 점수 계산의 출발점이 된다.
   2. 문서 항: 문서에 같은 단어와 구문이 어떻게 나타나는지 비교한다.
   3. 순위 결정: 모든 문서를 개념적으로 점수화한 뒤 점수가 높은 상위 K개를 반환한다.

2.2. top-K 검색을 빠르게 만드는 문제

1. 기본 계산의 비용

   1. 전체 문서 점수화: 문서 수가 커지면 각 문서와 쿼리를 비교하는 작업이 막대한 비용이 된다.
   2. 상위 결과 추출: 실제 검색 시스템은 전체 순위를 완성하지 않고도 상위 K개를 찾기 위해 다양한 최적화 기법을 사용한다.

2. BM25와 구현의 분리

   1. 함수 자체: 약 30년 동안 BM25의 수학적 점수 함수는 본질적으로 변하지 않았다.
   2. 엔진의 차이: 인덱싱, 실행 전략, 하드웨어 활용, 파라미터, top-K 가속 구현에 따라 처리량과 지연시간은 달라진다.
   3. 결론: “어떤 BM25인가?”라는 질문을 해야 하며, BM25라는 이름만으로 엔진 품질을 판단할 수 없다.

3. LLM이라는 새로운 사용자가 BM25를 강화하는 이유

BM25의 부활을 설명하는 핵심 변수는 점수 함수의 변화가 아니라 검색 사용자의 능력 변화다.

3.1. 사람보다 강한 질의 작성자

1. 더 많은 질의

   1. 사람의 패턴: AOL 검색 로그와 더 최근의 검색 로그에서 사람은 대체로 몇 개 단어로 짧은 질의를 만든다.
   2. 에이전트의 패턴: GPT-5 같은 모델은 작업 중 질의를 계속 실행하고, 결과를 읽으며, 필요한 방향으로 다시 검색한다.

2. 더 구체적인 질의

   1. 긴 문자열: 모델은 사람보다 긴 질의를 빠르게 작성해 조건과 배경을 한 번에 넣을 수 있다.
   2. 검색 문법: 웹 검색을 통해 학습한 site 연산자, 구문 검색 등 다양한 문법을 질의에 사용할 수 있다.
   3. 작업량의 변화: 검색은 한 번의 입력과 한 번의 결과가 아니라 여러 질의가 이어지는 새로운 워크로드가 된다.

3.2. 일반 지식과 정확 매칭의 결합

1. 파라미터 지식의 역할

   1. 엔티티 인식: 모델은 회사, 인물, 제품, 날짜 같은 엔티티를 알고 있어 검색어를 더 정확하게 만들 수 있다.
   2. 후속 판단: 반환된 정확 매칭 결과를 읽고 어떤 단어를 추가하거나 제거할지 결정할 수 있다.

2. 임베딩으로 놓치기 쉬운 문자열

   1. 코드와 식별자: 우편번호, SKU, 제품 코드, 고유명사처럼 한 글자 차이가 의미를 바꾸는 항목은 정확한 문자열 매칭이 중요하다.
   2. 고정 어휘의 한계: 임베딩 모델은 모든 토큰을 고정된 어휘 공간으로 인코딩하므로 특정 코드나 희귀 문자열을 그대로 보존하고 찾는 데 불리할 수 있다.
   3. 역할 분담: 의미적 유사성은 임베딩이 도울 수 있지만, 명시적인 단어·구문·식별자는 BM25가 직접 다룬다.

3.3. 비용과 설명 가능성

1. 상대적으로 낮은 비용

   1. 임베딩 추론 비용: 일부 임베딩 모델은 약 80억 개 파라미터 규모이며, 텍스트를 인코딩하고 이를 운영할 별도 인프라가 필요하다.
   2. BM25의 단순성: 어휘 기반 인덱스와 점수 계산을 활용하므로 검색 파이프라인을 단순하게 구축할 수 있다.
   3. 성숙한 생태계: BM25는 오래 사용돼 도구와 운영 경험이 널리 축적돼 있다.

2. 모델이 결과를 설명할 수 있음

   1. 문자열 기반 근거: 모델은 어떤 단어와 구문이 결과에 실제로 매칭됐는지 확인할 수 있다.
   2. 질의 재작성: 매칭 단어를 보고 결과가 나온 이유를 이해하면 다음 질의를 더 정교하게 만들 수 있다.
   3. 검증 가능성: 결과의 근거가 임베딩 공간의 추상적인 거리보다 직접적인 단어 매칭으로 드러난다.

4. BrowseComp Plus가 보여주는 검색의 병목

BrowseComp Plus는 단일 검색 품질보다 검색 도구를 포함한 전체 에이전트 루프가 답을 맞히는지를 평가하게 만든다.

4.1. 벤치마크의 문제와 프로토콜

1. 문제 구성

   1. 질문 수: 약 820개의 질문으로 구성된다.
   2. 난이도: 펍 퀴즈처럼 정답을 바로 떠올리기 어려운 수수께끼형 질문이며, 질문 자체도 비교적 길다.
   3. 정답 판정: 각 질문에 기준 정답이 있어 전체 루프가 최종 답을 정확하게 만들어내는지 확인한다.

2. 검색 인터페이스

   1. 모델: 에이전트 루프를 실행하는 모델이 문제를 받는다.
   2. 검색 도구: 문자열 하나를 받는 매우 단순한 search 도구가 제공된다.
   3. 반환값: 검색 도구는 문서 전체가 아니라 결과 스니펫을 모델에 돌려준다.
   4. 코퍼스: 웹 문서 약 10만~10만 5천 개가 검색 대상이다.

4.2. 추론보다 검색이 병목이 되는 이유

1. 증거를 미리 제공한 경우

   1. 컨텍스트 직접 주입: 정답에 필요한 증거 문서를 모델의 컨텍스트에 인위적으로 넣으면 정확도가 매우 높다.
   2. 모델 능력의 의미: GPT-4조차 증거가 주어지면 수수께끼형 질문에 높은 정확도로 답하므로, 추론 자체가 유일한 병목은 아니다.

2. 검색 도구를 사용해야 하는 경우

   1. 하니스 의존성: 모델에 검색 기능을 어떻게 노출하는지가 결과에 영향을 준다.
   2. 질의 작성 의존성: 모델이 적합한 단어와 문법으로 쿼리를 만들어야 한다.
   3. 검색 품질 의존성: 검색 엔진이 좋은 문서를 찾아 스니펫으로 돌려줘야 한다.
   4. 종단간 정확도 하락: 같은 모델이라도 필요한 증거를 직접 받는 경우보다 검색 루프를 거치는 경우 정확도가 낮아진다.

4.3. 컨텍스트 창과 플로피 디스크 비유

1. 한정된 작업 공간

   1. 플로피 디스크: 1980년대 게임을 설치하던 플로피 디스크 한 장에는 약 1.4MB가 들어갔다.
   2. 현대 모델의 비유: 모델 품질이 떨어지기 시작하는 컨텍스트 용량을 약 35만 토큰으로 보면, 현재의 컨텍스트 창은 정보량 관점에서 플로피 디스크 한 장과 비슷한 제한을 가진다.

2. 완벽한 모델 이후에도 남는 문제

   1. 정보 선택: AGI에 가까운 모델이 실수를 거의 하지 않더라도 모든 문서를 컨텍스트에 넣을 수는 없다.
   2. 검색의 지속적 필요: 필요한 정보만 골라 컨텍스트 창으로 가져오는 retrieval은 모델이 더 좋아져도 계속 중요하다.

5. 검색 궤적과 BM25 파라미터의 함정

에이전트 검색의 성능은 검색 함수와 검색 궤적이 함께 만들어내며, 오래된 기본 파라미터는 새로운 워크로드에서 실패할 수 있다.

5.1. 검색 궤적의 구조

1. 반복 루프

   1. 질의 실행: 모델이 검색어를 입력한다.
   2. 결과 읽기: 스니펫을 읽고 현재 증거가 충분한지 파악한다.
   3. 질의 재구성: 부족한 단서, 새로 발견한 엔티티, 다른 표현을 다음 검색어에 반영한다.
   4. 종료 조건: 답을 찾거나 컨텍스트 창이 채워질 때까지 궤적이 이어진다.

2. GPT-5 질의의 특징

   1. AOL 로그와 대조: 사람은 짧은 질의를 반복하는 반면 GPT-5는 훨씬 길고 구체적인 질의를 작성한다.
   2. 검색 연산자 활용: site 검색, 구문 검색 등 웹 검색 문법을 사용한다.
   3. 일반 지식의 증폭: 모델이 알고 있는 배경지식이 문자열 검색의 정확도를 높인다.

5.2. “어떤 BM25인가?”라는 질문

1. 두 개의 주요 하이퍼파라미터

   1. 점수 조절: BM25에는 점수 함수의 여러 측면을 조절하는 두 개의 하이퍼파라미터가 있다.
   2. 문서 길이와 빈도 대응: 파라미터 선택은 긴 문서와 용어 빈도가 점수에 반영되는 방식을 바꾼다.

2. BrowseComp Plus의 나쁜 기준선

   1. 기본값의 문제: 벤치마크에서 사용한 BM25 기준선은 처음에는 매우 형편없는 결과를 보였다.
   2. 고급 기법의 착시: 기본값이 부적절하면 더 정교한 랭킹 모델이 BM25보다 훨씬 나은 것처럼 보인다.
   3. 최근 연구의 교훈: 원 논문과 이후 연구에서 사용한 파라미터가 긴 문서 워크로드에 적합하지 않을 수 있다.
   4. 큰 정확도 차이: 이 특정 벤치마크에서는 BM25 구현·파라미터 선택이 종단간 정확도에 극적인 영향을 준다.

6. 동적 작업공간으로 확장하는 검색 인프라

수십억 개 문서를 곧바로 컨텍스트에 넣을 수 없으므로, BM25 결과를 에이전트가 다룰 수 있는 파일시스템형 작업공간으로 단계적으로 노출하는 설계가 유망하다.

6.1. Waterloo 연구의 방향

1. 연구 배경

   1. 연구 그룹: 워털루대학교 Jimmy Lin 그룹은 정보 검색과 에이전트 검색을 연구한다.
   2. 논문: “Scaling Direct Corpus Interaction via Dynamic Workspace Expansion”은 검색 결과를 동적 작업공간으로 확장하는 방향을 다룬다.
   3. 실무 맥락: 여러 기업이 에이전트를 위한 웹 검색 인프라를 구축하고 있으며, 수십억 개 문서가 대상이 될 수 있다.

2. 검색 결과의 역할

   1. 에이전트용 SERP: BM25가 반환한 문서는 에이전트를 위한 검색 결과 페이지(SERP)처럼 작업공간에 배치된다.
   2. 컨텍스트 외부화: 모든 원문을 즉시 컨텍스트에 넣지 않고, 필요한 정보만 점진적으로 읽게 한다.

6.2. 파일시스템과 점진적 공개

1. 작업공간의 구조

   1. 파일시스템형 배치: 검색된 문서를 파일처럼 정리하면 모델이 익숙한 코드 에이전트 작업 방식으로 접근할 수 있다.
   2. 제목과 스니펫 우선: 처음에는 문서 제목과 짧은 스니펫만 보여준다.
   3. 추가 읽기의 선택: 모델이 가치 있다고 판단한 문서만 더 읽어 컨텍스트를 확장한다.

2. 기존 코드 도구와의 결합

   1. grep·ripgrep: 정확한 문자열을 빠르게 찾고 관련 문서의 범위를 줄인다.
   2. sed·awk: 문서의 필요한 부분을 추출하고 변환한다.
   3. 셸과 VFS: 샌드박스 인프라, 가상 파일시스템(VFS), bash를 검색 인프라와 함께 사용할 수 있다.
   4. 두 세계의 장점: 대규모 검색 엔진의 후보 선별과 코드 에이전트의 파일 탐색 능력을 결합한다.

6.3. 현재 모델에 맞춘 실용적 해킹

1. 모델이 잘하는 경로에 작업을 올리기

   1. 최적화 방향: 프런티어 LLM 기업들은 모델을 코딩, bash, 도구 사용에 강하게 만들고 있다.
   2. 시스템 설계: 종단간 작업을 파일시스템·셸·검색 도구를 쓰는 궤적에 맞추면 현재 모델의 강점을 바로 활용할 수 있다.
   3. 모델 교체 내성: 새 모델이 출시될수록 같은 도구 사용 경로가 더 좋아질 가능성이 있다.

2. 미래와 현재의 구분

   1. AGI 이후: AGI가 브라우저를 직접 자유롭게 사용할 수 있다면 설계가 달라질 수 있다.
   2. 현재의 결론: 현시점에는 BM25, 작업공간, 파일 도구를 묶는 방식이 강력한 에이전트 검색 경험을 제공한다.

7. 평가 방식의 전환과 구현 효율

여러 질의를 스스로 만들고 도구를 조합하는 에이전트에는 전통적인 단일 질의 순위 평가보다 실제 과업 성공률이 더 적합하다.

7.1. 고전적 정보 검색 평가의 한계

1. 기존 평가 방식

   1. 단일 질의: 하나의 쿼리를 입력한다.
   2. 단일 순위 목록: 검색 결과 순위를 만든다.
   3. NDCG 계산: 순위 품질을 NDCG 같은 지표로 계산하고 시스템끼리 비교한다.

2. 에이전트 검색에서의 불일치

   1. 다중 질의: 에이전트는 한 번이 아니라 여러 번 검색한다.
   2. 질의 확장: 결과에 따라 표현과 조건을 추가하거나 바꾼다.
   3. 도구 조합: 검색 외에도 파일 읽기, grep, 코드 실행을 사용한다.
   4. 새 기준: 검색 한 번의 순위보다 모델이 맡은 질문에 정답을 내고 과업을 끝냈는지를 평가해야 한다.

7.2. Hornet의 BM25 평가 목표

1. 기본 프리미티브에 대한 투자

   1. 가설: BM25는 에이전트 검색을 구성하는 강력한 근본 프리미티브다.
   2. 목표: BM25를 가장 효율적으로 평가하고 실행하는 방법을 구축한다.

2. 단일 노드 비교

   1. 데이터 규모: 웹 문서 1억 개를 하나의 노드에서 검색한다.
   2. 동일 조건: 익명화된 여러 엔진과 Hornet을 같은 종류의 하드웨어에서 비교한다.
   3. 처리량: 동일한 장비에서 Hornet의 구현이 다른 엔진보다 효율적이고 더 많은 처리량을 낸다는 비교 결과가 제시된다.
   4. 비용 의미: 웹 검색 인프라를 구축하는 기업에는 같은 장비로 더 많은 작업을 처리하는 능력이 직접적인 비용 절감으로 이어진다.
   5. 축 설명 정정: 질의응답에서 세로축을 처음에는 QPS라고 말했다가, 곧바로 정정해 지연시간(latency)이라고 설명했다.

주요 발언 모음

“BM25는 변하지 않았다. 바뀐 것은 훨씬 강력해진 사용자다.”

“새로운 사용자는 더 빠르게 입력하고, 더 빠르게 읽고, 질의를 재구성할 수 있다.”

“어떤 BM25를 말하는가? 구현, 성능, 파라미터에는 차이가 있다.”

“BM25가 에이전트 검색에 효과적인 이유는 모델이 결과를 설명할 수 있기 때문이다.”

“grep과 BM25의 조합은 매우 강력한 에이전트 검색 또는 에이전트 검색(retrieval) 패러다임이다.”

핵심 데이터 & 수치

• 약 30년: BM25는 약 30년 된 어휘 기반 점수 함수다.
• 2개: BM25 점수의 여러 측면을 조절하는 주요 하이퍼파라미터가 두 개다.
• 약 820개: BrowseComp Plus의 수수께끼형 질문 규모다.
• 약 10만~10만 5천 개: BrowseComp Plus 검색 코퍼스의 웹 문서 규모다.
• 약 1.4MB: 1980년대 플로피 디스크 한 장의 저장 용량 비유다.
• 약 35만 토큰: 품질 저하가 시작된다고 보는 현대 모델 컨텍스트 용량의 비유적 기준이다.
• 약 80억 파라미터: 일부 임베딩 모델의 규모로, 별도 임베딩 추론 인프라 비용을 설명하는 사례다.
• 1억 개: 단일 노드에서 엔진 효율을 비교한 웹 문서 규모다.

결론 및 시사점

1. 검색 사용자를 다시 정의한다: BM25의 부활은 점수 함수가 새로워져서가 아니라, 일반 지식과 도구 사용 능력을 갖춘 LLM이 긴 질의를 빠르게 만들고 반복 검색하기 때문에 일어난다.
2. 정확 매칭을 버리지 않는다: 엔티티·코드·SKU·우편번호·고유명사처럼 문자열 자체가 의미를 담는 정보에는 BM25의 정확 매칭이 임베딩과 다른 강점을 가진다.
3. 설명 가능성을 활용한다: 모델이 어떤 단어가 매칭됐는지 볼 수 있으면 결과를 이해하고 더 나은 다음 질의를 만들 수 있다.
4. grep과 함께 설계한다: BM25로 대규모 후보를 좁힌 뒤 grep·ripgrep·sed·awk로 문서 내부를 탐색하면 검색과 코드 에이전트의 강점을 결합할 수 있다.
5. BM25를 단일 제품명이 아니라 구현군으로 본다: 엔진 구현, 인덱스, top-K 알고리즘, 파라미터와 긴 문서 처리 방식이 실제 품질과 비용을 좌우한다.
6. 기본 파라미터를 의심한다: BrowseComp Plus에서 나쁜 BM25 기준선은 알고리즘 자체의 실패가 아니라 긴 문서에 맞지 않는 파라미터 선택의 결과일 수 있다.
7. 작업 성공률로 평가한다: 다중 질의·질의 재작성·도구 조합이 있는 환경에서는 NDCG 하나보다 최종 답 정확도와 종단간 과업 완료율이 핵심 지표다.
8. 컨텍스트를 작업공간으로 확장한다: 검색 결과를 파일시스템에 제목·스니펫부터 배치하고 필요할 때 원문을 읽게 하면 제한된 컨텍스트를 효율적으로 쓸 수 있다.
9. 대규모 인프라에서는 비용을 함께 본다: 1억 개 문서를 단일 노드에서 처리하는 엔진 효율은 동일 하드웨어에서 더 높은 처리량과 더 낮은 운영 비용으로 연결된다.
10. 현재 모델의 강점을 경로로 만든다: 코딩·bash·도구 사용에 최적화된 모델에게 검색을 파일시스템과 셸 도구로 노출하면 모델이 좋아질수록 전체 검색 경험도 개선될 가능성이 크다.

핵심 요약 (20줄)

1. BM25는 약 30년 된 어휘 기반 점수 함수지만 LLM 에이전트의 등장으로 다시 강력한 검색 기반이 됐다.
2. 에이전트 검색은 코딩이나 심층 조사 같은 작업의 실행 루프 안에서 검색을 반복하는 방식이다.
3. 좋은 시스템에는 능력 있는 모델, 검색 하니스, 대규모 검색 엔진이 함께 필요하다.
4. BM25는 쿼리와 문서의 단어·구문 상호작용으로 관련성 점수를 계산한다.
5. BM25 자체는 변하지 않았고 검색 사용자인 모델의 능력이 크게 달라졌다.
6. LLM은 기업·날짜·엔티티에 관한 일반 지식을 이용해 더 구체적인 질의를 작성한다.
7. 에이전트는 사람보다 많은 질의를 빠르게 실행하고 결과를 읽어 다음 질의를 재구성한다.
8. GPT-5는 긴 질의와 site·구문 검색 같은 웹 검색 문법을 활용할 수 있다.
9. 코드·SKU·우편번호·고유명사는 임베딩보다 정확 문자열 매칭이 중요한 대표 사례다.
10. BM25는 대규모 임베딩 추론 인프라보다 단순하고 비용 효율적인 선택이 될 수 있다.
11. 문자열 매칭 결과는 모델이 검색 이유를 이해하고 질의를 수정하기 쉽다.
12. BrowseComp Plus는 약 820개의 수수께끼형 질문과 약 10만 개의 웹 문서로 검색 루프를 평가한다.
13. 필요한 증거를 미리 주면 모델 정확도가 높아져 검색 품질이 핵심 병목임을 보여준다.
14. 모델 컨텍스트는 약 35만 토큰 수준의 플로피 디스크처럼 한정된 작업 공간이다.
15. BrowseComp Plus의 기본 BM25 기준선은 긴 문서에 부적합한 파라미터 때문에 약하게 보일 수 있다.
16. BM25의 구현·파라미터·top-K 가속 방식에 따라 결과와 비용이 크게 달라진다.
17. 검색 문서를 파일시스템형 작업공간에 넣으면 제목·스니펫부터 점진적으로 공개할 수 있다.
18. grep·ripgrep·sed·awk·bash는 BM25와 결합해 모델의 코드 도구 사용 능력을 확장한다.
19. 다중 질의 에이전트는 단일 질의 NDCG보다 최종 답 정확도와 과업 성공률로 평가해야 한다.
20. BM25와 파일 도구를 결합한 설명 가능한 검색 경로는 현재 에이전트 인프라의 강력한 기본 설계다.