директор и машина · производственный цикл · запись № 052 · 28 августа 2026 · Давид Герштейн

Распознавание документов: как мы снизили ошибки с 20% до 7% на 92 эталонных документах

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

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

Мы сразу запустили распознавание документов — и получили путаницу в именах клиентов

Разберём на примере: сервисная компания, отдел продаж из 8 менеджеров, оборот около 9 млн ₽ в месяц, средний чек услуги — 180 000 ₽. Это примерно 50 сделок в месяц на отдел — то есть на каждого менеджера приходится около 6 сделок в месяц, чуть больше одной новой сделки в неделю (цикл сделки — около 6 недель, у каждого менеджера обычно несколько сделок одновременно в работе). Всего в компании около 40 человек. Каждая сделка — это комплект из нескольких документов: удостоверение личности, справка, договор, иногда рукописная форма. Именно на этом потоке мы и включили распознавание документов — с этого стартовал весь разбор ниже.

Мы решили не тратить полгода на пилот и запустили распознавание документов сразу на живом потоке. Логика была простая: в интерфейсе Клода мы прогнали десяток сканов — модель прекрасно читала имена, даты, номера документов. Значит, думали мы, через API будет так же. Не было.

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

Ошибка в имени клиента — это не мелочь. Это переделка карточки, повторная проверка менеджером и, в худшем случае, конфликт с клиентом, который увидел свои данные с ошибкой в личном кабинете. При потоке около 50 комплектов в месяц каждый пятый в первые недели — то есть около 10 комплектов — требовал ручной пересборки: дополнительные 30–40 минут работы менеджера сверх обычных 10–15 минут на проверку (оценка). Скрытая нагрузка на отдел, которую никто не считал при запуске.

Почему в чате работало, а через API — нет

Ловушка, в которую попадёте и вы, если будете тестировать в чате, а запускать через API: это разные условия, и результат отличается. Я сам в неё зашёл первым: показал руководству прогон в чате, получил «отлично, запускаем» — и потом месяц объяснял, почему на живом потоке всё иначе. Мне это стоило доверия к проекту на старте, вам не обязательно повторять.

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

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

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

Как мы переделали: механика по шагам

Ваш путь будет короче, если сразу заложите то, к чему мы пришли через месяц проб. Я закладывал на переделку неделю — ушло больше месяца, и почти всё это время съела не техника, а описание типов документов.

Вместо того чтобы чинить универсальный промпт, мы откатились назад и собрали процесс заново, на маленьком контролируемом объёме.

1. Собрали эталонную выборку. 92 реальных документа разных типов — не случайных, а специально подобранных так, чтобы в них были все проблемные варианты: повёрнутые сканы, рукописные вставки, документы с низким контрастом.
2. Разметили вручную. Стажёр прошёл все 92 документа и зафиксировал, что модель распознала правильно, а что — нет, с указанием конкретной причины ошибки (ориентация, почерк, качество скана).
3. Написали спецификации по типам документов. Для каждого типа — отдельная инструкция: где искать нужные поля, какие нюансы у этого типа (например, в рукописных формах отчество часто пишут через запятую после имени, а не отдельным полем).
4. Добавили автоматический разворот. Перед вызовом модели изображение проверяется и разворачивается в правильную ориентацию — это убрало большую часть ошибок с вертикальными сканами.
5. Построили каскад из двух моделей. Дешёвая модель сначала определяет тип документа, затем к нему применяется своя спецификация, и только на этом этапе подключается более мощная модель для извлечения данных.
6. Добавили проверку человеком на выборке, а не на всём потоке. Менеджер смотрит не каждый документ, а случайную часть — если ошибок нет, доля проверки снижается.
7. Перепроверили промпты на разных моделях. На наборе из 10–15 полных первичных консультаций прогнали одну и ту же задачу через несколько моделей разного уровня — сравнили, где точнее и где дешевле.

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

ИИ-связка целиком

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

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

Шаг 1. Классификация типа документа. Модель: дешёвая (лёгкий уровень) — задача простая, вариантов ответа мало, переплачивать за мощную модель здесь бессмысленно.

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

Верни строго JSON без пояснений:
{
  "document_type": "один из перечисленных типов",
  "confidence": число от 0 до 1,
  "orientation_issue": true/false — есть ли признаки того,
    что документ загружен повёрнутым (текст читается не горизонтально)
}

