长上下文如何改写知识库成本结构

长上下文真正动到的，不只是“模型一次能读多长”，而是企业知识库该把钱花在哪一段。

过去谈知识库，成本很容易被理解成建索引、做切分、养检索链路。长上下文把另一种账本推到台前：每次提问带进去的字越多，单次处理就越贵。哪怕里面大半内容跟当下问题无关，也可能一起进账单。偶尔通读一份报告、比对几章合同，这种一次性的高输入通常还能接受；可如果每天都是高频问答，输入量就会从“偶尔贵一下”变成“长期固定支出”。

这正好和 RAG 形成对照。RAG 并不消灭成本，它只是把成本前移：清洗、去重、切分、索引、排序，再加上版本失控、术语不统一、重复文档带来的维护摩擦。你少付的是每次请求里那一大坨无关上下文，多付的是持续把知识库维持在“可被问”的状态。文档量不大、调用不密、任务偏一次性阅读时，直接塞进长上下文往往更省事；资料持续膨胀、请求稳定、又必须卡住单次输入规模时，RAG 更容易撑起可预期的成本结构。

更有意思的是中间地带。海量资料里先筛出相关文档，再把较完整的章节交给长上下文，等于用检索控制范围，用长窗口保留关系。成本不再是“全检索”或“全塞入”二选一，而是按任务决定：这次该为筛选付账，还是为完整理解付账。实时性也会改写账单——临时会议纪要、刚上传的合同，直接放进上下文，省掉等索引的时间；但若知识要长期发布、旧版要退出检索，更新链路本身又成了必须计入的运营成本。

所以长上下文改写的，不是“RAG 过时了”，而是计价单位变了：从建设一套总能召回的库，转向每次回答愿意为多少上下文买单。真正该先问的，往往不是技术名词，而是请求频率、资料更新节奏，以及一次答错或答慢，企业到底更怕哪一种浪费。