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

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

Юридическая сфера деятельности — одна из тех гуманитарных сфер, которые стоят на пороге масштабной трансформации под воздействием технологий ИИ. И дело не ограничивается автоматизац

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

• Как именно ИИ влияет на юридическую деятельность уже сегодня? С какими проблемами приходится сталкиваться юристам при использовании современных LLM?

• Чем обусловлены сложности языкового моделирования в юридической сфере?

• Возможности и ограничения архитектуры RAG+LLM в юридической предметной области.

• Юридические бенчмарки, оценка RAG‑системы с помощью фреймворка RAGAS на эталонных данных.

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

План следующий:

1. В первой части:

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

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

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

2. Во второй части:

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

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

Юридическая деятельность, а также роль юриста в относительно ближайшем будущем неизбежно подвергнутся масштабной ИИ‑трансформации, обусловленной общим трендом автоматизации задач, связанных с обработкой текстов и изображений. Так, недавно CEO Anthropic Дарио Амодей заявил, что развитие ИИ уже в недалеком будущем (перспектива — 5 лет) может привести к массовым сокращениям «беловоротничковых» рабочих мест.

Появляется множество публикаций (см., например, РБК: Будущее труда: как жить и работать в мире с ИИ) о том, что, мол, ИИ — не конкурент, а AI‑партнер для профессиональных юристов. Авторы полагают, что алгоритмы ИИ будут «довольствоваться» рутинными задачами, оставляя человеку задачи более высокого уровня — те, где важны опыт, эмпатия и способность мыслить вне шаблонов, то есть задачи сугубо творческие.

Thomson Reuters оптимистично пишет: ИИ преобразует юридическую профессию, в целом. Автоматизация рутинных задач и повышение продуктивности юристов с помощью инструментов на базе ИИ, которые занимаются проверкой документов, юридическими исследованиями и анализом контрактов, может сэкономить юристам 4 часа в неделю и принести (консалтинговым фирмам) 100 000 долларов в год в виде дополнительного оплачиваемого времени на каждого юриста.

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

О непростой задаче моделирования юридического языка

Может ли искусственный интеллект уже сегодня стать надежным помощником в этой работе?

Юридическая деятельность объективно реализуются в виде различных текстов. И, казалось бы, в нашем распоряжении мощные NLP Tools, способные учитывать как особенности делового стиля, так и контекст использования различных языковых единиц.

В чем, собственно, тогда сложность? Специфика юридических текстов состоит в том, что за привычными языковыми единицами стоит своя, особенная семантика. То есть, когда мы используем привычные нам слова и выражения в различных юридических практиках, мы говорим и пишем по‑особому. Речь идет, по сути, о некоем особом способе говорить или писать, по‑научному — о юридическом дискурсе.

Юристы изобрели целый велосипед

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

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

К примеру, если попросить ChatGPT ответить на более сложный и неоднозначный вопрос а‑ля «Является ли велосипед источником повышенной опасности», модель ответит (на момент написания статьи) как‑то так:

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

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

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

Факторы возникновения сложностей моделирования юридического языка

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

1. Неопределенность юридического языка.
   Границы ключевых терминов, понятий и категорий «размыты» и интерпретируются на практике субъективно теми, кто уполномочен принимать юридически значимые решения.

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

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

3. Противоречивая судебная практика.

   Аналогичные обстоятельства дела — разные выводы: суды могут по‑разному квалифицировать объекты при схожих обстоятельствах.

4. Дефицит данных для создания действительно полезных решений.

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

5. Избыточность юридического языка

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

Данные факторы обусловливают различные сложности в практическом использовании »чистых» LLM для обработки юридических вопросов. Перечислим некоторые из них:

1. LLM ограничены информацией о мире, актуальной, максимум, на время последней итерации обучения;

2. LLM «страдают» от «галлюцинаций» — генерации фактически или контекстуально неверной, но правдоподобной информации, что недопустимо в правовой сфере;

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

4. использование «чистых» LLM пока не позволяет реализовать разделение прав и управление доступом в отношении помещаемых в него документов.

Главная сложность, безусловно — это склонность «чистых» LLM к «галлюцинациям».

