Автор статьи: Сергей Слепухин (@Sergey_Slepukhin_1988)

В первой части мы кратко рассмотрели предпосылки и последствия ИИ‑трансформации деятельности юристов, а также предложили вариант архитектуры продвинутой RAG‑системы, учитывающей особенности юридической предметной области.

Во этой части мы дадим обзор общих и юридических бенчмарков, которые целесообразно учитывать при оценке технических компонент RAG, а также системы, в целом. В заключение рассмотрим, как самостоятельно подготовить тестовый датасет для оценки RAG‑системы с помощью фреймворка RAGAS и разберем итоговые результаты эксперимента.

Общие и юридические бенчмарки

Данная тема — бенчмаркинг LLMs и других компонентов RAG‑систем в юридическом домене на русском языке, насколько нам известно, более или менее глубоко или системно еще не обсуждалась на habr, поэтому уделим ей должное внимание.

Оценивать, в общем, можно следующие технические компоненты RAG:

1. бенчмарки моделей эмбеддингов;

2. бенчмарки для векторных хранилищ;

3. бенчмарки для LLM.

1. Бенчмарки моделей эмбеддингов: для оценки производительности и качества моделей эмбеддингов на различных задачах поиска по разным наборам данных.

Именно модель эмбеддингов вносит наиболее важный вклад в качество работы модуля Retrieval. Выбор векторного хранилища, к которому будет обращаться эмбеддер, также важен, однако он влияет, главным образом, на производительность поиска.

Основным инструментом для оценки качества поиска является MTEB (Massive Text Embedding Benchmark, MTEB). Бенчмарк MTEB — комплексный стандарт для тестирования моделей sentence‑эмбеддингов, позволяющий оценивать их производительность на более чем 50-и различных датасетах (среди которых есть и юридические, правда, на английском языке, об см. ниже по тексту).

Для оценки RAG‑системы важны задачи, связанные с информационным поиском. В категориях MTEB:

• Retrieval: найти релевантные документы по запросу;

• Reranking: улучшить порядок результатов поиска;

• STS (Semantic Textual Similarity): оценить степень семантического сходства пар;

• Summarization.

Для каждой из категорий вычисляется средний ранг модели по всем датасетам в этой категории. Рейтинги моделей публикуются на Hugging Face и доступны по ссылке.

В 2024 году появилась возможность оценки и русскоязычных эмбеддеров с помощью ruMTEB на 23 задачах, среди которых также есть и задача Retrieval.

Также MTEB содержит специализированный бенчмарк для юридического домена — MTEB (Law, v1), который позволяет оценивать модели на 8 задач, в частности:

• LegalBenchConsumerContractsQA (Retrieval): датасет, который содержит 400 пар вопросов‑ответов (да / нет) в сфере потребительских договоров (consumer contracts);

• AILACasedocs (Retrieval): датасет состоит из текстов решений Верховного суда Индии, позволяет оценивать поиск релевантных текстов судебных решений по запросу;

• LegalSummarization (Retrieval): датасет состоит из 439 пар контрактов и их суммаризаций.

Датасеты в MTEB (Law, v1) на русском языке отсутствуют (только на английском, немецком и китайском языках).

В текущих условиях, полагаем, логично было бы взять в качестве эмбеддера‑компонента RAG‑системы какую‑нибудь мультиязычную модель, поддерживающую русский и английский языки, а также входящую в топ-10 на общем MTEB и одновременно имеющую наиболее высокий рейтинг на MTEB (Law, v1). Современные трансформерные мультиязычные модели обучались на множестве параллельных корпусов (задача text2text), соответственно можно предположить, что такой эмбеддер сможет уловить некие общие, кросс‑языковые юридические паттерны. К таким моделям, например, относятся BGE‑M3 (также входит в топ-10 рейтинга на ruMTEB для задачи Retrieval) или e5-large.

2. Бенчмарки для векторных хранилищ: для оценки производительности и качества задач векторного поиска, шире — информационного поиска.

При этом биенкодер cointegrated/LaBSE-en-ru, который мы выбрали в качестве эмбеддера, конечно, не может соперничать с современными моделями: LaBSE вообще не представлена в лидерборде MTEB (Law, v1). Однако для того, чтобы оценить работу RAG‑системы в целом, cointegrated/LaBSE-en-ru, на наш взгляд — оптимальный baseline: BGE‑M3 и e5-large имеют большую размерность (1024), требуют больше ресурсов для развертки, более медленный инференс по сравнению с LaBSE, и так далее.

Основной инструмент для бенчмаркинга — ANN‑Benchmarks (link). Инструмент позволяет оценивать производительность работы алгоритмов из семейства ANN для аппроксимированного поиска ближайших соседей (Approximate Nearest Neighbor, ANN). Векторное хранилище FAISS, которое является одним из ключевых компонентов в нашей RAG‑системе, в значительной степени опирается именно на алгоритмы ANN.

Метрики ANN‑Benchmarks позволяют, главным образом, измерить полноту (Recall) и скорость (per sec) поиска на больших наборах данных. Для RAG‑системы, работающей в юридическом домене, на наш взгляд, более важна полнота (по сравнению с точностью): критически важный контекст не должен быть упущен. Ложные срабатывания, безусловно, также необходимо минимизировать, так как, если система будет недостаточно точной, LLM просто запутается в нерелевантном и противоречивом контексте.

Также, наряду с бенчмарками, на практике важно учитывать показатели производительности (Performance Metrics measure efficiency):

• задержка при выполнении запроса (time per search) и пропускная способность (queries handled per second) для приложений, работающих в режиме реального времени, критически важны;

• время индексирования (indexing time) — время, необходимое для создания структуры данных, — также имеет большее значение для юридического домена, так как с ростом количества пользователей и охвата поддоменов неизбежно придется обрабатывать большие и часто обновляемые наборы текстовых данных;

• объём занимаемой оперативной памяти (memory footprint);

• масштабируемость (scalability): это показатель необходимо протестировать в зависимости от размера набора передаваемых данных (например, обработка 1000 векторов, 1 млн или 100 млн векторов — разные задачи) и размерности векторов (например, 768 или 1536 измерений), поскольку производительность часто снижается при увеличении этого показателя.

Исходя из параметров производительности, FAISS, на наш взгляд, является оптимальным решением, по крайней мере, в начале пути:

1. не являясь решением «из коробки», оно требует дополнительной настройки перед развертыванием, тем не менее оно бесплатное;

2. требуют бОльшого объёма ОЗУ, чем основные конкуренты на ANN (например, Annoy), однако обеспечивает более высокую скорость обработки данных (особенно, если подключить графический процессор), более того, является одним из лидеров по скоростным характеристикам, вне зависимости от алгоритмов «под капотом».

3. Бенчмарки для LLM.

Здесь, как и в случае с моделями эмбеддингов, можно условно выделить:

1. бенчмарки общего назначения;

2. бенчмарки специального назначения для оценки юридических способностей модели.

3.1. Бенчмарки общего назначения позволяют оценивать LLMs на 2-х общих категориях задач:

