Прикладной лингвист и data scientist Сергей Слепухин опубликовал продолжение эксперимента с фреймворком LightRAG на юридическом корпусе: 110 решений Верховного Суда РФ по вопросам квалификации объектов имущества за 2006–2023 годы плюс статьи Гражданского кодекса. Первая часть зафиксировала проблему — граф выглядел работоспособным, но топологический анализ обнажил структурные слабости. Вторая часть посвящена тому, как эти слабости устранялись.
LightRAG — это фреймворк для построения графов знаний поверх текстовых корпусов, альтернатива классическому векторному RAG (retrieval-augmented generation). Вместо того чтобы искать релевантные фрагменты по близости эмбеддингов, система извлекает сущности и связи между ними, строит граф и использует его топологию при ответе на запросы. Теоретически это позволяет лучше работать с многошаговыми вопросами, хронологией событий и правовой аргументацией — задачами, где важен контекст связей, а не просто близость текстов.
| Исходные типы LightRAG | Целевой тип после remap |
|---|---|
| law, article, legalreference, legalarticle, legislation, legalprovision | legal_norm |
| artifact, naturalobject, creature, property, product, equipment, material | legal_object |
| concept, project, program, method | legal_concept |
| document, legal_document, legaldocument, contract | document |
| content | legal_content |
| unknown, other | other |
| organization, person, date, currency, measurement, location | оставляем без изменений |
Исходный граф показал три системных дефекта. Первый — двуязычное расщепление: одна и та же сущность существовала как отдельные узлы на русском и английском (Supreme Court of the Russian Federation и Верховный Суд РФ). Второй — разорванная иерархия статей: одна статья кодекса могла присутствовать одновременно как «ст. 130», «статья 130», «статья 130 ГК РФ» и «ст. 130 ГК РФ», причём ни один из этих узлов не был явно связан с центральным узлом-кодексом. Третий — шум в виде инициалов, обрывков ФИО и случайных токенов.
Оптимизация разбита на три последовательных этапа. На первом этапе проводилось слияние дубликатов и нормализация: популярные узлы с парными именованиями на двух языках объединялись через словарь MAPPING_DICT и метод rag.merge_entities(). Этот метод не просто удаляет лишний узел — он перенаправляет все связи в целевую сущность, предотвращает циклы и сохраняет веса рёбер, синхронно обновляя векторное хранилище. Прямая правка внутреннего объекта networkx.Graph в обход встроенных методов технически возможна, но рассинхронизирует граф и векторную базу.
Для масштабирования на большие корпусы ручной словарь не подходит. Автор предлагает двухпроходную схему: на первом шаге библиотека rapidfuzz через метрики нечёткого сравнения строк (расстояние Левенштейна) ловит опечатки и расхождения в регистре. На втором шаге эмбеддинг-кластеризация с многоязычными энкодерами выявляет понятийные синонимы и межъязыковые дубли — то, что символьные методы пропустят из-за разных алфавитов. Полная автоматизация без ручной валидации центральных узлов при этом остаётся нереалистичной: кластеризация по эмбеддингам может объединить сущности разных типов.
Второй этап — стандартизация наименований статей и создание явных рёбер вида «Статья N → part_of → Гражданский кодекс РФ». Без этого шага топологически кодекс и часть его собственных статей существовали как несвязанные компоненты, что напрямую снижало качество поиска по иерархическим запросам. Третий этап — переопределение юридической таксономии сущностей — описан в продолжении материала.
После оптимизации автор сравнивает граф с исходным по топологическим метрикам и тестирует поиск на трёх типах юридических запросов: правовая квалификация объекта, восстановление хронологии дела и legal reasoning по кейсу. Именно на этих задачах графовый подход должен показать преимущество перед классическим векторным RAG — или обнаружить свои ограничения.