Навигация в правовом поле с помощью RAG-систем

Как относительно малыми силами уменьшить вероятность и количество »галлюцинаций»? — Использовать RAG!

RAG (от Retrieval Augmented Generation, что можно перевести как «Генерация с дополненной выборкой») — технология или методика работы с LLM, которая позволяет на основе данных, полученных в результате поиска во внешних источниках, контекстуально оптимизировать генерацию ответов модели. Согласно оригинальной статье, посвященной RAG (Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks), «ванильный», базовый RAG включает 2-е ключевых компоненты:

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

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

Почему не Fine‑tuning?

Очевидно, сразу пытаться дообучать (Fine‑tuning) LLM на вопросно‑ответном датасете, если вы не обладаете достаточными людскими, финансовыми и вычислительными ресурсами, в такой сложной области знаний как юридическая — не лучшая стратегия:

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

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

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

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

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

6. изменение документации / выход новой версии базовой LLM модели ? повторное переобучение;

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

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

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

Архитектура »ванильной» RAG‑системы.

На сегодняшний день базовая («ванильная») архитектура RAG‑систем включает в себя три связанных друг с другом этапа:

1. Индексация (Indexing): входной текст разделяется на сегменты заданного размера, именуемые «чанками» (от англ. сhunk «кусок»), которые затем векторизуются в соответствии с определенным алгоритмом; далее полученные векторы вместе с соответствующими чанками индексируются и сохраняются в специализированном векторном хранилище, оптимизированном для поиска по сходству (с входным запросом пользователя).

2. Поиск (Retrieval): поступивший пользовательский вопрос векторизуется в соответствии с тем же алгоритмом, что и на этапе индексации, после чего осуществляется поиск в ранее созданном векторном хранилище данных; результатом поиска является top‑k наиболее релевантных документов (чанков), отранжированных в соответствии с определенной мерой сходства (наиболее распространенная — косинусное расстояние между векторами) между векторами входного вопроса и векторами в хранилище данных.

3. Генерация (Generation): на основании заранее подготовленного промпта, состоящего из пользовательского запроса или системного промпта, а также извлеченного контекста на этапе поиска, LLM генерирует свой ответ, используя как свои внутренние параметрические знания, воплощенные в весах модели, так и непараметрические данные, полученных из внешних источников на предыдущем этапе.

   

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

О важности предварительного этапа сбора и подготовки данных перед развертыванием RAG‑системы

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

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

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

1. Данные должны быть предварительно разбиты хотя бы на общие тематические кластеры в соответствии с их источниками (мы здесь не рассматриваем архитектуры хранения данных — сетевые диски, DMS, ЭДО и проч.), например: кадровые документы, внутренние ЛНА, приказы и регламенты, корпоративные документы, договоры с внешними контрагентами, судебное делопроизводство, корпоративные документы, юридические заключения и справки, подготовленные юристами компании и т. д.

2. Должна быть проведена предварительная обработка текстов‑источников данных:

• текстовые данные должны иметь машиночитаемый формат, сканы лучше предварительно распознать, применив OCR;

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

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

О многоаспектности юридических вопросов

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

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

2. актуальной судебной практики,

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

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

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

Таким образом, «ванильный» RAG не подходит:

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

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

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

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

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

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

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

2. Повышение релевантности ответов системы с учетом многоаспектности юридических вопросов: используем MultiQueryRetriever для генерации альтернативных формулировок вопросов.

3. Повышение точности ответа за счет:

• возможности однозначной верификации значимой юридической информации при сравнении с информацией в использованном контексте;

• возможности управления размером контекстного окна;

• реализации структурированных ответов по заранее заданным шаблонам.

4. Оценка качества: тестирование системы на контрольных вопросах.

Подготовка данных: источники знаний — законы и решения судов

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

1. Тексты законов: Гражданский кодекс Российской Федерации, Земельный кодекс Российской Федерации, Градостроительный кодекс Российской Федерации, Гражданско‑процессуальный кодекс Российской Федерации, Жилищный кодекс Российской Федерации, некоторые федеральные законы.

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

   

Сбор данных в конкретной области — это довольно кропотливая и трудозатратная

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

