企业知识库选型不宜从“要不要向量数据库”开始。先问一个更具体的问题：回答这类业务问题，必须看到哪些材料，怎样证明没有漏掉决定结论的例外？长上下文改变了把材料交给模型的方式，却没有替企业定义材料范围。本文的判断是：以同一组真实任务、同一权限与版本边界、同一合格标准比较路线，才能知道哪一种值得部署。
变化在于阅读范围，而非知识库工作消失
检索增强生成（RAG）先选择少量相关材料，再由模型组织答案；长上下文路线则把一个较大的、事先确定的文档集合直接交给模型。两者并非严格对立：可以先检索到整份文档，再用长上下文阅读正文和附件。采购时真正需要比较的是证据进入模型之前，哪些选择由检索器完成，哪些由模型完成。
2024 年 Li 等人的研究在指定模型和公共数据集上比较两条路线，发现资源充分时长上下文的平均表现更好，而 RAG 保留成本优势，并提出混合路由。[1] 这不是今天任意模型的采购结论，也不是企业全量文档已获验证的证据。本文将其视为建立对照基线的理由，而不搬用论文中的性能差值。
长输入也存在反例。2024 年 Lost in the Middle 研究展示了证据位置变化对特定任务表现的影响；Google 的长上下文文档也区分了单条信息定位与多条信息提取的难度。[2][3] 因此，容量上限、单条检索测试成绩、完整业务回答质量，应分别验收。
先给问题画出最小完整证据范围
本文建议先给每类问题写一张证据清单：答案需要哪些来源，是否存在优先级更高的附件或修订，是否要覆盖所有对象，以及“没有找到”能否代表“确实不存在”。这是一种工程分析方法，不是通用行业标准。它让选型讨论从输入长度转向遗漏的后果。
查一条设备维护步骤，证据可能集中在某个版本的几页手册；比较采购协议与补充条款，则需要同时读到相互覆盖的规则；列出一个项目全部交付义务，必须界定项目文档集合并验证完整性。问题表面上都在问文档，漏检的风险却不同。
权限感知的企业 RAG 讨论了访问边界与证据适用性。这些要求同样适用于长上下文：不能因为窗口装得下，就把调用者无权查看的附件一并输入；也不能混入失效版本，让模型自行决定哪个更可信。权限过滤和版本选择必须在构建输入时落实。
三类工作负载，对应三种优先测试路线
对于大语料中的局部事实查询，先测试检索路线。它把输入限制在少量候选证据，适合问题集中、证据位置可被关键词或语义定位的场景。代价是要维护切分、索引和召回评估；若例外条款分散，检索命中主条款仍可能给出错误结论。增加候选数量只能缓解部分遗漏，不能证明范围完整。
对于用户已明确选择的一组文件，例如某次评审的主文档及固定附件，直接长上下文是合理基线。它减少片段选择环节，便于跨章节比较。前提是材料经过解析、版本和权限检查，且总输入为提示、问题和输出预留了空间。超过限制时不能静默截断；应明确缩小任务或采用分阶段阅读。
对于范围较大但可先确定相关文档的任务，测试“检索文档，再完整阅读”的混合路线。检索负责找对文件，长上下文负责处理文件内部关系。它仍会受文档选择遗漏影响，却可能避免把重要附件切散。若问题要求对全部交易求和或穷尽记录，优先使用受控数据库查询和确定性计算，不能让文本检索承担完整枚举的证明。
把价格比较改为每个合格答案的全流程成本
本文建议以同一评估周期内的总运行成本除以合格答案数量。总成本包括文档解析和更新、索引与检索、模型输入输出、失败重试，以及必要的人工复核；开发和迁移投入另列，避免用一次性费用掩盖长期运行差异。合格答案须同时满足事实正确、证据充分、权限合规和响应时限，而不是只要返回文字就计数。
长上下文可能省去部分索引工程，却增加重复输入和等待时间；RAG 可能降低每次输入量，却需要持续维护检索质量。对于反复查询同一材料集的任务，可评估上下文缓存。Google 文档说明缓存能够帮助降低重复上下文的成本，同时提示长输入通常增加首个输出出现前的等待。[3] 实际收益仍取决于复用率、缓存有效期和所选服务的计费条件。
测试应分别记录冷缓存、热缓存及更新后的请求，不能把所有流量都当作缓存命中。延迟除中位数外，还要报告较慢请求的分位数及超时比例；单位成本同时列出总请求数和合格数量。一个便宜但经常需要人工纠错的方案，可能只是把费用转移到了业务团队。
用一个构造场景检验遗漏，而不是追逐平均分
以下是构造场景，并非壹典项目或实测结果。某团队评审一组设备采购文件，包括主合同、验收附件和一份修订通知。问题是“本次交付是否必须完成现场培训”。主合同写有一般培训要求，附件限定设备范围，修订通知调整了本次交付安排。只命中主合同就可能回答得流畅而错误。
为同一授权文档快照建立三条基线：片段检索、完整文件集输入、检索文件后阅读全文。人工先标出结论所必需的条款及其优先关系，再检查每条路线是否找到这些证据、是否正确处理覆盖关系、是否能指出材料缺失。不能用某条路线生成的答案直接充当标准答案。
随后加入范围外的相似旧合同、把决定性修订放到不同位置，并移除一份必要附件。位置变化用于观察稳定性；旧合同用于检验版本边界；移除附件时，合格行为是说明无法确定，而不是沿用此前结论。测试集合还应包含无需全量阅读的简单查询，防止为少数复杂任务付出所有请求的高成本。
混合方案需要可解释的升级条件
不是每次低置信度都值得重发全量材料。建议先记录文档范围是否确定、必要来源是否齐全、输入是否超预算，再决定扩大阅读范围。模型自报“有把握”可作为辅助信号，不应成为唯一放行条件。研究中的混合思路提供了参考，但企业路由还必须接入权限、时限和证据要求。[1]
升级路线应保留原始问题、材料版本、已尝试路径及新增证据，避免重试变成无法解释的另一套答案。权限不足时不能通过扩大输入绕过限制；来源确实缺失时，应请求补齐材料或返回有限结论。运营上可按问题类型调整路线，无需为整个知识库永久押注一种架构。
最终验收建议交付三份结果：按任务类别拆分的质量与遗漏记录、包含维护和复核的成本账，以及失败时的处理边界。只有某条路线在对应工作负载上满足这些条件，才扩大流量。长上下文是否替代 RAG，最终应成为可重做的工程判断，而不是依据窗口长度作出的品牌选择。