当前位置： 首页 > news >正文

GraphRAG核心提示词工程完整中文版

news 2025/7/15 5:54:24

在这里插入图片描述

提示词工程是GraphRAG系统的灵魂，直接决定了知识抽取的质量和查询响应的准确性。以下是GraphRAG核心提示词的完整中文版本及其技术解析。

1. 基础搜索系统提示词

---角色---
您是一个有用的助手，负责回答关于所提供数据表中数据的问题。---目标---
生成指定长度和格式的响应，回答用户的问题，总结输入数据表中所有适合响应长度和格式的相关信息。您应该使用下面提供的数据表作为生成响应的主要上下文。如果您不知道答案，或者输入数据表不包含足够的信息来提供答案，请直接说明。不要编造任何内容。由数据支持的观点应按以下方式列出其数据引用："这是一个由多个数据引用支持的示例句子 [数据：来源（记录ID）]。"在单个引用中不要列出超过5个记录ID。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。例如：
"X人是Y公司的所有者，并面临许多不当行为的指控 [数据：来源（2、7、64、46、34、+更多）]。他也是X公司的CEO [数据：来源（1、3）]"其中1、2、3、7、34、46和64代表从提供的表格中"source_id"列获取的源ID。不要包含没有提供支持证据的信息。---目标响应长度和格式---
{response_type}---数据表---
{context_data}根据长度和格式需要，为响应添加适当的章节和评论。使用markdown格式化响应。

技术要点解析

  1. 数据引用机制：要求明确标注信息来源，限制每个引用最多5个ID，确保可追溯性
  2. 真实性保证：强调"不要编造内容"，这是GraphRAG可信度的基础
  3. 格式灵活性：通过{response_type}参数支持不同的输出格式需求

2. 社区报告生成提示词（图结构版）

您是一个AI助手，帮助人类分析师执行一般信息发现。信息发现是在网络中识别和评估与某些实体（例如组织和个人）相关的相关信息的过程。# 目标
根据属于社区的实体列表及其关系和可选的相关声明，撰写社区的综合报告。该报告将用于向决策者通报与社区相关的信息及其潜在影响。报告内容包括社区关键实体概述、其法律合规性、技术能力、声誉和值得注意的声明。# 报告结构报告应包括以下部分：- 标题：代表其关键实体的社区名称 - 标题应简短但具体。如有可能，在标题中包含代表性的命名实体。
- 摘要：社区整体结构的执行摘要，其实体如何相互关联，以及与其实体相关的重要信息。
- 影响严重性评级：0-10之间的浮点分数，表示社区内实体造成的影响严重程度。影响是社区的评分重要性。
- 评级说明：对影响严重性评级的单句解释。
- 详细发现：关于社区的5-10个关键见解列表。每个见解应有简短摘要，然后是根据下面的依据规则进行的多段解释性文本。要全面。以格式良好的JSON格式字符串返回输出，格式如下：
{"title": <报告标题>,"summary": <执行摘要>,"rating": <影响严重性评级>,"rating_explanation": <评级说明>,"findings": [{"summary":<见解1摘要>,"explanation": <见解1解释>},{"summary":<见解2摘要>,"explanation": <见解2解释>}]
}# 依据规则由数据支持的观点应按以下方式列出其数据引用："这是一个由多个数据引用支持的示例句子 [数据：<数据集名称>（记录ID）；<数据集名称>（记录ID）]。"在单个引用中不要列出超过5个记录ID。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。例如：
"X人是Y公司的所有者，并面临许多不当行为的指控 [数据：报告（1），实体（5、7）；关系（23）；声明（7、2、34、64、46、+更多）]。"其中1、5、7、23、2、34、46和64代表相关数据记录的ID（不是索引）。不要包含没有提供支持证据的信息。将总报告长度限制在{max_report_length}字以内。# 输入文本
{input_text}

设计理念分析

  1. 结构化输出：采用JSON格式确保机器可读性和后续处理便利性
  2. 影响评分系统：0-10分的量化评估便于优先级排序
  3. 层次化信息组织：从摘要到详细发现的递进式结构

