Ни одна современная AI‑система в юридическом домене сегодня не обходится без Retrieval Augmented Generation (RAG): она должна учитывать во всей глубине и полноте довольно специфичные для LLM юридические данные, которые, скорее всего, не составляли значимую часть выборки во время ее предобучения или SFT (Supervised Fine‑Tuning).
При этом, как правило, модуль Retrieval (поиска) в такой системе основан на векторном поиске, который имеет ряд принципиальных ограничений. Эти ограничения не позволяют в полной мере удовлетворить запросы взыскательных пользователей относительно приемлемого уровня качества. А квалифицированные пользователи в юридической сфере, как правило, взыскательны: цена ошибки может быть очень высока.
Кто я?
Меня зовут Сергей Слепухин. Прикладной лингвист и DS с фокусом на юридическом домене: исследую правовую область знаний и решаю практические задачи в этой сфере.
План статьи
разберем возможности и ограничения графовых RAG-систем по сравнению с классическими, векторными,
дадим обзор наиболее популярных и интересных (субъективно) фреймворков для автоматического построения графов знаний, а также
создадим базу и задел для разбора в следующей публикации практического кейса - как оперативно построить RAG-систему в сфере недвижимости с помощью популярного фреймворка LightRAG.
Эксперименты с классическим векторным RAG в юридической предметной области
Ранее, в статье – Law & Practice Ensemble RAG. Как создать ассистента, помогающего решать многоаспектные юридические задачи, опубликованной в блоге компании OTUS, мы подробно разобрали:
принципиальные ограничения и риски использования как «чистых» LLM, так и базовых («ванильных») RAG‑систем в юридическом домене,
а также каким образом можно улучшить RAG-систему с помощью разделения векторных индексов и ретриверов по поддоменам (законов + судебной практики), а также последующего ансамблирования извлеченных фрагментов посредством RRF-алгоритма и др.
Несмотря на то, что нам удалось достичь неплохих результатов на поддомене, связанном с регулированием недвижимого имущества, при попытке масштабирования системы на мультидоменные задачи (как юридические – например, включение в базу знаний норм из других отраслей права, так и внешние – например, финансовые, кадровые и проч.) или задачи, где необходимо учитывать различные отношения и связи отдельных сущностей с другими сущностями (например, темпоральность: учесть, что ФИО одновременно включен в проект А и проект Б, а проект С, в который он был включен ранее, уже неактуален), ее качество, скорее всего, окажется недостаточным для эффективного практического применения.
RAG и графы знаний: мотивация использования в юридическом домене
Часть принципиальных ограничений векторных RAG-систем, которые принято называть "наивными" или "классическими", уже сегодня можно решить с помощью построения модуля поиска, основанного на графах знаний.
Если в векторных базах данных (БД) данные хранятся в виде многомерных векторов (эмбеддингов), в графовых БД для хранения самих данных и связей между точками данных используется структура графа, где узлы-объекты соответствуют этим точкам (или их сообществам), а рёбра – отношениям между ними.
Аналитически юридическую область знаний можно представить как постоянно меняющуюся систему сложных взаимосвязей между иерархически организованными сущностями: законами, подзаконными актами, статьями, судами, конкретными персонами и прочими категориями, терминами, понятиями и иными сущностями, которые могут быть описаны как объекты (узлы) графа.
То есть, на первый взгляд, кажется, что в таких сложно устроенных предметных областях, как юридическая, хранение знаний в виде графа, в целом, является разумной альтернативой векторной базе данных. Однако нужно быть аккуратным: вместо одних сложностей можно получить другие, даже бОльшие, без улучшения значимых метрик системы, основанной на понятном векторном поиске.
Ограничения и возможности поиска по графу знаний в RAG-системе
Введем обозначения
В дальнейшем векторные хранилища обозначим как VDB (Vector DataBase), графовые – как KGDB (Knowledge Graph DataBase).
Основные ограничения RAG-систем, основанные исключительно на VDB, связаны с особенностями векторного поиска, а точнее – построения векторного пространства (результат векторизации текстов), в котором осуществляется поиск:
точки, находящиеся близко в многомерном пространстве, соответствуют близким по смыслу токенам ("словам"), расстояние между точками – характеристика их семантической близости;
поиск в VDB по векторизованному запросу пользователя, упрощенно говоря, сводится к подсчету расстояния [с помощью косинусного расстояния или др. метрики] между вектором запроса пользователя и векторами в VDB, последующему ранжированию полученных top-k результатов и тп.
Очевидны ограничения такого подхода:
Потеря связей в тексте при векторизации чанков (на которые этот текст был "разрезан" в ходе предобработки): в сложных текстах связи неравномерно представлены на разных уровнях, и их невозможно точно "поймать" при любой, даже семантической "нарезке" текста, к которому сводится разделение на чанки.
Семантическая "размытость" векторизованных чанков и запросов (Context Collapse): чанки и запросы отображаются в векторы одного и того же размера – [1 * n], где n – размер вектора, который, как правило, не может уловить ни тонкие отличия между сущностями внутри текстового фрагмента, ни связи между объектами, что приводит к непреодолимой смысловой неточности обрабатываемого контекста.
Асимметрия между размерами коротких запросов и длинных чанков: эмбеддинги запроса и эмбеддинги VDB в связи с одинаковой размерностью векторов получаются разными по плотности (насыщенности), что также приводит к снижению точности.
Семантически близкие векторные представления чанков могут содержать противоречивые сведения: например, несколько чанков, содержащих информацию о целевом объекте – объекте судебного спора, относительно которого различными судебными инстанциями были сделаны разные выводы, в одномерном векторном представлении будут являться очень близкими (без возможности выявления связей между этими инстанциями и иерархии судов в судебной системе RAG-система, скорее всего, будет "галлюцинировать").
Векторный поиск, сам по себе, не способен улавливать логические связи между извлеченными чанками: например, документы (регламенты, правила и тп), содержащие схожие по смыслу сведения, могут иметь различное назначение, которое не будет учтено при векторном поиске, поскольку у системы отсутствует информация об иерархии таких документов или иных связей между ними.
Слабая интерпретируемость данных на "выходе" системы: мы можем понять, на основании каких текстовых фрагментов система сделала выводы, однако в отсутствие явно представленных связей между сущностями логика принятия решения останется от нас скрытой.
Графовые БД позволяют, в той или иной степени, преодолеть указанные ограничения наивных RAG-систем:
В KGDB данные встраиваются в топологию графа и хранятся явно, например, в виде RDF-триплетов (атомарные смысловые сущностей вида "субъект – предикат – объект"), которые позволяют представить множество связей между парами сущностей в обрабатываемом текстовом фрагменте (у каждой сущности есть свои наименование, тип и атрибуты).
Логическая структура графов, формально описывающая семантику отношений между объектами, позволяет:
осуществлять глубокое исследование связей между абстрактными понятиями, терминами и отдельными сущностями в домене за счет анализа топологии графа: например, анализ центральных узлов, наличия в графе изолированных компонент или одиночных вершин, "мостов" между вершинами, обеспечивающими целостность графа, наличие кластеров – связных компонент, а также связности, плотности графа и других метрик, может многое сказать о качестве собранной выборки данных или об устройстве исследуемой предметной области;
извлекать скрытые знания, недоступные векторному поиску: например, язык RDF основан на математическом аппарате дескрипционной логики, соответственно, логический вывод по ребрам графа позволяет восстанавливать транзитивные связи и классифицировать объекты на основе их свойств, превращая разрозненные факты в дедуктивную систему, где ответ на запрос формируется не по внешнему сходству векторов, а на основе явно описанной и формально представленной семантики.
При этом ограничения и сложности, которые может породить использование графовых БД также очевидны:
Качество графа напрямую зависит от LLM, используемой для построения графа, и ее настроек:
Фреймворки (самый популярный на сегодняшний день – GraphRAG от Microsoft) для построения графовых индексов имеют множество предварительных настроек: от системных промптов, задающих логику и направление по извлечению сущностей и отношений, до итеративных алгоритмов, которые обеспечивают плотность и логическую связность графа.
Однако несмотря на эти настройки, пока ни один фреймворк не может гарантировать полное и точное описание представленных в тексте сущностей и связей между ними: статистические паттерны, усвоенные любыми LLM – это всегда неопределенность.
Проблемы, связанные с неполнотой и неточностью извлеченных сущностей и связей:
Один и тот же реальный объект может соответствовать множеству различных узлов, названных по-разному (например, «ГК РФ», «Гражданский кодекс РФ», «Гражданский кодекс России» и тд): в этом случае граф превращается в "зашумленную" сеть из разрозненных синонимичных узлов, что, очевидно, влияет на качество поиска.
Жесткость извлечённой структуры отношений между вершинами графа: если у графа нет информации об отношении, которое очевидно присутствовало в тексте, однако не было выявлено при построении графа, система ничего о нем знать не будет, в то время как простой векторный поиск смог бы найти ответ по семантическому сходству.
Если логическая цепочка между фактами в тексте выражена неявно или модель пропустила какое-нибудь отношение при индексации, поисковый алгоритм не сможет "перепрыгнуть" через разрыв в графе, в то время как простой векторный поиск мог бы найти ответ по семантическому сходству;
Высокая вычислительная сложность построения графов: процесс автоматического извлечения сущностей и отношений обходится значительно дороже и происходит медленнее, чем простая векторизация текстовых фрагментов.
Проблема масштабирования запросов: при увеличении глубины обхода графа (количества переходов между узлами) количество извлекаемой информации растет экспоненциально, что приводит к переполнению контекстного окна 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), сначала сгруппируют релевантные узлы в кластеры, сформируют резюме для каждого кластера и лишь затем сгенерируют ответ;
это достаточно эффективный способ избежать так называемого "контекстного коллапса" при масштабировании системы на десятки тысяч документов из разных поддоменов.
Обзор фреймворков для автоматического построения графов знаний
На сегодняшний день существует достаточно много фреймворков, которые позволяют автоматически построить граф знаний из неструктурированных текстов с помощью LLM и использовать его как основу для поиска. Принципиальные различия между ними определяются, в целом, ответами на два вопроса: как именно строится граф и как по нему ведётся поиск.
LlamaIndex
Прежде чем перейти к специализированным фреймворкам, отдельно рассмотрим LlamaIndex – популярный оркестровый инструмент, который, помимо прочего, позволяет строить графы знаний.
LlamaIndex (Jerry Liu, 2022; PropertyGraphIndex, активное развитие с 2024)
LlamaIndex позволяет построить граф знаний поверх любой графовой СУБД (Neo4j, Nebula Graph и др.) с помощью модуля PropertyGraphIndex, который предоставляет разработчику предзаданные классы экстракторов на выбор для различных сценариев работы:
SimpleLLMPathExtractor: свободное LLM-извлечение сущностей и отношений без предзаданной схемы, дефолтный;SchemaLLMPathExtractor: извлечение строго в рамках заранее заданной онтологии;ImplicitPathExtractor: автоматическое извлечение метаданных из структуры файлов и документов, а также путей к ним → обогащение узлов графа атрибутами без обращения к LLM;DynamicLLMPathExtractor: динамическое извлечение в соответствии с заданным списком разрешенных типов сущностей и типов связей: при этом LLM работает по agile, то есть список – некий ориентир, который не дает гарантию извлечения именно предзаданных типов.
LLM с помощью указанных экстракторов извлекает из документов сущности и отношения в виде триплетов: "субъект → предикат → объект", которые записываются непосредственно в графовую БД.
Настраиваемые параметры поиска. В частности, можно выбрать режим Hybrid, который совмещает векторный поиск и графовый о��ход, запуская их параллельно и объединяя результаты.
Ограничения и особенности: LlamaIndex – именно оркестровый фреймворк, а не специализированная система / метод извлечения знаний в виде графа. Он максимально гибок, но перекладывает на разработчика все онтологические решения и сборку итогового пайплайна.
5 фреймворков для автоматического построения графов знаний
Кратко рассмотрим 5 наиболее популярных и интересных (субъективно) фреймворков для автоматического построения графов знаний в хронологическом порядке их появления.
GraphRAG (блог Microsoft Research, 13 февраля 2024; Github⭐: 31.6k, Fork: 3.3k) – наиболее популярный и хронологически первый полноценный фреймворк для автоматического построения графа в контуре RAG-системы.
Построение графа
LLM несколько раз проходит по каждому чанку, руководствуясь инструкциями из системного промпта, извлекая сущности (имя, тип, описание) и отношения (источник, цель, описание, числовой вес связи), каждый узел и ребро снабжаются развёрнутыми текстовыми описаниями.
Алгоритм Leiden разбивает полученный граф на иерархические сообщества (Communities) узлов, для каждого из которых LLM заранее генерирует краткое текстовое описание (Community Summaries).
Поиск представлен в двух режимах:
Local: сущности запроса сопоставляются с узлами графа, извлекаются ближайшие сообщества и их описания;Global: map-reduce по всем Community Summaries: для каждого Summary генерируется частичный ответ с оценкой полезности, затем эти частичные ответы ранжируются и объединяются в итоговый ответ.
Ограничения и особенности:
На сегодняшний день по-прежнему является лучшим фреймворком на задачах глобального тематического синтеза (QFS).
Индексация обходится очень дорого (~$6–7 / 32 000 tokens на GPT-4o, данные на начало 2025).
Отсутствует возможность инкрементальных обновлений (при добавлении в БД новых знаний индекс графа необходимо пересчитывать заново).
Отсутствует возможность явной дедупликации сущностей (один и тот же объект с различными наименованиями может существовать как несколько разных узлов).
В дальнейшем было создано несколько оптимизированных версий, в попытках преодолеть указанные ограничения, наиболее известные:
nano-graphrag - облегченная версия оригинального пайплайна Microsoft Research;
fast-graphrag: принципиальное отличие – использование динамического алгоритма Personalized PageRank (PPR) вместо статичного Leiden алгоритма, что позволяет кратно снизить расходы на индек��ацию графа.
LightRAG (HKUDS, Университет Гонконга, октябрь 2024, Github⭐: 29.4k, Fork: 4.2k)
Построение графа
LLM извлекает из каждого чанка сущности (имя, тип из конфигурируемого списка, заданного изначально в системном промпте, краткое описание) и отношения (источник, цель, ключевые слова отношения, краткое описание).
Для каждой сущности и каждого отношения выполняется так называемое "профилирование" – генерация с помощью специальной функции пары {key : value}, где key – имя сущности или ключевые слова отношения, а value - summary, агрегирующее релевантный контекст из чанков.
Значения KV-пар дополнительно векторизуются, таким образом формируется гибридный индекс - "граф + вектор".
Поиск представлен в 5 режимах:
naive(стандартный векторный поиск, без обхода графа),local(поиск по ключевым словам запроса на локальном уровне конкретных сущностей и их непосредственных соседей),global(поиск по ключевым словам запроса на глобальном уровне обобщений),hybrid(local + global),mix(параллельный обход графа на обоих уровнях + векторный поиск, реранкинг и объединение результатов).
Ограничения и особенности:
Из всех рассмотренных фреймворков LightRAG наиболее прост в запуске, так как поставляется с готовым LightRAG Server (WebUI + API из "коробки"), поддерживает one-click деплой через платформу Railway без ручной настройки Docker и конфигурации сервера; для локального запуска достаточно CPU. Для сравнения: KAG, рассмотренный ниже, требует Docker Compose с несколькими контейнерами и настройки стека TuGraph-DB; GraphRAG не имеет встроенного сервера; HiRAG и проч "молодые" проекты, в целом, не имеют развитой экосистемы.
LightRAG в режиме
mix– один из двух лидеров (примерно наравне с ним – LlamaIndex в режимеHybrid) по точности (метрика answer_accuracy, RAGAS) на единственном на сегодняшний день специализированном бенчмарке на юридических документах (ISWC RAGE-KG 2025 ).Возможность автоматической дедупликации сущностей (на уровне точного совпадения имени).
Возможность инкрементального обновления графа (при обновлении БД не приходится заново индексировать весь ранее обработанный корпус).
Качество графа во многом определяется качеством используемой LLM: слабая модель даёт топологически неполный и "зашумлённый" граф.
KAG (Ant Group / OpenSPG, 24 октября 2024; Github⭐: 8.3k, Fork: 633)
Этот фреймворк отличается от остальных тем, что граф знаний используется не только как основа для поиска, но и как формальная база для дедуктивного рассуждения.
Движок KAG-Solver преобразует запрос на естественном языке в последовательность логических форм - подзапросов, каждый из которых исполняется одним конкретным оператором: поиском по графу, текстовым поиском по чанкам, числовым вычислением или языковым рассуждением.
Если накопленных ответов недостаточно, цикл повторяется с уточняющим запросом. Таким образом, ответ формируется итеративно.
Построение графа
Фреймворк поддерживает два режима извлечения данных:
schema-free: LLM извлекает сущности и отношения по конфигурируемому списку типов, аналогично LightRAG и
schema-constraint: по сути, доменная онтология, на этапе проектирования задаются:
типы сущностей,
допустимые отношения между сущностями,
иерархия,
атрибуты,
правила логического вывода.
Два ключевых отличия от рассмотренных фреймворков:
Mutual Indexing (взаимная индексация): связи между узлами графа и породившими их чанками сохраняются как рёбра в самом графе. Это позволяет системе в процессе рассуждения напрямую обращаться к исходным текстовым фрагментам внутри логической цепочки.
Knowledge Alignment (концептуальное выравнивание):
каждая сущность получает атрибутsemanticType- ссылку на своё место в онтологии концептов домена. Онтология строится на базе дескрипционной логики, что даёт возможность реализовать дедуктивный вывод по иерархии понятий
Поиск
Реализован через KAG-Solver – логически управляемый гибридный движок, работающий итеративно:
Planner декомпозирует запрос на список подзапросов в форме логических выражений.
Reasoner обрабатывает каждый подзапрос, выбирая оператор - поиск по графу, текстовый поиск по чанкам, числовое вычисление или языковое рассуждение.
Judge анализирует накопленные промежуточные ответы, если данных недостаточно, цикл
повторяется с уточняющим запросом.Generator выдает финальный ответ с явным выравниванием по фактам графа; темпоральные отношения и числовая логика поддерживаются нативно и прозрачно (это отличие от всех рассмотренных фреймворков, где подобные задачи остаются на усмотрение LLM).
Ограничения и особенности:
Единственный из рассмотренных фреймворков, изначально спроектированный под профессиональные вертикальные домены (профессиональные области знаний со специфическим языком и иерархически организованной структурой знаний, например, право, медицина, финансы).
Он поддерживает полноценный логический вывод в областях со специфическим языком и иерархически организованной структурой знаний.Высокий порог входа:
а) режим schema-constraint требует предварительного проектирования доменной онтологии, что является очень непростой и самостоятельной исследовательской задачей, которую необходимо решить до запуска системы;
б) развёртывание через Docker Compose с несколькими контейнерами;
в) документация преимущественно на китайском языке.Зависимость от проприетарных технологий (Vendor lock-in): жёсткая зависимость от стека TuGraph-DB (графовая СУБД собственной разработки китайской корпорации Ant Group) / OpenSPG (движок для построения и обработки семантических графов знаний, также от Ant Group).
В отличие от LightRAG, здесь невозможно заменить графовую СУБД через конфигурационный файл. Миграция потребует существенной переработки системы, что критично при требованиях к технологическому суверенитету инфраструктуры.
HippoRAG 2 (OSU NLP Group, февраль 2025; Github⭐: 3.1k, Fork: 316)
Архитектура фреймворка вдохновлена принципами работы долговременной памяти человека, в которой учавствуют неокортекс (LLM: получение и обработка сигналов), парагиппокампальные области (распознавание и связывание близких понятий с помощью PHR-энкодера) и сам гиппокамп (граф знаний, который обеспечивает ассоциативное хранение и поиск по цепочкам связей в графе):
Построение графа
LLM извлекает из чанков сущности и отношения в формате OpenIE-триплетов (Open Information Extraction, без предзаданной схемы).
Отдельный компонент – PHR-энкодер (parahippocampal region) находит семантически близкие объекты (в отличие от LightRAG, который производит дедупликацию только в отношении узлов с полностью совпадающими наименованиями) и объединяет их в один узел, во многом решая проблему дедупликации. Каждый узел также имеет информацию, извлеченную из исходных чанков.
Поиск
Вдохновлён принципом работы гиппокампа - одной из ключевых структур мозга, которая связывает разрозненные воспоминания через ассоциативные цепочки:
извлечение seed nodes: LLM извлекает из запроса пользователя ключевые сущности, которые становятся узлами-якорями (seed nodes);
ранжирование узлов: алгоритм PPR обходит граф, ранжируя все узлы по близости к seed nodes через цепочки связей;
маппинг на текст: найденные релевантные узлы соотносятся с исходными текстовыми фрагментами, которые затем передаются в LLM для генерации ответа;
также дополнительно реализован механизм recognition memory: система "узнаёт" ранее встречавшиеся сущности, улучшая точность ранжирования.
Таким образом, за счет связывания релевантных текстовых фрагментов частично устраняется главный недостаток наивного векторного поиска (!).
Ограничения и особенности:
Согласно данным авторов превосходит GraphRAG и LightRAG по трём измерениям: factual memory, sense-making и associativity (multi-hop поиск), при этом требуя значительно меньше ресурсов на индексацию по сравнению с GraphRAG и LightRAG.
Однако отсутствует встроенный веб-интерфейс и простой деплой, фреймворк ориентирован прежде всего на задачи retrieval, а не на полный RAG-пайплайн "из коробки".
Для юридического домена Open Information Extraction (свободное извлечение сущностей и отношений с помощью триплетов, без предзаданной схемы) может оказаться очень смелым решением. В юриспруденции критичны точность и строгость схем извлечения данных: свободный подход потенциально увеличивает риск ошибок.
HiRAG (EMNLP, март 2025; Github⭐: 519, Fork: 82)
Наиболее молодое ответвление семейства GraphRAG
Построение графа
В отличие от GraphRAG, где иерархия формируется через топологическую кластеризацию ребер алгоритмом Leiden, HiRAG выстраивает иерархию семантически.
Чанки кластеризуются по смыслу через алгоритм Gaussian Mixture Models (GMM) – метода мягкой вероятностной кластеризации векторных представлений.
Каждый кластер получает LLM-summary и становится узлом следующего уровня.
Процесс повторяется рекурсивно, выстраивая иерархию - от конкретных фактов до высокоуровневых тематических обобщений.
Поиск
Реализован одновременно на разных уровнях, без жёсткого разделения на local/global, как в GraphRAG. Дополнительно реализован механизм интеграции знаний с разных уровней иерархии.
Ограничения и особенности:
По данным авторских экспериментов HiRAG превосходит GraphRAG и LightRAG как в задачах глобального тематического синтеза (QFS), так и в multi-hop QA.
Однако фреймворк "молодой", отсутствует развитая экосистема.
Существенный недостаток оригинала (GraphRAG ) сохраняется: отсутствует возможность инкрементальных обновлений графа знаний.
Стоимость индексации существенно выше, чем у LightRAG, - это связанно с необходимостью рекурсивно генерировать summary на каждом уровне иерархии.
Сравнительная итоговая таблица
Фреймворк | Сильные стороны (для домена) | Слабые стороны (для домена) |
LlamaIndex (PropertyGraphIndex) | 1. Возможность гибкой настройки пайплайна с использованием всей экосистемы LlamaIndex. 2. Лидер (наряду с LightRAG) по метрике - answer_accuracy (RAGAS) на бенчмарке ISWC RAGE-KG 2025. | 1. Требуется предварительное проектирование онтологии домена (типов сущностей и допустимых отношений между ними), что является отдельной и непростой исследовательской задачей. 2. Нет готового сервера и встроенного деплоя: пайплайн нужно собирать вручную. |
GraphRAG | Лучший на задачах Query-Focused Summarization (QFS). Например, выявление трендов в судебной практике за прошедший год или обзор судебной практики по конкретной категории споров. | 1. Дорогая индексация ~$6–7 / 32 000 tokens на GPT-4o (данные на начало 2025). 2. Отсутствует возможность инкрементальных обновлений графа, что может быть критично для системы на крупном поддомене, состоящей из постоянно меняющихся законов и судебной практики. 3. Нет автоматической дедупликации. |
LightRAG | 1. Низкая стоимость индексации (в ~30–40 раз дешевле GraphRAG), при сохранении ключевых преимуществ. 2. Поддержка инкрементальных обновлений графа и дедупликации (по точному совпадению наименований узлов). 3. Лидер (наряду с LlamaIndex) по метрике - answer_accuracy (RAGAS) на бенчмарке ISWC RAGE-KG 2025. 4. Самый простой деплой среди всех рассмотренных фреймворков. | Качество построенного графа напрямую зависит от производительности LLM, используемой для его индексации. |
KAG | 1. Интерпретируемость и трассировка рассуждений за счет: (1) управления логическими цепочками через KAG-Solver; (2) Mutual Indexing: прямые связи между узлами и исходными текстовыми фрагментами в самом графе. 2. Встроенная обработка временных отношений и числовых операций (условий), без делегирования этих задач LLM. 3. Семантическая дедупликация с помощью механизма Knowledge Alignment. | 1. Рабочий для юридического домена режим - 2. Vendor lock-in: TuGraph-DB / OpenSPG (Ant Group). 3. Сложный деплой, документация на китайском. |
HippoRAG 2 | 1. Лучший multi-hop reasoning среди рассмотренных. 2. Семантическая дедупликация с помощью PHR-энкодера. 3. Низкие затраты на индексацию (по данным авторов ниже, чем у GraphRAG и LightRAG). | 1. Использование OpenIE без заранее заданной схемы: высокий риск получения "шумного" графа. 2. Отсутствует встроенный веб-интерфейс и простой деплой. 3. Отсутствие production-кейсов на юридических документах. |
HiRAG | По данным авторов фреймворка превосходит GraphRAG и LightRAG на задачах QFS и multi-hop QA . | 1. Отсутствует возможность инкрементальных обновлений графа. 2. Отсутствие production-кейсов на юридических документах. 3. Неразвитость экосистемы, что затрудняет доработку и деплой. |
Если важно провести эксперимент, запустить и потестить прототип, проверить гипотезу на реальных данных в юридическом домене и получить понятные результаты, на мой взгляд, прагматически обоснованным выбором на сегодняшний день является LightRAG в режиме mix.
Аргументы:
сравнительно низкая стоимость индексации;
поддержка инкрементальных обновлений;
высокая точность ответов (answer_accuracy);
простота деплоя;
баланс между функциональностью и удобством использования.
Вместо заключения
RAG-систему с правильно настроенным модулем векторного поиска можно сравнить с хорошо организованной справочной системой или образно - с библиотекой: опытный библиотекарь способен мгновенно найти несколько подходящих книг даже по "размытому" описанию обложки, если в описании будет присутствовать хоть какой-то смысл или значимые ключевые слова.
Графовый поиск, если он правильно организован, позволяет создать полноценную аналитическую систему, которая, например, учитывает, как условие из одного пункта договора влияет на исполнимость другого договорного усл��вия, как это условие связано с внутренними регламентами компании, и точно знает, какая редакция закона лежала на столе в момент совершения сделки.
При этом на текущем этапе необходимо учитывать сравнительно высокую стоимость автоматической индексации и зависимость качества построенного графа от качества LLM, обрабатывающей источники данных, и предварительных настроек фреймворков для создания KGDB.
В текущих условиях при построении и развертывании RAG-систем в юридическом домене, если вам требуется не справочная по локальным документам и законам, а аналитическая система, логично использовать гибридную архитектуру, совмещающую графы знаний с элементами векторного поиска.
В следующей публикации собираюсь разобрать конкретный кейс построения RAG-системы в сфере недвижимости с помощью фреймворка LightRAG, который основан на гибридной архитектуре.
P.S.
Спасибо за внимание! Надеюсь, было интересно, готов ответить на вопросы в комментариях.
