补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-03 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
企业知识库是过去一年我见过最多的 AI 落地入口之一。几乎每个团队在讨论 AI 能做什么的时候，都会很快想到它：把文档喂进去、把制度接进去、把 FAQ 接进去，然后做一个“问什么答什么”的系统。这个方向当然成立，但也正因为看起来太成立了，大家很容易低估它背后的难度。
我现在一听到“我们想做一个企业知识库”，脑子里不会先出现模型，也不会先出现向量库，而是先出现七个问题。只要其中有几项答不清楚，我就不会建议直接开工。因为很多知识库项目，不是死在技术实现上，而是死在一开始的问题定义就不清楚。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-01-16 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去一年，RAG 几乎成了大模型落地的标准答案。只要有人问“模型回答不准怎么办”，大家第一反应往往就是“上 RAG”。这条路线当然没有错，很多知识型场景确实该这么做。但我越来越警惕另一种倾向：把 RAG 变成条件反射，仿佛只要做 AI 问答，前面就必须先接一个向量库。
现实没有这么简单。RAG 不是一个按钮，而是一整套系统：文档清洗、切分、索引、召回、重排、上下文拼装、引用展示、评估和回放。只要其中一个环节没做好，最后用户看到的就不是“更智能”，而是“更复杂且更不稳定”。
所以我现在会先问：这件事真的需要检索增强吗？如果不需要，硬上 RAG 不仅没有收益，反而会把系统搞重。
RAG 观测体系 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 系统效果波动时，只能靠人工体感猜是哪一环出了问题，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。
RAG 在 2023 年越来越热，但真正落地后就会发现，它从来不是“把文档丢进向量库”这么简单。一个像样的 RAG 系统，本质上是一条检索与生成协同的流水线。
RAG 缓存层 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 每次都全链路重跑检索和生成，高频场景的成本和延迟会持续被放大，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。
引用与 grounding 风格 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 模型回答看起来很自信，但用户根本不知道依据来自哪里，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。
embedding 模型切换成本 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 只盯着单点评测结果，忽略了索引重建和线上切换的系统代价，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。
rerank 阶段 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 初始召回虽然覆盖到了答案，但排序顺序不对，模型看到的上下文依然不够好，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。
query rewrite 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 原始问题太口语或太短，检索阶段根本抓不到真正意图，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。
metadata 过滤设计 这件事在 2023 年开始越来越频繁地进入真实项目，但很多团队一开始只看到表面收益，没有先把边界收住。只要 字段命名和过滤粒度不一致，导致向量召回只能靠全文语义硬扛，问题就会很快从“一个小体验瑕疵”变成系统性的维护成本。