AI应用开发（3）

多轮对话与上下文管理大模型的无状态特性大模型具备无状态特性即每次对话独立不包含上下文信息。因此我们需要自己把历史消息一条条拼接回去每轮都手动维护上下文。msg{role:user,content:userin}respapi.chat(messages[msg])userininput(用户)#在终端输入我是小明模型回复你好小明再次调用后输入我叫什么模型回复我不确定将用户的每一轮对话都存入一个列表中在每次的对话时将这个列表中的内容给大模型作为背景大模型就可以拥有“记忆”了。但是随着对话数越来越长背景信息的token就会达到最大限制从而记不住更早的信息常见的模型上下文窗口限制在4k token或8k token 这是物理限制与代码逻辑无关。因此我们需要对上下文进行管理。上下文管理截断顾名思义截断就是保留最近的几条消息将更早的前面的对话忘掉。这种管理方式适合前后文联系不强的内容比如简单问答翻译等任务。滑动窗口策略这种方式既能控制长度又能保留重要内容。首先这种方式可以将重要信息固定为锚点从而保留信息。除此之外它还能进行动态调整实时计算token在token即将达到限制时进行截断防止暴力截断丢失重要信息。总结由于大模型具备无状态特性所以会忘记前面对话的内容因此需要将每次对话的上下文信息作为背景与新对话的问题一起给大模型这样大模型就有了记忆。然而随着对话数越来越多上下文信息会超过最大token限制这个时候就要进行上下文管理。上下文管理有两种方式一是截断只保留最近的N条对话内容前面的对话内容则丢弃然而这种方式会导致重要信息丢失比如第一轮对话的角色信息等二是滑动窗口策略将重要信息固定为锚点同时主动计算token在快要达到限制前及时丢弃前面的信息处理更加平滑。Zero-shot/Few-shot/系统提示词Zero-shot无样本示例直接向模型提问简单快捷但有时可能得不到精确的输出格式。优点操作简单快速上手零成本准备示例。当你需要快速验证一个想法或者任务本身很简单时Zero-shot 是最便捷的选择。缺点输出格式不稳定比如有时会附带无关的解释也可能完全偏离任务要求。而且性能严重依赖模型的通用能力对于需要严格格式的任务风险较高。典型的应用场景翻译、总结这类简单问题写诗、故事等创意生成以及通用知识检索。在这些场景下Zero-shot 往往能直接给出令人满意的结果。例子直接要求模型提取 JSON 数据它可能返回被 Markdown 代码块包裹的 JSON而不是纯数据这就给程序解析带来了麻烦。Zero-shot 虽然方便但在格式控制上确实容易出问题。Few-shot我们提供少量示例来引导模型输出期望的样式这大大提高了输出可控性。在提示中直接提供一组输入-输出对作为示范。比如给出一个问题和你期望的答案格式模型就会模仿这个样式来回答。而且例子不用多一般 1 到 3 个就非常有效。对比我们刚才讨论的 Zero-shotFew-shot 在格式一致性和准确率上都有质的飞跃。但有一个非常重要的注意事项你选的示例必须覆盖目标的边界情况否则会引入偏差。比如做情感分类如果只给正面的例子模型就可能把所有输入都判成正面。所以用心选好案例是 Few-shot 成功的关键。System Prompt通过设定角色和行为约束它能让模型在整个对话中保持特定的身份和规则非常适合复杂应用场景。System Prompt 位于对话的最前端它就像舞台导演为模型预先定义好角色、专业领域、输出风格甚至安全护栏。比如你可以告诉模型“你是一位严谨的法律顾问回答必须引用法条。”这样后续的所有对话都会在这个框架下运行。而 User Prompt也就是用户提示是每一次对话中我们直接提出的具体任务或问题。如果把 System Prompt 比作搭建好的舞台和演员角色那么 User Prompt 就是每一幕的台词和情节。一个负责顶层设计一个负责具体执行分工非常明确。理解了这种职责分离我们就能更高效地驾驭大模型。例子设计一个 Python 专用助手。System Prompt 明确写道“你是一名 Python 助手仅回答与 Python 相关的问题拒绝无关提问。”一旦设定无论用户怎么追问它都会坚守 Python 专家的身份这种稳定性在专用服务中至关重要。为了提高 System Prompt 的遵循度建议使用清晰的列表、加粗或“重要提示”之类的强调语法。比如用“你必须始终…”这样的强力措辞能有效降低模型偏离轨道的概率。总结zero-shot是不给例子直接让大模型生成不过生成的内容可能会有问题few-shot是给少量样本让大模型根据样本和问题生成内容例子需要覆盖边界情况尽量包含所有可能的结果以及结果的答案系统提示词则是对大模型下一个角色定义将它的岗位职责规定清楚用角色特点约束它的行为赋予它能力。