Проверка точности извлечения данных из договоров и писем

Зачем измерять точность, а не полагаться на ощущения

Когда вы настраиваете извлечение данных из договоров и писем, почти всегда появляется чувство: «вроде работает». Пара удачных примеров успокаивает, но это ловушка. Документы слишком разные, и ошибки часто всплывают не там, где вы проверяли.

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

Самые дорогие ошибки почти всегда связаны с критичными полями: суммами и валютами, датами и сроками (особенно с формулировками «не позднее» и «в течение N дней»), сторонами и реквизитами (кто исполнитель, кто заказчик, где БИН), предметом и условиями поставки, а также приложениями и спецификациями, где часто «спрятано» главное.

Есть и коварные ситуации, когда неоднозначность заложена в самом документе. Условия могут уехать в приложение, в сноску или в скан с печатью, где часть текста перекрыта. В письме важная дата может быть в цитате из прошлого сообщения, а актуальная - выше, в одном коротком предложении.

Оценка качества нужна не ради красивых процентов, а чтобы понимать риск. Если из 50 договоров система правильно нашла суммы в 49, это звучит отлично, пока не выяснится, что ошибка пришлась на самый крупный договор и из-за него ушло неверное согласование.

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

Сначала договоритесь, что считать «точным» результатом

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

Зафиксируйте, какие поля вы извлекаете, и расставьте приоритеты. Иначе легко потратить время на редкие поля и поздно заметить критичные ошибки.

Практично разделить поля на три группы. Ключевые (влияют на оплату, сроки, юридические риски) - сумма, валюта, дата или срок действия, номер договора, стороны (наименование, БИН). Важные (для поиска и отчетов) - предмет договора, адрес, контактное лицо. Второстепенные (удобно иметь, но процесс не блокируют) - примечания, внутренние коды, дополнительные реквизиты.

Дальше определите «правильное значение» для каждого поля. Например, для суммы это число вместе с валютой, а для стороны - официальное юр. наименование, а не сокращение из письма. Часто в договоре одна формулировка, в сопроводительном письме другая, а в подписи третья. Выберите один источник «главнее» или заранее разрешите несколько вариантов как корректные.

Отдельно задайте единый формат. Для дат решите, приводите ли все к виду ДД.ММ.ГГГГ. Для денег - храните ли копейки, как пишете тенге (KZT или тг), что делаете с пробелами в тысячах. Для ИИН/БИН и номеров договоров договоритесь, сохраняете ли дефисы и пробелы, и как обрабатываете символ «№».

Заранее опишите пустые значения. «Пусто» и «нет в документе» - разные ситуации. «Пусто» может означать, что поле пропущено системой, а «нет в документе» - что система правильно ничего не нашла.

Наконец, решите, как считать частичные совпадения. «Иванов Иван» вместо «Иванов Иван Иванович» - это ошибка или допустимый вариант? Номер договора без суффикса или без года - засчитывается или нет? Такие правила делают проверку честной и повторяемой.

Precision и recall без математики «на пальцах»

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

Precision (точность) отвечает на вопрос: из всего, что система извлекла, какая доля верная. Recall (полнота) - из всего, что должно было быть извлечено, какая доля реально найдена. F1 - один общий показатель, который помогает сравнивать варианты, когда нужен баланс между precision и recall.

Представим поле «номер договора». У вас 100 документов, и в 80 из них номер действительно есть. Система вернула номера в 50 документах. Из этих 50 номеров 45 верные, а 5 ошибочные (например, подхватила номер письма или счета).

• Precision: 45 из 50. Система редко ошибается, когда решается извлечь номер.
• Recall: 45 из 80. Но она пропустила много документов, где номер был.

Такой сценарий типичен: высокий precision легко скрывает низкий recall. Это бывает, когда модель «осторожничает» и извлекает только там, где уверена, а сомнительные места игнорирует.

Что важнее на старте зависит от риска. Если ошибка опаснее пропуска (например, сумма для оплаты), сначала гонятся за высоким precision. Если пропуск опаснее ошибки (например, нужно найти все договоры с автопролонгацией), важнее recall.

Считать лучше по полям: номер, дата, сумма, ИИН/БИН, срок, контрагент. А общий итог используйте как сводку, не пряча ключевые поля внутри одной «средней по больнице» цифры.

Как собрать контрольный набор документов

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

Реалистичный минимум для первого замера

Для старта обычно хватает 30-50 документов. Если у вас много типов (договоры, письма, приложения), можно взять 60-80, но не пытайтесь охватить все сразу. Важно, чтобы каждый ключевой тип встретился хотя бы 5-10 раз, иначе метрики будут сильно зависеть от случайности.

