Когда один ИИ тупит, а пять спорят — рождается вердикт
Представьте ситуацию: у вас есть иск о незаконном увольнении. Вы загружаете документы в ChatGPT-4o (самая свежая версия на январь 2026) и спрашиваете: «Каковы шансы выиграть?». Модель выдаст красивый, логичный, абсолютно бесполезный ответ. Она не знает судебной практики вашего региона. Не понимает, как судьи трактуют конкретные формулировки. Не учитывает человеческий фактор.
Именно эту проблему и решает SimCourt — исследовательская платформа из Университета Цинхуа. Китайские инженеры не стали улучшать одну монолитную модель. Они создали виртуальный суд, где пять специализированных AI-агентов ведут процесс, спорят друг с другом и в итоге выносят обоснованное предсказание. Точность возрастает на 15-20% по сравнению с одиночными LLM. И самое главное — система объясняет каждое решение.
Важно: SimCourt — это не коммерческий продукт, а исследовательский фреймворк с открытым кодом (опубликован в 2025 году). Вы не найдете его в виде SaaS. Зато можете собрать аналогичную систему сами, используя их архитектуру.
Почему обычные LLM проваливаются в юриспруденции? (И что с этим делать)
Проблема не в интеллекте моделей, а в структуре задачи. Юридический анализ — это многоэтапный процесс:
- Извлечение фактов из запутанных, многостраничных документов.
- Квалификация этих фактов под конкретные статьи закона.
- Поиск прецедентов (похожих дел) в базе решений.
- Прогнозирование исхода с учетом субъективных факторов (настроение судьи, региональная специфика).
- Формулировка обоснованного вердикта.
Одна модель пытается сделать всё сразу. Получается каша. Вспомните статью «Почему общие LLM проваливаются в юриспруденции» — там подробно разбирали, как специализированные модели вроде LabourLawLLM бьют GPT-4 на юридических бенчмарках.
SimCourt пошел дальше. Вместо одной супермодели — команда узких экспертов. Каждый отвечает за свой этап. Они общаются через структурированные сообщения. Контролируют друг друга. Итоговое решение — результат коллективного обсуждения, а не вывод одинокого алгоритма.
Архитектура SimCourt: кто есть кто в виртуальном суде
Основная фишка системы — пять автономных агентов, каждый с четкой ролью и промптом. Они не просто вызывают API LLM. У них есть память, доступ к инструментам и протокол взаимодействия.
| Агент | Роль | Что делает | Пример инструмента |
|---|---|---|---|
| Fact Extractor | Следователь | Вытаскивает ключевые факты из искового заявления, договоров, доказательств. Игнорирует «воду». | NER-модель для юридических实体 (юридических лиц, сумм, дат) |
| Legal Analyst | Юрисконсульт | Квалифицирует факты под статьи ГК, ТК, УК. Определяет состав правонарушения. | Векторная база с законодательством (например, Qdrant) |
| Precedent Researcher | Судебный архивариус | Ищет похожие дела в базе судебных решений. Оценивает, чем текущий случай отличается. | Semantic Search по базе прецедентов |
| Judge Simulator | Судья (виртуальный) | Взвешивает аргументы, оценивает доказательства, предсказывает решение реального суда. | Fine-tuned LLM на исторических решениях конкретного суда |
| Verdict Writer | Секретарь суда | Формулирует итоговый документ — мотивированное предсказание с ссылками на законы и прецеденты. | Шаблонизатор + LLM для генерации связного текста |
Все агенты работают асинхронно. Fact Extractor первым обрабатывает документы и передает структурированные факты Legal Analyst. Тот, в свою очередь, формирует правовую позицию и передает ее Precedent Researcher. Информация течет по конвейеру, но есть и обратная связь. Например, Judge Simulator может запросить у Fact Extractor уточнение по конкретному доказательству.
Пошаговый план: собираем свою SimCourt с нуля
Теория — это хорошо, но давайте перейдем к практике. Вот как реализовать аналогичную систему на современном стеке (2025-2026).
1 Выбор ядра: какой фреймворк для агентов взять?
SimCourt использует кастомный фреймворк на Python. Но сегодня есть готовые решения. Я рекомендую LangGraph (от LangChain) или CrewAI. Первый — более гибкий, позволяет описывать сложные workflow графами. Второй — проще для старта, имеет встроенные ролевые модели.
# Пример инициализации агента в LangGraph (схематично)
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from agents import FactExtractorAgent, LegalAnalystAgent
# Определяем состояние (общая память системы)
class CourtState(TypedDict):
case_text: str
extracted_facts: dict
legal_qualification: list
precedents: list
prediction: dict
final_verdict: str
# Создаем граф workflow
workflow = StateGraph(CourtState)
workflow.add_node("extract_facts", FactExtractorAgent().run)
workflow.add_node("analyze_law", LegalAnalystAgent().run)
# ... добавляем остальных агентов
workflow.set_entry_point("extract_facts")
workflow.add_edge("extract_facts", "analyze_law")
# ... определяем порядок
app = workflow.compile()2 Подбор моделей: не все LLM одинаково полезны для права
Для разных агентов нужны разные модели. Fact Extractor может работать на маленькой, быстрой модели (например, Qwen2.5-Coder-7B, актуальная на начало 2026), fine-tuned на юридическом NER. Для Judge Simulator уже нужна мощная модель с глубоким пониманием контекста — здесь подойдет DeepSeek-V3 или Claude 3.5 Sonnet (через API).
Не пытайтесь засунуть всю систему в одну модель через разные промпты. Это главная ошибка. Каждый агент должен иметь свой оптимизированный инференс. Возможно, даже свою fine-tuned версию. В статье «Юридические документы против open-source LLM» есть отличные бенчмарки, какие модели лучше справляются с юридическими текстами.
3 Инструменты и базы знаний: RAG — это только начало
Каждому агенту даем свои «инструменты»:
- Fact Extractor: Модель для извлечения именованных сущностей (spaCy с дообучением на юридическом корпусе). Плюс — парсер PDF/DOCX для извлечения структурированных данных из сканов.
- Legal Analyst: Векторная база законов (разверните Chroma или Weaviate с embeddings от юридической модели). Не забывайте про актуальность — законы меняются.
- Precedent Researcher: Отдельная база судебных решений. Ключевой момент — нужно семантическое сходство + фильтрация по категориям дел (трудовые, гражданские, арбитражные).
- Judge Simulator: Здесь сложнее. Нужна модель, дообученная на исторических решениях. Если данных мало — используйте few-shot prompting с примерами похожих вердиктов.
Простой RAG, где модель просто получает куски текста из базы знаний, не подойдет. Нужна многоуровневая фильтрация. Смотрите наш гид «RAG в 2024: как научить ИИ не врать» — там как раз разбираются техники релевантного поиска.
4 Оркестрация и диалог: как агенты общаются
Агенты не должны болтать свободно. Нужен строгий протокол. SimCourt использует JSON-схемы для сообщений. Пример:
{
"from": "fact_extractor",
"to": "legal_analyst",
"type": "facts_extracted",
"payload": {
"parties": [
{"name": "Иванов И.И.", "role": "истец"},
{"name": "ООО 'Ромашка'", "role": "ответчик"}
],
"claims": [
{"description": "Невыплата заработной платы", "amount": 500000}
],
"evidence": ["трудовая книжка", "выписка из банка"]
}
}Это структурировано, машиночитаемо и исключает «галлюцинации» в коммуникации. Для оркестрации можно использовать Redis или RabbitMQ как брокер сообщений между микросервисами-агентами.
5 Валидация и контроль: система должна ошибаться реже человека
Введите «агента-критика» (можно того же Judge Simulator в другой роли), который проверяет итоговый вердикт на противоречия. Если вердикт противоречит найденным прецедентам без веских причин — отправляем на пересмотр.
Логируйте все шаги. В идеале — сохраняйте цепочку рассуждений (reasoning chain) каждого агента. Это критически важно для объяснения решения клиенту (или для аудита регулятором).
Типичные ошибки при сборке мультиагентных систем для LegalTech
Я видел десятки попыток повторить SimCourt. Большинство проваливаются на этих граблях:
| Ошибка | Почему это проблема | Как исправить |
|---|---|---|
| Один LLM на всех агентов | Разные задачи требуют разных компетенций. Fact extraction и legal reasoning — разные навыки. | Используйте специализированные модели или хотя бы разные промпты с fine-tuning под задачу. |
| Свободный диалог без протокола | Агенты начинают «флудить», уходить в философские дискуссии, тратить токены. | Жестко определите схему обмена сообщениями. Ограничьте количество «ходов» в диалоге. |
| Отсутствие валидации на выходе | Система может выдать юридически некорректный вердикт (например, применить устаревшую статью). | Добавьте агента-валидатора, который проверяет выводы на соответствие актуальному законодательству. |
| Игнорирование скорости | Если система думает 5 минут над простым запросом — юристы ее не будут использовать. | Кэшируйте результаты поиска прецедентов. Используйте маленькие модели для простых шагов. Распараллеливайте независимые задачи. |
Что дальше? Будущее агентных систем в LegalTech
SimCourt — только первый шаг. Уже сейчас видны направления развития:
- Агенты-переговорщики: Система, которая не только предсказывает судебное решение, но и моделирует досудебное урегулирование. Один агент играет роль адвоката истца, другой — адвоката ответчика. Они ведут переговоры, ищут компромиссы. Технологически это сложнее, но уже есть прототипы (например, в проектах типа Pact).
- Персонализация под судью: Fine-tune Judge Simulator на решения конкретного судьи. Звучит немного по-дистопийному, но это работает — стиль и предпочтения судей часто предсказуемы.
- Кросс-юрисдикционный анализ: Агенты, которые сравнивают практику разных регионов или даже стран. Полезно для международных споров.
Главный вывод SimCourt прост: будущее LegalTech — не за одной гигантской моделью, а за кооперацией маленьких, умных специалистов. Каждый делает свою работу идеально. Вместе они решают задачи, которые не под силу ни одному ИИ в одиночку.
Собирайте своих агентов. Делите большие проблемы на маленькие. И помните — лучшая система та, которую можно объяснить. Пять агентов с понятными ролями объяснить проще, чем одну нейросеть с 500 миллиардами параметров.