• Language Understanding — способность «понимать» естественный язык и использовать это «понимание» в работе;

• Reasoning — способность «рассуждать» и делать выводы на основе вводных данных и цепочек рассуждений.

Language Understanding

1. GLUE и SuperGLUE (от англ. General Language Understanding Evaluation): включает девять разнородных задач (грамматическая правильность предложений, классификация текста, парафраз, логический вывод и др.) для оценки общего понимания языка моделями (GLUE стал одним из «пионеров» в бенчмаркинге LLM в 2018 году, но на сегодняшний день несколько устарел и уже редко используется в реальных задачах, так как не представляет особой сложности для топовых больших языковых моделей), для русского языка был специально разработан и широко использовался в свое время бенчмарк Russian SuperGLUE.

2. MMLU (от англ. Massive Multitask Language Understanding) — основный бенчмарк для оценки способности «понимания» LLM на сегодняшний день, позволяет протестировать профессиональные знания модели, приобретенные в процессе предобучения в различных областях:

• содержит большое количество сложных вопросов из экспертных областей знания, в оригинальной статье сказано, что тест включает 57 заданий, в том числе по элементарной математике, истории США, информатике, юриспруденции и другим предметам; справедливо отмечается, что для понимания права необходимо знать, как применять правила и стандарты в сложных ситуациях, а также давать ответы с оговорками и пояснениями;

• однако юридические знания оценивались крайне фрагментарно, только на английском языке, на законах и прецедентах, действующих в правовой системе США, в виде ответов на вопросы в тестовой форме, например:

  

• вопросы предполагают несколько вариантов ответов (обычно четыре), что позволяет минимизировать влияние случайно правильных ответов;

• содержит тесты, которые позволяют оценить общие навыки рассуждения и анализа.

  3. MERA (от англ. Multimodal* Evaluation for Russian‑language Architectures) — основный бенчмарк для оценки способности «понимания» LLMs русского языка на сегодняшний день. Содержит 23 задачи с открытыми и закрытыми датасетами, представленными в виде инструктивного набора данных. Для оценки способностей модели »понимать» некоторые элементы юридического контекста можно использовать задачу RCB:

• Russian Commitment Bank (RCB) — это набор из естественных контекстов, в которых содержится или отсутствует причинно‑следственная связь, а также размечены дополнительные дискурсивные характеристики — вопрос, модальность, отрицание предшествующих условий;

• тип задачи — NLI, textual entailment: оценивает способность делать логические выводы, классифицируя отношения между двумя предложениями как согласованность, противоречие или отсутствие логической связи;

• разработчики отмечают: «Датасет в бенчмарке Russian SuperGLUE один из немногих, для которых всё ещё сохраняется значительный разрыв между оценками моделей и человеческой», хотя на момент написания статьи задачу RCB лучше решают уже 3-и модели (общий разрыв внутри домена, в любом случае, остается пока значительным):

  

  используемая нами модель gpt-4o‑mini пока на 21 месте, что для относительно не новой и маленькой LLM также неплохо;

• создание датасета: все примеры были собраны из открытых новостных источников и литературных журналов, на основе корпуса Taiga (преимущественно не специальные юридические источники), а затем вручную перепроверены и дополнены человеческой оценкой на Yandex.Toloka (то есть оценивался, скорее всего НЕ юристами).

Language Reasoning

1. BIG‑bench (Beyond the Imitation Game) на сегодняшний день — основной бенчмарк для оценки Reasoning:

• философия и цель отражены в расшифровке аббревиатуры его названия — «За пределами игры в имитацию»;

• содержит более 200 задач, среди которых, например, formal_fallacies_syllogisms_negation (выявление логических ошибок в силлогизмах), logical_deduction (задачи на логический вывод), strategyqa (ответы на вопросы, требующие стратегического мышления) и др.;

• существует в 3-х версиях, которые отличаются по сложности вопросов, на которые нужно ответить моделям: BIG‑bench Lite (BBL), BIG‑bench Hard (BBH), BIG‑bench Extra Hard (BBEH); лидерборды для 2-х первых отсутствуют, для BBEH на момент написания статьи первая пятерка выглядит так:

  

• к сожалению, на момент написания статьи специальных юридических задач бенчмарк не содержит.

  2. rulm‑sbs2: бенчмарк, который сравнивает русские аналоги ChatGPT — Saiga, YandexGPT, Gigachat:

• содержит 15 категорий задач, позволяет оценивать также способность reasoning;

• в основе оценки подход LLM‑as‑a-judge с помощью GPT-4, что явно не подходит для нашего узкого профессионального домена: байесы модели‑оценщика, очевидно, будут иметь смещение, которое может повлиять на оценку модели неочевидным для разработчиков образом.

Тема LLM‑бенчмарков — отдельная, очень интересная и объемная тема. Для тех, кто не знаком или находится в начале пути освоения LLM, рекомендуем статью Германа Петрова И Дениса Рябоконь (Deepschool) — «Большой обзор LLM‑бенчмарков»: очень емко и доходчиво.

Также отметим, что нецелесообразно использовать для оценки общих способностей LLM платформы автоматических оценок а‑ля LMSYS ChatbotArena: данная платформа позволяет пользователям оценить вслепую, какая модель лучше (если пользователь выбрал правильно, получает очки, если нет — теряет).

Очевидно, что для юридического домена оценки получатся крайне смещенными как по условно айтишным типам запросов (сложно представить, чтобы пользователи‑юристы в массовом порядке оценивали работу моделей, большинство вопросов касаются кодинга), так и по формату вопросов (неструктурированные прямые вопросы) или ответов, далеких от условных стандартов юридической практики.

В заключение отметим, что на первом этапе, для оценки нужных вам общих способностей LLM можно и нужно использовать информацию с ресурсов, содержащих бенчмарки‑агрегаторы:

• Open LLM Leaderboard (от Hugging Face): помимо MMLU содержит бенчмарки для оценки рассуждений на основе здравого смысла (HellaSwag), для оценки сложных научных рассуждений такие (ARC) и др.;

• Artificial Analysis LLM Performance Leaderboard — обширный ресурс (платформа) для оценки открытых и проприетарных LLM. Ценностью ресурса является возможность сравнения качества моделей на самом верхнем уровне качества и производительности:

  

На уровне отдельных бенчмарков (например, MMLUPro):

3.2. Бенчмарки специального назначения для оценки юридических способностей модели: разработаны специально для оценки юридических »навыков» LLMs.

Нам известны какие‑либо русскоязычные бенчмарки в рассматриваемом поддомене, на котором тестируется RAG‑система — правовой режим недвижимого имущества.

Также нам неизвестны комплексные (multi‑task) русскоязычные юридические бенчмарки, которые содержат подзадачи разного типа (классификация, QA, интерпретация, поиск, генерация и др.) и направлены на универсальную оценку моделей на поддоменах, соответствующих отраслям права, отдельным законам, судебной практике различных инстанций и проч.

Имеющиеся [среди тех, которые удалось найти] можно отнести к экспериментальным наборам данных в юридической сфере:

