RAG научил модель отвечать по твоим данным: нашли похожие куски текста — подмешали в промпт. Но у «похожих кусков» есть потолок, в который упираются реальные системы. Следующая ступень — дать модели не куски текста, а структуру знаний: понятия и связи. Это и есть граф знаний — онтология, заполненная фактами.

Где векторный поиск слеп

Векторный RAG находит фрагменты, похожие на вопрос по смыслу. Это отлично работает для вопросов вида «что такое X» — ответ лежит в одном-двух кусках. И плохо — для трёх классов вопросов:

  • Многошаговые. «Какие сервисы затронет изменение контракта платёжного API?» Ответ нигде не написан одним куском — он выводится по цепочке связей: контракт → кто его потребляет → кто зависит от потребителей. Векторный поиск найдёт документ про контракт, но не пройдёт по цепочке.
  • Агрегирующие. «Сколько у нас интеграций с внешними провайдерами?» Ответ — это подсчёт по всей базе знаний, а не фрагмент текста.
  • Точные связи. «Кто владелец сервиса X?» — похожих кусков много (упоминания в разных доках, старые и новые), а нужен один достоверный факт, не «наиболее похожий абзац».

Общая причина: текст хранит знания неявно, размазанными по формулировкам. Чтобы отвечать на вопросы о связях, связи нужно хранить как связи.

Граф знаний: факты вместо абзацев

Граф знаний хранит знания в виде фактов-троек: субъект → отношение → объект. «payment-service — потребляет — orders-api», «orders-api — принадлежит — команде checkout». Узлы — понятия, рёбра — связи.

А чтобы граф не превратился в свалку произвольных стрелок, нужна онтология — схема графа: какие бывают типы узлов (сервис, команда, контракт), какие отношения допустимы (сервис потребляет контракт, но не «сервис дружит с командой»), какие правила действуют. Онтология для графа — то же, что модель понятий для продукта: без неё каждый пишет факты в своём словаре, и граф не срастается.

По графу можно ходить: от контракта к потребителям, от них — к зависимым, сколько угодно шагов, с точным и проверяемым результатом на каждом. Ровно то, чего не умеет векторный поиск.

GraphRAG: связка графа и модели

GraphRAG — это RAG, где источником для промпта служит не только векторный индекс, но и граф знаний. Типичная схема:

  1. Из вопроса выделяются сущности («платёжный API» → узел orders-api).
  2. По графу обходятся связи вокруг этих сущностей — собирается точный подграф: потребители, владельцы, зависимости.
  3. Подграф (плюс, при необходимости, найденные векторно куски текста) подмешивается в промпт.
  4. Модель формулирует ответ — по фактам со связями, а не по «похожим абзацам».

Модель и граф закрывают слабости друг друга: граф не умеет говорить и понимать вопросы на естественном языке — модель умеет; модель выдумывает и не выводит цепочки надёжно — граф хранит проверяемые факты и связи. LLM здесь ещё и помогает строить граф: извлекать сущности и связи из документов — с обязательной валидацией против онтологии, иначе в граф протекут галлюцинации.

Когда граф оправдан, а когда — перебор

Граф знаний — не апгрейд RAG «по умолчанию», а инструмент со своей ценой: спроектировать онтологию, наполнять и поддерживать актуальность (протухший граф хуже отсутствующего — он уверенно врёт).

  • Не нужен, если вопросы к базе знаний — «найди и перескажи»: обычный RAG дешевле и достаточен.
  • Нужен, когда вопросы — про связи и следствия: анализ влияния изменений, зависимости сервисов и команд, комплаенс («какие системы трогают персональные данные?»), каталоги с отношениями.

И заметь знакомый паттерн: реестр сервисов с владельцами, контрактами и связями между контекстами — такой артефакт мы уже описывали как масштабирование спек до уровня платформы. Это и есть граф знаний твоего продукта, просто записанный в файлах: вопрос «что затронет изменение контракта» по нему — классический обход графа. Онтология, спека и граф знаний — одна дисциплина на разных масштабах: записывай понятия и связи явно — и по ним смогут работать и люди, и агенты.

Коротко

  • Векторный RAG слеп на многошаговых, агрегирующих и точечных вопросах: текст хранит связи неявно.
  • Граф знаний = факты-тройки «субъект → отношение → объект»; онтология — его схема (типы узлов, допустимые связи, правила), без которой граф не срастается.
  • GraphRAG: из вопроса — сущности → обход графа → точный подграф в промпт → ответ по фактам. Модель и граф закрывают слабости друг друга.
  • Цена графа — проектирование онтологии и поддержание актуальности; для «найди и перескажи» хватает обычного RAG, для вопросов о связях и следствиях граф незаменим.
  • Онтология, спека и граф знаний — одна дисциплина явной записи понятий и связей: по ней работают и люди, и агенты.

Это последняя статья куста про модель домена. Вместе с системой понятий, концептуальной моделью, единым языком и спекой у тебя есть полный путь: от «из чего состоит задача» до документа, который исполняет агент, и графа, у которого можно спрашивать.