В прошлой статье мы уже говорили, что нашли быстрый и простой способ, как с помощью LLM вытаскивать данные из юридических документов и доверенностей. А сегодня расскажем, какой промт мы для этого использовали.

С чего все началось

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

Список полей, которые нужно было извлечь мы получили от заказчика. Для судебных документов это были: даты выдачи, ФИО должника, сумма пошлины, номер контракта, дата выдачи решения, наименование суда, дата контракта, сумма задолженности. Для доверенностей — дата выдачи и срок окончания ее действия, сумма и пр. 

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

Заказчику нужны были точность, скорость и гибкость под новые документы — поэтому мы выбрали LLM вместо классического NLP. Так начался подбор универсального промта, работающего с разными типами документов. 

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

Промт тестировали на GigaChat и YandexGPT — облачных LLM от крупных российских провайдеров, как на более доступном и экономичном варианте для клиента. От локальных моделей отказались: хотя они сами по себе бесплатны, их использование требует дорогой инфраструктуры — видеокарт, LLM-ферм и пр.

Структура универсального промта

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

Контекст модели. В начале промта мы задали модели ее роль. Например, «Ты — эксперт по извлечению данных из юридических документов. Твоя задача — анализировать текст и возвращать только запрошенную информацию».  

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

Описание задачи и формат данных. После указания контекста, важно четко объяснить LLM, что от нее требуется. Например, «Извлеки имя человека, на которого выдана доверенность. Имя должно быть в формате "Фамилия Имя Отчество" в именительном падеже». 

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

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

Для этого в промте пришлось детально описывать структуру ответа: имя поля, его формат и место в выходном объекте. Например: «Верни извлеченное имя в поле full_name` JSON-объекта». Такой подход смог гарантировать машиночитаемый результат для дальнейшей обработки: упрощает парсинг и автоматизацию процессов, так как данные сразу поступают в нужном формате.  

Примеры. В промт-инжиниринге есть несколько методик работы с промтами. Мы протестировали две из них: Zero-shot и Few-shot. В первом случае запрос отправляется в LLM без примеров, и модель полагается только на описание задачи. Например: «Извлеки дату выдачи доверенности».  

Однако опыт показал, что без примеров точность извлечения данных у нас падала на 30-40%. Поэтому остановились на подходе few-shot, который предполагает использование примеров для «обучения» модели. Добавление в запрос всего 3-5 примеров позволило свести количество ошибок к минимуму.  

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

Разбираем промт на запчасти: итоги экспериментов

Провели серию экспериментов (аblation study), чтобы определить, какие компоненты промта критически влияют на производительность. Для этого мы последовательно исключали отдельные элементы промта — такие как формат данных, контекст или примеры — и замеряли изменения в точности модели. Этот подход позволил выявить избыточные части, которые не влияют на результат, и ключевые компоненты, без которых качество извлечения значительно падает.

Стоит отметить, что ablation study и настройку промта мы проводили с использованием локальных моделей таких как: llama3 8b дообученной на русском корпусе. Это помогло нам понять, как влияет ли язык промта на качество извлечения данных. Эксперименты показали, что русскоязычные промты работают не хуже англоязычных, несмотря на то, что большинство моделей изначально обучаются на корпусах с небольшим количеством русского текста. Разница в точности оказалась незначительной.

Проблемы и ограничения 

Однако не все наши попытки заставить LLM точно извлекать данные прошли гладко. Вот основные сложности, с которыми мы столкнулись

Верификация данных. Даже самые точные LLM сегодня не гарантируют 100% правильности извлечения данных. Мы столкнулись с тем, что модели допускали ошибки в 8% судебных документов, а для доверенностей этот процент был вдвое выше. Поэтому после извлечения информации из документов требовалось их верифицировать. 

Мы решили эту задачу так:  

1. Разбили документ на пронумерованные строки.  

2. Попросили модель указать номер строки с ответом.  

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

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

Погрешность в одну строку для нас была не критична — она не влияла на скорость и точность верификации. Этот подход позволил нам упростить задачу и улучшить итоговое качество.

Цензура. Облачные LLM работают как сервис с оплатой за токены, но иногда отказываются обрабатывать документы. Так GigaChat цензурировал 3-4% наших документов, что выше, чем у YandexGPT (1-3%).

Ниже результаты наших замеров по цензуре на разных облачных моделях:

Локальные модели лишены этого недостатка, но требуют мощных видеокарт. Например, в наших тестах использовались карта NVIDIA Quadro RTX 8000 с 46 ГБ. Такие видеокарты дороги, и клиенту придется их покупать или арендовать.

Зависимость качества извлечения от вида модели. Промт, идеально работающий на GigaChat Max, мог давать худшие результаты на других LLM. Для нашего типа документов отлично подошли модели GigaChat Max и YandexGPT, работающая в режиме structured output base. Он позволяет нейросети выдавать ответы в строго заданном формате по указанной JSON-схеме.

Оценивали эффективность промтов по двум метрикам: F-мера (извлечение полей) и Precision (поиск строк). Вот какие результаты у нас получились: 

Что дальше

Наши эксперименты подтвердили, что LLM — мощный инструмент для работы с полуструктурированными документами. Универсальный промт с четкой структурой, именами полей и примерами позволил нам добиться довольно высокой точности извлечения на юридических документах и доверенностей.

Однако предстоит решить несколько важных задач:

1. Длинные документы и составные файлы. Хотя современные модели поддерживают большие контексты (до 128K и выше), но это не всегда работает достаточно хорошо. Предполагаем, что в этом случае есть риски столкнуться с проблемой Needle In A Haystack — когда модель должна найти и точно извлечь небольшой фрагмент из длинного документа или множества текстов.

Сложны также случаи, когда один файл содержит несколько типов документов (например, судебный приказ со сканами приложений) — это снижает качество экстракции на 8-10%. И мы планируем это исправить.

2. Повторяющиеся поля. Нужна адаптация промтов для извлечения дублирующихся сущностей (например, несколько подписей в договоре) без потери точности.

3. Мультиязычные документы. Требуется оценка качества работы на документах на других языках (белорусском, казахском и др.), которые встречаются у клиентов.

Мы продолжаем улучшать подход, тестируя новые модели, форматы промтов и методы решения этих проблем.

А как вы используете LLM в своих проектах? Делитесь в комментариях!