同一个模型，同一个问题，昨天答得头头是道，今天却开始胡编。很多团队的第一反应是换模型、调参数、加算力。但问题往往不在生成端——检索找到的那段内容本身就是错的、过时的，或者压根什么都没找到。

这就是知识管理要解决的问题。它管的不是模型，是模型伸手去够的那堆内容。

先分清是检索坏了，还是生成坏了

一个带检索增强（RAG）的问答机器人答错，原因可能出在两个完全不同的环节。用户的问题先被拿去检索相关内容片段，模型再基于这些片段组织答案。如果检索捞上来的是错误片段、过期片段，或者干脆空手而归，那模型再强也救不回来。

所以在动模型之前，先看它拿到了什么证据。这一步能把检索失败和生成失败区分开，也决定了你接下来该修哪一头。

知识结构是这条链路里团队能直接动手改的部分。重排源内容、调整分块方式和元数据，然后拿一批有代表性的问题去测：该出现的段落，到底有没有被捞出来。

写给检索看，不只是写给人看

为人类浏览帮助中心而写的内容，往往不适合被检索。几个原则能拉开明显差距：

  • 一节只讲一个主题。自成一体的章节检索起来干净利落；一篇文章横跨五个主题，检索结果就会含糊不清。
  • 答案前置。把答案放在每个章节靠前的位置，这样被捞出来的片段本身就带着干货。
  • 用明确的标题。标题贴近客户提问的说法，匹配效果会更好。
  • 别跨章节用代词链。一个片段应该脱离上一段也能读得通。

这几条听起来朴素，但它们直接决定了检索阶段能不能捞到对的东西。

分块策略：那个安静的杠杆

分块决定了哪一单位的内容会被嵌入、被检索。块太大，相关性被稀释，答案被埋在里面；块太小，回答所需的上下文又丢了。合适的甜点区通常是一个连贯的章节——大到能独立成立，小到足够具体。

优先选结构感知的分块方式，尊重标题和自然边界，而不是粗暴地按固定长度切。相邻块之间留一点重叠上下文，有助于保住边缘处的语义。然后按块级别给检索打分，你才能看清哪些块真的在回答问题，哪些从来没被用过。

有个实操建议：如果一篇文章要回答很多不同的问题，就拿聚焦的章节或条目去和原文对比测试。真正有用的单位，是那种能为你的评估问题捞回完整答案、又不捎带无关材料的单位。

元数据打标：精度和新鲜度都靠它

元数据能把一堆平铺的内容变成可筛选、可治理的东西。给内容块打上属性标签，比如产品线之类的维度，检索时就能按条件过滤，而不是在一锅粥里碰运气。

它同时也是新鲜度的抓手。内容会过时，产品会改版，答案会失效。没有元数据，你很难知道哪些块该被复查、哪些块已经没人用了。有了标签，维护就从"凭感觉"变成"看清单"。

把这几件事串起来看：结构决定内容能不能被干净地捞出来，分块决定捞出来的单位对不对，元数据决定你能不能管住它、更新它。三者都指向同一个判断——答案不准的时候，先别急着怪模型。