Когда слышишь «автоматизация согласования договоров», представляешь: ИИ прочитал документ — и выдал готовое решение Кейс телеком-оператора. Тысячи договоров аренды: земля и крыши под базовые станции. Сценарий стандартный: отправили контрагенту шаблон договора — получили заполненный вариант — сравнили с шаблоном. Казалось бы, типовая задача для сравнения файлов в Word. Но Word показывает все расхождения подряд: заполненные поля, варианты из скобок «ИЛИ», мелкую редактуру. И среди этого массива легко теряются действительно важные правки: сроки, суммы, условия расторжения. Много времени уходит на разбор расхождений, пока другие договоры ждут своей очереди. Почему нельзя просто отдать это LLM? Потому что здесь не одна задача, а три: 1. Структура. Контрагенты переставляют пункты и меняют заголовки. Построчное сравнение показывает расхождения, хотя смысл мог сохраниться. 2. Ожидаемые отличия. В шаблоне есть пустые поля и опциональные блоки. Их заполнение — норма, но инструмент воспринимает это как расхождения. 3. Точечные изменения. Одно слово или дата могут радикально менять условие. И находить их нужно быстро и надёжно. Даже если бы модель идеально решала все три задачи, остаётся четвёртый, прагматичный фактор: «гонять» через LLM каждый договор — всё равно что приглашать аналитика Big4 для разовой сверки. Экономика такого решения не сойдётся в масштабе. Поэтому следующий шаг — каскад детерминированных правил, который отсеивает большинство второстепенных расхождений до того, как дело дойдёт до LLM. Решение построили как конвейер: 🔸Сначала система определяет, какая типовая форма и редакция пришли. 🔸Затем нормализует структуру и сопоставляет фрагменты по смыслу. 🔸Дальше — каскад из 15-ти правил. Он отсеивает служебные отличия: заполнение полей, допустимые варианты, опциональные разделы. 🔸 И только потом включается LLM. Но в узкой роли: классифицировать оставшиеся расхождения по критичности, подсветить риски, проверить условия, числа и даты. Не переписывать договор, а помочь юристу понять, куда смотреть в первую очередь. LLM получает на вход не все страницы договора, а небольшие фрагменты, где действительно нужно принять решение. Зачем это нужно? Чтобы снизить нагрузку на LLM. Чем больше мы решаем формальными методами, тем меньше требований к модели, дешевле её эксплуатация, проще архитектура и понятнее поведение системы. Что на выходе Формируется протокол разногласий со ссылками на конкретные места в тексте. И ключевой момент: протокол автоматически прикрепляется к карточке договора в 1С. Результат звучит буднично: протокол разногласий автоматически появляется за 10–30 секунд и попадает в 1С ещё до того, как юрист в первый раз открыл карточку договора. Юрист начинает работу не с нуля, а с подготовленного черновика протокола. Что важно в архитектуре LLM здесь может меняться. А постоянная часть — эталоны, правила, workflow, интеграция с 1С — остаётся. И ещё один плюс: качество растёт благодаря работе юриста. Если он поправил протокол, это можно превратить в новое правило или исключение. Система учится в процессе эксплуатации. Если коротко 🔸Отсекли рутину формальными методами без использования LLM — правила берут на себя 80% расхождений. 🔸Передаём LLM только те фрагменты, где действительно нужно её решение. 🔸Встроили результат в 1С и процесс согласования — система не просто ответила, а сделала работу. Подробнее: https://blogs.epsilonmetrics.ru/avtomatizaciya-soglasovaniya-dogovorov/