改进你的提示工程
Posted on Sat 07 September 2024 in Journal
Abstract | 改进你的提示工程 |
---|---|
Authors | Walter Fan |
Category | learning note |
Status | v1.0 |
Updated | 2024-09-07 |
License | CC-BY-NC-ND 4.0 |
提示工程在 ChatGPT(Generative Pre-trained Transformer 生成式预训练变换模型) 出现之前, 就已经存在了, 但是籍籍无名, 随着 ChatGPT 的出现, 才让提示工程又火了一把.
GPT 通过计算大量数据中的概率分布, 来预测下一个词, 从而生成文本. 但是, 如果给 GPT 一个提示词, 它就会生成一个符合提示词的文本. 提示词就是提示工程的核心.
Pre-trained 预训练是指在训练特定任务之前,让模型先学习大量的无标签数据(无监督学习),以获得对语言的初步理解。这个过程通常使用大量的文本数据,如维基百科文章、新闻文章、书籍等。
Transformer 变换器是一种深度学习模型,用于处理序列数据,如自然语言文本。它由编码器(Encoder)和解码器(Decoder)两部分组成。它使用自注意机制来处理序列数据. 所谓自注意机制, 就是让模型在处理序列的每个元素时, 不仅考虑当前元素,还考虑序列中的其他元素,以捕捉序列中的依赖关系。
ChatGPT 是 GPT 的一个变体,它专门用于对话生成任务。它使用 Transformer 架构,并经过大量对话数据的训练,使其能够生成连贯、有逻辑的对话。可是要实际应用的时候, 我们会发现它有时候会胡说八道, 这种现象叫做幻觉.
提示指的是用户向人工智能提供的输入的信息,通常包含关键词, 问题或指令, 以引导模型生成特定类型的输出。提示可以是文本、图像或其他形式的信息,用于指导模型生成符合用户期望的响应。提示通常用于与人工智能模型进行交互,以获取特定类型的输出。
而提示工程是指通过精心设计和优化过的输入信息, 来引导大语言模型生成高质量,准确,有针对性的回应。提示工程的目标是提高模型的性能、准确性和用户体验。
在 2022 的一篇论文 "Let's think step by step: Using language models for commonsense reasoning" 中, 作者提出了一种叫做 "思维链" 的提示词, 它能够引导 GPT 模型进行逻辑推理, 从而生成更准确, 更符合人类思维的答案. 它将 GPT-3在一个数学题库上的正确率从 17.7% 提高到了 78.7%, 大约提高了 4.5 倍.
提示工程框架
CRISPE和BROKE是两种不同的提示词(Prompt)框架,它们用于指导用户如何更有效地与人工智能模型进行交流,以获得更准确和有用的回答。 这两种框架都是为了提高与AI交互的效率和质量,但它们的侧重点和应用场景可能有所不同。CRISPE框架更注重于角色扮演和个性化互动,而BROKE框架则强调了任务的背景、角色、目标、关键输出和持续改进
CRISPE 框架
CRISPE框架由以下五个部分组成:
- Capacity and Role(角色):设定AI的角色,使其能够更好地理解问题背景。
- Insight(洞察):提供背景信息和上下文,帮助AI更好地理解问题。
- Statement(声明):明确地陈述问题或需求,让AI知道期望得到的答案类型。
- Personality(个性):设定回答问题的语言风格或结构。
- Experiment(实验):如果问题较宽泛,可以要求AI提供多个答案或建议。
CRISPE框架的例子:
假设你是一名计划去欧洲旅行的用户,想要使用AI来规划旅行路线。
Capacity and Role: 旅行顾问
Insight: 我和我的家人计划在暑假期间去欧洲旅行,我们有大约两周的时间。我们希望游览一些著名的历史景点和文化名胜,同时也享受美食和购物。
Statement: 请根据我们的需求,为我们规划一条合适的欧洲旅行线路,并推荐一些必游景点。
Personality: 请用详细且具有吸引力的描述来回答,让我们对旅行充满期待。
Experiment: 如果可能,请提供至少两个不同的旅行线路供我们选择。
在这个例子中,CRISPE框架帮助用户清晰地向AI描述了他们的需求,并设定了AI的角色,提供了背景信息,明确了问题声明,指定了回答的个性,并且要求AI提供多个选项进行选择。
BROKE 框架
BROKE 框架是指:
- Background(背景):说明背景,提供充足信息。
- Role(角色):设定AI的角色。
- Objectives(目标/任务):描述AI需要完成的任务。
- Key Result(关键结果):定义AI输出的回答在风格、格式、内容等方面的要求。
- Evolve(改进):在AI给出回答后,提出三种调整、改进方法。
BROKE框架的例子:
假设你是一名项目经理,需要AI帮助制定一个软件开发项目的计划。
Background: 我们正在启动一个新的软件开发项目,目标是为中小企业提供一款高效的财务管理工具。项目团队由5名开发人员、2名设计师、1名测试工程师和1名产品经理组成。
Role: 我希望你扮演一名经验丰富的项目经理。
Objectives: 请帮助我们制定一个详细的项目计划,包括项目的各个阶段、关键里程碑、资源分配和风险管理。
Key Result: 项目计划应以Gantt图的形式呈现,并包括每个任务的开始和结束日期、负责人和依赖关系。确保项目计划考虑到所有潜在的风险,并为每个风险提供了相应的应对策略。
Evolve: 在项目计划制定完成后,请提供一个反馈机制,以便团队成员可以提出他们的建议和改进意见。根据团队的反馈和项目进展,每两周对项目计划进行一次迭代和更新。
在这个例子中,BROKE框架让用户为AI提供了项目的背景信息,设定了AI的角色,明确了项目目标,定义了关键结果,并且提出了项目计划制定后的改进和迭代机制。这样的结构化方法有助于确保项目计划的全面性和实用性。
提示工程技巧
- 使用文本分隔符分割指令和上下文
- 使用标记语言 markdown 来标记输入格式
- 使用有序列表与无序列表列出不同的条目
- 量化你的要求
- 不要说"我不想要什么", 而要说"我想要什么"
- 利用 ChatGPT 的接龙补全功能引导下一步的动作
- 使用 ChatGPT 的上下文功能, 将之前的对话作为上下文, 保持对话主题的连贯性
- 使用 ChatGPT 的相关插件, 例如 Chat with Browsing, Chat with PDF, etc.
提示工程的最佳实践
When choosing the model to work with, the latest and most capable models are likely to perform better. Start with a simple and short prompt, and iterate from there. Put the instructions at the beginning of the prompt, or at the very end. When working with large context, models apply various optimizations to prevent Attention complexity from scaling quadratically. This may make a model more attentive to the beginning or end of a prompt than the middle. Clearly separate instructions from the text they apply to > more on this in the next section. Be specific and descriptive about the task and the desired outcome > its format, length, style, language, etc. Avoid ambiguous descriptions and instructions. Favor instructions that say “what to do” instead of those that say “what not to do”. “Lead” the output in the right direction by writing the first word (or even begin the first sentence for the model). Use advanced techniques like Few-shot prompting and Chain-of-thought Test your prompts with different models to assess their robustness. Version and track the performance of your prompts.
- 在选择使用的模型时,最新、功能最强大的模型可能会表现更好。
- 从一个简单而简短的提示开始,然后从那里进行迭代。
- 将说明放在提示的开头或结尾。处理大上下文时,模型会应用各种优化来防止注意力复杂度呈二次方增长。这可能会使模型更关注提示的开头或结尾,而不是中间部分。
- 将指令与其适用的文本明确分开。
- 具体描述任务和期望结果 - 其格式、长度、风格、语言等。
- 避免使用含糊不清的描述和说明。
- 倾向于使用“应该做什么”的指示,而不是“不应该做什么”的指示。
- 通过写下第一个单词(甚至是开始模型的第一个句子)来“引导”输出朝正确的方向发展。
- 使用少量提示和思维链等高级技巧
- 使用不同的模型测试您的提示以评估其稳健性。
- 对提示进行版本控制并跟踪其性能。
示例
Prompt Example 1
Question: 你是一个被设计用来执行文本摘要和总结的助手. 你将获得一段文本, 你的任务是总结这段文本的主要内容, 从原始文本中提取其主旨和关键信息, 并将其以简明扼要的方式呈现. 请确保你的总结准确地反映了原始文本的主要观点和信息. 请注意, 你的总结应该简洁明了, 避免冗长的描述.
请在总结摘要中列出对原文的引用, 也就是形成摘要的依据, 请用中文开始对下面文本的总结摘要:
In Pydantic, the term "validation" refers to the process of instantiating a model (or other type) that adheres to specified types and constraints. Pydantic guarantees the types and constraints of the output, not the input data. This distinction becomes apparent when considering that Pydantic's ValidationError is raised when data cannot be successfully parsed into a model instance.
While this distinction may initially seem subtle, it holds practical significance. In some cases, "validation" goes beyond just model creation, and can include the copying and coercion of data. This can involve copying arguments passed to the constructor in order to perform coercion to a new type without mutating the original input data. For a more in-depth understanding of the implications for your usage, refer to the Data Conversion and Attribute Copies sections below.
In essence, Pydantic's primary goal is to assure that the resulting structure post-processing (termed "validation") precisely conforms to the applied type hints. Given the widespread adoption of "validation" as the colloquial term for this process, we will consistently use it in our documentation.
While the terms "parse" and "validation" were previously used interchangeably, moving forward, we aim to exclusively employ "validate", with "parse" reserved specifically for discussions related to JSON parsing.
Answer:
总结: - Pydantic中的“验证”是指创建一个符合指定类型和约束的模型实例的过程。这个过程确保输出数据的类型和约束,而不是输入数据。 - Pydantic在数据不能成功解析为模型实例时会抛出ValidationError。 - “验证”可能包括数据的复制和强制类型转换,这可能涉及复制构造函数的参数以执行类型强制转换,而不改变原始输入数据。 - Pydantic的主要目标是确保处理后的结构(称为“验证”)精确符合应用的类型提示。 - 为了避免混淆,“解析”和“验证”这两个术语将不再互换使用,未来将专门使用“验证”,而“解析”将专门用于讨论与JSON解析相关的内容。
原文引用: - "Pydantic guarantees the types and constraints of the output, not the input data." - "Pydantic's ValidationError is raised when data cannot be successfully parsed into a model instance." - "validation" goes beyond just model creation, and can include the copying and coercion of data. - "Pydantic's primary goal is to assure that the resulting structure post-processing (termed 'validation') precisely conforms to the applied type hints." - "While the terms 'parse' and 'validation' were previously used interchangeably, moving forward, we aim to exclusively employ 'validate', with 'parse' reserved specifically for discussions related to JSON parsing."
Prompt Example 2
Question: 你是一个经验丰富的项目经理, 请帮助我制定一个详细的项目计划, 包括项目的各个阶段, 关键里程碑, 资源分配和风险管理. 项目计划应以Gantt图的形式呈现, 并包括每个任务的开始和结束日期, 负责人和依赖关系. 确保项目计划考虑到所有潜在的风险, 并为每个风险提供了相应的应对策略. 在项目计划制定完成后, 请提供一个反馈机制, 以便团队成员可以提出他们的建议和改进意见. 根据团队的反馈和项目进展, 每两周对项目计划进行一次迭代和更新.
项目概况:
在 3 个月内完成一个项目, 项目的目标是为中学生提供一款高效的数学知识学习工具, 既能引导学生循序渐进地学习数学知识, 也能智能出题, 分析和解答. 项目团队由 5 名开发人员, 2 名设计师, 1 名测试工程师和 1 名产品经理组成.
Answer:
为了制定一个详细的项目计划,我们将遵循以下步骤:
- 项目启动
- 需求收集与分析
- 设计
- 开发
- 测试
- 部署
- 维护与反馈
1. 项目启动
- 目标: 确立项目目标、范围和初步计划。
- 关键里程碑: 项目启动会议。
- 资源分配: 项目经理、产品经理。
- 风险管理: 确定项目范围,避免后期需求蔓延。
2. 需求收集与分析
- 目标: 收集用户需求,定义产品功能。
- 关键里程碑: 需求文档完成。
- 资源分配: 产品经理、设计师。
- 风险管理: 需求变更管理,确保需求的可实现性。
3. 设计
- 目标: 设计产品界面和用户体验。
- 关键里程碑: 设计稿完成。
- 资源分配: 设计师。
- 风险管理: 设计与需求不符,进行迭代。
4. 开发
- 目标: 根据设计稿开发产品。
- 关键里程碑: 各功能模块开发完成。
- 资源分配: 开发人员。
- 风险管理: 技术难题,代码质量控制。
5. 测试
- 目标: 测试产品功能,确保产品质量。
- 关键里程碑: 测试报告完成。
- 资源分配: 测试工程师。
- 风险管理: 发现的缺陷,测试覆盖率不足。
6. 部署
- 目标: 将产品部署到生产环境。
- 关键里程碑: 产品上线。
- 资源分配: 开发人员、测试工程师。
- 风险管理: 部署失败,回滚计划。
7. 维护与反馈
- 目标: 收集用户反馈,进行产品维护。
- 关键里程碑: 反馈收集和产品迭代。
- 资源分配: 产品经理、开发人员。
- 风险管理: 用户反馈处理不及时。
Gantt图
由于我无法直接生成图表,我将提供一个Gantt图的文本描述,你可以使用项目管理软件如Microsoft Project或在线工具如Trello来创建实际的Gantt图。
+-----------------+------------+------------+------------+------------+
| 任务 | 开始日期 | 结束日期 | 负责人 | 依赖关系 |
+-----------------+------------+------------+------------+------------+
| 项目启动 | 2024-09-12 | 2024-09-14 | 项目经理 | |
| 需求收集 | 2024-09-15 | 2024-09-22 | 产品经理 | 项目启动 |
| 设计 | 2024-09-23 | 2024-10-06 | 设计师 | 需求收集 |
| 开发 - 功能A | 2024-10-07 | 2024-10-21 | 开发人员A | 设计 |
| 开发 - 功能B | 2024-10-07 | 2024-10-21 | 开发人员B | 设计 |
| ... | ... | ... | ... | ... |
| 测试 | 2024-10-22 | 2024-11-04 | 测试工程师 | 开发 |
| 部署 | 2024-11-05 | 2024-11-07 | 开发人员 | 测试 |
| 维护与反馈 | 2024-11-08 | 2024-12-09 | 产品经理 | 部署 |
+-----------------+------------+------------+------------+------------+
风险管理
- 技术难题: 定期技术评审,引入专家咨询。
- 需求变更: 建立变更管理流程,评估变更影响。
- 时间管理: 使用敏捷方法,定期检查进度。
反馈机制
- 方法: 使用项目管理工具的反馈功能,定期会议。
- 频率: 每两周一次。
迭代更新
- 频率: 每两周一次。
- 方法: 根据反馈和项目进展调整计划。
请根据实际情况调整上述计划,并使用项目管理工具创建详细的Gantt图。记得在项目过程中保持沟通和透明度,确保所有团队成员都对项目进度和计划有清晰的了解。
参考文章
- https://huggingface.co/docs/transformers/en/tasks/prompting
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。