Ранее мы уже делились опытом использования LLM для обработки юридических документов и доверенностей. Сегодня расскажем о другом подходе, который применил наш технологический партнер ООО «ЕСМ-Консалтинг». При реализации нескольких показательных кейсов для крупных российских энергосбытовых компаний мы автоматизировали в них обработку судебных документов с помощью платформы ContentCapture и больших языковых моделей (LLM).

Изначально мы рассматривали два подхода к реализации подобных проектов. Первый – предполагал классическую работу с гибкими описаниями документов, когда правила извлечения информации задаются человеком. Второй вариант – комбинированный, с использованием больших языковых моделей (LLM). Наш опыт показал, что последний подход как минимум в три раза экономичнее при работе с неструктурированными документами. Он обеспечивает хорошую скорость и высокое качество извлечения данных (более 95% правильно извлеченных данных), позволяя нашим заказчикам масштабировать обработку документов без роста операционных расходов.

Специфика обработки судебных документов

Несмотря на формализованный набор данных, судебные документы сильно отличаются по внутренней структуре. Например:

• судебные приказы, хотя и имеют стандартную структуру, но текстовое наполнение этой структуры может сильно отличаться для разных судов
• определения суда еще менее унифицированы – их содержание зависит от процессуальных нюансов
• постановления ФССП содержат как шаблонные блоки (дата, номер дела), так и вариативные части, где указываются причины окончания производства (исполнение, невозможность взыскания и др.)

Использовать только правила автоматического извлечения информации, описанные человеком — проблематично из-за сильной вариативности документов. В этом случае всегда найдется вариация документа, обработка которой не будет предусмотрена этими шаблонами.

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

Поэтому было принято решение использовать комбинацию классических технологий и LLM:

• данные в шапке судебных документов, такие как дата решения и номер дела, извлекаются с помощью гибких описаний, поскольку их местоположение предсказуемо, а LLM может ошибаться из-за недостатка контекста. Например, если в шапке документа указана просто дата без пояснений, модель не всегда корректно интерпретирует ее назначение.
• основная часть документа обрабатывается LLM для качественного извлечения неструктурированных данных, таких как номера лицевого счета, периодов взысканий, списка должников и их паспортных данных и других. И здесь важно точно указать в инструкции для модели – что именно требуется найти в тексте документа. Например, запрос «номер лицевого счета жилого помещения» работает надежнее, чем просто «номер лицевого счета», так как исключает захват посторонних данных. Аналогично, «серия паспорта должника» предпочтительнее общего «серия паспорта».

Выбор LLM

В качестве LLM, на проектах была выбрана языковая модель YandexGPT Pro. Выбор в пользу облачного решения был сделан по двум причинам. Во-первых, из-за ограниченных вычислительных возможностей наших заказчиков — у большинства из них не было достаточных ресурсов для развертывания и эффективной работы локальных моделей в закрытом контуре. Однако описанный ниже подход к обработке судебных документов отлично работает и на локальных моделях, которые возможно установить в закрытом контуре заказчика, без доступа в интернет. Мы проводили тесты Qwen2.5-72B и ей подобных.

Во-вторых, платформа не только соответствует строгим требованиям законодательства, но и подтвердила свою надежность независимыми аудитами. Yandex Cloud имеет аттестат соответствия ИСПДн требованиям безопасности, полностью отвечает нормам ФЗ-152, постановления Правительства № 1119 и Приказа ФСТЭК № 21. Кроме того, YandexGPT в составе Foundation Models также успешно прошел аудит по ФЗ-152, что гарантирует заказчикам дополнительный уровень защиты.

Несмотря на встроенные механизмы безопасности, для максимального снижения рисков утечки персональных данных мы пошли дальше и отключили логирование запросов. Это соответствует рекомендациям самого Yandex Cloud: в каждый REST-запрос или вызов метаинформации gRPC мы добавили опцию x-data-logging-enabled: false. Благодаря этому переданные запросы не сохраняются на серверах, что сводит к нулю вероятность их несанкционированного доступа или утечки.

Схема извлечения данных

Прежде чем передать данные в языковую модель, ContentCapture проводит подготовку документов:

• их классифицируют, разбивают на смысловые блоки

• удаляется избыточная информация, анализируются только ключевые блоки с релевантными данными: основания возврата, ссылки на статьи, ФИО, даты и другие значимые критерии. Это существенно снижает стоимость обработки

• затем текст собирается в оптимальные для анализа фрагменты

Заложенную в ContentCapture механику обработки документов можно дополнять специализированными скриптами (например, C#-сборками), которые: выполняют предобработку данных перед отправкой в API, корректируют ответы модели (форматы дат, JSON-структуры), реализуют сложную постобработку (разделение сумм, нормализацию значений).

С помощью подобных скриптов был реализован механизм динамического формирования инструкции для LLM. Его суть следующая: ContentCapture автоматически определяет поля с пометкой «индексные», подставляет их в структуру JSON и генерирует запрос.

Схема JSON динамическая и меняется в зависимости от типа документа и набора извлекаемых заказчиком данных. Инструкция для модели – анализ текста и заполнение JSON.

В скриптах также задаются уточняющие пояснения для инструкций: правила поиска данных, запреты на вычисление сумм и пр.

После формирования инструкции система отправляет запрос в LLM, обрабатывает ответ и записывает данные в соответствующие поля документа.

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

Технические сложности

Внедрение ContentCapture в связке с LLM не обошлось без сложностей. Каждый этап работы с документами потребовал нестандартных решений и дополнительной настройки.

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

Чтобы уменьшить ошибки, расширяли инструкцию, добавляли в нее различные дополнительные условия и исключения («если встретишь X, не делай Y»). Однако вместо улучшения, усложнение инструкции привело к обратному эффекту — модели чаще ошибались.

После тестирования разных подходов, экспериментальным путем были подобраны оптимальные правила формирования инструкции:

• отказ от разделения на поиск и форматирование

• единая компактная инструкция с явным указанием схемы JSON

• zero-shot метод (без примеров)

Парсинг чисел и данных. Языковые модели иногда допускали неочевидные ошибки, например, заменяли английские буквы на русские в ключевых терминах. Для исправления таких случаев реализовали дополнительную проверку через алгоритм Левенштейна, который вычисляет степень похожести слов. Этот метод определяет, сколько символов нужно изменить в слове, чтобы получить правильный вариант.

Пример

• «аmоunt» (с русской «О») и «amount» — расстояние Левенштейна = 1 (замена одной буквы)

• «Total Аmount» и «amount» — расстояние больше, так как требуется исправить несколько символов

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

Еще одна сложность состояла в том, что протестированные LLM не всегда корректно извлекали числа, особенно дробные (float). Модели могли искажать разряды, путать разделители или вовсе пропускать часть цифр. Перепробовав разные инструкции, выбрали компромиссный вариант: модель возвращает числа в исходном виде, а их обработка (парсинг, форматирование) выполняется отдельно строгими алгоритмами. Например, сумма задолженности всегда разбивается на рубли и копейки по первым и вторым цифрам. Это снизило ошибки, хоть и добавило шаг постобработки. Даже несмотря на хорошую работу последней версии YandexGPT Pro 5 с числами, мы дополнительно производим обработку данных скриптом для надежности.

Выводы и результаты

В связке ContentCapture и LLM мы видим новые возможности для автоматизации процессов работы с неструктурированными документами — и не только в энергетике. Да, были свои «вызовы»: инструкции приходилось шлифовать, а с числами — повозиться. Но результат того стоил: система не просто работает, а делает это быстро, точно и без лишних затрат.

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

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