Neo4j Pushes Knowledge Graphs to Fix Multi-Hop AI Retrieval Limits

The GraphRAG Advantage: Providing Enterprise-Grade Knowledge to AI Agents and LLMs With Neo4j — Ai4

Ai4

Standard vector retrieval fails on multi-step enterprise reasoning, but anchoring AI agents in knowledge graphs and standard protocols triples response accuracy and eliminates vector search dependencies.

AI-assisted summary of The GraphRAG Advantage: Providing Enterprise-Grade Knowledge to AI Agents and LLMs With Neo4j — original source. Check the original for full context.

Source published: 2025-08-29

Detailed notes

## Background Published on YouTube by Ai4 on August 29, 2025, this presentation features Nyah Macklin, Senior Developer Advocate for Artificial Intelligence at Neo4j. According to the description, the session explores how GraphRAG and knowledge graphs solve traditional vector RAG failures in multi-hop reasoning, enabling engineering teams to ground AI agents and large language models with accurate, explainable enterprise data.

## TL;DR Nyah Macklin breaks down the architectural shift from standard vector-only Retrieval-Augmented Generation (RAG) to GraphRAG, showing how native knowledge graphs resolve vector search's core weaknesses in handling complex multi-hop relationships, domain logic, and explainability. Backed by empirical case studies from data.world, LinkedIn, and Microsoft Research, she outlines the three core pillars of GraphRAG: higher accuracy, intuitive data modeling, and robust governance. Finally, she demonstrates how knowledge graphs and the Model Context Protocol (MCP) power autonomous AI agents through the Thought-Action-Observation cycle to execute deterministic enterprise workflows.

## Atmosphere & style The talk carries an energetic, welcoming, and fast-paced conference vibe, with Macklin combining deep technical advocacy with approachable humor and audience polling. Her passionate shoutouts to tech inclusion initiatives and conversational examples make complex graph theory feel accessible and engaging. The delivery transitions smoothly from lighthearted stage rapport into dense, pragmatic architectural walkthroughs, leaving the room with a sense of momentum and practical enthusiasm.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=tt9QidsVtYI&t=4s) A knowledge graph organizes real-world entities (nodes) and their relationships (edges) within a native graph database to explicitly preserve context and interconnected meaning. - [02:00](https://www.youtube.com/watch?v=tt9QidsVtYI&t=120s) GraphRAG enhances the standard vector RAG pipeline by embedding a knowledge graph directly into the retrieval path alongside or in place of vector search. - [03:25](https://www.youtube.com/watch?v=tt9QidsVtYI&t=205s) While vector RAG is suitable for basic semantic lookups, GraphRAG is critical for complex multi-hop reasoning, supply chain tracking, and cross-document aggregations. - [05:01](https://www.youtube.com/watch?v=tt9QidsVtYI&t=301s) Standard vector retrieval suffers from four major flaws: utilizing only a fraction of structured enterprise data, missing domain rules, conflating semantic similarity with relevance, and lacking explainability. - [05:01](https://www.youtube.com/watch?v=tt9QidsVtYI&t=301s) GraphRAG is designed as a hybrid layer that augments rather than necessarily replaces vector search, combining structural graph traversals with vector similarity. - [10:02](https://www.youtube.com/watch?v=tt9QidsVtYI&t=602s) The value proposition of GraphRAG centers on three pillars: higher retrieval accuracy, more intuitive data modeling for developers, and transparent governance and auditability. - [10:02](https://www.youtube.com/watch?v=tt9QidsVtYI&t=602s) Empirical research from data.world demonstrated an average accuracy improvement of 300% when adding a knowledge graph to vector retrieval across enterprise benchmarks. - [13:20](https://www.youtube.com/watch?v=tt9QidsVtYI&t=800s) Production case studies from LinkedIn showed a 28.6% reduction in customer service issue resolution time after implementing knowledge graphs. - [15:10](https://www.youtube.com/watch?v=tt9QidsVtYI&t=910s) Autonomous AI agents use GraphRAG within an iterative Thought-Action-Observation loop to plan steps, invoke graph tools, and reason over corporate data fabrics. - [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) The Model Context Protocol (MCP) serves as a standardized bridge connecting enterprise knowledge graphs and tools directly to LLM agents. - [19:08](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1148s) In domain-specific enterprise settings with rich explicit relations, knowledge graphs can completely bypass vector search to deliver deterministic and accurate retrieval.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=tt9QidsVtYI&t=4s) Welcome and Foundations: From AI Ethics to Knowledge Graphs

Nyah Macklin, a Senior Developer Advocate on the developer relations team at Neo4j, opens the session with an energetic introduction to her background and core focus areas. Beyond diving deep into graph algorithms and GraphRAG, Macklin emphasizes her strong personal and professional dedication to responsible artificial intelligence, algorithmic governance, safety, and ethics—topics she considers paramount when speaking at major AI conferences. Her outreach extends to universities, high schools, and educational non-profits, giving passionate shoutouts to organizations like Girls Who Code and Black Girls Code to emphasize the necessity of broad inclusion: "We're trying to make sure that we have everyone in this space. Okay? Period."

Setting the groundwork before tackling complex architectures, Macklin establishes common terminology by polling the room on who has encountered knowledge graphs. Seeing a sea of hands go up, she defines a knowledge graph as an organized representation of real-world entities and their relationships, typically housed within a native graph database that explicitly stores connections between data points. Entities (or nodes) represent discrete objects, events, situations, or abstract concepts, while the connecting edges capture essential context and meaning. To make the concept intuitive, she gestures to a colleague in the room: if she is a node and a fellow speaker is a node, the relationship connecting them is that they are now good friends.

```mermaid flowchart LR accTitle: Knowledge Graph Node and Edge Example A["Nyah Macklin (Node / Entity)"] -->|"FRIENDS_WITH (Edge / Relationship)"| B["Fellow Speaker (Node / Entity)"] ```

