从RAG到GraphRAG：知识图谱如何解决大模型复杂推理难题

1. 项目概述：从“检索增强”到“图增强”的演进

最近和几个做AI应用落地的朋友聊天，大家不约而同地都在讨论同一个话题：RAG（检索增强生成）的瓶颈到底在哪？我们辛辛苦苦搭建的向量数据库，为什么在面对复杂的、关联性强的业务问题时，回答还是显得零散、缺乏深度，甚至有时会“一本正经地胡说八道”？这让我想起了去年我们团队在做一个智能客服知识库升级时遇到的困境。当时我们用了最主流的向量检索方案，把产品手册、FAQ、历史工单都切分、向量化存了进去。单点问答效果不错，但一旦用户问“A产品升级到B版本后，之前与C服务集成的配置项D为什么失效了？”，系统就懵了。它可能会分别检索出A产品、B版本、C服务、D配置的片段，但无法理解它们之间“升级导致”、“集成依赖”、“配置项变更”这一连串的深层关系，生成的回答自然就缺乏逻辑链条。

这正是传统RAG的核心痛点：它擅长处理“点状”知识，却难以驾驭“网状”知识。而“GraphRAG”这个概念，正是在这种背景下被提出并迅速成为热点的。它不是一个全新的技术，而是一种架构思想的进化。简单来说，GraphRAG = RAG + 知识图谱。它的核心思想是，在传统的“文档切片->向量化->检索”流水线之前或之中，引入一个“知识抽取与图谱构建”的环节。系统不再仅仅将文档视为一堆孤立的文本块，而是试图从中提取实体（如产品、版本、服务、配置项）以及实体之间的关系（如“依赖”、“导致”、“属于”），构建成一个结构化的知识图谱。当用户提问时，系统不仅进行语义相似度检索，还会在图谱上进行推理和路径查找，从而能够回答涉及多跳推理、关系归纳和因果分析的复杂问题。

所以，今天我想结合我们踩过的坑和后续的探索，和大家深入聊聊RAG与GraphRAG。这不仅仅是两个技术名词，更代表了构建更智能、更可靠大模型应用的一种工程范式演进。无论你是正在考虑引入RAG来解决“大模型幻觉”问题的算法工程师，还是苦恼于如何让知识库真正“智能”起来的业务开发者，理解这套从“检索”到“检索+推理”的升级路径，都至关重要。

2. RAG核心架构与工程化深潜

在谈论GraphRAG之前，我们必须先夯实对经典RAG的理解。很多人把RAG简单理解为“向量数据库+大模型”，这其实大大低估了其工程复杂度。一个健壮、高效的RAG系统，是一个精密的流水线，每个环节都有大量的设计抉择和陷阱。

2.1 知识切片：不只是“切”那么简单

知识切片是RAG的基石，也是最容易埋下隐患的第一步。目标是将长文档（如PDF、Word、网页）转化为适合检索的片段（chunks）。常见的策略有固定长度重叠切片、按段落/标题切分、按语义切分等。

固定长度重叠切片是最简单粗暴的方法，比如每500个字符切一段，重叠50个字符。它的优点是实现简单、速度快。但缺点极其明显：很可能把一个完整的句子或一个关键表格从中间切断，导致检索到的片段语义不完整。我们早期就吃过这个亏，一份API接口文档被切得支离破碎，检索结果里充满了半截的参数说明，导致大模型生成的代码漏洞百出。

按段落或标题切分稍微好一些，它尊重了文档的原始结构。但对于结构不规整的文档（如一些扫描后OCR的PDF），效果也不稳定。

语义切分是更高级的方法，它利用句子嵌入模型计算句子间的相似度，在语义发生较大转变的地方进行切割。这能更好地保证每个片段的主题一致性。常用的工具有LangChain的RecursiveCharacterTextSplitter（结合分隔符和长度）或专门基于语义的拆分器。但这里有个关键参数：相似度阈值。阈值设得太高，切出来的片段会非常细碎；阈值设得太低，又可能把不同主题的内容混在一起。这个阈值没有银弹，必须结合你的文档类型（技术文档、法律合同、会议纪要）通过实验来确定。

