开拉

I HATE 提示词工程（Prompt Engineering），就像I HATE 释出（release）一样。

从初次见到“提示词工程”这个词伊始，我就觉得不妙。睿智如我一眼看出这是弱智机翻与审稿人垃圾洋文水平悲惨结合的诞牲品。一如市面上英语学习软件/资料有多多，群众的学习持续性与实用英语就有多差。屎一般强劲taste的传统机翻与苹果一般英文水平的广大群众只能协奏一曲吃了迷幻菇一般的大喷菇狂想曲——不信不达也不雅。

如我所料，随着LLM的爆火，各平台媒体逮着个名词就争先恐后地到处broadcasting。翻译质量？棘手且路边一条——现在好了，所有人都叫Prompt Engineering为提示词工程了！てめーら还不如speak洋文呢洗八呀TAT

这回借着喷古神翻译¹，一同讲讲我对提示词工程、上下文工程²的认识。

“提示词工程”屎在哪里？

屎在没有传达有效信息的同时还有迷惑性，简直和医学英语³有异曲同工之妙。

普通大众看到这个提示词工程，脑袋里首先就会想“提示词”？我是要给他提示吗？从头开始就误导了prompt思路，还与传统chat情景相割裂。

“指令工程”好在哪里？

说实话也不算贴切。但我相信随着时间与实践的沉淀，这个词会成长出自己的底蕴。而不是在某个机翻笑话下积淀。

“上下文工程”强在哪里？

我觉得这个概念是指令工程实践到一定程度后总结诞生的、更贴切模型原理的新视角⁴。

常规来讲，我们习惯一问一答。我们当下需要什么，就拟定一下prompt发过去。模型收到我们的输入，会开始生成输出。后台数据传输大致可以简化为：

<data>
<user>用户发送的内容</user>
<assistant>模型生成的内容</assistant>
</data>

众所周知，模型可以基于前文和我们多轮对话。 后台数据传输大致可以简化为：

<data>
【<user>用户发送的内容1</user>
<assistant>模型生成的内容1</assistant>
<user>用户发送的内容2</user>
<assistant>模型生成的内容2</assistant>
<user>用户发送的内容3</user>】
<assistant>模型生成的内容3</assistant>
</data>

华点在于： 多轮对话时，模型收到的是“对话历史+你最新发送的内容（也就是我用【】包裹的内容）”。也就是说，过去所有记录⁵共同构成一个prompt引导模型生成内容⁶！视角打开——

这就是，上下文工程！

你需要考虑模型是怎样被训练的？有什么记忆/理解特点？从结果上看模型读文本有什么特点？以何种方案管理会话历史能最大限度的引导模型注意力，才能让其尽可能输出更为优质的内容？

后话

这篇骂的好脏，但不算畅快——哥苦叠甲久矣，宝刀失利。没灵性了，噫嘘唏！

顺便一提，我发现最近输出的文章里提示词浓度好高。这种非实学真是让人来得心虚⁷。无所谓，我会——

༺✿꧁沉淀༒顶峰相见꧂✿༻

Footnotes

1. 指在LLM爆火的时代、传播LLM相关资讯的文章的人选择传统机翻速通新技术译名的不可名状又古典的操作。 ↩

2. 我确实觉得这个没什么好说的，但上次参加了公司的提示词培训，那念稿中故意带点迟钝装作free speak的同时搀杂点口胡且在最理当深度说明的地方一笔带过的分享听得我无语凝噎屏幕映泪眼。一想到对方工资必定比我高我就面目却非阴暗爬行。 我意识到此次写下我的见解确实有点价值。 ↩

3. 通过反常识反直觉的词根词缀命名规律成功凭空架起本不必要的门槛，一如垄断圣经解读权的教会。当然我的文章埋这么多逆天梗何尝不是在架设一种地狱门槛。 ↩

4. 而不是某个培训分享中说的随着技术进步要求变高而诞生的。尼玛的这是什么雷霆思路？八竿子打不着吧。你是在发通稿吗？整个培训看下来只有合规这一块讲得最顺。 ↩

5. 这里就先不聊什么对话窗口上限、优化大文本记忆之类的了。 ↩

6. 这也意味着所谓系统提示词、用户提示词、助手提示词本质上是注入次序和字段的不同。但我也听说从训练视角来看，你不能随意修改系统、用户输出内容的标签。我将其大体和batch size大小归类为同样问题：理论上不影响，实际上居然真的有影响？ ↩

7. 你以为我要开始励志修习显学了？哈哈，才不是！上一个订阅的生产力频道主说“知识先于方式”之后仍然高强度输出两年生产力工具折腾方案。我才不要立这种flag呢。 ↩