# Что такое KAG: как он использует граф знаний и исходные тексты

Автор: Ермолаев Тимофей Владимирович  
Оригинал: https://timofei-ermolaev.ru/llm/chto-takoe-kag/  
Опубликовано: 2026-10-19  
Обновлено: 2026-10-22

Представим, что вы помогаете организовать субботний киноклуб. Вы открываете цифрового помощника, который работает с внутренними заметками клуба, и спрашиваете: кому и куда написать насчёт проектора для ближайшего показа и что указать в сообщении?

## Коротко

- KAG заранее связывает факты в графе знаний и сохраняет их привязку к исходным текстам.
- Для ответа Solver строит план операций: найденные сведения становятся входными данными следующих действий.
- Граф помогает пройти цепочку фактов, а связанные текстовые фрагменты сохраняют инструкции и подробности.
- Полнота базы, точность извлечения и актуальность источников определяют качество ответа. Сам граф не гарантирует правильность.

Допустим, в базе киноклуба лежат три отдельные записи:

1. Ближайший показ: «Ближайший показ киноклуба состоится в субботу, 24 октября, в зале „Сосна“».
2. Оборудование зала: «В зале „Сосна“ установлен проектор П-17».
3. Контакт по проектору: «За проектор П-17 отвечает Ирина. По вопросам проектора напишите ей в общий чат киноклуба. В сообщении укажите дату показа и название зала».

По отдельности ни одна запись не даёт полного ответа. В первой нет ни проектора, ни имени, во второй нет даты и контактов, а третья не сообщает, где стоит П-17 и когда пройдёт показ. Но человек легко собирает из них маршрут по повторяющимся названиям и обозначениям: субботний показ ведёт к залу «Сосна» и дате 24 октября, через название «Сосна» находится установленный там проектор П-17, а обозначение П-17 указывает на Ирину и правила обращения из третьей заметки.

При этом сведения делятся на два вида. Короткие переходы от показа к залу, от зала к проектору П-17 и от проектора к Ирине удобно представить как цепочку связанных объектов — граф знаний. А вот подробную памятку из третьей записи («По вопросам проектора напишите ей в общий чат киноклуба. В сообщении укажите дату показа и название зала») не обязательно дробить на мелкие связи: её проще оставить в исходном тексте, привязанном к объекту П-17.