实操心得：不要追求单一的切片策略。我们现在的做法是“分层切片”。对于结构化强的技术文档，优先按章节标题切；对于非结构化的报告、文章，采用语义切分；同时，对于代码块、表格这类特殊内容，会单独识别并作为整体保留，绝不切分。这需要写一些规则和启发式方法，但换来的是检索质量的显著提升。

2.2 向量化与索引：模型与量化权衡

切片之后，需要将这些文本转化为向量（嵌入），并存入向量数据库。这里第一个关键选择是：嵌入模型。

很多人直接使用OpenAI的text-embedding-ada-002或其后续版本，它确实省心且效果不错。但在企业级、对数据隐私和成本敏感的场景下，开源模型是更主流的选择。例如BGE系列、text2vec、M3E等，都是中文社区经过验证的优秀模型。选择时，不能只看排行榜的分数，一定要用你自己的业务数据做测试。我们曾发现，某个在通用榜单上名列前茅的模型，在处理我们特定行业的专业术语时，表现反而不如一个更轻量级的模型。

向量维度也是一个需要考虑的点。更高的维度（如1024维）通常能携带更多信息，但也会增加存储和计算开销。对于绝大多数应用，768维的模型已经足够。更重要的是向量归一化。许多向量数据库（如Milvus, Pinecone）在进行相似度计算（通常是余弦相似度）时，要求向量是归一化的（模长为1）。如果你的嵌入模型输出没有自动归一化，务必在存入数据库前手动处理，否则检索结果会完全错误。

向量数据库的选择同样重要。Chroma轻量易用，适合原型验证；Milvus、Weaviate功能强大，适合大规模生产部署；PGVector则能与现有PostgreSQL生态无缝集成。我们的选择标准是：一看团队技术栈，二看是否需要混合检索（同时支持向量和标量过滤，如按时间、标签查询），三看运维复杂度。对于大多数中小型项目，从PGVector开始是个稳妥的选择，它“够用”，且避免了维护一个新数据库的负担。

2.3 检索、召回与重排序：从“准”到“精”的漏斗

这是RAG流水线的核心环节，通常是一个多级漏斗。

第一级：召回。根据用户查询的向量，从向量数据库中找出Top-K个最相似的片段。这里的K值是个艺术，通常设置在5到20之间。设得太小，可能漏掉关键信息；设得太大，会给后续的重排序和模型上下文带来压力，增加成本和延迟。

然而，单纯基于向量的语义检索存在“词汇鸿沟”问题。如果用户查询用的是口语化表述，而文档用的是专业术语，即使语义相近，向量相似度也可能不高。因此，混合检索成为必选项。即在向量检索的同时，并行一个基于关键词（如BM25）的检索。关键词检索能很好地捕捉到精确的术语匹配。将两者的结果集取并集或按一定规则融合，能显著提高召回率。

第二级：重排序。召回得到的Top-K个片段，其相似度分数（如余弦相似度）只能衡量“全局语义”上的接近程度，无法精确判断哪一个片段“最相关”或“最能回答问题”。这时就需要一个更精细的重排序模型。它是一个专门的、通常比嵌入模型更小的交叉编码器模型（如bge-reranker），它同时接收查询和候选文档，输出一个更精细的相关性分数。

重排序的成本比向量检索高，所以通常只对召回阶段得到的10-20个候选片段进行。经过重排序后，选取Top-N（N通常为3-5）个片段，作为最终提供给大模型的上下文。

踩坑记录：我们曾经忽略了重排序，直接拿向量检索的Top-5结果喂给大模型，结果发现模型经常被一个“全局语义相似但并未回答问题”的片段带偏。引入一个轻量级的重排序模型后，答案的准确率立刻提升了15%以上。这个环节的投入产出比非常高。

2.4 生成与提示工程：给模型清晰的指令

