Алгебра правосудия: как инженеры оцифровывали суды за 50 лет до ИИ

Сейчас в Legal AI доминирует довольно наивная идея: если большая языковая модель уже умеет писать приличный юридический текст, значит осталось только дать ей корпус судебных актов, прикрутить чат и получить “цифрового юриста” То есть будто бы право – это просто очень длинный prompt.

Проблема в том, что суд – не текстовый жанр. Суд – это система.

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

Это особенно заметно в задачах судебной аналитики: где дело может зависнуть, на каком этапе ломается траектория, где процесс ветвится, где нужен не текст, а расчет. И вот тут внезапно оказывается, что самые полезные идеи лежат не в свежем AI-маркетинге, а в работах полувековой давности.

Еще в конце 1960-х исследователи моделировали прохождение felony defendants через судебную систему округа Колумбия, а в 1973 году уже описывали преимущественно алгебраический подход к симуляции legal systems для совместной работы инженеров и юристов, в том числе на материале судов Индианы. С инженерной точки зрения ^[1] это важно не как исторический курьез, а как ранняя попытка честно ответить на вопрос: что именно мы автоматизируем в праве – текст, решение или саму систему.

Ниже несколько простых, но, как кажется, важных идей по прочтении двух статей полувековой давности – Simulation Applied to a Court System (Jean G. Taylor, Joseph A. Navarro, Robert H. Cohen, 1968) ^[2] и An algebraic method for simulating legal systems (Michael K. Sain, Eugene W. Henry, John J. Uhran, 1973) ^[3].

Почему LLM-обертка быстро упирается в потолок

Когда мы говорим “автоматизировать юриста”, мы почти всегда подменяем задачу. Нам кажется, что нужно смоделировать мышление ^[4] опытного специалиста: как он читает дело, как замечает слабые места, как оценивает перспективу. Но на практике это часто приводит к тому, что модель имитирует стиль рассуждения лучше, чем саму структуру процесса.

Для договора это еще терпимо. Для суда – уже нет.

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

• Текст.

• Процессуальная траектория.

• Ограничения и сроки.

• Вероятностные переходы между стадиями.

• Объяснение результата человеку.

LLM годится в основном для пятого пункта и частично для первого. Все остальное она может только маскировать. И именно здесь старые court simulations оказываются неожиданно современными.

Урок первый: сначала модель процесса, потом “умный юрист”

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

GPSS, который использовался в ранних моделях такого рода, вообще создавался как General Purpose Simulation System для дискретных процессов, где ключевую роль играют события, очереди, ресурсы и переходы между состояниями. И это почти идеальная метафора для суда: поступление дела, распределение, ожидание, ходатайство, перенос, следующая инстанция, выход.

Отсюда очень простой, но болезненный вывод для Legal AI: прежде чем заставлять модель “думать как судья” нужно хотя бы описать, что именно происходит с делом в системе. Prompt не важнее process graph. Тонкость формулировки не важнее topology.

Именно поэтому плохой Legal AI обычно выглядит так: один огромный вызов LLM, куда свалили фабулу, документы, пару судебных актов и просьбу “оцени шансы”. А хороший – как конвейер, где языковая модель вообще не трогает то, что можно описать правилами, графом или статистикой.

Урок второй: право нелинейно, и это не баг, а базовое свойство системы

Юристы это и так знают на практике, но разработчики почему-то регулярно про это забывают ^[5]. Судебное дело почти никогда не идет по прямой. Есть возвраты. Есть переносы. Есть апелляции. Есть новые доказательства. Есть процессуальные петли, после которых дело вроде бы “то же самое”, но в другой конфигурации.

Именно поэтому работа 1973 года до сих пор цепляет: ее авторы описывали primarily algebraic technique for simulating social systems в логике ^[6] system theory и явно мыслили не текстами, а структурой переходов. Для разработчика это важный сигнал: юридический процесс удобнее мыслить как граф состояний с вероятностными переходами, чем как цепочку абзацев.

Из этого, кстати, вытекает одна неприятная правда про многие современные AI-продукты в праве. Они пытаются решить задачу уровня workflow engine с помощью chat completion API. То есть вместо моделирования системы берут модель, которая хорошо продолжает текст, и просят ее быть одновременно процессуалистом, аналитиком, маршрутизатором и калькулятором вероятностей.

Работает ли это на красивых демо? Да.

Ломается ли это на реальном грязном контуре? Тоже да.

Урок третий: юристу нужен не “ответ”, а карта того, как к пришли к этому ответу

Самая опасная ошибка ^[7] в 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 – автоматизировать не тот уровень системы.

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

Никита Поляков
🌐  ^[8]lexometrica.com ^[9] | neshemyaka.ru ^[10]