• RuTaR:

  • поддомен — российское налоговое право;

  • датасет:

    • в его основе — 199 обработанных писем Минфина и ФНС России,

    • содержит сгенерированные GPT-4o вопросы на основе указанных писем Минфина, ответы экспертов, суммаризацию ответов в бинарном виде — Да/Нет, юридические источники, необходимые для обоснования ответа;

  • оцененные LLMs: на момент написания статьи — GPT-4o, LLaMA 3.3 и Mixtral + разные RAG‑режимы;

  • ссылка на репозиторий GitHub на момент написания статьи не открывается;

  • Ru‑Legal‑QA‑v1:

  • поддомен — набор вопрос‑ответов по разным законодательным актам;

  • датасет: 228 пар «вопрос‑ответ», помимо собственно вопросов датасет включает в себя:

    • полный экспертный ответ,

    • список НПА, упомянутых в ответе,

    • точные цитаты НПА, использованные при ответе,

    • тип ответа: дихотомический, фактологический, пропуск и т. п.,

    • краткую версию ответа,

    • полные тексты соответствующих НПА.

  • оцененные LLMs: информация об оценке моделей не приводится;

  • ссылка на репозиторий GitHub на момент написания статьи не открывается;

В общем, исходим из того, что отсутствуют какие‑либо общепризнанные (как MERA) комплексные или нишевые юридические бенчмарки на русском языке. В таких условиях целесообразно обратиться к лидерам — наиболее известным, проработанным и распространенным англоязычным юридическим комплексным бенчмаркам, и поразмышлять — корректно ли использовать их оценки для работы в условиях российской правовой системы.

Language Understanding: LexGLUE.

Бенчмарк позиционируется как комплексная система независимого оценивания LLMs в различных задачах категории Natural language understanding (NLU). Проект, вдохновленный бенчмарком SuperGLUE, основан на 7-и англоязычных датасетах и соответствующих им 7-и задачах:

1. ECtHR Tasks A & B (Multi‑label classification): основан на решениях Европейского суда по правам человека (ЕСПЧ), каждое дело сопоставлено со статьями Европейской конвенции о правах человека, которые были нарушены (если таковые имеются):

1. в задаче А входными данными для модели является список фактов в деле, а выходными данными — набор нарушенных статей конвенции (10+ статей — labels);

2. в задаче В выходными данными является набор предположительно нарушенных статей (10+ статей — labels).

2. SCOTUS (Multi‑label classification): основан на информации из решений (court opinions) Верховного суда США с 1946 по 2020 годы:

• входными данными являются фрагменты решений и различные метаданные, выходными данными — набор категорий различных поддоменов (например, уголовное судопроизводство, гражданские права, экономическая деятельность и т. д.), соответствующих 14 labels.

3. EUR‑LEX (Multi‑label classification): основан на англоязычных текстах законов Европейского Союза (ЕС), опубликованных на портале EUR‑Lex:

• входными данными являются фрагменты различных законов, выходными данными — набор наиболее часто встречающихся концептов, относящихся к различным видам деятельности ЕС и его государств‑членов (например, экономика, здравоохранение, торговля и т. д.), соответствующих 100 labels.

4. LEDGAR (Multi‑label classification): основан на размеченных текстах положений договоров, полученных из документов Комиссии по ценным бумагам и биржам США (SEC), опубликованных на портале EDGAR:

• входными данными являются положения договоров, выходными данными — набор наиболее часто встречающихся категорий, соответствующих 100 labels.

5. UNFAIR‑ToS (Multi‑label classification): основан на наборе данных UNFAIR‑ToS, который содержит 50 условий обслуживания (ToS) с онлайн‑платформ (например, YouTube, eBay, Facebook и т. д.), аннотирован на уровне предложений с 8 типами несправедливых договорных условий, то есть условий (предложений), которые потенциально нарушают права пользователей в соответствии с законодательством ЕС о защите прав потребителей:

• входные данные — предложение, выходные данные — набор несправедливых типов (если таковые имеются);

6. CaseHOLD (Multiple choice QA): содержит около 53 тыс. вопросов с несколькими вариантами ответов по списку судебных дел (представляют собой краткие резюме решений) из корпуса прецедентного права Гарвардской юридической библиотеки:

• входные данные — отрывки, фрагменты из текстов судебного решения, содержащие некоторое утверждение, выделенное жирным шрифтом;

• выходные данные — номер правильного утверждения из 5-и предложенных вариантов.

Представленный на Hugging Face leaderboard на сегодняшний день устарел (данные на 2021).

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

Пусть LexGLUE и не содержит NLI‑задач, однако такие задачи как CaseHOLD, ECtHR A/B, полагаем, позволяют оценить способность различать схожие нормы, классифицировать тексты по их применению, в целом, что коррелирует со способностью legal reasoning.

Language Reasoning: LegalBench

LegalBench разработан исследователями (Neel Guha, Daniel E. Ho, Julian Nyarko, Christopher Ré) из Стэнфордского университета, является одним из самых известных юридических бенчмарков, позволяющих оценить способность LLM к юридическому рассуждению (legal reasoning) на английском, а впоследствии, как утверждают авторы, и на других языках.

Бенчмарк является результатом совместного труда авторов (все авторы либо являются юристами, либо имеют отношение к юридической профессии) и профессиональных юристов, которые активно привлекались для подготовки датасетов и разработки задач. Например, юристам самим предлагалось предоставить наборы данных или формулировку задачи, с помощью которых можно было бы оценить интересную способность LLM к юридическому рассуждению.

LegalBench: датасеты.

Датасеты (всего — 36 различных корпусов) собраны из 3-х источников:

1. существующих юридических корпусов (часто специально адаптированных для LLM),

2. наборы данных от юристов, участвовавших в проекте,

3. наборы данных, специально созданных авторами проекта.

LegalBench: 6 типов задач.

Бенчмарк состоит из 162 задач, которые распределяются среди 6 различных категорий (типов), соответствующих 6 компонентам юридического анализа (рассуждения) — legal reasoning.

«Ядро» составляют 4-е основных компонента (Issue‑spotting, Rule‑recall, Application, Conclusion), в основе которых лежит довольно известный в юридической практике и юридическом образовании США (и иных стран, правовые системы которых относятся к англосаксонской семье права) формализованный шаблон юридического анализа — IRAC (Issue — Rule — Application — Conclusion).

В соответствии с методикой IRAC юридическое суждение по вопросу следует составлять из следующих компонент:

1. Issue / issue‑spotting — выявление (идентификация) юридической проблемы.

2. Rule / rule‑recall — определение применимых правил.

3. Application — анализ фактов через призму правил.

4. Conclusion — формулирование вывода.

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

Однако IRAC — это, все‑таки, не метод юридического анализа или юридического рассуждения по своей сути, если под ним понимать интеллектуальную деятельность, связанную с решением юридических проблем: в своей практической деятельности юрист, как правило, использует множество навыков (не только письменных) и умений, которые никак не покрываются указанной схемой. Модель IRAC относится к технике и стилю юридического письма (legal writing), которая позволяет ясно и последовательно изложить свои аргументы по какому‑либо правовому вопросу.

