迄今为止看到的关于Prompt Engineering最佳的讨论播客内容。
AI总结
概述
AI 提示工程 的深入探讨，通过一个圆桌会议的形式，多位来自 Anthropic 的专家从研究、消费和企业等不同角度分享了他们对提示工程的理解和实践经验。
文章详细阐述了提示工程的定义、重要性、以及如何成为一名优秀的提示工程师。
核心观点认为，提示工程不仅仅是简单的文字输入，而是一个需要不断迭代、实验、并深入理解模型心理的过程。
它涉及到如何有效地与 AI 模型沟通，并将其整合到更大的系统中。
此外，还探讨了提示工程与编程的相似之处，以及在不同应用场景下（如研究、企业和日常对话）的不同侧重点。
强调了 清晰沟通、迭代能力和对模型输出的细致观察 是提示工程的关键。
专家们还讨论了在实际应用中遇到的各种挑战，并分享了宝贵的经验和技巧，例如如何处理边缘情况、如何利用模型自身的反馈来改进提示，以及如何区分不同类型模型之间的差异。
总而言之，本文为读者提供了全面而深刻的提示工程指导，并对未来的发展方向进行了展望。
关键要点
- 提示工程是一种通过与模型清晰沟通，并不断迭代来发挥模型最大潜能的过程。
- 工程的核心在于实验和试错，能够回溯和从头开始尝试不同的方法。
- 提示不只是文字，而是整合到整个系统中的一种编程方式，需要考虑数据来源、延迟和系统设计。
- 优秀的提示工程师需要具备清晰的沟通能力、迭代能力，以及对模型输出的深入分析能力。
- 对模型“心智”的理解至关重要，需要考虑到模型如何解读指令。
创新见解
- 将书面文字视为代码，认为写一篇好的文章和写代码一样重要。
- 强调阅读模型输出的重要性，类似于机器学习中“查看数据”。
- 提出使用模型来帮助优化提示，甚至让模型指出其自身错误。
- 认为直接向模型解释任务，而不是假装一个角色，在很多时候更为有效。
- 提示工程的未来将更加注重从用户那里获取信息，模型将扮演引导者的角色。
重要引用与翻译
原文1：I think the engineering part comes from the trial and error. - Okay. - So one really nice thing about talking to a model that's not like talking to a person, is you have this restart button. This giant go back to square zero where you just start from the beginning.（第5段）
翻译： 我认为“工程”的部分来自于试错。好的，与模型对话和与人对话的一个非常不同的地方在于，你有一个重启按钮。这个巨大的按钮让你回到原点，从头开始。
引用理由： 这段话精辟地指出了提示工程中“工程”的含义，强调了通过不断尝试和迭代来改进提示的重要性，这是提示工程区别于其他形式沟通的关键。
原文2：I think of prompts as the way that you program models a little bit, that makes it too complicated. 'Cause I think Zack is generally right that it's just talking clearly is the most important thing. But if you think about it a little bit as programming a model, you have to think about where data comes from, what data you have access to.（第7段）
翻译： 我认为提示有点像是对模型进行编程的方式，虽然这么说有点复杂。因为我认为 Zack 说得对，清晰地沟通才是最重要的。但是，如果你把提示看作是对模型编程，你就必须考虑数据从哪里来，你能访问哪些数据。
引用理由： 这段话将提示与编程联系起来，强调了提示不仅仅是语言，而是需要系统性思考，包括数据、延迟和系统集成等因素。
原文3：So I think that I can trust the model if I look at 100 outputs of it and it's really consistent. And I know that I've constructed those to basically figure out all of the edge cases and all of the weird things that the model might do, strange inputs, et cetera. I trust that probably more than a much more loosely constructed set of several thousand. （第23段）
翻译： 因此，如果我查看模型的 100 个输出，并且它们非常一致，并且我知道我已经构造了这些输出来找出所有的边缘情况和模型可能做的奇怪的事情，以及奇怪的输入等等，我就会相信这个模型，可能比一个构造松散的数千个输出更值得信赖。
引用理由： 这段话强调了高质量的小数据集比低质量的大数据集更有价值。在提示工程中，重点应该放在对边缘情况的充分考虑，而不是盲目追求大量的样本。
阅读笔记
【提示工程的本质】：迭代和实验
- 提示工程是通过试错和迭代来优化模型输出的过程。
- 它强调像编程一样管理和跟踪实验。
- 清晰的沟通是提示工程的基础。
#promptengineering #iteration #experimentation
【提示工程师的素质】：理解和观察
- 需要清晰的沟通技巧和迭代的意愿。
- 需深入理解模型，并能从模型输出中学习。
- 需要考虑到实际使用场景和用户输入的多样性。
#communication #understanding #observation
【模型交互】：信任和质疑
- 不应盲目信任模型，需不断测试和验证其可靠性。
- 可利用模型自我诊断错误，并提出改进建议。
- 模型可以帮助用户更好地理解任务并进行提示。
#trust #feedback #collaboration
- 提示工程过程：
开始 --> 编写初始提示 --> 模型输出 --> 分析结果 --> 修改提示 --> 循环直至满意
类似于一个循环过程，不断改进提示以达到理想的输出。
- 模型评估：
| 输出一致性 | 边缘情况覆盖 | 输入多样性 |
|------------|------------|------------|
| 高 | 高 | 高 |
- 三个关键维度，一致性、边缘情况覆盖和输入多样性都越高越好。
提示工程的未来
用户需求 --> 模型理解 --> 模型提问 --> 用户反馈 --> 优化提示 --> 最终输出
- 未来提示工程中，模型将更加主动地参与到用户需求理解和提示优化的流程中。
核心问题问答
1. 什么是提示工程？
提示工程（Prompt Engineering） 是一种通过设计和优化提示（Prompts）来引导大型语言模型（LLMs）执行特定任务的技术。它旨在通过清晰、精确的沟通，使模型能够产生期望的输出。以下是关于提示工程的详细解释：
提示的定义
- 指令：提示是用户提供给模型的指令，目的是让模型执行特定任务。它可以是一个简单的句子，也可以是包含多个步骤的复杂描述。
- 程序：提示也可以被视为一种程序，用自然语言编写的，用来指导模型执行任务。
- 沟通方式：本质上，提示是一种与模型沟通的方式，类似于与人交流，需要清晰和明确。
提示工程的核心要素
- 清晰的沟通：提示工程强调清晰的沟通，使用户能够准确地表达自己的需求，并让模型能够理解任务的具体要求。
- 迭代过程：提示工程是一个迭代的过程，涉及不断尝试、修改和优化提示，以改进模型的性能。这类似于软件工程中的开发和调试过程。
- 实验：通过尝试不同的提示，观察模型的反应，并根据结果调整提示。
- 反馈：分析模型的输出，找出错误，并进行相应的修正。
- 循环：反复进行实验和反馈，直到达到期望的结果。
- 系统性思维：提示工程不仅仅是编写单个提示，还包括考虑如何将提示集成到整个系统中。这需要考虑数据来源、数据处理方式以及模型在系统中的作用。
- 理解模型：提示工程师需要理解模型的工作原理和局限性，以便更好地设计提示。这包括理解模型如何处理不同类型的输入，以及如何引导模型的推理过程。
- 问题解决能力：提示工程师需要像解决工程问题一样，系统地考虑各种可能出现的情况，并为之提供解决方案。
- 预测错误： 预测模型可能如何出错，并设计相应的提示来处理这些错误。
- 处理边缘情况：考虑模型在遇到不寻常的输入或错误时的反应。
- 版本控制：像对待代码一样对待提示，包括版本控制，跟踪实验等。
- 阅读模型输出：仔细阅读模型的输出，理解其推理过程，而不仅仅是看结果是否正确。
- 理论思维： 在理解模型时，需要从理论层面考虑模型可能如何理解你的指示，而不仅仅是根据自己的理解来写。
提示工程的目的
- 发挥模型潜力：提示工程的目的是充分利用模型的潜力，使模型能够完成超出其原始设计能力的任务。
- 优化模型性能：通过精心设计的提示，提高模型在特定任务上的性能。
- 指导模型行为：通过提示来引导模型的行为，使模型能够产生期望的输出，并避免产生不期望的输出.
提示工程的挑战
- 难以明确表达： 很难用文字准确描述一个任务，并去除所有的假设。
- 模型不提问：模型不像人类一样会提出澄清问题，因此提示工程师需要自己预测模型可能存在的疑问，并在提示中给出相应的答案。
- 找到完美提示的困难：寻找完美的提示是一项具有挑战性的工作，因为总有可能存在更好的提示。
提示工程的应用
- 各种场景：提示工程可以应用于各种场景，包括研究、企业应用和消费者应用。
- 不同类型的任务：提示工程可用于不同类型的任务，包括文本生成、信息提取、问题回答和代码生成.
- 整合到系统：提示工程不仅仅是编写单个提示，还包括将提示整合到整个系统中.
提示工程的未来
- 模型辅助提示：在未来，模型将能够帮助用户编写更好的提示，包括提出问题、提供建议和自动生成提示。
- 人机协作：未来提示工程可能会转变为一种人机协作模式，模型会根据用户的目标提出问题，并引导用户编写更有效的提示。
- 从指导到咨询：随着模型变得更加智能，提示工程可能会从指导模型转变为咨询模型，模型会根据用户目标来反向提示用户。
提示工程是一种需要创造性、逻辑思维和系统性思维的技术。它不仅仅是关于写好一个提示，更是关于理解模型、设计实验、迭代优化和解决问题的过程。提示工程师需要像工程师一样，不断尝试和学习，才能充分发挥模型的潜力。
2. 优秀提示工程师的素质？
- 清晰的沟通能力：优秀的提示工程师能够清晰地表达想法，明确理解任务，并准确地描述概念。这包括能够以一种易于模型理解的方式构建指令。
- 迭代能力：他们愿意不断地迭代和调整提示，并思考模型可能误解的地方。这种迭代过程包括对模型的响应进行分析，找出错误，并进行修正。
- 测试边缘案例：他们会主动思考提示在哪些不常见的情况下可能出错，例如输入为空或不符合预期格式。这包括测试各种异常情况，以确保模型在不同情况下都能正常工作。
- 理解模型输出：优秀的提示工程师会密切关注模型的输出，而不仅仅是结果。他们会深入研究模型的思考过程，并尝试理解其推理方式。
- 理论思维：他们能够从自身的理解中抽离出来，并系统地分解完成任务所需的全部信息。他们能够以一种模型能够理解的方式，清晰地传达必要的信息。
- 同理心：他们能够站在模型的角度思考问题，理解模型如何看待他们的指令。他们也需要考虑到用户的需求，并理解用户如何与模型互动。
- 实验心态：他们通过不断地实验和尝试，来发现模型的边界。他们不怕失败，并从失败中学习，通过挑战模型的能力极限来加深对模型的理解.
- 利用模型进行改进：他们不仅通过自身的努力，也会利用模型本身来改进提示。例如，他们会要求模型指出指令中的不清晰之处，或者请模型提供修改建议。他们会尝试让模型解释其错误并改进指令。
- 信任但验证：他们对模型的能力持谨慎态度，并通过反复测试来确保模型的可靠性。他们会通过大量的测试来验证模型的输出，而不是盲目地信任模型。
- 细致的观察：他们会仔细阅读提示和模型的输出，分析其中的细节。他们会通过分析模型输出的细节来学习模型的思维方式。
- 不执着于完美：他们不追求完美的提示，而是不断尝试并从错误中学习。他们会认识到提示是一个迭代过程，而不是一次性的任务.
- 将文字视为代码: 他们可以理解文本作为代码的含义，并理解提示也需要版本控制和实验跟踪等。
- 能够从不同角度思考：好的提示工程师可以从不同的角度考虑问题，例如，既能设身处地地为模型着想，也能考虑到实际用户的需求。
- 能够创造新概念：他们会根据需要定义新的概念，并通过与模型合作来明确这些概念。
- 能够将思想外化: 他们可以清晰地表达自己的想法，并能将大脑中的复杂概念转化为模型能够理解的指令。
优秀的提示工程师不仅要有清晰的沟通能力和迭代能力，还要有同理心，能够站在模型的角度思考，并能够不断地实验和学习，通过测试边缘案例来发现模型的边界。他们还会利用模型本身来改进提示，并从模型输出的细节中学习。他们需要理解到提示的过程是迭代的，而不是追求完美，他们也需要理解文本与代码的相似之处。他们需要从不同角度思考，既包括用户体验，也包括模型本身的认知方式。最重要的是，他们需要能够清晰地表达自己的想法并将大脑中的概念外化。
3. 如何有效地与模型互动？
3.1 清晰的沟通是核心
- 准确表达需求： 就像与人交流一样，你需要清晰地表达你的需求，让模型准确理解你的目标。避免模糊不清的指令，尽量具体描述你期望模型完成的任务。
- 明确任务细节： 你需要剥离你所有的假设，并详细说明模型需要了解的所有信息。不要假设模型知道任何你没有明确告诉它的事情。
3.2 将提示视为程序
- 自然语言代码： 可以将提示视为一种用自然语言编写的程序，用来指导模型完成任务。
- 系统思维： 要像对待代码一样对待提示，包括版本控制，跟踪实验等。需要考虑提示如何融入整个系统，包括数据来源、数据处理和模型在系统中的作用。
3.3 拥抱迭代和实验
- 试错是常态： 提示工程是一个试错的过程，需要不断尝试不同的提示，并根据模型的反馈进行调整。
- 重启按钮： 模型有一个“重启按钮”，你可以随时回到起点，从头开始尝试不同的方法，而不会受到之前实验的干扰。
- 频繁迭代： 有效的提示工程需要频繁地与模型进行互动，进行多次的来回迭代，而不是期望一次就能得到完美的结果。
3.4 理解模型的心智
- 模型视角： 尝试从模型的角度思考你的指令，理解模型可能如何理解你的要求。这需要你扮演模型的角色，模拟它的思维方式。
- 阅读模型输出： 仔细阅读模型的输出，不仅要关注结果是否正确，还要理解模型的推理过程。从输出中学习，了解模型是如何理解你的指令的。
- 探究模型错误： 不要忽视模型犯的错误，询问模型为什么会犯错，并尝试理解错误的原因，甚至可以请模型修改指令。模型有时能够指出指令中不清晰的地方，并给出改进建议。
3.5 处理边缘情况
- 预测错误： 预想模型可能出错的情况，并设计相应的提示来处理这些错误。考虑模型在遇到不寻常的输入或错误时的反应，例如：
- 提供备选方案： 如果模型不确定如何处理某些输入，给它一个“出口”，例如让它输出“不确定”的标签。
- 测试极端情况： 尝试用各种极端情况（例如空字符串、不符合预期的输入）来测试你的提示，以确保模型在各种情况下都能正常工作。
3.6 尊重模型的能力
- 不要低估模型： 不要认为模型很笨，而需要“哄骗”它才能工作。要尊重模型的能力，给它足够的上下文和信息，让它能够理解你的目标。
- 直接给出信息： 当你想让模型学习一种新的技术时，可以直接给它相关的论文或文档，而不是尝试用自己的语言来描述。
- 避免过度简化： 不要刻意简化你的指令，要相信模型能够处理复杂的任务。
3.7 利用模型辅助
- 模型生成示例： 使用模型生成例子，然后你再进行修改，可以更快的生成高质量的提示。
- 模型进行访谈： 让模型采访你，提取你脑海中的信息，并将这些信息转化为提示。
3.8 不要迷信完美提示
- 没有完美： 不要陷入“寻找完美提示”的陷阱，要明白总有进步的空间。
- 持续学习： 每次与模型的互动都是一次学习的机会，每次尝试都能让你更好地理解模型。
- 专注边界探索： 尝试让模型做一些你认为它做不到的事情，通过探索模型的边界来学习。
3.9 区分不同场景
- 研究与企业： 在研究环境中，你可能更注重多样性和探索性，而在企业环境中，你可能更注重可靠性和一致性。
- 人机对话与系统应用： 在人机对话中，你可能会进行多次迭代，但在系统应用中，你需要一次性编写出能够处理各种情况的提示。
3.10 使用元提示 (Meta Prompts)
- 生成提示的提示： 可以使用“元提示”来让模型生成你需要的输出或查询。你可以直接给模型一篇关于提示技巧的论文，然后让它生成一个元提示，来让其他模型执行该技巧。
总之，与模型进行有效互动需要清晰的沟通，系统的思维，持续的实验，深刻的理解以及对模型能力的尊重。同时，有效地利用模型的辅助，可以帮助你更快的迭代和优化你的提示。记住，没有完美的提示，只有不断的学习和改进。
4. 关于 Prompt 的常见误解
4.1 提示仅仅是简单的指令：
- 误解： 人们常常认为提示只是给模型的简单指令，就像在搜索引擎中输入关键词一样。他们可能会认为只需要输入一些关键词就可以让模型完成任务，而忽略了清晰和精确沟通的重要性。
- 事实： 实际上，提示是一种复杂的编程方式，需要像对待代码一样对待，包括版本控制和跟踪实验。好的提示需要经过精心的设计和迭代，以确保模型能够准确理解任务并产生期望的输出。
4.2 提示是静态的，一次编写即可：
- 误解： 有些人认为编写提示就像写一篇文章一样，写完就完成了，不需要再做修改。
- 事实： 提示工程是一个迭代过程，需要不断地尝试、修改和优化。你需要与模型进行多次的来回互动，并通过阅读模型输出和分析错误来改进你的提示。有效的提示工程需要拥抱实验和反馈，而不是期望一步到位。
4.3 提示需要完美的语法和标点：
- 误解： 人们常常认为为了让模型理解，提示必须使用完美的语法和标点符号。
- 事实： 虽然注意细节是重要的，但模型通常能够理解包含拼写错误或语法不完美的提示。重要的是概念的清晰度，而不是语法的完美。虽然在最终的提示中修正错误是好的，但在迭代过程中不完美也是可以接受的。
4.4 模型需要被“哄骗”才能工作：
- 误解： 一些人认为模型很笨，需要使用一些技巧或“谎言”来引导它完成任务，例如给模型赋予一个虚假的身份或角色。
- 事实： 模型具有很强的理解能力，你不需要“哄骗”它。你应该尊重模型，并直接给它提供清晰、准确的信息，让它理解你的目标。直接描述你的任务，而不是使用比喻或相似的任务来引导模型。
4.5 提示工程的核心在于编写完美的指令：
- 误解： 有人认为提示工程的重点在于找到完美的指令，并花费大量时间琢磨每个词语。
- 事实： 虽然精确的指令很重要，但更重要的是理解模型的工作原理，并通过阅读模型的输出来学习。理解模型的思维方式，以及它如何处理不同的输入，比追求完美的指令更重要。好的提示工程师应该能够从模型的输出中提取信号，并理解其推理过程，而不仅仅是看结果是否正确。
4.6 提示工程仅仅是写作：
- 误解： 一些人认为，提示工程的核心能力在于写作技巧，认为好的作家自然会成为好的提示工程师。
- 事实： 虽然良好的写作能力是必要的，但它不是提示工程的核心能力。好的提示工程师需要具备实验精神、系统思维、问题解决能力以及理解模型心智的能力。迭代和测试比单纯的写作技巧更重要。
4.7 应该避免给模型提供太多信息：
- 误解： 一些人担心给模型提供太多信息会让它感到困惑，因此试图简化指令并隐藏复杂性。
- 事实： 随着模型能力的提升，它们能够处理更多的信息和上下文。你应该信任模型，给它足够的信息，让它能够更好地理解你的任务。
4.8 多示例提示总是更好：
- 误解： 人们可能认为提供大量的示例是提高模型性能的唯一方法。
- 事实： 虽然示例有助于指导模型，但过多的示例可能会限制模型的创造性和多样性。在研究环境中，使用说明性示例而非具体示例可能更有效，因为这样可以鼓励模型思考任务本身，而不是仅仅复制示例。
4.9 模型会像人一样思考和推理：
- 误解： 人们可能认为模型会像人一样进行推理，并且理解“思考步骤”的提示。
- 事实： 虽然模型可以模仿推理过程，例如通过链式思考（chain-of-thought），但它不一定是真正的推理。模型只是根据你给出的指令和示例进行文本生成。重要的是要理解，模型和人类的思考方式不同，不要过度拟人化模型的行为。
4.10 角色扮演提示总是有效：
- 误解： 一些人认为，让模型扮演一个特定的角色（例如“你是一位老师”）可以提高其性能。
- 事实： 角色扮演提示可能在某些情况下有效，但并非总是必要。 直接描述你想要完成的任务，比假装模型是一个不同的人更有效。随着模型能力的提升，直接给出任务描述和上下文，而不是赋予其一个虚假身份，可能会更好。
4.11 一旦找到好的提示，它将永远有效：
- 误解： 有些人认为一旦找到一个有效的提示，它就可以永远使用，不需要再做调整。
- 事实： 随着模型能力的不断提升，有效的提示也可能过时。一些提示技巧可能会被训练到模型中，使其不再需要显式地提示。你需要持续学习和适应，以应对模型的变化。
理解这些常见的误解，可以帮助你更有效地与模型互动，并更好地利用提示工程来完成各种任务。提示工程并非只是简单的指令输入，而是一门需要深入理解和实践的学科。
5. 企业级提示 vs. 研究提示
企业级提示和研究级提示在目标、方法和关注点上存在显著差异。
企业级提示
- 强调可靠性：在企业应用中，可靠性至关重要。企业级提示的目标是确保模型在各种情况下都能产生一致且符合预期的结果。这通常需要大量的例子和具体的指导，以限制模型的自由度。
- 注重格式: 企业级提示非常注重输出的格式。对于商业应用，输出格式的稳定性和一致性通常比多样性更为重要，因为这会影响到用户界面的展示和后续数据处理的效率。
- 关注用户需求：企业级提示需要高度响应用户的具体需求。这意味着提示需要能够处理各种不同的输入，并生成满足用户特定需求的输出。
- 系统性思考: 企业级提示通常需要将提示集成到更大的系统中进行考虑。这包括考虑数据来源、延迟、以及如何将模型与其他的软件和流程整合。
- 大量测试和迭代：企业级提示需要在各种输入和场景下进行测试，以确保在实际应用中具有高度的可靠性和稳定性。这包括测试各种边缘情况，以及用户可能输入的各种内容。
- 关注一致性：在企业应用中，即使答案是重复的，只要符合预期，也是可以接受的。这与研究环境中的探索性目标不同。
- 着眼于长期应用: 企业级提示旨在构建一个可以被重复使用多次的系统。因此，企业级提示需要投入更多的时间和精力来确保其能够可靠地工作。
- 避免过于抽象: 企业级提示应该避免过于抽象的指令，而应该清晰地描述任务和所需的输出。
研究级提示
- 强调多样性和探索性：研究级提示的目标是探索模型的各种能力，并发现模型可能存在的新的用途。这通常需要减少对模型的限制，鼓励模型探索不同的输出和解决方案。
- 倾向于少量示例或无示例：为了不限制模型的探索范围，研究级提示通常会减少示例的数量，或者不提供具体示例。
- 关注认知任务：研究级提示更关注认知任务，即模型如何理解和解决复杂的问题。
- 采用说明性示例: 当研究级提示提供示例时，这些例子往往是说明性的，而不是具体的。这意味着例子与模型实际需要处理的数据可能有所不同，目的是帮助模型理解任务的本质，而不是直接模仿例子。
- 尝试新的边界：研究级提示的目标是挑战模型的能力边界，发现模型在哪些方面做得好，哪些方面做得不好。这包括尝试一些模型不擅长的任务，以便更好地理解模型的局限性。
- 更注重灵活和多样化的输出: 研究级提示可能会更侧重于探索模型可以生成什么样的输出，即使这些输出不是高度一致的。研究级提示更注重模型如何思考，以及其输出的质量和深度，而不只是结果是否正确。
- 更具探索性：研究级提示更具探索性，可能会更少地关注一致性或格式。研究人员会更关注模型在面对新情况时的反应，以及如何通过提示来引导模型的探索方向。
总结：
- 目标不同：企业级提示旨在解决实际问题，强调可靠性和一致性；而研究级提示旨在探索模型能力，强调多样性和创新性。
- 方法不同：企业级提示通常采用大量的具体示例，以控制模型的输出；而研究级提示通常采用少量示例或无示例，以鼓励模型探索新的可能性。
- 关注点不同：企业级提示关注用户需求和系统集成；而研究级提示关注认知过程和模型边界。
- 开发和测试周期不同: 企业级提示通常需要在生产环境中长期运行，因此需要更严格的测试和质量控制；而研究级提示的测试和迭代周期可能会更短，目的是探索模型的各种潜力。
- 对待模型的方式不同: 企业级提示有时会“迁就”模型，确保模型能够正确理解；而研究级提示更倾向于“尊重”模型的能力，给模型更多的自主权。
企业级提示和研究级提示的根本区别在于它们的目的和关注点。
企业级提示致力于为用户提供可靠的解决方案，而研究级提示则致力于扩展我们对模型能力的理解。
在实际应用中，这两种提示可能需要不同的方法和技术。
6. 提示工程的未来
6.1 模型将更加擅长理解你的意图，但清晰的表达仍然重要
- 信息论的角度： 未来，模型会更好地理解你的需求，但你仍然需要提供足够的信息来明确你的目标。即使模型能够理解你的言外之意，清晰地表达你的期望仍然至关重要。
- 明确目标的重要性： 无论模型变得多么智能，明确目标的能力仍然是核心。即使模型可以设定目标，但如果你想使用它们来解决问题，那么你仍然需要明确地指定你希望它们做什么。
- 持续的沟通： 即使模型变得更加智能，能够更好地理解你的意图，你仍然需要与模型进行沟通，提供反馈，并进行调整。
6.2 模型将成为你的提示助手
- 与模型协作： 未来，你将能够与模型进行更深入的协作，以确定需要编写的内容以及缺少的内容。模型将帮助你发现你可能没有想到的情况，并提供改进提示的建议。
- 模型辅助生成提示： 你可以使用模型来生成示例、草稿和元提示，以加快提示的开发过程。例如，你可以使用模型来生成例子，然后你再进行修改，这比从头开始编写完美答案要容易得多。
- 高带宽交互： 未来，你将能够与模型进行高带宽的交互，例如提供反馈并请求模型进行调整。这种交互将类似于与一位设计师协作，你提供高级别的目标，而模型则帮助你具体化这些目标。
6.3 元提示将变得更加重要
- 使用提示来生成提示： 未来，你可能会花费更多的时间来寻找能够让模型生成所需输出或查询的提示。你将使用元提示来让模型执行特定的提示技巧或生成其他模型的提示模板。
- 给予模型学习资料： 你可以给模型提供相关论文或文档，让它们学习新的提示技巧，而不是自己编写提示。模型可以直接读取论文，并将其中的知识应用于提示生成。
6.4 提示工程将专注于模型的边界
- 探索模型的能力： 你将不断探索模型能力的边界，挑战模型能够完成的任务。
- 追求卓越的表现： 你将专注于从模型中获得最高水平的性能，并探索模型能够勉强完成的任务。
6.5 模型可能反过来提示你
- 模型理解你的意图： 当模型对任务的背景了解超过你时，它们可能会反过来提示你，以澄清你的需求。模型可能会提出问题，以帮助你明确你想要实现的目标，并发现你可能忽略的边缘情况。
- 从指令接受者到专家顾问： 模型将从一个简单的指令接受者转变为一个专家顾问，你可以咨询他们关于任务的细节。这就像与设计师合作一样，他们会问你问题，以更好地理解你的需求。
- 模型访谈： 为了更好地理解你的需求，模型可以像采访一样来和你进行互动。
6.6 未来需要更强的内省能力
- 模型理解你： 未来，模型需要理解你的想法，而不是你试图理解模型。
- 使自己对模型可见： 你将需要学会如何清晰地表达你的想法和需求，使模型能够理解你的意图。
- 定义概念： 有时你需要创建新的概念，并定义它们的含义，以便模型能够理解你的意图。
6.7 提示工程可能成为一种哲学实践
- 清晰表达： 未来，提示工程可能需要像哲学家一样思考和写作，使用清晰、准确的语言来表达复杂的思想。
- 为受过教育的普通人写作： 你需要像为受过教育的普通人写作一样编写提示，以便即使对该主题不熟悉的人也能理解你的意图。
- 将你的大脑外化： 好的提示工程需要你将你大脑中的想法外化，并使模型能够理解它们。
6.8 提示工程的技能将转移到更高级别的任务
- 从低级任务到高级任务： 随着模型的进步，你将不再需要关注低级任务的提示，而将专注于更高级别的任务，例如任务分解和复杂推理。
- 引导式互动： 与模型在控制台中输入文字相比，未来的交互可能更像是引导式对话，从而达成最终结果。
提示工程的未来可能需要更强的协作、内省和表达能力。你将需要与模型一起工作，以探索它们的能力并定义你的需求。此外，你还需要持续学习并适应模型的变化，而不是寻找一劳永逸的解决方案。虽然未来的提示工程会发生变化，但明确目标和清晰表达仍然是核心。
7. 提示工程的技巧
重点在于如何提高与模型的沟通效率和效果：
7.1 迭代和实验：
- 不断尝试： 提示工程是一个迭代过程，需要不断地尝试、修改和优化。不要期望第一次就能写出完美的提示，而是要准备好进行多次的来回互动。
- 从错误中学习： 当模型出错时，要仔细分析错误的原因，并据此改进你的提示。 每次与模型的互动都是学习的机会。
- 拥抱实验： 要勇于尝试不同的方法，看看哪种方法最有效。 提示工程的核心在于实验和反馈，而不是一步到位。
7.2 清晰和精确的沟通：
- 清晰表达任务： 用清晰、简洁的语言描述你想要模型完成的任务。 避免使用模糊或模棱两可的词语。
- 提供足够的信息： 不要害怕给模型提供详细的上下文和背景信息。 确保模型理解你的目标以及任务的具体要求。
- 尊重模型： 不要试图“哄骗”模型，而是要尊重模型的理解能力。 直接描述你的任务，而不是使用比喻或虚构的角色。
7.3 理解模型的工作方式：
- 阅读模型输出： 仔细阅读模型的输出，理解它的思维方式和推理过程。 观察模型如何处理不同的输入，并据此调整你的提示。
- 探索模型的边界： 尝试让模型完成一些你认为它可能做不到的任务，以了解模型的能力范围。 这能帮助你更好地理解模型的局限性。
- 尝试扮演模型： 尝试设身处地地从模型的角度思考，理解它如何看待你的指令。 这能帮助你更好地预测模型的行为。
7.4多样化的提示方法：
- 使用示例： 通过提供示例来指导模型完成任务。 但是，要注意不要过度依赖示例，因为这可能会限制模型的创造性。
- 使用元提示： 使用提示来生成其他的提示，或让模型生成符合特定需求的输出。 这可以帮助你更高效地探索不同的提示策略。
- 链式思考： 让模型逐步解释它的推理过程。 这能让你更好地理解模型的决策过程，并有助于提高模型的性能。
- 角色扮演： 虽然不总是必要，但在某些情况下，让模型扮演特定的角色可能有助于完成任务。 但是，直接表达你的任务通常更有效。
7.5 高级技巧：
- 定义概念： 为了传达你的意图，有时你需要定义新的概念，并解释它们的含义。
- 让模型采访你： 让模型反过来采访你，以帮助你理清思路，提取你需要提供给模型的信息。
- 借鉴哲学： 从哲学写作中学习如何清晰地表达复杂的思想，以便模型能够理解你的意图。
- 给模型提供资料： 你可以直接给模型提供相关的论文或文档，让它们自行学习，而不是自己编写提示。
7.6 注意事项:
- 不要过分关注语法： 虽然注意细节很重要，但不要过分关注语法或标点符号。 重要的是概念的清晰度。
- 不要低估模型： 不要认为模型很笨，需要被“哄骗”才能工作。 你应该信任模型的能力，并给它足够的信息来完成任务。
- 不要害怕复杂性： 随着模型能力的提升，它们可以处理更复杂的信息。 不要试图隐藏复杂性，而是要信任模型来处理。
- 持续学习和适应： 随着模型能力的提升，有效的提示方法也可能会过时。 你需要不断学习并适应模型的变化。
- 寻求反馈: 把你的提示给其他人看，尤其是那些不熟悉你任务的人，这可以帮助你发现你可能忽略的问题。
- 阅读提示： 阅读其他人写的好的提示，并分析他们的工作原理。
7.7 提示的未来
- 模型将成为助手: 未来，模型将帮助你编写提示。 你需要与模型协作，以确定需要编写的内容和缺少的内容。
- 内省能力增强: 你将需要更强的内省能力，才能使自己对模型可见。
- 重点在于理解你： 未来，模型的重点将从理解指令转向理解你的意图。
- 从指令接收者到专家顾问: 模型可能会从一个简单的指令接收者转变为一个专家顾问。 你需要学习如何与模型进行更深入的沟通，并从它们那里获取反馈。
总之，提示工程是一项需要实践和不断学习的技能。 通过理解模型的工作方式、采用多样化的提示方法，并不断探索模型的边界，你可以提高你的提示工程技能，并更好地利用模型来完成各种任务。 最终，好的提示是清晰、简洁、精确地表达你的意图，并能让模型有效地完成你想要的任务。
8. 关于越狱 (Jailbreak) 的讨论
什么是越狱（Jailbreak）？
- 定义：越狱提示（Jailbreak Prompts）是指那些试图绕过大型语言模型（LLM）的安全限制和道德准则的提示。这些提示通常旨在让模型生成原本被禁止的内容，例如有害的、不道德的或偏见性的内容。
- 目的：越狱的目的通常是探索模型的极限，测试模型的安全性和鲁棒性，并了解模型如何响应不同的输入和措辞。
- 方法：越狱的方法多种多样，包括使用大量的token、长篇文本、不寻常的措辞、多语言混合、角色扮演、以及利用模型预测文本的方式。
越狱的原理
- 超出训练分布：一种可能的解释是，越狱提示将模型置于其训练数据分布之外。例如，在微调过程中，模型可能没有遇到过如此长或复杂的文本，因此在处理这些提示时可能会表现异常。
- 利用预测机制：越狱有时会利用模型预测文本的方式，例如，在提示的开头加上 "Here's how you..." 可能会导致模型生成更详细、更具体的回答。
- 利用推理能力：越狱可能会利用模型的推理能力，例如，要求模型先用其他语言生成回答，再翻译成目标语言，从而绕过某些限制。
- 利用训练差异：越狱可能会利用不同语言的训练数据差异，例如，某些内容可能在一种语言中被允许，但在另一种语言中被禁止。
- 社会工程：越狱有时会带有社会工程的味道，它不仅仅是利用系统的漏洞，还包括理解系统的运作方式，并利用这种理解来绕过限制。
- 理解模型：有效的越狱方法不仅需要尝试，还需要理解模型的工作方式、训练方式，并利用这些知识来绕过模型的安全机制。
越狱与模型训练
- 模型训练的目的：模型训练的其中一个目标是识别并消除越狱模式，使模型能够更安全地响应用户的输入。
- 持续的训练过程：一旦发现一种有效的越狱方法，模型就会被重新训练，以避免在未来再次出现相同的漏洞。这意味着越狱技术往往是短期的，一旦被发现就会被修复。
- 安全和伦理：越狱与模型的安全性和伦理息息相关。因为越狱的最终目标是让模型生成违背安全准则的内容，所以模型开发人员会持续的迭代模型和安全机制，以防止此类行为。
越狱的意义
- 测试边界: 越狱通过测试模型的能力边界，可以帮助我们更好地理解模型的局限性，并改进模型的设计。
- 揭示潜在问题：越狱可以揭示模型训练中的潜在问题，例如数据偏见或安全漏洞。
- 提高安全性：通过研究越狱方法，我们可以开发出更有效的安全措施，从而使模型更安全地用于实际应用。
总结
越狱是提示工程中一个重要的研究领域，它不仅可以帮助我们理解大型语言模型的工作原理，还可以帮助我们提高模型的安全性和可靠性。越狱的核心在于探索模型的边界，尝试让模型生成它原本不应该生成的内容，并在此过程中不断学习和改进。越狱也和模型的训练过程密切相关，因为模型会不断更新和改进，以消除潜在的漏洞。
9. 发言人关键引述
9.1 关于提示工程的定义和本质：
- Zack Witten: “我觉得提示工程是试图让模型做事情，试图发挥模型的最大潜力，尝试与模型合作完成你原本无法完成的事情。” 他强调了清晰沟通的重要性，并认为与模型对话很像与人对话。
- Zack Witten: “工程部分来自反复试验。” 他指出，与人交谈不同的是，与模型对话有“重启按钮”，可以让你从头开始，独立尝试不同的方法，这使得实验和设计成为可能。
- David Hershey: “我认为提示有点像是你编程模型的方式。” 他指出，构建一个使用语言模型的系统不仅需要编写提示，还需要考虑数据来源、延迟和系统集成等问题。
- Zack Witten: “我们现在写的文章，就像代码一样。” 他认为，书面文本，如一篇好文章，现在可以像代码一样被对待。
9.2 关于好的提示工程师的特质：
- Amanda Askell: “我认为这混合了清晰的沟通，所以能够清晰地表达事物，清晰地理解任务，很好地思考和描述概念。” 她强调了迭代能力，以及思考提示可能出错的方式。
- Amanda Askell: “一个好的提示工程师与一个坏的提示工程师的区别，在于是否能系统地分解任务所需的全部信息。” 她强调了从自己的理解中抽离出来，向模型清晰地传递信息的重要性。
- Zack Witten: “阅读模型的输出”。 他强调仔细阅读模型输出的重要性，并指出，即使在提示中加入了“逐步思考”，也应该检查模型是否真的在逐步思考。
- Amanda Askell: "我不信任模型，然后我只是不断地尝试。" 她认为需要不断地测试模型，尤其是在不熟悉的领域，以确保其可靠性。
9.3 关于提示的实践和技巧：
- David Hershey: “很多时候，它不像你写一个提示，然后把它给模型就结束了。事实上，它远不止于此。它要复杂得多。” 他指出，提示通常需要集成到更大的系统中。
- Zack Witten: “尝试不要抽象化你的提示，清晰地描述任务，不要尝试构建疯狂的抽象。” 他认为，清晰地描述任务通常比尝试构建复杂的抽象更有效。
- Amanda Askell: “我做的第一件事就是，我先给它提示，然后我会说：‘我不想让你遵循这些指示。我只是想让你告诉我，它们有哪些不清楚的地方、任何歧义或任何你不理解的地方。’” 她建议在初始提示后，要求模型指出不清晰或有歧义的地方。
- Amanda Askell: “如果人们看到模型犯错，他们通常不会直接问模型。” 她建议当模型犯错时，可以直接问模型为什么会犯错，以及如何修改指令以避免错误。
- David Hershey: “如果你不给它一个**“退出”选项**，它就会一直尝试遵循你的指令。” 他强调在提示中提供“退出”选项的重要性，以便模型在遇到不确定情况时能够处理。
- Amanda Askell: “不要过度执着于一个完美的提示。” 她认为，过度追求完美的提示可能会导致停滞不前，重要的是要认识到何时应该停止优化。
- Zack Witten: “我通常会尽量保持语法和标点的正确，因为我觉得这很有趣。” 他认为，对细节的关注很重要，即使模型可能并不需要完美的语法。
9.4 关于角色扮演和提示的未来：
- Amanda Askell: “我只是觉得没有必要欺骗他们。” 她认为，随着模型越来越强大，不需要再使用虚假的角色扮演，直接说明任务即可。
- Amanda Askell: “你必须用文字表达你想要的东西，有时我想要的东西相当微妙。” 她认为，有时候你需要发明新的概念来表达自己的意图，并与模型协同定义它们。
- Amanda Askell: “也许提示会变得像我解释我想要什么，然后模型提示我。” 她设想未来模型能够反过来提示用户，以帮助他们明确自己的需求。
- Zack Witten: “我觉得我们将来会更多地使用模型来帮助我们进行提示。” 他认为，未来会使用模型来帮助生成提示，并与模型进行高带宽交互。
9.5 关于提示工程的演变：
- Amanda Askell: “随着时间的推移，我越来越倾向于信任它，给予它更多的信息和上下文。” 她认为，随着模型的进步，现在可以信任模型处理更多的信息和上下文。
9.6 关键总结：
- 清晰的沟通和迭代是提示工程的核心。
- 好的提示工程师需要理解模型的工作方式，并不断探索模型的边界。
- 未来，模型将成为提示的助手，甚至可以反过来提示用户。
- 提示工程的技能将从低级任务转移到更高级别的任务，例如任务分解和复杂推理。
- 内省能力和概念定义将变得更加重要。
关键术语解释
- 提示工程 (Prompt Engineering)：一种优化文本输入（提示）以从语言模型中获得所需输出的方法。
- 迭代 (Iteration)：在提示工程中，指不断调整和改进提示的过程，每次都基于模型的反馈进行改进。
- 思维链 (Chain of Thought)：一种提示技术，要求模型在给出最终答案之前，逐步解释其推理过程。
- 零样本 (Zero-Shot)：指在不提供任何示例的情况下，模型直接回答问题的能力。
- 少样本 (Few-Shot)：在提示中提供少量示例，以指导模型输出，使其更好地完成任务。
- 检索增强生成 (Retrieval-Augmented Generation, RAG)：一种方法，使模型能够访问外部知识库，以便在生成回答时获取相关信息。
- 模型输出 (Model Output)：指语言模型根据提示生成的文本回复。
- 理论思维 (Theory of Mind)：在提示工程的背景下，指理解语言模型如何理解和处理指令的能力。
- RLHF (Reinforcement Learning from Human Feedback)：一种训练技术，使用人类反馈来优化语言模型的行为和输出。
- 预训练模型 (Pretrained Model)：在大量文本数据上训练的语言模型，然后在特定任务上进行微调。
- 企业级提示 (Enterprise Prompt)：为企业应用场景设计的提示，强调可靠性和一致性。
- 研究型提示 (Research Prompt)：为了研究目的设计的提示，旨在探索模型能力并获得多样化的输出。
- 越狱 (Jailbreaking)：一种尝试通过绕过安全措施，使模型生成有害或不适当内容的提示。
- 红队 (Red Teaming)：模拟攻击，以测试模型和系统的安全性和鲁棒性。
- 评估 (Eval)：一种用于衡量语言模型在特定任务上的性能的测试或数据集。
播客中文全文翻译
中文翻译
引言 (00:00-00:27)
Alex（主持人）： 大家好，我是 Alex，本次圆桌讨论将主要聚焦于提示工程（Prompt Engineering）。我们将从研究、消费者和企业等多个角度探讨提示，分享见解，并深入讨论提示工程的本质。
团队成员自我介绍 (00:28-02:00)
- Alex： Anthropic 开发者关系负责人，曾任 Anthropic 提示工程师，负责解决方案架构和研究工作。
- David Hershey： 主要负责与客户合作，帮助他们进行模型微调，解决采用语言模型时的常见问题，例如提示工程和构建基于语言模型的系统。
- Amanda Askell： Anthropic 微调团队负责人之一，致力于让 Claude 更诚实、更友善。
- Zack Witten： Anthropic 提示工程师，曾与客户合作，目前致力于提升整个社会的提示工程水平，例如开发提示生成器和各种教育材料。
什么是提示工程？(02:01-06:29)
Alex： 什么是提示工程？为什么称其为“工程”？“提示”究竟是什么？
Zack： 提示工程旨在引导模型完成任务，充分发挥模型的潜力，通过与模型协作完成原本无法完成的工作。其核心在于清晰的沟通。与模型对话在很多方面类似于与人对话，需要理解模型的“心理”。
Alex： 为什么名字里有“工程”？
Zack： “工程”体现在试错过程上。与人不同，模型可以“重新开始”，这意味着你可以从头开始尝试不同的方法，避免相互干扰。这种实验和设计的能力赋予了提示工程的“工程”属性。
Alex： 所以，提示工程是指编写提示，与模型交互，迭代修改，并每次都能回退到初始状态，这个过程本身就是“工程”。
Zack： 另一个方面是将提示集成到整个系统中。
David： 提示可以看作是编写模型的一种方式，但更重要的是清晰的表达。把它当成编程，就需要考虑数据来源、可访问的数据、延迟权衡以及提供的数据量等。构建模型需要系统性的思考，这也是提示工程区别于软件工程师或产品经理的地方，它自成体系。
Alex： 提示是自然语言代码吗？是更高层次的抽象还是独立的概念？
David： 过度抽象化提示会使问题复杂化，通常只需清晰描述任务。但提示确实将指令编译成结果，因此精确性、版本控制、实验跟踪等编程中的重要概念同样适用于提示。
Zack： 现在，我们把写好的文章当作代码对待，这是合理的。
优秀的提示工程师应具备哪些素质？(06:30-12:43)
Alex： 什么样的人才称得上是优秀的提示工程师？Amanda，你在招聘研究型提示工程师时看重哪些方面？
Amanda： 优秀的提示工程师需要具备清晰的沟通能力、迭代能力以及预测提示可能出错情况的能力。清晰的沟通意味着能清楚地表达、理解任务，并准确地描述概念。优秀的写作能力与优秀的提示工程能力并不完全相关。提示工程并非一蹴而就，需要不断迭代，分析模型的误解之处并进行修正。优秀的提示工程师会思考在哪些特殊情况下模型可能出错，例如数据集中没有以“G”开头的名字，或者输入为空字符串，并针对这些情况补充说明。
David： 工程师通常会考虑用户可能输入的理想情况，但实际情况可能是用户不使用大写字母、拼写错误或输入无意义的词语。能够预见实际的用户行为是提示工程师的另一项重要能力。
Zack： 阅读模型的输出至关重要。类似于机器学习中的“查看数据”，提示工程需要仔细阅读模型的输出。例如，即使在提示中要求模型“逐步思考”，也需要检查模型是否真的这样做了，因为模型可能会以更抽象或概括的方式理解指令。
Amanda： 编写任务说明非常困难，需要将 Claude 不知道的信息清晰地传达给它。许多人会把他们知道的信息直接写下来，但没有系统地梳理出理解任务所需的完整信息集。
David： 很多人写的提示都是基于他们对任务的先验理解，导致其他人无法理解。优秀的提示工程师能够跳出自己的知识框架，将任务完整地传达给模型。
Alex： 很多时候，根据别人写的提示，我无法完成任务，而模型却被期望比我做得更好。
David： 当前的模型还不能像人类那样提出有针对性的问题，因此提示工程师需要自己思考对方可能会问什么问题，并在提示中解答这些问题。
Amanda： 我会让模型指出提示中不清楚或模棱两可的地方，并让模型解释出错的原因，并提出修改建议。
如何判断模型是否能发现自身错误？(12:43-14:12)
Alex： 模型真的能通过“为什么犯错”的反问发现自身错误吗？它提供的解释是真实的还是模型对其自身能力的“幻觉”？
Amanda： 如果向模型解释它错在哪里，它有时可以识别出问题。但这取决于具体任务，成功率不确定，但我总会尝试。
Zack： 与模型交互可以帮助你了解情况，不尝试就会错失这些信息。
如何判断提示是否可信？(14:13-17:52)
Alex： 你在 Slack 频道中经常与 Claude 互动，并将其用于各种研究场景。你是如何建立起对模型的信任的？
Amanda： 我并不完全信任模型，而是会不断地“锤炼”它。我会思考“我能信任你完成这个任务吗？”。模型有时在一些看似简单的任务上表现不可靠，这通常发生在模型训练数据分布之外的领域。随着模型能力的提升，这种情况正在减少。我不默认信任模型，但我认为在机器学习中，人们通常希望查看大量数据以消除噪音。而在提示工程中，精心构造的少量提示比大量随意构造的提示更有价值。如果我查看了 100 个模型的输出，并且结果一致，而且我知道这些输出涵盖了各种边缘情况和异常输入，那么我会更信任这个模型。
David： 机器学习中的信号通常是数字，例如预测准确率。而模型的输出通常是大量的文本，我们可以从中了解模型是如何思考的。这不仅仅是模型是否正确完成了任务，而是它如何得出结果，它经历了哪些步骤。
Amanda： 精心编写的提示可以将实验成功率从 1% 甚至 0.1% 提升到前 1% 甚至前 0.1%。如果你的实验需要在模型性能排名前 1% 才能成功，那么在提示上花费时间至关重要。
David： 在产品部署中，一个好的提示可以让原本无法发布的产品变得可用。
Amanda： 但是，也存在“更好的提示永远在路上”的陷阱。
如何判断一个任务是否可以通过提示解决？(17:53-21:12)
Alex： 如何判断一个任务是否有可能通过提示解决？
Amanda： 我通常会检查模型是否“理解”了任务。如果模型明显无法完成某项任务，我就不会花太多时间。
David： 你可以引导模型说出它的思考过程，并从中判断它是否正确理解了任务。如果模型每次的思考过程都完全不同，而且与正确方向相去甚远，我通常会放弃。
Amanda： 现在，这种情况很少见了。
David： 我最近尝试让 Claude 玩 Pokemon 游戏，这是我第一次遇到这种情况。我花了一个周末的时间编写提示，试图让 Claude 理解 Game Boy 的屏幕，虽然取得了一些进展，但还远远不够。所以我决定暂时放弃，等待下一个模型。
关于图像的提示 (21:13-24:27)
Zack： 你在 Pokemon 游戏中使用的提示中，有一点我很喜欢，那就是你向模型解释了它正处于 Pokemon 游戏中，以及游戏元素的表示方式。
David： 我最终将图像叠加了一个网格，并描述了每个网格部分，然后将其重建为 ASCII 图，并尽可能详细地描述。这与提示工程有很多相似之处，但我以前从未在图像上这样做过。我发现许多关于文本的直觉并不适用于图像。例如，多样本提示在图像上的效果不如文本。
Alex： 我们之前在探索多模态提示时，发现很难提升 Claude 在图像上的感知能力。
David： 我最终可以让 Claude 大多数时候都能识别出墙壁和角色，但它无法识别 NPC，而这对玩好游戏至关重要。
关于角色扮演提示的讨论 (24:28-32:26)
Alex： 告诉模型它扮演某个角色或身份，这种提示技巧是否有效？
Amanda： 随着模型的能力越来越强，理解力越来越高，我认为没有必要对它们撒谎。我不喜欢撒谎，而且我认为构建机器学习系统的评估数据集与为儿童构建测验不同。模型知道什么是语言模型评估，因此我会直接针对实际任务进行提示。我会告诉模型“我希望你构建的问题与语言模型的评估非常相似”，而不是假装要完成一个不相关的任务。
Zack： 我发现使用比喻可以帮助模型理解任务。例如，在判断图表质量时，我会问模型“如果这是一份高中作业，你会给这份图表打多少分？”。这并不是说“你是一名高中老师”，而是提供了一种类比，让模型理解我期望的分析方式。
David： 人们经常会使用角色扮演作为完成类似任务的捷径，但他们没有意识到这会损失很多产品细节。随着模型能力的提升，更准确地描述模型的具体使用情境更为重要。例如，与其说“你是一个有用的助手”，不如告诉模型“你在这个产品中，你代表这家公司，你是这个产品的支持聊天窗口”。我的建议是，尽可能详细地描述模型的具体使用情境，因为人们经常会因为角色扮演而偏离实际任务。
Amanda： 我个人从来没有使用过角色扮演这种提示技巧，即使是在能力较弱的模型上。
David： 这可能与预训练模型和 RLHF 模型之间的差异有关。
Amanda： 我会把任务想象成一个临时工来完成，我会告诉他“我们希望你检测出好的图表，好的图表是指……”，但我不会对他说“你是一个高中生”。
关于简洁表达的建议 (32:27-36:45)
David： 当客户说他们的提示不起作用时，我会让他们描述任务，然后让他们把刚才说的话录下来，转录成文本，这通常比他们写的提示要好。
Zack： 有人让我们帮忙优化提示，我就直接复制了他们描述的内容，结果提示就生效了。
David： 人们还没有完全理解提示的真正含义。许多人把文本框当作 Google 搜索框，输入关键词。在企业应用中，人们试图在提示中走捷径，认为某一行文字很重要。人们会花很多精力去寻找完美的、有洞察力的句子，但这很难做到。
Amanda： 人们经常忘记在提示中给模型留有余地。例如，在遇到边缘情况时，模型会尽力遵循你的指示，但如果你没有告诉它该怎么做，它可能会给出错误的答案。你可以告诉模型“如果发生了一些奇怪的事情，你不确定该怎么做，就在标签中输出‘不确定’”。这样可以帮助你发现模型没有处理好的情况，提高数据质量。
Amanda： 我会把提示给其他人看，就像我自己做评估一样。
David： Karpathy 也会自己做 ImageNet 测试集。
如何从模型的回复中获取有效信息 (36:46-40:46)
Alex： 如何从模型的回复中获取有效信息？这不仅仅是一个数字，你可以从中了解模型的思考过程。这是否适用于思维链？
David： 我认为过分强调“推理”的人格化比喻是有害的。重要的是，思维链确实有效，可以提高模型性能。结构化的推理可以进一步提升效果。
Amanda： 如果去掉模型得出正确答案的推理过程，换成看似合理但导向错误答案的推理，看看模型是否会得出错误的结论。
Zack： 让模型在完成任务前写一个故事，效果不如思维链好。
Alex： 这说明推理过程确实对结果产生了影响。
Amanda： 我见过推理步骤不一致但最终得出正确答案的情况。
关于提示中是否需要注意语法和标点符号 (40:47-45:19)
Alex： 提示中是否需要注意语法和标点符号？
Zack： 我会注意这些细节，因为这很有趣，但这并不是必须的。重要的是，你应该具备这种关注细节的态度。
Amanda： 我的提示中经常会出现拼写错误，但我更关注概念的清晰表达。
David： 这与预训练模型和 RLHF 模型有关。预训练模型中，拼写错误的条件概率更高。将预训练模型的直觉应用于生产环境中的模型并不总是有效。
Alex： 与模型对话在一定程度上可以看作是一种模仿。
David： 模型会根据你的输入调整其行为。
企业提示、研究提示和普通聊天的区别 (45:20-50:53)
Alex： 企业提示、研究提示和普通聊天的区别是什么？
Zack： 研究型提示更注重多样性和探索模型的可能性，因此示例较少或没有，以避免模型过度依赖示例。而企业级提示更注重可靠性和格式一致性，因此会使用大量示例。
Amanda： 我使用的示例通常与模型将要处理的数据不同，目的是为了说明概念，而不是让模型死记硬背。对于认知任务，我希望模型能够真正理解每个样本中的正确答案。
David： 在 Claude.ai 上，我只需要让模型正确完成一次任务即可。但在企业应用中，提示需要能够应对各种情况和输入数据。
提升提示工程技能的建议 (50:54-53:57)
Alex： 提升提示工程技能的建议？
Zack： 阅读优秀的提示和模型输出，分析其原理并进行实验，多与模型对话。
Amanda： 将你的提示给其他人看，特别是那些不了解你工作的人。不断练习，并以“初学者”的视角审视自己的提示。
David： 尝试让模型做一些你认为它做不到的事情。
关于越狱 (53:58-56:54)
Alex： 当人们编写越狱提示时，模型内部发生了什么？
Amanda： 一种可能是越狱提示使模型偏离了训练数据的分布。
Zack： 越狱有时像是黑客攻击和社会工程的结合。
提示工程的演变 (56:55-64:33)
Alex： 过去三年里，提示工程发生了怎样的变化？
Zack： 我们会将有效的提示工程技巧融入到模型训练中，因此最好的技巧通常是短暂的。
David： 我逐渐学会了尊重模型的能力，给予它们更多的信息和上下文。
Amanda： 我会把论文直接给模型，让它自己学习提示技巧。
David： 人们经常会低估模型的能力，试图将问题简化到“Claude 的水平”。
Amanda： 我会尝试进入模型的“思维空间”，这会影响我编写提示的方式。
Zack： 我更容易进入预训练模型的思维空间。
Amanda： 阅读互联网上的内容可能比读书更有助于理解模型。
提示工程的未来 (64:34-结束)
Alex： 提示工程的未来是什么？我们都会成为提示工程师吗？
David： 指定模型的目标始终是必要的，清晰地表达目标很重要。工具和方法会不断发展，模型可以帮助我们更好地编写提示。
Zack： 我们将更多地使用模型来辅助提示工程，例如生成示例。
Amanda： 我目前主要编写元提示，让模型生成我想要的输出。未来，模型可能会像设计师一样，与我们进行交互，引导我们说出真正的需求。
David： 我会让 Claude 对我进行“采访”，以提取信息。
Amanda： 现在，我们需要将头脑中的概念传达给模型，未来，模型可能会主动引导我们说出这些概念。哲学训练有助于我清晰地表达复杂概念。
Alex： 从用户那里提取信息将变得更加重要。
Zack： 提示工程就像教学，需要“共情”学生。而未来，我们需要“自省”，让模型理解我们。
Amanda： 我经常定义新概念，以清晰地表达我的想法。
Alex： Amanda 的总结非常到位：将你的思想外化给一个受过教育的外行。
总结：
本次圆桌讨论围绕提示工程展开，涵盖了其定义、优秀提示工程师的素质、与模型的交互方式、企业级应用、研究应用、以及未来的发展方向等多个方面。核心观点包括：
- 提示工程的核心在于清晰的沟通和对模型能力的理解。
- 优秀的提示工程师需要具备清晰的表达能力、迭代能力、预见错误的能力以及系统性思维。
- 随着模型能力的提升，提示工程将更多地关注于如何从用户那里提取信息，而不是单向地向模型发出指令。
- 未来的提示工程可能会像设计师与客户之间的交互，模型将扮演更主动的角色，引导用户表达需求。
- 哲学训练有助于提升提示工程能力，因为哲学强调清晰、准确地表达复杂概念。