Пайплайн предобработки данных

Пайплайн предобработки данных условно можно разделить на следующие этапы:

1. Чанкинг.

2. Преобразование чанков в LangChain Documents.

3. Векторизация (индексация).

   

Чанкинг текстов законов и судебных решений

Чанкинг (сhunking от англ. chunk «кусок») — автоматическое разделение документов на логически связанные фрагменты. Техника чанкинга — отдельная тема. Здесь отметим, что логика разделения текстов на части должна соответствовать конкретной задаче, а также структуре и связям текстовых данных. Например, длинные юридические нормативные документы логично разбивать на более мелкие, используя в качестве разделителей такие структурные единицы как параграфы, разделы договора, наименование статей законов и т. д. Размер чанка определяется экспериментально, важно чтобы он содержал достаточно контекста, но при этом не был слишком большим.

В качестве автоматического разделителя текста мы использовали посимвольный RecursiveCharacterTextSplitter с нестандартными параметрами, учитывающими особенности юридического текста. Чанкинг текстов судебных решений:

• «режем» на чанки крупного размера, учитывающие синтаксическую структуру текстов;

• «режем» со значительным перекрытием (20%), дабы не потерять значимую информацию;

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

  

В результате обработки текстов на данном этапе также отдельно сохраняем значимые метаданные:

• номер дела,

• дата принятия судебного постановления,

• порядковый номер чанка,

• общее количество чанков для данного документа.

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

На выходе — датафрейм с получившимися текстовыми фрагментами (чанками) и метаданными, хранящимися по ключам словаря в соответствующей колонке:

Чанкинг текстов законов:

• так как тексты законов — наиболее структурированные юридические тексты, уменьшаем размер чанков (1000) и перекрытия (overlap) между ними (200);

• сохраняем наименование обрабатываемых законов в качестве метаданных;

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

Преобразование чанков в LangChain Documents

Далее преобразовываем таблицы с получившимися чанками в список объектов Document, готовых для использования в LangChain

Векторизация (индексация) чанков и пользовательских запросов

Модуль индексации любой RAG‑системы включает 2 основных процесса векторизации:

• векторизация чанков с помощью с помощью модели на основе BERT для векторизации предложений (embedding model) → создание векторного хранилища данных;

• векторизация пользовательского запроса с помощью той же embedding model.

Embedding model: cointegrated/LaBSE‑en‑ru («Language‑agnostic BERT sentence embedding») от Google. Выбор данной модели на этапе Retriever обусловлен несколькими факторами:

• это классический би‑энкодер (Bi‑encoder) со стандартными размерами контекста (512) и эмбеддинга (768);

• доступность, может работать в локальной среде;

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

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

Выбор векторного хранилища. В качестве векторного хранилища мы используем FAISS

FAISS — это библиотека с открытым исходным кодом для поиска сходства и кластеризации плотных векторов, разработанная компанией Facebook.

Наш выбор обусловлен несколькими причинами:

• FAISS — открытый программный продукт, который можно использовать для локальной разработки и экспериментов;

• FAISS может использовать ускорение на GPU;

• бесшовная интеграция с LangChain;

• встроенная возможность сериализации/десериализации индексов, дабы не создавать векторные хранилища каждый раз заново.

Обратим внимание, что два независимых FAISS‑хранилища — practice_db (судебная практика) и law_db (законодательство), создаются на основе одной embedding‑модели, которая возвращает так называемые «плотные» (dense) семантические векторы последовательностей (предложений).

Данные векторные представления позволяют реализовать семантический поиск (dense search). Часто бывает полезным объединить результаты dense search вместе с поиском по ключевым словам (sparse search). Последний основан на известном алгоритме BM25 (Best Match 25) и представляет собой широко используемый алгоритм полнотекстового поиска, основанный на TF‑IDF‑векторизации. В нашем случае это также могло было быть полезно, так как плотные векторы призваны представлять семантику чанков в целом, тогда как поиск ссылок на конкретные объекты (например, статьи законов, индивидуальные номера, имена и фамилии лиц, участвующих в деле и т. д.) может дать результаты с «галлюцинациями» (если, например, плохо отработает модуль поиска системы), поскольку в таких данных мало смысла, который можно было бы отразить в эмбеддингах. Также могут возникнуть сложности с поиском релевантных фрагментов, если эмбеддинги не будут отражать семантику специализированных юридических терминов.