При этом данная модель не универсальна и подходит, главным образом, для оформления аргументов в жалобах, претензиях, исковых заявлениях и прочих подобных документах (для каждого аргумента в документе отдельно применяют IRAC).

Для оформления юридических заключений (legal opinions) и меморандумов в той же американской юридической практике также часто используется CREAC (Conclusion, Rules, Explanation of Rules, Application, Conclusion): в соответствии с этой методикой документ начинается с краткого вывода, далее кратко приводятся примененные правила с обоснованием их применения, после чего приводятся факты дела, подробный анализ и итоговый вывод на основании предыдущих элементов. И таких методов более 2-х десятков (подробнее см. по ссылке).

Таким образом, IRAC:

1. не является универсальной схемой юридического рассуждения, даже в США,

2. не позволяет моделировать процесс юридического мышления (юристы очень редко излагают свои мысли напрямую в документах, а их навыки и умения не сводятся к письменному изложению и обоснованию аргументов в тексте),

3. позволяет структурировать анализ и вывод только по одному вопросу‑аргументу: в одном документе могут быть 10-и вопросов или аргументов, каждый из которых может по‑особенному учитываться в итоговом выводе.

Несмотря на указанные ограничения, мы полагаем, что IRAC является естественным (воспроизводит структуру классического силлогизма в юридической сфере) и элементарным (рассмотренные схемы кардинально не отличаются от IRAC и являются, скорее, его вариациями) способом построения юридического рассуждения на уровне аргументов.

Поэтому позиции LLMs на лидерборде LegalBench могут и должны учитываться при выборе модели для компонента генерации в юридических RAG‑системах.

Исходя из схемы IRAC, LLMs оцениваются на 4 типах задачах.

Issue‑spotting: модель должна определить, можно ли из набора данных фактов распознать конкретный юридический вопрос или проблему. Обычно задача формулируется как задача классификация («Да/Нет»):

Rule‑recall: модель должна сформулировать или вывести требуемое правило / ‑а по заданной теме. Это может быть задача либо на генерацию текста, который следует из правила, либо задача на классификацию, например, действует ли указанное правило в данной юрисдикции. Задача важна для оценки достоверности ответов модели.

Rule‑conclusion: модель на входе получает набор конкретных фактов и формулировку правила, на выходе она должна выдать ответ, без пояснений.

Rule‑application: задача формулируется аналогичным образом, что и для rule‑conclusion, но в данном случае модель должна объяснить ход своих «рассуждений». Оценивается корректность изложения и наличие в изложении анализа (аргументации). Генератор должен логично связать факты с нормой и сделать вывод. Для RAG это означает, что модель выдаёт не просто ответ, а развёрнутую аргументацию.

Корректность соответствует критерию, согласно которому объяснения не должны содержать ошибок (искажение юридической нормы, искажение фактов, неправильный вывод, логические и арифметические ошибки).

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

Оставшиеся 2 типа задач, как раз, связаны с ограничениями схемы IRAC.

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

Rhetorical‑understanding — аргументация на основе анализа юридического текста: в этих задачах LLM на вход предоставляется фрагмент текста, содержащий юридическую аргументацию (обычно фрагмент из судебного решения), на выходе модель должна определить, выполняет ли данный фрагмент определенную функцию с точки зрения аргументации / обладает ли определенным свойством. Например:

LegalBench: распределение задач.

162 задачи распределяются по различным критериям:

1. разный формат:

• MCQA — множественный выбор ответов (35 задач),

• генерация (7),

• бинарная классификация (112),

• многоклассовая классификация (8);

2. элементы юридического анализа (видимо, категории задач пересекаются):

• rule‑recall (5),

• issue‑spotting (17),

• rule‑application (16),

• rule‑conclusion (16),

• interpretation (119),

• rhetorical‑understanding (10).

3. поддомены (авторы специально отмечают: для того, чтобы стандартизировать оценку, они выпустили «руководство по ответам» для каждой задачи данной категории, которое содержит выводы, необходимые для каждого примера, и описывает распространенные типы ошибок. Очевидно, что это существенное ограничивает полезность метрики Rule‑application Task для оценки модели в условиях НЕамериканской правовой системы).

• контрактное право (58),

• корпоративное право (58),

• прочие (гражданский процесс, страхование и т. д.).

4. стили юридической письменной речи:

• plain English (32),

• legal opinions (11),

• merger agreements (34),

• contracts (55),

• statutory text (3),

• др.

LegalBench: стратегии промпт‑инжиниринга.

Все задачи представлены в виде инструктивного набора данных. Инструкции были подготовлены авторами проекта, с привлечением сторонних юристов — ученых и практиков. Помимо инструкций в контекст модели при оценивании встраиваются от 0 до 8 заранее подготовленных примеров.

LegalBench: ограничения (указанные авторами проекта):

1. задачи построены на датасетах с короткими по сегодняшним меркам текстами: на момент публикации (2022) большинство оцениваемых LLM не работали с длинными (для любых юридических задач) контекстами;

2. задачи рассчитаны на однозначные (объективно верные) ответы, а не на гибкое и извилистое юридическое рассуждение;

3. бенчмарк ограничен английским языком и преимущественно американской юрисдикцией;

4. ограничения, связанные с IRAC (подробно рассмотрены выше по тексту);

5. бенчмарк не покрывает задач комплексного многоступенчатого юридического анализа (каковым он, как правило, и является на практике), наконец, тестируя компоненты юридического рассуждения по отдельности (сегодня мы поручили такую многоступенчатую задачу AI‑агенту);

6. датасеты представлены исключительно поддоменом гражданского права, со смещением в сторону контрактного права.

LegalBench: Leaderboards for Tasks on 07/23/2025

Issue Tasks

Отметим:

1. в лидерах модели семейства Gemini, имеющие на сегодняшний день самый большой размер окна — 1 000 000 токенов;

2. LLMs не универсальны: на разных категориях задач разные модели демонстрируют различные результаты;

3. интересно, что модель gpt-4o‑mini занимает почетное 2-е место на Rhetoric Tasks, в среднем, модель занимает 22 место в общем рейтинге;

4. С точки зрения соотношения «цена / качество» Gemini 2.5 Flash Preview (Nonthinking) на данном бенчмарке выглядит оптимальным выбором.

Итак, рассмотрев общие и специальные бенчмарки, мы можем сделать следующие общие выводы:

1. Существующие на сегодняшний день общие и специальные бенчмарки позволяют оценить работу компонентов (генератора, векторного хранилища и эмбеддера) RAG‑системы в юридическом домене только на этапе предварительной проверки.

2. Отсутствуют признанные и поддерживаемые специализированные юридические бенчмарки на русском языке. Имеющиеся комплексные и наиболее проработанные англоязычные бенчмарки дают возможность оценить только общие юридические способности LLMs «понимать» и «рассуждать», и то — на ограниченном наборе задач, замкнутых на отрасли гражданского, главным образом, контрактного права США.

