一泽：有效的 Context 工程（精读、万字梳理）｜见知录 004

一泽：有效的 Context 工程（精读、万字梳理）｜见知录 004 一泽：有效的 Context 工程（精读、万字梳理）｜见知录 004 Modified October 21, 2025 例如，Manus 所推出的 Wide Research 功能，就采用了类似方案，有兴趣可以去试试看。因为是并行架构，所以能够在单位时间内开展更加广泛、深入的 Deep Research 研究或其他复杂任务。 ⇣ 至此， • 压缩适合多轮对话交互任务； • 结构化笔记记录适用于持久化保存工作记忆； • 多智能体架构则方便分解复杂任务，缓和单 Agent 的上下文压力。 可以根据 Agent 应用的类型和复杂度灵活组合，共同为超长程任务实现无限上下文，提供切实的可能。 4️⃣ 总结： 精心设计你的 Context 工程 回顾上文，system prompt 编写、即时上下文检索、上下文架构管理，一切讨论的锚点，最终都回归到了 context 工程的核心： 找到能以最小 tokens 集合，最大化引出期望 AI 结果的策略。 Context 工程本身并不神秘，只是随着 AI Agent 架构日趋复杂、健全的自然工程发展。 理解了超长上下文如何影响 LLM 的性能表现，和 Agent 内的上下文记忆运作机制，我们才能更好地开展有效 context 工程。 最后的最后，请务必、务必，把上下文窗口视为有限的资源。 Ref： • Effective context engineering for AI agents｜By Anthropic：https://www.anthropic.com/engineering/effective context engineering for ai agents • Managing context on the Claude Developer Platform｜By Anthropic：https://www.anthropic.com/news/context management • Context Rot: How Increasing Input Tokens Impacts LLM Performance｜By Chroma：https://research.trychroma.com/context rot 梳理：Anthropic 界定的 Agent 类型 Anthropic 分享了他们过去一年里，与数十个团队、客户合作构建智能体时，总结下来的实用建议。 关于智能体的定义划分，往往在 workflows 和 agents 中有所混淆。Anthropic 将其统称为 agentic systems，智能系统： • 工作流 Workflow：把 LLMs 和工具通过代码，预编排好执行路径的规则流程。 • AI 代理 Agent：由 LLMs 自主指导其执行过程和工具使用的自主系统。 如何选用、设计 agentic systems ？ • 无硬性规定与优劣，应当以解决问题为目标出发，可以用多种类型进行组合。 • 最小化设计原则，如无必要，无增实体。从简单提示与优秀模型开始，实验并构筑第一个版本的「Agent」。只有智能不足时，才考虑调优工程，添加更多步骤与 Context 指引。 • 请注意 Agent 的可解释性与维护性，不可解释的 Agent 无法维护，无法维护则无法针对生产环境的各类问题进行工程调优。所以请保持 Agent 的规划步骤的透明度 以下是 Anthropic 总结的 workflow 与 Agents 类型，可能为你带来一些参考启发： Workflow • 增强型 LLM（the augmented LLM） ◦ 给 LLM 配上检索、工具、记忆等增强功能，LLM 可以主动使用，生成自己的搜搜查询、选择合适的工具。 ◦ 和 Agent 的区别是，增强型 LLM 不会规划任务流程，也无法自行决定下一步做什么，不能自主进行多轮交互。 • 提示链工作流（Workflow： Prompt Chaining） ◦ 通过将任务分解为多个子环节，由多个 LLM 分别处理前一个环节的输出，就像 coze、dify 一样。 ◦ 示例应用：营销文案生成 → 翻译为其他语言；文章大纲生成 → 检查 → 分段完成正文编写 • 路由式工作流（Workflow：Routing） ◦ 允许 LLM 分类 input，并在更合适的子任务中解决。可以对不同类型的任务进行分别的提示优化，不会干扰其他任务的表现 ◦ 比如：AI 客服、Chatbot 自主切换回答模型（简单问题就切换到小模型，类似 ChatGPT 5 网页服务，优化成本和响应速度） • 并行式工作流（Workflow：Parallelization） ◦ 并行式有两种应用角度，一是分治可并行的独立子任务；二是多次运行同一任务获取多样化结果 or 进行投票 ◦ 什么时候使用效果更好？1）提升任务执行性能；2）LLM 同时处理多因素任务是困难的，分解为单因素单个模型处理，会更好 ◦ 比如： ▪ Sectioning：在与用户对话时，一个模型负责处理用户意图，一个模型筛查问答中不适当、不合规的内容。 ▪ Voting：代码 or 内容审计，通过不同模型/不同提示，从不同方面对内容进行评估，甚至通过投票阈值来过滤假阳性。 • 协调 执行式工作流（Workflow：Orchestrator Workers） ◦ 中央 LLM 分解任务（相较并行式更灵活，子任务不是预先定义的），工作者 LLM 分别执行，返回结果，综合输出。 ◦ 示例应用：对多个文件进行复杂更改的 coding 产品， 分解需要从多个来源收集信息的 search 任务等。 • 评估 优化式工作流（Workflow：Evaluator Optimizer） ◦ 何时使用？——当人类清晰地表达其反馈时，LLM 的响应可以明显改进；其次，LLM 能够提供这种反馈 ◦ 比如：Search 场景、多轮文学创作与编辑（Evaluator 对多轮生成内容，进行综合反馈与建议） Agent Anthropic 把 Agent 定义为：LLMs autonomously using tools in a loop. • 通常指自主智能体，不断基于环境反馈的循环使用工具。能够理解复杂输入，推理与规划，以及从错误中恢复。（通常会包含最大迭代次数，控制 Agent 行动何时终止） • 常见的 Computer Use、Coding Agent 均在此列 • 随着底层模型能力的提升，Agent 独立解决复杂问题、处理错误反馈的能力也会随之提升 Ref： • Building effective agents｜BY Anthropic：https://www.anthropic.com/engineering/building effective agents 反思：止损线，亦是起跑线 “在抵达下一个阶段之前，这就是我探索愿意投入的、输得起的代价。” 发现自己在涉及到需要长期投入的重大决策时（如职业选择、亲密关系等），容易过度“忧虑未来的最终结果”，而导致因为畏惧远期回撤心理，不自觉地压抑当下的机会、幸福感，最终决定放弃对自己现阶段更有价值的行动。 比如： • 忧虑某个商业模式、变现机会能走多远，导致面对送到手上的机会时，迟迟不敢下注。 例如，Manus 所推出的 Wide Research 功能，就采用了类似方案，有兴趣可以去试试看。因为是并行架构，所以能够在单位时间内开展更加广泛、深入的 Deep Research 研究或其他复杂任务。 ⇣ 至此， • 压缩适合多轮对话交互任务； • 结构化笔记记录适用于持久化保存工作记忆； • 多智能体架构则方便分解复杂任务，缓和单 Agent 的上下文压力。 可以根据 Agent 应用的类型和复杂度灵活组合，共同为超长程任务实现无限上下文，提供切实的可能。 4️⃣ 总结： 精心设计你的 Context 工程 回顾上文，system prompt 编写、即时上下文检索、上下文架构管理，一切讨论的锚点，最终都回归到了 context 工程的核心： 找到能以最小 tokens 集合，最大化引出期望 AI 结果的策略。 Context 工程本身并不神秘，只是随着 AI Agent 架构日趋复杂、健全的自然工程发展。 理解了超长上下文如何影响 LLM 的性能表现，和 Agent 内的上下文记忆运作机制，我们才能更好地开展有效 context 工程。 最后的最后，请务必、务必，把上下文窗口视为有限的资源。 Ref： • Effective context engineering for AI agents｜By Anthropic：https://www.anthropic.com/engineering/effective context engineering for ai agents • Managing context on the Claude Developer Platform｜By Anthropic：https://www.anthropic.com/news/context management • Context Rot: How Increasing Input Tokens Impacts LLM Performance｜By Chroma：https://research.trychroma.com/context rot 梳理：Anthropic 界定的 Agent 类型 Anthropic 分享了他们过去一年里，与数十个团队、客户合作构建智能体时，总结下来的实用建议。 关于智能体的定义划分，往往在 workflows 和 agents 中有所混淆。Anthropic 将其统称为 agentic systems，智能系统： • 工作流 Workflow：把 LLMs 和工具通过代码，预编排好执行路径的规则流程。 • AI 代理 Agent：由 LLMs 自主指导其执行过程和工具使用的自主系统。 如何选用、设计 agentic systems ？ • 无硬性规定与优劣，应当以解决问题为目标出发，可以用多种类型进行组合。 • 最小化设计原则，如无必要，无增实体。从简单提示与优秀模型开始，实验并构筑第一个版本的「Agent」。只有智能不足时，才考虑调优工程，添加更多步骤与 Context 指引。 • 请注意 Agent 的可解释性与维护性，不可解释的 Agent 无法维护，无法维护则无法针对生产环境的各类问题进行工程调优。所以请保持 Agent 的规划步骤的透明度 以下是 Anthropic 总结的 workflow 与 Agents 类型，可能为你带来一些参考启发： Workflow • 增强型 LLM（the augmented LLM） ◦ 给 LLM 配上检索、工具、记忆等增强功能，LLM 可以主动使用，生成自己的搜搜查询、选择合适的工具。 ◦ 和 Agent 的区别是，增强型 LLM 不会规划任务流程，也无法自行决定下一步做什么，不能自主进行多轮交互。 ◦ 给 LLM 配上检索、工具、记忆等增强功能，LLM 可以主动使用，生成自己的搜搜查询、选择合适的工具。 ◦ 和 Agent 的区别是，增强型 LLM 不会规划任务流程，也无法自行决定下一步做什么，不能自主进行多轮交互。 • 提示链工作流（Workflow： Prompt Chaining） ◦ 通过将任务分解为多个子环节，由多个 LLM 分别处理前一个环节的输出，就像 coze、dify 一样。 ◦ 示例应用：营销文案生成 → 翻译为其他语言；文章大纲生成 → 检查 → 分段完成正文编写 ◦ 通过将任务分解为多个子环节，由多个 LLM 分别处理前一个环节的输出，就像 coze、dify 一样。 ◦ 示例应用：营销文案生成 → 翻译为其他语言；文章大纲生成 → 检查 → 分段完成正文编写 • 路由式工作流（Workflow：Routing） ◦ 允许 LLM 分类 input，并在更合适的子任务中解决。可以对不同类型的任务进行分别的提示优化，不会干扰其他任务的表现 ◦ 比如：AI 客服、Chatbot 自主切换回答模型（简单问题就切换到小模型，类似 ChatGPT 5 网页服务，优化成本和响应速度） ◦ 允许 LLM 分类 input，并在更合适的子任务中解决。可以对不同类型的任务进行分别的提示优化，不会干扰其他任务的表现 ◦ 比如：AI 客服、Chatbot 自主切换回答模型（简单问题就切换到小模型，类似 ChatGPT 5 网页服务，优化成本和响应速度） • 并行式工作流（Workflow：Parallelization） ◦ 并行式有两种应用角度，一是分治可并行的独立子任务；二是多次运行同一任务获取多样化结果 or 进行投票 ◦ 什么时候使用效果更好？1）提升任务执行性能；2）LLM 同时处理多因素任务是困难的，分解为单因素单个模型处理，会更好 ◦ 比如： ▪ Sectioning：在与用户对话时，一个模型负责处理用户意图，一个模型筛查问答中不适当、不合规的内容。 ▪ Voting：代码 or 内容审计，通过不同模型/不同提示，从不同方面对内容进行评估，甚至通过投票阈值来过滤假阳性。 ◦ 并行式有两种应用角度，一是分治可并行的独立子任务；二是多次运行同一任务获取多样化结果 or 进行投票 ◦ 什么时候使用效果更好？1）提升任务执行性能；2）LLM 同时处理多因素任务是困难的，分解为单因素单个模型处理，会更好 ◦ 比如： ▪ Sectioning：在与用户对话时，一个模型负责处理用户意图，一个模型筛查问答中不适当、不合规的内容。 ▪ Voting：代码 or 内容审计，通过不同模型/不同提示，从不同方面对内容进行评估，甚至通过投票阈值来过滤假阳性。 ▪ Sectioning：在与用户对话时，一个模型负责处理用户意图，一个模型筛查问答中不适当、不合规的内容。 ▪ Voting：代码 or 内容审计，通过不同模型/不同提示，从不同方面对内容进行评估，甚至通过投票阈值来过滤假阳性。 • 协调 执行式工作流（Workflow：Orchestrator Workers） ◦ 中央 LLM 分解任务（相较并行式更灵活，子任务不是预先定义的），工作者 LLM 分别执行，返回结果，综合输出。 ◦ 示例应用：对多个文件进行复杂更改的 coding 产品， 分解需要从多个来源收集信息的 search 任务等。 ◦ 中央 LLM 分解任务（相较并行式更灵活，子任务不是预先定义的），工作者 LLM 分别执行，返回结果，综合输出。 ◦ 示例应用：对多个文件进行复杂更改的 coding 产品， 分解需要从多个来源收集信息的 search 任务等。 • 评估 优化式工作流（Workflow：Evaluator Optimizer） ◦ 何时使用？——当人类清晰地表达其反馈时，LLM 的响应可以明显改进；其次，LLM 能够提供这种反馈 ◦ 比如：Search 场景、多轮文学创作与编辑（Evaluator 对多轮生成内容，进行综合反馈与建议） ◦ 何时使用？——当人类清晰地表达其反馈时，LLM 的响应可以明显改进；其次，LLM 能够提供这种反馈 ◦ 比如：Search 场景、多轮文学创作与编辑（Evaluator 对多轮生成内容，进行综合反馈与建议） Agent Anthropic 把 Agent 定义为：LLMs autonomously using tools in a loop. Anthropic 把 Agent 定义为：LLMs autonomously using tools in a loop. • 通常指自主智能体，不断基于环境反馈的循环使用工具。能够理解复杂输入，推理与规划，以及从错误中恢复。（通常会包含最大迭代次数，控制 Agent 行动何时终止） • 常见的 Computer Use、Coding Agent 均在此列 • 随着底层模型能力的提升，Agent 独立解决复杂问题、处理错误反馈的能力也会随之提升 Ref： • Building effective agents｜BY Anthropic：https://www.anthropic.com/engineering/building effective agents 反思：止损线，亦是起跑线 “在抵达下一个阶段之前，这就是我探索愿意投入的、输得起的代价。” 发现自己在涉及到需要长期投入的重大决策时（如职业选择、亲密关系等），容易过度“忧虑未来的最终结果”，而导致因为畏惧远期回撤心理，不自觉地压抑当下的机会、幸福感，最终决定放弃对自己现阶段更有价值的行动。 比如： • 忧虑某个商业模式、变现机会能走多远，导致面对送到手上的机会时，迟迟不敢下注。 • 因过度追求构建“长期可靠”的关系，而忽视在当下接触到的人，就无法通过一段段交织的关系，成长为更好的自己。 被评价“这个人想得清楚”，看起来是件好事。但有时也会因为犹豫，错过一些机会。 很难区分保守与激进、深思熟虑与开放灵活，孰对孰错。 但重点在于，决策的第一步不仅仅是靠直觉、喜好，而是先明确自己当下最需要解决的问题是什么，盘算清自己愿意押注的筹码底线。 比如现在有多少储蓄，现在来看，最多愿意设置 xx 时间、金钱的止损线。再次之前要尽情探索自己创业可能性，到了止损阶段后，即使回去上班，自己也能接受 比如现在有多少储蓄，现在来看，最多愿意设置 xx 时间、金钱的止损线。再次之前要尽情探索自己创业可能性，到了止损阶段后，即使回去上班，自己也能接受 过度忧虑未来、不预分配当前阶段的筹码，混乱地做出“明智、保护自己”的投资，是对流向自己的机会的不尊重。 ——未来是很重要，投注成本是很珍贵，但也请多多珍惜当下。 🎐 写在最后的卷尾 • 猛然发现，有半年没更「见知录」了。 这半年 AI 变化太快，持续在探索各个场景的应用，比如 AI Partner、Chat Memo。也因为全职创业，不停地见老朋友和新朋友。被动的认知碎片很多，其中一些内容已经同步在了 一泽Eze 公众号中。（所以不算偷懒吧……） 但回过头来，也焦虑自己主动学习的时间占比，较当初学习 Prompt Engineering 和 Workflow，体系化的「学习 沉淀 输出」闭环少了很多。 所以还是得恢复「见知录」的更新，倒逼一下自己的主动输入。 这半年 AI 变化太快，持续在探索各个场景的应用，比如 AI Partner、Chat Memo。也因为全职创业，不停地见老朋友和新朋友。被动的认知碎片很多，其中一些内容已经同步在了 一泽Eze 公众号中。（所以不算偷懒吧……） 但回过头来，也焦虑自己主动学习的时间占比，较当初学习 Prompt Engineering 和 Workflow，体系化的「学习 沉淀 输出」闭环少了很多。 所以还是得恢复「见知录」的更新，倒逼一下自己的主动输入。 • 这半年多了很多新关注的朋友，如果你不太了解「见知录 AI With Me」专栏是什么，可以看看往期内容： 《见知录 Vol.001：最小化提示词原则》 《见知录 Vol.002：愿你成为独一无二的大模型｜新年特刊》 《AI 无法替代的工作们｜见知录 Vol.003》 一言以蔽之，以 AI 、产品、生活、哲学这些维度，从我最近的所学所得中，筛选值得回顾的部分进行整理，分享我的理解和收获。 行文结构相对自由、精炼，但内容应当靠谱，毕竟都是对我自己负责的输入，这点还请放心。 也希望能通过「见知录」能让你了解更加全面的一泽（而不只是发经过编辑的长文 AI 博主） 《见知录 Vol.001：最小化提示词原则》 《见知录 Vol.002：愿你成为独一无二的大模型｜新年特刊》 《AI 无法替代的工作们｜见知录 Vol.003》 《见知录 Vol.001：最小化提示词原则》 《见知录 Vol.002：愿你成为独一无二的大模型｜新年特刊》 《AI 无法替代的工作们｜见知录 Vol.003》 《见知录 Vol.001：最小化提示词原则》 《见知录 Vol.002：愿你成为独一无二的大模型｜新年特刊》 《AI 无法替代的工作们｜见知录 Vol.003》 《见知录 Vol.001：最小化提示词原则》 《见知录 Vol.001：最小化提示词原则》 《见知录 Vol.002：愿你成为独一无二的大模型｜新年特刊》 《见知录 Vol.002：愿你成为独一无二的大模型｜新年特刊》 《AI 无法替代的工作们｜见知录 Vol.003》 《AI 无法替代的工作们｜见知录 Vol.003》 一言以蔽之，以 AI 、产品、生活、哲学这些维度，从我最近的所学所得中，筛选值得回顾的部分进行整理，分享我的理解和收获。 行文结构相对自由、精炼，但内容应当靠谱，毕竟都是对我自己负责的输入，这点还请放心。 也希望能通过「见知录」能让你了解更加全面的一泽（而不只是发经过编辑的长文 AI 博主） • 最后，感谢你读到了这里。 如果这期「见知录 AI with Me」对你有启发，或者你对它有任何期待，欢迎在评论区告诉我。 我也在考虑将《见知录》做得更深入、更成体系，也可能尝试付费订阅的模式，让我能投入更多精力。但在此之前，我很想听听你的期待与反馈？ 我的微信是eze is，期待与你更深度的连接～ 如果这期「见知录 AI with Me」对你有启发，或者你对它有任何期待，欢迎在评论区告诉我。 我也在考虑将《见知录》做得更深入、更成体系，也可能尝试付费订阅的模式，让我能投入更多精力。但在此之前，我很想听听你的期待与反馈？ 我的微信是eze is，期待与你更深度的连接～ You don't have permission to access this synced block. Please log in and try again. Log In 本期概要： • 方法：有效的 context 工程 • 梳理：Anthropic 界定的 Agent 类型 • 反思：止损线，亦是起跑线 本期概要： • 方法：有效的 context 工程 • 梳理：Anthropic 界定的 Agent 类型 • 反思：止损线，亦是起跑线 🎐 卷首语 • 「见知录 AI with Me」是一档有关 AI 、产品、生活、哲学的专栏，从我最近的所学所得中，筛选值得回顾的部分，分享我的理解和收获。 • 近日刚好得了空闲，在研读 Anthropic 官方技术博客和一些相关论文，主题是「Agent 与 Context 工程」。 经过个人梳理与解释细化，与我的实践经验一起，形成了这份较为完整的 Context Engineering 的认知与技巧，与你在本期分享。 经过个人梳理与解释细化，与我的实践经验一起，形成了这份较为完整的 Context Engineering 的认知与技巧，与你在本期分享。 @ 一泽Eze 💎 方法：AI Agent 的有效上下文工程 1️⃣ 何为上下文工程 Context Engineering ？ 2025 年 6 月以来，原名为「Prompt Engineering」的提示词工程，在 AI Agent 概念日趋火热的应用潮中， 经由 Anthropic、LangChain、Manus 等 AI 公司的更新，以及 Andrej Karpathy（前 OpenAI 联创）、Tobi Lutke（Shopify CEO）等行业领袖的传播下，共识成了更适应 Agent 构建的新概念： ——「Context Engineering」，即上下文工程。 在国内，也对应出现了“Prompt 工程已死，未来属于 context 工程”、“别再卷 prompt 了”等论调。 但，事实尽是如此？ 虽然传播一个新概念的“好”方法，就是拿它与出了名的旧事物对比、营造冲突。 但 prompt 仍是 context 工程不可或缺的子集，context 工程则是为适应 AI Agent 架构日趋复杂健全的自然发展。（Anthropic 团队在《Effective Context Engineering for AI Agents》一文中，也提到了一致观点） 要简单区分两者差异的话，可以如此理解： • Prompt 工程，专注单轮 AI 交互的生成质量，是为获得最佳结果而编写和组织 LLM 指令的方法。 • Context 工程，更关心在多轮 LLM 推理过程（可通俗理解为 Agent 运行过程）中，找到并维护动态优化整个 LLM 所接触的上下文信息配置（包括系统指令 system instructions、工具 tools、MCP 协议、外部数据、消息历史 message history）的策略。以期尽可能少且必要的 tokens，最大化 LLM 生成结果，引导模型输出我们期望的行为。 （比如，Context 工程涉及的 system instruction 依旧是 prompt 工程实现的。并非全方位替代，只是需要根据 AI 开发情景，灵活选择实现深度而已） Anthropic 《Effective Context Engineering for AI Agents》：context engineering 与 prompt engineering 的差异 Anthropic 《Effective Context Engineering for AI Agents》：context engineering 与 prompt engineering 的差异 2️⃣ 有限的大模型上下文空间 → Context Rot 大模型的上下文窗口有限。 从 GPT3.5 的 16K ，到 Claude 3.5 的 200K，再到现在 Gemini 2.5 Pro 的动辄 1M，近年来 LLM 上下文窗口大小，确实提升飞快。 这是否意味着我们可以高枕无忧，把一切 Context 都无脑地塞进去？ 答案是否定的——时至今日，上下文依旧需要被视为有递减收益边际的有限资源。 不知道你在和 AI 聊天时，是否发现这么一个现象？ 当对话长度不断增加（即使还没超过官方标称的上下文窗口尺度），模型的回复质量也会有明显的下降： • 回答深度降低： 越来越难深入结合前文你提供的细节，提供创造性和细节度俱佳的回应。通常你不得不重新发送关键 Prompt，再次强调可能有用的细节。 • 混乱归因：在做归纳或分析时，胡乱地把你上文中提到的不相关细节关联起来，得出一些南辕北辙的奇怪结论。 • 忘记前序指令： 忘记了对话早期你对它的回答要求（比如不要滥用比喻句式），但随着你自己使用了类似比喻的文风后，又开始犯轴。 ——1M 上下文的 Gemini 2.5 Pro，基本在 tokens 量来到 4w 左右时，会反应为推理缓慢，质量开始有所下降。 是的，最大上下文窗口 ≠ 最佳注意力窗口。 有个专门术语来描述这个普遍的负面模型现象：Context Rot，上下文腐烂。 如同人类在信息过载时会思维混乱，而过长的、充满干扰的上下文，同样会显著降低模型的推理能力。 而模型性能下降（上下文腐烂，context rot）的三大因素如下： 1. Context 输入越长 → 注意力被稀释。 2. 问题与关键信息的语义相似度越低 → 模型越难匹配到答案。 3. 关键信息与周围干扰内容的语义相似度越高 → 干扰增强，模型难以分辨。 这三个因素会相互放大，导致性能显著下降。 PS：反过来，控制 Context 长度、减少 Context 中的干扰项数量、提升问题与 Context 中有效信息的相似度，就能够提升 Agent 的处理效果 这三大因素来自于 Chroma 团队（打造了目前全球最主流的开源向量数据库之一）一次名为《Context Rot》的同名实验研究。 👉 实验研究古法人工浓缩如下，个人觉得会对测试 AI 产品有一些实用启发。（比如测试较佳 context 长度） 如果觉得太长，也可以下滑到本段小结～ 实验研究古法人工浓缩如下，个人觉得会对测试 AI 产品有一些实用启发。（比如测试较佳 context 长度） 如果觉得太长，也可以下滑到本段小结～ ☞ Chroma，探究上下文对模型性能影响的关键要素 他们设计了一套实验，来测试影响 LLM 长上下文性能表现的因素： 在传统 NIAH（Needle in a Haystack：即，LLM 大海捞针、在干草堆中找针）基础上，进一步拓展任务难度，考察大模型的语义理解层面的捞针能力，而非直接词汇匹配。 传统 NIAH 任务，是评估模型长上下文能力最广使用的基准之一： 将一个随机事实（针信息），放在较长的上下文（干草堆）中，通过直接问答，要求模型回答某个针的信息 ，比如： 干草堆：[大量无关文本]