一个让 AI 说胡话的问题

先问你一个问题：

“特斯拉和比亚迪在2023年的研发投入差距是多少？各自的技术专利分布有什么趋势？”

这个问题看起来不难，但实则藏着陷阱——它要求 AI 同时处理两个主体的两个时间点的两类信息（研发投入 + 专利分布），还要做对比分析。

如果你去问一个用了基于向量检索的 RAG（dense retrieval RAG）的 AI 助手，它很可能会这样回答：

“比亚迪在2023年加大了研发投入，特斯拉也在持续投入，两家公司都有许多技术专利。”

废话文学大师。数据是对的，但没有真正回答你的问题。AI 提取到了相关文本，但搞不清楚这些信息之间的关系——它不知道”比亚迪”和”特斯拉”是两个独立实体，不知道”研发投入”和”专利”是两个不同维度的数据，更不知道”2023年”是时间条件而不是一个公司。

这就是向量检索的盲区：它很擅长找”像”的东西，但不擅长理解”关系”。

⚠️ 补充说明：在当前生产环境中，”纯向量检索”实则已经不多见了。更主流的落地形态是混合检索（hybrid search）——即关键词检索（BM25/TF-IDF）和向量类似性检索配合使用，取长补短。本文为便于理解，仍以向量检索为核心讨论对象，但读者需知道实际系统往往更复杂。

什么是基于向量检索的 RAG？

RAG（Retrieval-Augmented Generation，检索增强生成）是目前让大模型回答私有知识问题的主流架构。简单说就是：大模型在回答问题之前，先从你自己的文档里找到相关的内容，然后再基于这些内容生成答案。

基于向量检索的 RAG（dense retrieval RAG）是最常见的实现方式之一。它的原理是这样的：

1. 把文档切成一块一块（叫做”chunks”）
2. 用一个 embedding 模型把每个 chunk 变成一串数字（向量）
3. 把你问的问题也变成向量
4. 在向量数据库里找最”像”你问题的那些 chunks
5. 把这些 chunks 作为上下文喂给大模型，让它生成答案

你可以把它理解成一个”类似度匹配“的搜索引擎。它问的是：”哪些文本和我问的问题长得最像？”

这在许多场景下都很好用。但它有一个根本局限：文本类似不等于语义相关。

举一个经典的例子：用户问”如何降低汽车的能耗”，向量检索可能返回的是一篇关于”动物冬眠可以降低能量消耗”的生物学文章——由于”能耗”这个词在两篇文章里都出现了，语义上却完全不相关。

Graph-RAG 是什么？

Graph-RAG 的核心思想是：不仅检索文本，还检索实体之间的关系。

它引入了一个关键概念——知识图谱（Knowledge Graph）。

什么是知识图谱？用大白话来说，就是把信息变成一张”网”。每个节点（node）是一个实体，列如”特斯拉”、”2023年”、”研发投入”、”专利数量”。每条边（edge）是实体之间的关系，列如”特斯拉 – 在 – 2023年”、”特斯拉 – 研发投入 – X亿元”、”比亚迪 – 专利分布 – 电池技术”。

当用户问”特斯拉和比亚迪在2023年的研发投入差距”时，Graph-RAG 知道你在找两家公司和年份之间的关系，而不是在找包含”特斯拉”和”比亚迪”两个词的类似文本。

Graph-RAG 是怎么做事的？

一个完整的 Graph-RAG 工作流程，分为四个主要环节（下述为工程实践中的常见划分方式）：

环节一：文档解析。 把原始文档（列如财报、论文、合同）转成结构化文本，去除噪音。

环节二：信息抽取（Information Extraction）。 用大模型从文本里同时完成实体识别和关系建立——这是一个步骤，不是两个。列如”特斯拉在2023年的研发投入是X亿元”，AI 会提取出：（实体：特斯拉）、（实体：2023年）、（实体：X亿元），以及它们之间的关系：主体-时间-数值的关联链。值得注意的是：这一环节是整个 pipeline 中质量最不可控的——LLM 的抽取结果存在准确率上限，尤其在低质文档或专业术语密集的场景下，一般仍需人工校验或规则兜底。”自动构建”并不意味着零人工。

环节三：图谱构建与存储。 把所有实体和关系存入图数据库。

环节四：查询与生成。 当用户提问时，实际包含三个子步骤：

1. 问题解析：将自然语言问题转换为图查询语言（ Cypher / SPARQL / Gremlin 等）
2. 子图匹配：在图中找到满足查询条件的实体和关系路径
3. 路径筛选：对多条候选路径进行排序和筛选，组装为 LLM 的上下文

真实对比：一个多跳问题的两种回答

让我们用一个具体例子来看差异。

