LLM-пайплайн для страховых заявлений, тикетов и KYC-документов внутри вашей собственной инфраструктуры: извлечение, валидация, проверка и аудит

У страховых заявлений, тикетов поддержки и KYC-документов общая проблема: люди читают их, чтобы заполнить поля, нужные другой системе. Страховое заявление превращается в номер полиса, дату страхового случая и позиции счёта; тикет — в категорию и клиента; документ, удостоверяющий личность, — в имя, дату рождения и дату окончания срока действия. Требование, которое приходит вместе с задачей, обычно звучит раньше всего остального: документы не должны уходить в OpenAI или к любому другому внешнему провайдеру моделей.

Где работает модель — отдельное решение; варианты сравниваются в одной из предыдущих статей этого блога. Здесь предполагается модель с открытыми весами, развёрнутая внутри вашей инфраструктуры, и описывается пайплайн вокруг неё — от приёма до записи, которую потребляет другая система. Статья объясняет механику; это не кейс.

Семь этапов, и каждый остаётся внутри

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

Приём: классифицируйте документ до того, как его что-либо прочитает

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

• При поступлении записывайте канал, отправителя и хеш содержимого, чтобы документ, присланный дважды, распознавался до того, как станет двумя делами
• Классифицируйте по закрытому списку типов: документация vLLM о structured outputs называет параметр choice, при котором вывод будет ровно одним из вариантов, поэтому классификатор не может выдумать тип
• Документ, который не подходит ни под один тип или подходит с низкой степенью согласия, отправляйте человеку, а не в ближайшую схему

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

PDF, сгенерированный программой, содержит текстовый слой, который можно прочитать напрямую. Скан или фото с телефона содержит только пиксели, и что-то должно превратить их в символы с координатами.

Open-source движки для этого шага работают локально. Документация командной строки Tesseract показывает вывод в формате TSV со столбцом уверенности для каждого слова и вывод hOCR с атрибутом уверенности слова — пословный сигнал, который может использовать этап маршрутизации. Docling — open-source библиотека конвертации под лицензией MIT — называет среди своих возможностей для PDF разметку страницы, порядок чтения и структуру таблиц, поддержку OCR для отсканированных PDF и изображений, а также локальное выполнение для чувствительных данных и изолированных (air-gapped) сред.

• Читайте текстовый слой там, где он есть, и применяйте OCR только там, где его нет, чтобы в чистые документы не попадали ошибки распознавания
• Сохраняйте номер страницы и ограничивающую рамку (bounding box) каждого слова, чтобы любое извлечённое поле потом можно было показать проверяющему на той странице, откуда оно взято
• Сохраняйте таблицы таблицами: в счёте, чьи столбцы сплющены в одну строку текста, теряется, какая сумма относится к какой позиции

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

Вывод с ограничением по схеме: форма гарантирована, содержание — нет

Каждый тип документов получает собственную схему вывода, которая версионируется как код. Документация vLLM о structured outputs перечисляет пять видов ограничений: choice, regex, JSON-схема, контекстно-свободная грамматика и structural tag, — с бэкендами, среди которых xgrammar, guidance, outlines и lm-format-enforcer, и значением по умолчанию auto, которое попытается выбрать подходящий бэкенд исходя из деталей запроса.

• Сделайте «не найдено» явным значением для каждого поля, чтобы отсутствующая дата страхового случая записывалась как отсутствующая, а не угадывалась
• Используйте перечисления (enum) для всего, по чему будет ветвиться другая система: тип страхового заявления, категория тикета, тип документа, код страны
• Добавьте к каждому полю ссылку на источник — страницу и слова, из которых оно взято, — чтобы валидация и ручная проверка могли сверить его с документом

Проверяйте вывод ещё раз в коде приложения обычным валидатором JSON Schema. Бэкенды различаются: на той же странице отмечено, что xgrammar, guidance и outlines используют регулярные выражения в стиле Rust, а lm-format-enforcer — модуль re из Python, и что для моделей Qwen3 Coder с включённым reasoning structured outputs могут оказаться отключены, если содержимое reasoning не разбирается в отдельное поле. Генерация, остановленная лимитом токенов, к тому же обрывается посреди записи. Вторая проверка стоит дёшево.

Валидация: уже существующие бизнес-правила, записанные в виде кода

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

• Страховые заявления: номер полиса существует в системе полисов, дата страхового случая попадает в период страхования, а позиции счёта в сумме дают итог счёта
• Тикеты: идентификатор клиента соответствует реальному аккаунту, а названный продукт действительно есть у этого клиента
• KYC: контрольные цифры машиночитаемой зоны верны, срок действия не истёк, а имя и дата рождения в машиночитаемой зоне совпадают с теми же полями, прочитанными из визуальной зоны

