Mistral превратила поиск по документам в управляемое расследование

Поиск становится циклом действий

Mistral представила Agentic Search как retrieval layer для работы с длинными, плотными и разнородными корпоративными документами. Вместо единственного запроса к индексу и ответа по нескольким найденным chunks модель получает возможность последовательно искать, изучать и проверять информацию. Продукт доступен через Mistral Search Toolkit и встроен в Libraries внутри Studio и Vibe; его можно использовать в cloud и on-premises окружениях, не вынося чувствительные данные за заданные границы изоляции.

Ключевое отличие от one-shot RAG — право агента признать первый результат недостаточным. Если нужная цифра скрыта в таблице, ссылка ведёт в другой отчёт или вопрос требует сопоставить несколько файлов, система может уточнить запрос, открыть перспективный документ и прочитать конкретный фрагмент. Индекс по-прежнему определяет вероятные источники, но окончательный маршрут по ним строит модель. Это смещает retrieval с механического top-k отбора к наблюдаемому процессу исследования.

Пять tools вместо неограниченного доступа

Agentic Search строится вокруг пяти операций: search ищет документы по существующему индексу, open открывает выбранный файл, navigate переводит к странице, секции или области, read извлекает содержимое в указанной точке, а grep находит шаблон внутри открытого документа. Такой набор напоминает файловую навигацию, но оставляет retrieval в узком предметном контракте. Агент не получает произвольный shell: он действует через понятные операции, которые можно логировать, ограничивать и воспроизводить.

Mistral подчёркивает, что tools не требуют fine-tuning или отдельного обучения под конкретную модель. По мере улучшения reasoning и tool use тот же retrieval stack способен давать более качественные маршруты без полной замены инфраструктуры. При этом foundation остаётся прежним: ingestion, parsers, chunking, embeddings, Vespa schemas и ranking должны быть настроены корректно. Agentic loop не отменяет индекс, а добавляет над ним способность исследовать материал после первого поиска.

Почему обычного RAG бывает недостаточно

One-shot RAG хорошо работает, когда ответ уже присутствует в одном из первых chunks. Сложность начинается в финансовых отчётах, договорах, manuals, technical specifications и scanned PDFs: смысл может зависеть от строки таблицы, подписи, сноски или соседней страницы. Если первоначальная выдача неполна, обычная схема всё равно просит модель ответить на её основе. Она не может самостоятельно запросить другой раздел, проследить ссылку или проверить, совпадают ли значения в нескольких документах.

В демонстрационном примере вопрос требует сложить помесячные расходы США за 1953 год. Первый поиск находит бюллетени лишь за часть периода, тогда как Agentic Search выполняет второй уточнённый запрос, находит Treasury Bulletin с полной таблицей на странице 15 и читает её перед расчётом. Важно не само полученное число, а траектория: система сохраняет промежуточную нехватку данных и меняет маршрут, вместо того чтобы достраивать отсутствующие месяцы вероятным ответом.

Заявленные результаты на FinanceBench

На FinanceBench компания тестировала 150 вопросов по 368 документам SEC объёмом около 53 900 страниц. По данным Mistral, переход от one-shot RAG к циклу только с повторным search дал прирост точности на 47,3 процентного пункта для Mistral Medium 3.5 и на 52,6 пункта для GLM-5.2. Добавление open, navigate, read и grep принесло ещё 8,7 и 6,7 пункта соответственно. В сводном описании компания указывает рост корректности с 26,7% до 86%.

Навигация при этом не стала простой надбавкой к расходам. В сравнении с search-only loop полный вариант снизил token usage на 23,9% для Mistral Medium 3.5 и на 33,7% для GLM-5.2. p90 latency уменьшилась с 255 до 154 секунд, средняя — со 108 до 71 секунды. Объяснение авторов практично: точечное чтение заменяет повторные широкие поиски, которые тратят контекст, но не приближают модель к нужному доказательству.

OfficeQA Pro проверяет глубокую навигацию

Второй benchmark, OfficeQA Pro, состоит из числовых вопросов по 696 историческим Treasury Bulletins — примерно 89 000 страниц scanned и table-heavy документов. На подмножестве из 133 вопросов GLM-5.2 с полным agentic loop достиг 51,9% против 6,3% у one-shot RAG, то есть прибавил 45,6 процентного пункта. Для Mistral Medium 3.5 рост составил 27,1 пункта. Навигационные tools дополнительно улучшили результат обеих моделей и одновременно сократили число turns и расход токенов.

Эти цифры нужно читать в заявленных границах. Mistral использовала out-of-the-box Search Toolkit с default chunking и ranking, ответы FinanceBench оценивал LLM judge, а результаты OfficeQA Pro относятся к конкретному набору вопросов и harness. Компания называет показатели нижней границей для последующей настройки, но они не гарантируют такой же прирост на другом corpus. Перед production rollout команде всё равно нужен собственный eval с реальными документами, правами доступа и типичными ошибками OCR.

Где agentic retrieval действительно оправдан

Mistral рекомендует Agentic Search для длинных документов, вопросов по нескольким источникам, проверяемых ответов и таблиц, где важна позиция на странице. Для коротких чистых файлов, массовой выдачи passages и предсказуемых direct lookups обычный indexed retrieval остаётся разумнее. Это полезное ограничение: агентный цикл добавляет свободу выбора и наблюдаемые шаги, но для простого запроса его latency и orchestration не обязательно окупятся.

Начать можно с Search Starter App, который создаёт локальный индекс с default configuration. Дальше разработчик выбирает parsers и extractors, настраивает chunking, embeddings, Vespa schemas и relevance profiles, а при необходимости добавляет query rewriting, reranking или hybrid retrieval. Для эксплуатации важнее всего хранить полную trajectory: запросы, открытые документы, прочитанные области и финальные ссылки. Тогда рост accuracy не приходится принимать на веру — каждый ответ можно связать с конкретным фрагментом источника.