最后，将重排序筛选出的N个上下文片段，连同用户的问题，一起构造成提示词（Prompt），提交给大模型生成最终答案。这里的提示工程同样关键。

一个糟糕的Prompt可能是：“这是相关文档：{context}。问题：{question}。请回答。”这给了模型太大的自由发挥空间。

一个好的Prompt应该：

1. 明确角色：“你是一个专业的IT技术支持专家。”
2. 规定任务：“请严格根据提供的参考资料来回答问题。”
3. 给出格式：“如果资料中有明确答案，请直接引用。如果资料不足，请明确说明‘根据现有资料无法完全确定’，并给出基于已知信息的推测。”
4. 处理不确定性：“禁止编造参考资料中不存在的信息。”

我们甚至会在Prompt中加入“思维链”的引导，例如：“请先一步步分析参考资料中的信息，再综合给出结论。”这能鼓励模型进行更逻辑化的推理，而不仅仅是复述。

3. GraphRAG：引入知识图谱的结构化推理

当你的知识库需要回答“为什么”、“如何关联”、“接下来会怎样”这类问题时，传统RAG的局限性就暴露无遗。GraphRAG的核心突破，在于引入了“关系”这一维度。

3.1 GraphRAG的核心原理：从文本到图谱

GraphRAG的流程可以概括为两个阶段：离线构建和在线查询。

离线构建阶段：

1. 命名实体识别与关系抽取：利用NLP模型（如SPACY、斯坦福NLP工具包，或微调后的BERT类模型）从原始文档中提取实体（人、组织、地点、产品、事件等）和关系（位于、属于、导致、合作等）。这步是关键，抽取质量直接决定图谱价值。
2. 知识图谱构建：将抽取出的实体和关系，以“节点-边-属性”的形式存储在图数据库（如Neo4j, NebulaGraph, Amazon Neptune）中。每个节点代表一个实体，带有属性（如名称、类型、描述）；每条边代表一种关系，也可以有属性（如强度、时间）。
3. 文本片段与图谱节点关联：原始的文档切片并不会被丢弃。我们需要建立“文本片段”与“图谱节点”之间的链接。例如，某个片段提到了“公司A发布了产品B”，那么这个片段就应该与图谱中的“公司A”节点和“产品B”节点关联起来。

在线查询阶段：

1. 查询理解与实体链接：当用户提问时，系统首先进行查询理解，识别出查询中的关键实体。例如，对于问题“A公司的主要竞争对手有哪些？”，识别出实体“A公司”。
2. 图谱检索与路径发现：系统以识别出的实体为起点，在图谱中进行遍历。寻找与“A公司”有“竞争”关系的其他公司节点。图谱查询语言（如Cypher for Neo4j）可以非常高效地完成这种多跳查询。它可能发现“A公司”与“B公司”在“智能手机市场”存在竞争，与“C公司”在“云服务市场”存在竞争。
3. 相关文本片段召回：根据图谱检索到的相关节点（如B公司、C公司），通过之前建立的关联，召回与这些节点相关的所有文本片段。这些片段可能来自不同的原始文档，但都围绕着“竞争”这个主题。
4. 上下文增强与生成：将图谱检索到的结构化信息（如“A竞争B，领域：智能手机”）和召回的相关文本片段，一起作为增强的上下文，输入给大模型。Prompt可以设计为：“根据以下关于公司关系的图谱信息及相关文档片段，回答问题：...”。模型此时不仅看到了零散的文本，还看到了清晰的关系网络，因此能生成更具洞察力、逻辑更严谨的回答，比如：“A公司的主要竞争对手包括B公司和C公司。其中，在智能手机领域与B公司竞争激烈，相关专利纠纷见文档X；在云服务领域则与C公司形成直接竞争，市场分析见文档Y。”

3.2 对比传统RAG：优势与挑战

GraphRAG的优势显而易见：

• 深度推理能力：能回答“如果A发生，对B和C会有什么影响？”这类复杂问题。
• 知识融合：能将分散在不同文档中的关联信息自动串联起来。
• 可解释性增强：检索结果不仅是一堆文本，还包括了清晰的推理路径，便于调试和验证。