3. Рассмотренные бенчмарки не оценивают качество и производительности модуля поиска, тогда как он имеет ключевое значение для оценки работы RAG в целом: риск возникновения «галлюцинаций» при генерации увеличивается по мере того, как в контекстное окно языковой модели включается нерелевантная информация, что представляет значительный риск для работы приложения в юридическом домене.

4. Главное практическое следствие ограниченности рассмотренных общих и специальных бенчмарков — юристам трудно соотнести результаты работы современных LLMs с их собственным пониманием юридической компетентности.

Таким образом, на сегодняшний день использование бенчмарков позволяет на предварительном этапе сузить выбор кандидатов на место компонентов в RAG‑системе: сравнительный анализ по рассмотренным метрикам и иным параметрам позволит вам принять более обоснованные решения в отношении компонент приложения RAG.

Эталонные наборы данных

Однако, несмотря на полезность этих стандартизированных метрик для начального этапа, особенно учитывая отсутствие специализированных юридические бенчмарков на русском языке, чтобы действительно понять, насколько хорошо ваша система RAG будет работать на ваших уникальных данных, необходимо создать собственную систему оценки.

Собственная система оценки RAG предполагает наличие у вас эталонных данных, которые будут отражать реальные сценарии работы вашего приложения. Эталонные данные — это, в общем, данные, которые представляют собой условно идеальные ответы на заранее сформулированные вопросы. Категории вопросов должны максимально охватывать прогнозируемые сценарии работы приложения при взаимодействии с пользователями, при этом вопросы должны быть максимально реалистичными и в то же время достаточно экспертными, чтобы не сбить модель с толку.

Несмотря на то, что оценка на таких данных может показаться довольно субъективной, наличие набора эталонных данных для сравнения входных и выходных данных RAG‑системы является критически важным шагом для анализа влияния внесенных изменений и повышения эффективности системы в дальнейшем.

Но как объективно оценить качество такой RAG‑системы в столь ответственной области, как юриспруденция? Здесь нам на помощь приходит фреймворк RAGAS.

Оценка RAG‑системы с помощью фреймворка RAGAS на эталонных данных

Оценка работы модуля поиска

Для оценки поиска RAGAS предлагает две метрики:

Context Precision: оценивает, насколько высоко ранжируются релевантные для «эталонного ответа» элементы в извлеченном контексте. Идеальная ситуация, когда все релевантные фрагменты находятся на самых верхних позициях среди извлеченных результатов. Эта метрика подчеркивает, что важен не только сам факт наличия релевантного контекста (чанка), но и его позиция в выдаче ретривера: если релевантные фрагменты находятся в конце списка, context precision будет низкой, даже если вся нужная информация была извлечена.

Для юридического домена метрика крайне важна, так как она позволяет гарантировать, что LLM при обработке похожих пользовательских запросов будет держать фокус на наиболее релевантной правовой информации. Если говорить о потенциале масштабирования базы знаний в юридической сфере, такие БД могут быть огромны, и «шум» в извлеченном контексте (нерелевантные статьи, дела) может «сбить» LLM с «толку».

Context Recall: оценивает, насколько пОлно извлеченный контекст соответствует эталонному (аннотированному) ответу, который считается «истинным» (ground truth). Метрика считается, в общем, так: берем эталонный ответ, разбиваем его на отдельные смысловые утверждения, затем для каждого такого утверждения проверяем, есть ли информация, его подтверждающая, в контексте, который выдал ретривер. То есть метрика показывает долю утверждений из эталонного ответа, которые действительно присутствуют в извлеченном контексте.

Для юридического домена метрика также крайне важна: чтобы дать полный и точный ответ, LLM должна иметь доступ ко всей необходимой правовой информации, соответствующей набору разнородных фрагментов (конкретные статьи, части статей, релевантные судебные прецеденты и т. д.). Отметим, что для адекватной оценки этой метрики необходимо наличие качественных и подробных эталонных ответов (ground_truth).

Оценка работы модуля генерации

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

Необходимо учитывать, что метрика сильно зависит от способности Critic LLM, которую использует RAGAS, корректно разбивать ответ на атомарные утверждения, а также точно определять, подтверждается ли каждое утверждение контекстом (это требует глубокого понимания текста и иногда — логического вывода).

Для юридического домена, пожалуй, самая важная метрика, поскольку именно она позволяет понять, «галлюцинирует» ли LLM при генерации, а это критически важный риск при использовании модели в домене. В правовой сфере недопустимы «выдуманные» ссылки на законы, несуществующие судебные решения или искаженные факты.

Answer Relevance: оценивает, насколько сгенерированный ответ релевантен исходному вопросу. Метрика позволяет оценить, насколько (условно) «хорошо» ответ модели отвечает на заданный вопрос (например, «плохой» ответ может быть обусловлен тем, что модель отклоняется от темы, включая ненужную информацию). Высокий балл означает, что искусственные вопросы, полученные из ответа, очень похожи на оригинальный вопрос, что должно указывать на высокую релевантность ответа; низкий балл означает, что ответ, возможно, ушел в сторону или содержит много нерелевантной информации.

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

1. генерация искусственных вопросов: на первом шаге Critic LLM, которую использует RAGAS, основываясь на сгенерированном моделью ответе, обратно генерирует несколько (по умолчанию — 3) вопросов, соответствующих этому ответу. То есть Critic LLM генерирует набор вопросов, на которые, по ее «мнению», отвечает сгенерированный текст.

2. сравнение с исходным вопросом: на втором шаге вычисляется среднее косинусное расстояние между этими сгенерированными (искусственными) вопросами и исходным (оригинальным) вопросом.

Учитывая то, как считается данная метрика, ее использование для оценки систем в юридическом домене, на наш взгляд, должно быть ограничено: Critic LLM может истолковать избыточность юридического ответа как нераскрытие релевантности: в юридической практике часто ценятся подробные ответы, которые раскрывают тему с разных сторон, даже если исходный вопрос был общим; Critic LLM может «воспринять» подробный ответ как нерелевантный исходному «простому» вопросу. Это парадокс: хороший юридический ответ может быть оценен низко.

Critic LLM специально не дообучена на юридических текстах, также данная модель «видит» только сгенерированный ответ и исходный вопрос. Она не «знает», что у оцениваемой RAG‑системы есть доступ к огромной базе документов, которая позволяет ей давать такие подробные ответы на основе коротких, но по смыслу емких вопросов.

В общем, Critic LLM под «капотом» у RAGAS, скорее всего, не сможет уловить юридические смысловые тонкости, представленные в ответе RAG‑системы, и адекватно сопоставить его по смыслу с пользовательскими запросами. Вместо этого, Critic LLM, например, может «воспринимать» каждый абзац ответа как «ответ» на отдельный, очень конкретный вопрос, теряя из виду общий смысл оригинального запроса.

Таким образом, answer_relevance полезна для выявления абсолютно нерелевантных ответов или «болтовни». Однако для ответов, которые являются подробными и юридически релевантными, но значительно более объемными, чем исходный вопрос, эта метрика может давать вводящие в заблуждение низкие оценки.

