Автоматическое извлечение фактов: LLM и NLP пайплайны

Почему извлечение фактов из текста ломается на реальных документах

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

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

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

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

Дальше разбираем, как это закрывается — контролем на каждом шаге разбора документов, а не только на выходе.

Эффект от автоматической разметки: что меняется в процессе

Разметка перестаёт быть ручной там, где поле извлекается однозначно: реквизиты, даты, суммы, номера договоров, ссылки на стороны. Рабочая схема — гибридная: детерминированные правила и словари для регулярных полей, модель для формулировок в свободной форме. Такой конвейер держит точность извлечения на уровне, который проверяется выборкой, а не сплошным просмотром, и главной метрикой становится доля документов, прошедших без ручного разбора.

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

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

Снимаются и целые классы отказов: расхождения форматов у поставщиков, потерянные при копировании поля, дубли одной сущности под разными названиями. Подход к качеству данных выстраиваем по практике DAMA-DMBOK — с владельцем поля, правилом проверки и журналом правок, чтобы результат разметки можно было объяснить и откатить.

Сравнение режимов разбора: правила, модели, гибрид

Режим разбора выбирают не по вкусу, а по структуре данных. Там, где значение задано формально — номер договора, дата, код, сумма прописью, — выигрывают правила; там, где смысл держится на контексте — сторона сделки, условие расторжения, оговорка о подсудности, — без модели не обойтись. Крайности одинаково дороги: словари ломаются на первой перефразировке, а модель без проверки выдаёт правдоподобное, но неверное значение, и отличить его от верного нечем.

Человек в контуре проверки замыкает схему: каждый факт приходит со ссылкой на фрагмент-источник, спорные случаи уходят оператору по порогу уверенности, а его правки попадают в словари и в примеры для дообучения. Выбор подхода — это выбор точки приложения усилий: правила чинят быстро, модель дообучают реже, но она держит формулировки, которых в словаре никогда не было.

Внедрение по шагам: от аудита корпуса до передачи

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

1. Аудит корпуса документов. Разбираем выборку по всем типам: какие поля встречаются, как часто отсутствуют, где лежит значение — в таблице, сноске или подписи. Итог — перечень полей с реалистичной оценкой полноты извлечения.
2. Схема разметки полей. Для каждого поля задаём тип, допустимые варианты записи и правило приведения к единому виду. Спорные случаи описываем явно, чтобы ручная разметка и модель трактовали их одинаково.
3. Разметка эталонной выборки. Несколько сотен документов размечаем вручную и делим на две части: одна идёт на настройку, вторая остаётся закрытой до проверки.
4. Настройка извлечения. Подбираем формулировки запросов и правила обработки результата, сверяясь с размеченной частью. Отдельно разбираем поля, где система уверенно выдаёт неверный формат.
5. Проверка на отложенной выборке. Прогоняем готовый контур на документах, которых он не видел, и считаем по каждому полю долю верных значений, пропусков и ложных срабатываний. Пороги приёмки фиксируем до замеров, а не после.
6. Передача в эксплуатацию. Отдаём работающий контур, журнал обработки, интерфейс разбора спорных случаев и регламент: как подключать новые типы документов и когда пересматривать схему полей.

Комплект передачи: правила, схемы и регламенты проверки

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

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

Комплект сопровождается короткой передачей: разбор на живых примерах и ответы на вопросы команды. Объём зависит от числа типов документов и классов фактов — на старте обсудим задачу и вернёмся с составом артефактов и планом работ.

Кейс: разбор договоров с контролем качества на выходе

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

Извлечение фактов собрали в два слоя: выписки в формате УФЭБС и текстовые договоры разбирали из структуры, сканы — через распознавание с привязкой к блоку на странице. Каждое значение модель возвращает по описанной схеме — стороны, номер, дата, сумма, график платежей, предмет — и обязательно со ссылкой на фрагмент-источник.

Контур контроля качества

Результат не уходит в учётную систему напрямую. Сначала срабатывают проверки: контрольное число ИНН, равенство суммы договора сумме графика, даты в пределах срока, сверка реквизитов между договором и выпиской. Поле, не прошедшее проверку или пришедшее с низкой уверенностью, уходит в очередь на ручной разбор, а не в базу «как получилось». Рядом — журнал решений: версия схемы, фрагмент-источник, автор правки; архив перепроверяется после смены правил без потери истории.

Метрики до и после

• доля документов с ручным вводом: 100% → 9–12%;
• время обработки пакета: 2–3 дня → 40–60 минут;
• ошибки в критичных полях: 4–6% → менее 0,5%;
• повторный прогон корпуса: переобработка по новой схеме без операторов.

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

Что делать, если разметка фактов уже ведётся вручную?

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

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

Автоматизация запускается на готовых данных, а не с нуля: модель или правила извлечения обучаются и настраиваются на размеченном корпусе, после чего их результат сравнивают с эталоном вручную на отложенной части. Расхождения показывают, где схема неоднозначна, а где не хватает примеров — это и есть план доработки. Часть разметки сознательно оставляют вне обучения: она нужна как независимый контроль качества при каждом обновлении.

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

Технические сомнения: качество данных и дообучение

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

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

Что происходит при смене шаблона документов?

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

Как вы поступаете со спорными случаями?

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

Как вы контролируете качество данных для дообучения?

Размечаем по письменной инструкции, ключевые поля — двумя исполнителями независимо, расхождения разбираем отдельно. Держим отложенный набор примеров, который не участвует в обучении, и считаем точность и полноту по каждому полю, а не одной общей цифрой. Если метрика проседает на конкретном типе документа, это видно до выката.

Обсудим задачу и вернёмся со схемой и оценкой

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

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

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