prompt工程

基本概念

prompt工程是什么？
prompt工程又称为提示词工程，通过向ai发送请求时附加额外信息从而引导模型输出与提问问题更加接近或者准确的回答，可以说提示词是入门aiagent或者应用开发要学习的第一个要掌握也是最重要的概念
一个好的，结构清晰的提示词可以无限的逼近模型的能力上限，因为大模型本质上建模的就是一个概率模型，其就是根据当前文字预测下一个最有可能输出的文字的概率。一个好的提示词可以视为一个条件引导，在这个条件引导下，原本模型预测的概率空间将会大大缩小从而提高模型预测该问题的最佳答案。
提示词分类：
系统提示词和用户提示词
用户提示词：用户向ai提供的实际问题，指令/信息，传达用户的直接需求，告诉模型需要做什么如回答问题，编写代码
系统提示次：设置的ai的行为规则以及角色定位的隐藏指令，用户一般看不到
助手prompt：ai模型的响应内容，多轮对话过程中，助手回复也会成为上下文的一部分
token：一般文字并不能被大模型直接识别，需要进行转化，token就是大模型的识别也是计算的基本单元，用户在调用ai模型时会消耗两个token 一个是输入token一个是输出token，用户花费 = 输入token * 输入价格 + 输出token * 输出价格
在开发应用的时候，就要考虑到对应的token花费成本与任务需求，如果需要精细化或者复杂推理能力的时候可以优先选择花费比较高的模型，如果只是简单的api调用或者代码检测这类简单任务就可以选择一些比较轻量以及token花费比较便宜的模型。

提示词工程的重点在于如何高效的设计高效，可复用的提示词

提示词输入与输出的结构化

基于成本考虑：精简系统提示词可以避免模型注意力稀释现象（并非越详细越好，prompt越长结合用户输入到模型的序列也就越长，模型本身对于长序列存在注意力稀疏现象，会导致每个token得到的注意力分数会下降），定期清理对话历史，当重复使用一个用户角色背景来
对模型进行prompt优化的时候，模型能力就会下降（看java guide的博客说的），因此定期清理对话历史可以避免模型退化。通过结构化代替自然语言，既可以节省token也可以让模型输出的内容更加可靠
基于内容考虑：prompt包含四部分可以优化的内容，分别是角色定位，任务描述，约束条件以及输出格式。通过明确角色定位可以激活特定的模型权重让模型使用更加专业的知识进行问题回答，除了对应的角色定位要详细以外还要提供详细的说明和具体实例，也就是任务描述，
可以引导模型理解复杂问题的上下文背景，以及期望得到的内容。约束条件如输出或者思维链使得问题拆解方式可以帮助模型将复杂的问题一步步的分解为小问题，减少模型幻觉并且格式化的输出格式也可以让模型更好的理解作者的需求，输出作者期望的结果。
基于提示词工程设计考虑：通过将复杂的用户需求进行分发以及聚合实现用户需求的实现，如在复杂ai系统中，通常会通过skill来帮助模型去逐步的理解以及解决问题，当用户提出复杂的需求比如我想要你帮我设计一个分布式后端微服务程序的时候，模型会调用对应的搜索agent进行任务编排，寻找到对应的系统设计提示词后讲用户输入与搜索的提示词结合发送到对应的编程ai中，ai根据具体的提示此进行任务的执行并返回任务完成结果给上一个调用的ai，这样就构成了一个复杂的ai调用，而ai的调用就是根据提示词路由系统进行分发的

复杂问题的链式与模块化设计

针对复杂问题可以采用进阶技巧：
思维链提示法：通过将问题拆分为一个个可以思考的子问题，引导模型进行推理并逐步思考问题，提高模型回答复杂问题的准确性
少样本学习：提供少量的输入-输出样本对，从而帮助模型理解任务模式以及期望输出
分步骤指导：将复杂问题拆分为课管理的步骤，确保模型完成每个关键环节
自我评估和修正：可以利用大模型去自己评估自己的输出，并根据输出进行改进从而提高模型的准确性以及质量
利用rag：为模型提供对应的知识库，模型在回答问题之前先搜寻与问题相关的内容然后将用户内容作为背景信息结合用户提示词整理为新的prompt然后再传入模型，从而提高模型回答问题的准确性和缓解幻觉问题
多角度，多模态思维：引入多个知识专家模型，让每个专家从自己的角度对回答进行分析与优化然后汇总后输出从而提供更加全面以及专业的视角分析，通过思维导图，表格结构以及代码逻辑来实现相应的功能，从而减少模型的输出幻觉
除了上述系统化进行提示词的设计以外最重要的就是迭代优化，提示词并不是写完就可以了，还需要进行测试以及迭代优化，通过逐步的修改和完善提示词从而提高输出质量，针对用户的特定需求进行提示次的设计，设计完成后通过机器以及人工进行评测得到对应的效果的定性和定量结果，对量化成果进行归因分析，分别针对提示词的不同角度进行优化然后重复上述实验进行迭代优化，以达到期望的模型输出效果。