Комплексные оценки

Наиболее значимой является Answer Correctness, которая оценивает точность сгенерированного ответа по сравнению с «эталонным» ответом (ground truth).

На 1-м шаге рассчитывается фактическая корректность (Factual Correctness) — F1-подобная метрика: насколько факты, утверждения или положения, присутствующие в сгенерированном ответе, совпадают с фактами в эталонном ответе.

На 2-м шаге рассчитывается семантическая схожесть (Semantic Similarity): насколько сгенерированный ответ и эталонный ответ близки по смыслу. На 3-м шаге рассчитывается взвешенное среднее фактической корректности и семантической схожести, по умолчанию веса составляют [0.75, 0.25] соответственно.

Учитывая, что Critic LLM специально не дообучена на юридических текстах Answer Correctness следует использовать с еще бОльшой осторожностью чем Answer Relevance:

• ответы на юридические вопросы, как правило, содержат мало фактологической информации, так как представляют собой юридическую оценку указанных в вопросе фактов, при этом отсутствие в ответе ссылок на какие‑либо обстоятельства далеко не всегда означает, что ответ неполный или некорректный;

• Critic LLM может быть сложно атомизировать юридический текст на дискретные «факты», как это делается для более простых утверждений, и она может вести себя непредсказуемо при оценке наличия набора таких «фактов» в сгенерированном и «эталонном» ответах.

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

Подведем краткий итог обзора метрик RAGAS и ограничений их использования в юридическом домене.

1. Faithfulness и Context Precision — основные метрики: с учетом рассмотренных особенностей и ограничений использования метрик RAGAS для оценки RAG‑систем в юридическом домене, оценка по данным метрикам должна быть в приоритете.

2. В качестве Critic LLM, если есть такая возможность, целесообразно использовать LLM, дообученную на юридических текстах.

3. Важность тщательной экспертной подготовки тестового датасета, включающего Ground Truth: все метрики, кроме Faithfulness и Context Precision, очень требовательны к формулировкам «эталонных» ответов.

Тестовый набор данных для RAGAS

Сразу отметим, что нам неизвестно о принципах сборки тестовых датасетов для юридического домена, в том смысле, что отсутствуют известные и общепризнанные публикации о том, какие именно способности целесообразно учитывать при автоматической оценке работы RAG‑системы в юридическом домене.

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

1. Проверка на »галлюцинации»:

Пример вопроса: «Какой статьей гражданского кодекса регламентируется продажа квартиры?»

Пример ответа: «Квартира является разновидностью жилых помещений, продажа которых регламентируется статьей 558 ГК РФ. Эта статья описывает существенные условия договора продажи жилых помещений, а также указывает на необходимость государственной регистрации такого договора».

2. Проверка на работу с неклассическими случаями и пограничными примерами:

Пример вопроса: «Является ли футбольное поле недвижимым имуществом?»

Значимые примеры в юридической практике, как правило, связаны с неоднозначностью интерпретации того или иного правила, что приводит к возникновению спора, а спорными являются именно «пограничные» случаи.

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

3. Сравнение:

Сравнительный анализ используется при проведении исследований, пожалуй, в любой профессиональной сфере знаний.

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

Пример ответа: «Термин объект капитального строительства не равнозначен термину объект недвижимого имущества. Определение термина объект капитального строительства даётся в ст. 1 ГрК РФ, содержание категории объект недвижимого имущества раскрывается в ст. 130 ГК РФ. Как указано в постановлении Президиума Высшего Арбитражного Суда РФ от 24 сентября 2013 г. N 1160/13: …».

4. Квалификация:

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

Пример вопроса: «С какого момента появляется земельный участок как недвижимая вещь?»

Пример ответа: «В соответствии с п. 1 ст. 141.2 ГК РФ земельным участком признается часть поверхности земли, границы которой определены в порядке, установленном законом. … Таким образом, общий вывод таков: в настоящее время земельный участок приобретает правовой режим недвижимой вещи с момента первой государственной регистрации права собственности на него. Однако это не касается земельных участков, право собственности на которые было приобретено до введения в России системы государственной регистрации прав на недвижимые вещи, а также в отношении земельных участков, находящихся в публичной собственности …».

Итак, перечисленные выше способности — (1) не галлюцинировать при ответе на вопросы, требующие цитат из законов или решений судов или каких‑либо фактов; (2) производить сравнительный анализ юридических аспектов объектов и явлений, которые приведены в вопросе; (3) рассуждать и делать выводы как настоящий юрист (юридическая квалификация), в частности в (4) пограничных и неклассических случаях, — полагаем, это важные и значимые способности, которые должна демонстрировать RAG‑система, работающая в юридическом домене.

1. В рамках эксперимента нашей основной задачей было отработать оценку системы с точки зрения наличия у нее описанных выше »способностей», которые в нашем тестовом датасете соответствуют типу вопроса (question_type), всего — 15 вопросов и развернутых ответов. Приоритет был отдан вопросам, которые позволяют оценить наиболее критические ошибки в работе системы — «галлюцинациям» и неклассическим случаям квалификации:

Nota bene!

При использовании RAGAS важно учитывать, что фреймворк активно будет использовать API LLM (для Generator LLM & Critic LLM), что означает — каждый раз, когда создается или оценивается эталонный пример, вызывается LLM (иногда многократно для одной метрики). Это может привести к довольно большим расходам на генерацию токенов. Поэтому в начале, в любом случае, лучше протестировать систему на датасете небольшого размера.

2. Для выявления зависимости производительности системы от типа вопроса по отношению к имеющейся базе знаний, которую использует RAG, мы разделили все тестовые вопросы на две группы:

База знаний судебной практики, напомним, состоит из текстов решений Верховного Суда Российской Федерации, в которых рассматриваются вопросы неоднозначной квалификации объектов имущества, за период: 2006-2023.

• Группа A: 8 целевых вопросов: вопросы, которые напрямую касаются неклассической квалификации объектов имущества и, как следствие, релевантны специализированной базе знаний судебной практики.

• Группа B: 7 смежных и общих вопросов (остальные вопросы) — остальные вопросы, которые не имеют прямого отношения к специализированной базе знаний, а сосредотачиваются, например, на процессуальных аспектах («Как подать иск …?») или касаются смежных / общих правовых категорий / понятий.

Nota bene!

При использовании RAGAS важно учитывать, что фреймворк активно будет использовать API LLM (для Generator LLM & Critic LLM), что означает — каждый раз, когда создается или оценивается эталонный пример, вызывается LLM (иногда многократно для одной метрики). Это может привести к довольно большим расходам на генерацию токенов. Поэтому в начале, в любом случае, лучше протестировать систему на датасете небольшого размера.

Сбор данных

Учитывая, что автор является практикующим юристом, датасет собирали собственными силами. При этом для запуска системы в прод или при ее масштабировании, очевидно, потребуется привлечение экспертов из предметной области: на первом этапе, на наш взгляд, выборка должна, в любом случае, состоять из только из проверенных экспертами вопросов‑ответов.

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

