Mistral이 Agentic Search를 공개했다. 문서 검색을 한 번의 호출로 끝내는 방식에서 여러 단계를 거치는 방식으로 바꾼 것이다. 시스템은 모델에 search, open, navigate, read, grep이라는 다섯 가지 도구를 제공한다. 모델은 먼저 한 차례 검색한 뒤 일치하는 파일을 열어 살펴보고, 해당 섹션까지 넘겨 읽는다. 읽어보고 이상하다 싶으면 키워드를 바꿔 다시 검색하고, 확인이 끝난 뒤에야 답을 낸다.
이 방식은 두 벤치마크에서 상당한 개선폭을 보였다. 미국 상장기업의 SEC 공시 자료를 다루는 FinanceBench에서는 정답률이 26.7%에서 86%로 세 배 넘게 뛰었다. 미국 재무부 공보를 소재로 하는 OfficeQA Pro에서도 6.3%에서 51.9%로 45.6포인트 상승했다.
단발성 검색은 어디서 막히나
표준 RAG는 문서를 청크로 나누고, 벡터를 계산하고, 질문과 가장 유사한 청크 몇 개를 불러와 컨텍스트에 끼워 넣어 모델이 답하게 하는 방식이다. 이 파이프라인은 '특정 연도 매출이 얼마인가' 같은 질문에는 충분하지만, '지난 3년간 잉여현금흐름을 나열하고 산정 기준 변경까지 설명하라'는 질문 앞에서는 무너지기 시작한다.
이런 실패는 청크 분할 단계에서부터 이미 심어진다. 재무제표 속 숫자 하나를 제대로 읽으려면 대개 세 가지가 필요하다. 표 안의 값, 표 아래 각주, 그리고 앞쪽 어딘가에 있는 회계 기준에 대한 설명이다. 이 세 가지는 수십 페이지씩 떨어져 있는 경우가 많은데, 벡터 검색은 의미적 유사도로 순위를 매기기 때문에 각주나 기준 설명은 상위권에 들지 못하는 경우가 대부분이다. 모델은 고립된 숫자 하나만 받아 그대로 읽을 뿐이고, 틀려도 알아채지 못한다.
다단계 검색은 이 과정을 사람이 문서를 넘겨보는 방식에 가깝게 복원한다. 먼저 위치를 찾고, 펼쳐보고, '자세한 내용은 주석 12 참조'라는 문구가 나오면 그쪽으로 넘어갔다가 다시 돌아온다. grep이라는 도구가 포함됐다는 사실 자체가 시사하는 바가 크다. 벡터 검색은 모호한 의미 매칭에 강하지만, 'Note 12' 같은 정확한 문자열을 찾을 때는 오히려 옛날 방식의 전문 검색이 더 믿을 만하다. 두 검색 방식이 같은 도구 모음 안에서 각자의 몫을 맡는 셈이다.
여기에는 놓치기 쉬운 이점도 숨어 있다. 단발성 검색의 답은 추적이 불가능하다. 모델이 매출을 특정 숫자라고 답해도, 사용자가 그 숫자가 어느 페이지에서 나왔는지 알고 싶다면 직접 문서를 다시 뒤져야 한다. 다단계 검색은 모든 단계가 명시적인 도구 호출이어서, 어떤 파일을 열었는지, 어느 섹션으로 넘어갔는지, 어떤 문자열이 일치했는지가 전부 기록으로 남는다. 금융·법무 분야에서는 이 경로 자체가 결과물의 일부이며, 정답을 맞히는 것만으로는 부족하고 왜 맞는지 증명할 수 있어야 한다.
몇 번 더 돌수록 오히려 절약된다
다단계 작업은 상식적으로 라운드도, 토큰도, 대기 시간도 늘어나야 한다. 그런데 Mistral이 공개한 수치는 정반대였다. 토큰 사용량은 최대 33.7% 줄고, P90 지연 시간은 39.6% 감소했으며, FinanceBench 기준 255초이던 것이 154초로 단축됐다.
이 수치가 성립하는 전제는 비교 대상에 있다. 단발성 RAG는 놓치는 것을 막기 위해 검색 청크 수를 크게 잡는 경향이 있어서, 20개, 80개씩 컨텍스트에 밀어 넣는데 그중 대부분은 질문과 무관하다. 다단계 검색은 매 라운드마다 필요한 부분만 읽는다. 라운드 수는 늘지만 한 번에 들어가는 입력량은 짧아서, 총량으로 계산하면 오히려 절약된다.
지연 시간 쪽은 엔지니어링에 좌우되는 정도가 더 크다. P90이 낮아졌다는 것은 '검색 실패, 모델이 숫자를 지어냄, 답이 엉뚱함, 다시 돌려야 함' 같은 롱테일 케이스가 줄었다는 뜻이다. 단발성 검색의 실패는 조용히 일어난다. 모델은 자신이 각주를 못 찾았다는 사실조차 모른다. 다단계 검색에서는 모델이 스스로 못 찾았다는 것을 알아채고 다시 검색하기 때문에, 오히려 롱테일이 좁아진다.
중국어 문서에서 넘어야 할 두 가지 고비
Mistral이 제공하는 형태는 Search Toolkit과 Libraries로, 이미 Studio와 Vibe에 통합돼 있으며 클라우드와 온프레미스 배포를 모두 지원한다. 온프레미스 지원은 금융, 의료, 행정처럼 문서를 외부로 내보낼 수 없는 업종에는 필수 조건이며, Mistral은 이를 줄곧 미국 업체들과의 차별점으로 내세워 왔다.
이 방식을 중국어 문서에 적용하면 새로운 두 가지 문제에 부딪힌다. 첫째는 grep이다. 중국어에는 단어 경계가 없어서 정확 일치 매칭의 이점이 영어보다 작고, 대략 계산해도 매칭 노이즈가 상당히 높아진다. 둘째는 중국 국내 투자설명서, 연차보고서, 정책 문서 상당수가 스캔 이미지와 비표준 표를 대거 사용한다는 점이다. read 단계가 표 구조를 제대로 복원할 수 있는지가 이후 단계들이 '읽는' 것인지 '추측하는' 것인지를 그대로 가른다.
주의해야 할 또 다른 지점은 벤치마크 자체다. FinanceBench와 OfficeQA Pro는 둘 다 공개된 문제 세트로, 문제와 원문서가 이미 오래전부터 온라인에 돌아다녔다. 어느 업체든 자사 시스템으로 이 벤치마크를 돌리면 학습 데이터 오염 가능성을 피하기 어렵다. 26.7%라는 출발점은 눈에 띄게 낮은데, 이것이 어떤 RAG 구성에 해당하는지, 검색 청크 수를 얼마로 잡았는지, 어떤 기반 모델을 썼는지는 공식 발표에서 밝히지 않았다. 개선 방향은 신뢰할 만하지만, 배수는 어느 정도 할인해서 봐야 한다.
가격은 아직 공개되지 않았다. 기업 구매 담당자에게는 이 부분이 매우 중요하다. 다단계 검색은 질의응답 한 번당 여러 차례의 모델 호출을 유발하므로, 호출 단위로 과금한다면 86%라는 정답률을 얻는 데 단가의 몇 배가 들 수 있고, 비용 계산을 다시 해야 한다.
참고 출처: Mistral 공식 발표, CocoLoop; FinanceBench와 OfficeQA Pro의 정답률, 토큰 절감폭, P90 지연 시간 수치는 항목별로 대조 확인했다.