Как KAG может усилить AI Office: от тендерных требований до эксплуатации

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

OpenSPG KAG интересен именно для такой работы: связывать объекты, условия и доказательства, а затем помогать отвечать на вопросы по этой структуре. Для AI Office это возможное развитие от поиска по документам к разбору конкретного рабочего случая.

У нас уже есть вводная статья о графах знаний и KAG. Здесь рассмотрим практические задачи, состав будущей интеграции и критерии полезного пилота. Сведения об официальном проекте проверены 15 октября 2026 года. Описанные ниже KAG-сценарии — предложения по развитию сервиса, а не заявление об уже внедрённом модуле.

KAG — Knowledge Augmented Generation — это конкретный открытый фреймворк на базе OpenSPG и языковых моделей. Он сочетает граф знаний, исходные текстовые фрагменты и поиск. Вопрос может раскладываться на шаги с точным сопоставлением, извлечением текста, переходами по связям и вычислениями. OpenSPG · KAG official repository and architecture ↗

В основе подхода — взаимное индексирование графа и текста и гибридное рассуждение. Это архитектурная основа, а не гарантия правильного ответа на любые корпоративные данные. KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation ↗

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

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

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

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

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

Полезный результат — матрица с основаниями и вопросами ответственным. Десять рабочих и двенадцать календарных дней нельзя автоматически считать равными: нужны условия начала отсчёта и календарь.

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

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

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

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

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

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

Такой слой знаний поддерживает подготовку работ, передачу объекта новому подрядчику и поиск истории изменений. Он не считывает показания датчиков сам по себе и не управляет оборудованием. Телеметрия, диспетчеризация и команды умного дома — отдельные интеграции с собственными требованиями к эксплуатации.

Цифровой паспорт объекта и связи с инженерными системами — возможное развитие услуг AI Office; в текущем прототипе они не реализованы.

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

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

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

Практичная интеграция начинается с границ одного процесса. Определяем типы объектов и отношений: например, требование, позиция, модификация, документ и подтверждение. В OpenSPG предусмотрены семантическая схема, построение знаний и логические правила; конкретную бизнес-модель нужно разработать под задачу. OpenSPG: semantic modeling, knowledge construction and rule reasoning ↗

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

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

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

В коде KAG есть клиент Ollama для языковых моделей и отдельный клиент Ollama для эмбеддингов — числовых представлений текста, используемых при поиске. Это даёт техническую основу для локальной конфигурации, но не доказывает качество любой модели на конкретной задаче. KAG source snapshot: Ollama language-model client ↗ KAG source snapshot: Ollama embedding client ↗

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

В официальном примере конфигурации генерация и извлечение направлены в DeepSeek API, а эмбеддинги — во внешний сервис SiliconFlow. Поэтому установка проекта на офисном сервере ещё не означает закрытый контур. Для чувствительных материалов необходимо задать и проверить все адреса обработки, включая импорт, поиск, диагностические журналы и дополнительные инструменты. KAG examples: model endpoints, graph construction and question answering ↗

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

В текущем прототипе AI Office реализованы поиск по документам с проверкой прав, версии источников и ссылки на фрагменты. Есть обработка текстовых PDF и DOCX, работа с Excel/CSV-каталогом, проверяемые расчёты КП, утверждение конкретной версии и создание локальной задачи. Совет аналитиков использует 3–5 ролей одной настроенной модели.

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

Открытый код KAG распространяется под Apache 2.0. При выборе полного решения отдельно проверяют условия моделей и зависимостей, сопровождение и обновления. Открытость проекта облегчает изучение и адаптацию, но не заменяет внедрение под данные компании. KAG source snapshot: Apache License 2.0 ↗

Мы бы начали с одного повторяемого вопроса, например: «Какие требования этого комплекта документов подтверждены выбранным предложением?» Специалист компании готовит эталонный разбор, включая неоднозначные случаи и правильные уточняющие вопросы.

Сравнивать стоит три варианта: текущий поиск, поиск с обычными структурированными запросами и KAG. Одинаковыми должны оставаться документы, права и критерии оценки. Это позволяет понять, какую пользу принесли связи и не решается ли задача более простым способом.

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

Успех — это пригодный для проверки результат при понятной стоимости сопровождения. Если одни и те же зависимости нужны постоянно и граф помогает их обслуживать, KAG становится обоснованным следующим шагом. Если ответ лежит в одной инструкции или строится простым запросом к таблице, дополнительный слой может не понадобиться.

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