За последний год автор поста на r/LocalLLaMA много работал со структурированными юридическими данными и собрал подборку визуализаций графов знаний, построенных по ходу этой работы. Каждое представление в подборке демонстрируется по 5 секунд, и такой темп подобран осмысленно: за пару минут видно, насколько по-разному можно показать одни и те же связи между нормами, статьями и прецедентами. Исходники закрыты, но сам пост ценен как срез подходов. Подборка визуализаций графов знаний
Главный тезис автора отрезвляет тех, кто ждёт от графов прорыва в агентных системах: графы знаний он не считает особо полезными для агентов, но охотно использует их как инструмент визуализации. Похожую картинку, по его словам, несложно воссоздать на 3js, а среди открытых альтернатив он называет graphiti.
Ниже разберём, что такое граф знаний, чем он отличается от таблиц, какими инструментами его рисуют и в каких сценариях он окупает затраты на поддержку.
Что такое граф знаний и зачем он нужен в AI-проектах
Граф знаний описывает предметную область набором узлов и связей. Узел - конкретная сущность: статья закона, судебный акт, компания, договор, термин. Ребро - типизированное отношение с направлением: «ссылается на», «отменяет», «уточняет», «вступает в силу после». У рёбер бывают свойства: дата, источник, уверенность извлечения, версия документа. В юридической сфере такая схема ложится на данные естественно, потому что сами нормы устроены как сеть перекрёстных отсылок.
В AI-проектах граф знаний решает одну из двух задач: даёт структурированный контекст для поиска и генерации либо служит картой, по которой видно устройство корпуса.
Граф знаний vs традиционные базы данных
В реляционной базе связь между двумя записями вычисляется в момент запроса: внешний ключ плюс JOIN. Чем глубже цепочка, тем дороже запрос, и на четвёртом-пятом уровне вложенности SQL начинает заметно проигрывать по времени. Документные базы вкладывают связанные данные внутрь документа, что удобно для чтения одного объекта и неудобно для обхода всей сети ссылок.
Графовая модель хранит связи как объекты первого класса: ребро лежит рядом с узлом, обход идёт по указателям, а не по индексам. Запросы формулируются на Cypher, Gremlin или SPARQL и читаются почти как фразы на естественном языке: «найди статьи, которые ссылаются на отменённые нормы, но сами не отменены».
Обратная сторона: граф избыточен, когда связи простые. Если у вас каталог товаров с одной связью «принадлежит категории», JOIN дешевле и поддерживать его проще. Граф окупается на многоуровневых и разнотипных связях, а также там, где важно видеть не отдельную запись, а всю окрестность узла.
Роль графов знаний в RAG и агентах
Классический RAG режет документы на чанки и ищет по эмбеддингам. Связи между фрагментами при этом теряются: фраза «см. статью 22» остаётся текстом внутри чанка, а не указателем на нужный узел. Граф знаний возвращает эти связи в пайплайн: из документов извлекаются сущности и отношения, поиск находит точку входа, дальше по графу набирается подграф, и в контекст модели уходит не пять случайных чанков, а связная окрестность. Как это выглядит на уровне архитектуры, разобрано в материале про шесть паттернов GraphRAG: от Text-to-Cypher и гибридного поиска до Graph-First и агентного обхода.
С агентами картина спорнее. Граф может служить средой планирования: состояние агента - узел, переход - ребро, а по графу видно, какие действия уже выполнены. Автор подборки прямо говорит, что не считает графы знаний особо полезными для агентов, и у этого есть основания: извлечение графа через LLM стоит токенов, даёт ошибки в связях и требует синхронизации при каждом обновлении документов. Агент с юридическими документами может использовать граф для навигации по ссылкам, но на коротких вопросах по одному документу векторный поиск справится быстрее и дешевле.
Визуализация графов знаний: подходы и инструменты
В подборке каждая визуализация держится на экране 5 секунд, и это осмысленный формат для сравнения: за такое время видно, как расположены узлы, есть ли выраженные хабы, насколько читаемы подписи и как ведёт себя компоновка при разном числе связей. Репозиторий с примерами не публичный, поэтому конкретные реализации посмотреть нельзя, и это ограничение стоит держать в голове: оценивать приходится по видео, а не по коду.
Визуализация помогает увидеть структуру корпуса: какие статьи собирают десятки ссылок, где образовались изолированные кластеры, есть ли циклы взаимных отсылок. Сама по себе картинка не проверяет корректность данных и не заменяет валидацию связей.
Инструмент 3js для визуализации графов
Под 3js автор, скорее всего, имеет в виду three.js - JavaScript-библиотеку для 3D-графики в браузере поверх WebGL. Она даёт минимум готовых решений: сцена, камера, рендерер, геометрия, материалы, шейдеры. Граф собирается вручную: узлы - сферы или спрайты, рёбра - линии или тонкие цилиндры, позиции считает алгоритм раскладки, обычно force-directed.
Схематичный каркас выглядит так:
const graph = {
nodes: [
{ id: "ст-15", group: "закон", x: 0, y: 0, z: 0 },
{ id: "ст-22", group: "закон", x: 5, y: 2, z: -3 }
],
edges: [
{ source: "ст-15", target: "ст-22", type: "ссылается" }
]
};
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(60, innerWidth / innerHeight, 0.1, 2000);
const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(innerWidth, innerHeight);
document.body.appendChild(renderer.domElement);
const nodeGeometry = new THREE.SphereGeometry(1, 16, 16);
const nodeMaterial = new THREE.MeshBasicMaterial({ color: 0x4c9aff });
graph.nodes.forEach((node) => {
const mesh = new THREE.Mesh(nodeGeometry, nodeMaterial);
mesh.position.set(node.x, node.y, node.z);
scene.add(mesh);
});
Дальше добавляются рёбра через буферную геометрию, подписи через спрайты с canvas-текстурой и контролы для вращения сцены. API three.js меняется от версии к версии, поэтому конкретные вызовы стоит сверять с актуальной документацией библиотеки.
Порог, после которого наивная отрисовка перестаёт работать, лежит в районе нескольких тысяч узлов. Спасают инстансинг, объединение рёбер в один буфер, отсечение по видимости и упрощение геометрии на дальних узлах. Для статичных отчётов хватает 2D-раскладок: силовых в d3 или рендера в sigma.js. Трёхмерная сцена нужна, когда объём связей реально требует третьего измерения.
Открытые альтернативы: graphiti и другие
Свой репозиторий автор не открывал, но упоминает, что хороших открытых решений много, и приводит в пример graphiti. Что именно умеет проект на текущей версии и насколько он подходит под вашу схему данных, проверяйте по его документации: набор возможностей у таких инструментов меняется быстро, а переносить чужие ожидания на конкретный релиз рискованно.
Если нужен только слой хранения и обхода, подойдут графовые базы вроде Neo4j. Для анализа и вычислений на графе в Python часто берут NetworkX, для интерактивной отрисовки в браузере - Cytoscape.js или sigma.js. Выбор диктует задача: визуализация связей и продакшен-поиск по графу требуют разных инструментов.
Практическое применение: графы знаний для юридических данных
Юридический корпус устроен как многоуровневая сеть. Верхний уровень - кодексы и законы, ниже - главы, статьи, пункты и подпункты, сбоку - судебные акты и разъяснения, отдельно - глоссарий терминов. Узлы соединяются отсылками: «в порядке, предусмотренном статьёй 15», «в редакции, действовавшей до 1 января», «признать утратившим силу». Одна статья легко собирает сотни входящих ссылок.
В таблицах такие данные живут плохо. Ссылка внутри текста нормы - это связь, которую приходится либо парсить в рантайме, либо хранить отдельной таблицей связей, что по сути повторяет граф, но без удобных запросов по нему. На графе можно за один обход получить окрестность статьи, проверить, не ссылается ли действующая норма на отменённый пункт, или найти статьи, которые никто не цитирует и которые, возможно, потеряли актуальность.
Визуализация здесь даёт то, чего не даёт список ссылок: распределение. Узлы с высокой степенью сразу показывают нормы-хабы, вокруг которых держится регулирование, изолированные фрагменты подсказывают места, где парсер не нашёл связей, а плотные кольца выдают циклы взаимных отсылок.
Особенности юридических данных
Четыре свойства отличают этот домен от большинства других. Первое: перекрёстные ссылки почти всегда внутритекстовые, их приходится извлекать из формулировок, а не из готовых полей. Второе: жёсткая иерархия, где уровень вложенности влияет на юридическую силу. Третье: версионность, причём у одной и той же статьи одновременно существуют разные редакции, и связь «действует» зависит от даты. Четвёртое: терминологическая связность, когда определения из глоссария работают на весь документ.
Версионность - самый неприятный пункт для графа. Простое ребро без временных меток соврёт при первом же запросе к историческим данным. На практике к рёбрам добавляют интервал действия, а выборку ограничивают датой; без этого граф показывает смесь редакций разных лет.
Графы знаний для агентов: ограничения и реальная польза
Позиция автора подборки сформулирована без оговорок: графы знаний он не считает особо полезными для агентов, но видит в них хороший инструмент визуализации. Аргументы против применения в агентах выглядят так.
- Стоимость поддержки. Граф нужно строить, обновлять при каждом изменении документов и валидировать. Это отдельный пайплайн со своими сбоями.
- Ошибки извлечения. Связи вытаскивает LLM или парсер, и часть рёбер окажется неверной. Плохое ребро хуже отсутствующего: агент уверенно пойдёт не туда.
- Дрейф онтологии. Типы узлов и отношений расползаются по мере роста корпуса, и запросы приходится чинить.
- Задержка. Обход графа и генерация промежуточных запросов добавляют время к ответу, а выигрыш не всегда заметен на коротких вопросах.
Векторный поиск проще: загрузил чанки, посчитал эмбеддинги, получил топ-k. Для вопросов, ответ на которые лежит внутри одного фрагмента, этого достаточно, и городить граф незачем.
Когда графы знаний действительно помогают агентам
Есть сценарии, где связи важнее скорости. Если агенту нужно строго соблюдать иерархию документов и не выходить за пределы ветки, граф работает как ограничитель: допустимые переходы заданы рёбрами, а лишние просто недостижимы. Если требуется отследить версионность, временные метки на рёбрах дают ответ на вопрос «какая норма действовала на эту дату» без пересборки индекса. Если нужен аудит, сам путь агента по узлам становится журналом решений, который можно показать человеку.
Похожий приём, только для кода, разобран в статье про локальный граф кода и MCP-сервер для агентов: агент получает структурированный контекст вместо попыток угадать связи по тексту файлов. Схема с визуальным контролем над агентными системами описана в разборе GraphArc, где граф оркестрации показывается до выполнения шагов.
Все эти случаи нишевые, и объединяет их одно: связи в данных критичны для правильного ответа. Там, где связь не влияет на результат, граф добавляет работу без отдачи.
Как воссоздать визуализацию графа знаний: пошаговый подход
Автор замечает, что похожую картинку несложно собрать на 3js самостоятельно. Порядок действий выглядит так.
- Соберите данные в узлы и рёбра. Минимальный JSON: массив узлов с идентификатором, типом и подписью плюс массив рёбер с полями source, target и type. Тип узла потом станет цветом или формой, тип ребра - толщиной линии.
- Посчитайте раскладку. Силовой алгоритм расталкивает несвязанные узлы и притягивает соседей друг к другу, пока система не стабилизируется. Раскладку можно посчитать один раз и сохранить координаты, чтобы визуализация не «дышала» при каждом открытии.
- Выберите инструмент. Для 3D и интерактива подходит three.js, для быстрых 2D-схем хватает силовых раскладок в d3 или рендера в sigma.js, для статичных изображений годится любой графовый редактор.
- Настройте отображение. Размер узла по числу связей, цвет по типу сущности, порог фильтрации по степени, подписи только для крупных узлов. Без фильтров граф на тысячу узлов превращается в кашу.
- Добавьте интерактивность. Наведение с подсветкой окрестности, поиск по идентификатору, клик с панелью свойств, переключатель даты для версионных рёбер.
Главное ограничение - масштаб. Несколько тысяч узлов браузер ещё тянет, десятки тысяч требуют инстансинга, уровней детализации и рендера в отдельном потоке, а иногда и предварительной агрегации: показывать не все узлы, а кластеры с раскрытием по клику. Для юридического корпуса это актуально: один кодекс даёт тысячи узлов и десятки тысяч рёбер.
Посмотреть, как выглядят живые примеры, можно в подборке автора: пост с визуализациями графов знаний.
Итог: где графы знаний уместны, а где нет
Граф знаний оправдан, когда данные устроены как сеть: много типов связей, глубина вложенности больше двух-трёх уровней, важна версионность и происхождение связи. Юридические документы подходят под это описание идеально, и визуализация такого графа даёт быстрый обзор структуры, который трудно получить другим способом.
Для агентов расчёт другой. Если вопрос решается внутри одного фрагмента, векторный поиск дешевле, проще и предсказуемее. Граф стоит добавлять, когда связи критичны: строгая иерархия, временные редакции, аудит пути решения. Начинать логично с векторной базы и смотреть, где именно она ошибается; граф достраивается под конкретный провал, а не заранее.
Если нужна наглядность, берите three.js и рисуйте. Если нужен продакшен-поиск, изучайте GraphRAG-паттерны и открытые графовые базы. Свой опыт с визуализацией юридических графов полезно сравнивать с чужим: у разных команд одни и те же связи читаются по-разному, и это часто подсказывает, чего не хватает в модели данных.