docs(rag): RAG 系列文章内容优化与格式规范化

Co-authored-by: Cursor <cursoragent@cursor.com>

Author: Snailclimb

docs/ai/rag/graphrag.md

@@ -18,23 +18,24 @@ Demo 很顺，领导问几个制度类问题也能回答。然后业务同事突
 
 向量 RAG 就开始力不从心了。
 
-它可能找到几个相似片段，却很难把”部门””风险””项目””供应商””时间线”这些对象串成一张关系网。更麻烦的是，答案往往来自多份文档的组合推理，而不是某一个 Chunk 里现成的一句话。
+它可能找到几个相似片段，却很难把“部门”“风险”“项目”“供应商”“时间线”这些对象串成一张关系网。更麻烦的是，答案往往来自多份文档的组合推理，而不是某一个 Chunk 里现成的一句话。
 
 这就是 GraphRAG 要解决的问题。
 
-今天这篇文章就来系统梳理 GraphRAG 的核心概念和工程实践，帮你搞清楚它和传统向量 RAG 的本质区别。本文接近 1.5w 字，建议收藏，通过本文你将搞懂：
+下面 Guide 会把 GraphRAG 的核心概念和工程实践拆开讲清楚，重点放在它和传统向量 RAG 到底差在哪、什么时候该上、什么时候别碰。
 
-1. **RAG 和 GraphRAG 分别是什么**：二者的本质区别是什么？
-2. **知识图谱核心概念**：实体、关系、社区发现分别解决什么问题？
-3. **全局检索 vs 局部检索**：两种查询方式各自的适用场景是什么？
-4. **GraphRAG 工程落地**：Neo4j GraphRAG 和其他实现路线分别适合什么场景？
-5. **不适用场景**：GraphRAG 真正难落地的地方在哪里？
+全文接近 1w 字，建议先收藏。主要覆盖：
+
+1. RAG 和 GraphRAG 的区别；
+2. 知识图谱里的实体关系和社区发现；
+3. 全局检索和局部检索各适合什么问题；
+4. GraphRAG 的工程落地路线和成本、以及它真正难落地的地方。
 
 ## 什么是 RAG？
 
 ![什么是 RAG？](https://oss.javaguide.cn/github/javaguide/ai/rag/rag-simplified-architecture-diagram.jpeg)
 
-RAG（Retrieval-Augmented Generation，检索增强生成）是一种把**信息检索（Information Retrieval，IR）**和**生成式大语言模型（LLM）**结合起来的框架。
+RAG（Retrieval-Augmented Generation，检索增强生成）就是把信息检索和生成式大语言模型结合起来的框架。
 
 它的核心思想是：在让 LLM 回答问题或生成文本之前，先从数据库、文档集合、企业知识库等外部知识源中检索相关上下文，再把“原始问题 + 检索上下文”一起交给 LLM。这样可以让模型回答得更准确、更及时，也更符合特定领域知识。
 
@@ -617,9 +618,7 @@ GraphRAG 是目前唯一系统性解决“关系推理 + 全局归纳”的方
 
 GraphRAG 的价值不在于听起来高级，而在于它补上了传统向量 RAG 的一个结构性短板：**向量检索擅长找相似片段，但不擅长理解片段之间的关系。**
 
-总结一下本文的核心：
-
-GraphRAG 把检索对象从文本 Chunk 扩展到了实体、关系、路径、社区摘要。它适合多跳推理、影响分析、归因分析和复杂业务问答，但代价是数据治理成本更高。Neo4j GraphRAG 适合已有业务关系的场景；LangChain/LlamaIndex 等适合现有技术栈集成。选择哪条路线，要看你的技术栈、图模型复杂度和运维能力。
+GraphRAG 把检索对象从文本 Chunk 扩展到了实体、关系、路径、社区摘要。它适合多跳推理、影响分析、归因分析和复杂业务问答，但代价是数据治理成本更高。Neo4j GraphRAG 适合已有业务关系的场景；LangChain/LlamaIndex 等适合现有技术栈集成。选哪条路线，看你的技术栈、图模型复杂度和运维能力。
 
 最后给一个非常务实的判断标准：如果你的 RAG 失败原因只是“没搜到那段话”，先优化检索；如果失败原因是“搜到了很多话，但系统不理解它们之间的关系”，再考虑 GraphRAG。