Привет, Хабр! Меня зовут Екатерина, я практикующий инхаус-юрист с фокусом на IT, IP и рекламе. Недавно я начала экспериментировать с технологией Retrieval-Augmented Generation и векторным поиском в юридических задачах, а также исследовать архитектурные подходы к построению баз знаний в юриспруденции. Этот материал — обзор трёх публикаций о способах построения таких баз, а также моя попытка начать формулировать методологию структурирования юридического знания для RAG. Буду признательна за любой инпут со стороны  ML-специалистов.

Небольшой бэкграунд

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

О RAG я узнала благодаря сообществу юристов-энтузиастов ИИ Нейросети | ilovedocs, и мне захотелось реализовать эту технологию в хорошо понятной мне области. Я сделала небольшой полностью некоммерческий проект, а именно Telegram-бота «А юристы смотрели?». Он умеет проверять содержательную часть рекламных креативов на соответствие ФЗ «О рекламе» с помощью API-запросов в нейросеть с небольшой курированной базой знаний, состоящей из решений Федеральной антимонопольной службы по рекламным делам. RAG реализован самым простым способом: семантический поиск по косинусному сходству в базе однородных эмбеддингов, хранящихся в формате NumPy (записей там немногим меньше двух тысяч, поэтому и хранилище самое простое). 

Этот метод в целом очень неплох для той не самой сложной задачи, которую решает бот, но даже в её рамках далеко не совершенен, несмотря на работу по предварительной оптимизации текстов решений ФАС (с помощью нейросети я размечала решения, а эмбеддинги делала для резюме спора, аргументов регулятора и прямых цитат). Я пытаюсь это преодолевать, например, в качестве «костыля» в боте ставлю задачу нейросети критично относиться к тому, что в RAGе нашлось, и просто ничего не цитировать, если чего-то релевантного в выдаче не было. 

Работая над своим проектом, я осторожно думала, что базы, состоящие из огромного количества сырых необработанных текстов (иногда можно встретить утверждения о legaltech-проектах с базами из миллионов текстов) — это не самый  оптимальный путь, он не может не понижать качество ретривинга. Так дизайнить базы знаний не то чтобы нельзя… можно, но это не застрахует от ошибок другого типа и не повысит точность драматически. А ещё просто замусорит контекстное окно и принесёт пугающий счёт за токены. И вообще у меня проснулся огромный интерес к теме возможных стратегий и методов построения баз для юридических задач, в связи с чем я начала активно исследовать этот вопрос, формулировать первые базовые принципы работы по созданию баз знаний и вообще много размышлять о будущем юридического знания.

Результатами первых шагов в своих исследованиях и возникшими в связи с этим идеями хочу поделиться и здесь: будущее юристов явно будет всё теснее и теснее связано с миром IT.  

Flat RAG и его ограничения в юридических задачах

Главная проблема «наивных» RAG-баз из однородных (flat) эмбеддингов состоит в том, что такие системы не учитывают иерархичность источников — ни внутри источника, ни в соотношении между несколькими. Flat RAG не в состоянии «увидеть» большую картину и «планы» этой картины. 

К чему это может приводить: 

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

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

• Отслеживание изменений во времени в принципе невозможно. Даже если в плоской базе знаний будут разные версии закона, с какой вероятностью поиск по базе вернет нужные? Ведь векторные представления немного разных версий одного и того же будут максимально близки друг к другу по сравнению с остальными чанками. 

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

Неожиданностью для меня стало то, что тему RAG в юридическом домене активно исследуют и экспериментируют с ней специалисты в Сенате Бразилии. Менее года назад г-н João Alberto de Oliveira Lima опубликовал статью Unlocking Legal Knowledge with Multi-Layered Embedding-Based Retrieval, в которой представил многоуровневый подход к подготовке эмбеддингов и извлечению информации в нормативных документах.

Multi-Layered Embedding-Based Retrieval (далее — MLR)

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

Технически это реализовано так:

I - Каждый структурный элемент = самостоятельный чанк (часть текста, преобразуемая в эмбеддинг). Вместо простого разделения текста на куски по количеству токенов, документ разбирается в соответствии с его формальной структурой (разделы, главы, статьи, пункты, подпункты).

II - Для каждого выделенного структурного элемента создается свой эмбеддинг. Таким образом, в базе знаний хранятся эмбеддинги для:

• всего документа (Document Level);

• крупных разделов (Basic Unit Hierarchy Level, например, главы);

• основных единиц (Basic Unit Level, например, статьи);

• частей статей (Basic Unit Component Level, например, абзацы);

• перечислений (Enumeration Level, например, пункты и подпункты).

III - Контекстное обогащение. При создании эмбеддинга для дочернего элемента (подпункта) его текст объединяется с текстом родительского элемента (пункта/статьи), чтобы сохранить семантический контекст.

IV - На этапе ретривинга релевантные фрагменты выбираются на основе того же самого косинусного сходства, но применяется фильтрация по: 

• лимиту токенов (например, базовое ограничение — 2500 токенов);

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

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

После отбора минимум 7 сегментов процесс продолжается до превышения лимита токенов или падения сходства ниже порога.

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

• MLR позволяет извлекать больше релевантных (essential) чанков (≈37.86% от всех выбранных, тогда как flat-метод – ≈16.39%). 

• MLR снижает долю «шумных» (unnecessary) чанков — ≈58.25% (flat-метод — ≈75.41%). Это уменьшает объем ненужной информации в выдаче и делает контекст для LLM более чистым.

• MLR даёт около 3.88% дополнительных (complementary) чанков, flat-метод — 8.20%. Это говорит о большей точности границ релевантности. 

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

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

