«Какая нейросеть лучше для документов» — вопрос, на который честно нельзя ответить названием модели. Модель — только один слой связки; результат определяет то, что вокруг неё построено: как проверяются кандидаты, что происходит при сбое, где система признаёт свои границы вслух. Этот текст — не рейтинг из десяти инструментов, а разбор самого класса задач: что нейросеть в работе с документами действительно умеет, где она ломается предсказуемо, а не случайно, и какие вопросы стоит задать любому, кто вам её продаёт.
Коротко. Нейросеть в документах хорошо справляется с тремя вещами: определить тип документа, извлечь из него структурированные поля и подобрать, какому месту в процессе он соответствует. Ломается она не случайно, а системно — уверенно ошибается на редком формате, молча теряет уверенность на плохом скане, путает разряды в длинной таблице. Производственная связка отвечает на это двумя опорами: подобранное соответствие — это гипотеза для проверки, а не готовая запись, и смена модели при сбое не проходит незамеченной. Оценивать стоит не модель по названию, а эту связку целиком.
Что нейросеть действительно умеет в документах
В производственном контуре у модели три работающие роли, и держать их порознь важнее, чем кажется, потому что каждая опирается на разные данные и ошибается по-своему.
Первая роль — классификация: понять, какой документ перед ней, не читая его целиком глазами. В тендерном пакете это означает отличить устав от выписки, техническое предложение от сметы, лицензию от банковской справки — по структуре и характерным признакам текста, а не по имени файла, которое участник мог назвать как угодно.
Вторая роль — извлечение: превратить неструктурированный текст в конкретные поля. Из сметы — наименование позиции, единицу измерения, ставку, итог. Из лицензии — номер, дату выдачи, вид деятельности. Из технического предложения — заявленные сроки и объёмы. Разница между «прочитать документ» и «извлечь поле» здесь принципиальная: извлечение подразумевает, что дальше с этим значением будет работать другой процесс, а значит, поле должно прийти в предсказуемом виде, а не вольным пересказом.
Третья роль — сопоставление: связать извлечённое с местом, куда оно должно встать, — пунктом чек-листа заявки, позицией каталога услуг, слотом формы. Здесь модель не изобретает соответствие с нуля, а выбирает наиболее вероятный вариант из ограниченного набора возможных — и именно на этом шаге начинаются вопросы, разобранные в следующих разделах.
Все три роли работают на одном и том же материале — документах пакета, независимо от того, пришли они уже в цифровом виде или как скан. Как устроено извлечение текста из отсканированной страницы, прежде чем к ней вообще применить классификацию или извлечение полей, — отдельный разбор распознавания документов; здесь эта часть не пересказывается.
Автоматическое перенесение найденных значений обратно в форму заявки, которую заказчик прислал в собственном шаблоне, — следующий логичный шаг после сопоставления, и ему тоже стоит отдельного разговора.
Где она ломается — систематически, а не случайно
Важно сразу отделить одно от другого: перечисленное ниже — не список недоработок конкретного продукта, а свойства самого класса моделей. Любая нейросеть в этой роли ломается похожим образом, потому что причины лежат в природе задачи, а не в качестве конкретной реализации.
Первый и самый коварный сбой — уверенная ошибка. Модель не отвечает «не знаю» там, где данных недостаточно: она достраивает правдоподобное значение и выдаёт его с той же интонацией, что и верный ответ. Для поля «ставка» это может означать значение, которое выглядит разумным числом, но не взято из текста документа, а сконструировано моделью по контексту. Отличить такую ошибку от правильного извлечения на глаз почти невозможно — именно поэтому проверка не может полагаться на то, что явная ошибка выглядит явно.
Второй сбой — молчаливое падение уверенности на плохом скане, если её вообще никто не измеряет. Само по себе снижение качества входа неизбежно: слепой скан, смазанная фотография, битый файл. Проблема не в том, что уверенность падает, а в том, что система может не сообщить об этом падении вовсе — и тогда результат низкого качества выглядит так же аккуратно оформленным, как результат высокого.
Третий — незнакомый формат или вёрстка. Модель, обученная на типовых макетах документов, спотыкается там, где заказчик свёл таблицу нестандартно, объединил столбцы или расположил поля в неожиданном порядке. Это не исключение, а рабочий режим входящего потока, и относиться к нему нужно соответственно.
Четвёртый — числа и единицы измерения. Спутать ставку за единицу с итоговой суммой по строке, принять количество за номер позиции, потерять единицу измерения при переносе значения — эти ошибки особенно опасны именно потому, что итог выглядит правдоподобным числом в любом случае.
Пятый — длинные таблицы. Чем длиннее таблица, тем выше вероятность, что модель потеряет связь между строкой и заголовком где-то в середине, особенно если структура таблицы не идентична от страницы к странице внутри одного файла.
Обе колонки описывают саму технологию как класс, а не один конкретный продукт.
Опора 1: совместимость вместо похожести
Первое, что должна делать production-связка вокруг модели, — не доверять голому текстовому сходству. Слоты, которые нужно заполнить (пункт чек-листа заявки, позиция каталога, поле формы), и документы, которые могут в них встать, принадлежат ограниченному набору типовых кластеров совместимости: банковский слот совместим с банковскими документами, слот подтверждения полномочий — с уставом и протоколом, и так далее. Функция match_checklist сначала определяет, к какому кластеру относится слот, и только внутри допустимого кластера ищет подходящий документ — а не перебирает весь пакет по степени текстовой похожести.
Разница здесь не абстрактная. Устав компании может по формулировкам оказаться ближе к тексту банковской справки, чем реальная справка с непривычной шапкой конкретного банка, — если сравнивать голым сходством текста. Ограничение поиска рамками кластера совместимости снимает такой вариант заранее: устав не попадает в предложенные кандидаты для банковского слота — он вне допустимого кластера, независимо от того, насколько похожи отдельные фразы.
Второе, что стоит понимать про этот шаг: результат сопоставления — это гипотеза, ожидающая подтверждения, а не запись, которая сама ложится в заявку. Даже когда найденный документ выглядит очевидным совпадением внутри своего кластера, система не закрепляет его автоматически — она подсвечивает вариант и оставляет решение специалисту, который видит контекст конкретной закупки и может заметить то, что осталось за пределами формальной проверки. Почему автопривязка выключена намеренно — и что ещё мы сознательно отказались строить — разобрано в «Что мы пробовали автоматизировать в документах — и отказались».
Опора 2: деградация не имеет права быть тихой
Вторая опора связки касается не отдельного документа, а самой модели, которая работает под капотом. Основная модель — YandexGPT. Когда она недоступна или отвечает со сбоем, система автоматически переключается на резервную — DeepSeek — и при каждом таком переключении отправляет команде алерт. Алерт устроен с ограничением частоты: не каждый отдельный запрос поднимает новое уведомление, а сама смена состояния — переход с основной модели на резервную и обратно.
Принцип за этим решением простой и жёсткий: замена модели без уведомления — это молчаливое изменение качества результата. Пользователь, который не знает, что его документы сейчас обрабатывает резервная модель вместо основной, не может учесть эту разницу ни в чём — ни в том, каким пунктам довериться сразу, ни в том, что стоит перепроверить внимательнее. Уведомление о переключении не устраняет саму деградацию, но переводит её из скрытого события в наблюдаемое: команда видит факт переключения в момент, когда он произошёл, а не узнаёт о нём постфактум из жалобы пользователя.
Смена состояния — переход на резервную модель и обратно — всегда сопровождается уведомлением команды.
Как оценивать «нейросеть для документов», когда вам её продают
Рейтинг из десяти инструментов почти всегда отвечает не на тот вопрос: у него нет способа показать, что происходит внутри связки в нештатной ситуации — на это способна только серия правильных вопросов, заданных напрямую.
Что происходит с нечитаемым сканом? Продукт, который либо молча выдаёт пустой результат, либо всегда что-то «прочитывает», не сообщая об уровне уверенности, прячет именно ту информацию, которая нужна перед тем, как довериться результату. Разбор того, как выглядит устроенный ответ на этот вопрос, — в материале про распознавание документов.
Как я узнаю, что модель подменили или она деградирует? Если ответ — «вы не узнаете, просто доверяйте системе», это повод насторожиться: без наблюдаемого сигнала о переключении пользователь остаётся с более слабым результатом и без единого шанса это заметить вовремя.
Система сама привязывает результаты сопоставления или только предлагает их? Разница между «сохранено автоматически» и «найден вероятный кандидат, ждёт подтверждения» — это разница между продуктом, который берёт на себя ответственность за решение, и продуктом, который берёт на себя только черновую работу.
Какие форматы честно вне охвата? Любой пайплайн разбора документов имеет границу поддерживаемых форматов — она задаётся тем, для каких структур можно гарантировать качество разбора. Продукт, который заранее называет эту границу, стоит больше доверия, чем тот, что обещает работать со всем подряд, а границу вы обнаружите сами на важном документе в разгар подготовки.
Где хранятся данные и кто к ним имеет доступ? Документы тендерного пакета часто содержат сведения о компании и её финансовом положении — вопрос о хранении не формальность, а часть той же оценки надёжности связки.
Что происходит с документом, который система не распознала или не поняла? Это, пожалуй, самый честный вопрос из всех: он проверяет не то, что продукт умеет показать в демо на удачном примере, а то, как он ведёт себя именно в момент неудачи. Слабая связка в такой ситуации либо тихо пропускает документ, как будто его и не было, либо возвращает что-то правдоподобное, не признавая, что уверенности в этом результате нет, — и в обоих случаях пользователь остаётся без сигнала о том, что здесь нужно вмешаться самому. Устроенная связка поступает иначе: непонятый документ остаётся видимым в результате как отдельный, явно помеченный случай, а не исчезает и не маскируется под обработанный. Разница между этими двумя поведениями не видна на демонстрации, где заранее подобранные документы читаются без сбоев, — она проявляется только на реальном, неотобранном потоке, и именно поэтому стоит спросить об этом прямо, а не полагаться на то, что демо покажет всё само.
Так «лучшая нейросеть для документов» превращается не в имя победителя рейтинга, а в набор критериев, которым связка либо отвечает, либо нет — и это более честный и более полезный результат разбора, чем любой топ-10.
Границы и наш контур
Всё описанное выше — только один слой внутри всего пакета участника; о том, где нейросеть встроена в общую анатомию этого пакета и что остаётся за её пределами, — в разборе анатомии тендерного пакета целиком.
Честный разбор класса технологии обязан назвать не только то, что он делает, но и то, чего сознательно не делает.
Проверка юридических документов — договоров, соглашений, их условий — отдельный класс задач с собственными рисками и собственной квалификацией, и мы им не занимаемся. Это не временное ограничение и не то, что «скоро добавим», — это осознанная граница контура: юридическая экспертиза требует ответственности, которую распознавание и сопоставление структурированных полей не несёт и нести не должно.
Запрос «нейросеть для документов» иногда приводит и тех, кто на самом деле искал совсем другую задачу — обработку фотографий для документов, вроде фото на паспорт. Это то же самое слово, обозначающее другую сферу: здесь речь не о ней.
Творческое создание документов с нуля — написание текста делового письма, черновика соглашения, произвольного контента — тоже не то, чем занимается этот контур. Он работает не с созданием текста, а с потоком закупочных документов: прочитать то, что уже существует, разложить по структуре, предложить, куда это встаёт.
К этим трём границам стоит добавить четвёртую, более техническую: ввод документов в контур устроен по уровням — не потому что где-то не хватило времени доработать, а потому что для одних структур можно гарантировать качество разбора, а для других на текущем этапе нельзя. Часть форматов и вложенных структур пока честно остаётся вне этих уровней, и лучше сказать об этом прямо, чем позволить пользователю обнаружить границу самому, уже на реальной закупке. Это тот же принцип, что и с юридической экспертизой выше: граница называется вслух, а не маскируется общими обещаниями.
Внутри этих границ мы в Кельве строим ровно такую связку: часть, которая классифицирует документ, извлекает поля и предлагает совместимые соответствия, работает в проде начиная с 8 апреля 2026 года. Роль нейросети в ней — предлагать гипотезы на основе структурированных данных; закреплять решение, отвечать за итоговую заявку и замечать то, что осталось за пределами формальной проверки, — по-прежнему работа специалиста, который эту заявку подписывает.
