Почему «голая» GPT не тянет юриспруденцию: разбираем архитектуру китайской LabourLawLLM

Любой, кто пытался прикрутить LLM к реальному продакшену в узком домене (медицина, право, инженерия), проходил стадию отрицания: "Да ладно, сейчас промпт подкручу, RAG прикручу — и полетит".

Не полетит. 🙂

На этой неделе (январь 2026 г.) вышел любопытный китайский препринт "Chinese Labor Law Large Language Model Benchmark". Авторы сделали то, до чего у большинства стартапов не доходят руки: вместо написания очередной обертки над OpenAI API, они построили жесткий бенчмарк и доказали, что General-purpose модели сливают специализированным SFT-моделям, как только дело доходит до специфической логики и расчетов. Ниже - разбор статьи с проекцией на мой опыт разработки neshemyaka.ru (Legal AI для оценки исков). Спойлер: китайцы математически подтвердили то, что пришлось выяснять через боль и сжигание токенов.

Суть проблемы: Generalist vs Specialist

Основная гипотеза авторов: большие модели страдают от "размытия" контекста. Когда модель знает всё обо всём, она начинает галлюцинировать в задачах, требующих строгой импликации (если А, то Б, но только при условии В). Для проверки они собрали LabourLawBench - датасет из 12 типов задач по трудовому праву. И это не просто "вопрос-ответ".

Архитектура бенчмарка (можно сказать, feature map для разработчика)

Если вы пилите LegalTech, забирайте этот список как готовое ТЗ. Авторы выделили 12 задач:

• Statute Recitation (T1): Точное воспроизведение нормы (Retrieval memory).

• Knowledge QA (T2-T3): Классические тесты.

• Case-Type Prediction (T4): Классификация (Multi-class classification).

• Welfare Compensation Prediction (T5): Самое интересное. Предиктивный расчет компенсаций. Это то место, где LLM традиционно «плывут», пытаясь угадать цифру, а не посчитать её.

• NER & Mining (T6-T8): Извлечение сущностей, требований и сути спора.

• Statute Prediction (T9-T10): Предсказание применимой статьи (Reasoning).

• Case Analysis (T11-T12): Генерация текста решения.

Результаты тестов:

Специализированная модель LabourLawLLM (дообученная на корпусе трудового права) показала лучшие метрики (Rouge-L, F1, Accuracy) по сравнению с базовыми LLaMA, ChatGLM и даже GPT-4 в специфических задачах.​ Особенно показателен провал дженералистов в T5 (Calculations) и T1 (Citation). GPT-4 может написать красивое эссе, но когда нужно маппить 40 видов китайских социальных выплат на фабулу дела — она ошибается.

Методология оценки: LLM-as-a-Judge

Авторы используют гибридную оценку: для классификации/извлечения - Hard Metrics (Accuracy, F1). Для генерации (Case Analysis) - LLM-as-a-Judge (используют GPT-4 для скоринга ответов других моделей). И такой подход постепенно становится стандартом. В своем проекте я пришел к аналогичной схеме: валидировать юридический "ризонинг" регулярками невозможно. Приходится строить каскад, где "старшая" модель оценивает адекватность "младшей".

Как это бьется с моей практикой

Когда я пилил neshemyaka.ru (сервис первичного скоринга судебных исков), я наступил на те же грабли, что описаны в статье. Ожидание было понятным - User Input -> RAG (простенький, но специализированный в разных доменах) -> LLM -> Score.

В реальности же GPT (да и не только она) выдает очень гладкий, уверенный, но юридически бессмысленный текст. Например, она прекрасно «понимает» эмоцию истца, но пропускает пропущенный срок исковой давности, потому что для неё это просто дата в тексте, а не блокирующий фактор.

После этого пришлось уйти от ушли от монолитного промпта к пайплайну (chain of thought + decomposition), похожему на структуру задач, предложенный в статье:

• Pre-processing (NER): Отдельная задача на выделение дат, сумм и требований (аналог T6/T7 из статьи).

• Reasoning Layer: Модель не "пишет ответ", а сначала классифицирует тип спора (аналог T4).

• Validation: Вместо одной модели работает ансамбль (consensus check). Если GPT, Claude или другая модель расходятся в оценке шансов (например, разброс > 20%), система помечает этот кейс как "неопределенный".

Выводы из статьи

1. Supervised Fine-Tuning жив, а RAG - не панацея. Если вам нужен специфический формат вывода (например, JSON с разбивкой по 40 видам компенсаций), проще дообучить небольшую модель (7B-13B), чем мучить контекстное окно промптами на 10к токенов.

2. Decomposition "is a кing". Не пытайтесь решить задачу одним запросом "Будь юристом". Разбивайте её этапы - "Классифицируй", "Найди нормы", "Посчитай", «Сведи».

3. Бенчмарки решают. Пока у вас нет своего "золотого датасета" (хотя бы 100 размеченных кейсов, или как 600 в статье), вы не разрабатываете AI, вы просто играете в казино с API OpenAI.
   ​

P.S. Кому интересна статья - ссылка на arXiv. Код neshemyaka.ru пока не открывал, но сам сервис доступен — можно покидать в него иски и посмотреть, как он "галлюцинирует", но уже весьма уверенно.🙂