TL;DR
DEG-RAG — метод улучшения графов знаний (knowledge graphs), которые LLM автоматически строят из документов для RAG-систем. Метод работает в два шага: entity resolution убирает дубли сущностей (синонимы, аббревиатуры, разный регистр), triple reflection удаляет ненадёжные связи между сущностями. Уменьшает граф на ~40% и одновременно улучшает качество ответов.
Проблема: когда LLM извлекает сущности из большого объёма текста, она создаёт множество дублей одного понятия. Например, "LLMs", "LLM", "llms", "Large Language Models", "модели большого языка" — всё это разные узлы в графе, хотя означают одно. Это происходит потому что LLM обрабатывает текст батчами и не удерживает в памяти все ранее созданные сущности. Граф раздувается, поиск ухудшается, затраты растут. Плюс в графе появляются ошибочные связи из-за неточностей в исходных документах.
Метод состоит из нескольких технических шагов: блокирование сущностей (группировка кандидатов на слияние), создание векторных представлений (KG embeddings или LLM embeddings), сравнение по сходству, слияние дублей, проверка связей через LLM-as-judge. Исследователи протестировали разные варианты каждого компонента и выявили лучшие комбинации: блокирование по типу сущностей работает лучше семантического, традиционные KG embeddings иногда превосходят LLM embeddings.
Схема метода
Entity Resolution (удаление дублей сущностей):
ШАГ 1: Blocking — группировка похожих сущностей
├─ Semantic blocking: кластеризация по embeddings описаний
├─ Type-based blocking: группировка по типу (персона/место/организация)
└─ Structural blocking: группировка сущностей с общими соседями в графе
ШАГ 2: Matching — поиск дублей внутри групп
├─ Создание embeddings (KG embeddings / LLM embeddings)
├─ Расчёт сходства (ego node / neighbor / type-aware neighbor)
└─ Группировка сущностей с similarity > порога
ШАГ 3: Merging — слияние дублей
├─ Direct merge: один узел остаётся, остальные удаляются, связи переносятся
├─ Synonym linking: дубли остаются, добавляются связи "синоним"
└─ Merge + linking: слияние атрибутов + связи-синонимы
Triple Reflection (очистка связей):
ШАГ 4: LLM оценивает надёжность каждой связи (entity1, relation, entity2)
ШАГ 5: Удаляются связи с оценкой ниже порога
Все шаги требуют инфраструктуры: API, векторные БД, embeddings модели, код.
Пример применения
⚠️ Важно: Метод требует инфраструктуры (API, векторные БД, embeddings, код). Примеры ниже показывают концепцию, а не прямое применение в чате.
Концепция 1: Обнаружение дублей при работе с информацией
Задача: Ты собираешь информацию про российский рынок электромобилей из разных источников. В разных статьях встречаются: "Evolute", "Эволют", "бренд Evolute", "российские электромобили Evolute", "Evolute i-Pro".
Принцип из исследования: LLM создаёт дубли сущностей при обработке больших объёмов текста. Нужна явная инструкция на консолидацию.
Промпт:
Я собираю факты про рынок электромобилей.
Вот список упоминаний из разных источников:
- Evolute показал рост продаж
- Эволют открыл новый завод
- бренд Evolute входит в группу КАМАЗ
- российские электромобили Evolute i-Pro
- Evolute i-Pro — флагманская модель
Задача:
1. Определи какие упоминания относятся к одной сущности
2. Выбери каноническое название для каждой группы
3. Покажи связи между сущностями
Формат:
ГРУППА 1: [каноническое название]
- синонимы: [список]
- описание: [краткое]
СВЯЗИ:
- [сущность А] -> [тип связи] -> [сущность Б]
Результат: LLM покажет что "Evolute" и "Эволют" — одна сущность (бренд), "Evolute i-Pro" — отдельная (модель), связь "Evolute производит Evolute i-Pro". Ты получишь структурированную карту сущностей вместо хаоса дублей.
Концепция 2: Проверка надёжности утверждений (Triple Reflection)
Задача: Готовишь презентацию про влияние нейросетей на рынок труда. Нашёл утверждение: "ChatGPT привёл к сокращению 30% дизайнеров в IT-компаниях России в 2024 году".
Принцип из исследования: Triple reflection — LLM оценивает надёжность связи между сущностями.
Промпт:
Оцени надёжность этого утверждения по шкале 0-1:
"ChatGPT" -> "привёл к сокращению" -> "30% дизайнеров в IT-компаниях России в 2024"
Критерии:
- Есть ли причинно-следственная связь?
- Можно ли проверить цифры?
- Нет ли логических противоречий?
Формат ответа:
Оценка: [0.0-1.0]
Аргументы ЗА: [список]
Аргументы ПРОТИВ: [список]
Вывод: [использовать / проверить дополнительно / отклонить]
Результат: LLM укажет что связь слабая (корреляция vs причинность), цифра "30%" не верифицируема, нужен дополнительный фактчекинг. Получишь сигнал проверить источник перед включением в презентацию.
Почему это работает
Слабость LLM: При обработке больших объёмов текста батчами модель не удерживает в памяти все ранее созданные сущности. Обрабатывая 100-й документ, она не "помнит" что в документе №5 уже создала сущность "Large Language Models" — и создаёт дубль "LLMs". Результат: граф с десятками узлов для одного понятия.
Структурное решение проблемы: Entity resolution использует векторные представления (embeddings) для поиска семантически идентичных сущностей. TransE, ComplEx и другие KG embeddings учитывают не только текст описания, но и структурный контекст — с какими сущностями связан узел, через какие отношения. Это ловит дубли которые пропустит простое string matching.
Рычаги управления (для технической реализации):
- Entity reduction ratio (40% по умолчанию) → уменьши до 20% для консервативной очистки, увеличь до 60% для агрессивного сжатия
- Blocking strategy (type-based / semantic / structural) → type-based для доменных графов, structural для сильно связанных графов
- Similarity threshold δ_ER → подними для точного matching (меньше ложных слияний), понизь для полноты (больше дублей найдётся)
- Triple reflection threshold δ_TR (0.2 по умолчанию) → подними до 0.5 для строгой фильтрации ненадёжных связей
Особенность: исследование показало что type-aware blocking (группировка сущностей одного типа: персоны/места/организации) эффективнее семантического clustering. Это работает потому что типы дают естественную границу — "Apple" как компания и "apple" как фрукт не должны сливаться, хотя семантически близки.
Ограничения
⚠️ Требует инфраструктуры: Метод работает только с технической реализацией — нужен API к LLM, векторные базы данных (Llama Index), embeddings модели, KG база, код на Python. Невозможно применить в обычном чате ChatGPT/Claude.
⚠️ Только для Graph-RAG систем: Ценность только если ты строишь собственную RAG-систему с графами знаний. Для обычной работы с LLM в чате это не применимо напрямую.
⚠️ Риск ошибочных слияний: Если порог similarity слишком низкий, метод может слить разные сущности ("Apple компания" + "Apple фрукт"). Требует настройки под конкретный домен.
⚠️ Зависимость от качества embeddings: Для редких доменов (узкая специализация, редкие языки) LLM embeddings могут работать хуже традиционных KG embeddings, как показали эксперименты на Legal и Agriculture датасетах.
Ресурсы
Less is More: Denoising Knowledge Graphs for Retrieval Augmented Generation — исследование методов очистки LLM-генерируемых графов знаний, сравнение blocking стратегий, entity embeddings (TransE, DistMult, ComplEx, CompGCN, R-GCN, LLM embeddings), matching techniques, merging approaches
Авторы: Yilun Zheng, Dan Yang, Jie Li (Nanyang Technological University), Lin Shang (Nanjing University), Lihui Chen, Jiahao Xu (Nanyang Technological University), Sitao Luan (Mila, Quebec AI Institute / University of Montreal)
Код: https://github.com/157114/Denoise
Связанные работы: LightRAG (Guo et al., 2024), MS GraphRAG (Edge et al., 2024), HippoRAG (Jimenez Gutierrez et al., 2024) — Graph-based RAG системы которые исследователи улучшили через denoising