Новости и разборы
Граф знаний или векторный RAG: как выбрать по типу вопроса
Когда нужен граф знаний, а когда достаточно векторного RAG: вопросы по связям, актуальность фактов, происхождение данных и стоимость сопровождения.
«Как настроить согласование договора?» и «Какие действующие договоры связаны с поставщиком, у которого изменился статус?» выглядят как вопросы к одной корпоративной базе. Но отвечать на них приходится по-разному. Для первого может хватить подходящей инструкции. Второй требует найти поставщика, определить его договоры, проверить действительность каждого и связать сведения из нескольких источников.
Выбор между векторным RAG и графом знаний начинается с этого различия. Он зависит от структуры нужного ответа, а также от способности команды поддерживать исходные факты. Новая архитектура не заменяет актуальные данные и ясные правила доступа.
Что объясняет новый материал n8n
В статье n8n от 1 октября 2026 года сравниваются поиск семантически близких фрагментов и извлечение явно заданных связей. Граф представляет сущности узлами, отношения — рёбрами; факты могут записываться как тройки «субъект — отношение — объект». Например, «договор относится к поставщику» задаёт связь, которую можно использовать при обходе графа.
Авторы предлагают векторный RAG для ответов, содержащихся в нескольких релевантных фрагментах, а граф — для задач, где требуется соединять отношения между сущностями. Они также описывают HybridRAG, объединяющий несколько способов извлечения. Это руководство провайдера автоматизации, а не сравнительное испытание всех архитектур на ваших документах.
Обычная реляционная база тоже умеет хранить связи и отвечать на структурированные вопросы. Поэтому наличие нескольких связанных объектов само по себе не требует графовой базы. Сначала нужно проверить, можно ли получить ответ точным запросом к существующей системе. Языковой интерфейс может лишь помогать пользователю выразить этот запрос.
Когда достаточно найти несколько фрагментов
Для справочных вопросов вроде «как изменить адрес доставки?» часто подходит поиск по инструкциям. Векторный retrieval помогает сопоставлять формулировку клиента с другими словами в документе. Если необходимы точные названия, можно подключить лексический сигнал; его ограничения разобраны в материале о гибридном поиске и токенизации.
Результат такого поиска остаётся текстовым контекстом. Нужно знать версию инструкции, применимость к конкретной роли и источник утверждения. Если ответ содержится в одной понятной статье, построение сущностей и отношений для всей базы может добавить работу без заметной пользы.
Подход к AI-процессам с проверкой результата предлагает сначала ограничить задачу. Для справочного помощника полезным первым этапом будет набор вопросов с ожидаемыми источниками, проверка ответов и явное поведение при отсутствии сведений. Это даст основания расширять архитектуру по конкретным ошибкам.
Когда отношения становятся содержанием вопроса
Вернёмся к условному поставщику. Изменение статуса может затрагивать договоры, объекты обслуживания и ответственных сотрудников. Если сведения распределены по разным документам, близкий по смыслу абзац не обязательно содержит всю цепочку. Граф позволяет явно представить переходы, например от поставщика к договору, затем к объекту и ответственному.
Но связь требует точного значения. «Упомянут в переписке» и «является стороной действующего договора» нельзя объединить в одно отношение. Дата окончания договора, источник статуса и идентификатор объекта нужны для корректного отбора. Без них красивый путь по графу может объяснять несуществующую зависимость.
Для первого эксперимента стоит выбрать один тип вопроса и ограниченный набор связей. Например, вернуть договоры поставщика с источником и действующим статусом на указанную дату. Не следует сразу извлекать «все возможные отношения» из архива: проверить такую модель существенно сложнее, чем небольшую заранее определённую схему.
Кто отвечает за достоверность связи
n8n отдельно отмечает разрешение сущностей: разные написания одного объекта должны сопоставляться, но автоматическое объединение нуждается в проверке. В бизнес-данных это особенно важно для организаций с похожими названиями и сотрудников, работающих в нескольких проектах. Ошибочное слияние переносит связи на другого участника.
Полезно сохранять источник каждого отношения, время его подтверждения и условия применимости. Когда документ исправлен, нужно определить, какие производные факты стали недействующими. Если две версии источника противоречат друг другу, система должна показать конфликт или следовать заранее согласованному приоритету, а не выбирать более удобное объяснение.
Внутренние рабочие системы начинаются с вопроса, каким данным можно доверять и кто выполняет следующий шаг. Для графа это буквально часть модели: кто может подтвердить отношение, кто исправляет конфликт и где хранится действующая запись. Эти обязанности остаются у команды даже при автоматическом извлечении сущностей языковой моделью.
Как проверить пользу до расширения
Сравните варианты на одинаковых вопросах: справочный запрос, точный структурированный запрос и запрос с несколькими переходами. Для каждого запишите ожидаемые сущности, отношения, документы и недопустимые выводы. Отдельно включите смену статуса, повторяющиеся названия и удалённый источник.
В обзоре Weaviate от 6 мая автор по результатам своего исследовательского опыта выделяет устаревшие и недостаточные фрагменты среди причин ошибок retrieval. Этот материал не доказывает превосходство графа. Он подчёркивает необходимость проверять полноту и актуальность найденного контекста независимо от его формы.
При оценке графа полезно проверить, можно ли проследить ответ до исходного факта и объяснить каждый переход. У векторного варианта проверяют, достаточно ли полученных фрагментов для вывода. Затем учитывают сопровождение: обновление источников, исправление сущностей, изменение схемы и время эксперта на подтверждение спорных связей. Экономию нельзя предполагать только потому, что итоговый ответ выглядит компактнее.
Смешанный подход без лишних компонентов
HybridRAG имеет смысл, когда один запрос действительно нуждается и в отношениях, и в содержании документа. Условная система может точно найти договоры поставщика, а затем извлечь из этих документов условия уведомления. Каждый шаг должен сохранить идентификаторы и ограничения доступа; результаты двух инструментов нельзя бесконтрольно складывать в общий контекст.
Сложности извлечения таблиц и диаграмм рассмотрены в материале о RAG для PDF. Даже подходящая схема отношений не восстановит факты, потерянные при чтении документа.
Начать стоит с одного рабочего вопроса и наиболее простой реализации, которая возвращает проверяемый ответ. Граф полезен, если явные отношения решают обнаруженную проблему и команда может их поддерживать. Векторный поиск полезен, если нужны релевантные тексты. Выбор становится обоснованным после проверки этих задач на собственных источниках.