RAG

最近看到仍有人在建设数据库运维知识库，把技术文章整理成训练材料，从开源数据库源码中批量提取知识文章，或让 AI 参考官方文档生成 Skill。我越来越怀疑这类建设的必要性。从我的使用体验看，即便在数据库运维领域，当下的大模型凭借已有的知识与推理能力，也已经能解决绝大多数日常问题。涉及具体环境时，再调用 Tool（包括通过 MCP 接入的 Tool）触达现场、日志、数据库与源码，用 JIT Context 按任务即时获取所需上下文，就能继续调查、处置和验证。 我的判断是，知识库已经没有必要成为 AI 应用的默认前置工程。通用知识无须重复整理，特殊场景也不意味着值得提前穷举案例。更值得建设的，是获取证据、验证判断的能力，以及对具体环境与真实经历的记忆。 AI 的知识架构，应当从提前囤积答案，走向按需理解问题、持续积累经验。 模型与 Tool 在进步，预先建库的前提也要改变 回看 ChatGPT 刚出现的时候，我常遇到它连基本事实、事件时间都答错的情况。那时，把材料筛选好、把步骤写全、把问题整理成问答，确实能补偿模型的不足。如今，越来越多的问题已经可以交给模型配合 Tool 解决，联网读取最新资料也让回答突破了训练数据的时间限制。模型本可以运用更广泛的知识、查找新证据，如果系统仍让检索命中的几篇文章主导答案，原本用来弥补模型不足的知识库，反而可能限制强模型的推理和调查范围。 对于模型已经掌握的概念和方法，直接使用即可。需要补充版本细节、环境状态或诊断证据时，再按需查阅。 复杂任务也可以让 Agent 阅读原始材料、提出假设、获取证据，再根据执行反馈调整。工程应先把这条工作路径接通，让实际任务暴露缺口，再决定哪些知识需要专门整理。 因此，一份专门教模型通用 SQL 写法的长篇规范，和一份记录公司业务口径的说明，有不同的生命周期。前者的一部分可能随着模型升级失去必要性；后者承载了模型无法凭空知道的业务事实。 沿着这个方向推演，如果未来的 AGI 能够自主调查和解决更复杂的问题，预建知识库的必要性还会进一步下降。需要我们持续提供的，是它无法凭空知道的内部事实、业务约定与共同经历。这些内容可以通过原始系统和专有记忆取得，资料是否公开，并不决定是否需要另建一个知识库。 保留事实，让理解发生在需要的时候 一种值得重新审视的流程是：先让 AI 阅读源码和文档，生成摘要，再扩展成问答、知识点或 Skill，最后交给 AI 使用。AI 在消费 AI 生成的二手知识。 如果一个 Skill 只是把官方文档重新转述一遍，它增加的是某次生成时的筛选与解释。为什么不让模型在需要时直接读原文？尤其当这些解释被写成操作指令，原本需要结合场景判断的内容，还可能变成后续 AI 默认遵循的步骤。Skill 值得承载的是经过实际验证的方法、环境约束与配套脚本；把文档改写成 Skill，并没有自动完成这些工作。 如果模型最终只能读到这些加工结果，它面对的就是前一个模型筛选后的世界。被省略的分支、被压缩的限定条件、没有被识别出的关联，都可能无法再找回来。生成量越大，审核和同步工作也越多。 一份日志今天用于定位超时，明天可能用于分析资源变化；一段源码今天被检查权限逻辑，明天可能被调查并发问题。如果提前只保留“这次超时的原因”或“这个函数负责鉴权”，就把未来的问题限制在当时摘要者的视野里。 保留可追溯的原始信息，也是在保留让更强模型重新分析它的机会。 摘要适合帮助定位与复用，应当能够带人和 Agent 回到来源。 把这种思路落实到系统中，就是 Tool Use 与 JIT Context（Just-in-Time Context，即时上下文）：Tool 提供查询数据库、读取日志、搜索代码和查阅文档的能力；Agent 根据当前问题判断缺少什么证据，调用相应 Tool，再根据返回结果决定下一步查什么。上下文随着调查逐步形成。 例如排查一条慢 SQL，可以先查询执行计划和等待事件，发现锁等待后再追踪阻塞会话与事务；遇到版本相关行为，再查对应文档或源码。每一步取得的信息都服务于当前判断，无须提前把所有慢 SQL 案例装进上下文。 ...