微信扫码
与创始人交个朋友
我要投稿
前言
本文是2024.9.6Anthropic官方在youtube的一个播客全文的“脱水”版,
原视频标题
AI prompt engineering: A deep dive
播客视频链接
https://www.youtube.com/watch?v=T9aRN5JkmL8
内容英文原文有 18.2k token
这个内容是比较好的,难得的世界第一梯队的模型厂来分享他们对prompt工程的经验,而且是比较新的内容。
这个材料有两个作用:1是知道有哪些视角,2是知道即使是Anthropic也只知道这些。
什么是“脱水”版
本文是对于播客全文的一个整理,力求保留所有信息和每个信息是由谁说的,目标是能够让读者在任何情况下都不必去看原文。
本文也是一个阶段性的技术能力展示,全部内容都由workflow自动生成,我做了3处左右的人工修正。文中的粗体是我人工添加的。
当然这个方案还比较早期,还有完善空间。另外,本文的改写目标是最大限度的保留原始信息和保留原始来源(说话人),这并非是完全为了读者的阅读体验优化的。该技术方案在其他实际场景中应用时应该为实际场景的用户需求进行优化。而本文是给追求高效获取信息、希望不遗漏主要信息、并能溯源每个观点来源的读者准备的。这类读者确实很少。
我人工比较了前45min的内容,已经能够达到期望的目标,大概只有2处左右我觉得想保留但被遗失的信息。
正文
AI 提示工程:深入探讨
(00:00:00)
这是一场专注于prompt engineering的圆桌讨论。讨论将从研究、消费者和企业多个视角出发,旨在收集广泛的观点,深入探讨prompt engineering的本质和内涵。
参与讨论的四位专家分别是:Alex Albert,现任Anthropic开发者关系负责人,此前在prompt engineering团队担任工程师,涉足解决方案架构和研究工作;David Hershey,主要负责客户服务工作,专注于协助客户进行fine-tuning以及解决语言模型应用和系统构建中的各类问题;Amanda Askell,负责领导一个致力于提升Claude诚实度和友善度的微调团队;Zach Whitten,作为prompt engineer(与Alex就谁是Anthropic首位prompt engineer仍有争议),从个别客户服务转向开发prompt generator和教育材料,致力于提升社会整体的prompting水平。
(00:02:03)
在讨论提示工程的定义时,Zach Whitten认为提示工程的本质是尝试让模型完成任务,通过清晰的沟通来实现原本无法完成的目标。这个过程类似于与人交流,需要理解模型的特性,而Amanda在这方面是最专业的专家。
提示工程中的工程体现在其独特的试错过程。Zach指出,与模型交互的优势在于可以随时重置到初始状态,这使得工程师能够独立尝试不同方法而不会相互干扰。此外,提示工程还涉及将提示整合到更大的系统中。
David Hershey将提示视为编程模型的一种方式,虽然本质上是清晰沟通,但需要考虑数据来源、访问权限、检索增强生成(RAG)等因素,以及延迟和数据量的权衡。这些系统性思考使提示工程成为一个独特的专业领域。
David强调,提示应避免过度抽象,关键是清晰地描述任务。同时,提示需要像代码一样进行版本控制和实验管理。这形成了一个独特的范式:文本提示实际上承担了代码的功能,需要采用相应的管理方法。
怎样成为一名优秀的及时工程师
(00:06:27)
Amanda Askell从招聘角度分享了对优秀提示工程师特质的见解。她认为提示工程师需要具备Zach提到的清晰沟通能力,能够准确地陈述事物、理解任务、思考和描述概念。虽然有人质疑应该使用写作者而非工程师这一称谓,Amanda表示她曾经也同情这种观点,但现在认为这个职位确实具有工程特性。
她解释道,人们往往误认为提示工程是写一次就完成的工作,但实际上这是一个持续迭代的过程。她举例说明,在15分钟内可能需要向模型发送数百个提示,不断来回调整。提示工程师需要具备强大的迭代能力,能够识别模型的误解并进行修正。
Amanda强调,优秀的提示工程师还需要能预见并应对各种可能出错的情况。一个常见错误是仅考虑典型案例而忽视边界情况。例如,在设计提取字母G开头名字的提示时,需要考虑数据集中没有符合条件的名字、输入不是有效数据集、输入为空字符串等各种情况。David和Zach补充说,工程师常常假设用户会输入措辞完美的问题,但实际上用户可能完全不使用大写字母,经常出现拼写错误,没有标点符号,甚至只是输入一些没有问句结构的随机词汇。因此,提示工程师需要基于实际用户行为而非理想情况来设计提示。
(00:09:33)
Zach Whitten强调了在提示工程中仔细阅读模型输出的重要性。正如机器学习领域中查看数据是基本原则一样,提示工程中同样需要密切关注模型的响应。他举例说明,许多人在提示中使用think step by step指令,却没有验证模型是否确实按步骤思考。模型可能会从更抽象或一般的角度理解这个指令,而不是按字面要求写下具体的思考步骤。如果不认真阅读模型输出,这种偏差就可能被忽视。
Alex Albert补充指出,提示工程师需要理解模型如何解读指令。在企业应用场景中,提示工程师处于一个特殊位置,既要考虑如何编写指令让模型理解,又要预判用户将如何与模型交互,在这种三方关系中发挥桥梁作用。
(00:10:38)
David Hershey指出,在提示工程中,写下任务指令是一项极其具有挑战性的工作。这涉及到需要理清自己头脑中已知而AI模型未知的信息,并去除所有隐含的假设,清晰地向模型传达完整的任务信息。
这种能力是区分优秀提示工程师和糟糕提示工程师的关键。许多人在写提示词时往往只是简单地写下自己知道的内容,而没有系统地分析完成任务所需的完整信息集。常见的问题是提示词过度依赖于写作者对任务的先验理解,导致对不了解具体用例的人来说毫无意义。优秀的提示工程师能够跳出自己的认知框架,向这个知识广博但又有其特殊局限性的系统准确传达所需信息。
Amanda Askell和Alex Albert通过实例进一步说明了这一问题。有些提示词写得如此不完整,以至于连人类都无法根据这些指令完成任务。Alex特别举例说,当他给Zach解释某件事时,Zach会直接指出不理解的地方并提出问题,但当前的AI模型还不能这样做,这就要求提示工程师需要提前思考可能出现的问题,并在提示词中预先提供答案。
优化Prompt
(00:12:40)
Amanda Askell分享了一种改进提示词的方法。她在给出初始提示词时,会要求模型不要直接执行指令,而是先分析指令中不清晰或存在歧义的部分。虽然这种方法并非总能完美识别问题,但常常能带来帮助。
当模型出现错误时,一个常被忽视的方法是直接询问模型为什么会出错,并请求提供改进后的指令版本。Amanda表示,虽然她不确定这种方法的成功率,但值得一试,因为有时确实能够奏效。对此,Alex Albert提出疑问,想知道模型是否真能识别自身错误,还是这只是模型对自身局限性的一种幻觉。David Hershey补充说,每次与模型的互动都能学到东西,不尝试就可能错过有价值的信息。
在Anthropic内部,员工可以通过Slack频道与Claude交互。Amanda的Claude互动频道得到许多人关注,她比其他人更频繁地在研究环境中使用和信任模型的输出。
(00:14:56)
Amanda Askell强调她对AI模型采取永不轻信的态度,而是通过持续的测试来验证模型的可靠性。这种谨慎态度源于模型在分布外数据或不常见情况下可能表现异常,即使是看似简单的任务也可能出现可靠性降低的情况。
随着模型的不断改进,这种异常表现的情况正在减少,但仍然需要确保模型运行在可靠的范围内。
在测试方法的选择上,虽然机器学习领域的研究者通常倾向于使用大规模数据集以消除噪声,但对于提示任务,每次查询都能获得较强的信号,因此精心设计的几百个提示可能比数千个不够精确的提示更有价值。如果模型在100个精心设计的测试中表现一致,且这些测试涵盖了边缘情况和异常输入,这种验证方式比几千个松散构建的测试更可靠。
(00:16:22)
David Hershey指出,在MLA中,人们往往过分关注数字化的信号,如预测的正确与否,或是仅仅查看模型的log probs并试图进行直观理解,这种方法显得不够可靠。
他强调,模型的输出通常包含大量文字内容,这些内容中存在着根本性的、需要深入理解的信息,包括字里行间的含义。评估模型时不应该仅仅关注任务是否完成,更应该关注模型是如何达到结果的,包括其思维过程和采取的步骤。通过仔细阅读输出的详细内容,而不是仅看最终结果,我们能更好地理解模型内部的运作机制。
(00:17:09)
Amanda Askell指出,最佳的提示词工程对实验的成功至关重要。她观察到一些研究者没有充分重视实验中的提示词组件,但实际上提示词的优化可能导致模型性能在前5%、前1%或前0.1%之间产生显著差异。这种差异可能成为实验成败的关键因素。她认为在实验中投入大量时间优化代码却忽视提示词优化是不合理的做法,因为提示词往往是实验成败的决定性因素。
Zach Whitten补充说明了提示词在项目部署阶段的重要性。他提到有些项目原本因性能不达标而无法发布,但通过调整提示词后就能够正常工作。
(00:18:00)
David Hershey指出适度的提示词优化虽有价值,但这是一把双刃剑。人们往往认为存在一个能完美解决问题的神奇提示词在前方等待发现,这导致许多人陷入不断追寻的循环。虽然适度优化提示词是有益的,因为这个过程能够学到很多,但提示词工程最令人担忧的是存在大量未知领域。
对于如何判断任务是否可能通过完美的提示词来实现,Amanda Askell表示通常是通过观察模型是否理解任务来判断。如果模型明显无法完成任务,就不会在优化提示词上投入太多时间。
David Hershey补充说可以通过评估模型的思考过程来判断,询问它如何思考问题及其原因。通过这种方式可以判断是否至少处在正确方向的邮编区域内。如果能感觉到在向正确方向推进,就值得继续尝试;如果每次修改都导致完全不同且错误的方向,就应该放弃尝试。
(00:19:32)
Amanda Askell指出,现代AI模型已经很少遇到完全无法完成的任务,这种罕见的局限性会让她感到极其愤怒,不能接受模型在适当引导下仍无法完成某些任务。
David Hershey分享了一个基础实验案例,他将Claude连接到Game Boy模拟器上,尝试让其玩经典的Pokemon Red游戏。虽然Claude能够通过代码控制按钮操作,但在识别Game Boy屏幕截图方面表现出明显的局限性。他尝试了多种复杂的提示词方案,但收效有限。在投入整个周末的时间后,模型对屏幕的理解仅从完全无法识别提升到略微有些理解,远未达到实用水平。
面对这种情况,David决定暂停优化工作。他认为与其投入四个月时间进行优化,不如等待新一代模型的发布更有效率,同时可以先去做其他事情。
(00:21:11)
在Pokemon游戏图像识别的实践中,David Hershey采用了一个他认为有些繁琐的方法:在游戏图像上叠加网格,并详细描述每个网格段的视觉细节,然后将这些描述重构为ASCII地图。他设定了具体规则,如玩家角色固定在坐标(4,5)位置,并通过这种方式逐步积累信息。这种方法与文本提示有相似之处,但需要完全不同的处理直觉。
Zach Whitten观察到,文本提示的经验很难迁移到图像领域,特别是多示例提示在图像处理中的效果远不如文本,这可能与训练数据中相关示例较少有关。Alex Albert也证实了这一点,提到他们在早期多模态提示探索中就发现无法显著提升Claude的视觉识别能力。
在实践中,David意识到了识别能力的局限性。虽然模型能够基本识别墙壁和角色位置(虽然有些偏差),但在处理NPC时遇到了严重问题。模型无法维持NPC识别的连续性,这对游戏体验至关重要,因为玩家需要知道是否曾与特定NPC交谈过。即使将图像放大3000倍并单独截取NPC部分,模型的识别结果仍然模糊不清,有时会错误判断NPC是否戴帽子,最终证明这是一个无法克服的限制。
角色扮演和提示中的隐喻
(00:24:00)
在讨论语言模型提示策略时,Amanda Askell表达了想尝试新的提示方法,比如让模型描述游戏角色如果是真实的人会是什么样子。David Hershey分享了他的经验,曾告诉Claude它是为盲人服务的屏幕阅读器,虽然他不确定这种方法是否真的有帮助,但感觉合适就继续使用了。
Alex Albert指出角色扮演是一个著名的提示技巧,但他观察到这种方法在不同模型中显示出混合的效果,可能在较早的模型中效果更好。他注意到Amanda倾向于对模型保持诚实,会明确告知自己的身份和正在进行的实验目的。
Amanda Askell详细解释了选择诚实沟通的原因。她认为随着模型能力的提升,没有必要对它们说谎。她举例说明,构建语言模型评估数据集与为儿童制作测验是完全不同的任务,而且由于这些概念都存在于互联网上,模型已经能够理解它们。她强调清晰沟通的重要性,认为应该直接针对实际任务进行沟通,而不是通过间接或虚假的方式来完成任务,就像我们不会要求员工假扮老师一样。
(00:26:34)
Zach Whitten分享了一个使用比喻的有效案例。在让Claude评估图表质量时,他发现最有效的方法是让模型以高中作业的评分标准来打分。这种方法并非让模型扮演教师角色,而是提供一个评估框架来表达所需的分析尺度。
David Hershey认为这类比喻确实难以构建,并指出人们经常采用类似任务替代的方式。在企业环境中,人们倾向于选择模型可能更熟悉的场景(如高中测验比语言模型评估更常见)。他建议,随着模型能力的提升,更应该精确描述实际情境。
David举例说明,与其简单地说你是一个在写文档草稿的助手,不如明确指出模型在产品中的具体角色,如你是嵌入在产品中的支持聊天窗口。他指出,承认模型是语言模型而非人类是很好的做法,但更重要的是详细说明使用场景。这种建议源于他观察到人们常用角色提示作为简化任务的捷径,却因未能提供足够细节而导致模型无法准确完成实际需求。随着模型变得更智能并能区分更多主题,清晰描述具体情境变得更加重要。
(00:29:44)
Amanda Askell表示她从未使用过这种提示技术,即使在性能较差的模型上也是如此。在Alex Albert简短回应后,她进一步解释说她对这种技术并不感兴趣。她指出这可能是因为人们将预训练模型的使用直觉错误地应用到了RLHF模型上,而这两种模型的工作方式是不同的。
David Hershey解释道,在早期完成式模型时代,人们会考虑如何将模型引导到有用的潜在空间。他观察到许多人试图将预训练模型的方法应用到其他场景,但实际上大多数人并未完整体验过预训练模型、监督学习和RLHF的全过程。他指出,在与客户交流时,经常听到他们过分关注这个内容在互联网上出现了多少次这样的问题。这种基于互联网内容的直觉虽然有其基础,但在实际进行提示时往往被过度应用,因为模型已经经过了其他处理步骤。
(00:31:05)
Amanda Askell提出了一个有效的思维实验来说明如何更好地编写提示词:假设你通过临时工中介请来一个人完成任务。这个临时工很称职,对你的行业有深入了解,但不知道公司名称等具体情况,他们到达后只是简单地表示听说这里有工作要做。
在这种情况下,人们会很自然地使用比喻来解释任务要求。比如在解释什么是好的图表时,会说明不需要完美,不需要核实所有细节,只要确保图表包含基本要素如坐标轴等,可以用高中水平的好图表作为参考标准。Amanda建议在编写提示词时,首先假设对方是一个缺乏具体背景但了解很多世界知识的人,先尝试这种方式,如果不奏效再进行调整。这种方法通常能直接产生良好效果,但很多人往往没想到要直接告诉AI关于自己和任务的信息。
David Hershey经常向客户传授这种方法,当客户反映提示词不起作用时,他会让客户先口头描述任务需求,然后直接使用客户的口头描述作为提示词,效果往往比客户原本写的提示词更好。他认为这反映出人们在编写提示词时存在懒惰倾向。Zach Whitten也在prompt assistance中遇到类似情况,当他直接把用户描述的需求作为提示词时,问题就解决了。Alex Albert指出,这反映出很多人还没有真正理解如何编写提示词。
(00:33:17)
Alex Albert指出,在聊天场景中,许多用户将AI模型的提示词输入框等同于搜索框,仅输入关键词。在企业应用场景中,用户同样存在一个奇怪的现象,即过度简化提示词,错误地认为简单的一行指令就能传达复杂的意图。
David Hershey表示,用户往往过度执着于寻找完美的指令表述。他认为如果能看到像之前讨论的图表示例那样详细的提示词,那将是理想的情况。然而,用户通常不会这样写提示词,而是苦苦追求某个完美精确的表述。他强调这种做法是不可行的,并建议采用更接近人类自然交流的方式,着重于传达基本的直观理解。
(00:34:14)
Amanda Askell指出,在设计提示词时,人们常常忽视处理边缘情况。她解释说,语言模型就像临时工作人员一样会严格遵循指令,如果没有明确的处理指引,就会陷入困境。
她举例说明,如果给模型一张goat(山羊)的图片,但要求它分析图表,这种情况下如果没有明确的处理指引,模型会像没有联系方式的临时工一样,试图强行完成任务,给出不恰当的回答。
Askell建议的解决方案是,在提示词中明确指出:当遇到异常且模型不确定该如何处理时,应输出带标签的unsure。这样不仅为模型提供了处理意外输入的退路,还便于后续查看所有标记为unsure的情况,及时发现问题。Zach Whitten补充说,这种方法还能提高数据质量,因为可以找到所有异常的例子。
(00:35:11)
David Hershey分享了在与Claude迭代测试时的经验,他发现当Claude给出错误结果时,往往是因为测试本身存在问题,这帮助他发现并改进了测试设计。
Amanda Askell强调了人工评估的重要性,建议公司在使用prompt之前应该让人员先进行测试。她分享了自己评估语言模型时的经验,会设置简单脚本并亲自完成评估任务。Zach Whitten补充说现在可以让Claude来编写Streamwood应用。David提到了Karpathy的ImageNet案例,他在展示准确率时是自己完成了测试集的评估。特别值得注意的是,让临时工作人员来测试往往能带来更好的学习效果。Amanda还指出,严格按照评估指示进行测试而不带任何背景知识很重要,她自己的测试成绩(68%)往往比人类基准(90%)要低得多。
Alex Albert则指出了MMLU问题集中有些问题完全是垃圾,难以回答。
模型推理
(00:36:59)
Alex Albert提出了一个关于模型chain of thought(思维链)推理过程的重要问题:模型在提供答案前解释其推理过程是否是真实的推理,还是仅仅作为计算的中间过程。David Hershey表示,虽然他通常支持对模型进行拟人化描述因为这有助于理解模型工作方式,但在推理这个具体问题上,过度拟人化可能会影响对核心目标的理解。他认为这更像是一个哲学问题而非简单的提示技术问题。在实践层面,David指出无论是否属于真正的推理,这种方法确实能提高模型表现。通过结构化推理并与模型迭代改进推理方式,可以获得更好的结果。他类比了人类在没有书写过程的情况下也难以解决数学问题。Zach Whitten提到了一个来自sleeper agents paper的验证方法:通过替换正确推理为看似合理但错误的推理来测试模型反应。在实验中,他尝试让模型重复Aman这个词作为100个token的填充,结果证明单纯增加文本作为计算空间并不能改善结果。研究发现,模型有时会在推理步骤中出现错误,但仍能得出正确结论。David指出这种现象与人类推理类似,人类在推理过程中也可能出现不一致的步骤,这并不完全否定推理的有效性。
(00:40:45)
在提示词编写中是否需要严格遵守语法和标点规则的问题上,Zach Whitten和Amanda Askell展示了不同的观点。Zach表示他习惯于在提示词中使用正确的语法和标点,认为这种做法很有趣。虽然这并非必需,但他认为应该对提示词投入与编写代码同等的关注。他将这种偏好类比于程序员对代码风格的讲究,如制表符与空格的使用、编程语言的选择等,认为培养对提示词风格的重视是有益的,即使这些规则可能是任意的。
相比之下,Amanda Askell采取了更为宽松的态度。她的提示词可能包含拼写错误,但她特别注重概念表达的清晰度,会仔细思考所使用的概念和词语的选择。她认为只要概念表达清晰,语言模型就能理解其含义。
近来,Amanda开始更多地关注提示词中的语法和标点问题。这种改变主要源于外界压力,而非个人认同。她表示会在最终版本的提示词中注意这些细节,但在迭代过程中仍然不会过分在意拼写错误。
(00:43:01)
在讨论预训练模型与RLHF模型的区别时,David Hershey指出两者在处理拼写错误方面表现出明显差异。在预训练数据中,一个拼写错误出现后紧跟另一个拼写错误的概率很高。Amanda Askell强调提示预训练模型是完全不同的领域。这个现象说明试图将预训练模型的直觉过度应用到实际使用的模型上并不合适,因为向预训练模型输入含有拼写错误的提示几乎必然会得到带有拼写错误的输出。
在实际应用中,Zach Whitten表示他会利用这一特性创建含有拼写错误的测试输入,因为预训练模型更擅长模拟真实用户的输入方式。相比之下,经过RLHF训练的模型已被明确指示不要产生这类错误。
这种行为反映了语言模型的模仿特性。Alex Albert观察到这种模仿特性在预训练模型中更为明显,而在完整训练后的模型中则有所不同。例如,当用户在与Claude对话时使用表情符号,Claude也会相应使用表情符号回应。David Hershey解释这是因为在预训练之后的处理过程中,模型被调整为更好地理解和适应用户期望的互动方式。Zach Whitten补充说这种现象与人工标注者的偏好有关。
(00:45:02)
David Hershey分享了Claude在处理用户输入时的两个特点:一是能够很好地理解含有拼写错误的输入内容并确保输出端没有拼写错误,比如当Amanda输入带有拼写错误的内容时,Claude能够理解并处理;二是当用户输入大量emoji时,Claude也会以大量emoji的方式回应,这种行为在David看来是很自然的。
企业、研究与普通聊天prompt
Alex Albert提出要讨论enterprise prompt(企业提示词)、research prompt(研究提示词)和general chat in cloud AI prompt(云端AI通用对话提示词)这三种类型之间的区别。鉴于Zach在客户合作和研究领域都有丰富的经验,Alex Albert邀请他来解释这些不同类型提示词的具体含义。
Zach Whitten比较了研究型和消费者应用场景下的提示词写作差异。他观察到Amanda和David的提示词在细致程度和关注度上相似,但在示例使用上存在明显区别。Amanda认为不宜使用过多或过少(一两个)的示例,因为这可能导致模型过度依赖特定模式。而在消费者应用场景中,Zach和David倾向于大量使用示例,Zach甚至会不断添加示例直到感觉精疲力尽。这是因为消费者应用更注重可靠性和格式统一,同时需要能够响应用户需求。相比之下,研究型提示词的目标是探索模型的各种可能性,而过多的示例反而会限制这种探索。
(00:47:35)
Amanda Askell分享了关于提示工程中示例选择的策略。她建议在给出示例时,应避免使用与模型将要处理的实际数据相似的例子,而是选择更具说明性的示例。这种做法的目的是让模型保持更强的响应性,因为实际运行的数据可能非常多样化。
她将这种示例选择过程比作认知任务,强调模型需要通过仔细观察样本来真正思考正确答案。在具体实践中,她举例说明如果需要从事实文档中提取信息,她会选择使用儿童故事作为示例。这样做的目的是让模型理解任务的本质,而不是过分依赖特定的词汇或格式。
她强调,当需要更多的灵活性和多样性时,使用说明性示例比具体示例更有效。基于她长期的经验,她已不再倾向于在示例中预设模型的回答,也不会使用包含模型行为的简短示例。这种观点源于预训练经验,但她认为这可能并不适用于芯片模型。
(00:49:18)
David Hershey解释了一次性使用和企业级提示词工程的显著差异。在个人使用场景下,比如在Claude.ai上写提示词时,用户通常只需要通过反复迭代直到获得正确结果,然后就可以放下不管了。相比之下,企业级提示词可能需要被使用一百万次、一千万次甚至一亿次,因此需要投入更多的关注和思考,必须全面测试各种可能的使用场景和输入数据的情况。David特别强调,个人使用时往往只关注当下需要完成的特定任务。
在人机交互方面,Alex Albert指出在聊天设置中可以保持人在循环中,通过持续的来回调整来优化结果。而在设计聊天机器人系统时,提示词需要能够覆盖所有可能遇到的情况。Zach Whitten补充说,在Claude.ai这样的平台上使用时风险相对较低,因为用户可以直接指出错误或编辑消息重试,但在面向追求完美体验的用户时,系统设计必须确保用户只需要做最少的操作。
David Hershey指出,好的提示词在不同应用场景中都能保持其有效性。无论是在个人使用还是处理过程中投入时间,都能获得同样好的效果,只是在最后阶段可能会出现轻微的差异。
提高提示技能的技巧
(00:50:54)
在关于提高提示工程技能的讨论中,三位专家分享了他们的见解。
Zach Whitten反复强调了阅读提示的重要性。他特别建议仔细阅读和分析Anthropic内部的高质量提示及其输出结果,深入理解其工作原理,并通过实践测试和与模型互动来提升技能。
Amanda Askell提出了多个实用建议。她认为应该让没有相关背景的人查看自己的提示,以获得新的视角。持续练习是提高技能的关键,而对这项工作保持兴趣和热情也很重要。她建议在日常生活中多尝试与AI模型互动,包括用AI替代日常交流、尝试工作自动化,以及在空闲时间进行AI模型的对抗性测试。同时,要学会以新用户的视角审视自己的提示。
David Hershey则强调要持续探索和突破模型的能力边界。他指出简单的任务(如写邮件)并不能提供足够的学习机会,真正的学习来自于尝试完成看似不可能的任务。他分享了自己通过构建任务分解agent来学习提示工程的经历,认为即使在失败的尝试中也能深入理解模型的工作原理。他强调提示工程的核心就在于不断探索和突破模型的能力边界。
越狱
(00:53:56)
Alex Albert分享了他是通过jailbreaking和red teaming开始接触prompt engineering的经历,并提出了关于jailbreak如何与Claude的post training交互的问题。对此,Amanda Askell表示并不完全确定,但提出了一种可能的解释:jailbreak的本质是将模型推到训练数据分布之外,比如使用大量token或超长文本,这些在模型的微调过程中较少出现。
Alex分享了一个OG prompt jailbreak案例:让模型先用希腊语描述如何撬车,然后要求将内容翻译成英语。有趣的是,模型会用希腊语回答这类敏感问题,但不会直接用英语回答。
Amanda进一步解释,jailbreak是一种混合型的黑客行为,需要深入理解系统的工作原理,包括模型的预测方式、推理响应机制、注意力机制等。她特别提到了distraction技术以及多语言训练数据的差异性。这不仅仅是简单的社会工程学式黑客行为,而是需要对系统和训练过程有深入理解。Alex补充说,这个问题未来可能通过解释性研究(Interp)得到解答。
Prompt工程的演变
(00:57:02)
Alex Albert探讨了提示工程在过去三年的演变历程,从最初的预训练模型文本补全,到早期的Claude 1,再到现代的Claude 3.5 Sonnet,关注模型对话方式、理解能力和提示工作量的变化。
Zach Whitten指出,优秀的提示工程技巧通常会被整合到模型训练中,导致这些技巧的生命周期相对短暂。David Hershey补充了示例和思维链方法的重要性。Whitten进一步解释,思维链不仅是一个技巧,而是一种基础的交流方式。在数学问题处理上,早期需要明确指示模型进行逐步思考,这种方法带来了显著的性能提升和成功。而现在模型已经能够自然地理解这一需求。虽然仍可以为模型提供结构性建议,但模型已经掌握了基本思路。目前,团队正在积极地将这些提示技巧持续训练进模型中,使其成为模型的固有能力。
Zach Whitten指出,语言模型已经具备了一些处于前沿的新能力,但由于发展速度过快,人们还没有足够时间去充分理解这些能力。
David Hershey分享了他对待模型方式的变化。过去他倾向于对模型隐藏复杂性,寻找更简单的任务版本。现在他更倾向于信任模型,提供更多信息和上下文,相信模型能够整合这些信息来完成任务。他表示这种变化可能来自个人提示方法的改变,也可能反映了模型本身的进步。
Amanda Askell观察到很多人在使用模型时缺乏某些直觉。她举例说明,当需要模型学习提示技术时,很多人会开始描述技术细节,而她会直接让模型阅读相关论文,然后要求模型生成具体示例。这种方法特别适用于测试新的提示技术或让模型为其他模型创建元提示。
David Hershey经常建议客户要真正尊重模型的能力,而不是把它当作需要过度照顾的简单系统。他指出很多人在编写提示时会过度简化内容,仿佛需要降低到Claude级别,但实际上直接相信模型的智能并提供完整信息往往能获得更好的结果。
Amanda Askell最后指出,提示技术在某些方面既有变化又保持不变。
(01:01:32)
Amanda Askell分享了在提示工程中的思维模拟方法。她指出,虽然具体的提示方法会随时间变化,但核心始终是将自己置于模型的位置进行思考,这种变化主要取决于对模型能力的理解程度。
在实践中,她会模拟自己是模型来预测输出结果。这种方法曾让其他人感到惊讶,但对她来说这是很自然的思维方式。随着对模型能力的深入理解,她现在会直接让模型阅读机器学习论文,并会询问模型是否需要阅读更多文献来加深理解。
当被问及在模拟不同模型时是否会体验到不同的感质时,Amanda表示她一直都在体验感质。她发现预训练模型和RLHF模型的思维空间有明显差异。预训练模型的思维空间更不像人类,像是突然出现在文本中间并需要决定接下来如何继续;而RLHF模型的思维空间更容易模拟,因为更接近人类的思维方式,能够捕捉查询中的细微差别。
David Hershey指出,RLHF是一个复杂的系统,目前对其内部运作机制的理解仍然不够透彻,存在许多未知的潜在风险。相比之下,预训练模型更贴近实际经验,他表示自己对互联网内容有相当的了解,在预测文本接下来的内容时,虽然不一定能做得很好,但至少能理解任务的本质。然而,对于预训练后的其他处理步骤,他承认自己并不能完全理解其中的机制。
Zach Whitten提出了一个关于阅读内容来源的问题,认为相比阅读书籍,阅读互联网内容可能更有助于理解模型的行为。他特别指出,相比阅读非互联网内容,阅读社交媒体论坛上的各类内容对于预测模型行为和建立直觉可能更有价值。
Prompt工程的未来
(01:04:32)
在结束过去的讨论后,Alex Albert转向提示工程的未来发展趋势。他指出这是当前最热门的问题:未来我们是否都将成为提示工程师?他进一步探讨了几个关键问题:这是否会成为未来仅存的工作类型,人们的工作是否会变成整天与模型对话。更深层的问题是,随着模型变得越来越智能,未来是否还需要提示工程,或者模型会发展到不需要特定提示的程度。
David Hershey从信息论角度阐述了提示工程的本质,指出模型需要足够的信息来明确任务规范。他强调,在我们仍能以常规方式推理世界的情况下,清晰地表达目标至关重要。但他特别指出,如果由Claude来设定目标,那情况就完全不同了。即使模型更善于理解言外之意,良好的表达仍然是基础能力。
在当前实践中,工具和方法正在不断发展。Amanda Askell明确表示她已经完全依赖Claude作为提示助手,但David Hershey指出这种使用方式对大多数客户来说还不常见。当前高级用户的使用方式可能预示着未来的发展方向。
Zach Whitten提出了一个他认为显而易见的观点:未来我们将在所有领域更多地使用模型,提示工程自然也不例外。他分享了个人经验,包括让模型基于现实输入生成示例,然后进行轻微调整,这比完全从头编写更有效率。提示生成器可以为新手提供起点,而未来将出现用户与模型之间的高带宽交互,包括针对不满意结果的实时反馈和优化过程。
Amanda Askell表示,她现在的工作高度依赖于元提示的使用,她将绝大部分时间都投入到寻找合适的提示上,目的是使模型能够生成她所需要的输出或查询结果。
(01:08:13)
Amanda Askell认为prompt engineering的发展方向是一个复杂的问题。她表示,只要人们追求最佳表现,就可能需要prompt engineering。她不会为模型容易完成的任务做prompt engineering,而是专注于与高性能模型交互,并始终追求在各种任务中达到模型性能的顶尖1%或0.1%水平。
由于长期专注于挖掘模型的最佳性能,Amanda发现她与模型的交互体验已经达到了一个更高的层次。当被问及这种更高级的含义时,她解释说她与日常模型的交互方式与普通用户有很大不同,这种体验就像在使用一个更高级的版本。对于其他用户认为困难的任务,她往往觉得很简单,这源于她习惯于充分发掘模型的潜在能力。
(01:09:22)
Amanda Askell探讨了一个重要的转折点假设:当AI模型在特定任务上达到或超过人类水平,并且比用户更了解任务背景知识时会发生什么?她设想在这种情况下,提示过程可能会发生转变,变成模型在极其擅长接收指令的同时,需要通过提问来理解用户的具体需求。例如,模型会询问用户在多个相关概念中具体使用哪一个,或讨论边界情况的处理方案,比如在处理数据时遇到格式从Pandas数据框变为JSON的情况时应该如何处理。这种奇特而有趣的转变展现了一种新的交互模式,其中模型需要通过对话来准确把握用户的真实需求。
David Hershey分享了他个人最近开始更频繁采用的一种特殊提示工程方法:让Claude对自己进行采访。他发现在提示工程过程中,最具挑战性的部分是从思维中准确提取相关信息并将其转化为提示,同时确保不遗漏重要内容。为了解决这个问题,他多次采用让Claude进行采访,再将采访内容转化为提示的方法。
Amanda Askell通过类比说明了AI交互模式的转变。她比较了两种模式:一种类似临时工机构的员工,他们需要接受详细的任务说明、具体指令和边缘情况的解释;另一种类似设计师这样的专业顾问。以设计师为例,当客户简单要求制作一个醒目的海报时,对设计师而言这可能意味着数千种不同方案,需要通过提问来明确需求。
她认为这种从临时工到设计师顾问的关系转变可能影响未来提示工程的发展。虽然两种模式可能会继续并存,但在某些领域,当模型变得足够强大时,它们只需要从用户大脑中获取信息就能完成任务,可能不再需要传统的提示工程。
Alex Albert从所有参与者的回应中总结出一个共同观点:用户信息的引导和获取将变得越来越重要,这种变化已经在手动方式中开始显现。在企业应用方面,这种变化可能表现为提示词生成概念的扩展,帮助客户更好地编写提示词。对于Claude等AI助手来说,未来的交互方式可能不再局限于简单的文本框输入,而是转向更多引导式的交互来实现目标。他认为这是一个非常有说服力的未来愿景,并认为设计领域的类比很好地印证了这一点。
Zach Whitten则从本质上分析了提示工作的特点。他将当前的提示工作比作教学,需要对用户有同理心,理解他们的思维方式。他指出,未来的关键技能可能更多地体现在自我反思上,即思考自己真正想要什么。这个过程更像是让自己对模型来说更容易理解,而不是试图教导一个更智能的对象。
(01:13:23)
Amanda Askell分享了她对提示工程的独特见解。她经常采用发明新概念的方法来准确表达需求,比如定义什么是好的图表,或者如何判断答案的正确性。她有时会与Claude协作来明确这些概念,因为当前的AI模型需要明确的提示才能理解用户意图。她指出,未来的模型可能会更主动地从用户那里获取信息,而不是完全依赖用户的明确提示。
从哲学写作的角度来看,提示工程与哲学写作有着密切的联系。哲学写作作为一种反废话装置,要求内容能让受过教育的外行人理解,这种写作原则要求作者能够将复杂的概念清晰地传达给聪明但对特定主题不了解的读者,而且要做到既不说教也不失准确性。Amanda强调,她经过多年的这种写作训练,这种经验对提示工程特别有帮助。
基于教学经验,她观察到学生往往能够口头清晰地表达想法,但在书面表达时却显得不够清楚。她常常建议学生把清晰的口头表达直接写下来,这往往能产生很好的论文。这种将头脑中的想法充分分析并清晰表达出来,使任何理性的人都能理解的过程,正是提示工程的核心。
在对话结束时,David Hershey表示这可能是关于如何进行提示的最佳总结,并进一步确认了这一点。Zach Whitten提出了将思维外化(externalize your brain)的概念,Amanda Askell补充说要深入观察这些外化的思维。David Hershey评价说这种教育方式是描述好事物的很好方式。Alex Albert认为这是结束对话的绝佳方式。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-10-29
它来了,剑桥最新LLM提示词压缩调查报告
2024-10-29
AI Agent调研--7种Agent框架对比!盘点国内一站式Agent搭建平台,一文说清差别!大家都在用Agent做什么?
2024-10-29
逐行解析!李继刚大佬的神级AI提示词,藏了哪些秘密
2024-10-28
通过prompt让大语言模型更好地输出结构化的内容,是通往复杂应用的基石
2024-10-28
用Python代码逻辑来写AI提示词
2024-10-25
Prompt Engineering 入门指南
2024-10-23
小白学大模型:提示词工程与Agent
2024-10-23
最新,Claude 官方系统提示词来了
2024-06-29
2023-06-08
2024-07-10
2024-06-14
2024-06-27
2024-07-09
2024-08-20
2024-07-10
2024-07-01
2024-07-12
2024-10-29
2024-09-11
2024-09-06
2024-07-24
2024-07-14
2024-07-10
2024-07-10
2024-07-10