Графы знаний в юридическом домене: как не потерять сложность при построении RAG-системы

• разберем возможности и ограничения графовых RAG-систем по сравнению с классическими, векторными, а также

• создадим базу и задел для разбора в следующей публикации практического кейса - как оперативно построить RAG-систему в сфере недвижимости с помощью популярного фреймворка LightRAG.

Эксперименты с классическим векторным RAG в юридической предметной области

Ранее, в статье – Law & Practice Ensemble RAG. Как создать ассистента, помогающего решать многоаспектные юридические задачи, опубликованной в блоге компании OTUS, мы подробно разобрали:

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

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

Несмотря на то, что нам удалось достичь неплохих результатов на поддомене, связанном с регулированием недвижимого имущества, при попытке масштабирования системы на мультидоменные задачи (как юридические – например, включение в базу знаний норм из других отраслей права, так и внешние – например, финансовые, кадровые и проч.) или задачи, где необходимо учитывать различные отношения и связи отдельных сущностей с другими сущностями (например, темпоральность: учесть, что ФИО одновременно включен в проект А и проект Б, а проект С, в который он был включен ранее, уже неактуален), ее качество, скорее всего, окажется недостаточным для эффективного практического применения.

RAG и графы знаний: мотивация использования в юридическом домене

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

Если в векторных базах данных (БД) данные хранятся в виде многомерных векторов (эмбеддингов), в графовых БД для хранения самих данных и связей между точками данных используется структура графа, где узлы-объекты соответствуют этим точкам (или их сообществам), а рёбра – отношениям между ними.

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

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

Ограничения и возможности поиска по графу знаний в RAG-системе

Основные ограничения RAG-систем, основанные исключительно на VDB, связаны с особенностями векторного поиска, а точнее – построения векторного пространства (результат векторизации текстов), в котором осуществляется поиск:

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

поиск в VDB по векторизованному запросу пользователя, упрощенно говоря, сводится к подсчету расстояния [с помощью косинусного расстояния или др. метрики] между вектором запроса пользователя и векторами в VDB, последующему ранжированию полученных top-k результатов и тп.

Очевидны ограничения такого подхода:

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

2. Семантическая "размытость" векторизованных чанков и запросов (Context Collapse): чанки и запросы отображаются в векторы одного и того же размера – [1 * n], где n – размер вектора, который, как правило, не может уловить ни тонкие отличия между сущностями внутри текстового фрагмента, ни связи между объектами, что приводит к непреодолимой смысловой неточности обрабатываемого контекста.

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

4. Семантически близкие векторные представления чанков могут содержать противоречивые сведения: например, несколько чанков, содержащих информацию о целевом объекте – объекте судебного спора, относительно которого различными судебными инстанциями были сделаны разные выводы, в одномерном векторном представлении будут являться очень близкими (без возможности выявления связей между этими инстанциями и иерархии судов в судебной системе RAG-система, скорее всего, будет "галлюцинировать").

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

6. Слабая интерпретируемость данных на "выходе" системы: мы можем понять, на основании каких текстовых фрагментов система сделала выводы, однако в отсутствие явно представленных связей между сущностями логика принятия решения останется от нас скрытой.

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

1. В KGDB данные встраиваются в топологию графа и хранятся явно, например, в виде RDF-триплетов (атомарные смысловые сущностей вида "субъект – предикат – объект"), которые позволяют представить множество связей между парами сущностей в обрабатываемом текстовом фрагменте (у каждой сущности есть свои наименование, тип и атрибуты).

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

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

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

При этом ограничения и сложности, которые может породить использование графовых БД также очевидны:

1. Качество графа напрямую зависит от LLM, используемой для построения графа, и ее настроек:

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

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

2. Проблемы, связанные с неполнотой и неточностью извлеченных сущностей и связей:

   1. Один и тот же реальный объект может соответствовать множеству различных узлов, названных по-разному (например, «ГК РФ», «Гражданский кодекс РФ», «Гражданский кодекс России» и тд): в этом случае граф превращается в "зашумленную" сеть из разрозненных синонимичных узлов, что, очевидно, влияет на качество поиска.

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

   3. Если логическая цепочка между фактами в тексте выражена неявно или модель пропустила какое-нибудь отношение при индексации, поисковый алгоритм не сможет "перепрыгнуть" через разрыв в графе, в то время как простой векторный поиск мог бы найти ответ по семантическому сходству;

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

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

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

Когда следует использовать поиск по графу знаний при построении RAG-системы в юридическом домене?

1.Сложная топология данных

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

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

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

2. Важны темпоральность и версионность

Законы, судебные решения и юридические факты "живут" во времени.

• для векторного поиска по VDB фразы, содержащие указание на время действия НПА, например, "редакция от 01.01.2022 года" и "редакция от 01.01.2024 года", семантически почти идентичны;

• в KGDB временная характеристика - это ребро или атрибут узла. Это позволяет успешно находить информацию на запросы с указанием времени, например: "Опиши хронологию судебного процесса, начиная с 2023", - и получать детерминированный ответ (при условии, что эта информация явно присутствует в построенном графе), исключающий из поиска неактуальные, но семантически близкие узлы.

3. Транзитивность и поиск скрытых зависимостей (Multi-hop Reasoning)

Векторный поиск ищет похожее, графовый — связанное:

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

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

4. Наличие в знаниях противоречий, высокие требования к консистентности системы

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

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

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

5. Наличие большого количества перекрестных ссылок в текстах

Тексты законов перегружены конструкциями вида "за исключением случаев, предусмотренных ст. X":

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

• в момент обработки запроса система "подтянет" содержание ст. X, даже если оно находится семантически далеко от запроса пользователя.

6. Требуется учитывать уровень глобального обобщения

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

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

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

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

Вместо заключения

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

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

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

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

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

P.S. 

Спасибо за внимание! Надеюсь, было интересно, готов ответить на вопросы в комментариях.