• При генерации нейросетью ответов с применением MLR выявляется больше специфичных пунктов нормативного акта, важных для ответа, чем при flat-методе, особенно при сложных или многоаспектных вопросах.

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

GraphRAG

Кажется, что RAG и граф были созданы друг для друга и ждали встречи. В феврале этого года команда из Microsoft представила статью From Local to Global: A GraphRAG Approach to Query-Focused Summarization, в которой рассказала о графовых RAG (GraphRAG), представляя их как архитектурный сдвиг от локального поиска к глобальному и всестороннему осмыслению (sensemaking) больших массивов текста. 

Графовый RAG превосходит векторный RAG в задачах, требующих обобщения и синтеза, понимания взаимосвязей и высокоуровневого анализа, то есть система может предоставить «вид с высоты птичьего полета» на весь набор данных. Кроме того, графовые RAGи по подсчётам авторов значительно экономят токены — до 97–98% (например, для новостного корпуса — 39,770 против 1,707,694 токенов). Вместо того чтобы загружать в контекст модели большие объемы сырого текста, семантически схожего с запросом, GraphRAG предполагает эмбеддинги для сообществ сущностей и предварительное создание компактных самиари-отчётов для таких кластеров сущностей. 

Но и это не предел. Как ещё можно углубить и улучшить RAG-систему? Нам, юристам? Ответ опять-таки придумали исследователи из Сената Бразилии. 

Structure-Aware Temporal Graph RAG (далее — SAT-Graph)

Достаточно недавно, 11 сентября, г-н Hudson de Martim опубликовал статью An Ontology-Driven Graph RAG for Legal Norms: A Structural, Temporal, and Deterministic Approach, в которой представляет структурно-темпоральный подход к созданию графовых RAG (Structure-Aware Temporal GraphRAG). Главное отличие от просто графового RAG в том, что в структуре RAG добавляется временное изменение. Это делает возможным детерминированное извлечение на конкретный момент во времени (Point-in-Time Retrieval), то есть система может безошибочно ответить, как выглядел закон в любую заданную дату в прошлом, а также может отследить всю цепочку законодательных изменений, которые повлияли на конкретную норму. 

Практиковали опять же на Бразильской Конституции: 

I - Структура нормативного акта как основа графа (Structure-Aware компонент). Вместо извлечения семантических сущностей, как в GraphRAG, вершинами графа стали сами структурные элементы конституции (главы, статьи, пункты). В сущности это рассмотренный выше MLR-подход.

II - Темпоральное моделирование графа (Temporal компонент). Каждая поправка к Конституции не перезаписывает соответствующую вершину графа, а создает для них новые временные версии. Сами законодательные акты, которыми вносятся изменения в Конституцию, также моделируются как самостоятельные вершины типа «action». Эти вершины связывают старую версию статьи (которую они отменяют) и новую версию (которую они создают).

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

• Извлечение становится детерминированным и проверяемым. Только такой подход позволяет гарантированно получить текст нормы в состоянии, действовавшем в определённую дату. Flat RAG на однородных чанках могут некорректно отвечать на вопросы о том, как норма была сформулирована в 1999 году, выдавая анахронистичные или ошибочные результаты. 

• Благодаря использованию формальной, иерархической структуры закона (разделы, статьи и т. д.), система поддерживает сложные запросы по структуре, например, поиск всех изменений в конкретной главе или анализ влияния поправок по вершинам и дочерним элементам. Для «обычных» GraphRAG граф строится только на сущностях, теряя ключевые юридические зависимости, так как позиция нормы определяет её смысл и применимость. Здесь не могу полностью согласиться, так как графовый RAG по дизайну технологии никак не ограничивает пользователя в том, что брать за сущности/вершины.

• SAT-Graph RAG умеет показывать причинно-следственные взаимосвязи, а flat RAG не обеспечивают прозрачного и воспроизводимого анализа происхождения изменений. 

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

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

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

Выводы и размышления

Мой главный инсайт из этих первых шагов или ключевые принципы вырисовывающейся методологии построения RAG-систем в юридическом домене: 

Более сложный метод — не значит лучший применительно к конкретной задаче. 

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

Примеры возможных областей применения разных вариантов реализации технологии: 

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

• Иерархический RAG — для точного анализа структурированных документов, таких как договоры, сложно структурированные сделки или нормативные акты.

• Графовый RAG — для обнаружения неочевидных связей в больших и разнородных массивах данных: исследования, расследования, due diligence, управление холдингами.

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

В связи с этим у меня также появилось несколько гипотез о будущем:

• Варианты улучшения технологии развиваются просто стремительно, даже в нашем консервативном домене. Я узнала о том, что вообще есть такая технология в июне, в июле реализовала свой flat RAG, и похожих кейсов от своих коллег вижу считанное количество (могу, конечно, о чём-то и не знать). Тогда как ещё в прошлом ноябре в Бразилии экспериментировали с иерархическим, а уже в этом сентябре освоили появившийся в феврале графовый и дополнили его темпоральным измерением (а вообще пока я писала эту статью, впервые опубликованную в моём Telegram-канале в середине октября, кто-то и вовсе успел похоронить RAG). И это, разумеется, не единственные проекты и не единственные методы улучшения качества поиска в RAG-системах.

• Думаю, что в юридическом домене за этим будущее. Нам нужны RAG на корпоративном, правоприменительном, законодательном и академическом уровнях. Возможно, что кафедры юридических университетов займутся созданием RAGов по отраслям права, государство — по НПА, компании будут делать свои локальные-кастомные под свои задачи, стартапы будут предлагать методики, услуги по дизайну кастомных баз и пакетные решения. Будут библиотеки баз знаний, а справочно-правовые системы могут занять нишу достоверных и обновляемых RAG-систем.

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

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