Vertex / BP: invoice parsing, OCR и AI CI/CD

Нужен hybrid pipeline: PDF parser для native PDFs, OCR для scans, layout/table extraction, rules/NER/LLM layer, validation и gold-set eval.

Сначала делим входы: native PDF, где можно достать текст и координаты, и scanned PDF, где нужен OCR. Далее строим layout representation: страницы, блоки, таблицы, координаты, confidence OCR. На этом слое можно применять правила для стабильных vendor templates и ML/LLM для более разнообразных форматов.

Хорошая архитектура обычно hybrid: deterministic extraction там, где поле явно находится по шаблону; model-based extraction для вариативных описаний; post-processing для нормализации дат, валют, сумм и vendor names; validation rules для проверки total, tax, line items и обязательных полей.

Система должна возвращать не только JSON, но и confidence плюс evidence: откуда взято поле. Это важно для ручной проверки и аудита.

Пробуем извлечь text layer и координаты; если текста нет или он мусорный, идем в OCR. Для обоих путей сохраняем layout и confidence.

Native PDF обычно содержит текстовый слой: его можно извлечь быстрее, дешевле и точнее, чем OCR. Но текст может быть разбит странно, таблицы могут потерять структуру, а порядок чтения может не совпадать с визуальным.

Для сканов нужен OCR: там появляются ошибки распознавания символов, повороты, шум, плохое качество картинки, разрывы строк и неправильные таблицы. Поэтому pipeline должен сначала классифицировать документ: есть ли text layer, сколько текста извлекается, похож ли он на реальные слова/числа, есть ли страницы без текста.

Дальше оба пути лучше привести к одному формату: blocks/tables/cells with coordinates and confidence. Это упрощает downstream extraction и eval.

Нужно разложить latency/cost по стадиям: upload, OCR, layout, LLM, validation. Затем кешировать, роутить простые случаи в правила и батчить тяжелые вызовы.

Оптимизация начинается с измерений. Для каждого документа нужно логировать размер, число страниц, тип PDF, время OCR, время table extraction, число LLM calls, token count, retries и итоговый outcome. Без такого breakdown легко оптимизировать не тот слой.

Дальше применяются routing rules. Простые vendor templates можно обрабатывать без LLM. Native PDFs не нужно отправлять в OCR. Страницы без полезных таблиц можно отбрасывать. LLM можно вызывать только на candidate regions, а не на весь документ.

Для production также полезны кеши по document hash, batch processing, async queue, лимиты на максимальное число страниц и human review для документов с низким confidence вместо бесконечных retries.

Нужен versioned gold set документов, field-level метрики, regression thresholds, prompt/model versioning, canary и rollback.

Для AI extraction CI/CD должен проверять не только "код собирается", но и качество извлечения. Нужен фиксированный gold set: документы разных поставщиков, scans/native PDFs, edge cases, плохие таблицы, разные валюты и языки. Для каждого документа хранят ожидаемые поля и line items.

Метрики лучше считать field-level: exact match или normalized match для invoice number/date/vendor/total, precision/recall для line items, numeric tolerance для сумм, а также долю документов, ушедших в human review. Каждый prompt, rule set и model version должны быть версионированы.

Перед rollout новая версия проходит regression thresholds, затем canary на части трафика. Если растет error rate, latency или human-review rate, нужен rollback.