Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Проверку документов клиента для допуска к торгам удалось разложить на отдельные автоматизируемые операции, не передавая весь процесс одной LLM. В препринте Royal Bank of Canada, который не рецензирован и приводит собственные замеры авторов, Spectra сократила объём ручной проверки на 96%. Такая схема позволяет менять модели и исправлять отдельные этапы, не перестраивая весь KYC-процесс.
Правила определяют работу модели, а не прячутся в запросе
Spectra хранит требования комплаенса в PostgreSQL: виды документов, обязательные поля, требования для разных юрисдикций и типов организаций, а также исключения. По этим данным система составляет список необходимых документов без обращения к LLM.
Это отделяет нормативную логику от вероятностной. Если для нового типа клиента нужен другой документ или дополнительное поле, команда меняет записи в базе, а не переписывает большой запрос и не переобучает модель. Для каждого решения можно показать конкретное правило, которое его вызвало.
Загруженный файл проходит шесть этапов: очистку, поиск внедрённых инструкций, классификацию, получение схемы полей, извлечение данных и проверку по правилам. Только часть этих операций выполняют модели. Например, схема извлечения формируется обычным запросом к базе после того, как определён вид документа.
Такой порядок сокращает контекст: модель получает не весь многостраничный регламент, а только подходящие определения, поля и проверки. В работе нет денежной оценки экономии, но источник затрат понятен — система убирает лишние вызовы LLM и не отправляет каждой модели весь набор правил.
Изоляция этапов упрощает исправления. Если система неверно извлекает полномочия подписанта, можно уточнить схему конкретного поля. Если проверка неоднозначно применяет исключение, можно изменить представление политики, не затрагивая классификатор документов.
Точность зависит не только от документа, но и от схемы
Классификацию проверяли на 21 реальном KYC-документе девяти видов. Извлечение оценивали отдельно — на 15 синтетических документах со 141 размеченным полем. Все реальные документы система классифицировала правильно, а доля точных совпадений при извлечении составила 89,4%.
Эти результаты относятся к разным наборам, поэтому их нельзя объединять в общую оценку качества. Реальные файлы были относительно чистыми PDF, а список допустимых видов документов заранее сужался под конкретный клиентский процесс. Извлечение, напротив, проверяли не на реальных банковских документах, а на созданных для теста примерах.
Ошибки показывают границу подхода. Модель хорошо справлялась с названиями организаций, странами регистрации и регистрационными номерами, но ошибалась на сложных вложенных полях. В корпоративных решениях она заполняла поле о полномочиях подписанта, хотя ожидаемым результатом было пустое значение.
Другой источник ошибок — несовпадение словарей. Модель могла извлечь понятное человеку описание продукта, но система ожидала значение из внутренней классификации. Ещё одна проблема — лишние данные: если рядом с нужными полями находились телефон или сведения о работодателе, модель иногда добавляла их в результат, хотя схема этого не требовала.
Следовательно, качество здесь определяет не только выбранная LLM. Жёсткие форматы результата, контролируемые словари и точное описание пустых значений влияют на итог не меньше, чем способность модели читать документ.
Архитектурный план меняется, выбор модели — пока нет
Работа даёт практический шаблон для команд, которые автоматизируют комплаенс или другой документооборот с формальными правилами. Политику стоит хранить как данные, а LLM поручать задачи, где действительно нужна работа с неоднородным текстом: определить вид документа, найти значение и сопоставить его с контекстом.
Контракт между этапами должен включать структурированный результат, оценку уверенности и ссылку на источник: страницу, фрагмент текста и применённый пункт политики. Тогда спорный ответ можно отправить специалисту, а ошибку — привязать к конкретной операции. Spectra также сохраняет ручные исправления и их обоснования, поэтому окончательное решение остаётся у проверяющей команды.
Саму оценку уверенности нельзя считать доказательством правильности. В Spectra любое значение ниже максимальной уверенности отправляется на проверку, но работа не показывает, насколько хорошо эта оценка соответствует реальной вероятности ошибки на большом потоке. Для внедрения понадобится отдельно настроить правила передачи человеку на собственных документах.
Spectra не даёт основания выбрать LlamaCloud, o3-mini или GPT-4.1-mini: модели не сравнивали между собой. Зато работа меняет порядок проектирования системы. Сначала следует описать состояния процесса, правила, схемы данных и точки ручного контроля, а затем подключать модели к изолированным операциям. При такой структуре замена LLM не требует переносить вместе с ней нормативную логику и аудиторский след.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
