ИИ для анализа документов: что реально работает

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

Что ИИ делает с документами хорошо

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

• Извлечение полей. Номер, дата, стороны, суммы, сроки, предмет договора. Если у документа есть текстовый слой и понятный шаблон, модель возвращает JSON, который дальше проверяет код.
• Суммирование. Договор на сорок страниц превращается в список ключевых условий: что делаем, сколько платим, когда, какие штрафы и порядок расторжения.
• Сравнение редакций. Модель показывает, что изменилось между двумя версиями: суммы, сроки, новые обязанности. Полезна при согласовании договоров и приложений.
• Классификация. Документы раскладываются по типам и адресатам: счёт, акт, договор, заявка, претензия. Это освобождает время на разбор исключений.
• Вопросы по тексту. Можно спросить, где указана ответственность за просрочку или какой срок дан на оплату, и получить ответ со ссылкой на пункт.
• Перевод и двуязычные документы. Китайско-русские контракты и спецификации — отдельный сценарий, где важна точность перевода и сохранение структуры.

Где начинаются ошибки

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

• Сканы без текстового слоя. OCR путает похожие цифры и буквы, теряет столбцы, склеивает строки. Модель видит уже испорченный текст.
• Таблицы и приложения. Колонки сливаются, суммы съезжают, единицы измерения теряются. Для таблиц нужен отдельный парсер, а модель — только для проверки и пояснений.
• Рукописный текст, печати, подписи. Их распознают не всегда. Если в документе важна подпись, модель не заменит визуальную проверку.
• Противоречия внутри документа. В одном разделе срок один, в другом — другой. Модель выберет один вариант и не всегда скажет, что нашла расхождение. Это надо спрашивать отдельно.
• Арифметика. Суммы, НДС, итоги по строкам лучше считать кодом. Модель может объяснить расчёт, но проверять его нужно правилами.
• Юридические выводы. Модель объясняет текст, но не даёт заключение о рисках. Ответственность за решение остаётся на человеке.
• Длинные документы. Даже модели с большим контекстом теряют детали в середине. Надёжнее делить документ на части и сохранять ссылки на страницы.

Сначала текст, потом модель

Модель не читает PDF так, как человек. В запрос уходит текст, поэтому сначала из файла нужно получить содержимое, а уже потом отправлять его в API.

1. Определите типы документов и поля, которые нужны на выходе. Не начинайте с «разбери всё».
2. Заберите текстовый слой PDF библиотекой вроде pdfplumber или PyMuPDF. Если слоя нет, запустите OCR.
3. Уберите колонтитулы, номера страниц и переносы. Сохраните номер страницы у каждого фрагмента.
4. Разбейте текст на части по разделам или страницам. Для каждого фрагмента храните документ и страницу.
5. Отправьте текст в модель с заданием вернуть структуру. Попросите ссылку на страницу или пункт.
6. Проверьте ответ правилами и сохраните рядом с исходником. Так ошибку можно найти и объяснить.

Модель работает с текстом, а не с бумагой. Чем чище текст на входе, тем меньше фантазии на выходе.

Как выбрать модель

Для анализа документов не нужна самая дорогая модель. Сначала разделите задачи: массовое извлечение полей, сложный разбор условий и длинные документы — это разные нагрузки.

• DeepSeek V4-Flash — массовые задачи: классификация, короткие поля, типовые счета. Дешёвый вариант для потока.
• GLM 5.3 — похожие задачи, другой стиль ответов. Подходит, когда нужен второй взгляд на выборку.
• Qwen 3.8 Max — длинные документы и китайско-русские пары. Удобно, когда в одном файле смешаны языки.
• DeepSeek V4-Pro — сложные сравнения, разбор условий, длинные цепочки рассуждений.
• Claude Sonnet 5 и Opus 5 — сложные документы и агентские сценарии, где важна аккуратность формулировок.
• Kimi K3 — длинный контекст, когда нужно удержать большой массив текста.

Начните с дешёвой модели на небольшой выборке, сравните с ручным разбором и только потом повышайте класс. В каталоге Китай-API больше тридцати моделей; ID и актуальные цены — на странице моделей. Формат запросов совместим с OpenAI, поэтому переход на другую модель — это замена ID, а не переписывание кода.

Промпт, который даёт проверяемый результат

Один большой промпт «сделай всё хорошо» работает плохо. Разделите извлечение и проверку. Вот правила, которые снижают число ошибок:

• Опишите роль и границы: «ты извлекаешь поля из договора, не добавляй того, чего нет в тексте».
• Задайте схему ответа: список полей, типы, null для отсутствующих значений. Никаких догадок.
• Попросите ссылку на страницу или пункт для каждого поля. Это ускоряет проверку.
• Дайте два-три примера для неоднозначных полей: что считать суммой, что — предоплатой, что — штрафом.
• Отдельным запросом попросите найти противоречия и пропущенные условия.
• Для таблиц сначала извлеките строки парсером, а модель попросите проверить итоги и объяснить расхождения.

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

Проверка: правила, выборка, человек

Качество анализа документов держится не на модели, а на контуре проверки. Его нужно строить сразу, иначе экономия времени превращается в разбор ошибок.

• Обязательные поля. Если нет номера, даты или суммы, результат не принимается автоматически.
• Форматы. Даты, ИНН и суммы проверяются регулярными выражениями и справочниками.
• Сверка сумм. Строки и итог считает код. Расхождение — сигнал человеку.
• Выборка. Регулярно проверяйте часть документов вручную и считайте ошибки по полям. Так видно, где модель проседает.
• Человек на риске. Деньги, юридические формулировки и персональные данные — зона обязательной проверки.
• Следы. Храните исходный файл, текст, ответ модели, версию промпта и результат проверки. Без этого ошибку не воспроизвести.

Как встроить в рабочий процесс

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

Технически всё сводится к одному запросу на документ или фрагмент. Ключ с лимитом расходов, журнал моделей и токенов, повтор при сбое — этого достаточно для пилота. Если в документах есть персональные данные, сначала проверьте, можно ли передавать их внешнему сервису и какие требования применяются. Разбор этой темы есть в статье про 152-ФЗ и зарубежные API.

Китай-API даёт один ключ к DeepSeek, Qwen, Claude и другим моделям. Можно взять дешёвую модель для потока, а сложные документы отправлять в сильную. Попробовать на своих файлах можно в кабинете, а примеры запросов лежат в открытом репозитории.

Что в итоге

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