에이전트 검색은 정확도를 8.7점 올리고 비용은 160배로 늘린다

무엇인가

이 논문이 다루는 문제는 dense retrieval이 표면적인 의미 유사도에만 의존한다는 것이다. 질의와 문서 임베딩의 코사인 유사도로 top-k를 뽑는 방식은 표적형 검색 질의에는 잘 맞지만, 수학 문제에서 유용한 정리를 찾거나 도구 명세를 찾는 것처럼 질의와 정답 문서 사이에 표면적 유사도가 거의 없는 과제에서는 무너진다. RAG와 DeepResearch 같은 워크플로가 퍼지면서 검색 과제 자체가 표적형 질의에서 고수준이고 추상적인 과제 설명으로 옮겨가고 있고, 여기에는 추론, 실제 시스템 동역학에 대한 지식, 반복 탐색이 필요하다는 것이 저자들의 진단이다.

어떻게 동작하나

제안 방법은 NeMo Retriever Agent다. LLM의 추론 능력과 세계 지식, dense retriever의 대규모 코퍼스 탐색 능력을 ReAct 루프 안에서 결합한다. 기존의 정적 파이프라인(LLM이 질의를 한 번 재작성해 retriever에 넘기는 방식)과 달리, LLM이 검색을 언제, 몇 번, 어떤 질의로 호출할지 스스로 정하고 새로 발견한 정보에 따라 전략을 바꾼다. 구현은 ReAct 루프와 JSON 스키마 기반 표준 도구 호출로 되어 있다. 시스템 프롬프트에 과제 목표(관련 문서를 모두 찾는 것)와 각 도구 설명을 넣고, 첫 사용자 메시지에 원래 질의와 함께 그 질의로 dense retriever가 이미 검색한 초기 문서들을 포함시킨다. 이 초기 결과는 불필요한 탐색을 줄이고, 코퍼스에 어떤 유형의 문서가 있는지(수학 정리인지 함수 설명인지) 에이전트가 파악해 이후 질의를 조정하게 해준다.

무엇과 다른가

에이전트가 쓸 수 있는 도구는 세 가지다. Retrieve는 질의와 정수 k를 받아 코사인 유사도 기준 top-k 문서를 고유 ID와 함께 반환한다. Think는 문자열 사고를 받아 복잡한 질의 추론이나 탐색 계획을 위한 토큰을 추가 생성하며 환경을 바꾸지 않는다. Final_Results는 관련도 순으로 정렬한 k개 문서 ID 목록과 선택 근거를 받아 상호작용을 종료하는데, 문서 개수가 틀리면 오류를 반환하고 재시도를 요구한다. 신뢰성 측면에서는 컨텍스트 윈도 초과나 콘텐츠 위반 오류가 나면 오류 전까지의 각 검색 시도 순위 목록을 모아 RRF(Reciprocal Rank Fusion)로 병합해 최종 점수를 계산하는 폴백을 둔다. 인프라에서는 MCP 서버를 걷어냈다. 검색 에이전트는 적은 수의 도구를 여러 번 호출하는데, MCP는 실행마다 서버를 띄우고 코퍼스 임베딩을 GPU 메모리에 올리고 클라이언트·서버 수명주기를 관리해야 하며 네트워크 왕복이 매 호출에 지연을 더한다. 대신 에이전트와 같은 프로세스에 사는 스레드 안전 싱글턴 retriever를 두어 모델과 임베딩을 한 번만 로드하고, 재진입 락으로 접근을 보호하며, 동시 에이전트 여러 개에 같은 retrieve() 인터페이스를 노출한다.

어떻게 쓰나

실험은 복잡한 검색용 벤치마크 두 개에서 이뤄졌다. ViDoRe v3는 6개 언어, 10개 도메인(금융, 제약, 정부 에너지 보고서 등)을 아우르는 기업 문서 검색 벤치마크로 추출형, 멀티홉, 수치 추론 등 7가지 질의 유형을 포함한다. BRIGHT는 논리 연역, 코드 이해, 수학 추론 같은 추론 집약적 텍스트 검색을 측정한다. LLM은 Opus 4.5와 오픈소스 대표로 gpt-oss-120b를, retriever는 ViDoRe v3에 colembed-vl-8b-v2, BRIGHT에 llama-nv-reasoning-3b를 쓰고 더 작은 llama-nemotron-1b 결과도 함께 보고한다. 핵심 수치는 같은 임베딩 모델을 쓸 때 에이전트 검색이 표준 검색보다 nDCG@10을 평균 8.7점 높인 것이다. 추론 능력의 중요성도 드러나는데, 각 데이터셋의 최고 임베딩 모델 기준으로 Opus 4.5를 쓴 에이전트가 gpt-oss-120b 파이프라인보다 평균 6.2점 높고, 추론 요구가 큰 BRIGHT에서는 격차가 9.5점이다. ViDoRe v3에서 Opus 4.5는 질의당 평균 9.2회 검색을 호출한 반면 gpt-oss-120b는 2.4회에 그쳤고, 저자들은 이 제한된 탐색 능력을 성능 차이의 한 원인으로 본다. 또 에이전트 검색은 임베딩 모델 간 성능 격차를 평균 57%, 즉 거의 절반으로 줄여, 작은 임베딩 모델의 한계를 부분적으로 보상한다.

