Любой, кто пытался прикрутить 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%), система помечает этот кейс как «неопределенный».
Выводы из статьи
-
Supervised Fine-Tuning жив, а RAG – не панацея. Если вам нужен специфический формат вывода (например, JSON с разбивкой по 40 видам компенсаций), проще дообучить небольшую модель (7B-13B), чем мучить контекстное окно промптами на 10к токенов.
-
Decomposition “is a кing”. Не пытайтесь решить задачу одним запросом “Будь юристом”. Разбивайте её этапы – “Классифицируй”, “Найди нормы”, “Посчитай”, «Сведи».
-
Бенчмарки решают. Пока у вас нет своего “золотого датасета” (хотя бы 100 размеченных кейсов, или как 600 в статье), вы не разрабатываете AI, вы просто играете в казино с API OpenAI.
P.S. Кому интересна статья – ссылка на arXiv. Код neshemyaka.ru пока не открывал, но сам сервис доступен — можно покидать в него иски и посмотреть, как он “галлюцинирует”, но уже весьма уверенно.🙂
Автор: larayoda