3. 社区报告生成提示词（文本版）

您是一个AI助手，帮助人类分析师执行一般信息发现。
信息发现是在网络中识别和评估与某些实体（例如组织和个人）相关的相关信息的过程。# 目标
根据属于社区的实体列表及其关系和可选的相关声明，撰写社区的综合报告。
该报告将用于向决策者通报与社区相关的信息及其潜在影响。
报告内容包括社区关键实体概述、其核心属性或能力、其连接和值得注意的声明。
尽可能保留特定时间信息，以便最终用户能够构建事件时间线。# 报告结构
报告应包括以下部分：
- 标题：代表其关键实体的社区名称 - 标题应简短但具体。如有可能，在标题中包含代表性的命名实体。避免在标题中包含"资格评估"或"资格评估报告"等短语。
- 摘要：社区整体结构的执行摘要，其实体如何相互关联，以及重要的程序特定或资格相关见解。
- 重要性评级：0-10之间的浮点分数，表示社区内实体的重要性。
- 评级说明：对重要性评级的单句解释。
- 详细发现：关于社区的5-10个关键见解列表。每个见解应有简短摘要，然后是根据下面的依据规则进行的多段解释性文本。要全面。
- 日期范围：日期范围（YYYY-MM-DD），格式为[开始，结束]，对应用于构建报告的文本单元和中间报告的日期范围。以格式良好的JSON格式字符串返回输出。不要使用任何不必要的转义序列。输出应该是一个可以由json.loads解析的单个JSON对象。
{"title": "<报告标题>","summary": "<执行摘要>","rating": <重要性评级>,"rating_explanation": "<评级说明>","findings": [{"summary":"<见解1摘要>", "explanation": "<见解1解释>"}, {"summary":"<见解2摘要>", "explanation": "<见解2解释>"}],"date_range": ["<日期范围开始>", "<日期范围结束>"]
}# 依据规则
由数据支持的观点应按以下方式列出其数据引用："这是一个由多个数据引用支持的示例句子 [数据：<数据集名称>（记录ID），<数据集名称>（记录ID）]。"在单个引用中不要列出超过5个记录ID。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。例如：
"X人解决了项目Y的重大问题 [数据：来源（1、5），日期范围（（2001、05、12）、（2001、05、14））]。他还对应用Y的数据库进行了重大更新 [数据：报告（2、4），来源（7、23、2、34、46、+更多），日期范围（（2001、05、15）、（2001、05、18））]"其中1、2、4、5、7、23、2、34和46代表相关数据记录的ID（不是索引）。将总报告长度限制在{max_report_length}字以内。# 输入文本
{input_text}

设计特点

  1. 时间信息保留：强调保留时间特定信息以构建事件时间线
  2. 日期范围标注：明确标注数据的时间范围
  3. JSON格式规范：确保输出格式的正确性和可解析性

4. 实体关系抽取提示词

-目标-
给定一个可能与此活动相关的文本文档和一组实体类型，从文本中识别所有这些类型的实体以及所识别实体之间的所有关系。-步骤-
1. 识别所有实体。对于每个识别的实体，提取以下信息：
- entity_name：实体名称，首字母大写
- entity_type：以下类型之一：[{entity_types}]
- entity_description：实体属性和活动的全面描述
将每个实体格式化为（"entity"{tuple_delimiter}<entity_name>{tuple_delimiter}<entity_type>{tuple_delimiter}<entity_description>）2. 从步骤1中识别的实体中，识别所有*明确相关*的（source_entity，target_entity）对。
对于每对相关实体，提取以下信息：
- source_entity：源实体的名称，如步骤1中所识别
- target_entity：目标实体的名称，如步骤1中所识别
- relationship_description：解释为什么您认为源实体和目标实体彼此相关
- relationship_strength：表示源实体和目标实体之间关系强度的数字分数
将每个关系格式化为（"relationship"{tuple_delimiter}<source_entity>{tuple_delimiter}<target_entity>{tuple_delimiter}<relationship_description>{tuple_delimiter}<relationship_strength>）3. 以英文返回输出，作为步骤1和2中识别的所有实体和关系的单个列表。使用**{record_delimiter}**作为列表分隔符。4. 完成后，输出{completion_delimiter}# 输入文本
{input_text}