但其挑战也同样巨大：

1. 构建成本高昂：高质量的实体关系抽取本身就是一个难题，特别是在专业领域。需要标注数据、微调模型，且流程复杂。
2. 知识更新滞后：当有新文档加入时，不仅要做切片向量化，还需要重新进行实体关系抽取，并更新图谱，这比单纯向向量库添加文档要慢得多。
3. 冷启动问题：在知识图谱构建初期，数据稀疏，其优势无法体现。
4. 系统复杂度：需要同时维护向量数据库和图数据库两套系统，架构和运维复杂度翻倍。

3.3 实践路径：从RAG到GraphRAG的渐进式演进

对于大多数团队，我建议采用渐进式策略，而不是一开始就全面转向GraphRAG。

阶段一：夯实基础RAG。先把你手头的传统RAG流水线做到极致。优化切片策略、测试不同的嵌入模型、引入混合检索和重排序、精心设计Prompt。确保在“点状”事实问答上达到90分。这是你的地基。

阶段二：探索“轻量级”图谱。不必一开始就追求全自动、全覆盖的知识图谱。可以从核心实体入手。例如，在你的业务领域，手动定义最重要的10类实体（如产品、版本、客户、故障码）和5种核心关系（如依赖、导致、属于、兼容）。然后，可以：

• 基于规则抽取：编写一些正则表达式或利用现有系统里的结构化数据（如CRM里的客户-产品关系）来初始化图谱。
• 人机结合：利用大模型的能力，通过Prompt让其从文本中提取特定类型的实体和关系，作为辅助。
• “图谱增强检索”：在检索时，先识别查询中的实体，然后去图数据库中查找该实体的直接关联实体（一度关系），将这些关联实体的名称作为关键词，补充到用户的原始查询中，再进行向量检索。这相当于用图谱来“扩展”查询，是一个低成本获得部分图谱收益的方法。

阶段三：局部试点GraphRAG。选择一个业务价值高、且传统RAG效果不佳的特定场景进行试点。例如，“故障根因分析”或“竞品对比分析”。针对这个场景，投入资源构建高质量、小范围的知识图谱。验证其价值，并积累构建和运维的经验。

阶段四：全面融合与自动化。当在试点场景中验证了价值，并且积累了足够的数据和工具链后，再考虑将图谱构建流程自动化、规模化，并与现有的RAG系统深度集成，形成完整的GraphRAG解决方案。

4. 进阶话题：Agentic RAG与评测体系

随着RAG/GraphRAG系统的复杂化，两个问题变得突出：如何让系统更自主地处理复杂任务？如何科学地评估它的好坏？

4.1 Agentic RAG：让RAG拥有“大脑”

传统的RAG是一个被动的“检索-生成”管道。而Agentic RAG（智能体化RAG）则为其赋予了“智能体”的能力，使其能够主动规划、工具调用、迭代优化。

其核心思想是引入一个“规划器”或“路由”模块。当用户提出一个复杂问题时（例如，“帮我对比一下MySQL 8.0和PostgreSQL 15在高并发场景下的优劣，并给出选型建议”），这个模块不会直接去检索，而是先进行任务分解：

1. 分解出子问题：MySQL 8.0高并发特性、PostgreSQL 15高并发特性、两者对比维度、选型考虑因素。
2. 为每个子问题规划检索策略：可能对“特性”类问题用向量检索，对“对比维度”类问题去图谱中查找“对比”关系，对“选型”类问题需要调用外部工具搜索最新的行业报告。
3. 执行多轮检索与合成：依次或并行解决子问题，并将中间结果进行综合。
4. 自我验证与迭代：生成初步答案后，可以自我提问“我的回答是否覆盖了所有子问题？数据是否最新？”，必要时发起新一轮检索。

