Граф знаний: что это и как связать данные компании

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

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

Базовую модель графа и формат RDF сверяйте со спецификациями W3C RDF, а язык запросов — с W3C SPARQL 1.1.

Начните с вопроса

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

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

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

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

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

Выделите сущности

Этап «Выделите сущности» рассматривает объекты с самостоятельной идентичностью. Граф полезен, когда связь между объектами важна не меньше самих документов. Сбой возникает, когда каждое слово документа превращают в отдельный узел; поэтому сначала готовят словарь типов сущностей, а затем выполняют «оставить только объекты, участвующие в ответе».

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

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

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

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

Назначьте идентификаторы

Для раздела «Назначьте идентификаторы» рабочая граница — устойчивые ключи независимо от написания имени. Риск формулируется как «дубликаты расходятся по разным веткам графа». Граф полезен, когда связь между объектами важна не меньше самих документов. Проверяемый ход — сопоставить внутренние ID и правила слияния, результат фиксируется в артефакте «таблица идентификаторов».

• Рабочее действие: сопоставить внутренние ID и правила слияния.
• Сохраняемый артефакт: таблица идентификаторов.
• Контрольная ситуация: ООО с сокращённым и полным названием остаётся одной компанией.
• Показатель решения: доля сущностей без дубля.

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

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

Разберите пример отдельно: ООО с сокращённым и полным названием остаётся одной компанией. Полезно попросить второго специалиста повторить шаг «сопоставить внутренние ID и правила слияния» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «устойчивые ключи независимо от написания имени» владелец «инженер данных» сверяет артефакт «таблица идентификаторов» с метрикой «доля сущностей без дубля».

Опишите отношения

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

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

Приёмка этапа «Опишите отношения» начинается с независимого повтора. Второй специалист получает каталог отношений, применяет «задать глагол, направление и ограничения» к контуру «направленные связи с понятным смыслом» и сверяет «доля рёбер с определённым типом». Случай «сотрудник отвечает за процесс, а процесс использует систему» считается обязательным; ошибка «одно ребро «связан с» скрывает разные действия» останавливает выпуск.

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

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

Добавьте происхождение

В задаче «Добавьте происхождение» ожидаемый объект — источник, дата и способ получения каждой связи. Граф полезен, когда связь между объектами важна не меньше самих документов. Команда отдельно записывает опасение «правдоподобный факт нельзя проверить», выполняет «сохранять ссылку на документ или систему» и оставляет provenance у узлов и рёбер для повторной проверки.

• Рабочее действие: сохранять ссылку на документ или систему.
• Сохраняемый артефакт: provenance у узлов и рёбер.
• Контрольная ситуация: владелец изменился, и граф показывает старый приказ.
• Показатель решения: доля связей с источником.

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

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

Разберите пример отдельно: владелец изменился, и граф показывает старый приказ. Полезно попросить второго специалиста повторить шаг «сохранять ссылку на документ или систему» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «источник, дата и способ получения каждой связи» владелец «владелец данных» сверяет артефакт «provenance у узлов и рёбер» с метрикой «доля связей с источником».

Согласуйте схему

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

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

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

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

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

Загрузите первый срез

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

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

В разделе «Загрузите первый срез» сравните две версии на одинаковом входе «сто клиентов сверяются вручную до миллиона строк». Свидетельство отчёт загрузки и исключений связывает объект «ограниченный набор из двух или трёх систем» с действием «начать с контролируемой выборки». Итоговый показатель — «доля отклонённых записей»; владелец инженер интеграции отдельно проверяет ошибку «массовый импорт размножает ошибки источника».

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

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

Проверьте запросы

Владельца для этапа «Проверьте запросы» назначают до работы с объектом «маршруты по графу и отрицательные случаи». Граф полезен, когда связь между объектами важна не меньше самих документов. Он не допускает ошибку «демонстрация работает только на известном имени», требует выполнить «прогнать эталонные и пустые вопросы» и принять результаты SPARQL или API-тестов.

• Рабочее действие: прогнать эталонные и пустые вопросы.
• Сохраняемый артефакт: результаты SPARQL или API-тестов.
• Контрольная ситуация: запрос без владельца должен вернуть пробел, а не выдумку.
• Показатель решения: точность и полнота ответов.

Для решения по этапу «Проверьте запросы» недостаточно слов автора. Сначала роль специалист качества получает результаты SPARQL или API-тестов, затем повторяет «прогнать эталонные и пустые вопросы» и проверяет объект «маршруты по графу и отрицательные случаи» на ситуации «запрос без владельца должен вернуть пробел, а не выдумку». Метрика «точность и полнота ответов» принимается только без проявления риска «демонстрация работает только на известном имени».

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

Разберите пример отдельно: запрос без владельца должен вернуть пробел, а не выдумку. Полезно попросить второго специалиста повторить шаг «прогнать эталонные и пустые вопросы» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «маршруты по графу и отрицательные случаи» владелец «специалист качества» сверяет артефакт «результаты SPARQL или API-тестов» с метрикой «точность и полнота ответов».

Настройте обновления

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

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

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

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

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

Покажите объяснение

Свяжите пункт «Покажите объяснение» с решением человека о контуре «путь от результата к подтверждающим рёбрам». Граф полезен, когда связь между объектами важна не меньше самих документов. Без шага «возвращать маршрут и источники» и артефакта «читаемая трасса ответа» нельзя исключить ошибку «ответ выдаётся без основания».

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

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

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

Разберите пример отдельно: пользователь видит документ, проект и ответственного. Полезно попросить второго специалиста повторить шаг «возвращать маршрут и источники» без устного объяснения. Если он получает другой вывод, документация неполна. Если одинаковый — контроль можно включать в регрессионный набор и повторять после смены модели, данных, кода или назначения системы. Для объекта «путь от результата к подтверждающим рёбрам» владелец «владелец интерфейса» сверяет артефакт «читаемая трасса ответа» с метрикой «доля ответов с полной трассой».

Матрица приёмки

Что изучить дальше

• база знаний компании
• RAG
• нейросеть для анализа данных
• векторная база
• MCP-сервер
• эмбеддинги
• аудит ИИ-систем

Чек-лист запуска