应该做和不应该做

提示工程 (Prompt Engineering) - 应该做和不应该做

有效的提示工程 (Prompt Engineering) 是发挥大语言模型 (LLM, Large Language Models) 最佳性能、确保它们生成上下文相关、准确且有用响应的关键。本章概述了提示工程师在设计有效提示和实现预期结果时应遵循的基本原则。

提示工程的“应该做” (Do’s)

• 做到清晰具体： 明确阐述任务、期望的输出格式以及任何约束。你的指令越精确，LLM 就越能理解并满足你的请求。
• 提供充足的上下文： 如果任务需要背景信息、领域知识或之前的对话轮次，请将其包含在提示中，或确保模型能够访问这些信息。
• 使用角色提示或人设 (Personas)： 指导 LLM 扮演特定的角色或人设（例如，“你是一位专业的生物学家”，“扮演旅行向导”）来塑造其响应的语气、风格和专业性。
• 分解复杂任务： 对于多步骤或复杂的问题，通过将任务分解为更小的、易于管理的步骤来指导 LLM。思维链 (Chain-of-Thought, CoT) 等技术在这里会非常有效。
• 使用示例（少样本提示 Few-Shot Prompting）： 对于细微或需要特定输出格式的任务，在提示中提供一些示例（输入/输出对），以演示你期望的结果。
• 提供结构和格式： 在提示中使用清晰的分隔符（例如 ###、```、XML 标签）、标题或列表，帮助 LLM 理解指令的不同部分，并要求输出结构化的内容。
• 迭代和优化： 提示工程是一个迭代过程。从简单的开始，进行测试，分析输出，然后优化你的提示。保留不同版本的提示，并跟踪哪种效果最好。
• 试验模型参数： 结合你的提示，调整推理参数，如 temperature（用于控制创意性与事实性）、top_p、max_tokens 等，以微调输出。
• 考虑输出的目标受众： 调整提示，使其生成的响应适合预期最终用户的语言、知识水平和偏好。
• 监测和评估性能： 定期根据一组既定的标准或评估套件测试你的提示，以确保它们持续产生高质量的结果。

提示工程的“不应该做” (Don’ts)

• 不要使用含糊不清或模糊的语言： 避免容易产生多种解释的提示，这可能导致响应不一致或不相关。
• 不要过度泛化提示： 如果你需要一个具体的答案，不要提出一个非常宽泛的问题。这可能导致模型提供通用或无用的信息。
• 不要嵌入带有偏见或有害的假设的语言： 注意你在提示中使用的语言。避免强化刻板印象或引入模型可能复制或放大的偏见。
• 不要忽视伦理考量： 永远不要忽视提示的伦理影响，包括潜在的误用、生成有害内容、侵犯隐私或不公平结果。始终负责任地设计提示。
• 必要时不要忽略领域知识： 尽管 LLM 拥有广泛的通用知识，但对于专业任务，将相关的领域特定术语或上下文纳入提示中至关重要。
• 不要只依赖自动化指标进行评估： 尽管指标有用，但始终应包含人工评估，以评估自动化工具可能遗漏的质量、相关性和安全性的细微之处。
• 不要期望完美或读心术： LLM 功能强大，但并非完美无缺。它们基于训练数据中的模式和你提供的指令进行操作。它们无法推断出超出明确说明或暗示的意图。
• 不要无视上下文窗口限制： 请注意模型的最大上下文长度。过长的提示或对话历史可能会被截断或导致性能下降。明智地管理上下文。

提示工程关键最佳实践总结

• 从明确的提示目标开始。
• 指令要明确；不要假设 LLM 知道你的意思。
• 在简洁的同时提供足够的细节和上下文。
• 在精度或特定格式至关重要时，使用少样本示例。
• 彻底测试提示，并根据观察到的输出来迭代优化。
• 始终考虑伦理影响和潜在危害。
• 对于多语言应用，设计和测试能够适当支持不同语言和文化背景的提示。
• 定期审查和更新你的提示，特别是随着模型的演进或新技术的出现。

结论

遵循这些“应该做”和“不应该做”的原则是成功进行提示工程的坚实基础。理解任务需求、提供清晰且上下文相关的指令、迭代优化提示以及始终牢记伦理考量至关重要。

通过遵循最佳实践并结合用户反馈，提示工程师可以创建高效的提示，充分利用 LLM 的强大能力，从而获得期望的结果和负责任的 AI 应用。