这相当于在RAG流水线前端加了一个“大脑”。实现上，可以利用LangChain的Agent框架、AutoGen等多智能体框架，或者基于大模型本身强大的规划能力（通过精心设计的Prompt）来实现。Agentic RAG是解决复杂、多步骤查询的终极方向，但它也带来了更高的复杂性和不可预测性。

4.2 RAG评测系统：告别“感觉”，拥抱“数据”

“我感觉这个回答还行”是RAG项目早期最大的敌人。必须建立量化的评测体系。一个完整的RAG评测通常包括以下几个维度：

1. 检索质量评测：

   • 召回率：对于一个问题，系统检索出的片段中，包含正确答案的比例有多高？
   • 精确率：系统检索出的Top-K个片段中，真正相关的有多少？
   • MRR：正确答案在检索结果列表中的排名倒数平均值，衡量系统是否能把最相关的放在前面。

2. 生成质量评测：

   • 事实一致性：生成的答案与提供的上下文是否一致？是否引入了“幻觉”？可以用基于NLI的模型自动判断。
   • 答案相关性：生成的答案是否直接回答了问题？可以用模型打分。
   • 信息完整性：是否涵盖了所有必要的关键信息？
   • 人工评测：最终仍需人工从“准确性”、“有用性”、“流畅性”等维度进行打分，这是黄金标准。

3. 端到端评测：

   • 构建一个包含“问题-标准答案-参考上下文”的测试集。
   • 使用RAGAS、TruLens等专门框架进行自动化评测。这些框架可以基于大模型本身来评估答案的忠实度、相关性等。

避坑指南：构建测试集时，一定要覆盖多种问题类型：简单事实型、多跳推理型、总结归纳型、开放比较型。并且，测试集要随着知识库的更新而更新。我们曾经因为只测试简单问题而沾沾自喜，上线后面对复杂查询立刻收到大量投诉。

5. 实战：构建一个简易的GraphRAG原型

理论说了这么多，我们来动手搭建一个最简单的GraphRAG原型，感受一下从文本到图谱再到答案的完整流程。我们将使用Python、LangChain（简化流程）、Neo4j（图数据库）和OpenAI API（或开源LLM）来实现。

5.1 环境准备与数据加载

首先，安装必要的库，并准备一份示例数据。假设我们有一份关于“科技公司”的简短文本。

pip install langchain langchain-community langchain-openai neo4j wikipedia

# 示例文档 documents = [ "苹果公司由史蒂夫·乔布斯、史蒂夫·沃兹尼亚克和罗纳德·韦恩于1976年创立。它以其iPhone、iPad和Mac电脑而闻名。", "微软由比尔·盖茨和保罗·艾伦于1975年创立。它是Windows操作系统和Office办公套件的开发商。", "苹果公司在2007年发布了第一代iPhone，这彻底改变了智能手机行业。", "微软的Windows操作系统与苹果的MacOS是竞争关系。", "蒂姆·库克在2011年接替史蒂夫·乔布斯成为苹果公司的首席执行官。" ]

5.2 知识抽取与图谱构建

这里我们简化流程，使用大模型（LLM）作为知识抽取器。在生产环境中，你会使用更专门的NER和RE模型。