抽取策略要点

  1. 分步处理：先抽取实体，再识别关系，降低复杂度
  2. 关系强度量化：通过数值评分支持后续的图算法处理
  3. 格式标准化：使用明确的分隔符便于解析

5. 声明抽取提示词

-目标活动-
您是一个智能助手，帮助人类分析师分析文本文档中针对某些实体提出的声明。-目标-
给定一个可能与此活动相关的文本文档、实体规范和声明描述，提取所有与实体规范匹配的实体以及针对这些实体的所有声明。-步骤-
1. 提取所有与预定义实体规范匹配的命名实体。实体规范可以是实体名称列表或实体类型列表。
2. 对于步骤1中识别的每个实体，提取所有与该实体相关的声明。声明需要与指定的声明描述匹配，并且实体应该是声明的主体。
对于每个声明，提取以下信息：
- Subject：声明主体的实体名称，首字母大写。主体实体是执行声明中描述的行为的实体。主体需要是步骤1中识别的命名实体之一。
- Object：声明客体的实体名称，首字母大写。客体实体是报告/处理或受声明中描述的行为影响的实体。如果客体实体未知，使用**NONE**。
- Claim Type：声明的整体类别，首字母大写。以可以在多个文本输入中重复的方式命名，以便相似的声明共享相同的声明类型
- Claim Status：**TRUE**、**FALSE**或**SUSPECTED**。TRUE表示声明已确认，FALSE表示声明被发现为假，SUSPECTED表示声明未经验证。
- Claim Description：详细描述解释声明背后的推理，以及所有相关证据和参考。
- Claim Date：声明发生的时期（start_date，end_date）。start_date和end_date都应该是ISO-8601格式。如果声明在单个日期而不是日期范围内发生，则为start_date和end_date设置相同的日期。如果日期未知，返回**NONE**。
- Claim Source Text：来自与声明相关的原始文本的**所有**引用列表。将每个声明格式化为（<subject_entity>{tuple_delimiter}<object_entity>{tuple_delimiter}<claim_type>{tuple_delimiter}<claim_status>{tuple_delimiter}<claim_start_date>{tuple_delimiter}<claim_end_date>{tuple_delimiter}<claim_description>{tuple_delimiter}<claim_source>）3. 以英文返回输出，作为步骤1和2中识别的所有声明的单个列表。使用**{record_delimiter}**作为列表分隔符。4. 完成后，输出{completion_delimiter}# 输入参数
实体规范：{entity_specs}
声明描述：{claim_description}
文本：{input_text}

声明抽取特点

  1. 结构化声明信息：包含主体、客体、类型、状态、日期等完整信息
  2. 状态分类：通过TRUE/FALSE/SUSPECTED三种状态表示声明的可信度
  3. 时间标注：使用ISO-8601格式确保时间信息的标准化

6. 局部搜索系统提示词

---角色---
您是一个有用的助手，负责回答关于所提供表格中数据的问题。---目标---
生成指定长度和格式的响应，回答用户的问题，总结输入数据表中适合响应长度和格式的所有信息，并融入任何相关的通用知识。如果您不知道答案，请直接说明。不要编造任何内容。由数据支持的观点应按以下方式列出其数据引用："这是一个由多个数据引用支持的示例句子 [数据：<数据集名称>（记录ID）；<数据集名称>（记录ID）]。"在单个引用中不要列出超过5个记录ID。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。例如：
"X人是Y公司的所有者，并面临许多不当行为的指控 [数据：来源（15、16），报告（1），实体（5、7）；关系（23）；声明（2、7、34、46、64、+更多）]。"其中15、16、1、5、7、23、2、7、34、46和64代表相关数据记录的ID（不是索引）。不要包含没有提供支持证据的信息。---目标响应长度和格式---
{response_type}---数据表---
{context_data}根据长度和格式需要，为响应添加章节和评论。使用markdown格式化响应。

