引言：向量 RAG 的"天花板"在哪里

检索增强生成（RAG）已成为企业部署大模型的主流架构。传统向量 RAG 的逻辑清晰：将文档切块、向量化、存入向量数据库，查询时以语义相似度召回最相关的文本片段。

这套方法在单点事实查询场景表现优异——问"如何重置密码"，向量检索总能召回正确文档。但当企业应用深入到需要理解实体之间关系的场景时，向量 RAG 的天花板便显现出来。

典型场景：用户问"哪些供应商的工厂位于地震带上？这些供应商的上游原料采购有没有受到影响？"

这个问题涉及三层关系：​供应商 → 工厂地理位置 → 地震带划分​，以及​供应商 → 上游采购关系 → 原料来源​。向量 RAG 能做的，是找到与这段文字语义最相似的文档片段——但它​不理解"位于""上游""影响"这些关系语义​，更无法沿着关系链路进行推理。

GraphRAG（基于知识图谱的 RAG）正是为解决这一挑战而生。 ArangoDB 作为原生多模型数据库，凭借其图、文档、向量统一存储的架构，成为 GraphRAG 实现的主流选择。

一、GraphRAG vs 向量 RAG：本质差异在哪里

传统向量 RAG 处理的是"哪些文档与问题相关"，而 GraphRAG 处理的是"哪些实体和关系与问题相关"。这一字之差，带来的是能力边界的本质跃升：

向量 RAG 的局限：

• 只能捕捉"语义相似性"，无法理解实体间的结构关系
• 跨文档的因果链、层级链在切块后断裂
• 回答依赖文档的质量，文档未覆盖的关系无法被发现
• 存在"幻觉"风险：大模型可能将不相关片段拼凑成看似合理但错误的答案

GraphRAG 的核心优势：

• 以知识图谱显式建模实体与关系，回答"为什么"而非仅"是什么"
• 支持多跳推理：沿着关系链发现间接关联
• 图结构天然抗幻觉：答案来自可追溯的关系路径，而非文本片段的统计相似
• 全局问题能力：利用社群检测技术，回答"这批文档的核心主题是什么"等宏观问题

二、Arango GraphRAG 完整实战路径

第一步：知识图谱构建——从非结构化文本到结构化知识

GraphRAG 的第一步，是将企业文档转化为知识图谱。这个过程包含四个关键环节：

1. 文本预处理与分块将长文档切分为包含足够上下文的文本块（通常建议 1200 tokens 左右）。分块策略直接影响下游实体抽取质量——块太小会切断跨句关系，块太大则引入过多噪声。

2. 实体与关系抽取这是 GraphRAG 的核心创新。利用 LLM 的语言理解能力，从每个文本块中自动识别：

• ​实体​（Entity）：人名、组织、地点、产品、概念、事件等
• ​关系​（Relation）：实体之间的语义连接，如"位于""供应""隶属于"等

Arango 的图数据模型以 JSON 文档形式存储节点（实体）和边（关系），属性灵活可扩展，非常适合承接这类 LLM 抽取结果。

3. 实体消解与图合并不同文本块中提到的同一实体可能名称各异（如"ArangoDB"和"Arango"）。通过 LLM 驱动的实体消解，将重复实体合并，构建统一的全域知识图谱。

4. 图嵌入与向量索引为图中的节点和边生成向量嵌入，使后续检索可同时利用图结构（关系语义）和向量语义（文本相似度）两种索引。

Arango 原生支持图数据存储、向量搜索、全文搜索三种能力的统一管理，天然适合 GraphRAG 的数据存储层。

第二步：存储——用图结构管理实体关系

Arango 存储 GraphRAG 知识图谱的核心数据结构：

• ​**节点（Nodes）**​：代表实体，以 JSON 文档形式存储，支持丰富的属性字段
• ​**边（Edges）**​：代表关系，有明确的类型（如"PURCHASES_FROM"、"LOCATED_IN"），支持方向性
• ​**属性（Attributes）**​：节点和边均可附加描述性属性

例如，上游采购关系在 Arango 中可建模为：

供应商A --[PURCHASES_FROM {quantity: 5000, material: "稀土"}]--> 原料供应商B

这种结构化建模使系统能够​沿着关系进行多跳遍历​，回答"供应商 A 的原料从哪里来，这些原料供应商又向谁采购"这类递归关系问题——这是向量 RAG 完全无法做到的。

第三步：检索——图遍历驱动的上下文获取

GraphRAG 的检索分为两个阶段：

1. 向量检索初筛将用户问题转化为向量，在实体嵌入空间中检索最相关的节点，快速缩小候选范围。

2. 图遍历扩展从召回的种子实体出发，沿着关系边进行多跳遍历，扩展相关上下文。