Однако мы не будем здесь реализовывать классический гибридный поиск (dense search + sparse search):

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

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

• забегая немного вперед, скажем, что мы реализуем НЕклассический гибридный поиск, заключающийся во взвешенном ансамблировании «плотных» векторов, извлеченных из различных источников — законов и судебной практики;

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

Архитектура RAG‑системы

Архитектура RAG‑системы состоит из следующих модулей и подмодулей:

1. Индексация (Indexing): подробно рассмотрена выше, в рамках этапа предобработки данных.

2. Поиск (Retrieval):

   1. LLM + Query Prompt для генерации мультизапросов.

   2. Embedding model для векторизации запросов.

   3. Векторные хранилища: Law Vector Database, Practice Vector Database на рис.4.

   4. Базовые ретриверы: Practice Retriever, Law Retriever на рис. 4.

   5. Ансамблирование базовых ретриверов: Ensemble Retriever на рис. 4.

   6. MultiQueryRetriever поверх EnsembleRetriever + Custom RRF на рис. 4.

3. Генерация (Generation):

   1. LLM + User Prompt на рис.4.

   2. Запуск итоговой цепочки, включая:

      — форматирование вывода: Formatting Answer на рис. 4.

   3. Вывод ответа в соответствии с параметрами пользователя.

   

   Архитектура основана на семантическом ансамблировании результатов поиска с помощью dense‑ретриверов, обращающихся к хранилищам источников знаний (законов и судебной практики):

   1. сначала мы совмещаем два независимых dense‑поиска по разным доменам (каждому домены — свои индексы и свое векторное хранилище) и с разными стратегиями извлечения (оптимизация параметров поиска отдельно для каждого домена);

   2. далее — применяем взвешенное ансамблирование, и на выходе объединяем результаты с помощью алгоритма RRF.

Базовые ретриверы

Оба ретривера используют алгоритм MMR (Maximum Marginal Relevance) — это техника, используемая для извлечения релевантных элементов запроса при одновременном предотвращении избыточности (both relevant and diverse). Кратко суть алгоритма заключается в том, что он позволяет минимизировать количество семантических дубликатов в результатах поиска:

1. Сначала мы выбираем наиболее релевантный документ (на основе косинусного расстояния между соответствующими векторами).

2. Затем мы итеративно выбираем документ, который даёт максимальный показатель MMR (наиболее релевантный и наиболее непохожий на уже выбранные нами документы).

3. Делаем до тех пор, пока не выберем необходимое количество документов.

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

Подробнее об алгоритме и его реализации можно почитать здесь: https://docs.llamaindex.ai/en/stable/examples/vector_stores/SimpleIndexDemoMMR/

Разные ретриверы — разные параметры поиска.

Пороговое значение оценки сходства (score_threshold) и количество top‑k документов (k) для поиска по разным доменам соответственно различны:

• Практика: k=5, threshold=0.2 (больше практики, «мягче» фильтр);

• Законы: k=3, threshold=0.7 (меньше законов, «жестче» фильтр).

Значения указанных параметров подобраны эмпирически и обусловлены, во многом, тем, что:

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

• при этом в законах немного релевантной информации, поэтому параметр k ограничен 3 документами;

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

Ансамблирование базовых ретриверов и ранжирование результатов поиска

Используем класс EnsembleRetriever (специальный объект из библиотеки LangChain, который позволяет объединять результаты нескольких поисковых алгоритмов и переранжировать их с помощью алгоритма Reciprocal Rank Fusion), который позволяет произвести взвешенное ансамблирование и переранжирование топовых результатов базовых ретриверов:

Общая идея заключается во взвешенном объединении top‑k результатов поиска по указанным БД:

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

  • 70% — судебной практике;

  • 30% — законам;

• далее к результатам поиска применяется алгоритм ранжирования RRF.