Отбирайте документы не по принципу «самые красивые», а по принципу «как в жизни». Полезно заранее выписать несколько категорий и набрать из каждой понемногу: разные шаблоны договоров (типовые и нетиповые), документы разных лет (до и после смены шаблона), разные подразделения или филиалы, разные источники (входящие и исходящие письма, договоры от контрагентов), разные форматы (DOCX, текстовый PDF, сканы).

Обязательно добавьте сложные случаи

Если «тяжелые» файлы не включить, тест покажет хорошую картину, а в работе начнутся сбои. Держите хотя бы 20-30% сложных документов: кривые сканы, фото с телефона, печати поверх текста, таблицы, рукописные пометки, низкое разрешение. Это неприятно, зато честно.

Как разнести наборы и не потерять происхождение

Удобно сразу завести три корзины. Стартовый набор - для первого замера и настройки. Расширенный - чтобы добавлять новые типы и редкие случаи. Регрессионный - небольшой набор (10-20 документов), который вы прогоняете каждый раз после изменений, чтобы не сломать то, что уже работало.

И мелочь, которая экономит часы: помечайте источник каждого файла в названии или в отдельной таблице. Минимально достаточно полей: тип (договор, допсоглашение, письмо, приложение), год, подразделение, формат (скан или текстовый PDF). Тогда вы быстро увидите, что ошибки чаще, например, в приложениях или в сканах за конкретный год.

Эталонная разметка: правила лучше закрепить заранее

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

Сделайте короткую инструкцию разметчика на 1-2 страницы. В ней важно описать не только «что искать», но и «где это обычно находится» (шапка письма, преамбула договора, раздел про оплату, подписи). Это снижает разнобой и ускоряет работу.

Закрепите минимум:

• Формат поля: как записывать даты (ДД.ММ.ГГГГ), суммы (с валютой или без), номера (с префиксами типа № или без).
• Спорные случаи: что делать, если несколько дат (подписания и вступления в силу), несколько сумм (без НДС и с НДС), есть исправления или допсоглашения.
• Источник истины: что важнее при конфликте - текст, таблица, приложение, подпись, штамп.
• Значения «не найдено» и «не применяется»: когда ставить «не найдено» (поле ожидается, но в документе отсутствует) и когда «не применяется» (в этом типе документа поля не бывает).

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

Хранить эталон удобно в простой таблице: строка - документ, столбцы - поля. Добавьте колонку «комментарий», чтобы фиксировать исключения (например: «сумма указана в приложении», «в письме сумма только словами»). Это спасает от повторных обсуждений и помогает понять, почему система ошиблась.

Небольшой пример: в договоре есть «Дата договора» в шапке и «Дата подписания» рядом с подписями, а в письме встречается дата входящего номера и дата события. Если правило не закрепить, один разметчик возьмет первую дату, другой - вторую, и метрики будут прыгать даже при одинаковой работе системы.

Пошагово: как провести первый цикл оценки качества

Первый цикл нужен, чтобы получить честные цифры и понять, что именно ломается.

Начните с небольшого контрольного набора (например, 30-50 файлов), но такого, чтобы в нем были разные типы документов: договоры с приложениями, сканы, PDF из почты, письма с подписями и печатями.

5 шагов одного цикла

1. Прогоните документы через весь конвейер как в реальной жизни: загрузка, OCR (если нужен), извлечение полей, сохранение результата.
2. Для каждого документа сравните результат с эталоном по каждому полю. Сравнивайте не «в целом документ», а «поле-значение».
3. Зафиксируйте TP/FP/FN по каждому полю: TP - извлечено верно, FP - извлечено, но неверно, FN - не извлечено.
4. Сведите все в одну таблицу: строки - поля, столбцы - TP/FP/FN, precision/recall и короткий комментарий.
5. После правок повторите прогон на том же наборе. Иначе вы не поймете, стало ли лучше именно из-за изменений.

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

Чаще всего причины укладываются в несколько групп: проблемы OCR (плохо распознанные цифры, пропуски строк, смешение кириллицы и латиницы), ошибки логики извлечения (не учтены варианты формулировок), особенности формата (таблицы, колонки, перекос скана, разные шаблоны) и человеческий фактор (эталон размечен по разным правилам, опечатки в «правильном» ответе).

Практичный пример: если в письмах «Исх. No» иногда пишут как «Исх№» или просто «Исходящий», это даст и FP, и FN по полю «номер». В отчете помечайте это как «вариант написания», а не как «плохая модель».

Как организовать ручную верификацию на старте

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

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

Чтобы проверка не превращалась в бесконечный поток, работайте батчами. Например, по 50-100 документов в день с понятным критерием готовности: «документ проверен, критичные поля подтверждены или помечены как отсутствующие». Удобно заранее задать статусы: «ОК», «Нужно уточнение», «Не извлечено», «Сомнение».

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

