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

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

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

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

Наша легенда: сервисная компания, отдел из 6 менеджеров, оборот около 12 млн ₽ в месяц, средний чек услуги — 80 000 ₽. Это примерно 150 сделок в месяц на отдел — то есть на каждого менеджера приходится около 25 сделок в месяц, почти по одной новой сделке в каждый рабочий день. Каждая сделка — это комплект из нескольких документов: удостоверение личности, справка, договор, иногда рукописная анкета. Именно на этом потоке мы и включили ИИ-распознавание документов — с этого стартовал весь разбор ниже.

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

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

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

Почему в интерфейсе Клода всё работало, а через API — нет

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

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

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

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

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

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

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

ИИ-связка целиком: конвейер, промпты, обвязка

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

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

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

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

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

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

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

Шаг 2. Извлечение данных по спецификации. Модель: мощная (Opus или аналогичный уровень) — здесь цена ошибки высокая, экономить нельзя. Инструкция берётся под конкретный тип документа, определённый на шаге 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 — с реальными числами из нашей выборки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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