В дальнейшем нам понадобится общее понимание работы этого алгоритма, поэтому рассмотрим его более подробно.

Применение алгоритма RRF в Ensemble Retriever

1. Для каждого документа в каждом наборе результатов поиска по данному запросу вычисляется RRF‑score по формуле:

RRF_score = 1.0 / (rank + k),

где rank — позиция документа в конкретном ретривере, k — константа (обычно — 60)

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

2. RRF‑оценки для каждого документа в разных наборах результатов затем суммируются для получения итоговой оценки. В нашем случае суммируются взвешенные оценки документов для каждого ретривера. Таким образом, выполняется взвешенное объединение top‑k docs (k задается при инициализации базовых ретриверов), условно:

weighted_RRF = 0.3  RRF_law + 0.7  RRF_practice,

где RRF_law и RRF_practice — RRF‑оценки результатов поиска базовых ретриверов

3. Элементы (документы) сортируются по этим итоговым оценкам для формирования комбинированного списка результатов.

Рассмотрим указанные шаги на примере

Шаг 1: Запрос в БД ? получаем MMR‑scores from law retriever и practiceretriever

Шаги 2, 3: RRF c весами ? top‑k проранжированных результатов поиска по БД

Добавляем вариации исходного запроса: MultiQueryRetriever поверх EnsembleRetriever

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

Что делать?

Наше решение — генерировать близкие по смыслу запросы, которые, возможно, дадут большее покрытие релевантных документов. Данный метод известен как multi‑query rewriting. Его суть состоит в том, что пользовательский вопрос переформулируется разными способами, затем поиск выполняется по каждому переформулированному варианту, а результаты объединяются, исключая дубли.

Воспользуемся функционалом специального класса из библиотеки LangChain — MultiQueryRetriever, который в качестве параметра принимает объект EnsembleRetriever, а также llm‑chain — цепочку, которая задает порядок генерации мультизапросов:

В данном примере мы просим нашу модель сгенерировать 2 варианта вопроса, сохраняя исходный. Результат инициализации llm‑chain может быть таким:

Есть проблема!
Класс MultiQueryRetriever сам по себе не выполняет переранжирование (reranking) документов, поученных от разных подапросов.

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

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

Предложенное нами решение состоит в последовательной реализации следующих шагов:

1. Сохраняем ранги результатов поиска для каждого подзапроса:

1. получаем документы через EnsembleRetriever, вокруг которого «обернут» MultiQueryRetriever с помощью retriever.invoke()

2. для каждого документа:

• создаем уникальный ID;

• сохраняем ранг документа для текущего подзапроса;

• сохраняет текст и метаданные документа (при первом обнаружении)

  2. Интегрируем логику RRF: для каждого документа вычисляет взвешенную RRF‑оценку:

1. задаем веса: 0.7 для «practice», 0.3 для «law»;

2. реализуем в коде формулу: score += weight * (1.0 / (rank + k_rrf)).

   3. Сортировка и вывод результатов — сортируем документы по убыванию RRF‑оценки.

   4. Интеграция в итоговую цепочку LangChain.

Модуль генерации

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

Генератор

Исходя из соотношения цена‑качество, размера контекстного окна, «спортивного интереса» и других субъективных критериев, для эксперимента решили использовать модель GPT-4o‑mini (в нашем эксперименте не требуется локальный запуск) с параметрами:

• temperature=0.1,

• max_tokens=270.

Кастомные юридические промпты

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

Форматированный вывод

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

Итоговая RAG‑цепочка состоит из 4-х параллельных веток, которые позволяют: (1) контролировать результаты реранкинга после MultiQueryRetriever, (2) возвращать отформатированные ответы, (3) возвращать использованный контекст, (4) возвращать список извлеченных документов для последующей оценки системы с помощью фреймворка RAGAS.

Добавляем пользовательский интерфейс с помощью Gradio

Модель выдала юридическое заключение:

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

Пользователь может управлять выводимым контекстом — использованными для ответа источниками. Для этого достаточно поставить «галочку».:

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

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

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

Зададим модели другой вопрос, указав опцию — «подготовка к суду»:

---

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

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

Все программы и подробности можно найти в каталоге курсов.