Двойную проверку оставьте только там, где ошибка дорога: суммы, даты, срок действия, БИН/ИИН, банковские реквизиты, номер договора. Остальные поля можно проверять выборочно.

Нагрузку сильно снижает приоритизация. Начните со 100% проверки критичных полей и 10-20% выборки по остальным документам. Отдельно поднимайте наверх письма и договоры с «красными флагами»: много приложений, плохое качество скана, нестандартные шаблоны, несколько контрагентов в одном письме.

Ошибки, из-за которых метрики обманывают

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

Самая коварная ошибка - путать версии и источники документов. В тест попадает файл после ручной правки, а в работе приходит скан с печатью и пометками. Формально это «тот же договор», но для извлечения это разные входы. Если не фиксировать источник (почта, ЭДО, скан, шаблон), метрики будут оптимистичнее реальности.

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

Третья проблема - смотреть только общий средний результат. Можно иметь 95% в среднем, но провал по одному полю (например, БИН/ИИН или сумма с НДС) делает выгрузку непригодной. Полезнее держать метрики по каждому полю и по типам документов.

Не попадайтесь на красивый precision при игноре пропусков. Если система извлекает только то, в чем уверена, ошибок почти нет, но половина нужных полей отсутствует (FN). В живом процессе это означает ручной поиск и задержки.

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

Короткий чеклист перед запуском пилота

Перед пилотом важно убедиться, что вы оцениваете качество одинаково и не сравниваете «яблоки с апельсинами».

Сначала проверьте, что команда одинаково понимает, что именно извлекается. Для каждого поля нужен формат и пример: не просто «номер договора», а «строка вида KZ-2025/0145», не просто «дата», а «ДД.ММ.ГГГГ».

Дальше пройдитесь по базовой готовности:

• Список полей зафиксирован: формат, допустимые варианты записи, пример значения.
• Контрольный набор собран: есть типичные документы и отдельная доля сложных (сканы, плохое качество, нестандартные шаблоны, длинные письма с цепочками ответов).
• Правила для пустых и неприменимых значений согласованы.
• Precision и recall посчитаны отдельно по ключевым полям.
• Ведется журнал ошибок: что неверно, почему это случилось и что вы планируете менять.

Если есть время только на одну дополнительную проверку, сделайте мини-ревью вручную на 20-30 документах. Смотрите не только на проценты, но и на реальные промахи. Часто выясняется, что цифры приличные, а критичные поля (например, сумма или срок) ломаются из-за пары типовых формулировок.

Пример сценария: договоры и письма в организации

Представьте типичный поток: в общий ящик и в СЭД приходят письма от контрагентов, сканы договоров и приложения. Часть документов - PDF, часть - Word, часть - фото с телефона. Все это попадает в одну очередь на обработку.

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

Контрольный набор на 50-100 документов обычно собирают так, чтобы он отражал реальную жизнь. Например, можно взять 20-30 договоров разных типов (поставка, услуги, допсоглашения), 15-25 писем, где сумма или срок упоминаются в тексте, 10-20 документов с плохим качеством скана или нестандартным шаблоном и 5-10 случаев с несколькими суммами или датами в одном документе (аванс, итог, приложения).

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

После первого подсчета выводы обычно повторяются. Хорошо вытаскивается дата и номер из типовых договоров, но контрагент путается из-за ролей («Исполнитель», «Поставщик») и падежей. Сумма часто ломается на документах с несколькими валютами или таблицами, а срок действия - на письмах, где он описан словами («до конца квартала»). Эти наблюдения дают понятный план: уточнить правила разметки, добавить сложные примеры в контрольный набор и оставить обязательную ручную проверку только для полей с высоким риском.

Следующие шаги: как перейти от пилота к стабильной работе

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

Для критичных полей (сумма, ИИН/БИН, даты, номер договора, срок действия, банковские реквизиты) зафиксируйте целевые пороги качества. Задавайте их отдельно: где-то важнее не пропустить ни одного значения (выше recall), а где-то важнее не допускать ложных срабатываний (выше precision). Пороги должны быть понятны бизнесу, а не только команде, которая настраивает извлечение.

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

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

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

Если пилот показал пользу, следующим шагом часто становится инфраструктура: где запускать обработку, как хранить данные, как обеспечить стабильность. В таких задачах может помочь GSE.kz (gse.kz) как системный интегратор: подобрать серверы и рабочие станции под нагрузку, собрать инфраструктуру для обработки документов и организовать поддержку 24/7, чтобы решение уверенно работало в реальном потоке, а не только на тестовой папке.