Изображение документа: {{file_url}}
Клиент: {{client_id}}

Пример ответа модели:

{
  "document_type": "рукописная_форма",
  "confidence": 0.87,
  "orientation_issue": true
}

Шаг 2. Извлечение данных по спецификации. Модель: мощная — здесь цена ошибки высокая, экономить нельзя. Инструкция берётся под конкретный тип документа, определённый на шаге 1.

Ты извлекаешь данные из документа типа "рукописная_форма".
Особенности этого типа: отчество часто указано через запятую
после имени в одном поле; дата может быть в формате ДД.ММ.ГГ
или прописью; подпись не является полем для извлечения.

Верни строго JSON:
{
  "last_name": "фамилия",
  "first_name": "имя",
  "middle_name": "отчество или null, если не указано",
  "document_date": "дата в формате ГГГГ-ММ-ДД",
  "extraction_confidence": число от 0 до 1,
  "flags": ["список проблем, если есть: нечитаемый_текст,
    обрезан_край, требует_проверки_человеком"]
}

Изображение документа (развёрнутое): {{file_url_rotated}}
Спецификация типа: {{spec_id}}

Пример ответа модели:

{
  "last_name": "Соколова",
  "first_name": "Мария",
  "middle_name": "Викторовна",
  "document_date": "2026-03-14",
  "extraction_confidence": 0.74,
  "flags": ["требует_проверки_человеком"]
}

Инженерная обвязка. Скрипт крутится на облачном триггере, который раз в час проверяет папку с документами: появился новый файл — робот подхватил его в очередь. Все вызовы моделей логируются в отдельную таблицу: тип документа, использованная модель, уверенность ответа, флаги. Если модель вернула низкую уверенность или флаг «требует проверки», в CRM через вебхук ставится задача на менеджера, а не автоматически заполняется карточка. Если сам скрипт падает (нет ответа от API, таймаут) — в таблицу пишется строка с ошибкой и статусом «не обработано», и раз в день кто-то один просматривает эту колонку целиком, а не каждый сбой в моменте.

Отдельно: модель получает данные напрямую из CRM через отдельный слой между ИИ и базой данных компании, а не через ручную выгрузку файлов — это снижает расход токенов на 30–40%, потому что запрос не тащит за собой лишний контекст. Например: если типовой запрос на извлечение данных с ручной выгрузкой и склейкой файлов обходился условно в 1500 токенов на документ, то через прямой слой к CRM — ориентировочно 900–1050 токенов на тот же документ при том же качестве ответа (оценка, цифры иллюстративные). Заодно это снижает долю галлюцинаций модели — она не додумывает то, чего нет в обрезанном контексте. Тема отдельная и подробно разобрана в статье о реальных счетах за ИИ — Сколько на самом деле стоит ИИ в месяц.

Так может выглядеть карточка очереди документов в CRM — с реальными числами из нашей выборки:

Что показало сравнение моделей

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

Часы, которые уходили у менеджеров на ручное исправление ошибок распознавания, до и после внедрения спецификаций и автоповорота — на диаграмме ниже: поток около 50 комплектов в месяц, ставка менеджера ~1000 ₽/час.

≈7 часов/мес на исправления до внедрения спецификаций и автоповорота против ≈2 часов/мес после — оценка на основе потока около 50 комплектов в месяц.

Экономика: что стоил провал и что даёт починка

Настройка каскада заняла ~30 часов работы разработчика (≈60 000 ₽ по ставке 2000 ₽/час), а даёт снижение потерь на ручной пересборке документов с ≈7 000 до ≈2 000 ₽/мес — то есть эффект около 5 000 ₽/мес (оценка).

Формула для потерь простая и её легко пересчитать под свой поток: число комплектов в месяц × доля ошибок × лишние минуты на пересборку ÷ 60 = дополнительные часы менеджеров в месяц. У нас: 50 комплектов × 20% ошибок в первые недели × 40 минут (верхняя граница диапазона 30–40 минут) ÷ 60 ≈ 7 часов в месяц. При ставке менеджера 1000 ₽/час это около 7 000 ₽/мес прямых потерь на ручную пересборку.

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

Стоимость починки — это не покупка новой лицензии, а время разработчика: сбор и разметка эталонной выборки (92 документа, разметка стажёром — примерно 3–4 часа), написание спецификаций по 4–5 типам документов (примерно 2–3 часа на тип, итого 10–12 часов разработчика) и настройка каскада моделей с обвязкой — промпты, вебхуки, логирование (примерно 15–20 часов разработчика). Итого около 30 часов разработчика. При условной ставке разработчика 2000 ₽/час это порядка 60 000 ₽ разовых затрат.

После починки доля сбойных комплектов снизилась примерно до 7%: 50 × 7% × 40 минут ÷ 60 ≈ 2 часа в месяц — именно эта цифра стоит на диаграмме выше. Экономия на ручной работе: (7 − 2) часов × 1000 ₽/час = 5 000 ₽/мес. При разовых затратах на починку около 60 000 ₽ и экономии 5 000 ₽/мес окупаемость — около 12 месяцев, и это без учёта снижения репутационного риска от ошибок в карточках клиентов, который в часах не считается вовсе.

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

Цифра в 5 000 ₽/мес скромная в абсолютах, а окупаемость почти год — не быстрый результат. Но именно эта связка переводит распознавание документов из источника ручной работы в фоновый процесс, за которым не нужно следить каждый день, и при росте потока (например, при расширении отдела продаж) окупаемость только ускорится. Похожий по духу, но количественно другой результат — рост точности распознавания с 59% до 85% на другом наборе документов и с другими вводными — разобран отдельно в статье Распознавание документов: как мы подняли точность с 59% до 85%; не путайте эти два кейса.

Все числа в таблице привязаны к потоку ~50 комплектов в месяц — это оценка для примера, проценты ошибок и экономия токенов взяты из фактических результатов эксперимента.

Что дальше: от 92 документов к пилоту на тысячи клиентов

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

Чего я не понимал, когда начинал распознавание документов

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

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

Чек-лист на понедельник

• Не запускайте распознавание сразу на всём потоке — соберите 50–100 эталонных документов и разметьте вручную, где модель ошибается.
• Проверьте, действительно ли документы, отмеченные в CRM как «загружены», физически лежат на сервере — расхождение здесь ломает любое будущее обучение.
• Разбейте документы на типы и напишите отдельную короткую инструкцию для каждого, а не одну универсальную «распознай документ».
• Добавьте автоматический разворот изображения перед вызовом модели — если работаете через API, а не через чат-интерфейс, это не опция, а обязательный шаг.
• Постройте каскад: дешёвая модель на классификацию, дорогая — на извлечение данных, человек — на выборочную проверку, а не на весь поток.
• Прикиньте свою экономику по той же формуле: поток комплектов × доля ошибок × лишние минуты на пересборку ÷ 60 = ваши часы потерь в месяц — и сравните с разовыми затратами на починку, чтобы понять свою окупаемость.
• Перед тем как отправлять документы клиентов в любую модель, свежим взглядом перечитайте, что вообще можно передавать наружу — коротко об этом в статье Персональные данные и нейросети.

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

Полная механика — в разборе про точность и в бесплатном курсе.

Чек-лист для вашего запуска

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

Частые вопросы

Почему распознавание документов работает в чат-интерфейсе, но ломается через API?

Чат-интерфейс сам готовит изображение — разворачивает, улучшает контраст. API отдаёт модели то, что загрузили: если скан повёрнут на 90 градусов, распознавание поедет, и это нужно чинить самим, до вызова модели.

Сколько документов нужно, чтобы обучить промпт распознавания?

Не тысячи. У нас рабочий цикл начался с 92 эталонных документов, размеченных вручную, и набора 10–15 полных кейсов для сравнения моделей — этого хватило, чтобы найти рабочую связку и написать спецификации по типам.

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

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

Распознавание документов — это то же самое, что распознавание документов в 1С?

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

Чем это отличается от онлайн-сервиса, который распознаёт текст с фото?

Онлайн-сервис возвращает буквы: на выходе текст, который человек всё равно переносит в систему руками. Здесь задача другая — понять, какой перед нами тип документа, вытащить именно критичные поля и отдать их в CRM в готовом виде, с отметкой уверенности. Наши 20% и 7% — это доля комплектов с ошибкой в полях, а не качество узнавания символов.

#ии и нейросети #ошибки и провалы #контроль и надёжность