DOC OPS: как превратить счёт в проверенную таблицу

Почему «чат с PDF» не решает задачу

Когда заходит речь об «AI-помощнике по документам», обычно представляют чат: загрузил PDF, задал вопрос, получил ответ. Для демо это выглядит эффектно. Для операционки — почти бесполезно.

Менеджеру не нужен ответ «сумма к оплате составляет 5 678,26». Ему нужны строки в таблице: артикул, количество, цена, сумма, НДС. И нужна уверенность, что данные можно проводить в учёт, а не перепроверять каждую цифру вручную.

Поэтому DOC OPS строился не как чат, а как document intake: файл → проверенные структурированные данные → действие.

Демо: docs.webdev07.tech
Кейс: portfolio.webdev07.tech/ru/cases/doc-ops

Что происходит с документом

Пайплайн состоит из пяти шагов.

1. Ingest. PDF, JPG/PNG, DOCX или XLSX. Проверка MIME и размера, sha256, превью страниц.
2. Текст или OCR. Для PDF с текстовым слоем — pdftotext. Для сканов и фото — vision-модель.
3. Извлечение. Модель заполняет строгую JSON-схему: поставщик, номер, даты, суммы, все позиции.
4. Валидация. Обычный TypeScript проверяет арифметику, НДС, дубли, диапазон дат и обязательные поля.
5. Проверка и экспорт. Человек видит спорные поля, исправляет их и выгружает XLSX/CSV/JSON.

Ключевое решение: извлечение и проверки разделены. Модель не решает, сходится ли арифметика. Если 12 × 245,00 не равно 2 890,00, это ловит код, а не ещё один запрос к LLM.

Где модель ошибается

На синтетическом наборе из 44 документов модель ошибается редко, но ошибается. В первом прогоне один скан вообще не вернул JSON — низкое качество изображения. В другом прогоне дата на скане была прочитана как 2026-10-05 вместо 2026-10-06.

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

Что помогает:

• Повтор с текстом ошибки. Если JSON не прошёл Zod, модель получает список проблем и пытается ещё раз.
• Fallback на более сильную vision-модель для сканов, которые не прошли с первого раза.
• Confidence по полям. Низкая уверенность не прячется: поле подсвечено.
• Детерминированные проверки. Арифметика, НДС и дубли не зависят от температуры модели.
• Human-in-the-loop. Ниже порога документ не уходит дальше без человека.

Что показал бенчмарк

44 синтетических документа: текстовые PDF, сканы, DOCX, XLSX, счета с ошибкой в сумме, дублем номера и пропущенным полем.

Метрика	Значение
Точность полей	99.6%
Точность позиций	100%
Документов полностью верно	43 / 44
Медиана на документ	5.8 с
Оценка стоимости	$0.0015 / документ
Edge-case проверки	3 / 3

В одном прогоне получилось 44/44, в контрольном — 43/44. В кейсе опубликованы консервативные цифры и пометка о двух прогонах. Это синтетика, а не клиентские данные: обещать такую точность на чужих сканах было бы нечестно.

Почему XLSX разбирается без модели

Прайс-лист в XLSX — это уже структурированные данные. Отправлять его в LLM странно: дороже, медленнее и менее предсказуемо.

Код ищет строку заголовков, определяет колонки «Артикул», «Наименование», «Цена», читает строки и нормализует числа. Такой документ обрабатывается за доли секунды и стоит $0.

Модель нужна там, где структура потеряна: PDF, сканы, фотографии, DOCX с таблицами.

Что важно для доверия

• Цитаты страниц. Нажал на поле — увидел фрагмент исходника.
• Проверки привязаны к полям. Ошибка ведёт не в пустоту, а к конкретной строке.
• Правки сохраняются. После подтверждения документ получает статус done, а проверки пересчитываются.
• TTL 24 часа. Загруженные файлы удаляются автоматически; в демо — только синтетика.
• Никаких публичных URL. Доступ к файлу — по ID и сессионной cookie.

Что дальше

Следующие шаги — не «добавить ещё одну модель», а укрепить процесс:

• сравнение версий договоров;
• интеграция с 1С и почтовым ящиком;
• кастомные схемы для клиента;
• очередь с ретраями и аудитом;
• больше сканов и языков в бенчмарке.

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