Юридическая практика как данные

В делах о взыскании платы за жильё одни и те же сюжеты повторяются десятки раз: «я не член ТСЖ», «договора со мной нет», «откуда этот старый долг?», «управляющая компания ничего не делает». Юрист узнаёт знакомую ситуацию, вспоминает похожее дело, ищет нужный абзац в решении, перепроверяет основания — и пишет ответ. Через месяц то же самое заново делает его коллега.

Такой опыт живёт в головах, переписке и папках дел. Он не складывается в систему, его трудно передать новому сотруднику, его не находит поиск — и на нём не учится ни одна модель.

«Если команда всё равно годами собирает, проверяет и уточняет эти материалы, почему бы сразу не готовить их так, чтобы на них можно было учить модели — сегодня одну, завтра другую?»Вопрос, с которого началось исследование

Толчком к эксперименту стала идея Decision Models: вместо расплывчатого «проанализируй дело» модель получает узкий проверяемый вопрос — например, определить вид довода из заранее заданного списка. Такой ответ легко сверить с эталоном, а значит, модели и их версии можно честно сравнивать между собой.

Запись «должник ссылается на плохую работу УК» сама по себе почти бесполезна. Полезная карточка объясняет, что именно заявлено, какие обстоятельства меняют оценку, какие документы есть, каких не хватает и что проверить. И главное — помнит, откуда всё это взялось.

Одна ситуация может иметь десятки примеров, одно дело — несколько ситуаций, а один пример — участвовать в разных заданиях. Но происхождение не теряется: от любого ответа модели можно вернуться к абзацу, на котором он основан. А ещё у каждой записи есть время — период обстоятельств, дата акта, редакция источника, дата проверки.

Если смешать эти вещи при наполнении, модель будет учиться на неоднозначных ответах — даже при технически безупречном обучении. Поэтому самое важное в проекте — не код, а предметная дисциплина разметки. Её и делают юристы.

Мы собрали работающий веб-прототип на Python и SQLite. Он не требует внешних библиотек и отдельной сборки интерфейса: запускается на ноутбуке юриста, а на сервере команды открывается в браузере у всех.

Практика взыскания · локальный прототип · компьютер

Каталог: подборка «Возражения команды» и карточка на проверке; справа — та же база на телефоне, оба экрана прокручиваются. Название реального дела в боковой панели скрыто.

Это срез на 26 октября 2026 года. Часть карточек — учебные, с вымышленными примерами: на них отлаживаются интерфейс и структура, в рабочие наборы они не попадают. Содержательные карточки сейчас проходят юридическую проверку — до неё ни одна запись не допускается к обучению.

Первой настоящей проверкой идеи стал разбор двух обезличенных судебных актов по одному спору: решения первой инстанции и апелляционного определения. ТСЖ взыскивало плату за ЖКУ и взносы на капремонт; иск удовлетворили частично, апелляция решение оставила. Часть возражений не сработала, но некоторые статьи расходов суд исключил. Значит, одно дело пополнило сразу две базы — возражений должников и ошибок взыскателя.

Разбор вскрыл и слабые места исходников: часть сумм обезличена, первичных документов из решения в комплекте нет, а период в тексте не сходится с множителем месяцев. Такие места мы сохраняем как неясность и вопрос на проверку — а не «чиним» догадкой.

«Два акта разных инстанций — это одно дело, а десять извлечённых из него вопросов — не десять независимых дел.»Главный методический вывод разбора

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

Параллельно команда записала пять формулировок, которые в делах о ЖКУ встречаются постоянно. Из них выросли карточки с условиями, документами и направлениями проверки — и первая классификационная задача для модели: шесть категорий, включая «Другое».

Важная оговорка: метка описывает содержание довода, а не его силу. Модель отвечает на вопрос «что заявлено?», а не «прав ли должник?» — и тем более не «чем кончится дело».

Ловушка «обучение завершено»

Первая попытка — приложение Unsloth на Mac и небольшая модель Qwen3.5-2B. Интерфейс бодро отчитался: одна эпоха, четыре шага, 76 секунд, готово. Мы открыли сохранённую конфигурацию — и увидели is_decision: false. Вместо обучения решений шло обычное текстовое дообучение, а сам довод должника в модель вообще не попал: все 60 строк превратились в один и тот же вход с шестью разными ответами.

Модель ничему не научилась, а галочка «готово» стояла. С тех пор у нас правило: статус «обучено» ничего не значит, пока своими глазами не видно, что именно модель получила на вход.

Пробы готовой модели

Дальше — Laya, многоязычная Decision-модель с открытыми весами. Её создали не мы — мы её проверяем и дообучаем. Готовой модели дали три текста и шесть категорий — и быстро нашли слабое место.

Модель реагирует на упомянутую тему и пропускает оговорку, что именно этой проблемы нет. Для юридического текста это критично: «документ представлен» и «документ не представлен» почти не различаются словами, но означают противоположное.

