Автоматизация работы с бухгалтерскими документами требует надежных технологий извлечения структурированных данных. Несмотря на широкое распространение LLM общего назначения, их использование для распознавания документов связано с системными рисками: галлюцинациями, ошибками восстановления структуры документа, зависимостью результата от формулировки запроса и недостаточной прозрачностью полученного результата. В этой статье разбираем, какие принципиальные ограничения имеют LLM общего назначения и почему автоматическое распознавание первичных документов требует систем принципиально иного класса.
Проблема 1. Модель может придумать то, чего нет в документе
Речь идет прежде всего о таких документах, как УПД, счета, счета-фактуры, акты, товарные накладные и других первичных бухгалтерских документах, содержащих критичные для учета реквизиты и табличные данные. Любой такой документ служит источником сведений, ошибка в которых имеет прямые финансовые и юридические последствия. Нарушение при оцифровке этой информации может привести к неверному отражению операции в учете, искажению налоговой базы, прямым финансовым потерям, доначислениям и штрафам.
При извлечении данных с помощью LLM бизнес сталкивается с системным риском галлюцинаций: при недостаточной визуальной информации модель может достроить отсутствующее значение на основе статистических закономерностей. Опасность в том, что такой результат может выглядеть полностью корректным: соответствовать ожидаемому формату, содержать правдоподобные числа и не вызывать ошибок при последующей обработке. И при этом быть ошибочным.
В результате использование LLM не устраняет необходимость ручной проверки: распознанные значения приходится проверять и корректировать до передачи данных в учетную систему. Даже распознавание для ИИ-агентов не терпит галлюцинаций. А для бухгалтерской автоматизации, где на основе данных из документов держатся все дальнейшие хозяйственные и учетные операции, отсутствие достоверности становится критическим ограничением.
Проблема 2. Распознавание в реальных условиях усиливает галлюцинации
В реальном документообороте товарные накладные, акты, счета и УПД могут поступать в виде PDF, скана, фотографии или изображения после нескольких пересылок и конвертаций. Характерный пример – периферийное распознавание документов на мобильных устройствах при приемке товара на складе. Низкое разрешение, размытость, наклон, плохое освещение, печати, рукописные пометки и артефакты сканирования снижают качество работы LLM и повышают риск галлюцинаций при извлечении данных.
Исследования галлюцинаций LLM показывают, что ухудшение изображения принципиально меняет характер их работы. В 2025 году на NeurIPS был представлен бенчмарк, специально созданный для оценки галлюцинаций моделей на деловых документах, включая счета, изображения которых подвергались размытию, перекрытию и другим видам ухудшения качества. Авторы показали: при визуальной неопределенности модели сильнее опираются на языковые закономерности и значительно хуже распознают собственную неуверенность.
Обучение LLM на конкретных типах документов только усугубляет эту проблему: знание того, что счет обычно содержит номер, дату, ИНН и итоговую сумму, не делает нечитаемый символ читаемым. При недостатке визуальной информации большая языковая модель может компенсировать неопределенность наиболее вероятным значением, опираясь на знакомый ей контекст. В этом заключается еще одно принципиальное ограничение LLM: задача распознавания требует воспроизвести только то, что присутствует на изображении, тогда как генеративная модель по своей природе стремится сформировать наиболее вероятный ответ.
Проблема 3. Ошибки при восстановлении исходной структуры документа
Галлюцинации – не единственный источник ошибок при распознавании документов. В бухгалтерском документе критична не только сама цифра, но и ее место в структуре исходного документа. Распознавание для СЭД и ECM ставит жесткие требования: для учетной системы важно сохранить связи между реквизитами, строками и колонками. Если языковая модель неверно восстановила структуру таблицы, она может верно распознать все реквизиты, но при этом вернуть неправильный результат.
Это особенно актуально для документов с объединенными ячейками, многоуровневыми заголовками, переносами строк, многостраничными таблицами и колонками с похожими числовыми значениями. В ответе модели могут оказаться корректные числа, но не в тех полях, которым они соответствуют. Практические оценки подтверждают этот класс ошибок. В опубликованном в 2026 году руководстве по оценке LLM-извлечения счетов на базе Snowflake Cortex авторы приводят случаи, когда модель извлекала сумму без НДС вместо итоговой, путала продавца и покупателя или возвращала пустое значение вместо номера счета. Для выявления таких ошибок разработчикам пришлось использовать вторую языковую модель в качестве контролера.
Таблицы добавляют новые риски: при повреждении сетки, переносе строки или изменении межстрочного расстояния языковая модель будет восстанавливать структуру по косвенным визуальным и языковым признакам – а не считывать данные напрямую. Для распознавания бухгалтерских документов, где важно сохранить связь каждого значения с конкретным реквизитом, строкой и колонкой, это ограничение LLM становится критическим.
Проблема 4. Качество результата зависит от того, как сформулирован запрос
Результат работы LLM существенно зависит от промта – формулировки пользовательского запроса. Это часть “алгоритма” работы таких систем. Можно попросить модель просто извлечь из счета номер, дату и ИНН. А можно дать ей подробную схему полей, примеры, правила обработки отсутствующих значений и явный запрет на предположения. Результаты в этих двух случаях будут различаться кардинально.
Это подтверждено экспериментально. В исследовании 2026 года авторы протестировали Gemini 1.5 Pro и Mistral-small на счетах за электроэнергию, сравнив 19 конфигураций параметров и шесть стратегий формирования промпта. Разница между простым и продуманным запросом превысила 19 процентных пунктов на одной и той же модели.
Отсюда следует очередная проблема для бизнеса: промпт становится частью системы распознавания. Его нужно тестировать на новых типах документов, поддерживать при изменении требований, проверять при появлении новых полей и пересматривать при каждом обновлении модели. Даже если отбросить в сторону затраты на дополнительный и постоянно растущий слой прикладной инженерии вокруг LLM, такой подход не позволяет быстро масштабировать обработку бухгалтерских документов.
Проблема 5. Результат LLM не гарантирует предсказуемость
Демонстрации систематически переоценивают возможности LLM в прикладных задачах. Реальный документооборот компании не состоит из одного хорошо подготовленного счета. Даже если разработчик заявляет «96% точности» – это не означает, что 96% документов будут верно распознаваться автоматически. Здесь легко попасть в ловушку маркетинговых метрик.
Допустим, система извлекает 96% отдельных полей. Но бухгалтерский документ содержит десятки значимых реквизитов, и если автоматизация требует корректности каждого из них, вероятность точного результата по документу в целом оказывается значительно ниже. Даже в упрощенной модели, если считать ошибки независимыми, при 96% точности каждого поля вероятность безошибочного извлечения 20 полей составляет 0,96²⁰ ≈ 44%.
Связь между неверно распознанным полем и конкретным бизнес-последствием здесь прямая. Пропущенный номер счета разрывает аудиторский след и мешает обнаружить задвоенный платеж, неверная сумма приводит к искажению финансовой отчетности, а неверная дата может привести к отнесению операции не в тот отчетный период. Это последствия, которые становятся видны только тогда, когда ошибочные данные уже прошли дальше по цепочке.
Проблема 6. Непрозрачность результата распознавания LLM
Для распознавания документов в бухгалтерском контуре важна не только точность результата, но и его проверяемость. Специализированный OCR-подход позволяет выстроить прозрачную работу системы: для извлеченного значения сохраняется связь с конкретным фрагментом исходного документа, полем и символом, которую можно отследить в любой момент.
При использовании LLM общего назначения такой контроль принципиально невозможен. Пользователь получает сформированный моделью ответ, но не может детально отследить, какое именно визуальное содержимое стало источником конкретного значения и было ли оно действительно прочитано с документа, а не восстановлено моделью на основе контекста.
Для бухгалтерского учета эта разница критична: система должна не просто выдавать значение, а позволять проверить основание, на котором оно было извлечено. Иными словами, надежность распознавания определяется не только конечным результатом, но и возможностью выяснить его происхождение.
Проблема 7. Отсутствие конфиденциальности при работе с документами
При обработке бухгалтерских документов с помощью LLM есть еще один серьезный риск, не связанный с качеством распознавания. Счета, УПД, акты и накладные содержат коммерческую и персональную информацию. При использовании внешней LLM документы или извлеченный из них текст могут передаваться за пределы корпоративного периметра для обработки.
Для компании это означает необходимость решать вопросы хранения данных, контроля доступа, политики провайдера, локального развертывания и соответствия внутренним и отраслевым требованиям безопасности – задачи, которые никак не связаны с работой модели, но напрямую влияют на возможность ее использования в регулируемых процессах. В случае компрометации коммерческой тайны или утечки персональных данных последствия оказываются еще более серьезными – вплоть до штрафов до 500 млн рублей и уголовного преследования для должностных лиц.
Локальное развертывание LLM, с одной стороны, требует привлечения дорогостоящих вычислительных мощностей и, с другой, – не устраняет фундаментальные ограничения LLM, связанные с галлюцинациями при распознавании бухгалтерских документов.
Почему универсальность LLM становится ограничением в прикладных задачах
Универсальность обычно преподносится как главное преимущество LLM общего назначения. Однако в области распознавания бухгалтерских документов это не преимущество, а причина непригодности: модель может генерировать отсутствующие в документе значения, ошибаться при чтении изображения и восстановлении структуры, зависеть от формулировки запроса и не обеспечивать достаточную верифицируемость результата.При использовании внешних API к этим рискам добавляются вопросы передачи и защиты конфиденциальных данных.
Публичные исследования подтверждают это независимо друг от друга: генеративная модель способна вернуть убедительный ответ, который проходит любую формальную проверку и всплывает именно там, где цена ошибки максимальна. Для промышленной бухгалтерской автоматизации это не техническая деталь, а принципиальная граница применимости технологии. Именно поэтому надежное распознавание документов остается задачей для специализированных систем, спроектированных не для генерации правдоподобного текста, а для точного и прозрачного извлечения данных с контролем достоверности каждого символа.
