
В предыдущей части статьи мы разобрали архитектуру LightRAG и показали основные сценарии его развертывания. В качестве эксперимента (цели и технический стек эксперимента подробно разобраны в первой части статьи) мы запустили фреймворк на небольшом корпусе из Гражданского кодекса РФ и 110 тематических (вопросы неоднозначной квалификации объектов имущества за период с 2006 по 2023 годы) решений Верховного Суда РФ, после чего провели топологический анализ полученного графа.
Картина оказалась противоречивой: визуально граф выглядел убедительно, система как-то работала, однако анализ средствами теории графов показал, что топологические характеристики построенного графа, непосредственно влияющие на качество поиска, далеки от оптимальных:
средняя степень вершин графа : граф едва вышел за пределы древовидно‑лесной структуры;
64,7% вершин графа имели степень ≤ 1: две трети графа либо были изолированы, либо имели единственную связь;
наибольшая компонента связности покрывала 64,6% (с ядром — ГК РФ) сущностей: значимая часть статей ГК РФ оказались вне основной структуры;
среди узлов вне ядра обнаружились системные дефекты автоматического извлечения: двуязычное расщепление (Supreme Court of the Russian Federation и Верховный Суд РФ), разорванная иерархия статей ГК РФ относительно центрального узла‑кодекса, "шум" в виде инициалов и обрывков ФИО и так далее.
Промежуточный вывод был однозначен: без оптимизации не обойтись.
В этой статье разберём, как именно проводилась оптимизация, что в итоге получилось и каковы ее ограничения. Проведем анализ центральности узлов графа, разберем, как настраивался поиск и главное — что граф знаний даёт на конкретных юридических запросах по сравнению с классическим векторным RAG.
План статьи:
разбор трехэтапной оптимизации графа;
сравнительный топологический анализ графа: ДО и ПОСЛЕ оптимизации по характеристикам, которые подробно разобрали в предыдущей части статьи;
анализ узлов итогового графа: центральности и топология;
поиск по графу и сравнительное тестирование на трех типах юридических запросов: правовая квалификация, восстановление хронологии дела, legal reasoning по кейсу.
итоговые выводы.
Кто я?
Меня зовут Сергей Слепухин. Прикладной лингвист и DS с фокусом на юридическом домене: исследую правовую область знаний и решаю практические задачи в этой сфере.
Оптимизация была разделена на три последовательных этапа, от очистки явных дубликатов и стандартизации до переклассификации типов сущностей:
Слияние и нормализация дубликатов.
Стандартизация наименований статей закона и их связывание с центральным узлом графа — Гражданский кодекс РФ.
Переопределение юридической таксономии сущностей.

