补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-01-16 14:30。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
过去一年，RAG 几乎成了大模型落地的标准答案。只要有人问“模型回答不准怎么办”，大家第一反应往往就是“上 RAG”。这条路线当然没有错，很多知识型场景确实该这么做。但我越来越警惕另一种倾向：把 RAG 变成条件反射，仿佛只要做 AI 问答，前面就必须先接一个向量库。
现实没有这么简单。RAG 不是一个按钮，而是一整套系统：文档清洗、切分、索引、召回、重排、上下文拼装、引用展示、评估和回放。只要其中一个环节没做好，最后用户看到的就不是“更智能”，而是“更复杂且更不稳定”。
所以我现在会先问：这件事真的需要检索增强吗？如果不需要，硬上 RAG 不仅没有收益，反而会把系统搞重。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-03 20:15。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
企业知识库是过去一年我见过最多的 AI 落地入口之一。几乎每个团队在讨论 AI 能做什么的时候，都会很快想到它：把文档喂进去、把制度接进去、把 FAQ 接进去，然后做一个“问什么答什么”的系统。这个方向当然成立，但也正因为看起来太成立了，大家很容易低估它背后的难度。
我现在一听到“我们想做一个企业知识库”，脑子里不会先出现模型，也不会先出现向量库，而是先出现七个问题。只要其中有几项答不清楚，我就不会建议直接开工。因为很多知识库项目，不是死在技术实现上，而是死在一开始的问题定义就不清楚。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-02-07 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多团队在做 RAG 优化时，容易把问题切成几个独立模块来看：Chunk 怎么切、检索怎么召回、重排怎么加、最后模型怎么答。表面上看这很合理，因为技术栈确实也是这么拆开的。但真正调过一轮系统之后就会发现，这几个环节并不是并列关系，它们是串联关系，而且前一个环节的决策会强烈限制后一个环节的上限。
也就是说，很多 RAG 项目效果不好，不是某一个组件单独弱，而是顺序没想清楚：一开始切分就把信息结构破坏了，后面再怎么改召回和重排，都只能在一堆不完整片段里做“最优选择”。
所以我现在更在意的是这条链路的顺序：先怎么切，再怎么召，再怎么排，最后才轮到模型组织答案。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-03-08 16:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这次排查很典型：业务方反馈“最近知识库回答突然变差”，但表面上看系统并没有报错，模型也没换，接口响应时间甚至还是正常的。真正的问题出在一个很容易被忽略的指标上，检索命中率突然掉了一截。
一开始大家本能地怀疑 Prompt、怀疑模型、怀疑重排，但继续查下去才发现，问题不是最后生成阶段，而是索引更新后，一部分文档的元数据缺失，导致相关片段虽然被召回了，却没有排进最终候选。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-22 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
有一次我们为了把检索时延压下来，动了向量库的一组参数。改动本身不大，甚至可以说很“合理”：
结果上线后最先变化的不是延迟，而是答案味道。
用户不会告诉你“召回率下降了”，他们只会说：
后来追回去才发现，这次参数调整表面上节省了一点查询成本，实际上悄悄改掉了检索质量的下限。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2026-01-21 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
围绕「内容、知识库、文档、教程，应该是四套系统还是一套系统」，我希望沉淀出一个能被后续项目复用的判断框架。
主文以完整判断链路为主，重点写清背景、取舍、工程落地和复盘结论。
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2026-03-28 09:10。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
这次记录背后暴露了哪些可以复用到后续项目的经验？
短更以单点观察为主，重点记录一个具体问题、一次实验或一个小的工程判断。