Andrej Karpathy:
相比起“提示工程”(prompt engineering),我更倾向使用“上下文工程”(context engineering)这个词。
为什么呢?
因为大多数人一想到“提示”,就联想到我们日常跟大语言模型(LLM)互动时,输入的那些短小的任务描述或问题。而在工业级的 LLM 应用场景中,“上下文工程”指的是一种精妙而复杂的技术:你要精准地将上下文窗口填充上恰到好处的信息,让模型能准确地迈出下一步。
这是一门科学,也是门艺术。
说它是科学,因为你要把任务描述、说明、少量样例(few-shot examples)、检索增强生成(RAG)、各种相关数据(甚至可能是多模态数据)、工具、状态、历史信息等全部巧妙地组合在一起,同时还要考虑如何压缩信息。这就像烹饪一道精致的菜肴,配料太少或搭配不对,模型无法获得足够的信息,性能会变差;配料太多或毫无关联,则会增加成本甚至降低表现。要做好这件事,需要的不仅仅是简单堆叠,更是高度专业化的技巧。
说它是艺术,则是因为操作者还要掌握一种近似“心理学”的直觉,敏锐地洞察 LLM 和人类用户心理之间的微妙互动。
除了上下文工程之外,一个工业级 LLM 应用还要:
- 将复杂问题巧妙地拆解成合理的控制流程;
- 精细地管理每次调用模型时的上下文窗口;
- 根据具体需求分派不同类型、能力等级的模型;
- 妥善处理生成与验证的交互式用户界面和用户体验;
- 以及更多其他任务——如安全防护、性能评估、并行计算、预取数据等等……
所以说,“上下文工程”其实仅仅是众多工作中的一环。围绕 LLM 应用,还在逐渐兴起一层厚重、复杂的软件基础设施,它的任务是协调、优化各种 LLM 调用和相关操作,组合出真正有效、有价值的 LLM 应用。
因此,以前常听到的“ChatGPT 套壳”(wrapper)这样的说法,现在看来已经不仅陈旧,更是非常不恰当了。