Для документов, удостоверяющих личность, есть собственный валидатор. ICAO Doc 9303 — спецификация машиночитаемых проездных документов — определяет контрольные цифры в машиночитаемой зоне, вычисляемые по модулю 10 с непрерывно повторяющимися весами 7, 3, 1, где буквы от A до Z считаются как 10–35, а символ-заполнитель — как ноль, и указывает, что контрольные цифры позволяют считывателям проверить, что данные интерпретированы правильно.

Маршрутизация: правила и сигналы решают, какие поля видит человек

Маршрутизация решается по каждому полю, а не по документу: страховое заявление, у которого не сходится итог счёта, а всё остальное проходит, отправляет человеку одно поле, а не всё дело. Сигналы:

• Любой отказ валидатора, включая поле, которое схема требует, а модель пометила как ненайденное
• Низкая уверенность OCR в словах, из которых собрано поле, с порогом, заданным для каждого поля на оценочном наборе
• Два источника, которые расходятся, например машиночитаемая и визуальная зоны одного паспорта
• Поля, которые по принятому решению никогда не автоматизируются, например заявленная сумма выше установленного лимита
• Случайная выборка полей, прошедших все проверки, — чтобы долю ошибок, которые никто не отметил, измеряли, а не предполагали

Собственное заявление модели о своей уверенности намеренно не используется; в одной из предыдущих статей этого блога объясняется, почему это слабый фильтр.

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

Оценка по типу документов и по каждому полю, а не одна общая метрика

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

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

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

Аудиторский след: какая модель и какой промпт дали какое поле

Спорное страховое заявление или вопрос аудитора о личности, прошедшей проверку, касается одного поля в одном документе. Запись, которая на него отвечает, пишется по ходу работы пайплайна, по одной на поле, в хранилище только для добавления (append-only):

• Идентификатор документа и хеш содержимого, страница и слова, на которые ссылается поле
• Версия OCR-движка или движка анализа структуры страницы и его уверенность для этих слов
• Имя модели и контрольная сумма весов, версия шаблона промпта и версия схемы
• Результат каждого валидатора, выбранный маршрут и причина этого выбора
• Проверяющий, значение до и после и время, если его изменил человек

Регламент ЕС об ИИ (AI Act) устанавливает требование к логированию для систем, которые он относит к системам высокого риска: статья 12(1) гласит, что системы ИИ высокого риска должны технически позволять автоматическую запись событий (логов) на протяжении всего срока существования системы. Приложение III перечисляет виды использования высокого риска, среди них оценку кредитоспособности физических лиц, за исключением выявления финансового мошенничества, а также оценку рисков и ценообразование в страховании жизни и здоровья; статья 6(3) определяет, когда система из этого перечня всё же не считается системой высокого риска, например когда она выполняет узкую процедурную задачу. Подпадает ли конкретный пайплайн под действие регламента — вопрос к юристам клиента; пополевая запись, которая пишется во время работы, полезна в любом случае.

Персональные данные: каждый этап видит только то, что нужно для его задачи

Пайплайн копирует персональные данные в большее число мест, чем исходная папка. Статья 5(1)(c) GDPR требует, чтобы персональные данные были адекватными, релевантными и ограниченными тем, что необходимо для целей, для которых они обрабатываются. Статья 25(2) требует мер, обеспечивающих, что по умолчанию обрабатываются только персональные данные, необходимые для каждой конкретной цели, и распространяет это на объём собираемых данных, степень их обработки, срок хранения и доступность. В терминах пайплайна:

• Модель получает те страницы, которые нужны её схеме, а не всё дело целиком
• Проверяющие видят поля в своей очереди, а доступ к полным документам выдаётся по ролям и логируется
• Логи приложения записывают идентификаторы документов, имена полей и результаты, но не значения полей и не промпты
• Трейсы промптов и ответов, если их хранят для отладки, лежат в том же закрытом хранилище, что и документы, со своим коротким сроком хранения
• Оценочный набор — это копия реальных документов, и на него распространяются те же средства контроля доступа

OWASP Logging Cheat Sheet относит чувствительные персональные данные и некоторые виды персонально идентифицирующей информации, например данные о здоровье и государственные идентификаторы, к данным, которые обычно не следует записывать в логи напрямую, и говорит, что вместо этого такие данные следует удалять, маскировать, очищать, хешировать или шифровать.

