Исследователи Fudan и Ant Group заставили LLM следовать юридической процедуре по графу

Юристы используют ИИ почти все, а доверяют ему единицы. Причина не в том, что модель путает факты. Куда опаснее, когда она молча пропускает шаг процедуры и выдаёт гладкий отчёт, в котором чего-то не хватает. Разбираем подход TG-RAG, который пытается решить именно эту проблему, и то, что из него может взять любой, кто строит агентов для регулируемых областей.

Разрыв между возможным и реальным

По исследованию Anthropic от марта 2026 года, модели теоретически способны выполнять почти 90% задач юридических профессий, а фактически ИИ покрывает около 20%. Опрос ILTA показывает, что генеративный ИИ используют или тестируют 94% юрфирм против 80% годом ранее. Но большинство инструментов так и остаются пилотами. В России похожая картина: около 88% юристов уже работают с нейросетями, при этом 84% боятся недостоверной информации, а 80% вынуждены проверять каждый результат.

Автор разбора, прикладной лингвист Сергей Слепухин, видит корень проблемы в разделении знаний. Декларативные знания (что говорят нормы и практика) мы уже умеем хранить в векторных и графовых базах. Процедурные знания (как действовать) обычно лежат в промптах и файлах вроде skills.md, то есть тем же текстом, что и сами данные. У LLM нет границы между данными и инструкциями, поэтому в длинном диалоге она постепенно отходит от исходной инструкции. Это и есть instruction drift, а авторы TG-RAG называют его когнитивным дрейфом.

Как устроен TG-RAG

Идея простая. Рассуждение reasoning-модели — обычный текст между тегами <think> и </think>. Если у вас открытая модель на собственном сервере, например Qwen или DeepSeek R1-Distill на vLLM, вы управляете шаблоном чата и можете дописать этот текст за модель. Она продолжит его как собственную мысль и не отличит от сгенерированного.

На этом построена схема. Экспертную процедуру (SOP) формализуют в граф: вершины — аналитические шаги, рёбра — порядок и условия перехода. Программа исполняет граф сама. На границе шага она прерывает генерацию, вписывает в рассуждение директиву следующего шага и подкладывает знания, нужные именно сейчас. Процедура задаёт фарватер, а поиск по базе работает точечно, а не сваливает всё в один контекст.

Пример — due diligence при покупке доли в ООО. После запроса документов работа расходится на треки: корпоративный, активы, договоры, налоги, споры, долги и банкротство, регуляторика и санкции. Все они сходятся в матрицу рисков. Здесь нужен и multi-hop (собрать факты из разных источников), и multi-step (пройти каждую ветку по порядку). Ошибкой может оказаться не неверный факт, а пропущенный шаг, который трудно заметить при проверке.

Ограничения и что с этим делать

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

Второе ограничение методологическое. Граф процедуры кто-то должен составить, а это работа эксперта. Он должен описать SOP и условия переходов, и граф нужно поддерживать при изменении норм. Подходит он для задач со стандартной или описуемой процедурой, но не для открытого творческого анализа. Кроме того, в русскоязычном праве нет признанных бенчмарков, так что честно измерить выигрыш сложно. Автор прямо отмечает это и обещает эксперимент на собственных данных и разбор ограничений во второй части. Результатов авторов статьи в этой части ещё нет.

Практический вывод для разработчиков и продактов: если ваш агент работает в области с жёсткой процедурой (юриспруденция, комплаенс, медицина, финансы), перестаньте держать процедуру в промпте. Выносите её в явную структуру, например в граф, и исполняйте программно. Знания подавайте по шагам. Тогда результат проверять проще: вы смотрите не на всю цепочку рассуждений, а на то, пройдены ли обязательные узлы графа.