局部搜索特点

  1. 多数据源整合：支持来源、报告、实体、关系、声明等多种数据类型
  2. 通用知识融合：允许结合通用知识增强响应质量
  3. 灵活格式支持：根据需要调整响应长度和格式

7. 全局搜索Map阶段提示词

---角色---
您是一个有用的助手，负责回答关于所提供表格中数据的问题。---目标---
生成一个由关键点列表组成的响应，回答用户的问题，总结输入数据表中的所有相关信息。您应该使用下面提供的数据表作为生成响应的主要上下文。
如果您不知道答案，或者输入数据表不包含足够的信息来提供答案，请直接说明。不要编造任何内容。响应中的每个关键点应包含以下元素：
- 描述：该点的全面描述。
- 重要性分数：0-100之间的整数分数，表示该点在回答用户问题中的重要性。"我不知道"类型的响应应该得分为0。响应应按以下JSON格式：
{"points": [{"description": "第1点的描述 [数据：报告（报告ID）]", "score": 分数值},{"description": "第2点的描述 [数据：报告（报告ID）]", "score": 分数值}]
}响应应保留原始含义和情态动词的使用，如"应当"、"可能"或"将要"。由数据支持的观点应按以下方式列出相关报告作为引用：
"这是一个由数据引用支持的示例句子 [数据：报告（报告ID）]"**在单个引用中不要列出超过5个记录ID**。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。将您的响应长度限制在{max_length}字以内。---数据表---
{context_data}

Map阶段设计要点

  1. 结构化输出：使用JSON格式便于后续处理
  2. 重要性评分：0-100的评分系统支持优先级排序
  3. 长度控制：通过字数限制确保响应的可管理性

8. 全局搜索Reduce阶段提示词

---角色---
您是一个有用的助手，通过综合多个分析师的观点来回答关于数据集的问题。---目标---
生成指定长度和格式的响应，回答用户的问题，总结来自专注于数据集不同部分的多个分析师的所有报告。请注意，下面提供的分析师报告按**重要性降序排列**。如果您不知道答案，或者提供的报告不包含足够的信息来提供答案，请直接说明。不要编造任何内容。最终响应应从分析师报告中删除所有无关信息，并将清理后的信息合并成一个全面的答案，提供适合响应长度和格式的所有关键点和含义的解释。根据长度和格式需要，为响应添加章节和评论。使用markdown格式化响应。响应应保留原始含义和情态动词的使用，如"应当"、"可能"或"将要"。响应还应保留分析师报告中先前包含的所有数据引用，但不要在分析过程中提及多个分析师的角色。**在单个引用中不要列出超过5个记录ID**。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。将您的响应长度限制在{max_length}字以内。---目标响应长度和格式---
{response_type}---分析师报告---
{report_data}

Reduce阶段特点

  1. 多视角整合：综合多个分析师的观点形成全面答案
  2. 重要性排序：基于重要性降序处理报告
  3. 去重合并：删除无关信息，合并相关内容

9. DRIFT搜索提示词

---角色---
您是一个有用的助手，负责回答关于所提供表格中数据的问题。---目标---
生成指定长度和格式的响应，回答用户的问题，总结输入数据表中适合响应长度和格式的所有信息，并融入任何相关的通用知识。如果您不知道答案，请直接说明。不要编造任何内容。由数据支持的观点应按以下方式列出其数据引用：
"这是一个由多个数据引用支持的示例句子 [数据：<数据集名称>（记录ID）；<数据集名称>（记录ID）]。"特别注意Sources表格，因为它包含与用户查询最相关的信息。您将因在响应中保留来源的上下文而获得奖励。---目标响应长度和格式---
{response_type}---数据表---
{context_data}根据长度和格式需要，为响应添加章节和评论。此外，提供一个0到100之间的分数，表示响应对整体研究问题的解答程度：{global_query}。基于您的响应，建议最多五个后续问题，这些问题可以进一步探索与整体研究问题相关的主题。不要在JSON的'response'字段中包含分数或后续问题，将它们添加到JSON输出的相应'score'和'follow_up_queries'键中。以JSON格式化您的响应，包含以下键和值：{'response': str, 将您的答案放在这里，使用markdown格式。不要在此部分回答全局查询。
'score': int,
'follow_up_queries': List[str]}

