Графы знаний для агентных ИИ: четыре паттерна, выходящих за рамки векторного RAG.
Векторный поиск находит похожий текст, а не связанные между собой факты. Четыре графовых паттерна для агентов: основанное на данных формулирование запросов, планирование, проверка выполнения и самокоррекция.
Источники: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
Большинство команд, разрабатывающих системы ИИ, сталкиваются с одной и той же проблемой. Создается векторная база данных, документы делятся на фрагменты, подключается большая языковая модель, и всё это называется конвейером RAG. Всё работает до тех пор, пока пользователь не задаст вопрос, требующий объединения трех фактов из разных областей данных. В таком случае система либо выдумывает убедительный ответ, либо возвращает технически верный, но бесполезный в данном контексте результат.
Обычно вина не в большой языковой модели, а в слое поиска информации, находящемся под ней. Поиск по векторному сходству по сути представляет собой поиск фрагментов текста, похожих по звучанию, поэтому он находит тексты, семантически близкие друг к другу, но упускает факты, связанные между собой причинно-следственными или реляционными связями. Для агента, который должен рассуждать по нескольким шагам, принимать действия и последовательно принимать решения, эта ограниченность усугубляется. Один плохой ответ приводит к тому, что ошибки накапливаются на всем протяжении цепочки рассуждений.
Аргумент, который стоит воспринимать всерьез, заключается в том, что граф знаний — это не просто более совершенный механизм поиска. Это структурная основа, позволяющая агенту рассуждать, а не просто находить информацию.
Основная идея
Искусственный интеллект в формате агентов часто рассматривается как модный термин: добавляются некоторые вызовы инструментов к LLM, и это считается победой. Более дисциплинированный подход предполагает создание слоя знаний специально для многоэтапного рассуждения, а не для ответов на вопросы в один шаг.
Происходит переход от плоской модели поиска к структурированному графу, в котором сущности, связи и контекст занимают первостепенное место. Граф не просто фиксирует, что у продукта X есть дефект; он также указывает, что продукт X произведен поставщиком Y, доставлен в регион Z и охватывается рамками соответствия W. Агент, запрашивающий этот граф, может проследить эти связи и обнаружить информацию, которую векторный поиск никогда бы не выявил.
Ничего из этого не является новым в теории баз данных. Самое новое — это строгое применение этих принципов к агентным системам, и время для этого выбрано уместно. Технологии агентных пайплайнов достаточно созрели благодаря улучшенному рассуждению с помощью больших языков моделей, более совершенным API для вызова инструментов и более мощным фреймворкам оркестрации, в результате чего слой знаний стал узким местом. Даже идеальная архитектура агента будет генерировать бесполезные результаты, если основное представление знаний будет одномерным и несвязанным.
Метод делится на четыре архитектурных шаблона, каждый из которых ориентирован на отдельный этап жизненного цикла агента: закрепление знаний, планирование, выполнение и самокоррекция. Вместе они образуют план для производственных систем, а не теоретическое упражнение.
Почему это важно
Модели RAG обычно крайне чувствительны к ошибкам, и их причины трудно выявить. После плохого результата причина остается скрытой: слабая процедура извлечения информации, некорректные границы фрагментов или противоречие модели с предоставленным ей контекстом. При использовании простого векторного поиска приходится полагаться на догадки. Если включить в работу граф знаний, объяснимость действий модели становится практически бесплатной, поскольку сам путь прослеживания данных является следом логических рассуждений.
Это имеет огромное значение в регулируемых секторах. Здравоохранение, финансы и юридические технологии нуждаются в ИИ, способном показать, как он выполняет свою работу. Систему, которая указывает три узла графа и два шага связей, лежащих в основе ответа, можно проверить, тогда как систему, сообщающую лишь результат косинусного сходства типа top-k, проверить невозможно. Для команд, разрабатывающих ИИ в условиях строгого соблюдения нормативов, это разница между продуктом, готовым к внедрению, и концептом, который так и остается в лаборатории.
Существует также аргумент, связанный с надежностью. Агентные системы могут давать сбои в каскадном режиме: одно плохое решение на раннем этапе цепочки портит всё, что следует за ним. Граф выступает в роли структурного ограничителя: агенты могут проверять промежуточные выводы по нему перед продолжением работы и своевременно выявлять отклонения. Это похоже на инструмент проверки фактов, встроенный в цикл рассуждений, а не добавленный в конце.
Возможно, наименее оцененным преимуществом является обновление знаний без повторной обучаемости. С использованием эмбеддингов добавление новых фактов часто требует переэмбеддинга больших объемов данных, что может нарушить существующую логику поиска информации. С помощью графа достаточно добавить узлы и ребра, и рассуждения агента сразу отражают эти изменения. В быстро меняющихся областях, таких как финансовые рынки, медицинские исследования и развивающиеся программные экосистемы, это представляет собой реальное операционное преимущество.
Четыре подхода на практике
1. Подсказки, основанные на знаниях
Первый шаблон закрепляет исходный контекст агента в структурированных фактах, а не в результатах расплывчатого сходства. Вместо поиска отрывков, кажущихся похожими, необходимо запросить в графе подграф, соответствующий намерению пользователя, и включить этот структурированный контекст в промпт.
from neo4j import GraphDatabase
import json
def get_grounded_context(user_query: str, entity_extractor, driver) -> str:
# Step 1: Extract entities from the user query
entities = entity_extractor(user_query) # e.g., ["Product X", "Supplier Y"]
# Step 2: Pull a relevant subgraph from Neo4j
with driver.session() as session:
result = session.run(
"""
MATCH (e)-[r]-(connected)
WHERE e.name IN $entities
RETURN e.name AS entity,
type(r) AS relationship,
connected.name AS related_entity,
connected.attributes AS attributes
LIMIT 50
""",
entities=entities
)
subgraph = [record.data() for record in result]
# Step 3: Format subgraph as structured context
context_str = json.dumps(subgraph, indent=2)
grounded_prompt = f"""
You are a reasoning agent. Use ONLY the following structured knowledge to answer.
If the answer isn't derivable from this context, say so explicitly.
KNOWLEDGE GRAPH CONTEXT:
{context_str}
USER QUERY: {user_query}
"""
return grounded_prompt
Посмотрите, что здесь происходит. Агент не ищет документы, похожие на вопрос. Он извлекает конкретные сущности, получает информацию о их взаимосвязях и вставляет её в качестве структурированного контекста. В результате ЯЗЫК получает карту, в то время как раньше у него был набор абзацев, связанных между собой лишь косвенно.
2. Планирование с использованием графа
Второй подход касается многоэтапного планирования. Агенты разделяют сложные цели на выполнимые шаги, причем эти шаги должны основываться на том, что действительно возможно с учётом текущего уровня знаний. Граф делает процесс планирования гораздо менее свободным.
Сравните планирование дорожной поездки без карты и с картой. Без неё маршрут является лишь вероятным вариантом, а с картой он учитывает реальные дороги, расстояния и ограничения. Граф выполняет функцию карты.
def plan_with_graph(goal: str, graph_schema: dict, llm) -> list[dict]:
schema_str = json.dumps(graph_schema, indent=2)
planning_prompt = f"""
You are a planning agent. Given the goal below, decompose it into steps.
Each step must reference a valid entity type or relationship from the schema.
Do not invent steps that require knowledge outside this schema.
GRAPH SCHEMA:
{schema_str}
GOAL: {goal}
Return a JSON list of steps. Each step must include:
- "action": what to do
- "graph_query": the Cypher query to retrieve required context
- "depends_on": list of prior step indices this step requires
"""
raw_plan = llm.complete(planning_prompt)
plan = json.loads(raw_plan)
return plan
Ключевой момент заключается в вставке graph_schema в механизм планирования. Агент может планировать только те действия, которые структурно поддерживаются графом, что значительно сокращает количество ошибочных планов, поскольку он не может предлагать действия, зависящие от отношений между данными, отсутствующих в модели знаний.
3. Выполнение с проверкой графа
В процессе выполнения агент принимает действия и постепенно генерирует промежуточные результаты. Согласно третьему подходу, каждый промежуточный результат необходимо проверять по графу перед его принятием. Например, если агент приходит к выводу, что именно поставщик Y стал причиной дефекта в продукте X, система должна немедленно подтвердить наличие связи между этим поставщиком и продуктом в графе, а также отметить это утверждение как неверное, если такой связи нет.
def execute_with_validation(step: dict, intermediate_result: str, driver, llm) -> dict:
# Extract claims from the intermediate result
claim_extraction_prompt = f"""
Extract all factual claims from this text as a list of (subject, predicate, object) triples.
TEXT: {intermediate_result}
Return as JSON array.
"""
claims = json.loads(llm.complete(claim_extraction_prompt))
validation_results = []
with driver.session() as session:
for claim in claims:
result = session.run(
"""
MATCH (s {name: $subject})-[r]-(o {name: $object})
WHERE type(r) = $predicate OR $predicate IN r.aliases
RETURN count(r) AS match_count
""",
subject=claim["subject"],
predicate=claim["predicate"],
object=claim["object"]
)
record = result.single()
validation_results.append({
"claim": claim,
"validated": record["match_count"] > 0
})
unvalidated = [v for v in validation_results if not v["validated"]]
return {
"result": intermediate_result,
"validated": len(unvalidated) == 0,
"flagged_claims": unvalidated
}
Вероятно, именно здесь и заключается наибольшая ценность реализации. В цикл выполнения встроен постоянный детектор галлюцинаций как неотъемлемая часть процесса рассуждений, а не что-то, добавленное в последний момент. Неверифицированные утверждения не приводят к сбою системы; они отмечаются, чтобы агент мог их скорректировать или передать на проверку человеку.
4. Самокоррекция через просмотр графа
Четвертый подход закрывает цикл. При обнаружении несоответствий или получении отрицательной обратной связи агент не пытается действовать слепо. Он просматривает граф в поисках альтернативных путей рассуждений, что позволяет агенту грациозно справляться с ошибками в отличие от тех, кто бесконечно застревает на некорректных данных.
Предположим, агент исследует причину сбоя при проверке соответствия. Начиная с субъекта, вызвавшего сбой, он следует по связям наружу и находит пропущенный звено — например, обновление нормативных актов, которое ещё не было связано с соответствующей категорией продуктов. Это пробел в графе, а не в ЯЗЫКЕ больших моделей, и агент может явно сообщить об этом: вывод невозможно подтвердить, поскольку связь между конкретным обновлением норматива и категорией медицинских продуктов отсутствует. Это ошибка, требующая действий, а не галлюцинация.
Что делать с этим
Не спешите удалять базу данных векторов. Начните с определения того, где в данной области важна структура. Составьте список связанных сущностей и отношений между ними, затем рассмотрите вопросы, на которые должен отвечать агент, и подсчитайте, сколько из них требуют последовательного перехода по ссылкам между несколькими фактами. Если большинство сложных вопросов соответствует этому, то основная проблема — это графовая задача.
Что касается инструментов, то Neo4j является наиболее распространенной графовой базой данных, а ее Python SDK хорошо интегрируется с LangChain и LlamaIndex. Amazon Neptune и Memgraph — хорошие альтернативы в зависимости от среды выполнения. Для оркестрации рассмотрите LangGraph, чья обработка состояний напоминает просмотр графа. Состояние рассуждений агента уже находится в графовой структуре, что делает использование внешней графовой базы знаний естественным решением.
Практический подход начинается с первого шаблона, предусматривающего минимальные изменения в уже существующей системе RAG. Сначала создайте первую графовую структуру, ориентируясь на наиболее важные сущности и связи, затем сравните уровень галлюцинаций при использовании обоснованных запросов с базовыми показателями. Если этот уровень снизится, что весьма вероятно, у вас появятся основания для внедрения оставшихся трех шаблонов.
Одно предупреждение: построение графов совсем не простая задача. Некачественные, несогласованные или плохо маркированные исходные данные приводят к хаотичной структуре графа и некорректному поведению агента, поэтому принцип «грязный вход — грязный выход» здесь так же актуален, как и в любом другом случае. Сначала инвестируйте в качество данных и проектирование онтологии, а уже затем — в инфраструктуру графов. Чистая, хорошо структурированная графовая структура из 10 000 узлов будет работать эффективнее, чем разрозненная, несогласованная структура из 10 миллионов узлов.
К чему это приводит
Дальнейшее развитие лежит в сторону агентов, которые выходят за рамки простого поиска информации и её генерации. Они поддерживают постоянно обновляемую структурированную модель мира, в котором работают, и используют её для логических рассуждений, планирования и самокоррекции в реальном времени. Основное отличие ИИ, который лишь отвечает на вопросы, от ИИ, который решает проблемы, заключается в способе представления знаний, причём графы являются одним из самых мощных структурных инструментов для этой цели.
Попробуйте применить это к любой системе: если завтра агент примет неверное решение, можно ли выявить точную причину? Если нет, процесс работы будет происходить вслепую. Эти четыре принципа характеризуют агентов, которые раскрывают свои логические рассуждения, проверяют собственные выводы и допускают ошибки, которые можно отладить; именно такой формы должен достичь ИИ промышленного уровня. Команды, которые доберутся до этого первыми, обгонят те, кто до сих пор сосредоточен на коэффициентах косинуса и задаётся вопросом, почему их агент постоянно ошибается.
Связанные материалы
- Практические рекомендации: создание системы обнаружения мошенничества на основе агентов, готовой к использованию в производстве — Подробное руководство по созданию такой системы: контракты, проверки и готовые блоки кода для команд, разрабатывающих подобные решения.
- Семантическое поиск с использованием ChromaDB и эмбеддингов для многоагентной платформы — Переход многоагентной корпоративной платформы на семантический поиск: разбиение текста с учетом слов, расстояние Косинуса в ChromaDB, тестовые слои и следующий шаг развития RetrievalAgent.