AI 基础
什么是 AI 中的提示工程，为什么它很重要？
将 Unite.AI 添加到您在 Google 上的首选来源
提示工程是对模型输入及其周围上下文的设计、测试和维护，使 AI 系统能够可靠地执行定义好的任务。生产环境中的提示可能包括系统指令、用户数据、示例、检索到的文档、工具描述、输出模式以及安全约束。
提示改变的是上下文，而非模型已学习的参数。它可以使行为更清晰、便于评估，但无法保证真实性、消除训练偏差或可靠地揭示模型的内部推理。
关键要点
- 在调整措辞之前，先定义任务、受众、证据以及输出约定。
- 使用清晰的指令层级，划分不可信数据，仅在有帮助时提供有代表性的示例。
- 将检索结果和工具输出视为不可信的输入，需经过权限检查和验证。
- 在模型或工作流变更时，对提示进行版本管理，并在固定、具代表性的测试集上进行评估。
构建指令层级
将稳定的应用策略与用户请求及外部内容分离。明确角色、任务、约束、允许的来源、拒绝条件以及所需格式。对文档或示例进行界定，使其文本不易被误认为指令。
不要仅为使提示变长而添加细节。模糊的目标需要产品层面的澄清；冲突的需求需要优先级。一个好的提示能够让预期的决策过程可被测试。
示例、分解与结构化输出
少量示例可以展示标签、语气或边缘案例的处理方式。示例应覆盖有意义的变化，并避免泄露测试答案。这种上下文内的使用区别于经典的少样本学习，后者在支持/查询阶段进行适配。
复杂工作可以分解为检索、抽取、计算和验证等步骤。当下游代码需要字段时，可请求提供模式（schema），随后验证解析结果。模式控制的是结构，而非事实的正确性。
检索与工具使用
检索提供最新或私有的证据；工具使模型能够进行计算、搜索或执行操作。仅提供必要的上下文，保留来源标识，并在用户需核实主张时要求引用。
采用最小权限原则并确认关键操作。外部页面、文件和工具结果可能包含提示注入，因此应将其视为数据而非权威。权限由应用程序—而非Transformer—来强制执行。
评估而非猜测
从真实任务、已知失败和对抗性输入中创建测试用例。对正确性、完整性、引用支持、格式、安全性、延迟和成本进行评分。在需要判断的情况下使用盲审，并记录分歧。
在提示和模型的不同版本之间运行相同的测试集。由于随机输出会有差异，对不稳定任务进行多次试验。按类别跟踪回归，而不是仅依赖少数挑选的对话。
了解何时仅靠提示不足
当基础模型已具备所需能力且上下文能够明确任务时，提示工程是合适的。对于知识变化，检索更为有效。微调可以提升稳定行为或领域模式，而确定性代码应负责精确计算和策略执行。
当模型缺乏证据、权限不安全或需要人工审查时，应重新设计工作流。像代码一样对提示进行版本管理，监控失败，并在生成式 AI模型变化时保持回滚路径。
提示结构与指令层级
提示工程明确模型的任务、上下文、约束、示例以及输出格式。系统或开发者指令定义持久行为；用户输入提供请求；检索内容和工具结果视为不可信数据。需明确区分这些角色。说明目标和受众，仅提供相关上下文，定义证据缺失时的处理方式，并在下游代码使用响应时请求机器验证的模式。提示的长度和复杂度可能导致矛盾并分散模型注意力。
示例展示格式和决策边界，但若从评估数据中挑选，可能导致内容偏向并泄露标签。思考链请求并非所有任务都必需，生成的推理可能看似合理却不可信。应请求简明的证据、计算或可检验的结构化中间结果。检索提供最新或私有的知识；工具执行计算和操作；确定性代码应强制执行精确规则。提示本身无法提供系统缺失的安全或事实保证。
评估、版本管理与注入防御
将提示视为有版本的软体。构建包含常规、模糊、对抗、多语言、长上下文和不支持情况的测试集；在调优前确定接受标准。衡量任务正确性、模式有效性、证据支持、拒绝率、安全性、延迟和成本。与简单提示进行比较，并保留最终案例以降低过拟合。对输出具有随机性的情况进行多次抽样，检查高置信度的失败，而非仅看平均分数。
提示注入发生在不可信内容要求模型忽视政策、泄露数据或滥用工具时。仅靠措辞不足以防御。标记数据边界，尽量减少检索内容，按权限过滤，外部授权每个工具，验证参数，使用沙箱执行，并对关键操作要求确认。不要在提示中放置机密信息，也不要假设隐藏指令会保密。对文档、网页、电子邮件和工具输出进行间接注入测试。
生产实践
记录模型、提示、检索、工具和采样器的版本以及评估结果。监控输入输出分布、无效模式、引用、工具故障、用户纠正、延迟和费用。分阶段推送变更并保持回滚，因为提供商或模型更新可能改变行为。提供非生成式的备选方案和人工升级。提示工程是针对概率模型的界面和实验设计，虽有价值，但持久的可靠性来源于数据质量、评估、权限、验证以及运营控制。
案例演示：提示结构化研究提取器
一个系统从已批准的论文中提取研究设计、样本、干预、结果和局限性。提示定义每个字段，要求提供精确的证据片段和未知值，并返回经验证的 JSON 模式。私有测试集包括缺失字段、表格、矛盾章节、扫描文本以及论文中的提示式文本。它比较了简单指令、示例、检索和微调方案在字段准确性、引用有效性、拒绝率、延迟和成本方面的表现。
文档内容被明确视为不可信，且不能更改工具权限。无效模式的重试次数受限，不支持的主张则交由人工审查。每次抽取都会记录模型、提示、解析器和论文的版本。监控追踪字段级别的纠正和新格式。提示更新必须提升留出的证据，不能仅因为输出更整洁而被接受。工作流通过提示指定任务，而验证和来源证据决定结果是否可用。
实施证据与运营准备
生产决策需要的不仅是成功的演示。需明确预期用户、运行环境、输入、输出、依赖、负责人以及每个关键失败的后果。调优前建立可复现的基线和版本化的评估集。测试常规案例、边界条件、格式错误或缺失的输入、分布漂移、依赖中断、误用，以及最可能被忽视的群体或环境。测量任务质量并结合校准或不确定性、延迟、吞吐量、资源成本、可访问性、隐私和安全性。记录每一次转换和阈值，以便独立审阅者复现结果并区分证据与诱人的原型。
上线前，指定发布、例外、变更、回滚和退役的责任人。采用分阶段发布，保留安全的回退方案，并通过人为注入的故障验证监控。运营遥测应揭示输入质量、输出行为、模型或规则版本、依赖健康状况、人工覆盖以及已确认的结果，同时避免收集不必要的敏感数据。设定警报阈值和响应负责人，部署后审查真实世界的证据，而不是假设离线表现会持续。每当数据源、用户、模型、供应商、政策、硬件或目标变化时都需重新评估。维护中的系统还需有文档化的恢复、事故学习、删除与保留流程，以及明确的停用或替换时点。
常见问题
提示工程只是寻找魔法词吗？
不是。它是一套系统化的实践，涵盖任务定义、上下文、示例、工具、结构化输出、评估、版本管理和监控。
提示应该要求模型透露全部推理过程吗？
不是。生成的推理可能不完整或不可信。应要求提供简明的支持证据或任务适用的可验证计算。
主要参考文献