Arango 支持单次 AQL 查询完成以上两个步骤：

LET questionEmbedding = EMBEDDING(@userQuestion)
LET seedEntities = (
  FOR entity IN entities
    SORT ABS(entity.vector <-> questionEmbedding)
    LIMIT 5
    RETURN entity
)
FOR entity IN seedEntities
  FOR v, e IN 2 OUTBOUND entity GRAPH "supplyChainGraph"
    FILTER e.type IN ["PURCHASES_FROM", "LOCATED_IN"]
    RETURN { entity: v, relation: e }

这段 AQL 语句首先通过向量相似度找到最相关的 5 个种子实体，再沿"采购关系"和"位于关系"向外扩展两跳，将供应商的上游关系和地理位置信息一并召回。

第四步：生成——将图上下文注入大模型

将图遍历得到的实体和关系以结构化方式组装为 prompt 上下文，注入大模型进行生成。由于上下文来自可追溯的知识图谱关系路径，大模型的回答具有天然的可解释性——每一句话都能追溯到对应的实体节点和关系边。

Arango 的多模型特性在这一步的优势尤为突出：

• ​文档数据​：通过 ArangoSearch 的全文搜索，对实体描述进行语义扩展
• ​地理数据​：利用地理空间索引，基于位置关系筛选实体
• ​向量数据​：结合向量相似度搜索，提高实体召回的准确性

三种检索能力在 AQL 中无缝融合，单次查询完成跨模型数据聚合，无需在多个数据库间切换。

三、GraphRAG 的典型应用场景

场景一：企业知识管理

员工问："公司对供应商的数据安全有什么要求，哪些供应商通过了相关认证？"

向量 RAG 可能只能找到分散在多个文档中的相关段落。GraphRAG 则能构建"公司 → 供应商管理政策 → 供应商认证状态 → 数据安全要求"的完整关系链，给出结构化的答案，并附带可追溯的决策依据。

场景二：金融风控与欺诈检测

风控人员问："这批交易是否存在关联欺诈风险？"

GraphRAG 通过知识图谱串联账户、交易、设备、IP 地址等多维实体，识别出向量 RAG 无法发现的"隐匿关联"——例如同一设备登录多个账户、多个账户在同一时间向同一受益人转账等异常模式，触发精准的风控告警。

场景三：客户支持与智能问答

客服 AI 问："为什么我上个月的订单还没发货？"

GraphRAG 不仅能查到订单状态文档，还能关联到该订单涉及的仓库库存数据、物流合作方状态、节假日调度安排等背景信息，给出真正有价值的答案，而非简单地回复"请稍后"。

场景四：视频分析与监控智能

在 NVIDIA VSS（Video Search and Summarization）项目中，Arango GraphRAG 被用于视频分析场景：视频内容经 VLMs（视觉语言模型）解析后，转化为知识图谱存储，支持跨摄像头追踪、特定事件定位、异常行为推理等复杂查询。

四、为什么选择 Arango 作为 GraphRAG 的数据层

对比传统的"向量数据库 + 图数据库 + 文档数据库"三库方案，Arango 的单一多模型架构具有显著优势：

对比维度	三库方案（Neo4j + Milvus + MongoDB）	Arango 单库方案
运维复杂度	高（三个系统各自运维）	低（统一数据层）
跨模型查询	需要应用层多次查询拼装	AQL 原生跨模型联合查询
数据一致性	跨库同步延迟与一致性问题	单一数据源，无同步延迟
图 + 向量融合	需要额外的数据同步机制	原生支持，无需额外集成
许可证风险	各库许可风险叠加	Apache License，无供应商锁定
总体拥有成本	三套许可 + 三套运维	一套方案

特别值得强调的是成本优势： 三库方案中，向量嵌入的生成、存储和检索本身就需要消耗大量计算资源。Arango 的图遍历机制在大多数场景下不需要生成额外的向量嵌入，计算成本显著低于向量 RAG 方案。

结语

大模型要真正"理解"企业业务，光靠向量相似度检索是不够的——它需要理解数据之间的​关系​，而非仅仅知道数据本身的​内容​。

GraphRAG 通过知识图谱将企业数据中隐藏的关系结构显式化，让大模型的推理有了"依据"可循，也让回答从"听起来合理"进化为"真正可靠"。

Arango 凭借其图、文档、向量统一存储的多模型架构，以及强大的 AQL 查询能力，为 GraphRAG 提供了天然的数据基础设施——在同一个数据库中完成知识图谱构建、存储、检索与生成，无需引入额外的向量数据库或图数据库，大幅简化架构，降低总拥有成本。

当企业需要构建真正理解业务上下文的 AI 应用时，Arango GraphRAG 是一条值得认真评估的技术路径。