模型的上下文越来越长，企业做知识库时便会碰到一个很自然的问题。既然合同、手册和会议记录都能一次塞进去，还要不要整理资料。
我把长上下文研究和 Anthropic 的检索实验重新看了一遍。我的判断是，小资料集可以先用长提示试，文件多了以后仍要做检索。资料整理也不会消失。模型能读多少，和它能否稳定找到正确条款，是两件需要分别验收的事。
装得下只是第一步
Anthropic 在 Contextual Retrieval 的说明里给过一个实用界线。知识材料小于约二十万 token，粗略相当于五百页，可以考虑把整批内容直接放进提示。提示缓存还能降低反复传送同一批材料的时间和费用。对几十份制度文件的小团队，这条路值得先试，开发量也小。
文件一多，输入会变慢，费用也会上去。更麻烦的是相关内容可能埋在长文本中间。论文 Lost in the Middle 用多文档问答和键值检索做测试，研究者只改变关键信息在输入中的位置，模型表现就明显变化。答案放在开头或结尾时通常较好，放在中间时会下降。
这篇论文发表于长上下文快速发展之前，不能拿它给今天所有模型判同一个分数。它留下的设计提醒仍然有用。企业不能用“最大支持多少 token”代替自己的准确率测试。验收时可以直接问，二百页合同里那条违约期限放在不同位置，系统还能不能找对。
检索要同时认意思和编号
资料超过单次输入范围以后，常见做法是把文档切成片段，转成向量，再按问题找出相关片段交给模型。语义检索擅长找意思接近的内容，遇到产品编号、错误码和合同条款号时，精确字符串又很重要。
Anthropic 的实验把向量检索与 BM25 结合。BM25 会盯住词面匹配，像 TS-999 这样的错误码不容易被泛泛的相似内容盖过去。实验还给每个片段补了五十到一百 token 的原文背景，帮助系统知道“增长百分之三”究竟属于哪家公司和哪个季度。
在他们测试的多类资料上，上下文嵌入结合上下文 BM25，把前二十个检索结果的失败率从百分之五点七降到百分之二点九。加上重排以后降到百分之一点九。这是厂商在特定数据和设置上的实验结果，能说明整理片段有收益，不能直接当成企业项目的承诺值。
先整理版本，再谈模型
知识问答最常见的错，未必来自模型读不动。旧版制度和新版制度同时存在，扫描文件缺页，标题只写“最终版”，系统就很难知道该信谁。每份资料至少要保留名称、发布日期、适用部门和版本状态。切块以后也要带回这些信息，让答案能指向原文件。
上线前可以从员工真的会问的问题里挑几十条。既要有容易的，也要放进跨文件问题和容易混淆的编号。逐条记录系统找到了哪些片段，答案引用哪一版文件，找不到时有没有停下来。评测结果会告诉你该增加上下文，还是该改切块、检索和资料版本。
长上下文让第一版知识问答更容易做出来。资料整理决定它过几个月以后还能不能答对。