Миллион токенов или поиск по документам: что надёжнее для рабочего архива

После появления моделей с контекстом до миллиона токенов у команды возникает соблазн отказаться от поиска по документам: зачем строить индекс, если можно отправить весь архив в одном запросе? Ответ зависит не от размера окна в описании модели, а от того, как устроен архив. Сто документов, которые редко меняются, и сто тысяч файлов с новыми редакциями каждый день — разные задачи. Мы сравним два рабочих маршрута на одном примере и обозначим случаи, где каждый из них может подвести.

Маршрут А: документы полностью или крупными пачками помещаются во вход модели. Маршрут Б: система сначала находит несколько релевантных фрагментов, затем передаёт их модели вместе с вопросом. Второй подход часто называют поиском с дополнением ответа, или RAG. Здесь важно сравнивать не модные названия, а полный процесс: подготовку файлов, поиск, ответ, ссылки на первоисточник и время проверки человеком.

Пример, на котором различие видно сразу

Представим отдел снабжения с 420 договорами и приложениями за три года. Сотрудник спрашивает: «Какая редакция пункта о сроках поставки действовала для контрагента в феврале?» В архиве лежат договор, два дополнительных соглашения и переписка. В одном файле срок 30 дней, в другом — 45, а письмо содержит ещё одну, не подписанную сторонами формулировку. Правильный ответ требует не только найти число, но и установить, какой документ имел силу на конкретную дату. Если модель уверенно выдаст 45 без ссылки на подписанное соглашение, ответ нельзя принимать.

При маршруте с длинным контекстом команда может положить связанные файлы в один запрос и попросить указать страницу и точную цитату. Это удобно, когда набор невелик и уже собран человеком. Но если загрузить все 420 договоров сразу, высокая ёмкость окна не гарантирует внимания к нужному фрагменту. В рабочем потоке чаще разумно сузить набор хотя бы до контрагента и периода.

При маршруте с поиском система получает вопрос и извлекает подходящие фрагменты. Он быстрее на большом, постоянно меняющемся архиве, но именно поиск может не найти дополнительное соглашение или выдать неподписанное письмо первым. Модель тогда отвечает на неполных данных. Поэтому качественная поисковая выдача должна показывать не только похожие куски текста, но и тип документа, дату, статус подписания и связь с основной версией.

Сравнение по пяти критериям

Точность на конкретном вопросе. Длинный контекст даёт модели больше исходных сведений, но добавляет отвлекающие редакции. Поиск уменьшает шум, зато рискует потерять решающий фрагмент на этапе извлечения. Для проверки задайте вопросы с известным ответом и по одному вопросу без ответа в архиве. Считайте критической ошибкой и неверное число, и правильное число с неправильным основанием.

Обновление архива. Если в длинный запрос каждый раз попадает вручную собранный пакет, необходимо следить, чтобы он включал последнюю версию. Поисковый индекс требует собственного регламента переиндексации, отметки о задержке и удаления устаревших документов. Здесь нет автоматического победителя: плохо поддерживаемый индекс не надёжнее устаревшего пакета.

Стоимость и задержка. Полная загрузка большого набора при каждом запросе расходует входные токены. Поиск добавляет стоимость подготовки индекса и инфраструктуры, но сокращает объём, который каждый раз читает модель. Сравнивайте стоимость принятого ответа: счёт за API, поддержку индекса, ручную проверку и исправление. Для единичных вопросов настройка поиска может оказаться дороже простого ручного пакета; при ежедневных запросах картина меняется.

Проверяемость. В обоих маршрутах потребуйте ссылку на конкретный файл и страницу или фрагмент. У поискового маршрута можно отдельно оценить полноту найденного набора; у длинного — проверить, не пропущен ли документ в сформированном пакете. Ссылки, придуманные моделью, проверяйте по исходным файлам, а не по уверенности текста.

Конфиденциальность. Большой контекст означает передачу большего объёма данных за один запрос. Поиск может ограничить передачу несколькими фрагментами, но сам индекс становится ещё одним хранилищем чувствительных сведений. Проверьте права доступа, срок хранения и разрешённый способ обработки данных независимо от выбранного маршрута.

Как поставить честный эксперимент

Возьмите 20 вопросов из реальной работы: простые, с несколькими редакциями, с таблицами, с отсутствующим ответом. До запуска сотрудник фиксирует правильный документ и критерий принятия. Затем на одинаковом архиве сравните три варианта: ручной поиск, длинный контекст и поиск плюс модель. Не меняйте промпт после просмотра конкретного неудачного ответа, иначе тест начнёт подгоняться под выборку.

Для каждого варианта сохраняйте найденные файлы, ответ, цитату, время до первого ответа и время до принятия человеком. Если ответ отклонён, запишите точную причину: не найден документ, неверно определена версия, искажена цитата, не указана неопределённость. Пошаговую схему подготовки такой выборки мы дали в гайде по проверке длинного контекста.

Новая Kimi K3.1 Pro делает этот эксперимент актуальным благодаря заявленному большому окну, но её характеристики не доказывают преимущество на ваших файлах. Сравнение версий Kimi и других моделей через общий API можно организовать с отдельными бюджетами и журналом; о границах такого слоя — в обзоре AI Gateway.

Кому какой маршрут выбрать

Для небольшого, редко меняющегося пакета по одному делу начните с ручного отбора документов и длинного контекста. Такой способ проще проверить и не требует поддерживать индекс. Если архив велик, запросы повторяются, а документы постоянно обновляются, поисковый маршрут обычно проще масштабировать; но сначала докажите, что он стабильно находит решающие приложения и версии. Когда цена ошибки высока, используйте гибрид: поиск выделяет кандидатов, человек подтверждает набор, а модель помогает сопоставить выбранные документы. Финальное решение остаётся у ответственного сотрудника.

Частые вопросы. Если весь архив вмещается в окно, нужен ли индекс? Не обязательно, но всё ещё нужны выбор актуальных версий и контроль цитат. Можно ли доверять ссылкам в ответе? Только после открытия исходника. Что делать, если два документа противоречат друг другу? Не просить модель «выбрать правду» молча: показать конфликт, даты и статус документов тому, кто вправе принять решение.