전제와 한계

일반화도 이 논문의 주장이다. 2026년 3월 13일 기준으로 이 에이전트는 ViDoRe v3 리더보드 1위, BRIGHT 리더보드 2위를 기록했다. 반대로 BRIGHT 1위 방법인 INF-X-Retriever를 ViDoRe v3에서 평가하면 성능이 크게 떨어지고, 그 파이프라인에 에이전트가 쓰는 retriever를 그대로 끼워 넣어도 표준 검색 베이스라인보다 못한 결과가 나온다. 같은 에이전트가 수정 없이 두 벤치마크 모두에서 경쟁력 있는 결과를 낸다는 점이 동적 적응의 가치라는 것이다. 성공 패턴으로는 새 정보에 따라 이후 질의를 조정하는 질의 정교화, 유용한 정보를 찾을 때까지 질의를 계속 바꾸는 끈질긴 재표현, 복잡한 다중 질의를 목표가 분명한 단순 질의 여러 개로 쪼개는 복잡도 분해가 반복적으로 관찰됐다.

비용은 정면으로 인정된다. 표준 검색이 질의당 0.67초인데 에이전트 검색은 평균 107.45초가 걸리고, 질의당 입력 764.1K 토큰과 출력 5.8K 토큰을 소비한다. 저자들은 LLM 추론의 추가 오버헤드가 대규모 배포에서 에이전트 검색의 주된 한계라고 말한다. 비용 구조 자체가 다르다는 점도 짚는다. 표준 검색의 비용은 주로 검색 인덱스 크기, 즉 코퍼스 크기에 연동되지만 에이전트 검색은 추론 단계 수와 소비 토큰이라는 새 축이 생기고, 이는 질의 복잡도와 에이전트의 동적 행동에 좌우된다. 따라서 근사 최근접 이웃 검색 같은 인덱스 비용 제어 수단에 대응하는, 토큰과 추론 비용을 응용에 맞게 조절하는 장치가 앞으로 필요하다는 것이 제안이다.

개발자 관점에서 이 논문이 주는 판단 기준은 명확하다. 질의가 좁고 표적형이라면 기존 dense retrieval이 여전히 0.67초로 압도적으로 싸다. 반면 기업 문서 검색이나 수학·코드 추론처럼 질의와 정답 문서 사이 의미 유사도가 낮고 여러 단계 추론이 필요한 과제라면 에이전트 검색이 같은 임베딩 모델로 8.7점을 더 준다. 도입 전에 확인할 것은 질의당 지연과 토큰 예산, 오류 시 RRF 폴백 동작, 그리고 인프라 선택이다. 저자들은 MCP 기반 도구 노출이 검색 에이전트에는 부적합하다고 실측으로 말하며 인프로세스 싱글턴 retriever를 권하고, 검색에서는 한 턴에 여러 검색을 던지는 병렬 도구 호출이 순차 호출보다 낫다고 지적한다. 오픈소스 모델이 독점 모델에 뚜렷하게 뒤처진다는 점도 도입 모델 선택 시 감안해야 한다.

저자들이 밝힌 한계는 비용과 효율이다. 성능 향상은 실질적이지만 추가 연산 요구가 크고, 규모 있게 배포하려면 더 비용 효율적인 검색 에이전트 연구가 필요하다고 스스로 못 박는다. 또한 검색 에이전트는 dense retriever와 달리 컨텍스트 윈도 초과나 콘텐츠 위반 오류 등 여러 이유로 최종 문서 목록을 내기 전에 실패할 수 있어 RRF 폴백에 의존하며, 평가는 ViDoRe v3와 BRIGHT 두 벤치마크에 한정되어 있다.