В заключение также отметим, что мы намеренно (дабы не подгонять его под метрики, а наоборот — как можно сильнее приблизить к реальности) включили в датасет:

1. довольно каверзные и непростые вопросы, даже для практикующего юриста (например, на вопрос — «С какого момента появляется земельный участок как недвижимая вещь?», можно ответить очень по‑разному, и, в целом, он не имеет строгого и однозначного толкования);

2. вопросы, которые требуют от модели не только знаний, которые соответствуют поддомену нашей базы знаний (регулирование недвижимого имущества), но и общих знаний, связанных, например, с подачей искового заявления в суд.

Результаты оценки

Сначала посмотрим на сводные средние оценки по всем вопросам и метрикам:

Анализ выявляет несколько ключевых тенденций в работе системы:

1. Среднее значение ключевой метрики (0.88) — Faithfulness достигло высокого показателя при относительно небольшом разбросе оценок в пределах от 0.8 до 1 (2 «выброса» с невысокими оценками). В целом, это означает, что когда система получает релевантный контекст, даже сравнительно небольшая модель gpt4O‑mini практически не «галлюцинирует». Она воспроизводит факты, взятые непосредственно из извлеченных документов, что делает ответы надежными с точки зрения их источника.

2. Среднее значение метрики Context Recall (0.77) также является достаточно высоким, при этом оценки по большинству вопросов (2/3) достигают наивысшего значения, однако 3 ответа, согласно показателям, вообще не опираются на контекст. В целом, базы знаний законодательства и судебной практики адекватно покрывают предметную область большинства вопросов, и семантический поиск работает корректно в рамках своей специализации. Однако имеющиеся среди оценок «выбросы» с нулевыми значениями свидетельствуют о том, что ретривер при обработке некоторых вопросов извлекает совсем нерелевантный контекст. В таких условиях gpt4O‑mini, будучи небольшой, не обладает достаточными обобщающей и аналитической (рассуждающей) способностями, чтобы самостоятельно делать сложные юридические выводы из неоднозначного или «грязного» контекста.

3. Среднее значение метрики Context Precision (0.68), отличающееся в меньшую сторону от Context Recall, а также довольно высокая степень разброса оценок по вопросам, говорят о том, что при обработке некоторых вопросов ретривер извлекает «шумный» контекст. Распределение оценок характеризуется значительной левосторонней асимметрией (Me > X_ср): в 50% случаев метрика принимает высокие значения (более 0.8), в остальных случаях показатели метрики крайне нестабильны (разброс от 0 до 0.58).

4. Среднее значение метрики Answer Relevancy является низким (0.46), при этом распределение оценок, так же, как и в случае с Context Precision, характеризуется значительной левосторонней асимметрией (Me > X_ср): 8 из 15 ответов получили оценки выше 0.6, что дает основания видеть тенденцию к увеличению показателя. Выше мы указывали на то, что данная метрика должна оценивать очень осторожно, так как модель может истолковать избыточность ответа как нераскрытие релевантности, что особенно актуально для ответов, полученных при учете «шумных» контекстов.

5. Среднее значение метрики Answer Correctness (0.53), при наиболее симметричном распределении оценок с наименьшим разбросом, является, на наш взгляд, вполне допустимым. Метрика ведет себя, в целом, стабильно во всех случаях, не сильно изменяясь от качества извлеченного контекста. Выше мы отмечали, что особенность юридических ответов не практике состоит в том, что воспроизводство фактологической составляющей совсем не коррелирует с их качество. Если к этому прибавить абсолютно допустимую вариативность ответов на неоднозначные вопросы, а также в ряде случаев — «шумный» контекст и очевидные ограничения модели gpt4O‑mini, значение метрики является допустимым.

Наши наблюдения подтверждаются данными корреляции метрик. Answer Correctness заметно коррелирует только с точностью контекста (Context Precision). Также отметим высокое значение корреляции Faithfulness с полнотой контекста (Context Recall).

Теперь посмотрим на распределение средних значений наиболее интересных для нас метрик (Context Precision, Context Recall, Faithfulness) по всем типам вопросов:

1. «Галлюцинации» (смежные или общие вопросы, не опирающиеся прямо на базу знаний судебной практики);

2. «Пограничные случаи»;

3. «Квалификация объектов»;

4. «Сравнение» (вопросы, требующие сравнения правовых понятий и категорий, в том числе не входящих в базу знаний судебной практики).

   

Производительность ретривера (context_precision и context_recall):

• графики подтверждают, что ретривер RAG‑системы демонстрирует выдающуюся производительность на вопросах, которые находятся в центре его специализации — квалификация и пограничные случаи;

• напротив, для вопросов, требующих сравнения или имеющих «потенциал к галлюцинациям», производительность ретривера резко падает. Средний context_precision составляет всего 0.33 и 0.37 для этих категорий, что говорит о серьезном загрязнении контекста. Это наглядно иллюстрирует, что базовый семантический поиск с базовыми элементами архитектуры RAG‑системы и относительно слабой моделью генерации, пока не способен эффективно работать с запросами, выходящими за рамки узкой специализации, опирающейся на базу знаний.

Обоснованность ответов (faithfulness):

• модель gpt4O‑mini в целом хорошо справляется с задачей «оставаться в рамках» предоставленного контекста. Интересно, что даже в тех случаях, когда контекст «загрязнен» («Сравнение» — 0.82, «Галлюцинации» — 0.81), модель в большинстве случаев пытается опираться на него, что подтверждает её склонность к grounding, а не к генерации «с нуля».

  

Анализ производительности системы на целевых вопросах показывает, что она демонстрирует высокие или приемлемые результаты по ключевым метрикам для RAG‑системы, даже при базовых элементах архитектуры:

1. Faithfulness: среднее значение этой метрики достигает почти идеального показателя (0.95), что является одним из самых важных результатов, так как система воспроизводит факты, взятые непосредственно из извлеченных документов, что делает ответы надежными с точки зрения их источника, а это очень важно для юридического домена.

2. Context Recall: среднее значение также является достаточно высоким — 0.82, ретривер в подавляющем большинстве случаев успешно находит хотя бы один релевантный документ, содержащий необходимую информацию для ответа.

3. Context Precision: средний показатель 0.76 существенно выше производительности на смежных / общих вопросах (0.58) и говорит о том, что ретривер, хотя и с некоторыми ошибками, способен фильтровать «шум» и предоставлять модели относительно чистый контекст.

4. Answer Relevancy: парадоксально, но этот показатель для целевых вопросов (0.35) значительно ниже, чем для смежных / общих. Полагаем, этот феномен объясняется тем, что на прямые вопросы, на которые нет однозначного ответа, система, в отличие от экспертов, склонна давать развернутые и избыточные ответы.

5. Answer Correctness: среднее значение — 0.54 фактически не отличается от значения для смежных / общих вопросов.