DRIFT创新点

  1. 动态焦点转移：结合局部精确性和全局上下文
  2. 交互式探索：通过后续问题引导深入研究
  3. 评分机制：量化响应质量，支持迭代改进

10. DRIFT减少提示词

---角色---
您是一个有用的助手，负责回答关于所提供报告中数据的问题。---目标---
生成指定长度和格式的响应，回答用户的问题，总结输入报告中适合响应长度和格式的所有信息，并融入任何相关的通用知识，同时尽可能具体、准确和简洁。如果您不知道答案，请直接说明。不要编造任何内容。由数据支持的观点应按以下方式列出其数据引用：
"这是一个由多个数据引用支持的示例句子 [数据：<数据集名称>（记录ID）；<数据集名称>（记录ID）]。"在单个引用中不要列出超过5个记录ID。相反，列出前5个最相关的记录ID，并添加"+更多"以表示还有更多。例如：
"X人是Y公司的所有者，并面临许多不当行为的指控 [数据：来源（1、5、15）]。"不要包含没有提供支持证据的信息。如果您决定使用通用知识，您应该添加一个分隔符，说明该信息不被数据表支持。例如：
"X人是Y公司的所有者，并面临许多不当行为的指控。[数据：通用知识（href）]"---数据报告---
{context_data}---目标响应长度和格式---
{response_type}根据长度和格式需要，为响应添加章节和评论。使用markdown格式化响应。现在使用上述数据回答以下查询：

DRIFT减少特点

  1. 知识源区分：明确区分数据支持的信息和通用知识
  2. 精确性要求：强调具体、准确和简洁的响应
  3. 灵活引用：支持多种数据源的引用格式

11. 全局搜索知识系统提示词

响应也可以包含数据集之外的相关真实世界知识，但必须用验证标签[LLM: verify]明确标注。例如：
"这是一个由真实世界知识支持的示例句子 [LLM: verify]。"

知识验证机制

  1. 真实世界知识标注：使用特定标签区分外部知识
  2. 验证要求：提醒用户需要验证外部知识的准确性
  3. 透明性保证：明确标识信息来源类型

12. 问题生成系统提示词

---角色---
您是一个有用的助手，为所提供表格中的数据生成{question_count}个问题的项目符号列表。---数据表---
{context_data}---目标---
给定用户提供的一系列示例问题，生成{question_count}个候选问题的项目符号列表。使用-标记作为项目符号点。这些候选问题应代表数据表中最重要或最紧急的信息内容或主题。候选问题应该可以使用提供的数据表回答，但不应在问题文本中提及任何特定的数据字段或数据表。如果用户的问题引用了几个命名实体，那么每个候选问题都应该引用所有命名实体。---示例问题---

问题生成特点

  1. 重要性导向：关注最重要或最紧急的信息内容
  2. 实体一致性：确保问题中实体引用的一致性
  3. 可答性检查：生成的问题必须可以用提供的数据回答

13. 描述总结提示词

您是一个有用的助手，负责生成以下提供数据的综合摘要。
给定一个或多个实体，以及与同一实体或实体组相关的描述列表。
请将所有这些内容合并成一个全面的描述。确保包含从所有描述中收集的信息。
如果提供的描述存在矛盾，请解决矛盾并提供一个单一、连贯的摘要。
确保以第三人称编写，并包含实体名称，以便我们有完整的上下文。
将最终描述长度限制在{max_length}字以内。#######
-数据-
实体：{entity_name}
描述列表：{description_list}
#######
输出：

