RAG 没死，
死的是你的知识库
「RAG 已死」的论调每隔几个月来一轮：上下文窗口又变长了、Agent 自己会翻文件了、微调又便宜了。但看多了企业项目的实际结局会发现，死掉的项目里，检索管道往往还在健康运转——死的是喂给它的知识库。管道无罪，水源先臭了。三种最常见的死法，和一条活路。
01死法一：文档坟场直灌
上线最快的做法：把全部门的 wiki、网盘、会议纪要一次性灌进向量库。演示效果立竿见影——直到有人问了个正经问题，检回来的是三年前的旧流程、两个互相矛盾的版本、以及一份早就作废的规范。
企业文档堆的真实构成，大部分是过期、重复、或从写下那天起就没人再读过的内容。它们在网盘里沉底无害，进了检索库就变成活性污染源：检索器不知道哪份是真的，模型更不知道——它只会用最流畅的语气，把陈年错误复述给你。垃圾进，雄辩的垃圾出。
02死法二：上线即弃养
知识库项目有个残酷的时间规律：上线当天是它一生中最准确的一天。业务在变、流程在换、组织在调，而知识库停在了上线那个快照里。三个月后，它开始系统性地撒谎——不是模型幻觉，是它检索到的「事实」本身过期了。
根因几乎总是同一个：没有 owner。文档有作者，但知识库没有主人；每个人都用它，没有人对「它说的还对不对」负责。无人认领的知识，衰变速度和无人维护的代码一样快。
03死法三：错把检索命中当理解
第三种死得比较隐蔽：库是干净的、也有人维护，但切片是按固定字数硬切的，表格切碎了、上下文切断了、「适用范围」和「操作步骤」分了家。检索命中率看板一片绿，回答质量却始终上不去——因为命中了片段不等于命中了含义。
切片粒度、元数据设计（这份文档适用于谁、生效到几时、被谁取代）、结构化内容的特殊处理——这些不性感的工程细节，恰恰是检索质量的地基。跳过它们的项目，调什么参数都是在给漏水的桶换漂亮的把手。
管道升级得再快，也救不了臭掉的水。
04一条活路：把知识库当产品养
活下来的项目共性很一致，就一句话：知识库不是一次性工程，是一个需要持续运营的产品。落到执行是三件事：
有主人——每个知识域有明确 owner，回答错了能追到人；有保质期——文档入库即带失效日期，到期不续签自动降权或下架，宁可答「我不知道」也不引用过期货；有回路——用户标记的错误回答回流到知识库修正，而不是消失在客服工单里。
你会发现这三件事和 AI 一点关系都没有——它们是知识管理的老常识。RAG 只是把「你的组织到底有没有认真管理知识」这件事，从年度审计变成了每一次问答的实时曝光。
> 检索的是文档，暴露的是组织。接口未稳，下次重连_