Конвейер разбора входящих документов

Отдел из шести человек вручную переносил данные из документов в учётную систему. В пик — до 1 400 документов в сутки. Ошибка в номере или сумме всплывала через недели и стоила дороже самого ввода.

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

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

1. Приём

   Документы приходят из почтового ящика, папки обмена и мобильного приложения водителей. Всё складывается в объектное хранилище с исходным файлом.

2. Подготовка

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

3. Извлечение полей

   Модель заполняет типизированную схему. Для каждого поля возвращаются значение, уверенность и фрагмент документа, откуда оно взято.

4. Детерминированные сверки

   Арифметика, справочники, дубликаты, диапазоны дат. Эти проверки не используют модель — только код и данные учётной системы.

5. Развилка

   Всё сошлось — документ уходит в учётную систему. Есть расхождение или низкая уверенность — в очередь оператора с подсветкой проблемного места.

6. Обучение на правках

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

• IMAP — почтовый ящик приёмки
• S3-совместимое хранилище
• REST API учётной системы
• Telegram — уведомления о застрявших документах

Что сделано, чтобы система вела себя предсказуемо в эксплуатации, а не только на демонстрации.

• Типизированная схема на Pydantic: документ с невалидной структурой не проходит дальше по определению
• Детерминированные сверки поверх вывода модели — арифметика и справочники не отдаются на усмотрение LLM
• Пороги уверенности настраиваются по каждому полю отдельно: у суммы порог выше, чем у комментария
• Идемпотентность по хешу файла — повторная отправка не создаёт дубль
• Очередь с ретраями и dead-letter; застрявшие документы видны на дашборде и в Telegram
• Исходный файл хранится всегда, чтобы любой автоматический разбор можно было перепроверить
• Персональные данные из документов не попадают в логи и в мониторинг ошибок

• 87%

  Документов без ручного ввода

  Доля документов, прошедших все сверки автоматически. Замер за 60 дней после выхода на полную нагрузку.

• −78%

  Ошибки ввода, найденные после проводки

  Сравнение квартала после внедрения с аналогичным кварталом до.

• 4 мин → 18 с

  Время обработки документа

  Медиана от поступления до появления в учётной системе, включая очередь.

• Архитектура пайплайна, схема данных и модель порогов уверенности — лично
• Слой детерминированных сверок — лично
• Интерфейс очереди разбора для операторов — совместно с фронтенд-разработчиком клиента
• Развёртывание и мониторинг — DevOps клиента, я готовил требования и runbook

• Python
• Claude
• Pydantic
• Celery
• Redis
• PostgreSQL
• MinIO
• Sentry