Привет! Меня зовут Георгий Чернышов, я — аналитик СофтМедиаЛаб. В текущем тренде и потребности бизнеса в решениях, основанных на искусственном интеллекте, я создаю архитектуру ИИ-решений. Один из моих проектов — умный ассистент юриста, который должен максимально ускорить и удешевить работу с договорами.

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

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

1. Затягивал процесс работы с документами;

2. Обходился довольно дорого для компании.

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

Принцип работы ИИ-ассистента

Какие задачи интеллектуальный помощник должен был решать:

1. Проверять орфографические и пунктуационные ошибки в тексте.

2. Выделять основные параметры договора и проверять согласованность реквизитов в документе.

3. Показывать, какие риски для компании есть в договоре. Вот список рисков, которые мы обычно проверяем.

4. Отражать результаты проверок в комментариях к задаче.

Среда работы ИИ ассистента – система управления проектами, в которой документы двигаются по задачкам и в один момент должны попасть на этап «АI проверка». На этапе аналитики в качестве основного инструмента была выбрана последняя Gemini 2.5Pro, а заказчик выбрал модель pay-as-you-go подписки как самую оптимальную для бизнес-задач.

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

Старт проекта и инсайты

Когда проект стартовал, самой сложной казалась проверка рисков. Мы с командой предполагали, что из-за размытых, двояких и всяких хитрых юридических формулировок, ИИ будет трудно определить риски в договоре, а ответственность за проведение этой проверки наибольшая. А что получилось в итоге?

В итоге поделюсь важными инсайтами, которые мы с командой поняли в ходе проекта:

1. Чем больше примеров договоров, тем лучше. В нашем случае мы использовали порядка 50 различных документов.

2. Прежде чем анализировать документ, текст из него из документа необходимо извлечь!. Анализировать файл, а не текст документа, а не текст документа – фиаско.

3. Количество страниц не является объективной мерой объёма документа

4. Большим вызовом стала проверка орфографии и пунктуации

Во-первых, нужно обозначить, что целью был именно поиск ошибок, которые стандартные текстовые редакторы не считают ошибкой. (Зачем нужен ИИ инструмент, если все можно сделать в Office Word?). И для того, чтобы их найти, их необходимо правильно определить как: «Орфография и грамматика: Слово написано неверно без учета регистра, нарушено согласование слов. Пунктуация: отсутствует необходимый знак препинания или наоборот, присутствует лишний.»

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

В-третьих, эффективной является стратегия деления документа на чанки (от англ. Chunk — ячейка, кусок, осколок) и, очевидно, чем мельче чанки, тем эффективнее, но дольше процесс анализа. Но если делить документ на чанки по 1-2к токенов (это примерно 4-8 тысяч символов), то продолжительность анализа напрочь убивает бизнес-ценность продукта, так как выполнение может занять до 15 минут. В итоге, наиболее оптимальным является динамический подход относительно объема символов в документе, когда маленькие документы не делятся на чанки совсем, а большие - имеют строго заданное количество чанков.

5. Для любой проверки нужен эталон

А если его нет, можно создать. Вместо того, чтобы считать один из методов эталонным, для каждого исследуемого документа создавался сводный эталонный список ошибок. Этот так называемый «Золотой список» формировался путем агрегации всех уникальных ошибок, найденных всеми тестируемыми методами.

Однако самой важной частью такого метода, и самой продолжительной, будет ручная человеческая верификация всех найденных ошибок (ground-truth data). После формирования списка для расчета становятся доступны объективные метрики, типа F1-Score. Взять готовый отредактированный художественный текст - тоже не выход, так как количество оборотов в нем несравнимо меньше.

6. Галлюцинации ЛЛМ никуда не делись

На самом деле мы сначала думали, что это галлюцинация. Вот пример: «В договоре использованы визуально схожие символы кириллицы (С, Ј, В) вместо латиницы (C, J, B), что делает реквизит нефункциональным».

А потом нам позвонили и строгий мужской голос сказал:
— Престани да пишеш ову глупост! Српска Ћирилица такође има слово Ј! То је вуковица!
После чего нам пришлось переписать все возможные совпадения символов.

7. Проблема поиска рисков оказалась наиболее управляемой задачей из всех

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

При тестировании функции была выявлена интересная Ո -образная закономерность полноты проверки от температуры. Температура — это параметр, который определяет степень «креативности ответа». Так вот, была обнаружена нелинейная зависимость полноты от температуры (Ո-образная кривая) и опровергнута гипотеза, что самая низкая температура является самой стабильной и точной. При низких температурах ИИ находит только те формулировки, которые по большей части совпадают с формулировками рисков. А при высоких температурах - превращается в «юриста-параноика», когда каждый пункт при определенных обстоятельствах - это риск.

8. Качественным улучшением стало изменение формата вывода найденных рисков

По первому варианту риски формировались в список, формируемый ЛЛМ по ходу анализа документа. При таком подходе категории рисков чередовались, а сам ответ был отсортирован по пунктам основного документа. Качественное улучшение появилось при изменении формата группировки - так, чтобы в начале ответа были все пункты соответствующей категории рисков, затем другие. Таким образом, ИИ сначала формировал пул найденных рисков, а затем перепроверял его в процессе форматирования.

9. Создание эталона по определению рисков

Здесь необходимо отдать должное вовлеченности и организованности команды заказчика. Для создания эталона (и для выбора полноты ответа в зависимости от температуры), заказчику было предложено три варианта списков рисков для валидации. Из 32ух пунктов только по 3ем у команды заказчика возникли разногласия.

Такой подход позволил нам:

• сформировать эталонный документ;

• выбрать необходимую полноту ответа (температуру);

• валидировать найденные риски.

10. Для всех юридических проверок сначала надо определить сторону

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

Итоги

Подводя итоги в части разработки, нужно сказать, что принцип засовывания человека в петлю с ИИ (Human-in-the-loop AI) является обязательным требованием, для ИИ проектов, связанных с анализом документов - в частности. Для обеспечения требуемых результатов человек должен постоянно проводить A/B тестирование полученных результатов в сравнении с предыдущими, с эталонными и со здравым смыслом.

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

Вот такой интересный кейс получился. А вы создавали ИИ-помощников? Расскажите о своем опыте или поделитесь мнением в комментариях.