Когда перед глазами всего три короткие строки, они легко помещаются в запрос к языковой модели целиком, и она ответит вообще без графа. Трудность возникает, если эти три заметки лежат среди большого архива документов клуба. Если вспомнить, [как работает RAG](<https://timofei-ermolaev.ru/llm/chto-takoe-rag/>) в простейшем базовом варианте, система за один шаг ищет фрагменты, похожие по смыслу на вопрос. Как отмечают авторы [документации Microsoft GraphRAG](<https://microsoft.github.io/graphrag/>) и [описания KAG](<https://github.com/OpenSPG/KAG/blob/master/README.md>), у такого одношагового поиска по близости есть ограничение: в большой базе третья запись про П-17 и Ирину может не показаться алгоритму похожей на вопрос о «субботнем киноклубе», ведь в самом вопросе не упомянуты ни номер прибора, ни имя. Если же переходы между объектами подготовлены заранее, помощник сначала находит по показу зал «Сосна», от него переходит к обозначению П-17 и уже по этой точной связке вытаскивает нужную третью заметку. Это ограничение относится именно к простому одношаговому отбору: сам подход RAG не запрещает строить многошаговые цепочки запросов, а наш пример помогает разобрать устройство системы, но не доказывает превосходства одного подхода над другим.

Именно для такой работы со связанными фактами и текстами создан KAG (Knowledge Augmented Generation) — фреймворк проекта [OpenSPG/KAG](<https://github.com/OpenSPG/KAG/blob/master/README.md>) для поиска сведений, логического рассуждения и подготовки ответов с участием [большой языковой модели (LLM)](<https://timofei-ermolaev.ru/llm/chto-takoe-bolshie-yazykovye-modeli/>). В этой статье название KAG относится к конкретному фреймворку разработчиков OpenSPG, который опирается на движок графов знаний [OpenSPG](<https://github.com/OpenSPG/KAG#4-quick-start>). Работа в нём разделена на два этапа: сначала система заранее разбирает документы и связывает факты между собой, а затем по этой подготовленной базе собирает ответ на поступивший вопрос.

## Как KAG готовит базу знаний из документов

До того как пользователь задаст вопрос, KAG индексирует документы и выделяет из них подписанные смысловые связи (отношения) между конкретными объектами:

- ближайший показ (с датой 24 октября) — проходит в → «Сосна»;
- «Сосна» — имеет проектор → П-17;
- П-17 — имеет ответственного → Ирина.

Однако одних этих связей для ответа недостаточно: цепочка Показ → «Сосна» → П-17 → Ирина приводит к нужному человеку, но не сообщает, куда именно писать и что указывать в сообщении. Поэтому система не заменяет документы графом, а сохраняет описанную в [README KAG](<https://github.com/OpenSPG/KAG/blob/master/README.md>) взаимную индексацию узлов и связей графа с исходными текстовыми фрагментами. Все три извлечённые связи и их объекты остаются привязанными к первой, второй и третьей записям, а подробная инструкция из третьей заметки остаётся доступной в связанном текстовом отрывке.

В терминологии графа знаний конкретный объект вроде зала «Сосна» или проектора П-17 называется сущностью, а общая категория («Зал», «Проектор») — её типом. Чтобы при разборе текста отношение «проходит в» связывало показ именно с залом, а «имеет ответственного» вело от оборудования к человеку, для нашего примера заданы четыре типа («Показ», «Зал», «Проектор», «Человек»), их свойства (дата, название, обозначение, имя) и допустимые отношения между ними: Показ → Зал → Проектор → Человек. Такое описание структуры и правил в KAG называется схемой. Наш компактный набор из четырёх типов выбран для наглядности и не означает, что перед работой всегда нужно вручную перечислить все возможные связи: по [описанию архитектуры KAG](<https://github.com/OpenSPG/KAG/blob/master/README.md>), фреймворк сочетает построение графа по ограничениям схемы со свободным извлечением сведений без жёстких рамок.

За этот подготовительный этап отвечает подсистема построения — Builder. При индексации, как описано в [статье разработчиков KAG](<https://arxiv.org/html/2409.13731v3>), языковая модель вместе с компонентами обработки выделяет из текста сущности и отношения, а затем согласует одинаковые упоминания между собой. В нашем примере совпадение названий помогает объединить «Сосну» из первой и второй записей в один узел зала, а П-17 из второй и третьей — в один проектор (в общем случае согласование не сводится только к буквальному совпадению строк). Без этого шага три заметки остались бы разрозненными. Автоматическое извлечение не гарантирует безошибочного результата, но для разбора механизма будем считать, что исходные записи не противоречат друг другу, а сущности и связи извлечены корректно.

До вопроса: подготовка базы

**Три исходные записи**

1. Запись 1**Ближайший показ**

   Ближайший показ киноклуба состоится в субботу, 24 октября, в зале «Сосна».
2. Запись 2**Оборудование зала**

   В зале «Сосна» установлен проектор П-17.
3. Запись 3**Контакт по проектору**

   За проектор П-17 отвечает Ирина. По вопросам проектора напишите ей в общий чат киноклуба. В сообщении укажите дату показа и название зала.

**Builder**

Из трёх записей извлекает сущности и связи, согласует одинаковые упоминания.

**Граф со ссылками на записи**

Показ

**Ближайший показ**24 октября

проходит взапись 1

Зал

**«Сосна»**

имеет проекторзапись 2

Проектор

**П-17**

имеет ответственногозапись 3

Человек

**Ирина**

**Исходные тексты сохранены**

Все три записи остаются связаны с графом. У каждой связи указан её источник.

**Инструкция из записи 3**

Написать Ирине в общий чат киноклуба. В сообщении указать дату показа и название зала.

Правило — из записи 3.
Дата 24 октября и зал «Сосна» — из записи 1.

## Как KAG собирает ответ на вопрос

Когда поступает вопрос «Кому и куда написать насчёт проектора для субботнего киноклуба и что указать в сообщении?», в работу вступает подсистема решения задач — Solver. Она разбирает обращение и выстраивает маршрут по подготовленной базе.

В нашем примере решение раскладывается на четыре операции:

| Операция | Что получает на вход | Что возвращает |
| --- | --- | --- |
| 1. Определить зал и дату по событию | Указание на ближайший субботний показ | Зал «Сосна» и свойство показа — дату 24 октября |
| 2. Найти установленный проектор по залу | Найденную сущность «Сосна» | Проектор П-17 |
| 3. Найти ответственного по проектору | Найденную сущность П-17 | Имя Ирина |
| 4. Получить порядок обращения из исходного текста | Тот же проектор П-17 (через взаимную индексацию) | Канал связи (общий чат киноклуба) и требование указать дату показа и название зала |

После выполнения этих шагов перед языковой моделью оказываются проверенные части будущего ответа из всех трёх заметок:

- кому и куда писать — Ирине в общий чат киноклуба. Имя и правило о чате взяты из третьей записи, а их применимость к субботнему показу обоснована цепочкой от показа через зал «Сосна» из первой записи к проектору П-17 из второй;
- что указать в сообщении — дату 24 октября и зал «Сосна». Само требование назвать дату и зал находится в третьей записи, а конкретные значения для него получены на первом шаге из первой записи о показе.

Опираясь на этот собранный набор сведений, LLM формулирует ответ: «Напишите Ирине в общий чат киноклуба. В сообщении укажите дату показа — 24 октября — и зал „Сосна“». В такой короткой формулировке обозначение проектора П-17 из второй записи может даже не упоминаться, хотя именно этот промежуточный объект связал зал субботнего показа с контактом Ирины и правилами обращения. Привязка найденных фактов к исходным фрагментам позволяет [проверить основания ответа по документам](<https://timofei-ermolaev.ru/llm/faktcheking-otvetov-neyroseti/>), однако сама по себе ссылка на источник не доказывает ни полноты базы, ни истинности самих заметок.

После вопроса: получение ответа

**Кому написать перед субботним показом?**

Вопрос → операция 1

1

**Найти зал и дату показа**

Запись 1

«Сосна» · 24 октября

Из операции 1: зал «Сосна»

2

**Найти проектор**

Запись 2

П-17

Из операции 2: **П-17 → обе операции**

3

**Найти ответственного**

Запись 3 · вход: П-17 из операции 2

Ирина

4

**Получить порядок обращения**

Текст записи 3 · вход: П-17 из операции 2

Общий чат киноклуба

Указать дату показа и название зала.

Из операций 3 и 4 в ответ:
**Ирина, общий чат и правило**

Из операции 1

**24 октября
«Сосна»**

Дата и зал для правила

Напрямую
в ответ

**Итоговое сообщение**

Напишите Ирине в общий чат киноклуба. В сообщении укажите дату показа — 24 октября — и зал «Сосна».

В архитектуре KAG такой пошаговый план называется [логической формой](<https://arxiv.org/html/2409.13731v3>). Это не скрытая «цепочка мыслей» внутри языковой модели и не просто список подвопросов на естественном языке, а исполнимое представление операций и их аргументов. Результат одного действия становится переменной, то есть входными данными для зависимого шага: найденный зал «Сосна» передаётся на вход операции поиска оборудования, а полученный проектор П-17 подаётся сразу в два следующих действия. При этом не каждый шаг обязан зависеть от непосредственно предыдущего — порядок определяется тем, какие данные нужны на входе. Поиск ответственного в графе и обращение к текстовой инструкции опираются на один и тот же объект П-17, а дата 24 октября известна уже после первого шага, поэтому её не нужно искусственно протаскивать через цепочку оборудования.

Роли внутри этой последовательности разделены. Поисковые и вычислительные компоненты Solver выполняют обход графа, извлечение текстовых фрагментов, вычисления и передачу переменных между шагами. Языковая модель, по описаниям в [README KAG](<https://github.com/OpenSPG/KAG/blob/master/README.md>) и [статье разработчиков](<https://arxiv.org/html/2409.13731v3>), переводит исходный вопрос в план операций, может участвовать в интерпретации найденных данных и подготовке промежуточных ответов по отдельным подзадачам, а в конце формулирует итоговый текст. Распределение вызовов зависит от конфигурации, и разные настройки не обязаны строить один и тот же план. Приведённая таблица иллюстрирует архитектурный принцип логической формы на нашем примере, но не является реальной трассой запуска или записью синтаксиса конкретной версии KAG. Кроме того, исполнимость плана сама по себе не гарантирует правильного ответа: если система выберет неподходящую операцию или обопрётся на неверно извлечённую связь, план выполнится, но приведёт к ошибке.

## Что происходит при нехватке данных и какие есть ограничения

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

1. Связь в графе пропущена, но факт остался в тексте. Допустим, структурированного ребра от П-17 к человеку нет, однако в доступном для поиска исходном фрагменте третьей записи сохранилось предложение «За проектор П-17 отвечает Ирина» вместе с инструкцией про общий чат, дату и зал. Дойдя по графу до П-17 и не обнаружив готовой связи с ответственным, Solver, согласно [исследовательской статье о KAG](<https://arxiv.org/html/2409.13731v3>), может обратиться к поиску по связанным и доступным текстовым фрагментам. Только при условии, что этот отрывок с именем действительно сохранился и был найден, система сможет извлечь имя Ирины из текста и собрать ответ. Такой дополнительный поиск даёт шанс восстановить недостающее звено, но не гарантирует успеха; если бы во фрагменте остались лишь правила про чат, дату и зал без самой фразы об Ирине, назвать человека было бы нельзя.
2. Сведений нет ни в графе, ни в доступных текстах. Если третья запись не попала в базу или строка об ответственном в ней отсутствует, ни обход графа, ни текстовый поиск по П-17 не дадут имени. В материалах базы просто нет оснований назвать конкретного человека. При этом в разобранных источниках нет подтверждений, что KAG при любом подобном пробеле гарантированно выдаёт автоматический отказ.

Чтобы цепочки рассуждений приводили к верному результату, связи в базе должны соответствовать актуальным документам. Если в зале «Сосна» заменят проектор или за П-17 начнёт отвечать другой сотрудник, а запрос обратится к прежним связям в графе, ответ окажется устаревшим; в рамках рассмотренных материалов нет подтверждённой гарантии автоматического обновления или готового регламента синхронизации базы.

Качество ответа также зависит от полноты исходных документов, точности выделения сущностей и выбора операций при планировании, а подготовка представления и многошаговые вызовы LLM требуют вычислительных ресурсов. В [разделе об ограничениях статьи о KAG](<https://arxiv.org/html/2409.13731v3>) эти проблемы зафиксированы для исследовательской версии OpenSPG-KAG 0.5, поэтому их нельзя механически переносить как список нерешённых дефектов на сегодняшнюю реализацию. В то же время наличие графа и ссылок на источники не устраняет ошибки автоматически, а реальную стоимость, задержку и расход ресурсов нужно проверять на конкретной задаче.

## Чем KAG отличается от RAG и Microsoft GraphRAG

Сопоставляя эти названия, стоит различать общий принцип поиска фрагментов для генерации ответа (RAG) и конкретные фреймворки со своей архитектурой — KAG и Microsoft GraphRAG.

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

- KAG, фреймворк из [репозитория проекта](<https://github.com/OpenSPG/KAG/blob/master/README.md>) на базе [движка OpenSPG](<https://github.com/OpenSPG/KAG#4-quick-start>), согласно [статье разработчиков](<https://arxiv.org/html/2409.13731v3>) делает ставку на сочетание схемы со свободным извлечением знаний, взаимную индексацию графа и исходных текстовых фрагментов, а также на разбор вопроса через исполнимую логическую форму с передачей результатов между зависимыми операциями.
- Microsoft GraphRAG организует работу вокруг других режимов поиска. Его режим [Local Search](<https://microsoft.github.io/graphrag/query/local_search/>) рассчитан на вопросы о конкретных сущностях: он тоже соединяет узлы и связи графа с привязанными к ним исходными текстовыми фрагментами, а дополнительно может привлекать сводки по тематическим группам близких сущностей — сообществам графа. Режим [Global Search](<https://microsoft.github.io/graphrag/query/global_search/>) решает другую задачу — отвечает на обзорные вопросы по всему корпусу документов, опираясь на заранее подготовленные сводные отчёты по таким тематическим сообществам графа (community reports).

Упоминание схемы и логической формы в KAG не означает, что похожих инструментов нет в других системах, а Microsoft GraphRAG не сводится исключительно к глобальным сводкам по сообществам (и его устройство нельзя автоматически переносить на любые графовые решения). Архитектурные описания показывают, как устроены оба фреймворка, но без прямых испытаний на одних и тех же данных не позволяют утверждать, какая система окажется точнее, быстрее или дешевле.

В результате на одном вопросе о субботнем показе видно, как в KAG распределяются задачи: граф через промежуточное звено П-17 связывает зал «Сосна» с нужным человеком, привязанный текст третьей записи сохраняет подробные правила обращения, а план операций собирает из первой и третьей заметок все данные для готового ответа.

## Частые вопросы

### Нужно ли вручную задавать все связи в KAG?

Нет. Схема задаёт типы объектов, их свойства и допустимые отношения, а при подготовке базы языковая модель вместе с компонентами обработки извлекает сущности и связи из текстов. KAG сочетает построение по правилам схемы со свободным извлечением сведений. Это не гарантирует, что все связи будут найдены правильно.

### Зачем KAG сохраняет исходные тексты, если уже построен граф?

Связи графа помогают найти нужные объекты, а исходные фрагменты сохраняют подробности и основания ответа. В примере киноклуба граф приводит к Ирине, но инструкция написать в общий чат и указать дату и зал остаётся в связанном тексте. Взаимная индексация позволяет обратиться к этому фрагменту при подготовке и проверке ответа.

### Какую работу в KAG выполняет языковая модель?

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

### Может ли KAG найти факт, пропущенный при построении графа?

Может, если факт сохранился в доступном для поиска исходном тексте и система найдёт нужный фрагмент. Отсутствие связи в графе ещё не означает отсутствия сведений во всей базе. Если факта нет ни в графе, ни в доступных текстах, оснований для конкретного ответа нет. При этом обязательный автоматический отказ KAG при любом пробеле не подтверждён.

### Гарантируют ли граф и ссылки на документы правильность ответа KAG?

Нет. Ссылки позволяют проверить, откуда взяты сведения, но не доказывают истинность исходных документов или полноту базы. Ошибка возможна из-за устаревшего факта, неверно извлечённой связи или неподходящей операции в плане. Проверять нужно и основания ответа, и то, как найденные сведения связаны с вопросом.

### Доказывает ли пример с киноклубом, что KAG лучше обычного RAG?

Нет. Если все три записи попадут в контекст языковой модели, она сможет ответить и без графа. Пример показывает, как промежуточные связи помогают собрать основания ответа, но не является сравнительным испытанием или отчётом о запуске KAG. Для вывода о точности, скорости и стоимости нужны проверки на одних и тех же данных.

## По теме

- [Как работает RAG](<https://timofei-ermolaev.ru/llm/chto-takoe-rag/>) — Разобраться, как система находит фрагменты документов и передаёт их языковой модели.
- [Что такое CAG](<https://timofei-ermolaev.ru/llm/chto-takoe-cag/>) — Сравнить поиск по базе с предварительной обработкой документов и сохранением KV-состояния.
- [Фактчекинг ответов нейросети](<https://timofei-ermolaev.ru/llm/faktcheking-otvetov-neyroseti/>) — Проверять основания ответа по исходным документам и замечать неподтверждённые утверждения.

## Главное

В примере с киноклубом граф связывает показ, зал, проектор и ответственного, а исходный текст сообщает, куда написать и что указать. В показанном маршруте KAG ответ собирается из связей графа и подробностей исходного текста.

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

## Первоисточники

1. [KAG: Knowledge Augmented Generation — README](<https://github.com/OpenSPG/KAG/blob/master/README.md>) — OpenSPG/KAG maintainers
2. [KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation](<https://arxiv.org/html/2409.13731v3>) — Lei Liang et al.; arXiv
3. [Welcome to GraphRAG](<https://microsoft.github.io/graphrag/>) — Microsoft GraphRAG
4. [KAG Quick start](<https://raw.githubusercontent.com/OpenSPG/KAG/master/docs/quickstart.mdx>) — OpenSPG/KAG maintainers
5. [Local Search - GraphRAG](<https://microsoft.github.io/graphrag/query/local_search/>) — Microsoft GraphRAG
6. [Global Search - GraphRAG](<https://microsoft.github.io/graphrag/query/global_search/>) — Microsoft GraphRAG