Своя версия Laya

Затем — полное дообучение энкодера и головы решений через официальный пакет Laya 0.4.1 на PyTorch и Apple Silicon. Ноутбук с M5 Max, две эпохи, 58 обновлений параметров — и через две с половиной минуты у нас своя версия модели. Исходные веса проверены контрольными суммами и не тронуты, а в новой версии изменились 164 из 170 тензоров.

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

Здесь все 15 диагностических текстов и настоящие ответы обеих моделей. Выберите довод, решите сами, к какой категории он относится, — и посмотрите, что ответили исходная Laya и наша версия. Счёт ведётся.

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

1. ✓
   Прототип базы

   Каталог, источники, примеры, версии, выпуски наборов, экспорт в JSONL

   Сделано
2. ✓
   Первое дело разобрано

   Десять карточек из двух актов одного спора, ограничения исходников описаны

   Сделано
3. ✓
   Первая своя версия модели

   Дообучение Laya на синтетике и локальный стенд сравнения

   Сделано
4. 4
   Юридическая проверка

   Проверить 15 содержательных карточек: источники, условия, границы выводов

   Критерий: У каждой принятой записи есть основание, проверяющий и версия
   Сейчас
5. 5
   Правила разметки

   Что считать возражением; как быть с фоном, отрицанием и несколькими доводами

   Критерий: Юристы одинаково размечают спорные примеры и могут объяснить почему
   Впереди
6. 6
   Реальные материалы

   Обезличенные примеры из разных дел и первичные документы

   Критерий: Есть разнообразие дел и категорий, происхождение каждого примера известно
   Впереди
7. 7
   Редакторская модель 2.0

   Тема отдельно от задания, несколько доводов в одном тексте, отдельные итоги по вопросам дела

   Критерий: Запись переиспользуется без потери смысла и контекста
   Впереди
8. 8
   Выпуски и выборки

   Группировка по делам, поиск дубликатов, рецепты смешивания тем

   Критерий: Видно, какие строки и почему попали в каждую часть эксперимента
   Впереди
9. 9
   Новое сравнение моделей

   Исходная Laya, первая и следующая версии — на отложенных реальных материалах

   Критерий: Критерии приёмки согласованы до выбора победителя
   Впереди
10. 10
    ИИ-поиск по базе

    Фрагменты, ссылки и выдача для ассистента

    Критерий: Ответ опирается на найденные материалы с проверяемым происхождением
    Впереди
11. 11
    Наборы на Hugging Face

    Паспорта наборов, доступ, условия использования, резервные копии

    Критерий: Понятно, что остаётся внутри команды, а что публикуется
    Впереди
12. 12
    В рабочий процесс

    Одна узкая задача в ежедневной работе команды и сбор исправлений

    Критерий: На реальных задачах измерены польза, качество и объём ручной проверки
    Впереди

Представьте версию, к которой мы идём. Не «ИИ, который решает дела», а рабочее место, где опыт всей команды и узкие проверенные модели подставляют плечо в каждой мелочи.

Значимые выводы и действия по-прежнему подтверждает юрист. Но рутину — найти, сопоставить, проверить арифметику, вспомнить похожее дело — берёт на себя система, которая каждый день учится на исправлениях команды.

Дальше — идеи, ради которых всё это затевается. Каждая большая, и мы честно называем их фантазиями — но лабораторию двигают именно такие фантазии.

Мы открыли организацию LawLabs на Hugging Face — там будут жить выпуски наборов, их описания и наши версии моделей. Схема простая: юристы работают в одной базе, а из неё собираются тематические наборы — каждый с паспортом, версией и рецептом сборки.

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

Исследование — это прежде всего список вопросов без готовых ответов. Наш список:

1. Насколько одинаково разные юристы размечают типовые возражения и где расходятся их трактовки?
2. Какие задачи достаточно определённы для Decision-моделей, а какие требуют другой формы ответа?
3. Насколько модели устойчивы к отрицаниям, оговоркам и постороннему фону?
4. Как разделять несколько доводов в одном тексте и оценивать полноту их распознавания?
5. Сколько независимых дел нужно для полезной проверки каждой категории?
6. Что эффективнее для конкретной задачи: готовая модель, инструкция, поиск по базе, дообучение или их сочетание?
7. Как оценивать уверенность модели и когда звать человека на дополнительную проверку?
8. Какие примеры помогают одной категории, но портят другую, — и как ловить это до внедрения?
9. Как меняется качество при объединении тем и нужно ли учить каждое направление отдельно?
10. Как отделить сведения, доступные до судебного акта, от знания исхода задним числом?
11. Как организовать актуализацию правовых источников и связанные с ней редакторские задачи?
12. Как измерять реальную пользу: время поиска, пропущенные вопросы, число исправлений, полноту ссылок?