Срок хранения различается по типам документов, а для KYC в ЕС его устанавливает законодательство о противодействии отмыванию денег. Статья 77 Регламента (ЕС) 2024/1624, который применяется с 10 июля 2027 года, требует от обязанных субъектов хранить копию документов и информации, полученных в ходе надлежащей проверки клиента, и обеспечивать, чтобы из этих записей ничего не было изъято. Она устанавливает срок хранения в пять лет, отсчитываемый от окончания деловых отношений или от даты разовой операции, после чего персональные данные подлежат удалению, с учётом исключений, предусмотренных той же статьёй. Исходная KYC-запись остаётся полной в основной учётной системе; собственные копии пайплайна — от трейсов до снимков для проверки — минимизируются и удаляются по своему, более короткому графику.

Пропускная способность: очередь для пика, мощности для стабильной нагрузки

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

• Разделяйте очереди по срочности: KYC-проверка, которой клиент ждёт во время онбординга, не стоит в очереди за пакетом архивных страховых заявлений
• Масштабируйте OCR-воркеры на CPU и серверы моделей на ускорителях независимо, потому что они упираются в предел при разных объёмах
• Следите за собственной очередью движка сервинга: vLLM отдаёт метрики Prometheus на эндпоинте /metrics, включая число запросов, ожидающих обработки, и долю используемых блоков KV-кеша
• Масштабируйте воркеры по глубине очереди, а не по загрузке CPU: документация KEDA описывает масштабирование любого контейнера в Kubernetes в зависимости от числа событий, ожидающих обработки, — со скейлерами (scalers), в том числе для систем обмена сообщениями, и масштабированием до нуля (scale-to-zero)

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

Страховые заявления, тикеты и KYC: один скелет, разные правила

• Страховые заявления: много документов на одно дело, таблицы в счетах и часто данные о здоровье, которые статья 9 GDPR относит к особым категориям, обработка которых запрещена, если не применяется исключение, предусмотренное той же статьёй. Статья 22 даёт человеку право не подвергаться решению, основанному исключительно на автоматизированной обработке, которое порождает в отношении него правовые последствия или аналогичным образом существенно на него влияет, с исключениями в статье 22(2). Поэтому то, ограничивается ли пайплайн извлечением и проверкой, пока решение принимает специалист по урегулированию убытков, — это проектное решение, которое принимается вместе со специалистом клиента по защите данных (DPO), а не инженерное значение по умолчанию
• Тикеты: короткие тексты, большой объём и кто-то, кто ждёт ответа, поэтому задержка важнее; на выходе в основном категория, приоритет и несколько идентификаторов. Текст тикета пишут люди вне компании, и для модели это недоверенный вход — риск, разобранный в предыдущей статье о пилотах
• KYC: немного типов документов со строгими форматами, например паспорта и удостоверения личности, что делает валидацию на правилах сильной. Селфи, сверяемое с фотографией в документе, добавляет биометрические данные, которые статья 9 GDPR тоже относит к особой категории, когда они обрабатываются с целью однозначной идентификации человека. Срок хранения следует законодательству о противодействии отмыванию денег, а результат идёт в комплаенс-решение, которое принимает человек или задокументированное правило

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

Какие инженерные компании строят это внутри вашей собственной инфраструктуры?

У этого вопроса три вида ответов, и продают они разное. Вендоры систем обработки документов продают платформу — иногда устанавливаемую на собственном оборудовании клиента, — которую вы настраиваете под свои документы. Облачные провайдеры продают управляемые сервисы, работающие в их инфраструктуре. Инженерные компании строят пайплайн в вашей среде из открытых компонентов и ваших правил.

С кем бы из них вы ни говорили, эти вопросы показывают, строила ли команда такое раньше:

• Какие этапы обращаются к каким-либо сервисам за пределами вашей сети, включая OCR, мониторинг, трекинг ошибок и инструмент разметки?
• Как выглядит схема вывода для одного из ваших типов документов и как представлено «не найдено»?
• Какие сигналы отправляют поле на проверку и как выбирались пороги?
• Как исправления проверяющих попадают в оценочный набор, не загрязняя ту его часть, по которой принимаются решения о релизе?
• Могут ли они показать для одного поля в одном документе модель, промпт, схему и проверяющего, которые дали его значение?
• Кому принадлежат код пайплайна, схемы и оценочный набор после окончания работ и какие части остаются переиспользуемыми компонентами подрядчика?

Если ответ на первый и пятый вопросы остаётся общим, значит, путь данных и аудиторский след ещё не спроектированы.

Что amBrain может сказать о собственной работе в этой области

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

Эта статья объясняет, как работает такой пайплайн; это не кейс, в ней не называются клиенты, и она не утверждает, что amBrain построил систему для страховых заявлений, тикетов или KYC. Названная выше работа в проде — извлечение уведомлений брокеров и торговых площадок для торговой системы.

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