不论是索引还是查询都需要涉及针对LLM的调用,在模型不变的情况下,LLM响应内容的质量基本由指定的提示词来决定。默认提示是使用 GraphRAG 系统的最简单方法。它旨在开箱即用,只需极少的配置。有关索引和查询的每项默认提示的更多详细信息,请参阅手动调优页面。Prompt Tuning是GraphRAG 索引流程开始前的一个可选但强烈推荐的步骤,目的是让用于知识图谱生成的提示词适配你的特定数据领域,从而提升实体抽取和关系抽取的质量。
1. 它解决什么问题
GraphRAG 自带的默认提示词是通用型的,设计目标是开箱即用。但如果你的数据属于某个特定领域(如医学、法律、环境新闻),默认提示词可能无法准确识别该领域的专有实体类型和术语表达。Prompt Tuning就是用来弥补这个差距的。
GraphRAG 提供三种提示词使用方式:
- 默认提示词(Default Prompts):最简单,零配置,适合快速开始。
- 自动调优(Auto Tuning):官方推荐。用你自己的输入数据驱动 LLM,自动生成适配领域的提示词。它会采样文本、分析领域特征、发现实体类型、生成
few-shot示例,最终产出定制化的提示词文件。 - 手动调优(Manual Tuning):高级用例。直接手写或修改提示词文件,通过
{input_text}和{entity_types}等占位符控制注入内容。大多数用户不需要走到这一步。
2. 自动调优(Auto Tuning)
运行方式是通过CLI命令graphrag prompt-tune。生成的核心提示词文件包括实体/关系抽取、描述摘要、社区报告三类。核心参数包括:
- –root / -r:项目根目录路径,默认为当前根目录,提示词调优流程以此目录为基准读写配置与数据。
- –verbose / -v:以详细日志模式运行提示词调优流程。
- –domain:输入数据所属领域(如
space science、microbiology、environmental news);未指定时从输入数据自动推断。 - –selection-method:文本块采样方法,可选
all、random、top、auto,默认random。 - –n-subset-max:当
--selection-method=auto时,用于嵌入的文本块数量上限,默认300。 - –k:当
--selection-method=auto时,从每个聚类中心选取的最大文档数,默认15。 - –limit:当
--selection-method={random,top}时加载的文档数量,默认15。 - –max-tokens:提示词生成的最大token数,默认2000。
- –min-examples-required:实体抽取提示词中要求生成/包含的最少示例数,默认2。
- –chunk-size:每个示例文本块的大小,覆盖配置文件中的
chunking.size,默认 1200。 - –overlap:文档分块的重叠大小,覆盖配置文件中的
chunking.overlap,默认100。 - –language:GraphRAG 提示词输入与输出的主要语言。
- –discover-entity-types / --no-discover-entity-types:是否发现并抽取未指定的实体类型,默认开启(
discover-entity-types)。 - –output / -o:提示词保存目录,相对项目根目录,默认
prompts。 - –help:显示该帮助信息并退出。
我们依然使用本系列采用的演示场景通过调用graphrag prompt-tune命令生成针对性的提示词。我们依然使用如下这个四行的.csv提供作为原始的输入文档,
id,title,text
doc1,选址,2024年3月,李明决定在杭州开一家咖啡店。他考察了三个地点:学校附近、写字楼商圈、老城区街角。学校附近人流量大,但租金每月高达两万元;写字楼商圈工作日客流稳定,周末冷清;老城区租金低,但年轻客群少。最终李明选择了写字楼商圈,月租一万五千元,签约两年。
doc2,产品,李明将核心产品定为拿铁和美式。拿铁定价二十八元,适合大众口味;美式定价二十二元,面向咖啡爱好者。2024年5月,他推出季节限定款桂花拿铁,首月销量占总额的三成。店长王芳建议增加会员折扣,提升复购率。
doc3,营销,开业初期,李明通过小红书和抖音引流,首周新增粉丝五千人。2024年6月,他建立会员体系,充值五百元赠送五十元,三个月内会员数达到八百人。李明还与周边书店、健身房合作互推,获客成本从每人三十元降到十二元。
doc4,供应链,咖啡豆由云南普洱的供应商张伟每月供货一次,单价每公斤一百二十元。牛奶由本地乳企每日配送。2024年7月,因雨季运输延误,门店断货两天,损失约四千元。李明随后增加了第二家供应商作为备份。
我们执行如下的命令。由于我们的文档内容较少,所以将--selection-method参数设置为all。整个内容都是围绕经营咖啡店,所以我们将--domain设置为business & food and beverage。我们通过--language和-o参数将语言设置为中文,并将提示词文件保存在目录./custom_prompts下。
graphrag prompt-tune
--selection-method all
--domain "business & food and beverage"
--language Chinese
-o ./custom_prompts
命令执行之后,针对实体/关系抽取(extract_graph.txt)、描述摘要(summarize_descriptions.txt)和生成社区报告(community_report_graph.txt)的提示词文件将会出现在目录./custom_prompts中。
./custom_prompts
├── community_report_graph.txt
├── extract_graph.txt
└── summarize_descriptions.txt
如下所示的是extract_graph.txt的内容,很明显这是针对输入文件的内容和指定的领域(business & food and beverage)生成的内容。
-Goal-
Given a text document that is potentially relevant to this activity and a list of entity types, identify all entities of those types from the text and all relationships among the identified entities.
-Steps-
1. Identify all entities. For each identified entity, extract the following information:
- entity_name: Name of the entity, capitalized
- entity_type: One of the following types: [person, location, business venue, product, pricing, customer segment, promotion, marketing channel, membership program, business partner, supplier, logistics event, financial impact]
- entity_description: Comprehensive description of the entity's attributes and activities
Format each entity as ("entity"<|><entity_name><|><entity_type><|><entity_description>)
2. From the entities identified in step 1, identify all pairs of (source_entity, target_entity) that are *clearly related* to each other.
For each pair of related entities, extract the following information:
- source_entity: name of the source entity, as identified in step 1
- target_entity: name of the target entity, as identified in step 1
- relationship_description: explanation as to why you think the source entity and the target entity are related to each other
- relationship_strength: an integer score between 1 to 10, indicating strength of the relationship between the source entity and target entity
Format each relationship as ("relationship"<|><source_entity><|><target_entity><|><relationship_description><|><relationship_strength>)
3. Return output in chinese as a single list of all the entities and relationships identified in steps 1 and 2. Use **##** as the list delimiter.
4. If you have to translate into chinese, just translate the descriptions, nothing else!
5. When finished, output <|COMPLETE|>.
-Examples-
######################
Example 1:
entity_types: [person, location, business venue, product, pricing, customer segment, promotion, marketing channel, membership program, business partner, supplier, logistics event, financial impact]
text:
2024年3月,李明决定在杭州开一家咖啡店。他考察了三个地点:学校附近、写字楼商圈、老城区街角。学校附近人流量大,但租金每月高达两万元;写字楼商圈工作日客流稳定,周末冷清;老城区租金低,但年轻客群少。最终李明选择了写字楼商圈,月租一万五千元,签约两年。
------------------------
output:
("entity"<|>张伟<|>person<|>张伟是云南普洱的咖啡豆供应商,负责按月供货。)
##
("entity"<|>云南普洱<|>location<|>云南普洱是张伟供应咖啡豆的来源地。)
##
("entity"<|>咖啡豆<|>product<|>咖啡豆是门店使用的原料,由供应商按月供货,单价为每公斤一百二十元。)
##
("entity"<|>本地乳企<|>supplier<|>本地乳企是牛奶的供应方,负责每日配送给门店。)
##
("entity"<|>牛奶<|>product<|>牛奶是门店使用的原料,由本地乳企每日配送。)
##
("entity"<|>雨季运输延误<|>logistics event<|>雨季运输延误导致门店供应中断,是一次物流异常事件。)
##
("entity"<|>门店断货两天<|>financial impact<|>门店因运输延误出现断货两天的经营影响。)
##
("entity"<|>损失约四千元<|>financial impact<|>门店因断货与运输延误造成约四千元的经济损失。)
##
("entity"<|>李明<|>person<|>李明是门店经营者,因供应与运输问题增加了第二家供应商作为备份。)
##
("entity"<|>第二家供应商<|>supplier<|>第二家供应商是李明新增的备份供货方,用于降低断货风险。)
##
("relationship"<|>张伟<|>云南普洱<|>张伟来自云南普洱,并从该地向门店供应咖啡豆。<|>8)
##
("relationship"<|>张伟<|>咖啡豆<|>张伟负责每月向门店供货咖啡豆。<|>10)
##
("relationship"<|>云南普洱<|>咖啡豆<|>云南普洱是咖啡豆供货来源地。<|>7)
##
("relationship"<|>本地乳企<|>牛奶<|>本地乳企负责向门店每日配送牛奶。<|>10)
##
("relationship"<|>雨季运输延误<|>门店断货两天<|>雨季运输延误直接导致门店断货两天。<|>9)
##
("relationship"<|>门店断货两天<|>损失约四千元<|>门店断货两天进一步造成约四千元的损失。<|>9)
##
("relationship"<|>李明<|>第二家供应商<|>李明增加了第二家供应商作为备份供货渠道。<|>9)
##
("relationship"<|>李明<|>雨季运输延误<|>李明因雨季运输延误带来的问题而调整供应策略。<|>6)
##
("relationship"<|>第二家供应商<|>咖啡豆<|>第二家供应商被李明引入,作为咖啡豆等原料的备份供货方。<|>5)
<|COMPLETE|>
#############################
Example 2:
entity_types: [person, location, business venue, product, pricing, customer segment, promotion, marketing channel, membership program, business partner, supplier, logistics event, financial impact]
text:
李明将核心产品定为拿铁和美式。拿铁定价二十八元,适合大众口味;美式定价二十二元,面向咖啡爱好者。2024年5月,他推出季节限定款桂花拿铁,首月销量占总额的三成。店长王芳建议增加会员折扣,提升复购率。
------------------------
output:
("entity"<|>李明<|>person<|>李明是门店经营者,负责供应链调整,并在出现断货后增加第二家供应商作为备份)
##
("entity"<|>张伟<|>person<|>张伟是来自云南普洱的咖啡豆供应商,负责按月供货,咖啡豆单价为每公斤一百二十元)
##
("entity"<|>云南普洱<|>location<|>云南普洱是咖啡豆供应商张伟所在的供应来源地)
##
("entity"<|>本地乳企<|>business partner<|>本地乳企为门店提供牛奶,并以每日配送方式进行供应合作)
##
("entity"<|>咖啡豆<|>product<|>咖啡豆是门店采购的原料,由张伟每月供货一次,单价为每公斤一百二十元)
##
("entity"<|>牛奶<|>product<|>牛奶是门店采购的原料,由本地乳企每日配送)
##
("entity"<|>一百二十元<|>pricing<|>咖啡豆的单价为每公斤一百二十元)
##
("entity"<|>第二家供应商<|>supplier<|>李明为应对供应风险而增加的备份供应商,用于增强供货保障)
##
("entity"<|>每月供货一次<|>logistics event<|>咖啡豆的供货频率为每月一次,体现为定期配送安排)
##
("entity"<|>每日配送<|>logistics event<|>牛奶采用每日配送方式到店,属于高频物流配送安排)
##
("entity"<|>雨季运输延误<|>logistics event<|>2024年7月因雨季导致的运输延误,直接引发门店断货)
##
("entity"<|>断货两天<|>financial impact<|>门店因运输延误而断货两天,造成经营中断)
##
("entity"<|>损失约四千元<|>financial impact<|>门店因断货与运输延误产生的直接经济损失约四千元)
##
("relationship"<|>李明<|>第二家供应商<|>李明在出现供应风险后增加了第二家供应商作为备份<|>9)
##
("relationship"<|>张伟<|>云南普洱<|>张伟是来自云南普洱的咖啡豆供应商<|>8)
##
("relationship"<|>张伟<|>咖啡豆<|>张伟每月为门店供应咖啡豆<|>10)
##
("relationship"<|>咖啡豆<|>一百二十元<|>咖啡豆的单价为每公斤一百二十元<|>10)
##
("relationship"<|>咖啡豆<|>每月供货一次<|>咖啡豆采用每月一次的供货安排<|>9)
##
("relationship"<|>本地乳企<|>牛奶<|>本地乳企每日为门店配送牛奶<|>10)
##
("relationship"<|>本地乳企<|>每日配送<|>本地乳企与牛奶的供应方式是每日配送<|>9)
##
("relationship"<|>雨季运输延误<|>断货两天<|>雨季运输延误导致门店断货两天<|>10)
##
("relationship"<|>断货两天<|>损失约四千元<|>门店断货两天带来了约四千元的损失<|>9)
##
("relationship"<|>李明<|>损失约四千元<|>李明经营的门店因断货产生约四千元损失<|>8)
<|COMPLETE|>
#############################
-Real Data-
######################
entity_types: [person, location, business venue, product, pricing, customer segment, promotion, marketing channel, membership program, business partner, supplier, logistics event, financial impact]
text: {input_text}
######################
output:
3. 手动调优(Manual Tuning)
手动调优(Manual Tuning)是 GraphRAG 中面向高级用户的提示词定制方式,官方明确将其定位为高级用例,建议多数用户优先使用自动调优。其核心操作是直接以纯文本文件形式编写或修改提示词,通过{input_text}、{entity_types}和{tuple_delimiter} 等占位符控制运行时注入的内容。
用户可针对实体抽取、社区报告生成等环节分别定制,例如为医疗领域定义PATIENT、CONDITION等专属实体类型,并在settings.yaml中引用自定义提示词路径。这种方式适合自动调优效果不理想、或需要精确控制实体类型与输出格式的场景,但要求使用者对GraphRAG的提示词结构和领域知识有较深理解。
不同类型的提示词模板具有不同的占位符,接下来我们从索引和查询两类提示词来介绍每个提示词模板都具有哪些可用的占位符。
3.1 索引类提示词
-
实体/关系抽取
- {input_text}:待处理的输入文本。
- {entity_types}:实体类型列表。
- {tuple_delimiter}:用于分隔元组内各值的分隔符。单个元组用于表示一个实体或一条关系。
- {record_delimiter}:用于分隔各元组实例的分隔符。
- {completion_delimiter}:表示生成完成的指示符。
-
实体/关系描述摘要
- {entity_name}:实体名称,或关系的源/目标对。
- {description_list}:该实体或关系的描述列表。
-
声明抽取
- {input_text}:待处理的输入文本。
- {tuple_delimiter}:用于分隔元组内各值的分隔符。单个元组用于表示一个实体或一条关系。
- {record_delimiter}:用于分隔各元组实例的分隔符。
- {completion_delimiter}:表示生成完成的指示符。
- {entity_specs}:实体类型列表。
- {claim_description}:对声明应是什么样子的描述。默认为Any claims or facts that could be relevant to information discovery.
-
生成社区报告
- {input_text}:用于生成报告的输入文本。其中将包含实体和关系表格。
3.2 查询类提示词
-
Local
- {response_type}:描述响应应呈现的样子。我们默认为
multiple paragraphs。 - {context_data}:GraphRAG 索引中的数据表格。
- {response_type}:描述响应应呈现的样子。我们默认为
-
Global
- {response_type}:描述响应应呈现的样子(仅Reducer)。我们默认为
multiple paragraphs。 - {context_data}:GraphRAG索引中的数据表格。
- {response_type}:描述响应应呈现的样子(仅Reducer)。我们默认为
-
DRIFT
- {response_type}:描述响应应呈现的样子。我们默认为
multiple paragraphs。 - {context_data}:GraphRAG 索引中的数据表格。
- {community_reports}:摘要时应包含的最相关社区报告。
- {query}:注入上下文中的查询文本。
- {response_type}:描述响应应呈现的样子。我们默认为
转载自 CSDN-专业IT技术社区
原文链接:https://blog.csdn.net/JaydenAI/article/details/170241724


![[GraphRAG实现原理-23]提示词优化(Prompt Tuning)封面图](https://i-blog.csdnimg.cn/direct/c4544637926443b3b72f65d8c3eb11ea.png)

