Ранее мы уже делились опытом использования LLM для обработки юридических документов и доверенностей. Сегодня расскажем о другом подходе, который применил наш технологический партнер ООО «ЕСМ-Консалтинг». При реализации нескольких показательных кейсов для крупных российских энергосбытовых компаний мы автоматизировали в них обработку судебных документов с помощью платформы ContentCapture и больших языковых моделей (LLM).
Изначально мы рассматривали два подхода к реализации подобных проектов. Первый – предполагал классическую работу с гибкими описаниями документов, когда правила извлечения информации задаются человеком. Второй вариант – комбинированный, с использованием больших языковых моделей (LLM). Наш опыт показал, что последний подход как минимум в три раза экономичнее при работе с неструктурированными документами. Он обеспечивает хорошую скорость и высокое качество извлечения данных (более 95% правильно извлеченных данных), позволяя нашим заказчикам масштабировать обработку документов без роста операционных расходов.
Несмотря на формализованный набор данных, судебные документы сильно отличаются по внутренней структуре. Например:
• судебные приказы, хотя и имеют стандартную структуру, но текстовое наполнение этой структуры может сильно отличаться для разных судов
• определения суда еще менее унифицированы – их содержание зависит от процессуальных нюансов
• постановления ФССП содержат как шаблонные блоки (дата, номер дела), так и вариативные части, где указываются причины окончания производства (исполнение, невозможность взыскания и др.)
Использовать только правила автоматического извлечения информации, описанные человеком — проблематично из-за сильной вариативности документов. В этом случае всегда найдется вариация документа, обработка которой не будет предусмотрена этими шаблонами.
Однако использование только 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 дней, в данном решении адаптация производится менее чем за пол дня.
Теперь этот опыт можно масштабировать на другие отрасли — там, где тонны документов, жесткие сроки и высокие требования к точности извлечения данных. Например, банки, страховые, госструктуры — везде, где важно обеспечить работу с информацией в закрытом контуре.