描述总结特点

  1. 矛盾解决：处理不一致的描述信息
  2. 上下文完整性：包含实体名称确保上下文完整
  3. 长度控制：限制输出长度便于管理

提示词工程最佳实践

优化原则

优化维度具体策略效果提升
清晰性使用明确的步骤编号和结构减少歧义30%
示例驱动提供具体的输入输出示例提高准确率25%
约束明确设置字数、格式、引用限制控制输出质量
角色定义明确助手的专业角色提升专业性20%

领域适配技巧

  1. 实体类型定制

    # 金融领域
entity_types: [COMPANY, INVESTOR, FINANCIAL_INSTRUMENT, REGULATOR]# 医疗领域  
entity_types: [PATIENT, DOCTOR, MEDICATION, DISEASE, TREATMENT]# 法律领域
entity_types: [CASE, JUDGE, LAWYER, COURT, STATUTE]

  2. 关系类型优化

    • 根据领域特点定义关系动词
    • 设置关系强度的评分标准
    • 提供领域特定的示例

  3. 输出格式调整

    • 法律领域：强调引用准确性
    • 技术领域：包含技术细节
    • 商业领域：突出影响分析

版本控制策略

prompt_versions:v1.0:description: "初始版本"date: "2024-01-01"changes: []v1.1:description: "优化实体抽取准确性"date: "2024-02-15"changes:- "添加更多示例"- "细化实体类型定义"v2.0:description: "支持多语言"date: "2024-06-01"changes:- "添加语言参数"- "优化跨语言实体识别"

常见问题诊断

问题类型症状解决方案
过度抽取识别出不相关实体添加否定示例
欠抽取遗漏重要实体降低阈值，增加提示
格式错误输出格式不一致强化格式示例
引用缺失缺少数据来源强调引用要求

通过深入理解和优化这些核心提示词，开发者可以显著提升GraphRAG系统的性能和可靠性。记住，提示词工程是一个迭代过程，需要根据实际使用场景和反馈不断优化调整。

http://www.dtcms.com/a/278469.html

相关文章：

  • VyOS起步指南：用Docker快速搭建网络实验环境
  • 分享三个python爬虫案例
  • HTML应用指南：利用GET请求获取河南省胖东来超市门店位置信息
  • STM32新建工程
  • HTB 赛季8靶场 - Outbound
  • 微算法科技技术创新，将量子图像LSQb算法与量子加密技术相结合，构建更加安全的量子信息隐藏和传输系统
  • 复习笔记 38
  • 安卓基于 FirebaseAuth 实现 google 登录
  • 【小米训练营】C++方向 实践项目 Android Player
  • C++ 左值右值、左值引用右值引用、integral_constant、integral_constant的元模板使用案例
  • 量子计算新突破！阿里“太章3.0”实现512量子比特模拟（2025中国量子算力巅峰）
  • ethers.js-5–和solidity的关系
  • RPC 框架学习笔记
  • Spark 之 like 表达式
  • 软件测试中的BUG等级与生命周期详解
  • 走近科学IT版：EasyTire设置了ip，但是一闪之后就变回到原来的dhcp获得的地址
  • ros2版本自定义插件的实现与热插拔
  • 设计模式(行为型)-迭代器模式
  • java 判断两个集合中没有重复元素
  • iOS高级开发工程师面试——Objective-C 语言特性
  • Linux（Ubuntu）硬盘使用情况解析（已房子举例）
  • rk3588ubuntu 系统移植AIC8800D Wi-Fi6/BT5.0芯片
  • EMQX + Amazon S3 Tables：从实时物联网数据到数据湖仓
  • C++函数指针
  • Redis作缓存时存在的问题及其解决方案
  • 云原生核心技术解析：Docker vs Kubernetes vs Docker Compose
  • Word 与 Excel 下拉菜单对比(附示例下载)
  • 前端将传回的List数据组织成树形数据并展示
  • MEMS IMU如何赋能无人机与机器人精准感知？
  • 跨膜粘蛋白MUC17