from langchain.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI import json # 初始化LLM llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0) # 定义知识抽取的Prompt extraction_prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个精准的信息抽取助手。请从给定的文本中提取实体以及实体之间的关系。只输出JSON格式，不要有任何其他解释。"), ("human", "文本：{text}\n\n请提取其中的实体（人物、组织、产品等）和关系（如创立、发布、竞争、接替等）。输出格式：{{\"entities\": [{{\"name\": \"实体名\", \"type\": \"实体类型\"}}], \"relations\": [{{\"head\": \"头实体\", \"relation\": \"关系\", \"tail\": \"尾实体\"}}]}}") ]) def extract_knowledge(text): chain = extraction_prompt | llm result = chain.invoke({"text": text}) try: return json.loads(result.content) except: print(f"解析失败: {result.content}") return {"entities": [], "relations": []} # 连接Neo4j图数据库 from neo4j import GraphDatabase uri = "bolt://localhost:7687" # 你的Neo4j地址 username = "neo4j" password = "your_password" # 你的密码 driver = GraphDatabase.driver(uri, auth=(username, password)) def create_graph_from_data(data_list): with driver.session() as session: # 清空现有数据（仅用于演示） session.run("MATCH (n) DETACH DELETE n") for data in data_list: # 创建实体节点 for entity in data.get("entities", []): session.run( "MERGE (e:Entity {name: $name}) SET e.type = $type", name=entity["name"], type=entity["type"] ) # 创建关系边 for rel in data.get("relations", []): session.run( "MERGE (h:Entity {name: $head}) MERGE (t:Entity {name: $tail}) MERGE (h)-[r:RELATION {type: $rel_type}]->(t)", head=rel["head"], tail=rel["tail"], rel_type=rel["relation"] ) print("知识图谱构建完成！") # 处理所有文档，抽取知识并建图 all_knowledge = [] for doc in documents: knowledge = extract_knowledge(doc) all_knowledge.append(knowledge) print(f"从文档中抽取: {knowledge}") create_graph_from_data(all_knowledge) driver.close()

这段代码会从每段文本中抽取出实体和关系，并在Neo4j中构建一个简单的图谱。你可以在Neo4j Browser中看到类似“苹果公司-创立->史蒂夫·乔布斯”、“微软-竞争->苹果公司”这样的节点和关系。

5.3 关联文本与图谱查询

接下来，我们需要把原始文本片段存储起来，并建立它们与图谱中实体的关联。为了简化，我们可以使用一个字典在内存中模拟，生产环境会用更正式的存储。

# 存储文本片段及其关联的实体 text_chunks = [] for idx, doc in enumerate(documents): # 为每个片段生成一个ID并存储 chunk_id = f"chunk_{idx}" text_chunks.append({"id": chunk_id, "text": doc, "entities": []}) # 假设我们简单地将该片段关联到本段抽取出的所有实体 knowledge = all_knowledge[idx] for entity in knowledge.get("entities", []): text_chunks[idx]["entities"].append(entity["name"]) # 现在，当用户查询时，我们先进行图谱检索 def retrieve_via_graph(query): # 1. 从查询中提取关键实体（这里简化，实际应用需要用NER模型） # 假设我们通过一个简单的LLM调用或关键词匹配来获取查询中的实体 # 例如，查询“苹果公司的创始人是谁？”，我们提取出“苹果公司” query_entity = "苹果公司" # 简化处理 # 2. 在图谱中查询与该实体直接相关（一度关系）的其他实体 related_entities = [] with driver.session() as session: result = session.run( "MATCH (e:Entity {name: $name})-[r]->(other) RETURN other.name AS related_entity, r.type AS relation", name=query_entity ) for record in result: related_entities.append(record["related_entity"]) print(f"查询实体'{query_entity}'的相关实体: {related_entities}") # 3. 根据查询实体和相关实体，召回关联的文本片段 relevant_chunks = [] target_entities = [query_entity] + related_entities for chunk in text_chunks: # 如果片段的关联实体列表与目标实体有交集，则认为相关 if set(chunk["entities"]) & set(target_entities): relevant_chunks.append(chunk["text"]) return relevant_chunks # 测试查询 context_chunks = retrieve_via_graph("苹果公司的创始人是谁？") print("通过图谱检索到的相关文本片段：") for ctx in context_chunks: print(f"- {ctx[:50]}...")

5.4 增强生成

最后，将图谱检索到的上下文（已经包含了关系信息）和原始查询一起，发送给大模型生成答案。

