KAG: как граф знаний помогает корпоративному ИИ и AI Office

«Какие проекты зависят от поставщика, который задержал отгрузку, и кто должен принять решение?» Для ответа недостаточно найти один документ со словом «поставка». Нужно связать контрагента, договор, заказ, проект, срок и ответственное поручение. Эти сведения могут лежать в разных файлах и рабочих системах.

Именно здесь становится интересен KAG — Knowledge Augmented Generation, генерация с дополнением знаниями. Подход помогает использовать не только найденные фрагменты, но и явно описанные связи между фактами. Для AI Office это важное направление: корпоративный помощник должен понимать контекст работы и показывать основания ответа. Разберём, что означает KAG, где он полезен и какие элементы этой идеи уже поддерживает наш прототип.

Краткое объяснение «RAG работает с текстами, а KAG — с графами» удобно, но неполно. В исследовании KAG граф знаний и векторный поиск используются совместно, а элементы графа связаны с исходными текстовыми фрагментами. Документы остаются источниками и сохраняют контекст, который нельзя без потерь свести к нескольким связям. KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation ↗

В привычном сценарии RAG система находит релевантные материалы и передаёт их модели для подготовки ответа. Исходная работа о RAG объединила генератор с внешней извлекаемой памятью. Современная архитектура может включать разные способы поиска; RAG не ограничивается одним примитивным запросом по сходству. Retrieval-Augmented Generation · Lewis et al. ↗

KAG развивает эту идею для задач, где важны структура предметной области и последовательность проверок. Это также название конкретного фреймворка OpenSPG. Поэтому важно различать применение похожих архитектурных принципов и фактическое внедрение самого OpenSPG/KAG.

Граф помогает найти путь между фактами. Исходные документы позволяют проверить, существует ли этот путь в действительности.

Представьте карту, на которой узлы — это контрагенты, договоры, товары, проекты и поручения, а линии имеют определённый смысл: «заключил», «относится к», «поставляет», «оплачивает», «назначено сотруднику». У объектов и связей есть свойства: идентификатор, дата, сумма, статус, источник.

Например: компания заключила договор; договор содержит этап; этап относится к проекту; счёт выставлен по этапу; платёж связан со счётом; поручение требует проверить исполнение. Такое описание даёт маршрут поиска, даже когда разные документы используют разные слова.

Для практической пользы недостаточно нарисовать кружки и стрелки. Связь должна иметь точное значение. «Письмо упоминает договор» слабее, чем «платёж подтверждён как относящийся к этому счёту». Предположение модели нельзя незаметно превращать в подтверждённый факт.

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

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

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

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

В официальном проекте OpenSPG/KAG описаны построение знаний по схеме предметной области, взаимная связь графа и текстовых блоков и гибридное решение вопроса по логической форме. В одном маршруте могут сочетаться точный поиск, текстовый поиск, работа со связями и вычисления. OpenSPG · KAG official repository and architecture ↗

На практике это означает два разных этапа. Сначала система подготавливает доступные знания: выделяет объекты, согласует их названия и свойства, фиксирует источники. Затем разбирает вопрос на проверяемые шаги и собирает материал для ответа.

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

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

Название GraphRAG используют для подходов, добавляющих граф к поиску и генерации, а также для конкретного проекта Microsoft. В документации Microsoft GraphRAG описаны извлечение графа из текста, построение сообществ и подготовка их сводок для последующих запросов. Microsoft · GraphRAG documentation ↗

У OpenSPG/KAG свой акцент: схема профессиональных знаний и гибридное решение с логическими операциями. Это не две ступени обязательного обновления и не взаимозаменяемые названия одного продукта. Конкретную систему выбирают по задачам, данным и стоимости сопровождения.

Для AI Office важнее вопрос «какие связи помогают ответить и как их проверить», чем выбор самого нового сокращения. Часть отношений уже удобно хранится в обычной базе данных. Графовое представление не всегда требует отдельной графовой СУБД; необходимость нового хранилища должна быть обоснована нагрузкой и запросами.

По состоянию на 9 сентября 2026 года в нашем программном прототипе реализованы поиск по документам с проверкой текущих прав, версии источников и ссылки на фрагменты. Для текстовых PDF и DOCX сохраняются оригиналы и привязки к страницам, абзацам или строкам таблиц. Это позволяет вернуться от ответа к материалу, на котором он основан.

Есть и структурированные связи другого уровня. Подготовленное КП связано с версией каталога и исходными строками. Расчёт хранит формулу и входные данные. Поручения связаны с процессом, в котором возникли, а существенные действия проходят предусмотренное согласование. Такие элементы создают основу проверяемого корпоративного контекста.

При этом полноценный KAG-фреймворк, общий граф знаний и автоматическое многошаговое решение через OpenSPG в текущем прототипе не внедрены. Поиск использует Qdrant; структурированные рабочие данные хранятся в SQLite. Само наличие связей между записями не делает систему готовой реализацией KAG.

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

Первое направление — договоры и коммерческие предложения. Граф мог бы связывать запрос, выбранные позиции, действующий каталог, согласованную версию КП и последующие изменения условий. Тогда вопрос «почему здесь эта цена» ведёт к конкретному основанию, а изменение каталога не переписывает историю старого предложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

Не переносите показатели из чужого исследования в коммерческое обещание. Результат на открытом наборе вопросов не определяет качество на ваших договорах и справочниках. Успешная цепочка на демонстрации также не доказывает устойчивость на всём потоке.

Практичный пилот ограничивается одной предметной областью: например, связями между каталогом, КП и поручениями. После проверки можно решать, нужен ли OpenSPG/KAG, другое графовое решение или достаточно расширить текущую базу и поиск.

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

Для AI Office ценность подхода — в развитии корпоративной памяти, где документ связан с решением, решение с поручением, а показатель с источниками. Уже реализованные версии, привязки и расчёты помогают двигаться в эту сторону, не выдавая проектируемые возможности за готовый продукт.

Если в вашей компании ответ руководителю требует собрать цепочку из нескольких систем и переписок, это хороший кандидат для предметного пилота. Начать стоит с одного вопроса и проверяемого набора связей. Тогда KAG становится способом улучшить конкретную работу, а не ещё одной аббревиатурой в презентации.