Графи знань для агентського ШІ: чотири шаблони, які виходять за межі векторного RAG.
Векторний пошук знаходить схожий текст, а не пов’язані факти. Чотири шаблони графів для агентів: стимулювання на основі реальних даних, планування, перевірка виконання та самокорекція.
Джерела: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs
Більшість команд, які створюють системи ШІ, стикаються з однією й тією самою проблемою. Створюється векторна база даних, документи розділяються на частини, підключається LLM, і все це називається конвеєром RAG. Цей підхід працює доти, доки користувач не поставить запит, який вимагає об’єднання трьох фактів з різних доменів даних. У такому випадку система або вигадує відповідь, яка звучить впевнено, або повертає щось технічно правильне, але безполезне в контексті.
Зазвичай вина не лежить на LLM — проблема в шарі пошуку інформації під ним. Пошук за векторною схожістю по суті полягає у пошуку уривків тексту, схожих за змістом, тому він знаходить текст, семантично близький до запиту, але пропускає факти, які пов’язані між собою причинно-наслідковими або відносинними зв’язками. Для агента, який мусить міркувати кількома кроками, вживати дій та послідовно приймати рішення, це обмеження посилюється. Одна погана відповідь призводить до накопичення помилок у всій ланцюжку міркувань.
Аргумент, який варто сприймати серйозно, полягає у тому, що граф знань — це не просто удосконалений механізм пошуку. Це структурна основа, яка дозволяє агенту міркувати, а не лише знаходити інформацію.
Основна ідея
Штучний інтелект у форматі агентів часто розглядається як модний термін: додається кілька викликів інструментів навколо LLM, і це вважається перемогою. Більш дисциплінований підхід передбачає створення шару знань спеціально для багатоетапних міркувань, а не для відповідей на запитання одним кроком.
Відбувається перехід від плоскої моделі пошуку до структурованого графа, у якому елементи, взаємозв’язки та контекст мають першорядне значення. Граф не просто фіксує те, що у продукту X є дефект. Він також фіксує, що продукт X виготовлений постачальником Y, доставлений до регіону Z та підпадає під дію рамкової системи Compliance Framework W. Агент, який запитує цей граф, може пройтися цими зв’язками та знайти інсайти, яких ніколи не було б при використанні векторного пошуку.
Ніщо з цього не є новим у теорії баз даних. Справжньою новизною є її суворе застосування до агентних систем, і час для цього обраний доречно. Технології агентних пайплайнів достатньо розвинулися завдяки кращому міркуванню за допомогою LLM, вдосконаленим 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.