LLM 上下文角色：咱就是说这事儿可大着呢！

嘿，大家好 👋！我是 Moment，Zui近在搞一个 DocFlow 项目，用 Next.js、NestJS、LangChain 啥的。这个玩意儿是 AI 场景下的文档协作平台，挺酷的哈哈。对了别忘了给 DocFlow 点个 star ⭐ 哦！

你懂的，AI 技术现在火得不得了。搞 LLM 交互的时候，有个关键问题是：咱怎么组织上下文才Neng让模型稳住？别小kan这事儿，其实挺重要的。

咱先说说 LLM 的上下文角色吧。简单来说就是把对话分成几层，让模型知道自己在干啥。就像盖房子一样，得有地基、墙体、屋顶才行。

LLM 的上下文角色主要分为四种：开发者 、用户 、助手 和证据 。听起来有点绕吧？咱来细说哈。

*开发者 *: 这是长期行为约束层。比如“你是中文技术助手，回答清晰准确”这种东西就放这里。它定义了模型应该怎么工作，像给它定个底线一样。

*用户 *: 这是本轮任务目标层。你现在想让模型Zuo什么？比如“解释什么是 RAG”，就放这里。

*助手 *: 这是多轮对话历史层。当用户和开发者dou没写的时候，这个层就接上来了。确保对话连贯性嘛！

*证据 *: 这是外部事实层。比如工具返回的结果、数据库查询结果啥的dou放到这里头去吧！别把这些东西当成普通话聊啊！

哎呀，有时候会搞混啊！咱要记住这四层结构的原则：规则放在高优先级处，任务放在用户那里历史放在助手里证据放在独立输入那里。 结构越清晰越好！

在多轮对话中，助手 的历史越来越重要了哈！Ru果历史太长或者乱糟糟的，那后续的稳定性就会直接下降哦！所以要精简历史记录嘛~ 别堆砌啊！

举个例子： developer + user 基础搭好后加一些必要的 assistant 历史就Ke以啦. 在 RAG 或者 Agent 工作流里geng是关键一步哦! 稳定性和可控性直接提升! 你懂的!

工具调用型 Agent 流程一般是这样子的：规则定义 -> 任务输入 -> 模型决策 -> 工具返回 -> Zui后回复. 重点就在于证据和历史的分离上哦! 工具返回的结果要单独作为独立证据输入进去, 不要和之前的对话混在一起! 这点hen重要! 不然模型容易糊里糊涂地把工具结果当成自己的话了! 那可就出问题了! 比如说“请用工具查询一下今天的天气”然后把天气结果直接扔到 assistant 层里, 那是不是就把事实硬塞进去了? 这不对不对, 要放在 evidence 层, 让模型知道哪里来的信息. 清晰的分层才Neng保证模型的稳定性和可信度. 嗯... 希望你Neng明白哈!

还有一个角色叫Zuo system 。 它也是高优先级层, 但比 developer geng偏平台级或者全局边界. 用于设置跨场景dou成立的基本规则. 例如 “默认中文”、“仅依据提供资料回答”等等. 一般来说 system 比 developer geng通用一些. 不过要注意的是 system 和 developer 的职责有重叠的地方, 你Ke以根据实际情况选择拆开或者合并. 取决于项目需求啦! 当然啦, Ru果职责比较清晰的话, Ke以考虑拆开他们之间的关系. 但Zui终还是要kan具体情况来决定哦! 不一样吗? 你懂的 !

千万不要把检索内容成 assistant 层!!! 这会导致hen多问题哦!! Ru果你把检索结果或者数据库查询结果直接扔到 assistant 层里, 那相当于你在让模型相信它们是自己说的的话, 这会导致模型产生幻觉或者给出错误的信息!!! 所以一定要把这些外部事实放到 evidence 层里去吧! 这是基本原则之一!!! 不然你就得付出惨痛的代价啦!! 哈哈~ 开玩笑啦, 但是真的要重视这个问题哦! 这点是Zui容易忽略的地方之一!!! 你知道吗? 嗯... 我还是啰嗦一点... 不过这样Neng让你geng好理解呢! 别嫌我啰嗦啊!! 虽然我知道你可Neng觉得有点多余... 但认真对待一下会有好处哦!!!! 另外一个容易混淆的点是工具返回的结果通常不应当当作普通对话角色来处理, 而应作为独立证据输入. 从工程视角kan一次请求里的上下文来源通常有五层: 1. Developer: 应用开发者写给模型的长期行为约束. 2. User: 本轮任务目标. 3. Assistant: 多轮对话历史. 4. Evidence: 工具返回结果、数据库查询等外部事实. 5. System: 全局或平台级规则.

hen多项目在早期douNeng跑通但是到了中后期却开始不稳定是hen常见的现象．Zui常见的原因不是模型变差而是上下文结构越来越乱．你把规则、问题、历史、检索结果、工具输出全部堆在一起短期kan起来省事但是长期一定会出问题的．你Ke以kan到这样的现象:

1．混乱的信息流: 模型无法准确判断每个信息的来源和优先级．

2．上下文漂移: 模型可Neng会忘记之前的指令或规则．

3．幻觉风险增加: 模型可Neng会编造答案或引用不存在的信息．

4．调试困难: 当出现问题时难以定位错误原因．

所以说 “role” 不是标签装饰它是在告诉模型三件事:

1. 定义长期行为约束；

2. 指示本轮任务目标；

3. 提供辅助信息；

“context layers” 和 “prompt engineering” 是两个不同的概念。“context layers” 是指对 LLM 上下文进行分层管理的技术手段; 而 “prompt engineering” 则侧重于设计有效的提示词来引导模型的行为和输出。前者关注的是如何组织上下文信息以提高模型的性Neng和稳定性; 而后者关注的是如何通过巧妙的设计提示词来实现Zui佳效果。两者dou是 AI 开发过程中不可或缺的部分。理解并掌握这两个概念对于构建高效可靠的 AI 应用至关重要!希望本文Neng帮助大家geng好地理解 LLM 上下文的角色以及如何进行有效管理!Ru果有任何疑问欢迎随时提问!感谢大家的阅读与支持!祝大家一切顺利!加油💪🏻""

Ru果对 AI 全栈开发、文档编辑器等感兴趣欢迎添加我的微信一起交流哈~ 😊 也欢迎给 DocFlow 点个 star ⭐ 哦！！

希望这篇文章Neng帮到你～ 下次见啦 👋 ！