Сейчас в Legal AI доминирует довольно наивная идея: если большая языковая модель уже умеет писать приличный юридический текст, значит осталось только дать ей корпус судебных актов, прикрутить чат и получить “цифрового юриста” То есть будто бы право – это просто очень длинный prompt.
Проблема в том, что суд – не текстовый жанр. Суд – это система.
И как только вы выходите за пределы задач вроде “суммаризируй решение”, “достань нормы” или “набросай черновик ходатайства”, выясняется неприятная вещь: LLM неплохо работает как интерфейс, но очень слабо подходит на роль самой архитектуры. Она умеет красиво объяснять. Но плохо заменяет процессную модель, вероятностный движок, слой маршрутизации и проверку ограничений.
Это особенно заметно в задачах судебной аналитики: где дело может зависнуть, на каком этапе ломается траектория, где процесс ветвится, где нужен не текст, а расчет. И вот тут внезапно оказывается, что самые полезные идеи лежат не в свежем AI-маркетинге, а в работах полувековой давности.
Еще в конце 1960-х исследователи моделировали прохождение felony defendants через судебную систему округа Колумбия, а в 1973 году уже описывали преимущественно алгебраический подход к симуляции legal systems для совместной работы инженеров и юристов, в том числе на материале судов Индианы. С инженерной точки зрения это важно не как исторический курьез, а как ранняя попытка честно ответить на вопрос: что именно мы автоматизируем в праве – текст, решение или саму систему.
Ниже несколько простых, но, как кажется, важных идей по прочтении двух статей полувековой давности – Simulation Applied to a Court System (Jean G. Taylor, Joseph A. Navarro, Robert H. Cohen, 1968) и An algebraic method for simulating legal systems (Michael K. Sain, Eugene W. Henry, John J. Uhran, 1973).
Почему LLM-обертка быстро упирается в потолок
Когда мы говорим “автоматизировать юриста”, мы почти всегда подменяем задачу. Нам кажется, что нужно смоделировать мышление опытного специалиста: как он читает дело, как замечает слабые места, как оценивает перспективу. Но на практике это часто приводит к тому, что модель имитирует стиль рассуждения лучше, чем саму структуру процесса.
Для договора это еще терпимо. Для суда – уже нет.
Потому что в судебной задаче есть как минимум пять разных сущностей, которые иногда сваливают в одну кучу:
-
Текст.
-
Процессуальная траектория.
-
Ограничения и сроки.
-
Вероятностные переходы между стадиями.
-
Объяснение результата человеку.
LLM годится в основном для пятого пункта и частично для первого. Все остальное она может только маскировать. И именно здесь старые court simulations оказываются неожиданно современными.
Урок первый: сначала модель процесса, потом “умный юрист”
Ранние судебные симуляции были построены вокруг очень приземленной идеи: суд нужно рассматривать как систему обработки потока дел, а не как магию отдельных участников. Это звучит скучно, но именно в этом и есть инженерская честность.
GPSS, который использовался в ранних моделях такого рода, вообще создавался как General Purpose Simulation System для дискретных процессов, где ключевую роль играют события, очереди, ресурсы и переходы между состояниями. И это почти идеальная метафора для суда: поступление дела, распределение, ожидание, ходатайство, перенос, следующая инстанция, выход.
Отсюда очень простой, но болезненный вывод для Legal AI: прежде чем заставлять модель “думать как судья” нужно хотя бы описать, что именно происходит с делом в системе. Prompt не важнее process graph. Тонкость формулировки не важнее topology.
Именно поэтому плохой Legal AI обычно выглядит так: один огромный вызов LLM, куда свалили фабулу, документы, пару судебных актов и просьбу “оцени шансы”. А хороший – как конвейер, где языковая модель вообще не трогает то, что можно описать правилами, графом или статистикой.
Урок второй: право нелинейно, и это не баг, а базовое свойство системы
Юристы это и так знают на практике, но разработчики почему-то регулярно про это забывают. Судебное дело почти никогда не идет по прямой. Есть возвраты. Есть переносы. Есть апелляции. Есть новые доказательства. Есть процессуальные петли, после которых дело вроде бы “то же самое”, но в другой конфигурации.
Именно поэтому работа 1973 года до сих пор цепляет: ее авторы описывали primarily algebraic technique for simulating social systems в логике system theory и явно мыслили не текстами, а структурой переходов. Для разработчика это важный сигнал: юридический процесс удобнее мыслить как граф состояний с вероятностными переходами, чем как цепочку абзацев.
Из этого, кстати, вытекает одна неприятная правда про многие современные AI-продукты в праве. Они пытаются решить задачу уровня workflow engine с помощью chat completion API. То есть вместо моделирования системы берут модель, которая хорошо продолжает текст, и просят ее быть одновременно процессуалистом, аналитиком, маршрутизатором и калькулятором вероятностей.
Работает ли это на красивых демо? Да.
Ломается ли это на реальном грязном контуре? Тоже да.
Урок третий: юристу нужен не “ответ”, а карта того, как к пришли к этому ответу
Самая опасная ошибка в Legal AI – думать, что пользователю нужен просто финальный prediction. На самом деле ему нужна конструкция доверия. Юристу мало услышать: “вероятность удовлетворения иска 63%”. Судье тем более мало. Нужно понимать, какие факторы повлияли на вывод, где модель уверена, где нет, что было взято из данных, а что является интерпретацией, и на каком этапе вообще возможна ошибка.
В современных обсуждениях predictive justice именно эта проблема постоянно всплывает снова: судебные решения действительно становятся сырьем для моделей, но объяснимость и проверяемость вывода остаются одной из центральных трудностей. Поэтому explainable AI в праве – это не декоративная надстройка, а попытка сделать систему профессионально пригодной: чтобы ошибку можно было обнаружить, спорить с ней, а не просто восхищаться гладкостью ответа.
С инженерной стороны это означает простую вещь: результат должен приходить не в форме “черного ящика с уверенным тоном”, а в форме интерфейса. Где видно допущения. Видно маршрут дела. Видно, какие признаки сыграли роль. Видно, где модель опирается на статистику, а где – на текстовую реконструкцию.
Короче: не просто answer, а observability.
Как бы я проектировал Legal AI-систему сегодня
Если отбросить всякую AI-магию, архитектура для судебной аналитики, как кажется, может выглядеть примерно так:
-
Слой данных: судебные акты, карточки дел, процессуальные документы, метаданные.
-
Слой нормализации: выделение сущностей, стадий, событий, сроков, участников.
-
Процессная модель: граф движения дела, допустимые переходы, исключения, циклы.
-
Вероятностный слой: частоты, калибровка, confidence, интервалы, а не только “да/нет”.
-
Правила и валидация: проверки на противоречия, пропуски, процессуальные ограничения.
-
LLM-слой: объяснение результата, работа с вопросами пользователя, генерация понятного текста.
-
UI-слой: визуализация маршрута, факторов, сценариев и зон неопределенности.
LLM здесь не исчезает. Но она перестает быть богом системы. Она становится переводчиком между машинной моделью процесса и человеком.
И, честно говоря, это намного более реалистичная роль. Потому что LLM хороша в интерпретации, резюмировании, классификации по контексту, работе с неоднородным текстом. Но когда ей поручают быть одновременно движком процесса, статистическим аппаратом и источником истины, начинаются галлюцинации, которые в праве особенно токсичны.
Текстовая генерация, прогноз, объяснение, маршрутизация и проверка консистентности – это разные задачи. Если их смешать, система начинает звучать умно, но теряет инженерную опору. Если разделить – появляются вещи, без которых Legal AI не взрослеет: воспроизводимость, дебаг, измеримость качества и хоть какая-то защита от красивой ерунды.
Это, кстати, и есть главный урок тех старых работ. Исследователи 1960-х и 1970-х не пытались сделать “цифрового судью”. Они пытались понять, как устроен сам контур прохождения дела. И, возможно, именно поэтому их подход сегодня кажется более современным, чем многие презентации с надписью “AI for Law”.
Сентенция.
Самая дорогая ошибка в Legal AI – автоматизировать не тот уровень системы.
Если моделировать юриста, получится обаятельный интерфейс. Если моделировать суд как систему, появляется шанс построить рабочий инструмент. И вот это уже не маркетинг, а архитектура.
Никита Поляков
🌐 lexometrica.com | neshemyaka.ru
Автор: larayoda