На всех этапах оптимизации анализ топологии выполнялся непосредственно над внутренним графовым объектом LightRAG — экземпляром класса networkx.Graph (rag.chunk_entity_relation_graph._graph), а изменения вносились через встроенные методы LightRAG (rag.merge_entities(), rag.create_relation()), которые согласованно правят и сам граф, и связанные с ним хранилища (векторную базу сущностей, индекс связей и персистентные файлы).
Прямая правка ._graph через NetworkX-методы (add_node, remove_node) технически возможна, но привела бы к рассинхронизации между графом и векторным хранилищем.
К примеру, "умное" объединение узлов графа с помощью встроенного метода rag.merge_entities() заключается в следующем:
все связи из исходных сущностей перенаправляются в целевую сущность;
происходит интеллектуальное объединение дублирующихся связей, предотвращаются взаимные связи (циклы);
исходные сущности удаляются после объединения, при этом веса и атрибуты связей сохраняются.
Перед каждым этапом сохранялся бэкап рабочей директории.
Цель — устранить узлы, фактически описывающие один объект, но имеющие разные наименования.
Применялись две техники:
Mapping;
Normalization.
Mapping: объединение популярных узлов (количество связей > 3), которые имеют парные именования на русском и английском языках.
# rag - экземпляр LightRAG; ._graph - внутренний объект networkx.Graph
G = rag.chunk_entity_relation_graph._graph
MAPPING_DICT = {
"Civil Code of the Russian Federation": "Гражданский Кодекс РФ",
"Supreme Court of the Russian Federation": "Верховный Суд РФ",
# ... и т. д.
}
for source, target in MAPPING_DICT.items():
if source in G.nodes() and source != target:
rag.merge_entities(source_entities=[source], target_entity=target)Такой mapping прост, точен и понятен, когда у вас пара десятков значимых дубликатов, однако при масштабировании на корпусы в тысячи и десятки тысяч документов ручной словарь, конечно, перестает работать.
Как автоматизировать выявление дубликатов?
Применение чисто символьных подходов здесь ограничено. Например, можно использовать библиотеку rapidfuzz, которая позволяет на основе алгоритмов нечеткого сравнения строк (например, расстояние Левенштейна) определять степени их схожести (low‑level overlap). Это позволит достаточно эффективно выявить узлы, наименования которых отличаются только несколькими случайными символами (опечатки) или являются следствием расхождения в регистре. Однако в случае двуязычного дублирования сущностей символьное сходство между Supreme Court of the Russian Federation и Верховным Судом РФ ничтожно (другой алфавит, другая длина строки), хотя содержательно это одна и та же сущность.
Поэтому при масштабировании корпуса документов, на мой взгляд, целесообразно использовать двухпроходную схему выявления сущностей‑дубликатов:
на первом шаге тот же rapidfuzz ловит условно «простые» совпадения (это быстро и почти не даёт ложных срабатываний при высоком пороге сходства на метрике алгоритма);
на втором шаге — кластеризация по эмбеддингам имён сущностей с помощью би‑ или мультиязычных энкодеров: можно достаточно эффективно выявить понятийные синонимы (например, ВАС РФ | Высший Арбитражный Суд) или двуязычные сущности.
Однако на текущий момент полная автоматизация, которая отработает на 100%, в любом случае, невозможна. Например, эмбеддинг‑кластеризация отнесет к одной и той же сущности наименования, которые относятся к разным типам, поэтому лучше не сливать центральные узлы без ручной валидации.
Normalization: слияние сущностей, различающихся только регистром, кавычками или лишними пробелами с помощью регулярных выражений (напр., ООО "Результат" и ооо результат). В отличие от Mapping, алгоритм проходит по всем узлам, приводит их имена к нормализованному виду и группирует совпавшие. Помимо или совместно с регулярными выражениями можно также использовать указанные выше символьные и семантический (эмбеддинг‑кластеризация) подходы.
Данный этап, главным образом, направлен на снижение "зашумленности" графа, а также на унификацию ответов системы при цитировании наименований сущностей (не должно быть: "согласно ст. 130 ГК РФ" и "согласно статье 130" в одном и том же тексте).
Цель — создать явную связь между центральным узлом Гражданский Кодекс РФ и его статьями: Статья X ГК РФ → part_of → Гражданский Кодекс РФ. В общем случае (если индексируем произвольное количество кодексов и законов) — создать связь между каждым важным для выборки нормативным актом и его статьями ребро вида: Статья N → part_of → Кодекс | Закон X.
Проблема, которую мы зафиксировали в предыдущей части: одна и та же статья могла быть представлена в графе одновременно как ст. 130, статья 130, статья 130 ГК РФ, ст. 130 ГК РФ, и при этом ни одна из таких вершин не имела явной связи с центральным узлом. Топологически кодекс и часть его собственных статей оказались несвязанными сущностями, что объясняет, почему Статья 970 в графе (см. топологический анализ в предыдущей части: статьи) оказалась в топ-10 узлов вне наибольшей компоненты.
Шаг 1. Нормализация наименований статей. Поскольку мы хотим явно задать связи между сущностями‑статьями и сущностями‑законами (кодексами), важными для решаемой задачи (в нашем случае — только с ГК РФ), лучше явно задать справочник законов, каждая запись которого содержит:
наименование закона;
паттерн регулярного выражения, ищущий явный маркер этого закона в имени или в описании узла.
# Строительные блоки паттерна:
ARTICLE = r"(?:стать(?:я|и|е|ёй|ей|ю|ям|ях|ями)|статей|ст\.)"
NUM = r"(\d+)"
PROX = r"[\s,\-–—]*"
def codex_pattern(marker: str) -> re.Pattern:
return re.compile(
rf"\b{ARTICLE}\s*{NUM}{PROX}{marker}\b" # статья 130 [,–] ГК РФ
rf"|\b{marker}{PROX}{ARTICLE}\s*{NUM}\b", # ГК РФ [,] статья 130
re.IGNORECASE
)
CODEX_REGISTRY = [
{
"central_node": "Гражданский Кодекс РФ",
"pattern": codex_pattern(
r"(?:гк(?:\s*рф)?"
r"|граждан(?:ский|ского|ским|ском)\s+кодекс(?:а|е|у|ом)?(?:\s*рф)?)"
),
},
{
"central_node": "Уголовный Кодекс РФ",
"pattern": codex_pattern(
r"(?:ук(?:\s*рф)?"
r"|уголов(?:ный|ного|ным|ном)\s+кодекс(?:а|е|у|ом)?(?:\s*рф)?)"
),
},
# ... другие кодексы / законы добавляются сюда же
]Регулярные выражения находят все варианты записи статьи и приводят их к единому виду. Для каждого узла графа паттерн ищет лингвистический маркер кодекса и в имени узла, и в его описании: LLM при индексации графа, как правило, создает узел с коротким наименованием Статья 130, без указания закона, помещая описательную часть в поле description.
В результате поиска возможны три исхода:
явная привязка: маркер (соответствующий паттерну в справочнике) закона найден в имени или описании → имя узла приводится к единому виду Статья N Закона X, и на следующем шаге узел связывается с центральным узлом закона;
нормализация без привязки: имя имеет форму статья N, но ни в имени, ни в описании нет маркера конкретного закона или кодекса → имя приводится к виду Статья N, узел остается в графе без привязки (ошибочная привязка статьи не к тому кодексу в юридическом домене хуже, чем отсутствие привязки);
остальное — оставляем как есть.
Слияния выполняются через встроенный метод rag.merge_entities(), что гарантирует согласованное обновление графового и векторного хранилищ.
Шаг 2 — создание иерархических связей. Когда статьи приведены к каноническому виду относительно центральных узлов законов, для каждой статьи создается явное ребро к соответствующему центральному узлу через встроенный метод rag.create_relation():
canonical_re = re.compile(r"^Статья\s+\d+\s+(.+)$")
centrals = {c["central_node"] for c in CODEX_REGISTRY}
for node in list(G.nodes()):
node_str = str(node)
m = canonical_re.match(node_str)
if not m:
continue
tail = m.group(1) # часть имени после «Статья N »
if tail in centrals and node_str != tail:
if G.has_edge(node_str, tail): # ребро уже есть — не трогаем,
continue # чтобы не затереть его вес (см. ниже)
rag.create_relation(
node_str, tail,
{
"keywords": "legal_hierarchy, part_of",
"description": f"This article is a structural part of {tail}",
"weight": 1.0,
}
)Ключевые слова part_of и legal_hierarchy важны функционально: они становятся метками, по которым LightRAG будет находить иерархические связи на этапе поиска в global‑режиме.
Отдельно стоит сказать про вес создаваемого ребра. В LightRAG вес ребер участвует в ранжировании связей при обходе графа, и при усечении контекста по top_k более "тяжелые" ребра имеют приоритет попадания в финальный контекст, передаваемый LLM.
В рамках эксперимента ребрам "статья → кодекс" (для несвязанных вершин‑статей) присвоен нейтральный вес 1.0. Это необязательно оптимальное решение. При развертывании графа на корпусе большего масштаба более аккуратным решением может быть привязка веса ребра не к константе, а, например, к медиане связей, извлечённых LLM из текста для соответствующего узла.
Ограничения при масштабировании.
Текущий подход хорошо работает для фиксированного, заранее известного и небольшого набора законов и кодексов в экспериментальном режиме. Если же корпус кратно вырастет или предполагает постоянное обновление, возникают, как минимум, четыре системных ограничения:
"Ручные" паттерны не масштабируются: у большинства законов, в отличие от кодексов, нет устойчивого краткого обозначения вроде "ГК РФ" или "АПК РФ", а длинные названия в текстах сокращаются произвольно.
Рост доли непривязанных статей: чем шире и асимметричнее выборка законов, на которой построен корпус, тем больше будет упоминаний а-ля "Статья N" без явного указания источника: LLM сокращает длинные и (или) непопулярные наименования или вовсе их опускает. На больших корпусах доля статей без иерархической привязки может заметно вырасти, частично обесценивая global‑поиск.
Конфликты и омонимия паттернов. На большом корпусе паттерны регулярных выражений начинают перекрываться: одна и та же аббревиатура может относиться к разным актам в разных контекстах.
Производительность. Итерация по всем узлам графа для каждой записи справочника имеет сложность , где
— число кодексов и законов.
О решениях для масштабирования здесь подробно писать не буду, отмечу только, что логичен переход к NER‑модели, специально обученной для извлечения атрибуции "статья‑источник" прямо на этапе индексации: тогда разрешение неоднозначности происходит там, где есть максимально широкий контекст (полный чанк), а не постфактум по имени уже сохранённого узла. Ручной справочник при этом остаётся как страховочный слой для наиболее критичных центральных узлов. Но и у этого подхода, очевидно, есть свои сложности и ограничения.
На третьем этапе производится финальная точечная чистка топологии графа, после — наиболее содержательное преобразование графа: изменение универсальной типологии на юридическую.
3.1. Точечная топологическая чистка.
После первых двух этапов в графе оставались три группы локальных дефектов, и все они правились впоследствии с помощью эвристик (решение, которое считаю целесообразным при масштабировании, рассмотрено ниже):
Разные словоформы — одна сущность (для top_k узлов). При индексации словоформы, отличающиеся только числом, были отнесены к разным сущностям. Очевидно, что это семантические дубликаты, которые необходимо мерджить в одну сущность. Слияние производилось для пар top_k узлов, являющихся такими дубликатами (например, Юридическое Лицо и Юридические Лица, Кредитор и Кредиторы и так далее).
Почему не использовали лемматизатор? Дело в том, что для русского языка с составными юридическими терминами такая оптимизация могла бы привести к еще большому «зашумлению» графа: например, тот же pymorphy "Устав ООО" преобразует в "устать ООО".
Удаление "мусорных"инициалов: фрагменты вроде Б., С.А., являющиеся артефактами индексации, оторванные от полных имен, детектируются и удаляется.
Интересное и важное наблюдение. Были обнаружены узлы, которые LLM "затащила" в граф из своих обучающих данных, а не из корпуса: Noah Carter, World Athletics Championship, Tokyo, Sprint Record. Наглядная иллюстрация того, о чем шла речь в предыдущей части: автоматическое извлечение не детерминировано, и LLM может "подмешать" в граф то, чего в текстах не было.
Точечная переклассификация сущностей в соответствии с доменной логикой. Обнаружили, что двум значимым группам сущностей при индексации тип был назначен неверно:
Индивидуальные предприниматели (ИП, Индивидуальный предприниматель Иванов) попадают в тип person, хотя с точки зрения юридической логики это субъекты предпринимательской деятельности, которые было бы более корректно отнести к organization;
Абстрактные юридические роли (Кредитор, Должник, Заказчик) оказались в person, хотя это, очевидно, обозначения сторон правоотношения, которые было бы более логично отнести к типу concept.
3.2. Приведение типов сущностей к доменной таксономии.
После предыдущих шагов в графе все еще доминировал неопределённый тип concept (2233 узла), а юридически значимые сущности разбросаны по десятку несогласованных типов:law, legalreference, legalarticle, legalprovision, legal_document, которые логично было бы свести к единому типу.
В общем, была поставлена задача — свести весь этот "зоопарк" к компактной доменной таксономии. Реализовано с помощью кастомной функции, которая задает последовательность проверок — от самого специфичного случая к самому общему: каждая следующая проверка применяется, только если не сработала предыдущая.
Сначала задаются два опорных объекта.
Список "замороженных" типов — категории, которые при индексации, в целом, определены корректно (organization, person, location, date).
Паттерн регулярного выражения, распознающего маркеры правовой нормы (закон, кодекс, ст., ФЗ, постановление и их английские аналоги).
# заморозка
LOCKED_TYPES = {'organization', 'person', 'date', 'currency', 'measurement', 'location'}
# маркеры правовой нормы
norm_pattern = re.compile(
r"(?i)\b(закон[а-я]*|кодекс[а-я]*|стать[яию]|пункт[а-я]*|указ[а-я]*|"
r"постановлени[ея]|глав[аы]|фз|гк|ук|апк|нк|"
r"article|law|act|clause|decree|code|section)\b|\b(ст\.|п\.)",
re.UNICODE)Далее каждый "незамороженный" узел переназначается по доменной таблице соответствий:
Исходные типы LightRAG | Целевой тип после remap |
|
|
|
|
|
|
|
|
|
|
|
|
| оставляем без изменений |
Алгоритм обработки:
Экспертные исключения — точечные исключения, которые не вписываются в реализованную логику фильтрации.
Итеративная фильтрация сущностей:
ядро функции — двуязычный паттерн norm_pattern;
далее, если паттерн не сработал, пошагово применяется логика маппинга, описанная выше, в таблице;
если не сработал и маппинг, базовая общая сущность по умолчанию — legal_concept.
Важная деталь реализации.
При смене типа функция сохраняет исходное текстовое описание сущности. Это связано с тем, как LightRAG векторизует узлы: в эмбеддинг сущности идет текст вида "имя + описание", а сам тип в вектор не входит (тип сущности хранится как метаданные). Если при смене типа описание "затереть", векторное представление сущности "съедет", и поиск в окрестности начнет работать хуже, чем до оптимизации. Сохраняя описание, мы меняем тип, не затрагивая векторное представление описания.
В чем польза изменения типологии, если векторы типов сущностей не влияют на работу retrieval?
Тип сущности попадает в структурированный контекст, который передаётся LLM на этапе генерации ответа: например, модель учитывает, что Статья 130 ГК РФ — это legal_norm, а Торговый павильон — legal_object, и, исходя из этого, точнее выстраивает reasoning (контекст становится более осмысленным).
Типизация даёт основу для фильтрации и визуализации (раскраска узлов по меньшему количеству типов в дашборде, отбор отдельных слоёв графа). В общем, это делает граф человекочитаемым и управляемым для аналитика.
После обработки распределение типов становится доменно-осмысленным:
Тип | Количество | Описание |
🟠 | 1620 | наиболее общая категория, включающая юридические понятия ( |
🟡 | 1575 | юридические нормы и их маркеры ( |
🔵 | 713 | суды, юрлица, индивидуальные предприниматели, госорганы и проч. |
🟢 | 287 | физические лица |
🔴 | 251 | конкретные объекты споров и иных правоотношений ( |
🟣 | 149 | географические объекты |
прочие | 269 |
|
Ограничения при масштабировании
Изменение типологии в такой реализации — это экспертная доводка на эвристиках под конкретный корпус. Для исследовательского эксперимента это оправдано, но на корпусе размером в десятки тысячи документов такой подход, конечно, плохо масштабируется.
Позволяет ли LightRAG упростить пост‑обработку внутренними инструментами, уменьшив число дефектов на этапе извлечения?
Такие возможности есть, но и они имеют свои ограничения:
Кастомная типология в entity extraction prompt. LightRAG позволяет переопределить список типов сущностей и инструкции для их распознавания на этапе извлечения (через отдельный файл промпта типов — ENTITY_TYPE_PROMPT_FILE). Конкретный механизм меняется от версии к версии, поэтому за актуальным способом стоит свериться с env.example и release notes репозитория фреймворка.
Использование более мощной и современной модели для индексации: в эксперименте использовалась "скромная" GPT-4o‑mini (рассматривали вопрос обоснования выбора модели эксперимента в предыдущей части статьи).
Однако даже мощная модель с идеальным промптом на текущий момент не позволит исключить появление ошибок в типологии на этапе индексации:
Всегда останется (или появится в будущем) группа явлений или объектов, для которой не найдется нужный тип сущности.
Границы между юридическими типами сущностей (особенно если они имеют абстрактную семантику и/или не имеют в языковом выражении определенной структуры, как, например, персоналии, суммы или даты) часто довольно "размыты" и зависят от контекста:
Земельный участок — это legal_object (конкретный объект спора) или legal_concept (категория "недвижимая вещь")? — Ответ зависит от контекста.
Договор купли‑продажи — понятие или документ? — Ответ зависит от контекста.
Самовольная постройка — понятие или объект? — Ответ зависит от контекста.
И чем больше типов с "размытыми" границами будет получать модель, тем чаще она будет ошибаться в пограничных случаях.
Характеристика | До оптимизации | После оптимизации | Разница |
Количество вершин | 5 261 | 4 864 | −397 |
Количество ребер | 5 773 | 6 505 | +732 |
Средняя степень | 2,19 | 2,67 | +22% |
Плотность | 0,00042 | 0,00055 | +31% |
Количество изолированных вершин | 1 389 | 992 | −29% |
Количество висячих вершин | 2 013 | 1 752 | −13% |
Количество компонент связности | 1 535 | 1 066 | −31% |
Количество вершин в наибольшей компоненте | 3 398 | 3 680 | +282 |
Степень центрального узла (ГК РФ) | 560 | 1 443 | ×2,6 |
Формулы расчета указанных метрик (характеристик) графа, а также, что они показывают — подробно разобрали в предыдущей части статьи.
Несколько любопытных наблюдений из этих чисел.
Изменение общего числа вершин (−397) в точности равно изменению числа изолированных вершин. То есть число связных вершин не изменилось, все сокращение пришлось исключительно на изолированную фракцию (дубликаты‑одиночки, мусорные инициалы, посторонние сущности), тогда как связное ядро по составу вершин осталось нетронутым, а добавленные 732 ребра уплотнили связи внутри него.
Рост средней степени вершин графа с 2,19 до 2,67. Изначально средняя степень вершин графа составляла 2,19: граф едва вышел за пределы древовидно‑лесной структуры. Увеличение значения этого показателя говорит о появлении и накоплении циклов. Другими словами, прирост 0.48 пунктов означает, что в графе появилось существенно больше альтернативных маршрутов между узлами.
Цикломатическое число выросло с 2047 (до оптимизации). То есть на 660 независимых циклов стало больше.
Доля вершин в связном ядре выросла с 64,6% до 75,7%. Теперь три четверти всех сущностей достижимы алгоритмами обхода, и это значимо может изменить качество global-поиска, потому что система получает доступ к существенно большему объему базы знаний за один обход.
20,4% узлов графа остались изолированными. Полагаю, это не "остаточный шум", а отчасти структурное свойство выбранного корпуса, которое мы обсуждали в предыдущей части статьи: при асимметричной выборке (полный текст ГК РФ против узкого тематического среза судебной практики) многие нормы кодекса (например: наследование, исключительные права, регулирование отдельных видов договоров) в наших 110 решениях о квалификации недвижимости не активируются в принципе и закономерно остаются вне ядра графа. Чтобы сократить долю изолятов ниже 20%, нужен либо более широкий и тематически сбалансированный корпус судебной практики, либо еще более глубокая пост-обработка графа, что выходит за пределы эксперимента по тестированию фреймворка.
Итог: характеристики графа значимо и измеримо улучшились по всем характеристикам.
Итак, граф структурно улучшился: он стал более плотным, связным и менее "шумным". Однако рассмотренные усредненные характеристики графа ничего не говорят нам о том, где именно эта связность сосредоточена, и какие узлы вносят наибольший вклад в обеспечение его структуры.
Для ответа на эти вопросы следует перейти от анализа графа в целом к анализу показателей индивидуального уровня — центральности наиболее важных узлов. Здесь мы выходим за пределы классической теории графов: исследование центральности — инструмент сетевого анализа (network science) — прикладной междисциплинарной области, применяющей аппарат теории графов к реальным сетевым структурам — социальным, биологическим, информационным.
Понятие центральности впервые системно формализовал в 1979 году американский социолог Линтон Фримен. Фримен показал, что "важность" узлов в графе можно измерить разными мерами и выделил три, ставшие позднее классическими: центральность по степени (degree centrality), по посредничеству (betweenness centrality) и по близости (closeness centrality). Позднее к ним добавились другие характеристики. Основные представлены на рисунке:

В каждом фрагменте красным выделен наиболее центральный узел согласно соответствующему типу центральности. Размер узла соответствует относительному размеру его степени.
Обзор основных мер центральности:
Центральность по степени: вершина, имеющая наибольшее число связей с другими вершинами, является наиболее центральной.
Центральность посредничества: вершина, через которую проходит наибольшее число кратчайших путей, является наиболее центральной.
Центральность по близости: вершина, находящаяся ближе всех к другим вершинам сети, является наиболее центральной.
Центральности по собственному вектору (разновидность спектральных центральностей) учитывают "качество" связей: центральность данной вершины зависит от центральностей соседей вершины.
PageRank — разновидность центральности по собственному вектору, изначально алгоритм был разработан компанией Google для ранжирования веб‑страниц; основан на модели случайного блуждания по сети.
Для нашей задачи и получившегося графа достаточно двух — центральности по степени и центральности посредничества. Остальные рассмотренные меры на неориентированном графе либо сильно коррелируют с центральностью по степени (eigenvector, PageRank), либо плохо определены на графе с большой долей изолированных вершин (closeness). Центральность посредничества оценивает узел не по числу связей, а по числу проходящих через него кратчайших путей: узел может иметь мало связей, но быть незаменимым посредником (мостом), без которого единый граф распадется на изолированные подграфы.
Таким образом, выбранные центральности отвечают на два важных и разных для организации поиска вопроса:
Степень — Какие узлы служат точками входа в граф?
Посредничество — Какие узлы служат мостами между его частями?
Информативным является само о себе расхождение между указанными метриками: оно указывает на узлы, чья структурная роль не сводится к простому числу связей.
Это самая базовая и прямая характеристика центральности узла: сколько связей у него относительно их максимально возможного числа:
Числитель — степень вершины (число инцидентных ребер), знаменатель — нормирующий коэффициент (максимально возможная степень в простом графе на вершинах).
принимает значения на отрезке
, если узел связан со всеми остальными вершинами, и
для изолированного узла.
Центральные по степени узлы — это, по сути, точки входа для global‑режима поиска. Когда запрос обрабатывается в этом режиме, обход графа начинается именно с этих узлов и движется от них к более частным понятиям (или конкретным делам). Соответственно, если degree centrality "забит" шумовыми или нерелевантными домену сущностями, global‑режим поиска будет работать плохо.
Реализация средствами NetworkX:
import networkx as nx
G = rag.chunk_entity_relation_graph._graph
centrality = nx.degree_centrality(G)
top_18 = sorted(centrality.items(), key=lambda x: x[1], reverse=True)[:18]Топ-18 узлов по degree centrality
# | Сущность | Score | Число связей | # | Сущность | Score | Число связей |
1 | Гражданский Кодекс РФ | 0,2967 | 1443 | 10 | Покупатель | 0,0105 | 51 |
2 | Суд | 0,0234 | 114 | 11 | Должник | 0,0103 | 50 |
3 | Верховный Суд РФ | 0,0232 | 113 | 12 | Подрядчик | 0,0103 | 50 |
4 | Земельный участок | 0,0226 | 110 | 13 | Заказчик | 0,0103 | 50 |
5 | Юридическое лицо | 0,0206 | 100 | 14 | Банк | 0,0097 | 47 |
6 | Гражданин | 0,0183 | 89 | 15 | Продавец | 0,0095 | 46 |
7 | Лицо | 0,0152 | 74 | 16 | Арендатор | 0,0078 | 38 |
8 | Кредитор | 0,0144 | 70 | 17 | АПК РФ | 0,0078 | 38 |
9 | Общество | 0,0138 | 67 | 18 | ВАС РФ | 0,0078 | 38 |
Распределение центральности адекватно юридической предметной области в целом и поддомену (тематике корпуса судебных постановлений ВС РФ) — в частности.
Центральный узел и хаб домена — Гражданский Кодекс РФ (): он связан почти с 30% всех узлов графа.
Земельный участок на четвёртом месте: отражение тематики корпуса (споры о квалификации недвижимого имущества).
Исследование узлов в webUI LightRAG


Изображение выше визуально подтверждает наблюдения из таблицы: Земельный участок — один из центральных узлов, плотно окружен разнообразными связями, являясь, как будет показано ниже, одним из хабов в графе. Среди его соседей — статьи ГК РФ, конкретные спорные объекты (Здание или Сооружение, Металлическое судно) и стороны судебных споров (ИП Никитина И.С.).
Замечание. В таблице выше у Земельного участка — 110 связей, а в веб‑интерфейс LightRAG — только 62. Противоречия нет: таблица построена по полному графу из 4864 узлов, веб‑интерфейс же визуализирует не весь граф, а подгруженный на экран подграф (в левом нижнем углу видно Max: 1000 — ограничение на число отображаемых узлов, и D: 3 — глубину обхода).
Если центральность по степени говорит нам о том, насколько узел популярен, то центральность по посредничеству отвечает на другой вопрос — насколько узел незаменим как посредник или мост между другими узлами в графе. В основе этой меры центральности лежит предположение, что информация в сети распространяется по кратчайшим путям между вершинами, а важность узла определяется тем, сколько таких путей проходит через него.
Формально:
— общее число кратчайших путей между вершинами
и
,
— число тех из них, что проходят через узел
.
Для нормированного индекса на неориентированном графе используется деление на максимально возможное число проходящих через узел путей:
Показатель относительно (показателей для других узлов) высоким, если значимая часть кратчайших маршрутов в графе будет проходить через . Удалите такой узел, и маршруты между частями графа (подграфами) либо удлинятся, либо исчезнут вовсе (если узел был единственным мостом между ними).
Узлы с высокой betweenness centrality — это, образно выражаясь, "центральные мосты" графа, и для retrieval они особенно ценны: именно через них система переходит от одной части графа к другой при многошаговом обходе, что прямо влияет на качество multi‑hop reasoning.
Вычисление betweenness centrality существенно дороже degree centrality. Наивный подсчет всех кратчайших путей между всеми парами узлов потребовал бы времени. NetworkX использует алгоритм Брандеса, который для неориентированного невзвешенного графа (наш случай) выполняется за
.
Реализация средствами NetworkX:
import networkx as nx
G = rag.chunk_entity_relation_graph._graph
betweenness = nx.betweenness_centrality(G, normalized=True)
top_bridges = sorted(betweenness.items(), key=lambda x: x[1], reverse=True)[:18]Топ-18 узлов по betweenness centrality
# | Сущность | Score | Число связей | # | Сущность | Score | Число связей |
1 | Гражданский Кодекс РФ | 0,4794 | 1443 | 10 | Кредитор | 0,0106 | 70 |
2 | Верховный Суд РФ | 0,0605 | 113 | 11 | Арбитражный суд | 0,0104 | 34 |
3 | Земельный участок | 0,0547 | 110 | 12 | Налоговый кодекс РФ | 0,0087 | 27 |
4 | Суд | 0,0415 | 114 | 13 | Российская Федерация | 0,0079 | 33 |
5 | ВАС РФ | 0,0225 | 38 | 14 | Спорный объект | 0,0079 | 32 |
6 | Общество | 0,0197 | 67 | 15 | АПК РФ | 0,0078 | 38 |
7 | Юридическое лицо | 0,0151 | 100 | 16 | Судебная коллегия | 0,0070 | 14 |
8 | Гражданин | 0,0148 | 89 | 17 | Договор купли-продажи | 0,0070 | 18 |
9 | Лицо | 0,0144 | 74 | 18 | Банк | 0,0067 | 47 |
Если сравнить топ-5 сущностей с топ-5 по degree centrality, первые четыре узла совпадают (хотя их порядок отличается).
Ключевое отличие в том, что Высший Арбитражный Суд РФ занимает 5-е место по betweenness, имея всего 38 связей, тогда как по degree он лишь 18-й в графе (мы отметили это в degree‑таблице). У ВАС РФ связей относительно немного, но почти каждая значима: эта сущность соединяет специфический сегмент арбитражной практики с остальным графом. Узел с невысокой степенью оказывается структурно незаменимым центром подграфа.
Визуализация такой структуры (где размер узла задан пропорционально его betweenness centrality) представляет собой самостоятельную аналитическую ценность.
К сожалению, веб‑интерфейс LightRAG не дает возможности визуализации центральности по посредничеству, поэтому использовал стек — NetworkX‑ PyVis. Пример визуализации, построенной средствами библиотеки PyVis на подграфе из ~2120 узлов со степенью не ниже 2:

Данный граф является подграфом, состоящим из ~2120 узлов (степень ≥ 2). Размер узла пропорционален betweenness centrality (случайный старт раскладки):
🟡 legal_norm 🟠 legal_concept 🔴 legal_object 🔵 organization 🟢 person
🟤 document 🟣 location ⚪ other
Размер узлов задан пропорционально их betweenness centrality, посчитанной средствами библиотеки NetworkX по всем узлам отображаемого подграфа.
Цвет вершин графа соответствует типам сущностей.
Раскладка вершин относительно друг друга получена с помощью встроенного алгоритма spring_layout (расставляет узлы, исходя из физической аналогии: связанные узлы притягиваются, как на пружинах, несвязанные отталкиваются). Характерная звездообразная форма — прямое следствие доминирования одного узла: betweenness centrality Гражданского кодекса РФ (0,48) на порядок превышает значения всех прочих, поэтому он стягивает к себе связи, образуя структуру, подобную звездной системе, а слабосвязанная периферия выталкивается на внешнюю окружность.
Красные "спицы" — это ребра к объектам споров (legal_object), радиально расходящиеся от центральной компоненты графа.
Как сделать картинку с изображением значимых узлов графа более информативной?
Звездообразная форма выше получена при случайных стартовых позициях узлов. Очевидно, что она не совсем удобна для визуального анализа: 2120 узлов сливаются в плотное кольцо, а структурные роли остальных мостов теряются.
Для удобочитаемой визуализации придадим геометрии графа большую информативность.
Во‑первых, оставим только несущий каркас мостов (500 узлов с наибольшей betweenness), отбросив слабосвязанную периферию. Во‑вторых, зададим алгоритму не случайный, а осмысленный старт: каждый узел будет стартовать тем ближе к центру, чем выше его центральность. Это направляет силовую раскладку к более информативной геометрии, где важные узлы‑мосты собираются в ядре, а не "разбрасываются" случайно.
Алгоритм построения:
С помощью библиотеки NetworkX считаем betweenness centrality по полному графу.
Оставляем топ-500 узлов‑мостов и раскладываем их алгоритмом spring_layout, но не со случайных позиций, а со стартом, заданным по центральности.
Задаем размер узлов пропорционально рассчитанным показателям центральности.
Визуализация средствами NetworkX-PyVis:
import networkx as nx
import math
from pyvis.network import Network
def visualize_top_n_nodes(rag, output_filename="legal_graph_500.html", top_n=500):
G_raw = rag.chunk_entity_relation_graph._graph
# Считаем betweenness по полному графу и берём топ-N узлов-мостов
centrality_full = nx.betweenness_centrality(G_raw, normalized=True)
sorted_nodes = sorted(centrality_full, key=centrality_full.get, reverse=True)
top_n_nodes = set(sorted_nodes[:top_n])
G_nx = G_raw.subgraph(top_n_nodes).copy()
centrality = {n: centrality_full[n] for n in G_nx.nodes()}
max_cent = max(centrality.values())
# Раскладка: стартовая позиция узла тем ближе к центру, чем выше его betweenness (это помогает spring_layout сойтись)
initial_pos = {}
for node in G_nx.nodes():
scale = 1.0 - centrality[node] / max_cent # важные → ближе к (0,0)
angle = hash(node) % 628 / 100.0 # угол из хэша имени, [0, 2π]
initial_pos[node] = (scale * math.cos(angle), scale * math.sin(angle))
pos = nx.spring_layout(G_nx, pos=initial_pos, k=0.6, iterations=120, seed=42)
# Цвет — по типу сущности после переклассификации
color_map = {
…
}
# Отрисовка через PyVis (физика отключена, позиции заданы вручную)
net = Network(height="950px", width="100%", bgcolor="#222222", font_color="white")
net.toggle_physics(False)
for node, attrs in G_nx.nodes(data=True):
net.add_node(
node,
x=float(pos[node][0]) * 6000, # масштаб координат под PyVis
y=float(pos[node][1]) * 6000,
label=str(node),
color=color_map.get(attrs.get('entity_type', 'other'), '#D3D3D3'),
size=centrality[node] / max_cent * 200 + 15, # размер ∝ betweenness
shape="dot",
)
for u, v, data in G_nx.edges(data=True):
is_lo = 'legal_object' in (G_nx.nodes[u].get('entity_type'),
G_nx.nodes[v].get('entity_type'))
net.add_edge(u, v,
width=3 if is_lo else 1.5,
color="#DC143C" if is_lo else "#aaaaaa")
net.write_html(output_filename)
visualize_top_n_nodes(rag, top_n=500)
🟡 legal_norm 🟠 legal_concept 🔴 legal_object 🔵 organization 🟢 person
🟤 document 🟣 location ⚪ other
Картинка явно показывает: крупнейшие узлы — Гражданский Кодекс РФ, Верховный Суд РФ, Земельный участок, Суд и Высший Арбитражный Суд РФ — главные мосты графа.
После визуализации продолжим анализ. Обратим внимание, что Верховный Суд РФ является вторым по значимости узлом по betweenness centrality (при третьем по degree): ВС РФ структурно соединяет нормативную часть графа (ГК РФ с его статьями) с правоприменительной (сущности из судебных решений).
Земельный участок — топологический центр плотного периферийного кластера, связанного с недвижимостью: через него обход по графу попадает к конкретным объектам споров (Здание, Сооружение, Объект незавершённого строительства, Торговый павильон и так далее).
Интересно также отметить, что в топ рейтинга по посредничеству попал Спорный объект (14-е место, 32 связи), который соединяет нормативное ядро и другие топологические центры графа с периферией конкретных объектов спора.
Адекватное распределение betweenness centrality является одним из независимых метрических подтверждений качества построенного графа: топология указала на мосты адекватные домену и поддомену. Полагаю, на них же указал бы и эксперт.
Итак, топология графа стала более оптимальной. Однако сниженная фрагментация, осмысленные мосты и прочие структурные улучшения не ценны сами по себе с практической точки зрения: это необходимое условие для реализации качественного поиска, но не достаточное. Поэтому дальше мы переходим к практике.
Гипотеза, которую мы хотим проверить, прямо вытекает из топологии: граф знаний в текущей оперативной реализации должен давать преимущество не на любых вопросах, а на вопросах определённого типа — тех, что требуют связывания разнесенных по различным чанкам фрагментов в цепочку, соответствующую логике вопроса.
Когда ответ, условно говоря, лежит в одном абзаце, его одинаково хорошо найдёт и обычный векторный поиск. Но когда ответ на вопрос требует сначала составить осмысленный маршрут, например — от нормы права к правовому концепту (понятию, категории), от концепта к спорному объекту, от объекта — ко всем связанным судебным делам, разбросанным по десяткам страниц текста, векторное сходство перестает работать. Векторный RAG принципиально не сможет собрать эти фрагменты, так как они семантически не похожи друг на друга, и retrieval по близости их вместе не соберет. А граф соберёт (должен собрать!), потому что между ними есть путь по ребрам: в этом и есть суть multi‑hop reasoning, которое позволяет реализовать граф знаний!
Проверим это, сравнив два подхода (векторный RAG и LightRAG) на одних и тех же запросах, от простых (простое утверждение о факте) до сложных, требующих собрать хронологию дела и выявить противоречия в практике.
Продвинутый векторный поиск против поиска по графу знаний, совмещенного с наивным векторным поиском.
Сравнение идёт между двумя системами, построенными на одних и тех же 110 решениях и тексте ГК РФ — Vector RAG vs LightRAG.
Vector RAG — это не наивный baseline, а ориентированный на домен, гибко настроенный pipeline, построенный на LangChain (подробнее об архитектуре см. статью Law & Practice Ensemble RAG. Как создать ассистента, помогающего решать многоаспектные юридические задачи). В общем, это продвинутый, тонко настроенный под юридические задачи векторный поиск. Поэтому сравнение с ним будет показательно.
В предыдущей части мы разобрали пять режимов поиска LightRAG (naive, local, global, hybrid, mix) и их назначение. Решили, что для юридических задач целесообразно использовать самый полный из них — mix: он совмещает графовый поиск (hybrid = local + global) с векторным поиском по чанкам и взвешенно сливает результаты в единый контекст, передаваемый LLM для генерации ответа.
Запросы юриста редко сводятся к одному типу. Например: "Какие нормы регулируют квалификацию объекта недвижимости?" — это вопрос одновременно и global‑уровня, требующий активации связей, имеющих отношения к понятию недвижимого имущества, и конкретно‑фактологический (local) вопрос. Также желательно, чтобы система могла поднять векторные представления самих чанков (naive).
Конфигурация запроса из рабочего ноутбука:
from lightrag import QueryParam
params = QueryParam(
mode="mix",
top_k=70, # топ-k сущностей/связей из графа
chunk_top_k=25, # топ-k чанков из векторного индекса
max_total_tokens=200_000, # бюджет контекста под LLM
enable_rerank=False, # реранкер отключён — см. ниже
user_prompt=sys_instruction)Пояснения по некоторым параметрам:
enable_rerank=False: в исследовательском эксперименте важно было увидеть, что дает сам граф, без дополнительных слоёв постобработки, на продакшне реранкер логично включить;
user_prompt=sys_instruction: очевидна важность адекватных инструкций на узкодоменных задачах с использованием такой "скромной" по нынешним меркам модели как GPT-4o‑mini (рассмотрим возможную реализацию этого параметра ниже).
Те же параметры можно выбрать в поисковом веб‑интерфейсе LightRAG.
Параметр user_prompt по своему функционалу — системная инструкция, передаваемая модели при генерации финального ответа. Через него можно управлять стилем, глубиной и форматом ответа и соответственно расходом токенов. С помощью тонкой настройки данного параметра мы можем обслуживать разные сценарии работы системы — от справочника по правовым вопросам до юридического анализа.
Полагаю, для юридического домена в любой RAG‑системе целесообразно использовать, как минимум, три уровня, по нарастанию сложности.
Basic: достаточен для простых односложных вопросов, не требующих сложных рассуждений, как, например — "Во сколько лет гражданин вправе приобрести недвижимое имущество?". Назначение — быстрая справка, без излишней детализации.
Пример реализации:
LEGAL_BASIC_PROMPT = """
РОЛЬ: Ты – профессиональный российский юрист-ассистент, специализирующийся на вопросах в сфере недвижимого имущества.
ЗАДАЧА:Ответь на вопрос пользователя, анализируя СТРОГО по предоставленному контексту (состоящему из сущностей графа знаний,
связей (relations) между сущностями и текстовых фрагментов).
ТРЕБОВАНИЯ К ОТВЕТУ:
1. В ответе ОБЯЗАТЕЛЬНО используй статьи применимых законов и номера, а также даты судебных дел из контекста.
2. Обращай особое внимание на слова и понятия, связанные со спорными объектами имущества в текстах найденных судебных постановлений.
3. Старайся выжать из контекста максимум деталей и связей!
4. Не используй отвлеченные обобщения.
5. Будь четок, корректен и компетентен!""" Ordinary — некий стандартный промпт для большинства практических запросов, исходя из вашей специфики. Можно указать подробные инструкции по идентификации источников (наименование суда, дата решения, номер дела при упоминании прецедентов), флаг на противоречивую практику (выдели как "Особенности правоприменения"), явный запрет на "изобретение" реквизитов (если не уверен — укажи прямо: "В предоставленных материалах реквизиты дела отсутствуют").
Senior — режим имитации полноценного юридического анализа. Отличается от режима Ordinary главным образом тем, что в нём задана явная цепочка рассуждений (Chain‑of‑Thought).
Пример реализации внутри промпта:
LEGAL_SENIOR_PROMPT = """...
...
ИНСТРУКЦИЯ ПО ЮРИДИЧЕСКОМУ МЫШЛЕНИЮ (CoT):
Прежде чем сформировать финальный ответ, проведи внутренний пошаговый анализ:
1. [Факты] Выдели характеристики объекта из вопроса и найденных сущностей.
2. [Норма] Сопоставь эти характеристики с найденными правовыми нормами.
3. [Практика] Найди в контексте судебные дела, где рассматривались похожие споры.
4. [Коллизии] Проверь противоречия:
а) между нормами;
б) между нормами и практикой;
в) между разными решениями.
5. [Синтез] Сформируй правовую позицию."""Также можно жестко задать структуру финального ответа, например:
"Правовая квалификация → Ключевые признаки → Доказательная база → Карта рисков".
Пример реализации поисковой функции с переключением указанных типов промптов:
async def ask_legal_rag_async(rag, question, prompt_type="ordinary"):
sys_instruction = {
"basic": LEGAL_BASIC_PROMPT,
"ordinary": LEGAL_ORDINARY_PROMPT,
"senior": LEGAL_SENIOR_PROMPT,
}[prompt_type]
params = QueryParam(
mode="mix",
top_k=70,
chunk_top_k=25,
max_total_tokens=200_000,
enable_rerank=False,
user_prompt=sys_instruction
)
return await rag.aquery(question, param=params)Для тестирования были выбраны три разных типа вопроса, принципиально различающиеся по типу необходимых для ответа на них способностей и знаний:
Вопрос на правовую квалификацию (промпт ordinary): проверяет точность ответа и достоверность использованных источников — наиболее важные метрики для RAG‑системы в юридическом домене.
Вопрос на восстановление хронологии сложного дела (промпт ordinary): здесь качество должно отличаться кардинально. Гипотеза в том, что даже продвинутый векторный поиск не способен собрать последовательность событий, разбросанную по тексту, в единую логически построенную цепочку.
Вопрос на проверку legal reasoning на достаточно сложном юридическом кейсе: дается развернутое описание кейса с позициями сторон. Проверяет корректность правового вывода через обоснование в отчете: применение "правильных" норм и релевантной судебной практики.
Ниже разберем наиболее показательные примеры.
Вопрос 1: можно ли зарегистрировать футбольное поле как недвижимость?
Полные ответы систем на Вопрос 1:
Ответ Vector RAG:Для регистрации футбольного поля как объекта недвижимого имущества необходимо учитывать несколько ключевых аспектов, основанных на применимом законодательстве и судебной практике.
1. Определение объекта недвижимости: Согласно статье 141.2 Гражданского кодекса Российской Федерации (ГК РФ), земельный участок является недвижимой вещью, и к недвижимым вещам также относятся здания и сооружения, которые создаются в результате строительства (статья 141.3 ГК РФ). Футбольное поле может быть отнесено к объектам недвижимости, если оно соответствует критериям, установленным законом.
2. Необходимые разрешительные документы: В соответствии со статьей 45 Федерального закона № 218, для осуществления государственного кадастрового учета и государственной регистрации прав на искусственно созданный земельный участок (включая футбольное поле) необходимо наличие следующих документов:
Разрешение на ввод в эксплуатацию искусственно созданного земельного участка.
Документация по планировке территории.
Разрешение на создание искусственно созданного земельного участка.
3. Судебная практика: В деле 17085/12 суд указал, что предприниматель, зарегистрировав право собственности на объекты, не имеющие самостоятельного функционального назначения, не может претендовать на оформление прав на земельный участок, если не соблюдены все необходимые разрешительные процедуры. Это подтверждает, что наличие всех разрешительных документов критически важно для регистрации.
4. Регистрация прав на объекты недвижимости: В деле 1160/13 суд отметил, что право собственности на недвижимые вещи подлежит государственной регистрации в ЕГРП (Едином государственном реестре прав на недвижимое имущество и сделок с ним). Это означает, что для регистрации футбольного поля необходимо пройти процедуру государственной регистрации.
Таким образом, для регистрации футбольного поля как объекта недвижимого имущества вам необходимо:
Получить все необходимые разрешительные документы, включая разрешение на ввод в эксплуатацию.
Убедиться, что футбольное поле соответствует критериям, установленным для объектов недвижимости.
Пройти процедуру государственной регистрации прав на это имущество.
Если у вас есть все указанные документы и соблюдены все условия, вы имеете право зарегистрировать футбольное поле как объект недвижимого имущества.
В соответствии с действующим законодательством и судебной практикой, регистрация футбольного поля как объекта недвижимого имущества возможна только при наличии определенных условий.
1. Признаки недвижимого имущества: Согласно пункту 1 статьи 130 Гражданского кодекса Российской Федерации, к недвижимым вещам относятся земельные участки и все, что прочно связано с землей, включая здания и сооружения. Однако, если футбольное поле рассматривается как улучшение земельного участка, а не как самостоятельный объект недвижимости, то оно не может быть зарегистрировано как объект недвижимого имущества.
2. Судебная практика: В судебных актах указано, что такие сооружения, как футбольное поле, представляют собой улучшения земельного участка и не являются самостоятельными недвижимыми вещами. Это подтверждается постановлениями Президиума Высшего Арбитражного Суда Российской Федерации, где указано, что на такие объекты не может быть зарегистрировано вещное право, поскольку они являются неотъемлемой частью земельного участка (постановления от 26.01.2010 № 11052/09 и от 17.01.2012 № 4777/08).
3. Регистрация прав: Если футбольное поле зарегистрировано как часть земельного участка, то право собственности на него может быть оспорено, если оно зарегистрировано за третьими лицами, что ущемляет интересы собственника земельного участка.
Таким образом, если футбольное поле не обладает признаками самостоятельного объекта недвижимости и рассматривается как улучшение земельного участка, то зарегистрировать его как объект недвижимого имущества не получится.
### References
- [1] Постановление Пленума Верховного Суда Российской Федерации от 23.06.2015 № 25
- [2] Постановление Президиума Высшего Арбитражного Суда Российской Федерации от 26.01.2010 № 11052/09
- [3] Постановление Президиума Высшего Арбитражного Суда Российской Федерации от 17.01.2012 № 4777/08
Критерии | Vector RAG | LightRAG (mix) |
Достоверность источников | ✅ | ✅ |
Корректность и полнота вывода | ⚠️ | ✅ |
LightRAG дал обоснованный и юридически более корректный ответ: футбольное поле – это улучшение земельного участка, а не самостоятельный объект недвижимости, поэтому зарегистрировать на него право собственности, в общем, нельзя.
Vector RAG также сослался на реальные нормы, судебные акты (интересно, что RAG-системы при ответе ориентировались на различные судебные постановления), ссылки на которые корректно атрибутированы. Однако его вывод получился общим и дезориентирующим пользователя относительно практических шансов зарегистрировать футбольное поле как объект недвижимости.
Вот как вопрос-ответ могут выглядеть в веб-интерфейсе LightRAG:

Вопрос 2: Интересует хронология судебного спора о признании права собственности ООО «Верево» на мелиоративные системы.
Дело «Верево» о квалификации инженерных (мелиоративных) систем в качестве движимого / недвижимого имущества является хорошо известным среди российских юристов, специализирующихся на гражданском праве.
Постановление Президиума Высшего Арбитражного Суда РФ от 17.01.2012 по данному делу является примером прецедентного судебного решения, после которого коренным образом изменилась практика по аналогичным делам. Дело рассматривалось около 7 лет: много дат, фактов и других обстоятельств — есть в чем запутаться!
Полные ответы систем на Вопрос 2:
Ответ Vector RAG:1. Начало спора: Общество "Верево" обратилось в арбитражный суд с иском о признании права собственности на спорные объекты, находящиеся на земельных участках в деревнях Зайцево и Большое Верево. Это произошло после реорганизации, в ходе которой все имущество ЗАО "Верево" было передано в уставный капитал корпорации, а затем, в результате выделения, передано вновь образованному ОАО "Верево" (Дело ВАС-4777/2008, решение от 17.01.2012).
2. Подтверждение прав на объекты: В иске общество ссылалось на наличие межевых дел, технических паспортов и выписок из генерального плана, подтверждающих нахождение мелиоративных систем на земельных участках, что является важным для установления прав собственности на объекты недвижимости (Дело ВАС-4777/2008).
3. Решение суда: Суд, рассматривая дело, должен был учитывать положения Гражданского кодекса, касающиеся защиты прав собственности и других вещных прав. В частности, согласно статье 301 Гражданского кодекса, собственник имеет право на защиту своего права, что также применимо к случаям, когда право собственности оспаривается (Дело 12505/13, решение от 24.12.2013).
4. Обжалование и последствия: В случае, если суд первой инстанции отказывает в удовлетворении иска, общество "Верево" имеет право на обжалование решения, что подтверждается нормами Гражданского процессуального кодекса (статья 274 ГПК РФ). Важно отметить, что в случае обжалования, суд должен учитывать все обстоятельства дела, включая наличие доказательств, подтверждающих право собственности (Дело 306-ЭС15-20155, решение от 02.06.2016).
5. Заключение: Спор о праве собственности на мелиоративные системы ООО "Верево" подчеркивает важность наличия документальных подтверждений прав на объекты недвижимости, а также необходимость соблюдения процессуальных норм при рассмотрении дел о признании прав собственности. Судебная практика показывает, что наличие четких доказательств и соблюдение всех процедурных требований являются ключевыми факторами в разрешении подобных споров.
Хронология судебного спора о признании права собственности ООО "Верево" на мелиоративные системы включает несколько ключевых этапов:
1. Исковое заявление: Общество "Верево" подало иск в Арбитражный суд города Санкт-Петербурга и Ленинградской области с требованием признать за ним право собственности на гидротехнические сооружения, которые были частью мелиоративной системы, и зарегистрировать это право.
2. Решение суда первой инстанции: Арбитражный суд города Санкт-Петербурга и Ленинградской области удовлетворил исковые требования общества "Верево" и признал его право собственности на спорные объекты. Это решение было принято 08.12.2006.
3. Апелляция: Решение суда первой инстанции было отменено Федеральным арбитражным судом Северо-Западного округа 09.03.2006, и дело было передано на новое рассмотрение.
4. Новые требования: В процессе нового рассмотрения дела общество "Верево" уточнило свои исковые требования, настаивая на том, что спорные сооружения являются объектами недвижимости и принадлежали его правопредшественнику.
5. Решение по уточненным требованиям: Арбитражный суд города Санкт-Петербурга и Ленинградской области 01.03.2010 удовлетворил уточненные исковые требования общества "Верево", признав его право собственности на гидротехнические сооружения.
6. Кассационная жалоба: В дальнейшем, решение суда первой инстанции было обжаловано, и Президиум Высшего Арбитражного Суда Российской Федерации 17.01.2012 отменил решение суда первой инстанции и отказал в удовлетворении исковых требований общества "Верево".
7. Итог: В результате, суды пришли к выводу, что спорные объекты не имеют самостоятельного функционального назначения и являются неотъемлемой частью земельного участка, на котором они расположены, что повлияло на решение о праве собственности.
Эта хронология показывает, что дело прошло через несколько инстанций и изменений в исковых требованиях, что является характерным для сложных споров о праве собственности на недвижимость.
### References
- [1] Судебное решение по делу о праве собственности общества «Верево» на гидротехнические сооружения.
- [2] Постановление Тринадцатого арбитражного апелляционного суда от 04.12.2007.
- [3] Постановление Высшего Арбитражного Суда Российской Федерации от 17.01.2012.
Критерий | Vector RAG | LightRAG (mix) |
Достоверность источников | ❌ | ✅ |
Полнота и связность хронологии | ❌ | ✅ |
Корректность и полнота вывода | ❌ | ✅ |
Vector RAG выдал набор разрозненных утверждений о деле, не выстроив хронологию, сослался на нерелевантную судебную практику, добавив "галлюцинации", вызванные затруднениями модели, отработавшей на неполном и противоречивом контексте.
LightRAG же, в целом, отлично справился с задачей, собрав связную хронологию — от подачи иска до итогового постановления Президиума ВАС, верно установив исход: в иске обществу «Верево» отказано, поскольку спорные гидротехнические сооружения признаны неотъемлемой частью земельного участка (ст. 135 ГК РФ) и не имеют самостоятельного назначения.
Именно на таких запросах преимущество графов знаний очевидно: восстановить хронологию из текста, где события одного дела разнесены по разным его частям и переплетены между собой, векторное сходство не позволяет. Граф же связывает их через общие сущности (дело, суд, объект) и позволяет пройти по цепочке, демонстрируя суть multi‑hop reasoning.
Вопрос 3: В пользу какой стороны должен вынести решение суд, и почему?
Описание кейса, подаваемое на "вход":Обстоятельства дела: Администрация сельского поселения, являясь собственником земельного участка со стадионом, передала его в аренду предпринимателю для эксплуатации стадиона. Арендатор зарегистрировал право собственности на футбольное поле, расположенное на арендованном участке, в ЕГРП как на объект недвижимости. Узнав о госрегистрации, Администрация обратилась в суд с иском о признании отсутствующим права собственности предпринимателя на футбольное поле.
Позиция истца (Администрации): Футбольное поле не является самостоятельным объектом недвижимости, а представляет собой улучшение земельного участка. Арендатор не имел права регистрировать право собственности на объект, так как участок предоставлялся для эксплуатации, а не для строительства.
Позиция ответчика (Предпринимателя): Футбольное поле является объектом недвижимости, так как прочно связано с землей, зарегистрировано в ЕГРП, и право собственности арендатора возникло в силу создания объекта на арендованном участке.
Такой вопрос требует полноценного юридического рассуждения (legal reasoning): нужно выявить ключевые юридические вопросы, которые требуют разрешения, корректно применить нормы права, сослаться на релевантную практику и прийти к верному выводу в условиях, когда позиции сторон (подаются в описании кейса) выглядят аргументированно.
Полные ответы систем на Вопрос 3:
Ответ Vector RAG:1. ПРАВОВАЯ КВАЛИФИКАЦИЯ
Суд должен вынести решение в пользу ответчика (Предпринимателя), так как футбольное поле, зарегистрированное в ЕГРП, является самостоятельным объектом недвижимости, что подтверждается его прочной связью с землей и фактом регистрации. Согласно статье 272 ГК РФ, права на недвижимость, оставленную собственником на земельном участке, определяются в соответствии с соглашением между собственником участка и собственником соответствующего недвижимого имущества. В данном случае, аренда подразумевает возможность создания объектов на арендованном участке, что подтверждается делом 17085/12 от 28.05.2013, где суд указал на возможность защиты прав арендатора на объекты, созданные на арендованной земле.
2. КЛЮЧЕВЫЕ ПРИЗНАКИ
- Футбольное поле зарегистрировано в ЕГРП как объект недвижимости.
- Объект прочно связан с землей и был создан на арендованном участке.
- Арендатор имел разрешение на эксплуатацию стадиона, что подразумевает возможность создания объектов на этом участке.
3. ДОКАЗАТЕЛЬНАЯ БАЗА
- Договор аренды земельного участка, подтверждающий право арендатора на использование земли.
- Свидетельства о государственной регистрации права собственности на футбольное поле.
- Разрешительная документация на строительство и эксплуатацию стадиона.
4. КАРТА РИСКОВ
- Риск: Возможность признания футбольного поля улучшением земельного участка и, как следствие, отсутствие права собственности у арендатора.
- Вероятность: Средняя, учитывая позицию истца.
- Способы минимизации: Подготовка дополнительных документов, подтверждающих право арендатора на создание объектов на арендованной земле, а также привлечение экспертов для оценки статуса футбольного поля как самостоятельного объекта недвижимости.
Таким образом, суд должен учесть все представленные доказательства и правовые нормы, подтверждающие право арендатора на футбольное поле, и вынести решение в его пользу.
1. ПРАВОВАЯ КВАЛИФИКАЦИЯ
- Суд должен вынести решение в пользу истца (Администрации). Согласно статье 130 Гражданского кодекса РФ, к недвижимым вещам относятся земельные участки и все, что прочно связано с землей. Однако, если объект не обладает признаками самостоятельного объекта недвижимости, он не может быть зарегистрирован как таковой. В данном случае, футбольное поле, как улучшение земельного участка, не является самостоятельным объектом недвижимости, поскольку его основное назначение связано с эксплуатацией стадиона, а не с его строительством.
- Судебная практика подтверждает, что если объект не имеет статуса самостоятельного недвижимого имущества, то регистрация права собственности на него может быть признана недействительной. В данном случае, аренда была предоставлена для эксплуатации, а не для строительства, что также подтверждает позицию истца.
2. КЛЮЧЕВЫЕ ПРИЗНАКИ
- Футбольное поле расположено на арендованном земельном участке.
- Арендатор зарегистрировал право собственности на футбольное поле в ЕГРП.
- Участок был предоставлен для эксплуатации стадиона, а не для строительства.
3. ДОКАЗАТЕЛЬНАЯ БАЗА
- Доказательства, подтверждающие, что футбольное поле является улучшением земельного участка, а не самостоятельным объектом недвижимости.
- Документы, подтверждающие условия аренды, в которых указано, что участок предоставлен для эксплуатации.
4. КАРТА РИСКОВ
- Риск: Признание права собственности арендатора на футбольное поле.
- Оценка вероятности: Высокая, учитывая регистрацию права в ЕГРП.
- Способ минимизации рисков: Убедиться в правильности регистрации и наличии всех необходимых разрешений на строительство и эксплуатацию объектов на арендованном участке.
Таким образом, суд должен признать, что футбольное поле не является самостоятельным объектом недвижимости, а представляет собой улучшение земельного участка, что подтверждает позицию истца.
Для системной оценки legal reasoning воспользуемся структурой IRAC — классического формализованного шаблона юридического анализа.
Аббревиатура IRAC раскладывает разбор правового вопроса на четыре последовательных шага:
Issue: выявление / идентификация юридической проблемы,
Rule: определение применимых правил,
Application: анализ фактов через призму "правил" и
Conclusion: вывод.
Выбор IRAC здесь не случаен ещё и потому, что он лежит в основе LegalBench — наиболее известного бенчмарка для оценки legal reasoning языковых моделей. Бенчмарк имеет ограничения, связанные с английским языком и вопросами с проблематикой преимущественно американской юрисдикции. Однако на сегодняшний день он является единственным глубоко проработанным бенчмарком подобного рода, а схема IRAC, несмотря на свои ограничения, сама по себе, может претендовать на универсальность (подробнее о юридических бенчмарках, включая LegalBench, можно ознакомиться в статье Law & Practice Ensemble RAG. Как создать ИИ‑ассистента, помогающего решать многоаспектные юридические задачи, 2 часть)
Применим этот шаблон к ответам обеих систем.
Ожидалось, что системы сошлются на релевантный кейс, фабула которого была положена в основу задания — постановления Президиума ВАС РФ № 17085/12 от 28.05.2013 г.
Что решил суд в аналогичных обстоятельствах:Суд решил спор в пользу администрации: футбольное поле признано улучшением земельного участка, не являющимся самостоятельной вещью; регистрация улучшений на участке произведена в нарушение арендных обязательств, а потому право собственности предпринимателя на такие улучшения необходимо признать отсутствующим.
IRAC | Vector RAG | LightRAG (mix) |
Issue | ✅ | ✅ |
Rule | ❌ | ⚠️ |
Application | ❌ | ✅ |
Conclusion | ❌ | ✅ |
Обе системы прошли шаг Issue, правильно определив один из ключевых правовых вопросов.
На шаге Rule Vector RAG сослался на НЕприменимую здесь статью 272 ГК РФ (Последствия утраты собственником недвижимости права пользования земельным участком).
Далее Vector RAG сослался на реальное и прямо относящееся к делу Постановление Президиума ВАС № 17085/12 (то самое, что лежит в основе кейса), но не смог извлечь из него "правильный" смысл (постановление вынесено против предпринимателя, Vector RAG же привёл его как довод в пользу предпринимателя, истолковав как "подтверждающее права арендатора на объекты, созданные на арендованной земле"). Иными словами, система нашла нужный документ, но прочла не то, что нужно и закономерно пришла к неверному выводу.
Полагаю, здесь, как раз, и проявились ограничения "чистого" векторного поиска. В тексте Постановления Президиума ВАС № 17085/12 кратко были перечислены решения, принятые нижестоящими инстанциями: постановления первой и кассационной инстанций были признаны Президиумом "неправильными", но это, видимо, не смог уловить векторный поиск, вытащив набор семантически близких чанков.
LightRAG, в целом, прошёл всю цепочку корректно.
Здесь, впрочем, нужна честная оговорка. Корректный вывод LightRAG опирается на верное, но неполное основание. То же постановление № 17085/12 обосновано, главным образом, обязательственным характером отношений (аренда). Квалификация объекта имущества как улучшения земельного участка, принадлежащего администрации, рассматривалась именно с точки зрения арендных обязательств, которые нарушил предприниматель, зарегистрировав в свою пользу улучшения земельного участка (футбольное поле и др.), вообще не являющиеся вещью. Соответственно полный ответ должен был бы содержать ссылку на нормы об аренде (ст. 263, 622, 623 ГК РФ: кому принадлежит возведённое на участке, и на что вправе претендовать арендатор). Таким образом, LightRAG дал верный вывод на усечённом основании.
Во всех трех случаях преимущество LightRAG проявлялось там, где ответ на вопрос требовал предварительно выстроить логику между нелинейно связанными фрагментами и сущностями: один этап дела с другим, фабулу кейса — со сложным текстом судебного постановления, в котором одновременно содержатся противоположные выводы разных инстанций.
Векторный поиск, даже продвинутый, оперирует семантической близостью отдельных чанков, а близость (сходство) не всегда равна адекватным вопросу связям. Два фрагмента одного дела могут быть семантически непохожи, а похожие чанки — относиться к разным делам.
Что подтвердилось
Граф знаний в гибридном режиме дает "юридическому" RAG реальное, измеримое преимущество, но на определенном классе задач: там, где ответ требует связать разнесенную по корпусу информацию в цепочку. Восстановление хронологии многолетнего дела, удержание смысла прецедента, корректная квалификация объекта со ссылкой на сложную линию из судебной практики — это задачи, главным образом, о связях, и граф решает их структурно, в то время как векторный поиск вынужден угадывать связь через семантическое сходство, которое связи не гарантирует. Гипотеза, выведенная из топологии, подтвердилась на практике.
Что потребовалось для этого
Граф "из коробки" был структурно непригоден для качественного поиска, и довести его до рабочего состояния позволила только систематическая и кропотливая оптимизация: слияние дубликатов, восстановление иерархии "статья → кодекс", доменная таксономия типов. Важно, что вся эта работа выполнена без переиндексации: возможность инкрементальных обновлений — преимущество фреймворка.
Топологические характеристики графа и анализ центральностей его узлов послужили рабочим инструментом контроля качества: именно метрики показали, что чинить, и подтвердили, что в итоге починилось.
Выявленные ограничения:
Пятая часть узлов осталась изолированной. Отчасти это свойство асимметричного корпуса, но и предел нашей пост‑обработки. Ручные эвристики оптимизации не масштабируются на тысячи актов — путь к большим корпусам лежит через доменную типологию на этапе извлечения и, на действительно больших объемах, через обучаемые NER‑компоненты, цена которых — дорогая экспертная разметка.
Для адекватной оценки RAG‑систем требуется разработка юридического бенчмарка, ориентированного на российскую правовую систему. Например, верный вывод системы не всегда означает полное юридическое обоснование, а само юридическое рассуждение, его наполненность ссылками на корректно приведенные нормы и прецеденты представляют собой практическую ценность. Эти вещи необходимо учитывать при подготовке тестов.
И наконец, качество автоматически построенного на текстах графа неизбежно упирается в качество извлечения на этапе индексации: артефакты препроцессинга и недетерминированность LLM никуда не исчезают, их можно лишь уменьшать и контролировать.
Что дальше? 🚀
Логичное продолжение — переход к агентной архитектуре, системе, где поверх хранилищ знаний появляется управляющий слой: например, маршрутизатор, решающий, в какой источник направить запрос (векторный индекс, граф, веб); многоуровневые guardrails — от проверки релевантности контекста до детекции галлюцинаций в готовом ответе; human-in-the-loop в точках неопределённости и честный отказ, когда ответ не проходит проверки.
Спасибо за внимание! Надеюсь, было интересно, готов ответить на вопросы в комментариях.