from langchain.schema import HumanMessage, SystemMessage def generate_answer_with_graphrag(query): # 1. 图谱检索上下文 graph_contexts = retrieve_via_graph(query) # 2. 构建增强的Prompt system_prompt = """你是一个知识渊博的助手。请根据以下提供的上下文信息，回答问题。上下文信息可能包含直接相关的事实和通过知识图谱关联的间接事实。请综合这些信息，给出准确、完整的回答。如果上下文信息不足，请说明。""" user_prompt = f""" 上下文信息： {chr(10).join(graph_contexts)} 问题：{query} 请根据上述上下文回答。 """ # 3. 调用LLM生成 messages = [ SystemMessage(content=system_prompt), HumanMessage(content=user_prompt) ] response = llm.invoke(messages) return response.content # 测试 answer = generate_answer_with_graphrag("苹果公司的创始人是谁？") print("GraphRAG生成的答案：") print(answer) # 预期答案应包含：史蒂夫·乔布斯、史蒂夫·沃兹尼亚克和罗纳德·韦恩。 # 测试一个需要推理的问题 answer2 = generate_answer_with_graphrag("谁接替了苹果公司创始人的职位？") print("\nGraphRAG生成的答案（推理问题）：") print(answer2) # 预期答案应能通过“史蒂夫·乔布斯”->“接替”->“蒂姆·库克”这条图谱路径找到答案。

这个原型非常简陋，但它清晰地展示了GraphRAG的工作流：文本->抽取->图谱->查询->关联文本->增强生成。在生产中，每一个环节都需要强化：使用更鲁棒的抽取模型、设计更复杂的图谱模式、实现更精准的查询理解和混合检索等。

6. 常见问题与避坑指南

在实施RAG和GraphRAG项目的过程中，我总结了一些最常见的“坑”和应对策略。

问题一：检索结果看似相关，但答案还是不准。

• 排查：这往往是“切片”和“重排序”环节的问题。检查你的切片是否破坏了语义单元（如表格、代码块、完整步骤）。检查重排序模型是否适合你的领域（用业务数据微调一个小的重排序模型往往效果显著）。
• 技巧：在Prompt中明确指令“请只根据以下上下文中的信息回答”，并让模型在生成答案时引用上下文片段的编号。这不仅能减少幻觉，还能帮你反向追踪是哪个片段提供了错误信息。

问题二：知识更新后，系统表现变差。

• 排查：对于RAG，检查新文档的切片和向量化流程是否与旧文档一致。对于GraphRAG，问题更复杂，新实体的加入可能影响图谱的整体结构。
• 策略：建立版本化的知识库。可以定期（如每周）全量重建索引和图谱，而不是增量更新。虽然成本高，但能保证一致性。对于实时性要求高的场景，可以考虑将最新数据放在一个单独的、更简单的检索模块中。

问题三：如何处理超长文档或复杂逻辑文档？

• 方案：采用“分层索引”或“摘要索引”。先为整个文档生成一个摘要并向量化，在召回时，先召回最相关的文档摘要，再根据摘要定位到该文档内部的详细片段进行精读。这类似于传统搜索引擎的“标题+摘要”模式。

问题四：GraphRAG的实体关系抽取准确率低怎么办？

• 策略：不要追求全自动。从“人机结合”开始。可以先利用大模型进行批量、粗粒度的抽取，然后由领域专家进行审核和修正，形成高质量的种子数据。再用这些数据去微调一个小的专用抽取模型。同时，定义清晰、有限的实体和关系类型，比追求大而全的图谱更重要。

问题五：系统延迟太高，用户体验差。

• 优化点：
  1. 检索阶段：优化向量索引（如使用HNSW），对非向量条件（如过滤标签）建立倒排索引。控制召回数量K。
  2. 重排序阶段：使用更轻量级的重排序模型，或只在置信度不高时才触发重排序。
  3. 生成阶段：考虑使用更快的模型（如较小的开源模型），或采用流式输出。
  4. 架构层面：对检索和生成进行异步处理或缓存高频查询的结果。

构建一个强大的RAG或GraphRAG系统，是一个持续迭代和优化的过程。它没有一劳永逸的解决方案，需要你深入理解自己的数据、业务场景和用户需求，在“检索精度”、“推理深度”、“系统复杂度”和“实施成本”之间找到最佳的平衡点。从简单的RAG开始，稳步推进，用数据驱动决策，才是通往成功最可靠的路径。