一篇围绕 Kubernetes 官方文档搭建 RAG（检索增强生成：先从私有知识库找资料，再让大模型据此回答）系统的开源实践，完整拆解了从抽取、切块到混合检索和部署的关键环节。我们的判断是：RAG 已经不再是“做个演示”的问题，而是进入“工程能力决定效果”的阶段。
这是什么
这篇文章讨论的不是某个新模型，而是一套生产级 RAG 架构。它的目标很直接：让大语言模型少“猜”，多引用企业自己的文档、手册和知识库。
核心设计有两层。第一层是摄取管线，也就是把 PDF、网页、JSON 等原始资料抽出来、清洗、切块、加元数据，再变成可检索的数据。第二层是检索+生成：用户提问后，系统先找最相关的内容，再把这些内容作为上下文交给模型回答。
文章特别强调一个现实：切块策略和检索方式，比很多人想象中更重要。作者选择了混合检索，即把 BM25 关键词检索和向量语义检索合在一起，再用 Qdrant 这类向量数据库统一处理。这说明行业正在形成一个共识：只靠语义检索不够，只靠关键词检索也不够，真正可用的系统往往要两者并用。
行业怎么看
这类方案受欢迎，原因并不复杂。过去两年，企业内部最常见的 AI 需求之一，就是“让模型读懂我的资料”。RAG 正好对应这个需求，而且比重新训练模型更便宜、更快，也更符合数据不出域的要求。
更值得我们关心的是，文章把“生产级”三个字落到了工程细节上：文档怎么抽取、章节怎么识别、长文如何切块、元数据怎么保留、检索结果如何融合。这些步骤一旦做差，后面的模型再强，最终回答也不可靠。
但反对意见同样成立。第一，RAG 不是万能药。如果原始文档质量差、版本混乱、结构不清，系统只会把混乱更高效地检索出来。第二，混合检索、向量库、自托管部署听起来开源省钱，实际上会把复杂度转移到企业 IT 团队，后续维护、索引更新和权限控制都不是小事。第三，很多公司高估了“知识库问答”的业务价值，最后发现员工真正需要的是流程系统整合，而不是多一个聊天入口。
对普通人的影响
对企业 IT： 采购重点会从“哪个模型更大”转向“数据怎么接、文档怎么管、权限怎么控”。RAG 项目能否上线，越来越像一个数据工程项目，而不是单纯模型项目。
对个人职场： 会写提示词的优势会变小，能把内部知识整理成结构化资料、能定义检索规则的人会更值钱。很多岗位与其学“调模型”，不如先学“管知识”。
对消费市场： 未来看到的 AI 产品，回答会更像“带出处的客服”而不是“什么都懂的助手”。这会让体验更稳，但也意味着产品差异将更多体现在数据和场景，而不是模型口才。