Из договора автоматически вытаскиваются два принципиально разных типа данных, и путать их — главная ошибка при постановке задачи. Атрибуты — это ИНН, номер, дата, сумма, срок оплаты, подписант: короткие значения, которые лежат в предсказуемых местах и проверяются по формальному признаку. Условия — это порядок расторжения, ответственность за просрочку, право на односторонний отказ: смысловые конструкции, которые в каждом договоре сформулированы по-своему и занимают от одного до пяти абзацев.
Разница видна на приёмке. В нашем замере на 100 договорах извлекались 14 атрибутов и 8 условий. Из 1 400 значений атрибутов правки потребовали 90 — 6,4 %. Из 800 значений условий правки потребовали 214 — 26,8 %. Четырёхкратная разница держится независимо от того, какая модель стоит внутри, потому что причина не в модели: у атрибута есть единственно верное значение, у условия — формулировка, которую два юриста запишут в реестр по-разному.
Ниже — маршрут документа от скана до записи в реестре, разбор того, где именно ломается вход, устройство порога уверенности, методика приёмки на своих 100 договорах и цена вопроса в рублях: и за один договор в потоке, и за разовый разбор архива на 4 000 документов.
Два класса полей и почему им нужны разные подходы
Атрибут извлекается и сразу проверяется: ИНН имеет контрольный разряд, сумма прописью сверяется с суммой цифрами, дата не может быть позже даты подписания, контрагент ищется в справочнике. Ошибка видна без юриста. Условие проверить формально нечем — можно только сравнить с тем, что записал бы человек, а человек записывает по-разному.
| Атрибуты | Условия | |
|---|---|---|
| Что это | ИНН, КПП, номер и дата, предмет одной строкой, сумма, валюта, НДС, срок действия, отсрочка в днях, пролонгация, подписант, банковские реквизиты | Ответственность за просрочку, порядок расторжения, односторонний отказ, приёмка, гарантия, конфиденциальность, подсудность, форс-мажор сверх типового |
| Сколько полей в замере | 14 | 8 |
| Где лежит в документе | В шапке, в разделе цены и в реквизитах — предсказуемо | В разных разделах, иногда в приложении, иногда двумя пунктами в разных местах |
| Как проверяется | Формально: контрольный разряд, справочник, сверка цифрами и прописью | Только сравнением с тем, что записал бы юрист |
| Доля ручных правок | 6,4 % | 26,8 % |
| Что записывать в реестр | Значение | Значение плюс ссылка на пункт и цитату — иначе поле бесполезно |
Последняя строка — практический вывод, который экономит больше всего. Условие без ссылки на пункт договора в реестре не работает: юрист всё равно откроет документ и найдёт это место руками, и вся экономия исчезнет. Поэтому поле «порядок расторжения» хранится не как абзац текста, а как тройка: краткая формулировка, номер пункта, точная цитата. То же требование действует и в поиске по архиву договоров, и в проверке договора по чек-листу — везде, где машина отвечает на вопрос по документу.
Сравнение в две колонки. Слева «Атрибуты — 14 полей»: список ИНН, КПП, номер, дата, сумма, валюта, НДС, срок действия, отсрочка, пролонгация, подписант, банковские реквизиты; внизу крупно «6,4 % ручных правок» и пометка «проверяется формально». Справа «Условия — 8 полей»: ответственность, расторжение, односторонний отказ, приёмка, гарантия, конфиденциальность, подсудность, форс-мажор; внизу крупно «26,8 % ручных правок» и пометка «проверяется только человеком». Под колонками общая строка «100 договоров, 2 200 значений, 304 правки». Чертёжный стиль, подписи по-русски.
Маршрут документа: пять шагов от файла до реестра
Цепочка одинаковая независимо от того, кто её собирает. Важно понимать, что это именно цепочка: качество каждого следующего шага ограничено качеством предыдущего, и вложение денег в конец цепочки при плохом начале ничего не даёт.
- 11. Приём и нормализация файла
Определяется, есть ли в PDF текстовый слой. Если есть — распознавание не нужно вообще, и это самая дешёвая ветка. Если нет, изображение выравнивается, чистится, приводится к рабочему разрешению. Скан переворачивается, если он вверх ногами, и разбивается на страницы.
- 22. Распознавание текста
Здесь работают Content AI — российский преемник ABBYY, Smart Engines или 1С:Распознавание первичных документов, если контур строится вокруг 1С. На выходе — текст с координатами, то есть с привязкой каждого фрагмента к месту на странице. Координаты понадобятся дальше, чтобы показать юристу, откуда взято значение.
- 33. Разбор структуры
Текст режется на разделы и пункты с номерами, отдельно выделяются приложения и спецификации, восстанавливается нумерация. Шаг, который чаще всего пропускают, а он определяет, сможете ли вы вообще сослаться на пункт в замечании и в реестре.
- 44. Извлечение значений
Атрибуты берутся правилами и справочниками там, где это возможно, и языковой моделью там, где формулировки плавают. Условия — только моделью, с обязательным требованием вернуть цитату и номер пункта. Каждое значение получает оценку уверенности.
- 55. Проверка и запись
Формальные проверки: контрольный разряд ИНН, сверка суммы цифрами и прописью, контрагент в справочнике, даты в допустимом порядке. Всё, что не прошло проверку или не дотянуло до порога уверенности, уходит человеку на подтверждение. Остальное пишется в реестр.
Как устроены первые два шага изнутри — предобработка изображения, слои распознавания и почему заявленные вендорами проценты точности почти ничего не говорят о вашем потоке, — мы разбирали подробно в отдельной статье о том, как машина читает документ. Здесь важно только то, что договор длиннее и сложнее счёта: девять страниц вместо двух, вложенная нумерация, приложения и спецификации, на которые ссылается основной текст.
Горизонтальная схема из пяти блоков со стрелками: «Приём файла: есть ли текстовый слой» → «Распознавание: Content AI, Smart Engines, 1С:Распознавание» → «Разбор структуры: разделы, пункты, приложения» → «Извлечение: 14 атрибутов правилами и моделью, 8 условий моделью с цитатой» → «Проверки и запись в реестр». От первого блока вниз отходит короткая ветка «PDF с текстовым слоем — распознавание не нужно, 1,8 % правок». От предпоследнего блока вниз ветка «ниже порога уверенности — человеку, 22 % значений». Чертёжный стиль, подписи по-русски.
Где ломается вход: 200 dpi и печать поверх реквизитов
Самая дорогая проблема в извлечении данных из договоров решается не деньгами за софт, а регламентом сканирования. В нашей выборке из 100 договоров было 48 файлов PDF с текстовым слоем, 34 чистых скана 300 dpi, 12 сканов 200 dpi с печатью и подписью поверх реквизитов и 6 фотографий с телефона. Доля правок по атрибутам различается на порядок.
| Тип исходника | Договоров в выборке | Значений атрибутов | Правок | Доля правок |
|---|---|---|---|---|
| PDF с текстовым слоем | 48 | 672 | 12 | 1,8 % |
| Скан 300 dpi, чистый | 34 | 476 | 20 | 4,2 % |
| Скан 200 dpi, печать поверх реквизитов | 12 | 168 | 32 | 19,0 % |
| Фотография с телефона | 6 | 84 | 26 | 31,0 % |
| Итого | 100 | 1 400 | 90 | 6,4 % |
Двенадцать плохих сканов и шесть фотографий — это 18 % выборки, но на них приходится 58 из 90 правок, то есть почти две трети всей ручной работы. Отсюда очевидное действие, которое стоит ноль рублей: регламент приёма документов. Договор принимается в PDF с текстовым слоем, если контрагент его так прислал; сканируется в 300 dpi; печать не ставится поверх реквизитов; фотография с телефона не принимается как исходник для реестра, хотя годится как оперативная копия. Эти четыре правила снимают больше правок, чем смена одной системы распознавания на другую.
Если старые договоры хранятся только на бумаге, оцифровка — отдельный проект со своим бюджетом, и экономить на разрешении сканирования в нём нельзя. Пересканировать 4 000 документов из-за того, что первый заход сделали в 200 dpi «чтобы быстрее», дороже, чем сразу сделать правильно: заново придётся поднимать коробки из архива, а не просто перезапускать обработку.
Уверенность и порог: что уходит человеку, а что проскакивает
Каждое извлечённое значение получает оценку уверенности от 0 до 1. Ниже порога значение уходит человеку на подтверждение, выше — пишется в реестр. Пороги настраиваются по классам полей отдельно: в нашей конфигурации 0,9 для атрибутов и 0,75 для условий. Смысл разный: у атрибута ошибка означает неверное значение в реестре, у условия — неточную формулировку, которую юрист поправит при первом обращении.
При этих порогах человеку уходит 22 % значений — 484 из 2 200. Внутри этих 484 значений находится 71 % всех реальных ошибок: 216 из 304. Оставшиеся 88 ошибок система сочла уверенными и записала в реестр молча. Это ровно 4 % всех значений, и это та цена, которую вы принимаете вместе с автоматикой. Скрывать её нельзя, а вот выбирать, где она приемлема, — можно и нужно.
Значение, ниже которого система не записывает результат сама, а спрашивает человека. Понижение порога уменьшает очередь на подтверждение и увеличивает число тихих ошибок; повышение — наоборот. Порог не универсален: для суммы договора и банковских реквизитов его ставят почти в единицу, потому что цена ошибки высокая, а для поля «предмет одной строкой» — низким, потому что ошибка там ничего не ломает.
Практическое правило: порог назначается не по полю вообще, а по цене ошибки в этом поле. Банковские реквизиты, сумма и срок действия — почти единица, вплоть до обязательного подтверждения всех значений. Пролонгация, отсрочка и подсудность — средний порог. Предмет и краткие формулировки условий — низкий, потому что они всё равно читаются вместе с цитатой из документа.
Приёмка на 100 договорах: четыре числа
Приёмка результата — это не «посмотрели, вроде работает». Это четыре измеримых числа на сплошной выборке из 100 договоров, взятых подряд, а не отобранных. Выборка размечается руками: помощник юриста выписывает верные значения 22 полей по каждому договору. Это примерно 30 часов работы, и без них принимать нечего.
- 1Доля значений, которые пришлось править руками, отдельно по атрибутам и по условиям. У нас — 6,4 % и 26,8 %. Приемлемый ориентир: не выше 5 % по атрибутам и не выше 30 % по условиям при обязательном подтверждении человеком.
- 2Доля договоров, где верны все 14 атрибутов. Показатель жёстче предыдущего и ближе к жизни: одна ошибка в карточке заставляет проверять карточку целиком. В нашем замере это 71 договор из 100.
- 3Доля значений, ушедших в очередь на подтверждение. 22 % — это нагрузка на человека, и её надо знать заранее, чтобы посчитать реальную экономию, а не бумажную.
- 4Доля тихих ошибок: значения, которые неверны, но система сочла их уверенными. У нас 88 из 2 200, то есть 4 %. Это единственное число, которое подрядчики не показывают по своей инициативе, и именно его надо требовать в акте.
Эти же четыре числа стоит записать в договор с подрядчиком как условия приёмки — с порогами и с указанием, что замер делается на выборке заказчика, а не на демонстрационном наборе. Что ещё имеет смысл фиксировать в договоре на разработку, мы разбирали отдельно; здесь важно, что без чисел приёмка превращается в спор о вкусах.
Сколько стоит: один договор и архив на 4 000 документов
Себестоимость машинной обработки одного договора складывается из четырёх машинных статей и одной человеческой. Договор в расчёте — девять страниц, скан 300 dpi, 22 извлекаемых поля.
Видно главное: 68 % себестоимости — человеческая строка. Машинная часть стоит 23,20 ₽ и почти не растёт с объёмом, а человеческая масштабируется линейно. Отсюда следует, что оптимизировать надо не цену токенов, а количество минут подтверждения: точнее пороги, лучше исходники, меньше полей в обязательном подтверждении. Для потока в 500 договоров в год экономия составит 53 400 ₽ — сама по себе она проект не окупает, и извлечение почти никогда не внедряется ради неё.
Настоящий повод — разовый разбор архива и появление реестра как такового. Компания, у которой 4 000 действующих и завершённых договоров лежат папками, не может ответить на вопрос «у скольких контрагентов у нас отсрочка больше 45 дней» вообще никак, кроме как посадив человека читать. Вот арифметика двух путей.
Смета внедрения на 380 000 ₽ раскладывается так: разметка эталона на 100 договорах — 60 000 ₽, подключение распознавания и правила предобработки — 70 000 ₽, извлечение 14 атрибутов со справочниками и проверками — 90 000 ₽, извлечение 8 условий с привязкой к пунктам — 110 000 ₽, пороги уверенности и очередь подтверждения — 50 000 ₽. Поддержка — 15 000–20 000 ₽/мес: ведение справочников, разбор исключений, правка правил при появлении новых типов договоров.
Столбчатая диаграмма из четырёх столбцов по типу исходника с подписями долей правок: «PDF с текстовым слоем — 1,8 %», «Скан 300 dpi — 4,2 %», «Скан 200 dpi с печатью — 19,0 %», «Фото с телефона — 31,0 %». Над столбцами — доля каждого типа в выборке: 48, 34, 12 и 6 договоров. Справа врезка: «18 % выборки дают 58 правок из 90». Внизу подпись «регламент сканирования стоит 0 ₽ и снимает больше правок, чем смена системы распознавания». Ось Y в процентах, подписи по-русски.
Куда складывать результат
Извлечённые данные оседают в трёх разных местах, и это не дублирование, а разделение задач. Ошибка — пытаться обойтись одним хранилищем: реестр, карточка сделки и поисковая база отвечают на разные вопросы и живут по разным правилам доступа.
| Место | Что там лежит | На какой вопрос отвечает | Кто пользуется |
|---|---|---|---|
| Реестр договоров | 14 атрибутов, 8 условий со ссылками на пункты, статус, срок, файл | «Сколько договоров с отсрочкой больше 45 дней», «что истекает в ноябре» | Юрист, финансы, руководитель |
| Карточка сделки в CRM | Номер и дата договора, сумма, срок оплаты, ссылка на карточку договора | «На каких условиях мы работаем с этим клиентом» | Менеджер по продажам |
| Поисковая база | Текст договора с разбивкой по пунктам и векторным индексом | «В каких договорах мы отвечаем за просрочку поставщика» | Юрист при подготовке к спору или переговорам |
Реестр — единственный источник истины по условиям, остальные два берут данные из него. Дублировать значения в карточку сделки можно и нужно, но односторонне: правка условия делается в реестре и оттуда расходится, а не наоборот. Иначе через полгода в CRM и в реестре будут разные сроки оплаты по одному договору, и никто не сможет сказать, какой из них верный. Как устроен поиск по архиву в трёх вариантах и сколько стоит каждый — тема соседнего материала.
Из реестра, заполненного автоматически, сразу получаются вещи, ради которых обычно всё и затевается: контроль сроков и пролонгаций без ручного календаря, отчёт по отсрочкам для финансовой службы, сверка условий договора с фактическими отгрузками и платежами. Последнее особенно заметно там, где условия у контрагентов разные: автоматическая сверка документов с реестром находит расхождения, которые при ручном контроле не находит никто, потому что для этого пришлось бы каждый раз открывать договор.
Карта из четырёх узлов. В центре крупный блок «Реестр договоров: 14 атрибутов, 8 условий со ссылками на пункты». Слева входящая стрелка от блока «Разбор документа» с подписью «73,20 ₽ за договор». Вправо две односторонние стрелки: к блоку «Карточка сделки в CRM» (подпись «номер, дата, сумма, срок оплаты») и к блоку «Поисковая база с векторным индексом» (подпись «текст по пунктам»). Стрелки помечены как односторонние с пометкой «правка — только в реестре». Снизу от реестра три коротких выхода: «контроль сроков и пролонгаций», «отчёт по отсрочкам», «сверка с отгрузками и платежами». Чертёжный стиль, подписи по-русски.
Когда извлечение не нужно
Четыре ситуации, в которых мы советуем не начинать. Проверяются они за час и до разговора о бюджете.
- Меньше 300 договоров в архиве и меньше 100 в год. Разбор руками обойдётся в 54 000 ₽ и около двух с половиной недель работы помощника — дешевле любого внедрения. Реестр в этом случае ведётся в таблице, и этого достаточно на годы вперёд.
- Все договоры типовые и созданы вами же. Если 90 % документов формируются из вашего шаблона по данным CRM, извлекать из них нечего: все поля известны в момент создания. Задача решается генерацией документа с сохранением полей, а не обратным разбором готового файла.
- Нужен один-два атрибута, а не карточка. Если по-настоящему нужны только срок действия и сумма, а всё остальное — «пусть будет», проект сокращается втрое и часто сводится к простой выгрузке из ЭДО и учётной системы. Полный разбор на 22 поля стоит денег и должен быть кому-то нужен.
- Архив только на бумаге и в плохом состоянии. Сначала оцифровка с нормальным разрешением как отдельный проект со своим бюджетом, потом извлечение. Попытка совместить одно с другим в одной смете обычно заканчивается тем, что обе задачи сделаны наполовину.
И общее правило, которое стоит держать в голове при любом разговоре об извлечении данных. Автоматика хорошо забирает механическую часть — найти, выписать, свести в таблицу. Решение о том, что означает найденное условие и опасно ли оно, остаётся человеку, и в реестре это отражается прямо: рядом со значением всегда лежит цитата и номер пункта, чтобы юрист мог за полминуты убедиться сам. Реестр, которому нельзя не доверять, потому что каждое поле проверяемо, стоит дороже реестра, который заполнен на 100 % и неизвестно как.
