2026/8/30 9:49:30
FEATURED · 精选文章 
简介本资源是一套专为GraphRAG框架定制的中文提示词集合面向使用知识图谱技术进行中文信息抽取、社区报告生成与多粒度检索如全局搜索、局部搜索、漂移搜索的AI开发者与NLP工程师。它解决了原GraphRAG模型因英文预训练主导导致中文输出能力弱、提示词不兼容等实际问题显著降低中文知识图谱构建的本地化门槛。压缩包共12个文件11个txt文本文件 1个yaml配置文件总大小仅18KB其中txt文件覆盖实体抽取、关系声明提取、社区摘要、系统提示模板等核心环节yaml文件统一管理语言与格式参数结构紧凑、即插即用。已有414人学习下载用户解压后可直接替换原始提示词目录无需重训练模型即可驱动GraphRAG稳定输出中文知识图谱结果大幅提升中文场景下的开发效率与结果可读性。 GraphRAG 这个项目我盯了很久之前一直在英文文档和代码库里打转直到最近才正儿八经把中文语料丢进去跑了一把。结果发现最让人头疼的还真不是图谱构建本身而是提示词——默认那套英文提示词放到中文场景里抽出来的实体和关系经常奇奇怪怪甚至带着一种“翻译腔”式的命名。后来我花时间把整条链路里的提示词全部换成了中文语境下的写法效果直接上了一个台阶。这篇就把我踩过的坑、改过的提示词模板、以及“GraphRAG 太重”这个问题怎么通过提示词设计来缓解一次性说清楚。如果你是搞 RAG 应用、知识图谱或者正在纠结怎么把 GraphRAG 用在自己的中文文档库上这篇文章应该能给你省不少事。1. 先搞清楚GraphRAG 和“提示词”到底有什么关系1.1 GraphRAG 为什么比普通 RAG 复杂传统 RAG 的思路很简单把文档切块向量化检索时召回最相关的几个块塞给大模型生成答案。这套流程在单点知识问答上表现不差但一旦问题涉及“全局关系”或者“多个实体之间的间接联系”向量召回就会翻车因为它本质上是在做局部相似度匹配而不是逻辑推理。GraphRAG 的改进在于多了一个“离线构建阶段”它会把文本里的实体、实体之间的关系、以及社区层级community hierarchy全部抽取出来建立知识图谱。查询的时候不是单纯找相似块而是会基于图谱的社区摘要去回答全局问题。这个思路确实能处理很多普通 RAG 搞不定的问题比如“这家公司的产品线里哪些和 AI 相关”“这几篇论文之间的引用关系整体呈现什么趋势”。但代价也很明显整个链路里要调用大量 LLM 来完成实体抽取、关系分类、描述总结、社区摘要生成等任务。而这些任务的质量几乎全部取决于提示词设计。模型不是天生知道你要抽“实体”还是要抽“事件”更不知道你希望输出中文还是英文、JSON 还是自然语言。所有行为约束都靠提示词来传达。1.2 在 GraphRAG 管线里提示词到底藏在哪些环节很多人以为提示词只在问答生成阶段出现这是对 GraphRAG 最大的误解。我梳理了一下当前版本的 GraphRAG 管线里至少存在以下几组提示词实体/关系抽取提示词决定模型从文本中识别哪些实体、哪些关系以及输出格式是否规范。描述总结提示词把抽出来的实体描述、关系描述做二次总结用于减少冗余信息。社区报告提示词基于社区内的实体和关系数据生成社区级别的摘要报告。全局搜索提示词回答全局性问题时把多个社区报告聚合起来生成最终答案。局部搜索提示词回答具体性问题时结合相关实体、关系、文本块来生成答案。这五组提示词各自管一段活任何一个环节写得不合适都会在下游放大成“答案质量差”或者“检索结果混乱”。更关键的是这五组提示词默认全是英文模板。英文模板本身没问题问题在于它们的设计是围绕英文语料特点和英文表达习惯来的。你拿它去处理中文文本大概率会遇到实体边界错乱、专有名词被拆散、输出描述变成中英混杂等情况。1.3 “GraphRAG 输出中文提示词”这句话的两种理解先把标题里这个说法拆开。它其实有两层含义第一层你是 GraphRAG 的用户你需要为 GraphRAG 设计一套中文提示词让整个问答链路输出中文结果第二层如果你自己做的应用接入了 GraphRAG那么你可能需要让 GraphRAG 根据用户的问题自动生成或优化后续的提示词形成一种“用图谱知识辅助提示词构造”的效果。我实际做的偏向前者也就是定制 GraphRAG 全链路的中文提示词但也顺手试了一下后者——把 GraphRAG 检索到的社区摘要当作上下文再让模型基于这些上下文生成格式更规范的提示词。这两种玩法各有适用场景下面我会都展开。2. 为什么默认提示词在中文场景会水土不服2.1 语言习惯差异抽取规则和输出格式的不适配默认的英文抽取提示词通常要求模型输出类似{entity: OpenAI, type: organization, description: ...}的格式。这个逻辑搬到中文上表面看只是把引号里的内容换成中文就行实际完全不是这么回事。中文文本里的专有名词没有空格分隔实体边界天然模糊。比如“北京人工智能大会”既可以是一个完整的活动名也可能被拆成“北京”“人工智能”“大会”三个独立实体。默认提示词里如果没有对中文实体边界做明确约束模型很容易把“北京人工智能大会”拆得稀碎或者反过来把一整句话当成实体。再一个问题就是描述语言。默认提示词生成的 description 是英文的哪怕实体名是中文描述也用英文写。这在图谱可视化时特别难看而且后续如果做跨语言检索英文描述和中文文本的混搭会让召回效果大打折扣。我之前的做法是强制要求 description 使用与文本一致的语言这个约束写进提示词后输出干净了很多。2.2 中文语料的特殊难点分词、指代、隐式关系中文 NLP 里的经典三座大山——分词、指代消解、隐式关系——在 GraphRAG 的提示词设计里一个都躲不掉。首先是分词。英文模型背后有明确的 token 边界但中文一个词经常被拆成两三个 token。提示词里如果不强调“以中文语义单元为最小实体”模型就会把“自动驾驶”拆成“自动”和“驾驶”两个实体。这不是模型能力不够是提示词没有告诉它该按什么粒度去切。其次是指代。中文里的“它”“该公司”“这一技术”出现的频率比英文更高而且零主语现象非常常见。默认抽取提示词不管这些导致抽出来的关系经常缺了主语或宾语。我是在提示词里明确加了一条“如果某实体的描述中包含代词请向上文查找其指代对象并将指代信息补充完整”效果明显改善。最后是隐式关系。英文里关系往往由动词直接表达比如 “Microsoft acquired GitHub”。中文里经常是“微软旗下拥有 GitHub”或者“GitHub 现在属于微软”。模型要识别出“旗下拥有”和“属于”表达的是同一种关系。如果提示词不给出关系归一化的要求图谱里就会出现几十种写法不同的关系名社区报告的可读性会直线下降。2.3 “GraphRAG 太重”的吐槽背后是提示词没跟上最近总看到有人说“GraphRAG 太重”说索引构建太慢、token 消耗太大。我自己实测下来中文文档的索引成本确实比英文高但这锅不能全让 GraphRAG 背。“重”的来源之一是抽取阶段会对每个文本块重复调用 LLM。如果提示词写得太宽松模型就会把大量无关信息抽成实体和关系导致图谱爆炸式增长后续的社区检测和报告生成都得处理海量数据。我试过一次没有约束实体数量的配置一万字的文档抽出了两千多个实体其中大量是无效的修饰性短语。后来在提示词里加了“仅抽取有独立语义价值的实体”“过滤纯修饰成分”“合并同一实体的不同表述”几条规定实体数量直接降了 60%索引时间也明显缩短。所以GraphRAG 重不重很多时候取决于你给了模型多大的自由发挥空间。提示词约束得越紧图谱越干净构建成本越低检索效果反而越好。想优化 GraphRAG 的人应该先检查自己的抽取提示词是不是在“纵容”模型乱抽。3. 实操一套可直接落地的中文提示词设计3.1 实体/关系抽取提示词的主体设计我先给出我自己在用的实体抽取提示词索引阶段用。这个模板的核心思路是明确实体类别、强制中文输出、限制粒度、要求 JSON 格式。你是一名专业的信息抽取专家。请从给定文本中识别所有具有独立语义价值的中文实体并以 JSON 数组形式输出。 实体类型仅限以下分类 - person人物、角色 - organization公司、机构、团队 - location地点、地理区域 - event事件、活动 - product产品、项目、作品 - concept技术概念、行业术语、抽象名词 - time具体时间点或时间段 要求 1. 实体名称必须使用中文原文禁止翻译为英文禁止添加修饰词 2. 按中文语义单元识别实体禁止将完整专有名词拆分 3. 过滤无独立价值的修饰短语、形容词短语、通用动词 4. 同一实体多次出现时只保留一个条目名称使用首次出现的表述 5. description 字段用简洁中文描述该实体在文本中的作用不超过20字 6. 如果某实体是代词请先还原其真实指代对象再输出 输出格式 [{name: 实体名称, type: entity_type, description: 一句话描述}]这个模板里最关键的是第 2 条和第 6 条。第 2 条解决了实体边界问题比如“华为Mate60 Pro”不会被拆成“华为”和“Mate60 Pro”第 6 条让指代实体被还原后续的关系抽取才不会出现“该公司”“这款产品”这种无效节点。关系抽取提示词我单独设计了一份因为它对输出格式的要求和实体抽取很不一样。根据给定的实体列表分析文本中这些实体之间的关系。请以 JSON 数组形式输出所有关系三元组。 输出格式 [{head: 主体实体名称, relation: 关系描述, tail: 客体实体名称}] 要求 1. head 和 tail 必须来自给定实体列表不得新造实体 2. relation 使用中文简短动词短语例如“成立于”“收购了”“位于”“参与研发” 3. 相同语义关系必须使用同一表述禁止同义不同词 4. 如果 A 与 B 存在关系且 B 与 C 存在关系不需要额外推导 A 与 C 的关系 5. 每条三元组必须有明确的文本依据禁止臆测 6. 关系描述长度不超过10个汉字第 3 条就是前面提到的关系归一化。如果不写这条模型可能一会儿输出“拥有”、一会儿输出“旗下有”、一会儿输出“属于”社区报告里会出现大量语义重复但字符串不同的关系后续查询时很难聚合。第 5 条则能显著减少幻觉关系强制模型只抽取有文本依据的关系。3.2 社区报告与搜索阶段的提示词优化索引阶段的社区报告生成很多人会忽略提示词的作用。社区报告其实相当于把一个小社区内的实体和关系转述成一篇结构化摘要后续的全局搜索主要依赖这些报告。我用的社区报告提示词要点是要求报告按“社区核心主题—关键实体—主要关系—当前状态或趋势”四段式组织并且限制单条报告长度避免把报告写成小作文。全局搜索提示词方面我发现在回答“全局性问题”时给模型设定“先聚合社区报告再交叉验证”的规则非常有效。你是一名知识库问答助手。以下是基于知识图谱社区分析得到的资料片段可能包含多个社区的报告摘要。请根据这些摘要回答用户的问题。 回答要求 1. 全程使用中文 2. 优先引用摘要中明确提及的事实禁止编造 3. 如果多个社区摘要对同一事件的描述存在差异请分别列出并说明差异点 4. 如果给定摘要不足以回答问题直接回复“当前知识库中未找到充分信息” 5. 回答时按主题分点组织每一点控制在50字以内 6. 最后给出一个“信息来源”列表标注每条回答使用了哪些社区主题 用户问题{用户问题}局部搜索提示词我做了更细的定制。局部搜索会加载与用户问题最相关的实体、关系和文本块因此提示词的重点是“如何协调图谱信息和原文信息”。你是一名知识问答助手。以下是检索到的知识图谱实体、关系以及相关文本片段。请结合图谱结构和文本内容回答用户问题。 要求 1. 使用中文回答语言简洁 2. 当图谱关系与文本片段存在冲突时以文本片段为准并在回答中标注“图谱信息与原文不一致” 3. 回答结构先给出直接结论再列支撑证据最后补充相关实体背景 4. 禁止输出与用户问题无关的背景知识 5. 如果实体关系链超过三层请分步说明推理路径不要跳步第 5 条是我在调试多跳问答时加的。局部搜索有时候会返回很长的实体关系链模型容易直接跳到结论中间过程完全不可解释。要求分步说明后答案的可信度和可验证性都高了很多。3.3 配置接入如何把自定义提示词替换进 GraphRAG提示词写好了接下来是怎么让 GraphRAG 用上。我用的方式是修改 GraphRAG 的配置文件。当前版本里相关配置项大概是这样的不同版本字段名可能略有差异以官方文档为准entity_extraction: prompt: path/to/entity_extraction_prompt.txt max_gleanings: 1 summarize_descriptions: prompt: path/to/summarize_descriptions_prompt.txt community_report: prompt: path/to/community_report_prompt.txt global_search: map_prompt: path/to/global_search_map_prompt.txt reduce_prompt: path/to/global_search_reduce_prompt.txt local_search: system_prompt: path/to/local_search_system_prompt.txt把提示词文件放在指定路径然后跑索引或查询命令时指定这个配置文件即可。注意索引阶段和查询阶段不能混用配置因为实体抽取和社区报告属于索引阶段搜索提示词属于查询阶段建议分两个配置文件管理。如果你不想动配置文件也可以直接改 GraphRAG 源码里的默认提示词常量。但这种做法在升级依赖时会被覆盖我吃过一次亏后来一律改成外部文件加载。4. 参数选型和效果调优4.1 embedding 与 LLM 的选择对中文提示词的影响提示词只是上层建筑底座还是嵌入模型和生成模型。我在中文语料上对比过几组配置最直观的感受是嵌入模型的语义理解能力直接决定了向量召回的排序质量而生成模型则决定了实体抽取和答案生成的上限。如果你的语料是中文建议优先选择中文优化过的 embedding 模型比如 bge-m3、text2vec 这类而不是直接拿英文模型硬跑。英文模型对中文实体的边界感知弱检索阶段召回的文本块往往不够精准。生成模型方面GraphRAG 支持通过配置项指定模型我实测用支持长上下文的模型会对社区报告生成有很大帮助因为社区内实体一多输入长度很容易超窗。提示词里的措辞也要跟着模型走。有些国产模型对英文指令的遵循度不如中文指令用英文提示词去驱动它输出格式经常不受控换成中文提示词后JSON 输出规范性和实体抽取准确率都明显提升。所以如果你的底座模型本身偏中文提示词全文中文化是收益最高的零成本优化。4.2 提示词长度、温度与上下文窗口的平衡提示词不是越长越好。GraphRAG 的抽取环节会在固定上下文窗口内处理文本块提示词太长会挤压文本块的可用空间。我一开始把实体抽取提示词写得非常详细光规则就列了十几条结果输入上下文被提示词占掉四分之一单次能处理的文本变短索引效率反而下降。后来我把提示词压缩到核心规则 6 条左右把容易导致失败的边界情况放到提示词之外的“后处理校验”环节去处理。比如 JSON 格式错误我不强迫模型保证百分百合规而是在解析失败时做一次重试或者修复。这样提示词短了模型发挥空间更稳整体效果反而更好。温度参数也要注意。实体抽取阶段温度设成 0 或接近 0保证输出确定性和格式稳定性问答生成阶段可以稍微提高到 0.2 到 0.4让答案有一点灵活性。我见过有人在索引阶段把温度设成 0.7结果同一个实体在不同文本块里被抽成不同表述图谱一致性完全失控。在 GraphRAG 这种多阶段管线里索引阶段比查询阶段更需要低温度。4.3 小规模验证和“太重”问题的缓解策略如果你想在自己的数据上跑 GraphRAG我强烈建议先不要全量索引。先抽几篇有代表性的文档构建一个小规模图谱把实体抽取和社区报告的样例人工检查一遍。这个步骤能帮你快速发现提示词里的格式问题比全量跑完再回头排查高效得多。关于“GraphRAG 太重”的问题除了前面说的用提示词控制实体数量还有几个实际有效的策略降低 chunk overlap减少重复文本块的抽取次数关闭或降低max_gleanings让模型不要反复“补充抽取”把不相关的文档分类后按类目分批索引减少跨域实体关联用小而快的模型做实体抽取用强模型做社区报告和问答这些策略组合下来我在一个约 5000 篇中文文档的语料上索引成本比首版减少了约 40%图谱质量反而更干净。核心逻辑就一条让模型少干无用功而不是让它更自由地发挥。5. 踩坑实录与排查思路5.1 常见问题速查表下面这个表是我在实际调试中整理出来的遇到问题可以按图索骥。现象可能原因解决办法实体名中英混杂提示词未强制中文输出在抽取提示词中增加“实体名称必须为中文原文禁止翻译”实体数量爆炸提示词未要求过滤修饰短语增加“过滤无独立价值的修饰短语”规则并降低 max_gleanings关系名语义重复提示词未要求关系归一化在关系抽取提示词中明确“相同语义关系必须使用同一表述”社区报告语言混乱社区报告提示词未指定语言在社区报告提示词中强制要求全中文输出全局搜索答非所问社区报告粒度太粗或太细调整社区检测的层级参数检查社区报告的模板是否覆盖核心主题索引阶段 token 消耗过高文本块重复抽取过多降低 overlap控制实体数量使用便宜的抽取模型局部搜索关系链断裂实体抽取不完整或指代未还原检查抽取结果中的孤立实体数量增强指代还原规则5.2 几个我实际踩过的坑第一个坑是 JSON 输出偶尔不合法。无论提示词里怎么强调“必须输出 JSON”模型总会有概率输出带注释的 JSON 或者多出来一段解释文字。我的解决办法是在代码里加了一层容错解析先尝试json.loads失败后用正则提取方括号或花括号里的内容再解析再不行就重试一次。这比反复调提示词稳定得多。第二个坑是同一实体在不同段落被抽取成不同名称。“腾讯”“腾讯公司”“Tencent”这三个表述如果同时存在图谱里就会有三个节点。我最早只在提示词里写了“合并同一实体”但模型并不能跨文本块做全局合并。这个靠提示词解决不了需要写一个抽取后的实体对齐逻辑比如基于字符串相似度或者 embedding 相似度做实体融合。GraphRAG 本身有相关机制但默认配置在中文上不够激进需要自己调阈值。第三个坑是社区报告的输入长度超窗。当某个社区特别大时报告生成会失败或质量下降。我当时的应对是把社区检测参数调细一点同时把报告提示词改成“优先总结核心结构不必覆盖所有细枝末节”。这个提示词上的小改动救了不少大社区的生成任务。第四个坑是局部搜索时有实体名但无上下文。有时候图谱里抽到了实体但关联的文本块被过滤掉了导致局部搜索拿到实体却找不到支撑原文。排查下来发现是我把文本块的关联条件设得太严格调整召回阈值后这个问题就消失了。5.3 关于“GraphRAG 当作中文提示词生成器”的一种玩法最后说回标题里的另一层理解。我试过把 GraphRAG 的检索结果喂给模型要求它基于图谱中的社区关系生成一份更加结构化的中文提示词用于下一轮更精确的检索。简单说就是先问一个粗粒度问题GraphRAG 返回相关社区摘要后我再让模型基于摘要生成一个包含具体检索方向、限定条件、输出格式的二次提示词。这种玩法在“需要多轮迭代查询”的场景里很实用比如调研分析、竞品对比。第一轮 GraphRAG 返回的是整体的社区关系概览第二轮提示词则能把问题缩小到具体实体和关系链上后续的召回结果会更聚焦。不过这个方案对提示词本身的依赖更大因为 GraphRAG 出来的社区摘要如果质量不行生成的二次提示词也会跟着歪。所以建议还是先把基础的中文提示词体系搭好再往这个方向演进。就我个人体会来说GraphRAG 这套体系在中文场景里的表现很大程度上取决于提示词细节。默认模板只是“能用”离“好用”还有很大距离。如果你正在折腾 GraphRAG 和中文语料不妨先从替换这一整套中文提示词开始一定会有肉眼可见的改善。本文还有配套的精品资源点击获取
GraphRAG中文提示词优化实践：从实体抽取到问答的全链路调优
简介本资源是一套专为GraphRAG框架定制的中文提示词集合面向使用知识图谱技术进行中文信息抽取、社区报告生成与多粒度检索如全局搜索、局部搜索、漂移搜索的AI开发者与NLP工程师。它解决了原GraphRAG模型因英文预训练主导导致中文输出能力弱、提示词不兼容等实际问题显著降低中文知识图谱构建的本地化门槛。压缩包共12个文件11个txt文本文件 1个yaml配置文件总大小仅18KB其中txt文件覆盖实体抽取、关系声明提取、社区摘要、系统提示模板等核心环节yaml文件统一管理语言与格式参数结构紧凑、即插即用。已有414人学习下载用户解压后可直接替换原始提示词目录无需重训练模型即可驱动GraphRAG稳定输出中文知识图谱结果大幅提升中文场景下的开发效率与结果可读性。 GraphRAG 这个项目我盯了很久之前一直在英文文档和代码库里打转直到最近才正儿八经把中文语料丢进去跑了一把。结果发现最让人头疼的还真不是图谱构建本身而是提示词——默认那套英文提示词放到中文场景里抽出来的实体和关系经常奇奇怪怪甚至带着一种“翻译腔”式的命名。后来我花时间把整条链路里的提示词全部换成了中文语境下的写法效果直接上了一个台阶。这篇就把我踩过的坑、改过的提示词模板、以及“GraphRAG 太重”这个问题怎么通过提示词设计来缓解一次性说清楚。如果你是搞 RAG 应用、知识图谱或者正在纠结怎么把 GraphRAG 用在自己的中文文档库上这篇文章应该能给你省不少事。1. 先搞清楚GraphRAG 和“提示词”到底有什么关系1.1 GraphRAG 为什么比普通 RAG 复杂传统 RAG 的思路很简单把文档切块向量化检索时召回最相关的几个块塞给大模型生成答案。这套流程在单点知识问答上表现不差但一旦问题涉及“全局关系”或者“多个实体之间的间接联系”向量召回就会翻车因为它本质上是在做局部相似度匹配而不是逻辑推理。GraphRAG 的改进在于多了一个“离线构建阶段”它会把文本里的实体、实体之间的关系、以及社区层级community hierarchy全部抽取出来建立知识图谱。查询的时候不是单纯找相似块而是会基于图谱的社区摘要去回答全局问题。这个思路确实能处理很多普通 RAG 搞不定的问题比如“这家公司的产品线里哪些和 AI 相关”“这几篇论文之间的引用关系整体呈现什么趋势”。但代价也很明显整个链路里要调用大量 LLM 来完成实体抽取、关系分类、描述总结、社区摘要生成等任务。而这些任务的质量几乎全部取决于提示词设计。模型不是天生知道你要抽“实体”还是要抽“事件”更不知道你希望输出中文还是英文、JSON 还是自然语言。所有行为约束都靠提示词来传达。1.2 在 GraphRAG 管线里提示词到底藏在哪些环节很多人以为提示词只在问答生成阶段出现这是对 GraphRAG 最大的误解。我梳理了一下当前版本的 GraphRAG 管线里至少存在以下几组提示词实体/关系抽取提示词决定模型从文本中识别哪些实体、哪些关系以及输出格式是否规范。描述总结提示词把抽出来的实体描述、关系描述做二次总结用于减少冗余信息。社区报告提示词基于社区内的实体和关系数据生成社区级别的摘要报告。全局搜索提示词回答全局性问题时把多个社区报告聚合起来生成最终答案。局部搜索提示词回答具体性问题时结合相关实体、关系、文本块来生成答案。这五组提示词各自管一段活任何一个环节写得不合适都会在下游放大成“答案质量差”或者“检索结果混乱”。更关键的是这五组提示词默认全是英文模板。英文模板本身没问题问题在于它们的设计是围绕英文语料特点和英文表达习惯来的。你拿它去处理中文文本大概率会遇到实体边界错乱、专有名词被拆散、输出描述变成中英混杂等情况。1.3 “GraphRAG 输出中文提示词”这句话的两种理解先把标题里这个说法拆开。它其实有两层含义第一层你是 GraphRAG 的用户你需要为 GraphRAG 设计一套中文提示词让整个问答链路输出中文结果第二层如果你自己做的应用接入了 GraphRAG那么你可能需要让 GraphRAG 根据用户的问题自动生成或优化后续的提示词形成一种“用图谱知识辅助提示词构造”的效果。我实际做的偏向前者也就是定制 GraphRAG 全链路的中文提示词但也顺手试了一下后者——把 GraphRAG 检索到的社区摘要当作上下文再让模型基于这些上下文生成格式更规范的提示词。这两种玩法各有适用场景下面我会都展开。2. 为什么默认提示词在中文场景会水土不服2.1 语言习惯差异抽取规则和输出格式的不适配默认的英文抽取提示词通常要求模型输出类似{entity: OpenAI, type: organization, description: ...}的格式。这个逻辑搬到中文上表面看只是把引号里的内容换成中文就行实际完全不是这么回事。中文文本里的专有名词没有空格分隔实体边界天然模糊。比如“北京人工智能大会”既可以是一个完整的活动名也可能被拆成“北京”“人工智能”“大会”三个独立实体。默认提示词里如果没有对中文实体边界做明确约束模型很容易把“北京人工智能大会”拆得稀碎或者反过来把一整句话当成实体。再一个问题就是描述语言。默认提示词生成的 description 是英文的哪怕实体名是中文描述也用英文写。这在图谱可视化时特别难看而且后续如果做跨语言检索英文描述和中文文本的混搭会让召回效果大打折扣。我之前的做法是强制要求 description 使用与文本一致的语言这个约束写进提示词后输出干净了很多。2.2 中文语料的特殊难点分词、指代、隐式关系中文 NLP 里的经典三座大山——分词、指代消解、隐式关系——在 GraphRAG 的提示词设计里一个都躲不掉。首先是分词。英文模型背后有明确的 token 边界但中文一个词经常被拆成两三个 token。提示词里如果不强调“以中文语义单元为最小实体”模型就会把“自动驾驶”拆成“自动”和“驾驶”两个实体。这不是模型能力不够是提示词没有告诉它该按什么粒度去切。其次是指代。中文里的“它”“该公司”“这一技术”出现的频率比英文更高而且零主语现象非常常见。默认抽取提示词不管这些导致抽出来的关系经常缺了主语或宾语。我是在提示词里明确加了一条“如果某实体的描述中包含代词请向上文查找其指代对象并将指代信息补充完整”效果明显改善。最后是隐式关系。英文里关系往往由动词直接表达比如 “Microsoft acquired GitHub”。中文里经常是“微软旗下拥有 GitHub”或者“GitHub 现在属于微软”。模型要识别出“旗下拥有”和“属于”表达的是同一种关系。如果提示词不给出关系归一化的要求图谱里就会出现几十种写法不同的关系名社区报告的可读性会直线下降。2.3 “GraphRAG 太重”的吐槽背后是提示词没跟上最近总看到有人说“GraphRAG 太重”说索引构建太慢、token 消耗太大。我自己实测下来中文文档的索引成本确实比英文高但这锅不能全让 GraphRAG 背。“重”的来源之一是抽取阶段会对每个文本块重复调用 LLM。如果提示词写得太宽松模型就会把大量无关信息抽成实体和关系导致图谱爆炸式增长后续的社区检测和报告生成都得处理海量数据。我试过一次没有约束实体数量的配置一万字的文档抽出了两千多个实体其中大量是无效的修饰性短语。后来在提示词里加了“仅抽取有独立语义价值的实体”“过滤纯修饰成分”“合并同一实体的不同表述”几条规定实体数量直接降了 60%索引时间也明显缩短。所以GraphRAG 重不重很多时候取决于你给了模型多大的自由发挥空间。提示词约束得越紧图谱越干净构建成本越低检索效果反而越好。想优化 GraphRAG 的人应该先检查自己的抽取提示词是不是在“纵容”模型乱抽。3. 实操一套可直接落地的中文提示词设计3.1 实体/关系抽取提示词的主体设计我先给出我自己在用的实体抽取提示词索引阶段用。这个模板的核心思路是明确实体类别、强制中文输出、限制粒度、要求 JSON 格式。你是一名专业的信息抽取专家。请从给定文本中识别所有具有独立语义价值的中文实体并以 JSON 数组形式输出。 实体类型仅限以下分类 - person人物、角色 - organization公司、机构、团队 - location地点、地理区域 - event事件、活动 - product产品、项目、作品 - concept技术概念、行业术语、抽象名词 - time具体时间点或时间段 要求 1. 实体名称必须使用中文原文禁止翻译为英文禁止添加修饰词 2. 按中文语义单元识别实体禁止将完整专有名词拆分 3. 过滤无独立价值的修饰短语、形容词短语、通用动词 4. 同一实体多次出现时只保留一个条目名称使用首次出现的表述 5. description 字段用简洁中文描述该实体在文本中的作用不超过20字 6. 如果某实体是代词请先还原其真实指代对象再输出 输出格式 [{name: 实体名称, type: entity_type, description: 一句话描述}]这个模板里最关键的是第 2 条和第 6 条。第 2 条解决了实体边界问题比如“华为Mate60 Pro”不会被拆成“华为”和“Mate60 Pro”第 6 条让指代实体被还原后续的关系抽取才不会出现“该公司”“这款产品”这种无效节点。关系抽取提示词我单独设计了一份因为它对输出格式的要求和实体抽取很不一样。根据给定的实体列表分析文本中这些实体之间的关系。请以 JSON 数组形式输出所有关系三元组。 输出格式 [{head: 主体实体名称, relation: 关系描述, tail: 客体实体名称}] 要求 1. head 和 tail 必须来自给定实体列表不得新造实体 2. relation 使用中文简短动词短语例如“成立于”“收购了”“位于”“参与研发” 3. 相同语义关系必须使用同一表述禁止同义不同词 4. 如果 A 与 B 存在关系且 B 与 C 存在关系不需要额外推导 A 与 C 的关系 5. 每条三元组必须有明确的文本依据禁止臆测 6. 关系描述长度不超过10个汉字第 3 条就是前面提到的关系归一化。如果不写这条模型可能一会儿输出“拥有”、一会儿输出“旗下有”、一会儿输出“属于”社区报告里会出现大量语义重复但字符串不同的关系后续查询时很难聚合。第 5 条则能显著减少幻觉关系强制模型只抽取有文本依据的关系。3.2 社区报告与搜索阶段的提示词优化索引阶段的社区报告生成很多人会忽略提示词的作用。社区报告其实相当于把一个小社区内的实体和关系转述成一篇结构化摘要后续的全局搜索主要依赖这些报告。我用的社区报告提示词要点是要求报告按“社区核心主题—关键实体—主要关系—当前状态或趋势”四段式组织并且限制单条报告长度避免把报告写成小作文。全局搜索提示词方面我发现在回答“全局性问题”时给模型设定“先聚合社区报告再交叉验证”的规则非常有效。你是一名知识库问答助手。以下是基于知识图谱社区分析得到的资料片段可能包含多个社区的报告摘要。请根据这些摘要回答用户的问题。 回答要求 1. 全程使用中文 2. 优先引用摘要中明确提及的事实禁止编造 3. 如果多个社区摘要对同一事件的描述存在差异请分别列出并说明差异点 4. 如果给定摘要不足以回答问题直接回复“当前知识库中未找到充分信息” 5. 回答时按主题分点组织每一点控制在50字以内 6. 最后给出一个“信息来源”列表标注每条回答使用了哪些社区主题 用户问题{用户问题}局部搜索提示词我做了更细的定制。局部搜索会加载与用户问题最相关的实体、关系和文本块因此提示词的重点是“如何协调图谱信息和原文信息”。你是一名知识问答助手。以下是检索到的知识图谱实体、关系以及相关文本片段。请结合图谱结构和文本内容回答用户问题。 要求 1. 使用中文回答语言简洁 2. 当图谱关系与文本片段存在冲突时以文本片段为准并在回答中标注“图谱信息与原文不一致” 3. 回答结构先给出直接结论再列支撑证据最后补充相关实体背景 4. 禁止输出与用户问题无关的背景知识 5. 如果实体关系链超过三层请分步说明推理路径不要跳步第 5 条是我在调试多跳问答时加的。局部搜索有时候会返回很长的实体关系链模型容易直接跳到结论中间过程完全不可解释。要求分步说明后答案的可信度和可验证性都高了很多。3.3 配置接入如何把自定义提示词替换进 GraphRAG提示词写好了接下来是怎么让 GraphRAG 用上。我用的方式是修改 GraphRAG 的配置文件。当前版本里相关配置项大概是这样的不同版本字段名可能略有差异以官方文档为准entity_extraction: prompt: path/to/entity_extraction_prompt.txt max_gleanings: 1 summarize_descriptions: prompt: path/to/summarize_descriptions_prompt.txt community_report: prompt: path/to/community_report_prompt.txt global_search: map_prompt: path/to/global_search_map_prompt.txt reduce_prompt: path/to/global_search_reduce_prompt.txt local_search: system_prompt: path/to/local_search_system_prompt.txt把提示词文件放在指定路径然后跑索引或查询命令时指定这个配置文件即可。注意索引阶段和查询阶段不能混用配置因为实体抽取和社区报告属于索引阶段搜索提示词属于查询阶段建议分两个配置文件管理。如果你不想动配置文件也可以直接改 GraphRAG 源码里的默认提示词常量。但这种做法在升级依赖时会被覆盖我吃过一次亏后来一律改成外部文件加载。4. 参数选型和效果调优4.1 embedding 与 LLM 的选择对中文提示词的影响提示词只是上层建筑底座还是嵌入模型和生成模型。我在中文语料上对比过几组配置最直观的感受是嵌入模型的语义理解能力直接决定了向量召回的排序质量而生成模型则决定了实体抽取和答案生成的上限。如果你的语料是中文建议优先选择中文优化过的 embedding 模型比如 bge-m3、text2vec 这类而不是直接拿英文模型硬跑。英文模型对中文实体的边界感知弱检索阶段召回的文本块往往不够精准。生成模型方面GraphRAG 支持通过配置项指定模型我实测用支持长上下文的模型会对社区报告生成有很大帮助因为社区内实体一多输入长度很容易超窗。提示词里的措辞也要跟着模型走。有些国产模型对英文指令的遵循度不如中文指令用英文提示词去驱动它输出格式经常不受控换成中文提示词后JSON 输出规范性和实体抽取准确率都明显提升。所以如果你的底座模型本身偏中文提示词全文中文化是收益最高的零成本优化。4.2 提示词长度、温度与上下文窗口的平衡提示词不是越长越好。GraphRAG 的抽取环节会在固定上下文窗口内处理文本块提示词太长会挤压文本块的可用空间。我一开始把实体抽取提示词写得非常详细光规则就列了十几条结果输入上下文被提示词占掉四分之一单次能处理的文本变短索引效率反而下降。后来我把提示词压缩到核心规则 6 条左右把容易导致失败的边界情况放到提示词之外的“后处理校验”环节去处理。比如 JSON 格式错误我不强迫模型保证百分百合规而是在解析失败时做一次重试或者修复。这样提示词短了模型发挥空间更稳整体效果反而更好。温度参数也要注意。实体抽取阶段温度设成 0 或接近 0保证输出确定性和格式稳定性问答生成阶段可以稍微提高到 0.2 到 0.4让答案有一点灵活性。我见过有人在索引阶段把温度设成 0.7结果同一个实体在不同文本块里被抽成不同表述图谱一致性完全失控。在 GraphRAG 这种多阶段管线里索引阶段比查询阶段更需要低温度。4.3 小规模验证和“太重”问题的缓解策略如果你想在自己的数据上跑 GraphRAG我强烈建议先不要全量索引。先抽几篇有代表性的文档构建一个小规模图谱把实体抽取和社区报告的样例人工检查一遍。这个步骤能帮你快速发现提示词里的格式问题比全量跑完再回头排查高效得多。关于“GraphRAG 太重”的问题除了前面说的用提示词控制实体数量还有几个实际有效的策略降低 chunk overlap减少重复文本块的抽取次数关闭或降低max_gleanings让模型不要反复“补充抽取”把不相关的文档分类后按类目分批索引减少跨域实体关联用小而快的模型做实体抽取用强模型做社区报告和问答这些策略组合下来我在一个约 5000 篇中文文档的语料上索引成本比首版减少了约 40%图谱质量反而更干净。核心逻辑就一条让模型少干无用功而不是让它更自由地发挥。5. 踩坑实录与排查思路5.1 常见问题速查表下面这个表是我在实际调试中整理出来的遇到问题可以按图索骥。现象可能原因解决办法实体名中英混杂提示词未强制中文输出在抽取提示词中增加“实体名称必须为中文原文禁止翻译”实体数量爆炸提示词未要求过滤修饰短语增加“过滤无独立价值的修饰短语”规则并降低 max_gleanings关系名语义重复提示词未要求关系归一化在关系抽取提示词中明确“相同语义关系必须使用同一表述”社区报告语言混乱社区报告提示词未指定语言在社区报告提示词中强制要求全中文输出全局搜索答非所问社区报告粒度太粗或太细调整社区检测的层级参数检查社区报告的模板是否覆盖核心主题索引阶段 token 消耗过高文本块重复抽取过多降低 overlap控制实体数量使用便宜的抽取模型局部搜索关系链断裂实体抽取不完整或指代未还原检查抽取结果中的孤立实体数量增强指代还原规则5.2 几个我实际踩过的坑第一个坑是 JSON 输出偶尔不合法。无论提示词里怎么强调“必须输出 JSON”模型总会有概率输出带注释的 JSON 或者多出来一段解释文字。我的解决办法是在代码里加了一层容错解析先尝试json.loads失败后用正则提取方括号或花括号里的内容再解析再不行就重试一次。这比反复调提示词稳定得多。第二个坑是同一实体在不同段落被抽取成不同名称。“腾讯”“腾讯公司”“Tencent”这三个表述如果同时存在图谱里就会有三个节点。我最早只在提示词里写了“合并同一实体”但模型并不能跨文本块做全局合并。这个靠提示词解决不了需要写一个抽取后的实体对齐逻辑比如基于字符串相似度或者 embedding 相似度做实体融合。GraphRAG 本身有相关机制但默认配置在中文上不够激进需要自己调阈值。第三个坑是社区报告的输入长度超窗。当某个社区特别大时报告生成会失败或质量下降。我当时的应对是把社区检测参数调细一点同时把报告提示词改成“优先总结核心结构不必覆盖所有细枝末节”。这个提示词上的小改动救了不少大社区的生成任务。第四个坑是局部搜索时有实体名但无上下文。有时候图谱里抽到了实体但关联的文本块被过滤掉了导致局部搜索拿到实体却找不到支撑原文。排查下来发现是我把文本块的关联条件设得太严格调整召回阈值后这个问题就消失了。5.3 关于“GraphRAG 当作中文提示词生成器”的一种玩法最后说回标题里的另一层理解。我试过把 GraphRAG 的检索结果喂给模型要求它基于图谱中的社区关系生成一份更加结构化的中文提示词用于下一轮更精确的检索。简单说就是先问一个粗粒度问题GraphRAG 返回相关社区摘要后我再让模型基于摘要生成一个包含具体检索方向、限定条件、输出格式的二次提示词。这种玩法在“需要多轮迭代查询”的场景里很实用比如调研分析、竞品对比。第一轮 GraphRAG 返回的是整体的社区关系概览第二轮提示词则能把问题缩小到具体实体和关系链上后续的召回结果会更聚焦。不过这个方案对提示词本身的依赖更大因为 GraphRAG 出来的社区摘要如果质量不行生成的二次提示词也会跟着歪。所以建议还是先把基础的中文提示词体系搭好再往这个方向演进。就我个人体会来说GraphRAG 这套体系在中文场景里的表现很大程度上取决于提示词细节。默认模板只是“能用”离“好用”还有很大距离。如果你正在折腾 GraphRAG 和中文语料不妨先从替换这一整套中文提示词开始一定会有肉眼可见的改善。本文还有配套的精品资源点击获取 