[02:00](https://www.youtube.com/watch?v=tt9QidsVtYI&t=120s) Standard RAG Architecture vs. The GraphRAG Paradigm

Macklin walks the audience through the standard vector-based Retrieval-Augmented Generation (RAG) pipeline to establish a baseline. In a conventional pipeline, source documents such as unstructured PDFs are ingested, chopped into smaller text chunks, and indexed using a text embedding model. At query time, a user prompt is embedded using that same model to calculate vector similarity and retrieve the top-$k$ most semantically relevant text chunks. Those raw retrieved passages, along with the prompt, are fed into a large language model (LLM) to synthesize the final response.

```mermaid flowchart TD accTitle: Traditional RAG Pipeline vs GraphRAG Path subgraph Traditional["Standard Vector RAG Pipeline"] direction TB A["Source Documents (PDFs)"] --> B["Text Chunking"] B --> C["Embedding Model"] C --> D["Vector Database"] Q["User Query"] --> C D -->|"Top-k Chunks"| M["LLM Response Synthesis"] end subgraph GraphAugment["GraphRAG Path"] direction TB KG["Knowledge Graph Store"] -->|"Graph Traversal & Enrichments"| M end ```

Contrasting this with GraphRAG, Macklin asks the room who can define it, playfully noting the hesitant hands before breaking it down to its fundamental essence: in the simplest terms, "GraphRAG is RAG where the retrieval path includes a knowledge graph." By placing a native graph database directly into the retrieval flow, systems can combine graph-enhanced vector searches with topological graph enrichments and multi-hop graph algorithms, transforming how external grounding context is surfaced for generation.

[03:25](https://www.youtube.com/watch?v=tt9QidsVtYI&t=205s) When Standard RAG Suffices vs. When GraphRAG Is Essential

To help engineering teams choose the right tool for the job, Macklin demystifies the trade-offs between standard vector RAG and GraphRAG. She acknowledges that vector-based RAG remains perfectly sufficient for simple, factual lookups that resemble standard search engine queries—humorously citing prompts like "find me a low sugar ice cream." For basic semantic matches on flat text, a vector database performs reliably without unnecessary architectural overhead.

However, when an application requires generating complex insights that depend on the explicit connections between disparate entities or across separate data silos, standard vector search quickly breaks down. GraphRAG becomes essential for use cases like deep source code dependency analysis, complex supply chain traceability, and queries requiring multi-document aggregation, concatenation, or multi-hop relationship traversals across enterprise databases.

- **Standard Vector RAG sweet spot**: Questions resolvable by traditional search queries, surface-level semantic search, single-chunk factual retrieval. - **GraphRAG sweet spot**: Enterprise data integration, multi-hop relationship tracking, cross-document aggregation, supply chain dependency analysis, and source code mapping.

[05:01](https://www.youtube.com/watch?v=tt9QidsVtYI&t=301s) The Four Critical Limitations of Vector-Only Retrieval

Addressing the common developer mindset of "if it ain't broke, don't fix it," Macklin acknowledges that vector databases have been invaluable for demonstrating the "art of the possible" in generative AI. However, she argues that as enterprise business requirements mature, four severe limitations of vector-only retrieval become unavoidable:

1. **Leveraging Only a Fraction of Data**: Vector databases index unstructured text chunks and basic metadata, completely discarding the rich, structured relationships that define enterprise operations unless an engineering team stands up a separate embedded graph service. 2. **Missing Domain-Specific Context**: Vector databases struggle when domain rules or multi-hop logic are required. Macklin illustrates this contrast: both a vector store and a knowledge graph can answer a single-hop lookup like "who is the CEO of my company?" But if the query becomes "which board meetings in the last 12 months had at least two members abstain from a vote?", vector embeddings return a blurry point in semantic space between those concepts rather than the precise set of records. A knowledge graph, by contrast, traverses the exact relationships between meetings, board members, dates, and voting actions to return definitive facts. 3. **Semantic Similarity Is Not Relevance**: Semantic vector distance does not equal logical or factual relevance. Lacking fine-grained deterministic filters, vector retrieval often yields duplicative, noisy, or hallucinated associations. For instance, asking "who is on the product management team?" might cause a vector database to incorrectly list an engineer or executive who merely left numerous comments across product documents. A knowledge graph checks explicit organizational relationship edges, returning only verified team members. 4. **Lack of Explainability and Black-Box Data Quality**: Vector databases provide basic metadata citations but fail to provide visibility into *why* certain passages were pulled over others. If an LLM misidentifies a team member based on vector similarity, engineering teams have no audit trail to discover the underlying mathematical inference error, making iterative debugging nearly impossible.

Macklin emphasizes that GraphRAG is not about throwing away vector search entirely, but rather creating a hybrid paradigm: "Use both. GraphRAG is not looking to completely replace your vector layer... it's most beneficial as an added layer onto your vector architecture so that you can get the benefits of both vector search and graph traversal."

[10:02](https://www.youtube.com/watch?v=tt9QidsVtYI&t=602s) The Three Core Pillars of GraphRAG

Macklin summarizes the value proposition of integrating a knowledge graph into three major operational pillars: higher accuracy, easier development, and robust explainability and governance.

```mermaid flowchart LR accTitle: The Three Pillars of GraphRAG subgraph Pillars["Core Benefits of GraphRAG"] P1["Higher Accuracy (Grounding & Answer Quality)"] P2["Easier Development (Intuitive Data Modeling)"] P3["Explainability & Governance (Traceability & Audit Paths)"] end ```

Expanding on **higher accuracy**, she references empirical research from data.world published in November 2023. Testing a benchmark of 43 enterprise questions, the researchers demonstrated that integrating a knowledge graph alongside vector search yielded an average response accuracy improvement of 300% (a 3x increase in quality) compared to vector search alone, proving that structured contextual grounding drastically improves generative outputs.

For **easier development**, Macklin explains that once developers overcome the initial learning curve of graph thinking, modeling relational facts is far more intuitive. Stating "apples and oranges are both fruit" in graph space is straightforward: an `Apple` node and an `Orange` node both share an `IS_A` edge pointing to a `Fruit` node. In vector space, that same statement becomes an opaque embedding vector plotted as high-dimensional coordinates on a hyper-plane. Graphs allow developers to perform both explicit structural taxonomies and implicit similarity calculations (such as cosine or Euclidean distances), alongside explicit traversals and Approximate Nearest Neighbor (ANN) search algorithms, simplifying data exploration.

Finally, **explainability and governance** provides a clear path of deterministic traversal, enabling organizations to trace exactly which nodes and edges informed the LLM's answer—a prerequisite for compliance, auditability, and regulatory governance.

[13:20](https://www.youtube.com/watch?v=tt9QidsVtYI&t=800s) Independent Validation: LinkedIn and Microsoft Research

Macklin addresses the audience's natural skepticism by pointing to major external benchmarks that validate GraphRAG in production environments:

- **LinkedIn Customer Service Case Study**: A seminal technical paper by LinkedIn's staff software engineering team, titled *"Retrieval-Augmented Generation and Knowledge Graphs for Customer Service Question Answering"*, evaluated the impact of incorporating knowledge graphs into their automated support workflows. The study showed a 28.6% reduction in per-issue resolution time, delivering major operational savings and faster customer resolutions without any involvement from Neo4j. - **Microsoft Research Office of the CTO**: A landmark study on Query-Focused Summarization (QFS) demonstrated that GraphRAG significantly outperforms traditional vector RAG when synthesizing comprehensive global summaries across massive document collections. - **Central Research Repository**: For engineers seeking additional benchmark data, Macklin directs the audience to scan the on-screen materials and visit `graphrag.com/appendices`, an open resource cataloging independent research papers across the AI ecosystem.

[15:10](https://www.youtube.com/watch?v=tt9QidsVtYI&t=910s) Empowering AI Agents: The Thought-Action-Observation Loop

Transitioning from static RAG pipelines to autonomous systems, Macklin explores how GraphRAG forms the enterprise memory backbone for AI agents. She defines an agent as a generative application designed to autonomously plan, reason, and take goal-directed actions within complex business environments where operational rules cannot be easily hardcoded.

```mermaid flowchart TD accTitle: Agentic Thought Action Observation Cycle subgraph AgentLoop["Agent Execution Cycle"] direction TB T["1. Thought (Agent reasons on required steps)"] --> A["2. Action (Function call / Tool selection / API invocation)"] A --> E["Tool Execution (Query database / External call)"] E --> O["3. Observation (Execution output fed back into LLM)"] O --> T end ```

Agents implement this reasoning capability using prompt wrappers that enforce an iterative cycle: 1. **Thought**: The LLM analyzes the background instructions, user objectives, and existing context to reason about what step must be taken next. 2. **Action**: The model selects a specific tool from a predefined list (specifying required API or database parameters), and generation pauses while the tool executes. 3. **Observation**: The raw output of that function call or database query is fed back into the context window as an observation, prompting the model to resume generation and determine whether to complete the task or initiate the next cycle.

By providing agents with graph tools and native traversals, the agent can navigate complex corporate data fabrics, retrieve factual connections, and carry out structured multi-step enterprise workflows far beyond the limitations of simple text generation.

[17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) Enterprise Agent Architecture with Knowledge Graphs and MCP

Nyah Macklin presents a comprehensive architectural blueprint illustrating how a knowledge graph integrates into an AI agent system. In describing the layout on screen, she laments the lack of a laser pointer—noting, "I wish this had a pointer on it, but I can't. So, I can't show it to you"—before visually guiding the audience through the components. At the center sits the agent itself (located in the teal box), which connects to a user interface that exposes it as a knowledge assistant capable of handling semantic search, automation, and personalized user experiences. Surrounding the agent are the AI models at the top left—utilizing both embedders and large language models (LLMs)—and various structured and unstructured data sources at the bottom left.

```mermaid flowchart TD accTitle: Knowledge Graph Agent Architecture subgraph Core ["Agent Core"] UI["User Interface / Knowledge Assistant"] AGENT["AI Agent"] UI --- AGENT end

subgraph Intelligence ["AI Layer"] LLM["LLMs & Embedders"] end

subgraph Data ["Data & Context Layer"] SOURCES["Structured & Unstructured Data"] KG[("Knowledge Graph")] MCP["Model Context Protocol (MCP)"] SOURCES --> KG KG --- MCP end

AGENT <--> LLM AGENT <--> MCP ```

This data is ingested directly into the knowledge graph, which the agent then accesses via the Model Context Protocol (MCP). Macklin highlights MCP as "the golden standard for connecting tools and context to LLM models and agents," providing a structured bridge between the reasoning engine and contextual data. By combining a knowledge graph with an MCP-based architecture, the underlying graph schema equips the agent with immediate context. When a user prompt is broken down, the system can map out direct, logical flows of information that standard RAG setups miss.

- **UI Capabilities:** Exposes the agent as a knowledge assistant supporting semantic search automation and personalized user experiences. - **Model Layer:** Combines LLMs and embedders to process incoming requests and reason over graph context. - **Data Ingestion:** Handles both structured and unstructured enterprise data sources feeding into the knowledge graph. - **Protocol Integration:** Uses MCP to allow agents to securely and standardizedly query the graph schema.

[19:08](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1148s) Bypassing Vector Search and Closing Insights

Building on the power of this unified graph and MCP setup, Macklin delivers her closing technical takeaway: in certain scenarios, the rich context provided by a knowledge graph allows engineering teams to eliminate vector search entirely for retrieval tasks. By capturing domain knowledge and explicit relationships natively within the graph, agentic workflows can achieve superior accuracy and domain alignment without depending on probabilistic semantic similarity search.

Reflecting on the sheer volume of concepts covered in the talk, Macklin acknowledges how fast they moved through the material—"That was a lot. We blew through a lot and again I just wanted to make sure that I went into a lot of detail." She emphasizes that while this presentation provided the theoretical foundation, developers looking to implement GraphRAG have several concrete avenues to deepen their practical skills.

- **Eliminating Vector Dependencies:** High domain knowledge and explicit graph relations can replace vector search in specialized retrieval pipelines. - **Accuracy Gains:** Graph context directly improves precision and logical reasoning in multi-hop agentic workflows.

[19:51](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1191s) Community Resources, Conferences, and Hands-On Learning

To wrap up her session, Macklin provides several key resources for attendees wanting to pursue further research or get hands-on experience. She shares a dedicated online hub for GraphRAG learning materials at `[graphrag.com/appendices](https://graphrag.com/appendices)` and invites attendees to participate in Neo4j's annual developer conference. Noticing audience members whipping out their phones to capture the slides, she warmly notes, "I see people taking pictures. Come see me after as well."

For those seeking interactive practice rather than theory, she points to Neo4j's Graph Academy, describing it as an excellent destination for hands-on, keyboard-level training. She concludes by inviting the audience to visit the team in person at booth 548 before giving a friendly sign-off: "All right, y'all. Thank you so so much for coming and it's been a pleasure."

- **Documentation & Research:** Core GraphRAG resources are available at `[graphrag.com/appendices](https://graphrag.com/appendices)`. - **Developer Conference:** Neo4j hosts a free, fully remote, one-day global developer conference annually on November 6th, featuring community, Neo4j, and partner sessions focused on graph technology. - **Interactive Training:** Neo4j Graph Academy offers self-paced, hands-on tutorials and courses for developers. - **In-Person Engagement:** Neo4j team presence at Booth 548 for direct follow-up discussions and questions.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=tt9QidsVtYI&t=4s) We're trying to make sure that we have everyone in this space. Okay? Period. — Nyah Macklin

> [02:00](https://www.youtube.com/watch?v=tt9QidsVtYI&t=120s) GraphRAG is RAG where the retrieval path includes a knowledge graph. — Nyah Macklin

> [03:25](https://www.youtube.com/watch?v=tt9QidsVtYI&t=205s) find me a low sugar ice cream. — Nyah Macklin

> [05:01](https://www.youtube.com/watch?v=tt9QidsVtYI&t=301s) if it ain't broke, don't fix it, — Nyah Macklin

> [05:01](https://www.youtube.com/watch?v=tt9QidsVtYI&t=301s) Use both. GraphRAG is not looking to completely replace your vector layer... it's most beneficial as an added layer onto your vector architecture so that you can get the benefits of both vector search and graph traversal. — Nyah Macklin

> [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) I wish this had a pointer on it, but I can't. So, I can't show it to you — Nyah Macklin

> [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) the golden standard for connecting tools and context to LLM models and agents, — Nyah Macklin

> [19:08](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1148s) That was a lot. We blew through a lot and again I just wanted to make sure that I went into a lot of detail. — Nyah Macklin

> [19:51](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1191s) I see people taking pictures. Come see me after as well. — Nyah Macklin

> [19:51](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1191s) All right, y'all. Thank you so so much for coming and it's been a pleasure. — Nyah Macklin

## Mentioned Nyah Macklin, Neo4j, Girls Who Code, Black Girls Code, GraphRAG, data.world, LinkedIn, Microsoft Research, Retrieval-Augmented Generation and Knowledge Graphs for Customer Service Question Answering, Model Context Protocol (MCP), Neo4j Graph Academy

## Video description Nyah Macklin, Senior Developer Advocate for Artificial Intelligence, Neo4j

Abstract

When AI agents have to execute complex, multi-hop reasoning across interconnected knowledge domains, traditional Retrieval-Augmented Generation (RAG) systems fail. Although vector-based retrieval is very good at finding content that is semantically similar, it is unable to find meaningful connections between related data points, which leads to fragmented insights. In this talk, we will dive into how engineering teams can use GraphRAG and knowledge graphs to ground agents and large language models (LLMs) to uncover connections in enterprise data that are often missed by conventional RAG techniques. Attendees will learn how this improved architecture makes accurate, explainable, and reliable answers to complex business problems, possible.

[Source](https://www.youtube.com/watch?v=tt9QidsVtYI)

中文简报

Neo4j力推知识图谱，破解AI多跳检索局限标准向量检索在企业级多步推理中表现乏力，但若将AI智能体锚定于知识图谱和标准协议，可使响应准确率提升至三倍并消除对向量检索的依赖。 Nyah Macklin深入剖析了从标准纯向量检索增强生成（RAG）向GraphRAG的架构转变，阐明了原生知识图谱如何化解向量检索在处理复杂多跳关系、领域逻辑和可解释性方面的核心缺陷。结合来自data.world、LinkedIn与Microsoft Research的实证案例，她概述了GraphRAG的三大核心支柱：更高的准确性、直观的数据建模以及稳健的治理能力。最后，她展示了知识图谱与模型上下文协议（MCP）如何通过“思考-行动-观察”（Thought-Action-Observation）循环赋能自主AI智能体，以执行确定性的企业工作流。 GraphRAG 将原生知识图谱直接引入检索流程，弥补传统向量 RAG 忽视显式关系、混淆语义相似度与事实相关性以及缺乏可解释性的缺陷，专为复杂多跳推理与跨文档聚合场景设计。 (2:00) GraphRAG 围绕提高准确度、简化关系建模与增强可追溯治理三大支柱展开；data.world 的基准测试显示，结合知识图谱后回答准确率平均提升了 300%。 (10:02) 实际生产案例验证了其显著效益，LinkedIn 在客服问答系统中引入知识图谱辅助后，客户支持问题的解决时长缩减了 28.6%。 (13:20) 在企业级 AI Agent 架构中，知识图谱通过模型上下文协议（MCP）作为上下文主干，使 Agent 能够实现精准的多步推理，在特定深度领域甚至可完全替代向量检索。 (17:37)

Reading summary

Nyah Macklin, Senior Developer Advocate at Neo4j, argues that traditional vector-only retrieval fails to handle complex enterprise relationships, requiring knowledge graphs to supply structured domain context, multi-hop reasoning, and explainability. Integrating graph traversals alongside or in place of vector search provides the factual grounding necessary for accurate large language model outputs and autonomous agentic workflows. Structural Deficits of Vector-Only Retrieval (5:01) Standard vector retrieval relies on text chunking and semantic similarity, which Macklin notes is sufficient for basic factual lookups like finding low-sugar ice cream. However, vector stores discard explicit data relationships, breaking down when handling complex cross-silo queries, supply chain traceability, or code dependencies. Macklin details four critical limitations in vector-only architectures: they leverage only a fraction of structured enterprise data, fail at domain-specific multi-hop logic, conflate semantic similarity with factual relevance, and lack explainable audit trails. For example, while a vector database returns a blurry semantic average when asked to identify board meetings where at least two members abstained from a vote—or misclassifies an active document commenter as an official product management team member—a knowledge graph executes deterministic traversals across verified nodes and edges to surface exact answers. Empirical Performance Gains and Auditable Governance (10:02) Macklin defines the value of GraphRAG across three operational pillars: higher accuracy, intuitive development, and robust explainability. Modeling facts as explicit nodes and edges simplifies relational data management compared to navigating high-dimensional embedding spaces, allowing teams to pair structural taxonomies directly with vector search and approximate nearest neighbor algorithms. Crucially, deterministic graph paths provide auditability for compliance and governance, enabling teams to trace the exact data points informing a generated answer. To substantiate these claims, Macklin cites external research rather than internal Neo4j benchmarks alone. A November 2023 evaluation by data.world across 43 enterprise questions showed a 300% (3x) accuracy improvement when combining a knowledge graph with vector search over vector search alone. Additionally, an independent LinkedIn study on customer service workflows demonstrated a 28.6% reduction in per-issue resolution time, and Microsoft Research documented GraphRAG's superiority over vector baselines in Query-Focused Summarization over large text corpora. Grounding Autonomous Agents Through Graph Traversal (15:10) Beyond static retrieval pipelines, Macklin positions knowledge graphs as the operational memory backbone for autonomous AI agents. These agents navigate unstructured environments by running an iterative Thought-Action-Observation loop, where the model reasons about next steps, calls external tools or databases, and consumes the execution output before continuing. In Macklin's enterprise architecture, structured and unstructured sources feed into a central knowledge graph connected to the agent via the Model Context Protocol (MCP), which she describes as the emerging standard for linking models with tools. While GraphRAG is predominantly implemented as an added layer over vector stores to blend similarity search with graph traversal, Macklin notes that in environments with mature domain models and explicit relationships, teams can bypass vector search entirely to rely on deterministic graph retrieval. Macklin concludes that while vector embeddings demonstrated the initial potential of generative AI, enterprise-grade deployments require structured knowledge graphs to resolve multi-hop queries and eliminate black-box retrieval errors. Although developers must navigate the initial learning curve of graph data modeling, independent empirical studies indicate that graph-augmented architectures are critical for reliable, auditable agentic systems.

精炼阅读摘要

Neo4j 资深开发者布道师 Nyah Macklin 指出，传统的纯向量检索增强生成（Vector RAG）在面对跨系统实体关联与深层多跳逻辑时存在显著局限；通过在检索路径中融入原生知识图谱（GraphRAG），企业能够结合显式实体拓扑与向量语义，大幅提升大语言模型及自主智能体（AI Agent）的准确率、可解释性与数据治理能力。纯向量检索瓶颈与混合检索架构 (5:01) Macklin 指出，向量数据库在验证生成式 AI 的概念可行性阶段发挥了关键作用，对于类似传统搜索引擎的浅层事实查询（例如寻找低糖冰淇淋）表现良好。然而，随着企业业务需求成熟，纯向量检索暴露出了四个关键缺陷：首先，向量库仅对非结构化文本块及基础元数据进行索引，丢失了企业运营中高度关联的结构化实体关系；其次，向量检索缺乏领域特定逻辑与多跳推理能力，面对类似“过去12个月内至少两名成员弃权的董事会会议”这一查询时，嵌入模型只能返回概念间的模糊空间交集，而无法像知识图谱那样精准追踪会议、成员、日期与表决动作之间的确定性路径。第三，语义相似度并不等同于逻辑或事实相关性，缺乏确定性过滤机制容易导致噪声与幻觉，例如向向量库查询“产品管理团队成员”时，系统可能仅仅因为某位工程师在产品文档中发表了大量评论而将其错误归入团队，而知识图谱则能依据组织架构关系边进行严格验证；第四，向量检索缺乏可解释性，仅提供文档引用却无法说明选择特定片段的底层推理逻辑，使得工程团队难以审计和排查数学推断错误。针对这些痛点，Macklin 强调 GraphRAG 并非完全抛弃向量层，而是倡导一种混合架构，将向量近似最近邻搜索与图遍历的显式约束相结合，兼顾二者的检索优势。三大价值支柱与外部实证基准 (10:02) Macklin 将知识图谱融入 RAG 的核心价值归纳为三大支柱：更高准确度、更易开发维护以及透明的可解释性与治理机制。在开发体验方面，知识图谱的关系建模贴近人类直觉，例如定义“苹果和橙子都是水果”只需将两个节点通过“属于”（IS_A）关系指向水果节点，而无需将其投射为高维超平面上晦涩的坐标向量；同时图数据库还支持在统一框架内结合余弦或欧几里得距离计算以及图拓扑算法。在治理层面，图谱的确定性遍历路径为受合规监管的企业提供了清晰的审计追踪链条，可精确复现支撑大模型回答的特定节点与关系。为证明架构的有效性，Macklin 列举了多项独立第三方的实证研究数据。数据管理平台 data.world 于 2023 年 11 月发布的基准测试显示，在 43 个企业级真实查询中，引入知识图谱辅助的检索方案相比纯向量检索，其回答准确率平均提升了 300%（即回答质量提升 3 倍）。在生产环境落地层面，LinkedIn 软件工程团队在客户服务问答场景下引入知识图谱后，将单次工单解决耗时降低了 28.6%，在没有 Neo4j 参与的情况下实现了显著的运营降本；此外，微软研究院首席技术官办公室针对查询聚焦摘要（QFS）的研究亦证实，在海量长文档综合摘要任务中，GraphRAG 的生成表现显著优于传统向量基线。智能体推理循环与 MCP 企业架构 (15:10) 从静态检索扩展到自主系统，知识图谱正成为 AI 智能体（AI Agent）的核心企业记忆基座。Macklin 将智能体定义为能够自主规划、推理并在非硬编码规则环境下采取目标导向行动的生成式应用。这类智能体通过“思维—行动—观察”（Thought-Action-Observation）循环运作：大语言模型首先解析任务目标与既有上下文推导下一步行动，随后从工具集中调用特定 API 或数据库接口并暂停生成，最后将工具执行返回的真实数据注入上下文作为观察结果，驱动模型继续推理或完成任务。图谱的原生遍历能力为智能体跨越复杂数据孤岛执行多步业务流提供了坚实的事实支撑。在系统架构落地层面，企业通过将结构化与非结构化数据直接摄入知识图谱，并借助模型上下文协议（Model Context Protocol, MCP）将其连接至位于核心的智能体层。Macklin 指出，MCP 已成为连接大模型与外部工具和上下文环境的黄金标准，它允许智能体通过标准化接口安全、规范地检索图谱 Schema。更进一步，Macklin 提出了一项技术洞见：在业务领域知识高度结构化、实体关系高度明确的特定检索场景中，知识图谱能够完全替代概率性的向量语义相似度搜索，直接利用精确的图拓扑路径驱动智能体完成推理，彻底消除向量检索带来的概率偏差。 Macklin 的论述表明，GraphRAG 正在推动生成式 AI 从单点文本比对迈向严密的结构化知识协同，特别是在企业客服、代码依赖映射和供应链溯源等关键场景中展现了明确的工程降本与增效成果。然而，该架构的落地仍取决于企业对领域本体建模的成熟度以及跨源数据清洗整合的质量；随着 MCP 协议的普及与社区对图思维开发范式的接受，确定性图结构与生成式智能体的深度融合将成为解决大模型合规与幻觉问题的核心演进路径。

Detailed notes — zh

## Background 本内容由 YouTube 频道 Ai4 于 2025 年 8 月 29 日发布，主讲人为 Neo4j 高级 AI 开发者布道师 Nyah Macklin。演讲围绕 GraphRAG 展开，深入探讨了工程团队如何借助知识图谱克服传统向量检索的局限，为 AI Agent 和大语言模型提供企业级的高精度、可解释且可靠的关联数据支持。 ## TL;DR 演讲系统对比了传统纯向量 RAG 与 GraphRAG 的架构差异，指出纯向量检索在处理复杂多跳推理、数据关系聚合与可解释性方面的固有缺陷。随后，讲者结合 data.world、LinkedIn 及微软研究院的实证研究，论证了引入知识图谱能够显著提升回答质量、降低工单耗时并简化开发探索。最后，演讲深入剖析了基于“思考-行动-观察”循环的 AI Agent 工作机制，展示了如何通过模型上下文协议（MCP）将 Neo4j 知识图谱深度整合进企业级 Agent 架构，以实现高确定性的任务执行。 ## Atmosphere & style 整场演讲充满激情且富有感染力，讲者在开篇不仅展现出极强的专业技术自信，还真诚融入了对负责任 AI 与多元技术社区的人文关怀。讲解风格通俗生动，善于用日常比喻化解枯燥的图论与向量概念，现场互动感极强。随着独立学术研究数据的层层展开与前沿 Agent 架构的呈现，演讲情绪从基础概念的循循善诱稳步推进至探讨技术前沿的高昂与笃定。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=tt9QidsVtYI&t=4s) 在推动 GraphRAG 与图算法技术的同时，AI 治理、系统安全以及负责任和包容性的技术生态至关重要。 - [00:49](https://www.youtube.com/watch?v=tt9QidsVtYI&t=49s) 知识图谱通过图数据库将现实世界的实体（节点）及其关联（关系）结构化，其核心威力在于能够精准捕获信息的业务上下文。 - [02:00](https://www.youtube.com/watch?v=tt9QidsVtYI&t=120s) GraphRAG 的本质是将知识图谱引入 RAG 检索路径中，用于解决复杂跨文档聚合、多跳关联计算及深层依赖分析等纯向量检索难以应对的高阶任务。 - [04:58](https://www.youtube.com/watch?v=tt9QidsVtYI&t=298s) 纯向量检索在企业级生产中存在致命瓶颈：割裂结构化关系、将语义相似度误判为业务相关度，且存在无法追溯决策路径的黑盒治理风险。 - [09:57](https://www.youtube.com/watch?v=tt9QidsVtYI&t=597s) 架构上演进并非淘汰向量，而是将知识图谱叠加在向量架构之上，实现向量模糊召回与图谱确定性路径遍历的优势互补。 - [10:50](https://www.youtube.com/watch?v=tt9QidsVtYI&t=650s) 根据 data.world 针对 43 个业务问题的实测，在向量检索基础上引入知识图谱后，LLM 的回答质量平均提升了 3 倍。 - [10:50](https://www.youtube.com/watch?v=tt9QidsVtYI&t=650s) 图空间以显式结构和分类体系直观呈现实体关系，相比高维向量嵌入的隐式表达更易于人类理解、调试与探索。 - [12:51](https://www.youtube.com/watch?v=tt9QidsVtYI&t=771s) LinkedIn 的独立白皮书研究证明，在客服问答系统中引入知识图谱与 RAG 架构后，单个工单的解决耗时显著降低了 28.6%。 - [15:10](https://www.youtube.com/watch?v=tt9QidsVtYI&t=910s) AI Agent 的本质是对 LLM 的工程封装，通过“思考（Thought）— 行动（Action）— 观察（Observation）”的循环调用外部工具以自动化复杂业务流程。 - [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) MCP（模型上下文协议）正在成为连接 Agent 与知识图谱等上下文工具的行业黄金标准。 - [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) 在特定业务场景下，知识图谱结合 MCP 能够提供极其完备的确定性上下文，系统甚至可以完全舍弃纯向量检索直接实现高精度推理与执行。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=tt9QidsVtYI&t=4s) 开场介绍与核心价值观：责任与包容性 AI Neo4j 开发者关系团队的高级开发者布道师 Nyah Macklin 开启了演讲。她介绍了自己的工作重点在于图算法（Graph Algorithms）以及本次演讲的核心主题——GraphRAG。除此之外，Nyah 强调自己极度关注技术伦理，尤其是在当下的 AI 大会环境中，AI 治理、系统安全性以及负责任的负责任人工智能（Responsible AI）至关重要。在投身技术传播的过程中，她在大学、高中以及非营利组织做过多场分享。她特别向推动技术多样性的公益组织致敬：“向 Girls Who Code 致敬，向 Black Girls Code 致敬。我们正努力确保每个人都能在这个领域占有一席之地，毋庸置疑（Period）。” - 演讲者：Nyah Macklin（Neo4j 开发者关系团队 / AI 高级开发者布道师） - 核心关注：图算法、GraphRAG、AI 伦理、AI 治理与负责任的人工智能 - 社区倡议：积极支持 Girls Who Code 与 Black Girls Code 等致力于技术多元化的组织 --- ### [00:49](https://www.youtube.com/watch?v=tt9QidsVtYI&t=49s) 核心术语奠基：什么是知识图谱？为了确保与会者在同一认知频道上，Nyah 首先对“知识图谱（Knowledge Graph）”这一基础概念进行了拆解与定义。现场大多数观众都举手表示听过该概念。从本质上讲，知识图谱是对现实世界实体及其相互关系的组织化表示，通常原生存储在能够直接保存实体间关系的图数据库（Graph Database）中。在知识图谱的结构中，“实体”或“节点（Nodes）”通常代表具体对象、事件、场景甚至是抽象概念；而连接这些节点的“关系（Relationships）”则精准捕获了信息连接的上下文与深层含义。Nyah 现场用了一个生动的类比：“如果我是一个节点，而坐在这里的另一位演讲嘉宾是另一个节点，我们之间建立的连接关系就是——我们现在是好朋友。”上下文（Context）正是知识图谱发挥威力的灵魂所在。 ```mermaid flowchart LR accTitle: 知识图谱基本结构示意图 A["实体/节点 A （例如：Nyah）"] -- "关系（捕获上下文语义） [好友 / 合作]" --> B["实体/节点 B （例如：演讲嘉宾）"] ``` --- ### [02:00](https://www.youtube.com/watch?v=tt9QidsVtYI&t=120s) 传统 RAG 与 GraphRAG 的架构对比 Nyah 带领大家回顾了标准 RAG（检索增强生成）的工作流：系统接收 PDF 等多种非结构化数据源并进行切块（Chunking），利用文本嵌入模型（Embedding Model）为文本块生成向量索引；在查询阶段，系统对用户查询生成相同的嵌入向量，在向量空间中检索出 Top-K 个最相关的文档切块，最后将这批切块作为上下文连同问题一起喂给大语言模型（LLM），由 LLM 生成最终答案。那么，究竟什么是 GraphRAG？Nyah 抛出问题后邀请观众互动，并给出了最精炼的定义：“用最简单的话来说，GraphRAG 就是将知识图谱引入检索路径（Retrieval Path）的 RAG 架构。”在检索路径中加入知识图谱后，系统能够执行基于图的检索模式与算法，例如图增强向量搜索（Graph Enhanced Vector Search）与图拓扑富化（Graph Enrichments）。 ```mermaid flowchart TD accTitle: 传统 RAG 与 GraphRAG 架构路径对比 subgraph Traditional_RAG ["传统向量 RAG 路径"] T1["多源文档 (PDFs)"] --> T2["文本切块 (Chunking)"] T2 --> T3["向量嵌入与索引"] T3 --> T4["Top-K 向量相似度检索"] T4 --> T5["大语言模型 (LLM)"] end subgraph GraphRAG_Path ["GraphRAG 增强路径"] G1["多源数据 + 结构化实体"] --> G2["知识图谱构建 (Nodes & Edges)"] G2 --> G3["图增强向量检索 / 图遍历富化"] G3 --> T5 end ``` 在选型决策上，Nyah 提供了一条清晰的经验法则： - **纯向量 RAG 的适用场景**：回答可通过常规搜索引擎解决的问题。例如“帮我找一款低糖冰淇淋”，直接使用向量相似度匹配即可轻松满足。 - **必须升级至 GraphRAG 的场景**：需要从数据及其关联关系中挖掘深层洞察的高阶任务。例如源代码静态依赖分析、复杂供应链推演，或者任何需要跨多个异构文档库进行数据聚合（Aggregation）与串联计算（Concatenation）的复杂业务。 --- ### [04:58](https://www.youtube.com/watch?v=tt9QidsVtYI&t=298s) 纯向量方案的四大致命局限针对业界普遍存在的“如果向量数据库没出毛病就别折腾（If it ain't broke, don't fix it）”的心态，Nyah 直言向量数据库在展示生成式 AI 的潜能时表现惊艳，但在面对严苛的企业级生产业务需求时，纯向量检索暴露出了不可忽视的瓶颈。 | 局限性维度 | 纯向量检索（Vector-Only）的表现与缺陷 | 知识图谱 / GraphRAG 的解决方案 | |:--- |:--- |:--- | | **数据利用率** | 仅能利用非结构化文本切块及少量基础元数据，割裂了结构化数据间的关系网。 | 原生打通非结构化与结构化数据，充分利用节点与关系捕获全局数据联结。 | | **领域特定上下文** | 局限于向量空间中的语义近似，难以捕捉复杂的跨实体逻辑与业务约束。 | 依靠确定性的图遍历（Graph Traversals）提供精准的多跳逻辑推理。 | | **检索精确度与相关性** | 向量相似度并不等同于业务相关度；缺乏高级过滤机制，易返回冗余或错误关联结果。 | 基于事实关系精准匹配实体，消除因为表面语义或共现频率带来的错误推断。 | | **可解释性与治理** | 黑盒检索；仅提供基础片段引用，无法溯源检索路径和错误归因。 | 具备完全白盒化的图路径追溯能力，清晰呈现证据链来源并支持数据治理。 | #### 1. 无法利用全局关系数据与丢失业务上下文纯向量检索只能处理部分数据片段。Nyah 举例说明了两者的根本差异：询问“谁是我们公司的 CEO？”，知识图谱和向量数据库都能轻松作答；但如果提问“在过去 12 个月里，哪些董事会会议有至少两名成员在投票中弃权？”，纯向量方案就会失效。向量数据库倾向于抓取向量空间中与“董事会”、“投票”、“弃权”处于中间语义位置的零散文本块，而无法精确聚合出符合条件的那几场特定会议；知识图谱则能沿着具有明确时态与属性的关系链条进行精准遍历。 #### 2. 向量相似度 ≠ 业务相关度（语义混淆案例）针对“谁属于产品管理团队（Product Management Team）？”这一问题，向量检索可能会检索到某个频繁在产品文档中留言审批的非产品人员，进而误判其为团队成员。而知识图谱依靠明确定义的组织架构从属关系（`[:MEMBER_OF]`），只会返回具有真实归属关系的成员，杜绝了模糊关联。 #### 3. 缺乏可解释性与黑盒数据隐患向量数据库虽然能提供基础的来源片段引用（Source Citations），但完全无法展示“系统为什么挑中了 A 文档而不是 B 文档”的内在决策逻辑。当模型给出错误推断时，工程师无法反查其推理依据的事实路径，陷入无法定位、无法撤销、无法迭代优化的黑盒困境。 --- ### [09:57](https://www.youtube.com/watch?v=tt9QidsVtYI&t=597s) 架构演进策略：融合向量与图的双重优势 Nyah 澄清道，倡导 GraphRAG 并不意味着要全盘推翻或彻底淘汰向量检索层。向量搜索依然是 RAG 拼图中的关键板块，最理想的架构是将知识图谱作为增强层叠加在现有的向量架构之上，实现向量相似度模糊召回与图谱确定性路径遍历的双剑合璧。 Nyah 总结了企业引入 GraphRAG 的三大核心红利，并为后续更深度的技术展开埋下伏笔： - **更高精准度（Higher Accuracy）**：显著提升大模型生成回答的质量与真实性，大幅抑制幻觉。 - **更简化的开发迭代（Easier Development）**：提供清晰的数据结构，使复杂多跳查询的开发与维护更加直观。 - **白盒可解释性与数据治理（Explainability and Governance）**：提供清晰的实体关系链路追踪，保障企业级合规与错误归因。 ### [10:50](https://www.youtube.com/watch?v=tt9QidsVtYI&t=650s) 知识图谱对检索质量的提升与数据表征优势演讲者引用了来自 data.world 的白皮书数据。该研究测试了 43 个不同的业务问题，结果表明，在传统向量检索（Vector Search）的基础上引入知识图谱（Knowledge Graph）后，大语言模型（LLM）的平均回答质量提升了整整 3 倍。这项发表于 2023 年 11 月的研究清楚地证明：知识图谱带来的显式上下文结构，能大幅改善生成式 AI（GenAI）应用的输出质量。除了回答质量更高之外，选择 GraphRAG（图增强检索生成）而非纯向量 RAG 的第二个关键优势在于**开发更简单、数据探索更直观**。演讲者举了一个浅显的例子：如果我们要表达“苹果和橙子都是水果”（apples and oranges are both fruit），在图空间（Graph Space）中，表达方式清晰明了——一个“苹果”节点、一个“橙子”节点，分别通过名为“is a”（是一种）的关系边（edge）连接到“水果”节点。但在纯向量空间（Vector Space）中，这个概念会被转化为高维度的嵌入向量计算（embedding calculation），在平面或多维坐标中分散为一组抽象的点，难以直接被人理解。 ```mermaid flowchart LR accTitle: Graph Space vs Vector Space Representation subgraph GraphSpace["图空间表达 (显式结构)"] A["苹果 (Apple)"] -->|"is_a"| F["水果 (Fruit)"] O["橙子 (Orange)"] -->|"is_a"| F end subgraph VectorSpace["向量空间表达 (隐式嵌入)"] V["[0.23, -0.81, 0.45,...] 高维向量点"] end ``` 在搜索与相似度计算方面，知识图谱能够兼顾显式（Explicit）与隐式（Implicit）计算： - **显式与分类搜索**：基于图节点的结构和分类体系（Taxonomy）进行精确图遍历（Graph Traversals）。 - **隐式与亚符号搜索**：使用欧氏距离（Euclidean）或余弦相似度（Cosine Similarity）配合近似最近邻算法（ANN, Approximate Nearest Neighbor）。 - 通过在检索链路中引入知识图谱，开发者不必被迫仅依赖近似和隐式搜索，使得数据的探索与调试更加便捷。 --- ### [12:51](https://www.youtube.com/watch?v=tt9QidsVtYI&t=771s) 可解释性、数据治理与行业权威白皮书验证演讲者指出了 GraphRAG 的第三大核心价值：**可解释性与数据治理（Explainability and Governance）**。当 LLM 生成最终回答时，系统可以通过遍历图谱精确溯源生成内容的事实路径，这在企业数据流程合规和审计中是不可或缺的硬性要求。针对现场观众可能存在的“口说无凭，谁在实际使用 GraphRAG？”的疑虑，演讲者列举了来自顶尖科技公司的权威独立研究： 1. **LinkedIn 团队的白皮书**：《Retrieval-Augmented Generation and Knowledge Graphs for Customer Service Question Answering》（用于客户服务问答的检索增强生成与知识图谱）。研究表明，在客服问答流水线中加入知识图谱后，每个工单的解决耗时（per-issue resolution time）**大幅降低了 28.6%**。演讲者特别强调，Neo4j 并未参与这项研究，这是 LinkedIn 团队的独立成果。 2. **微软研究院（Microsoft Research / CTO 办公室）白皮书**：论证了在查询聚焦摘要（QFS, Query-Focused Summarization）任务中，GraphRAG 相较于传统 RAG 的显著优势。 GraphRAG 正在迅速成为企业构建 RAG 系统的行业事实标准（de facto standard）。更多独立研究成果可访问汇总资源页面：`graphrag.com/appendices`。 --- ### [15:10](https://www.youtube.com/watch?v=tt9QidsVtYI&t=910s) AI Agent 的运作本质：Thought-Action-Observation 循环在总结了 GraphRAG 的三大核心优势（更高准确率、更简单开发、更强可解释性与治理）后，话题转向它如何赋能 AI 智能体（AI Agent）。演讲者首先给出了 Agent 的清晰定义：Agent 是一种利用生成式 AI 模型进行思考并为达成目标而行动的应用程序。它专为自动化企业复杂工作流而生，特别适用于那些业务规则模糊、难以纯靠硬编码程序定义逻辑的场景。 Agent 的底层机制本质上是对 LLM 的一层工程封装（Wrapper），通过特定的 Prompt 模板驱动其以 **“Thought（思考）— Action（行动）— Observation（观察）”** 循环执行任务： - **Thought（思考）**：分析当前状态，规划下一步要做什么。 - **Action（行动）**：从预定义的工具列表（Tools，本质是函数调用 Function Calling 或 API 调用）中选取一个，并指定必要的输入参数，随后暂停文本生成并执行该调用。 - **Observation（观察）**：接收工具执行返回的结果，作为上下文重新喂回给 LLM，驱动其继续推理或生成下一步动作。 ```mermaid flowchart TD accTitle: Agent Thought Action Observation Loop T["1. Thought (思考): 规划任务与下一步目标"] --> A["2. Action (行动): 选择工具/API并指定参数"] A --> E["执行外部调用 (Function / API Call)"] E --> O["3. Observation (观察): 获取执行结果并回传给模型"] O --> T ``` - Agent 编排框架（Orchestration Frameworks）将模型、工具与调用系统粘合在一起，使 Agent 能够执行实质性的系统操作，而不仅仅停留在文本生成层面。 --- ### [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) 基于知识图谱与 MCP 的现代化 Agent 架构演讲者展示了融入知识图谱的企业级 Agent 整体架构设计。整个系统各层级分工明确：前端提供面向用户的 UI 界面（如知识助手、自动化操作或个性化体验）；核心层为包含编排逻辑的 Agent；左侧由 Embedding 编码器与 LLM 模型提供底层推理支撑；底层接入结构化与非结构化多源数据，并统一摄入（Ingest）到知识图谱中。 ```mermaid flowchart TD accTitle: Enterprise Agent Architecture with Knowledge Graph subgraph UI_Layer["交互层 (UI)"] UI["智能知识助手 / 语义搜索 / 自动化界面"] end subgraph Agent_Core["Agent 核心层"] AG["AI Agent (规划、推理与编排调度)"] end subgraph Protocol["连接协议"] MCP["MCP (Model Context Protocol)"] end subgraph KG_Layer["数据与上下文层"] KG[("Neo4j 知识图谱 (Knowledge Graph)")] Data["结构化 / 非结构化企业多源数据"] end subgraph Model_Layer["模型层"] Models["LLM 推理模型 & 向量嵌入模型 (Embedders)"] end UI <--> AG AG <--> Models AG <-->|"工具调用"| MCP MCP <--> KG Data -->|"数据摄入 (Ingestion)"| KG ``` 在此架构中，Agent 通过 **MCP（Model Context Protocol，模型上下文协议）** 与知识图谱实现连接。演讲者指出，MCP 正在成为将工具和上下文连接到 LLM 模型与 Agent 的“黄金标准”（Golden Standard）。当用户提出复杂问题或指令时，知识图谱的严格模式（Schema）能为系统拆解 Prompt 提供极其精准的事实骨架与逻辑流向。演讲者给出了一个激进且强有力的结论：**在某些特定业务场景中，由于知识图谱结合 MCP 架构提供了极其完备的确定性上下文与领域知识，系统甚至可以完全舍弃向量检索（Vector Search）**，无需依赖概率性的语义相似度匹配即可实现极高精度的检索与任务执行。 --- ### [19:44](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1184s) 总结与生态资源指引在演讲尾声，演讲者整理了进一步深入学习 GraphRAG 和 Neo4j 的官方资源与活动入口： - **深度研究合集**：访问 `graphrag.com/appendices` 获取行业权威白皮书及参考资料。 - **年度线上开发者大会**：每年 11 月 6 日举办的完全免费、全远程开发者大会，内容涵盖社区实践、Neo4j 深度专题及合作伙伴分享。 - **实战学习平台**：推荐使用 **Graph Academy** 进行免费的在线动手实操实验（Hands-on Keyboard）。 - **展台交流**：现场参会者可前往 548 号展位与 Neo4j 团队深入交流。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=tt9QidsVtYI&t=4s) 向 Girls Who Code 致敬，向 Black Girls Code 致敬。我们正努力确保每个人都能在这个领域占有一席之地，毋庸置疑（Period）。 — Nyah Macklin > [02:00](https://www.youtube.com/watch?v=tt9QidsVtYI&t=120s) 用最简单的话来说，GraphRAG 就是将知识图谱引入检索路径（Retrieval Path）的 RAG 架构。 — Nyah Macklin > [00:49](https://www.youtube.com/watch?v=tt9QidsVtYI&t=49s) 如果我是一个节点，而坐在这里的另一位演讲嘉宾是另一个节点，我们之间建立的连接关系就是——我们现在是好朋友。 — Nyah Macklin > [04:58](https://www.youtube.com/watch?v=tt9QidsVtYI&t=298s) If it ain't broke, don't fix it（如果没出毛病就别折腾） — Nyah Macklin > [10:50](https://www.youtube.com/watch?v=tt9QidsVtYI&t=650s) 在传统向量检索（Vector Search）的基础上引入知识图谱（Knowledge Graph）后，大语言模型（LLM）的平均回答质量提升了整整 3 倍。 — Nyah Macklin > [15:10](https://www.youtube.com/watch?v=tt9QidsVtYI&t=910s) Agent 是一种利用生成式 AI 模型进行思考并为达成目标而行动的应用程序。 — Nyah Macklin > [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) MCP 正在成为将工具和上下文连接到 LLM 模型与 Agent 的“黄金标准”（Golden Standard）。 — Nyah Macklin > [17:37](https://www.youtube.com/watch?v=tt9QidsVtYI&t=1057s) 在某些特定业务场景中，由于知识图谱结合 MCP 架构提供了极其完备的确定性上下文与领域知识，系统甚至可以完全舍弃向量检索（Vector Search）。 — Nyah Macklin ## Mentioned Nyah Macklin, Neo4j, Girls Who Code, Black Girls Code, GraphRAG, data.world, LinkedIn, Microsoft Research, Model Context Protocol (MCP), Graph Academy ## Video description Nyah Macklin, Senior Developer Advocate for Artificial Intelligence, Neo4j Abstract When AI agents have to execute complex, multi-hop reasoning across interconnected knowledge domains, traditional Retrieval-Augmented Generation (RAG) systems fail. Although vector-based retrieval is very good at finding content that is semantically similar, it is unable to find meaningful connections between related data points, which leads to fragmented insights. In this talk, we will dive into how engineering teams can use GraphRAG and knowledge graphs to ground agents and large language models (LLMs) to uncover connections in enterprise data that are often missed by conventional RAG techniques. Attendees will learn how this improved architecture makes accurate, explainable, and reliable answers to complex business problems, possible. [Source](https://www.youtube.com/watch?v=tt9QidsVtYI)

Source quotes

[0:04] Nyah Macklin: 向 Girls Who Code 致敬，向 Black Girls Code 致敬。我们正努力确保每个人都能在这个领域占有一席之地，毋庸置疑（Period）。 [2:00] Nyah Macklin: 用最简单的话来说，GraphRAG 就是将知识图谱引入检索路径（Retrieval Path）的 RAG 架构。 [0:49] Nyah Macklin: 如果我是一个节点，而坐在这里的另一位演讲嘉宾是另一个节点，我们之间建立的连接关系就是——我们现在是好朋友。 [4:58] Nyah Macklin: If it ain't broke, don't fix it（如果没出毛病就别折腾） [10:50] Nyah Macklin: 在传统向量检索（Vector Search）的基础上引入知识图谱（Knowledge Graph）后，大语言模型（LLM）的平均回答质量提升了整整 3 倍。 [15:10] Nyah Macklin: Agent 是一种利用生成式 AI 模型进行思考并为达成目标而行动的应用程序。 [17:37] Nyah Macklin: MCP 正在成为将工具和上下文连接到 LLM 模型与 Agent 的“黄金标准”（Golden Standard）。 [17:37] Nyah Macklin: 在某些特定业务场景中，由于知识图谱结合 MCP 架构提供了极其完备的确定性上下文与领域知识，系统甚至可以完全舍弃向量检索（Vector Search）。

Source quotes

[0:04] Nyah Macklin: We're trying to make sure that we have everyone in this space. Okay? Period. [2:00] Nyah Macklin: GraphRAG is RAG where the retrieval path includes a knowledge graph. [3:25] Nyah Macklin: find me a low sugar ice cream. [5:01] Nyah Macklin: if it ain't broke, don't fix it, [5:01] Nyah Macklin: Use both. GraphRAG is not looking to completely replace your vector layer... it's most beneficial as an added layer onto your vector architecture so that you can get the benefits of both vector search and graph traversal. [17:37] Nyah Macklin: I wish this had a pointer on it, but I can't. So, I can't show it to you [17:37] Nyah Macklin: the golden standard for connecting tools and context to LLM models and agents, [19:08] Nyah Macklin: That was a lot. We blew through a lot and again I just wanted to make sure that I went into a lot of detail. [19:51] Nyah Macklin: I see people taking pictures. Come see me after as well. [19:51] Nyah Macklin: All right, y'all. Thank you so so much for coming and it's been a pleasure.

Original transcript

[0:04] So um again my name is Nia Mlin. Um we [0:07] will get right into it. Just a small [0:10] introduction to myself. My name is Nia [0:12] Mlin. I'm on the developer relations [0:14] team here at Neo4j. Um I often talk [0:18] about graph graph algorithms as well as [0:20] graph rag which we're going to talk [0:22] about today. Um I also really care about [0:25] ethics. So important especially being at [0:27] an AI conference. Okay. governance, [0:29] safety, and responsible artificial [0:32] intelligence. So, I've done talks at a [0:35] number of different uh places, [0:36] universities, high schools, nonprofits [0:38] as well. Shout out to Girls Who Code. [0:40] Shout out to Black Girls Code. We're [0:42] trying to make sure that we have [0:43] everyone in this space. Okay? Period. [0:46] All right. So, let's get into the talk [0:49] as well. So, first of all, uh before we [0:52] dive in, let's get some common [0:53] vocabulary underway, right? So, [0:56] knowledge graphs. Who's here have heard [0:57] about this concept of a knowledge graph? [1:00] Oh yes, most of the room love to see it. [1:02] Love to see it. Okay, so uh for those [1:05] who don't know, a knowledge graph is an [1:06] organized representation. Here's an [1:08] example right here. A knowledge graph is [1:10] an organized representation of real [1:12] world entities and their relationships, [1:14] right? So it's typically stored as uh [1:17] stored in a graph database, right? Uh [1:19] which natively stores the relationships [1:21] between the data entities. So entities [1:25] or nodes for I know a lot of us are [1:27] familiar nodes in a knowledgraph are [1:29] usually things like objects right um [1:32] events or situations or concepts even so [1:37] the relationships between these entities [1:39] they often capture context that [1:41] contextual piece is the key here and [1:44] meaning of how information is connected [1:47] so if I'm a node and my colleague here [1:50] is a node a fellow speaker we have a [1:52] relationship now that we are now good [1:55] friends. So, uh that is an example of a [1:58] knowledge graph. [2:00] All right. So, in a normal rag pipeline, [2:03] feel free to take a picture of this [2:04] architecture diagram. So, in a normal [2:06] rag pipeline, you can take in a number [2:08] of different PDFs, for example, [2:10] different data sources. You're going to [2:12] chunk that information and then index on [2:15] those chunks using a text embedding [2:18] model. So, then we have uh the time to [2:22] query those text chunks. We're going to [2:23] query the text chunks and we're going to [2:25] use that same embedding model to then [2:28] fetch the top maybe k or top x number of [2:31] relevant documents. Then we're going to [2:33] pass all of that to an LLM and the LLM [2:36] is going to give you the final answer [2:37] for the documents. [2:40] So what is this concept of graph rag? I [2:42] know you are all here in this building [2:44] probably to learn more but has anyone [2:46] heard of graph rag before? I see a lot [2:48] of hands. Okay, let me see let me make [2:50] sure I see the same number of hands. Who [2:52] can give me an explanation of graphag? [2:54] Don't be afraid. Yes. Okay, we have a [2:56] couple people. Everyone's like, um, I [2:59] don't know, Nia. Maybe, maybe not. But [3:02] that's perfect. So, I have a two two [3:04] wonderful people who should really just [3:05] join me up on this conversation. But, [3:08] um, but what is graph? So, in the [3:10] simplest terms, right, in the simplest [3:12] terms, graph rag is rag where the [3:15] retrieval path includes a knowledge [3:17] graph. Okay, so that is the most simple [3:20] terms of what graph rag is. [3:25] So now let's take a look at this [3:27] architecture of a graph rag application. [3:30] Love that y'all are taking your [3:32] pictures, y'all are doing your research. [3:34] So as illustrated in this architecture [3:37] diagram, we're including a knowledge [3:40] graph, a knowledge graph here on our [3:43] retrieval path which then allows us to [3:45] use graphbased retrieval patterns and [3:48] algorithms such as graph enhanced vector [3:51] search and graph enrichments as well. [3:54] But oftentimes when people ask me when [3:56] to use rag versus when to use graph rag, [4:00] usually I'd like to say that if you're [4:03] trying to answer a question that could [4:04] have been solved by a search engine, uh [4:07] then vectorbased rag can be enough, [4:11] right? It can be enough. So for example, [4:13] like find me a low sugar ice cream that [4:15] can easily be solved with vector only [4:18] rag. You don't have any problems. Use [4:19] your vector-based rag application or [4:22] architecture. But if you want to [4:24] generate insights right when from the [4:27] data including relationships between [4:30] that data and between data sources then [4:33] you'll probably need something more [4:35] advanced like graph rag right so for [4:38] example if you're trying to do source [4:40] code analysis right or if you have a [4:43] supply chain question or anything that [4:46] requires the aggregation or [4:48] concatenation [4:50] of data from different documents stores [4:53] then graph is highly beneficial here. [4:58] So I wanted to include this slide [5:01] because I I know that so many folks are [5:03] coming in here are saying you know what [5:04] Nia like I don't have any problem using [5:07] my vector only store there's no issues [5:09] here and um I'm just going to stick with [5:11] it and that can be perfectly fine but I [5:14] want to make sure to highlight some key [5:15] points on why a vector only approach you [5:19] know might not be sufficient. Some of [5:21] y'all are saying, "You know what, Nia, [5:22] if it ain't break if it ain't broke, [5:23] don't fix it." Right? Here's some key [5:26] reasons why you want might want to um [5:28] want to elevate from just using a vector [5:30] store. So, vector databases are amazing [5:34] when it comes to showing the art of the [5:36] possible with generative AI. However, [5:38] most business applications [5:40] uh with requirements that are more [5:42] demanding, right, uh will then need some [5:47] sort of enrichment. So this eventually [5:50] requires expanding beyond just using [5:52] vector databases. So while vector [5:54] databases may solve some hallucination [5:56] issues uh and offer basic source [5:59] traceability, they have several [6:01] different limitations. So number one [6:03] being that you can only leverage a [6:05] fraction of your data here. So you can [6:07] only uh really use your unstructured [6:10] data and perhaps some metadata, not the [6:13] relationships in your structured data [6:16] unless you stand up another solution [6:17] like your own graph embedded service for [6:19] example. [6:21] But another limitation is that you are [6:22] often missing critical domain specific [6:25] context. I mentioned context before. [6:27] This is critical. So because you can't [6:30] use all of your data, right? Um and [6:32] because vector databases just enable [6:34] embedding search your LLM applications [6:37] will miss critical domain specific [6:39] knowledge right so which you can compro [6:42] which can often compromise the quality [6:44] and the effectiveness of business [6:46] applications so for example right I'm [6:48] I'm talking a lot but let's get into [6:50] some examples so let's say both a [6:53] knowledge graph and a vector b vector [6:54] database can easily return an answer to [6:57] who's the CEO of my company right both [7:00] can solve that problem. But a knowledge [7:02] graph will outpace a vector database on [7:06] questions like which board meetings in [7:08] the last 12 months had at least two [7:11] members abstain from a vote, right? A [7:15] vector database is likely to find an [7:16] answer that's in the middle of the [7:18] subjects within vector space, right? And [7:21] not the specific answer. So a knowledge [7:25] graph looks for and returns precise [7:27] information based on traversing a graph [7:30] that is connected by relationships. [7:34] So another limitation of vector only [7:36] when it comes to rag is that you often [7:38] have poor retrieval results. So vector [7:41] similarity we have to remember does not [7:43] equal relevance here. So even leaving [7:47] what was just mentioned above aside, the [7:50] algorithms used in vector databases just [7:52] measure the semantic similarity which [7:55] doesn't always equate to relevance. So [7:58] vector database retrieval also doesn't [8:00] come with for example sophisticated [8:02] filters and this can result in many [8:05] duplicative irrelevant and sometimes [8:08] inaccurate results in rag. Now this is [8:11] not universally the case but this can [8:13] often be the case when using vector only [8:15] retrieval. So for example if we asked [8:19] who is on the product management team a [8:21] vector database might incorrectly infer [8:24] that someone was on the product [8:25] management team because they have [8:27] frequent commenting access to various [8:30] documents that the product team uses and [8:33] then it could return that person's name [8:36] in the results. So because a knowledge [8:39] graph uses nodes and relationships to [8:42] identify how people in an organization [8:44] are related, it would return only those [8:47] who are actually a part of the product [8:49] team. [8:50] So second to last I want to talk about [8:52] this uh lack of explanability piece [8:54] right and understanding grounding data. [8:56] So while vector databases offer basic [8:59] source citations in metadata, they do [9:02] not offer the vis the visibility in how [9:05] and why certain sources were retrieved [9:07] over others. Right? So further it can be [9:10] difficult to inspect and analyze your [9:12] grounding data which can result in [9:14] difficult to understand blackbox data [9:17] quality concerns that hinder LLM [9:19] performance and your ability to improve [9:22] and iterate over time. So for example [9:25] here right when a member of the product [9:27] team is misidentified the vector [9:29] database is not able to identify the [9:31] facts that was used to infer this [9:34] misinformation. So this means that it [9:36] isn't possible to undo or even [9:38] understand the source of the error here. [9:41] And then lastly I want to say that [9:43] vector search is only one piece of the [9:45] rag puzzle. I'm not saying to get rid of [9:47] vectoron base um rag completely. I'm [9:50] saying that it's only one part and so we [9:53] should augment that with knowledge [9:55] graphs. [9:57] Okay, that was a lot. So why use vector? [10:02] Why use graph rag over vectorbased rag? [10:04] Use both. Use both here, right? Graph [10:07] rag is not looking to completely replace [10:09] your vector layer. Although you can [10:12] completely replace it if you wish, but [10:13] it's most beneficial as an added layer [10:16] onto your vector architecture so that [10:17] you can get the benefits of both vector [10:19] search and graph traversal. [10:22] So just to summarize some of the [10:24] benefits of graph rag. So we have here [10:27] higher accuracy is a huge benefit of [10:29] using graph rag. Easier development also [10:32] a massive benefit. And then lastly [10:34] explainability and governance. These are [10:37] key benefits. I'm going to show this [10:38] slide again in a moment. [10:41] But now I want to show you all higher [10:43] accuracy. So one of the largest benefits [10:45] of graph rag versus standard rag is this [10:47] accuracy piece aka the quality of the [10:50] answer. So this one example from [10:52] data.world out of many white papers. [10:54] Feel free to scan the QR code here so [10:56] you can read it yourself. But the paper [10:58] found that they pulled out 43 different [11:00] questions. And they found that from that [11:02] sample size, the average response [11:05] quality was three times higher on [11:08] average when they used a knowledge graph [11:10] in addition to vector search. So now [11:13] this is not new information, right? This [11:14] white paper came out in 2023 of [11:16] November, right? So this is well known [11:18] that knowledge graphs and the additional [11:20] context they provide improve the [11:22] responses to LLMs as the output for [11:24] genai applications. [11:27] The second reason we hear people choose [11:29] graph rag over um vector only rag is [11:32] that once they've pushed through the [11:33] initial learning curve of learning graph [11:35] technology like we're doing right now [11:37] it's easier development. So uh if we [11:40] have the phrase for example apples and [11:42] oranges are both fruit. If we represent [11:44] that in graph space it's really easy [11:47] right? There's an apple node and a uh is [11:50] a relationship which is called an edge [11:53] and then a fruit node. Apples a fruit, [11:55] orange is a fruit. Very simple. But in [11:56] vector space, it can look a lot like [11:58] this with the actual embedding [12:00] calculation. And it can look like [12:02] several points on a plane as well. [12:06] So you can also run similarity [12:08] calculations on both explicit and [12:10] implicit data using more explicit [12:12] methods for structural and taxonomy [12:14] based similarity search on graph nodes [12:17] or using implicit or sub symbolic um [12:20] similarity searches like ukitian or [12:23] cosine similarities some uh searches [12:25] that you all have heard of before. [12:28] So then after that you can then uh run [12:31] search algorithms on using both explicit [12:33] graph traversals or more implicit [12:36] methods like approximate nearest [12:37] neighbor AN um uh algorithms. So instead [12:40] of forcing yourself to use implicit and [12:42] approximate searches, if you add a [12:44] knowledge graph onto your retrieval [12:46] path, the exploration of said data is [12:49] actually easier. Which leads us to the [12:51] third benefit of graph plus vector [12:55] explanability and governance. I love [12:58] when y'all take pictures. This makes me [12:59] so happy. So, finally, being able to [13:02] traverse a graph or trace the source of [13:06] an LLM's output allows us to better [13:08] explain the output that the LLM creates, [13:11] which is necessary, of course, for [13:13] auditing purposes of any data processes, [13:16] etc. All right, Nia, prove it. Right? [13:20] You're talking a lot. You're saying a [13:22] lot of these benefits. Prove it. Who [13:24] else is actually talking about graphite? [13:26] So number one, here is a seminal white [13:28] paper. I want you all to read this white [13:29] paper if you have not already. This is a [13:31] seminal white paper from the staff [13:32] software engineer from LinkedIn [13:36] and their team titled retrieval [13:38] augmented generation and knowledge [13:40] graphs for customer service question [13:42] answering. So this paper tested graph [13:44] rag to see whether it benefited customer [13:46] service question answering process. And [13:48] they found that by including knowledge [13:50] graphs into their rack pipeline, they [13:52] saw a decrease in perissue resolution [13:55] time by 28.6%. [13:59] Which is significant improvement for [14:01] vital customer support. So read this [14:03] white paper if you want to learn more [14:04] about this LinkedIn specific case study [14:06] on graph rag. We had nothing to do with [14:09] this. Uh they just put this paper out as [14:11] well. Right. [14:13] And here as well [14:15] is another white paper from the [14:17] Microsoft research team from the office [14:19] of the CTO on the benefits of using [14:21] graph rag over traditional rag for QFS [14:25] which is called query focused [14:26] summarization in LLM. Another seminal [14:29] white paper talking about graph rag. [14:31] We're just a graph database but we want [14:32] people to know the benefits of graph. [14:37] And here here is like an incredible [14:39] resource for folks as well. Definitely [14:41] take a picture of this. Graph and graph [14:42] rag are massive and it's becoming the de [14:45] facto way that organizations are [14:46] building their rag applications and [14:48] that's because there's so much [14:50] independent research investigating the [14:52] impacts of AI applications. So this is [14:55] just a small sample of the research and [14:57] make sure you take a picture of the link [14:59] here and go to graphrag.com/appendices. [15:04] Okay? And if you don't get it right now [15:06] I'm going to put this slide up again in [15:08] just a couple minutes. [15:10] So overall like we had mentioned the [15:12] benefits of using graph rag in your rag [15:15] applications higher accuracy easier [15:17] development and explanability and [15:19] governance. So how does this benefit AI [15:21] agents, right? So let's take a step [15:24] back. What is an agent? I know so many [15:26] of you all know this, but an agent is an [15:29] application that uses generative AI [15:30] models to think and act towards goals, [15:34] right? So they automate complex [15:36] enterprise workflows where you might [15:38] have rules that aren't very clear and [15:40] are not necessarily explained uh or [15:42] defined programmatically. So they use [15:45] reasoning and planning to determine the [15:47] steps that they're going to take next. [15:49] And then they can utilize those tools [15:51] aka function calling right tools is a [15:53] very particular word it's function [15:54] calling or API calls um which can then [15:57] allow a LLM to do anything like write [15:59] the function um the anything that you [16:02] would write a function for. So to access [16:04] data and then take actions like quering [16:06] a database or calling APIs like I had [16:08] mentioned before. So how they do this is [16:10] pretty much through a wrapper on the [16:12] LLM, right? So you're going to ask the [16:13] LLM to prompt in a specific way. You [16:15] then have it start by um adding [16:18] background context and instructions on [16:20] what you're going to do. And then you [16:21] ask it to always respond through [16:23] thought, action, observation. So you [16:26] start with a thought. What does the [16:27] agent need to do? Then you move to the [16:29] action, take a predefined list, and then [16:31] ask it to pick one of those tools and [16:34] specify some necessary parameters. And [16:36] then you're going to pause the [16:37] generation. You're going to execute on [16:39] that tool, either a function call or an [16:41] up or an API call, and then wait to see [16:44] what the results are. Then you're going [16:46] to feed all of that information back [16:48] into the LLM as the observation and as [16:51] the LLM asks the LLM to continue [16:53] generating. So this is a cycle thought, [16:56] action, observation. So this is the [16:59] nature of agentic applications and we [17:01] use the LLM to take concrete actions [17:04] beyond simple text generation. [17:08] So AI agents then we see that they plan, [17:11] they reason and they execute tasks using [17:15] tools, right? Tools which are function [17:16] calls and APIs and they orchestrate [17:19] frameworks which allow an agent to plan [17:21] and execute on the process when invoked. [17:24] And they're going to use these key [17:25] components, the model itself. They're [17:27] going to use all of the tools, the [17:29] orchestration, so how that uh that [17:32] process is being put together and then [17:34] executing on the system when invoked. [17:37] Now, this next slide is a really [17:39] important one because this next slide [17:40] shows what an agent architecture can [17:43] look like when you're including a [17:44] knowledge graph. So, you normally have [17:46] the agent itself. I wish this had a [17:48] pointer on it, but I can't. So, I can't [17:49] show it to you. But you normally have [17:50] the agent itself right here, um, which [17:53] is in the teal box. And you can have the [17:55] you and then you can also have an UI to [17:57] expose the agent as a knowledge [17:59] assistant for example with semantic [18:01] search automation or personalized [18:03] experiences. You then have the AI model [18:06] itself up at the top uh top left for you [18:10] um uh which is also going to use [18:12] embedders and LLMs. And then in the uh [18:15] the bottom left you're going to see um [18:18] data sources that you can use for [18:20] retrieval. Right? So both unstructured [18:22] and structured data and then that data [18:24] gets ingested into the knowledge graph. [18:27] So then the agent can access the [18:29] knowledge graph through tools like MCP. [18:31] We didn't really talk about this because [18:32] we don't have time but that's model [18:34] context protocol which is right now the [18:36] golden standard for connecting tools and [18:38] context to an LLM models and agents. Um [18:41] so it can access then other forms of [18:43] data. So the benefit for agents is that [18:46] by adding this knowledge graph to into [18:49] the pipeline here when paired with the [18:51] MCP architecture the schema of the [18:53] knowledge graph now provides context [18:56] when we break down a user's question or [18:58] a prompt then that you would then input [19:01] into a system you start to see very [19:03] clearly the direct and logical flows of [19:06] information. So if we take this even [19:08] further, which we're not going to get [19:10] into because of time, but in some [19:12] instances, and this will be my closing [19:14] point, because of the increased context [19:17] provided by the knowledge graph plus [19:20] agent MCP tool architecture, [19:24] you can then even in some instances get [19:28] rid of using vector search entirely. [19:30] Right? So for retrieval, retrieval [19:32] specifically due to being able to get [19:35] that accuracy increase and the domain [19:38] knowledge into your agentic workflows [19:40] without relying on semantic search. So [19:44] that was a lot. We blew through a lot [19:46] and again I just wanted to make sure [19:48] that we I went into a lot of detail. But [19:51] again, if you want to do research by [19:53] yourself, I'll leave this site up of the [19:56] core resources for learning more about [19:58] Graphra, which is [19:59] graphrag.com/appendices. [20:04] And then lastly, we also have a free [20:07] fully remote developer conference, which [20:09] happens on the 7th. Um, sorry, it [20:11] happens on November 6th. It happens [20:13] every year free and fully remote which [20:16] is going to have community member [20:17] sessions, Neo4j sessions and partner [20:19] sessions all about graph. This is [20:22] completely free one-day event. I see [20:24] people taking pictures. Come see me [20:26] after as well. And then lastly, if you [20:29] want to get more handson, right, this [20:31] was just a theoretical conversation, but [20:33] if you want hands-on keyboard, this is [20:35] an excellent place to get more [20:36] information about Graph Academy. All [20:38] right. So, Graph Academy is going to [20:40] teach you everything you want to know, [20:41] hands-on experience. And then lastly, if [20:44] you just want to have a chat with us, [20:46] I'll leave this up for a second. [20:47] Perfect. Perfect. If you just want to [20:49] have a chat with us, come chat with us [20:51] at booth 548 to learn more about graph. [20:55] All right, y'all. Thank you so so much [20:56] for coming and it's been a pleasure.