把全部资料放进上下文，模型就能把它们用好吗？这个问题值得和“窗口够不够大”分开检查。
长上下文让模型能接收更多材料，也让一些任务可以直接处理整篇文档。但外部资料如何取得、哪些证据与问题有关、旧信息是否过期、答案能否对应来源，仍然需要工程设计。我的判断是，窗口容量变大以后，信息筛选和组织的工作依然存在；RAG是否需要保留，要看任务和实际测试结果。
长上下文解决容量问题，有效利用仍需检验
一份材料能够放进窗口，只说明输入长度符合限制。要判断模型是否用得好，需要看它是否找到关键证据、正确处理冲突，并完成用户真正要做的事。
较早的原始研究《Lost in the Middle》在多文档问答和键值检索任务中观察到，相关信息的位置会影响所测模型的表现。这篇论文于2023年公开。它提供了检查上下文利用的实验依据，不能据此宣布所有当前模型都会以同样方式退化，也不能推出“窗口越长，答案必然越差”。
我把“注意力有限”作为提醒自己管理输入的工程说法。它不代表已经测到了某个平台内部的注意力分配，更不意味着答案错误都来自同一种机制。噪声、任务理解、检索缺失、来源过期和输出约束，都可能影响结果。
对资料已经完整取得、规模可控、需要理解全文的任务，可以先尝试直接使用长上下文。例如阅读一份结构清楚的合同，抽取条款后再检查条款之间的关系。若任务依赖持续更新的事实、分散的大量文档、访问权限或逐项引用，外部检索与来源管理仍有明确用途。资料能放进去，并不会自动解决这些问题。
向量化负责找候选，输入组织决定交给模型什么
向量化常用于把问题与文档片段表示成可比较的向量，帮助检索相关候选。候选进入答案生成之前，还需要检查主体、时间、来源、重复内容和相互冲突的事实。
我在自有RAG四层排查里把这部分放在答案层。哪些片段进入上下文、顺序怎样、token总量是否受控、有没有单一来源占据大部分输入，都值得检查。召回率较好，仍然可能出现证据组织不当或答案不忠于材料的问题。
检索算法不能直接替我们指定模型内部的注意力权重，但它可以通过候选筛选改变输入；排序、压缩、去重和提示结构也会影响模型面对的材料。所以“向量化解决了检索”不等于后续无需管理，也不意味着检索对有效利用毫无帮助。
我在检索工程与top-k中提到过TaoHtml的交付质量约束，包括隔离输入、浏览器QA、人工评审维度以及未通过检查时停止交付。这些措施检查报告的可追溯性和交付质量，不能直接当作注意力机制的实验。固定题集的作用也类似，它帮助比较不同运行结果；仅仅固定题数，无法证明模型已经充分利用上下文。
RAG把外部知识接入生成，多轮代理是其中一种工程选择
从工程角度看，我愿意把RAG理解为一段输入组织过程，依据问题取得外部材料，筛选证据，再以生成模型能够使用的形式提交。这里的“翻译”是一种工作解释，不是对所有RAG实现的严格定义。
Lewis等人的原始RAG论文将检索取得的非参数知识与生成模型结合。这个基础概念并不要求每个环节都有LLM，也不要求每个问题必须经过多轮搜索。
知识库范围稳定、问题清楚、一次检索即可提供完整证据时，简单流程可能已经够用。需要比较多个对象、检查新事实，或第一轮材料不足时，再考虑查询拆解、追加检索和证据评估。每增加一轮，都应能说清它补了哪个缺口，同时限制耗时和成本。Anthropic的工程说明也区分预定义工作流与模型动态控制的Agent，并建议按任务需要增加复杂度。
我在代理检索-lite中讨论过推荐类问题的多路检索。它解决多个检索方向的问题；长上下文解决能接收多少输入的问题。两者可以配合，也可能各自不必使用，不能只根据模型窗口大小决定整条检索架构。
每一步该看到什么，需要分清几种职责
Anthropic在2025年的Context Engineering文章中讨论了持续整理模型上下文的工程问题。对我来说，它把关注点推进到每次调用之前，当前任务需要哪些材料，哪些旧记录该继续保留，哪些内容已经可以移出。
下面是我用于理解工程职责的一种归纳，不是某一家产品的统一架构规范。实际系统可以把这些职责合并，也可以分开实现。
| 组件或工作 | 主要处理的问题 | 需要检查的边界 |
|---|---|---|
| RAG与外部检索 | 这次问题需要取得哪些外部证据 | 召回完整性、时效、权限、来源是否可靠 |
| Skill | 当前任务需要加载哪些专业步骤或工具说明 | 适用任务、版本、是否只加载必要内容 |
| Memory | 过去哪些事实或决定值得保留到后续步骤 | 过期、错误累积、项目混淆和纠正机制 |
| 上下文组织 | 这次调用最终提交哪些指令、证据和状态 | 重复、冲突、顺序、体积和可追溯性 |
| Harness或运行控制层 | 什么时候取资料、用工具、压缩、重试或结束 | 权限、预算、失败处理和停止条件 |
其中，Skill可以包含程序化步骤和辅助文件，按需加载是Agent Skills官方说明中的重要做法。它和检索事实资料解决的问题不同。工具说明加载正确，不代表事实来源已经充分；保留了历史记录，也不代表记录仍然有效。
以“根据新版本产品文档回答客户问题”为示意任务，第一步先明确产品和版本，第二步取得允许访问的相关文档，第三步检查关键事实和冲突，再组织生成输入。后续出现新问题，重新判断要补哪些资料。这个例子只是工作流程示意，不是客户项目或实验结果。
选长上下文、RAG还是组合，先看任务条件
我会先检查资料是否完整、是否持续变化，以及错误的代价，再决定输入路线。
| 任务条件 | 可以先尝试的路线 | 主要验证点 |
|---|---|---|
| 单份或少量完整文档，体积可控，需要理解全文 | 直接长上下文 | 关键内容有没有遗漏，全文关系能否正确处理 |
| 大量文档中只有少部分与问题相关，或资料持续更新 | 检索后生成 | 检索是否漏掉证据，是否取到正确版本 |
| 需要先发现材料，再对若干完整文档做综合分析 | 检索与长上下文组合 | 取得范围是否充分，输入是否保留原始依据 |
| 证据不足就应停止回答的任务 | 在上述路线加入证据检查与停止条件 | 能否明确承认不足，不靠流畅表达补齐事实 |
这些路线都要拿同一批真实任务比较。可以先固定资料版本、模型、问题和评分规则，记录正确性、证据支持、遗漏、延迟与成本。再分别观察输入路线的结果，确认差异来自哪里。
若要检查材料顺序或压缩是否影响结果，尽量一次只改一个因素。比较顺序时保持材料不变；比较压缩时记录压缩后删掉了什么；比较检索与全文输入时，明确两种路线取得的证据是否相同。模型有随机波动，就做重复运行，避免把一次变化当成稳定改进。
这也是我继续使用采样器和Benchmark的理由。它们应帮助我们发现具体失败、保留可比较记录，而不只是证明工具已经存在。眼下没有带明确指标和对照的原始记录，就不能把信息调度的收益写成“提升一个量级”。
下一次遇到答案错误，我会先把关键证据找出来，检查它有没有取得、有没有进入实际输入、版本是否正确，再看答案如何使用它。这样才能决定是改检索、改上下文组织，还是重新评估模型和任务约束。单独调大窗口，可能解决容量不足；剩下的问题需要沿这条记录继续查。
参考资料
- Nelson F. Liu等，Lost in the Middle: How Language Models Use Long Contexts，2023年公开，arXiv:2307.03172。本文引用其特定任务中的信息位置观察，不视为当前全部模型的统一规律。
- Patrick Lewis等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，NeurIPS 2020。
- Anthropic，Building effective agents，2024年12月19日；Effective context engineering for AI agents，2025年9月29日；Equipping agents for the real world with Agent Skills，2025年10月16日。工程说明中的具体产品能力会变化，本文只借用注明的工作区分。
- 王涛（Taomir），自有RAG四层排查、RAG检索工程与top-k、代理检索-lite。