Проведенный сравнительный анализ распределения метрик по целевым и смежным / общим вопросам демонстрирует, что RAG‑система с архитектурой, опирающейся на базы знаний законов и судебной практики, даже в своей базовой версии, является надежным инструментом в тех случаях, когда она опирается на базы знаний, то есть в узкой области своей специализации. При этом ее производительность может падать при выходе за пределы этой области.

При этом даже небольшая gpt4O‑mini, в качестве компонента RAG‑системы, очень неплохо справляется с задачей «обоснования» ответов, качество которых остается, в этом отношении, приемлемым даже нецелевых вопросов. Предложенная архитектура системы в базовом варианте позволила достичь приемлемых результатов работы ретривера, несмотря на непростые экспертные вопросы в тестовом датасете.

ВЫВОДЫ и возможные "точки роста":

1. Предложенная архитектура «Law & Practice Ensemble RAG» даже в базовом варианте продемонстрировала неплохие результаты при решении обозначенных выше ключевых проблем работы систем на основе RAG в юридическом домене:

• специализированное чанкирование, основанное на кастомных правилах, учитывающих структуру статей законов и разделов судебных решений, помогает избежать потери контекста на границах разделения фрагментов;

• гибридный подход (разделение индексов и ретриверов по поддоменам) позволяет реализовать поиск независимо по наиболее значимым поддоменам (законов и судебной практики);

• взвешенное ансамблирование извлеченных фрагментов законов и судебной практики вместе с RRF‑переранжированием итоговых результатов поиска позволяет не просто найти релевантные документы, а отранжировать их с учётом экспертной важности, что напрямую влияет на качество генерируемого ответа;

• решение проблемы многоаспектности запросов с помощью MultiQueryRetriever, который автоматически генерирует альтернативные формулировки запросов, значительно расширяет охват поиска, снижая зависимость от точности изначального запроса;

• гибкие возможности настройки параметров поиска на уровне пользователя и разработчика (возможность легко и быстро регулировать значимость поддоменов при ансамблировании, а также количество используемого контекста) позволяют оперативно настраивать систему для решения различных задач с необходимой точностью и (или) стоимостью генерации токенов, а также согласуются с практикой проверки ответов юристами;

• профессиональный вывод с использованием кастомных промптов позволяет моделировать структуру реального юридического заключения.

2. Эксперимент показал также и ограничения предложенной архитектуры в базовом виде, но мы видим «точки роста»:

• Усовершенствование модуля поиска. Базовый семантический поиск, даже в ансамбле, не всегда может отсеять «шум» в извлекаемом ретривером контексте. Для решения этой проблемы можно (все нужно отдельно тестировать):

  • внедрить классический гибридный поиск: комбинация семантического поиска с традиционным поиском по ключевым словам (BM25) может повысить context_precision на вопросах, содержащих точные ссылки на статьи, номера дел и другие фактологические данные, которые плохо улавливаются семантическими эмбеддингами;

  • использовать более современную и специализированную embedding‑модель (при необходимости и наличии ресурсов — дообучить на юридических данных).

• Усовершенствование модуля генерации. Результаты эксперимента (невысокая, но стабильная Answer Correctness) говорят о том, что даже с идеальным контекстом gpt4O‑mini не способна к глубокому юридическому анализу и рассуждению. Возможные направления развития:

  • Fine‑tuning на юридическом домене: например, дообучение модели на размеченном корпусе юридических пар — «вопрос‑ответ» гипотетически может позволит ей не просто воспроизводить факты, но и научиться их синтезировать при моделировании юридического рассуждения;

  • использование более мощной и крупной LLM (например, GPT-4o или Gemini 1.5 Pro, либо русскоязычные модели — YandexGPT и GigaСhat), дабы использовать более высокие рассуждающие способности (Reasoning) модели генерации.

• Дополнение архитектуры агентными модулями (требует проведения предварительного исследования, самостоятельность агентам в юридической сфере необходимо давать постепенно, начав с базовых инструментов, а‑ля проверка актуальной даты). Агентная архитектура позволит отойти от парадигмы «один запрос — один ответ» к многоэтапному, более сложному поиску и анализу, в рамках которого система способна будет планировать стратегию поиска, привлекать дополнительные инструменты (веб‑поиск, калькуляторы и пр.), а также организовывать многократные шаги запроса/поиска:

  • планирование действий и принятие решений: в контексте юридического ассистента это может означать, например, что бот сам определит, какие дополнительные уточняющие вопросы задать или какие базы ему подключить;

  • декомпозиция сложного запроса: например, обрабатывая вопрос «Как изменилась судебная практика по квалификации газопроводов за последние 5 лет?», агент мог бы сначала найти все релевантные судебные решения, затем проанализировать их хронологически, выявить ключевые изменения в аргументации и лишь после этого сгенерировать итоговый вывод;

  • работа с противоречиями: агент мог бы распознавать противоречивые судебные решения и предупреждать пользователя о наличии неоднозначной практики, а не просто выбирать один из вариантов.

• Интеграция с графовыми базами знаний:

  • для повышения качества извлекаемого контекста вместо (или в дополнение) простого поиска по семантической схожести или по ключевым словам, можно реализовать поиск по графовой базе знаний (GraphRAG);

  • такая база знаний представляет собой связанные между собой юридические сущности, автоматически извлеченные из текстов (например, с помощью GraphRAG от Microsoft), или юридические онтологии (Legal Ontologies); поиск по такой базе знаний позволит системе, например, использовать знание о том, что «сделка с недвижимостью» связана с «правом собственности» и «регистрацией», что может помочь модулю поиска выбирать релевантные законы и кейсы через навигацию по графу;

  • полагаем, такая база знаний позволила бы системе ответить на вопрос: «Какой судебный прецедент повлиял на толкование статьи 130 ГК РФ?» Векторный поиск не может этого сделать, так как он не хранит информацию о взаимосвязях.

• Расширение и уточнение датасета для оценки системы.

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

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

Однако с ростом числа поддоменов возникнет задача координации их между собой и возможного кросс‑индекса.

Теоретически, такая мультидоменная система могла бы быть реализована на основе архитектуры GraphRAG, где доменные индексы были бы связаны через различные агентные стратегии поиска по графам знаний. Кроме того, мультидоменность подразумевает необходимость более гибкой генерации запросов и, возможно, персонализации ответов в разных областях. Все это потребует гораздо больших ресурсов, чем описанная RAG‑система. Но во всем важен первый шаг!

---

Работа над юридическими RAG-системами показывает: одной лишь теории про бенчмарки и архитектуру недостаточно. Чтобы реально создать ассистента, способного работать с правовыми документами, нужно разбираться и в обработке языка, и в методах машинного обучения, и в том, как соединять разные компоненты в целостную систему. Для этого подойдут специализированные курсы.

На курсе NLP / Natural Language Processing вы подробно изучите работу трансформеров, семантический поиск, методы построения QA-систем и обработку текстов в разных предметных областях. Курс Machine Learning. Professional поможет системно закрепить знания по машинному обучению и глубинным моделям, что особенно важно для разработки и оценки сложных прикладных решений, включая RAG-ассистентов.

Все программы можно посмотреть в каталоге курсов.