不少团队把「解决大模型知识不足」的希望寄托在上下文窗口上窗口从 8K 涨到 128K再到百万级似乎把文档全塞进去就行。实际项目里你会发现窗口翻倍并没有解决根本问题RAG检索增强生成仍然是刚需。三个绕不开的现实第一是成本。按 token 计费的模式下每次请求都塞几十页文档费用线性上涨。一个日均千次调用的知识问答系统全量塞上下文的成本是 RAG 方案的几十倍。第二是注意力稀释。长上下文里模型对中间内容的利用率明显低于头尾这在海量评测里反复被验证塞进去不等于用得上。关键信息埋在几十页文档中间时回答质量会明显下降。第三是时效与权限。企业知识库天天更新每更新一次就重新塞一遍上下文既低效又无法做权限隔离——你没法保证模型只基于「当前用户有权看的文档」回答。RAG 的检索层天然解决这两件事知识更新只改索引检索时按用户权限过滤。RAG 落地的四个关键点一是切块策略。固定长度切块是最粗暴的效果往往一般。按文档结构标题、段落切块之间保留少量重叠检索命中率会明显提升。二是混合检索。纯向量检索对精确关键词产品型号、报错码不敏感BM25 加向量的混合检索再接一层重排序rerank是目前性价比最高的组合。三是引用溯源。让回答附带出处既能帮用户验证也方便排查检索质量问题——回答错了先看出处是不是错了。四是评估闭环。准备一套固定问答对每次改切块、换模型、调参数都跑一遍命中率靠感觉调优等于盲开。什么时候可以不用 RAG文档总量小于模型窗口、内容更新频率低、无权限要求的场景直接塞上下文确实更简单。但只要命中「知识量大、更新频繁、多用户权限」中任意两条RAG 就是更工程化的选择。窗口在涨检索的价值没在跌。两者是互补关系窗口解决「一次能用多少」检索解决「该用哪一段」。把该检索的检索好再把检索结果塞进窗口才是当前的最优解。