问题： “2019年到2023年之间，哪些 AI 论文引用了 Transformer 架构，并因此获得了更高的引用量？”

向量检索 RAG 的回答可能是：

“Transformer 是 2017 年提出的架构，被广泛应用于 NLP 领域。多篇论文引用了 Transformer 并取得了很好的效果。”

——听起来正确，但实则它没有回答”哪些论文”、”引用量变化趋势”这些具体信息。它只是找到了包含”Transformer”、”引用”等词的段落，然后拼凑了一下。

Graph-RAG 的回答可能是：

“从 2019 年到 2023 年，引用 Transformer 架构并在同期实现引用量显著增长的论文主要有三类：第一类是 BERT 及其衍生模型（如 RoBERTa、ALBERT），这些论文在 2020 年后引用量快速上升；第二类是大语言模型相关的论文（如 GPT 系列、T5），这些在 2022-2023 年出现引用高峰；第三类是扩散模型相关的论文（如 DDPM、DALL-E），这些在 2021 年后开始快速增长。”

——明显更具体，由于它理解了”论文”、”引用量”、”时间趋势”、”因果关系”这些实体之间的联系。

Graph-RAG 适合用在哪儿？

Graph-RAG 的核心优势是多跳推理——需要跨越多个实体、多个步骤才能找到答案的问题。以下场景特别适合：

金融行业：供应链分析。 列如问”A 公司的供应商 B 的下游客户里，有哪些在特定地区受影响？”——这个问题涉及三层实体关系，向量检索很难准确回答，Graph-RAG 可以沿着供应链图谱找到答案。

学术领域：文献综述。 列如问”近五年里，哪些方法解决了 Transformer 在长文本上的计算复杂度问题，效果如何？”——涉及论文、方法、效果、时间多个维度，Graph-RAG 可以构建论文之间的关系图谱。

法律行业：判例分析。 列如问”哪些判例引用了'个人信息保护'条款，且最终判决结果是原告胜诉？”——涉及法条、判例、判决结果三个实体及其关系。

医疗行业：疾病关系。 列如问”哪些基因突变与阿尔茨海默病的早期症状相关，并且已有相关的临床试验？”——涉及基因、疾病、症状、临床试验多个关系维度。

2026年的工具生态

LlamaIndex（开源）：提供了 KnowledgeGraphIndex，支持从文档自动构建知识图谱，并在查询时结合图遍历和向量检索。自动建图质量取决于文档结构化程度，非结构化复杂文档一般仍需人工介入。

Neo4j + LangChain（开源/商业）：Neo4j 是目前最成熟的图数据库，其查询语言是 Cypher。LangChain 提供了和 Neo4j 深度集成的 Graph-RAG 方案，适合有必定技术背景的团队。

NebulaGraph（开源）：国产图数据库，性能优秀，对中文文档支持较好，查询语言为 nGQL，社区活跃。

Microsoft GraphRAG（开源）：微软开源的 GraphRAG 框架，提供了端到端实现。对于结构化文件（如 CSV、JSON），可以较便捷地构建图谱；但对于非结构化复杂文档，仍需编写配置文件或自定义抽取规则，”无需写代码”的说法言过实则。

怎么选：向量检索还是 Graph-RAG？

两句话总结：

基于向量检索的 RAG（配合混合检索）适合：简单的实际查找、单跳问题、文档量不大且结构简单的场景。实现成本低，成熟工具多，是大多数场景下的默认选择。

Graph-RAG 适合：复杂的多跳问题、需要关系推理、结构化程度高的专业领域。如果你的文档涉及大量实体及其关系（公司、年份、指标、人名），且用户常常问”谁在什么时间做了什么事”这类问题，Graph-RAG 值得投入。

一个务实的提议：不要一开始就追求 Graph-RAG。 可以先用向量检索（或混合检索）跑起来，如果发现复杂问题回答质量不行，再思考引入知识图谱。

写在最后

AI 检索技术正在从”找最像的文本”进化到”理解语义和关系”。Graph-RAG 不是向量检索的替代者，而是补充——它们解决的是不同层次的问题。

对于大多数普通用户来说，向量检索（配合混合检索）已经够用了。但如果你在金融、法律、医疗、学术这些需要深度分析的领域工作，Graph-RAG 可能是下一个值得关注的升级方向。

参考来源

• ArXiv: Retrieval-Augmented Generation: A Comprehensive Survey（https://arxiv.org/abs/2506.00054）
• RadarAI: 2026年 RAG 技术最新进展与落地实践（https://radarai.top）
• Microsoft GraphRAG 开源项目（https://github.com/microsoft/graphrag）
• Neo4j 官方文档（https://neo4j.com/docs/）