大模型上下文如今主流大模型动辄宣称支持 128K 甚至 1M 上下文很多团队因此产生了一个想法文档直接整篇塞进去RAG 可以扔了。我们在实际项目中做了多组长上下文测试结论是标称上下文 ≠ 可用上下文。本文分享实测发现的三个坑以及我们的应对策略。坑一有效上下文远小于标称值经典的大海捞针Needle in a Haystack测试只要求模型在一篇长文档中找到一句插入的话大部分模型都能通过。但我们换成了更接近真实业务的测试在 100K 文档中插入 5 条互相关联的信息要求模型综合推理。结果差距明显检索型问题找到插入的一句话92% 准确率 关联型问题综合 5 条信息推理61% 准确率 中段信息关联问题 43% 准确率这就是所谓的lost in the middle现象模型对上下文开头和结尾的信息利用较好中段信息容易被忽略。文档越长中段被稀释得越严重。坑二成本和延迟线性增长贵得体感明显以主流 API 定价估算128K token 的单次调用成本是 8K 调用的 16 倍以上。更麻烦的是 prefill 延迟首 token 延迟随输入长度明显上升128K 输入的首 token 等待可能达到数十秒交互体验崩塌。我们的实测数据某 128K 模型 API输入 8K 首 token 约 1.2s 输入 32K 首 token 约 4.8s 输入 100K首 token 约 18s坑三长上下文不等于长记忆上下文窗口是工作台不是档案柜。跨会话的状态、用户三个月前提过的偏好、上周文档里的结论——这些不在窗口里的信息模型一概不知。把长上下文当记忆用是方向性错误。我们的应对长上下文和 RAG 混合使用实践中效果最好的是分层策略defanswer(question,docs):# 第一层粗检索缩小范围chunksvector_store.search(question,top_k20)# 第二层把相关 chunk 所在的完整章节放入长上下文sectionsmerge_parent_sections(chunks,max_tokens24_000)# 24K 以内模型中段注意力衰减可控成本和延迟也在可接受范围returnllm.generate(question,contextsections) 要点有三个1.**有效窗口控制在 32K 以内**超过这个长度精度和成本都开始恶化2.**关键信息前置**system prompt 和上下文的开头放最关键的指令和事实3.**长文档场景先做结构化切分**检索定位后再把完整章节喂给模型兼顾精度和上下文完整性。 结论128K 窗口是能力上限不是使用建议。把它当可以整篇塞文档的许可证大概率会踩坑把它当检索之后可以放更大范围原文的余量体验和成本都会好很多。