如何测试提示词是否满足要求

1 要根据业务设定对应的分析指标，不能只能从经验角度出发进行人工评价
比如关于金融和法律领域，根据输入模型输出对应的结果，可以通过回答结果的关键词数量以及词义相关性两个角度进行评估，避免纯人工的校验
2 模板化分析
先让模型输出格式化的结果，通过与标准的输出模板进行比对从而得到对应的定量指标

上下文工程

上下文工程可以视为prompt工程的进阶版，将系统prompt与用户prompt进行组装后发送给模型，上下文中包含了系统提示词，用户提示词，短期对话历史以及当前用户的输入，通过上下文工程模型可以在单次访问中得到历史对话文本，从而产生连续对话的现象，上下文中提供了模型可能用到的任何信息，如skill的元信息都是通过上下文整合的，模型在读取上下文的时候会根据用户需求选择合适的skill进行加载然后调用mcp去执行相关指令。模型在解题，而上下文就是用户提供给模型的题目描述。
因此上下文工程也是应用开发和设计时需要考虑的一个关键，如果让模型在有限的上下文窗口中看到想要的信息以及利用有限的信息去执行任务。
工业级的 LLM 应用中，上下文工程是填充上下文窗口以提供恰到好处的信息的艺术和科学，以便为下一步提供正确的背景信息。这是一门科学，因为正确地做到这一点需要任务描述和解释、少量示例、检索增强（RAG）、相关（可能跨模态）数据、工具、状态和历史记录，以及信息的压缩……如果信息不足或形式不对，LLM 将无法获得最佳性能所需的正确背景。如果信息过多或不相关，LLM 的成本可能会增加，性能可能会下降。做好这一点是非常非平凡的。而这也是一门艺术，因为它涉及到对 LLM 心理学和人类直觉的指导性理解。

上下文工程面临的挑战

上下文污染，上下文干扰，上下文混淆，上下文冲突
污染：模型对不存在的物品进行重复调用，模型出现幻觉，并且将幻觉事务视为当前状态
干扰：上下文过长的时候，模型倾向于重复之前的行为而非生成新计划，路径依赖，惯性输出
混淆：当提供的工具多且功能相似的时候，模型表现能力变差，功能过载，边界模糊
冲突：连续的工具调用彼此矛盾，模型表现会变差，逻辑互斥
针对上下文工程面临问题所采取的解决思路：
1 转移上下文负担
大模型虽然现在可以接受的输入窗口变得越来越大随着对话轮次增加，历史记录中的噪声信息会挤压当前任务指令的注意力权重。因此采用分层记忆架构：将完整历史转移到外部记忆系统，通过检索机制按需加载相关片段到上下文窗口，从而维持高信噪比。
2 精简上下文
既然窗口长度有限，注意力很宝贵，那就尽量的压缩上下文窗口，通过每次对话的时候只保留前两轮对话并删除历史中不相关的信息来保障窗口的干净以及准确
3 检索上下文
将上下文存储的文件中，面临再次需要时查找的问题，如何更加准确的检索出对应的历史对话以及上下文也是以一个重点：可以结合多种检索方法与重排技术，构建一个可以将多种检索结果整合为提示词的系统，根据工具描述检索相关工具等
4 隔离上下文
采用分而治之的思想，既然上下文太长不可以，我就像拆分具体任务一样，也将上下文按照一定的规则进行拆分，每个上下文窗口让一个agent进行处理，避免决策冲突问题
5 缓存上下文
提示词缓存：基于KV-Cache复用，将用户输出的提示词前缀进行缓存，下次输入的时候将用户输入拼接到缓存前缀后，可以提高模型的缓存命令率，避免重复计算对应额token，比如你要翻译xxx公司的相关说明文档，今天查完之后，软件将你查询到前缀缓存了起来下次你再输入的时候他会将缓存的和你的拼接到一起去计算token，因为前面的已经计算过了，每次计算的都是后面的这一部分

除了上下文工程本身之外，一个 LLM 应用还需要：将问题恰当地拆分成控制流；把上下文窗口调整得刚刚好分配合适的 LLM 调用；处理生成-验证的 UI/UX 流程；还有很多 - 边界限制、安全措施、评估、并行处理、预取 ...；
六种上下文管理策略（后续再看）
RAG（检索增强生成），选择性添加相关信息辅助大语言模型（LLM）生成更好回复；工具加载，仅选择相关工具定义添加到上下文；
上下文隔离，将上下文隔离在专用线程；
上下文修剪，从上下文中删除无关或不需要的信息；
上下文总结，把累积的上下文浓缩为摘要；
上下文卸载，通过存储和管理数据的工具将信息存储在 LLM 上下文之外