团队把三年的设计文档、复盘、群聊导出一起灌进内部助手，头三个月很惊艳，什么都能答。半年后没人敢直接拿它的话去用——答案读起来都对，但没人说得清它是从哪份文件、哪个版本里长出来的。上线时省掉的那一步"标出处"，后来要用"逐条人工核实"来还。
组织知识进入模型的路径有四条，成本和可追溯性差得很远。选路径的时候，多数人只算前一项。
1. 四条路径与各自的可追溯性
| 路径 | 典型做法 | 更新一条要多久 | 答案能指向来源吗 | 撤回单条知识 |
|---|---|---|---|---|
| 微调 | 历史文档训练进权重 | 天到周，需重训 | 不能 | 极难 |
| 语义检索 | 切块入向量库，调用时召回 | 分钟级 | 能，前提是元数据没丢 | 容易 |
| 提示内上下文 | 每次调用把原文塞进去 | 改提示即可 | 能，提示里就是原文 | 容易 |
| 人工复制粘贴 | 人把答案贴到群里或文档 | 零 | 通常丢失 | 无从谈起 |
微调的真实代价不是训练花销，而是知识从可编辑资产变成不可编辑资产。一条写错的规范进了权重，唯一的修法是重训，或者在上层加提示压住它——后者会让上下文里同时存在两条互斥的规则，模型只能挑一条遵守，而你无法预知它挑哪条。
第三条最容易被低估：提示内上下文不产生任何知识资产，只是每次把原文搬进来。它的代价落在别处——上下文预算、首 token 延迟，以及"这条约束为什么在这里"不留痕。它适合兜住少量强约束，不适合承载一个知识库。
第四条常常是实际上的主力，也最难管：人从助手那里拿到答案，转手贴进评审意见或周报，出处在这一步彻底断掉。此后所有追溯都失效，而这条答案还在被继续引用。
// 选路径的三问，按顺序问，不要跳
1. 这条知识半年内会改吗？ 会 → 不进权重
2. 被引用时要能追到人和时间吗？ 要 → 检索或提示内联
3. 撤回要多快生效？ 小时级 → 只有检索层做得到
2. 沉淀与固化的分野
| 判别问题 | 沉淀：可纠正 | 固化：难纠正 |
|---|---|---|
| 知识原文在哪 | 可检索的文档，带版本 | 权重里，或一份合成摘要 |
| 改一条要多久 | 分钟级 | 重训周期 |
| 错了谁会发现 | 引用者发现原文不对 | 没人发现，输出依旧流畅 |
| 删除请求怎么落地 | 删条目即生效 | 只能屏蔽输出或重训 |
沉淀是让人能用，固化是让人无法纠正。危险在于两者体验上长得一模一样：都是"问一句就给答案"，差别只在出错之后还能不能改。
由此得到一条不对称的判断：过时的知识被模型复述，危害大于根本没有这条知识。没有知识时，人会去查、会去问；有了一条措辞权威的旧答案，人就不查了。所以"收录率"不是好指标，它奖励把不确定的东西也塞进去。
固化的麻烦还在于它不可逆：一旦摘要或权重里长出了一条旧结论，后续只能往上叠补丁。补丁叠到第三条，输出的可信度就不再取决于知识质量，而取决于哪条补丁被排在后面。权重化只在一种情况下站得住：知识几乎不变，且不需要追责——术语表、格式约定、命名规范这类东西。
// 同一份知识的三种载体，可用寿命差得很远
原文 + 版本号 → 随修订持续有效，最长寿
检索条目 → 跟随原文，修订时必须同步，否则说谎
合成摘要 / 权重 → 没人知道它对应哪一版
─── 判据只有一条：能不能回答"这条来自哪一版"
3. 可追溯性的三个要求
| 要求 | 判据 | 不满足的后果 |
|---|---|---|
| 答案 → 来源 | 输出附可点开的原文与版本号 | 无法区分引用与编造 |
| 来源 → 人 | 每份来源有 owner 与生效日期 | 错了不知道该找谁改 |
| 来源 → 更新 | 来源修订后，引用它的答案同步变 | 旧版本继续被当成当前事实 |
// 一条答案的最小引用形态，缺任一项按不可信处理
answer: 限流阈值放在网关侧配置，服务内不再重复判断
sources:
- doc: 规范/限流-v3.md
revision: 2026-03-11
owner: 网关组
retrieved_at: 2026-11-09
第三项最难，也最能分出路径好坏。检索层天然满足它：下次召回拿到的是新版本。权重层根本不满足。合成摘要层最危险——摘要生成那天是对的，之后来源改了，摘要不会自己变，而它读起来和原文一样权威。三个要求是递进的，不是并列的：第一项做不到，后两项没有讨论的前提。
4. 生命周期与模型侧的响应
| 阶段 | 人的动作 | 检索层 | 权重层 |
|---|---|---|---|
| 写入 | 定 owner、生效日期、适用范围 | 立即可查 | 等下一次训练 |
| 被引用 | 记录引用次数与提问者 | 可统计 | 不可统计 |
| 修订 | 出新版本，旧版标 stale | 下次召回生效，但缓存与旧会话仍可能给旧答案 | 新旧知识并存，互相冲突 |
| 废弃 | 标记删除并通知引用方 | 删条目即生效 | 只能靠提示压制或重训 |
"通知引用方"这一列最容易被跳过：文档废弃了，检索条目删了，但上周贴进周报的那段答案还在被人引用，没有人会回头改它。所以废弃动作的完成判据不是"库里的条目没了"，而是"引用过它的人被告知了"。
语义检索与版本要单独说一句：同一份文档的 v1 和 v3 都可能进 top-K，模型会把它们当成同一件事的不同表述，而不是"新旧"。所以版本必须写进元数据、检索时默认只查 current，不能让相似度排序去裁决哪一版更权威——它只懂像不像，不懂对不对。
检索层满足第三项也不是无条件的：缓存和长会话都是时间切片。一个会话开了两小时，中途来源修订了，这个会话里模型仍然拿着旧块回答，而且不会主动回查。判断标准有两个：这份答案要不要精确到版本，以及用户是否在意那个时差。
// 入库与召回成对出现，缺一半就退化成"向量搜关键词"
入库：metadata = { doc, revision, owner, status: current|stale }
召回：filter = { status: "current" }, top_k = 8
─── 常见错法
只按相似度取 top_k，再在应用层过滤版本 → 旧块先占满 top_k，等于没过滤
"团队共享的提示词库"最容易变成法外之地：没有 owner、没有版本、没有生效日期。半年后没人知道某段约束是谁加的、为什么加，可它每天都在影响输出，且比文档更靠近答案。
| 指标 | 怎么算 | 读法 |
|---|---|---|
| 可追溯回答比例 | 带来源的回答数 / 总回答数 | 低说明出处是事后补的 |
| 来源过期率 | 引用中 ttl 已过的条数占比 |
高说明废弃流程没落地 |
| 被纠正次数 | 同一答案被人工更正的次数 | 集中在少数主题＝那批知识该重写 |
| 贡献者数 | 近一季有修订记录的人数 | 一两个人＝体系靠个人撑着 |
5. 排错：六种"答得挺像，但不敢用"
| 现象 | 根因 | 处置 |
|---|---|---|
| 答案对，但没出处 | 入库时丢了元数据 | 回填 doc/revision/owner，补不齐的不许入库 |
| 同一问题两次答案矛盾 | 新旧版本同时被召回 | 版本过滤，默认只查 current |
| 输出里出现已废弃的流程 | 废弃只改了文档，没动检索层 | 废弃要同时删条目与摘要 |
| 改一块，别的答案也变了 | 切块把两条规则切进同一块 | 按规则边界切，不按字数切 |
| 被要求删除，却删不干净 | 内容已进权重或缓存摘要 | 只能屏蔽输出；入库时就该拒绝这条路径 |
| 没人愿意贡献 | 贡献无署名、不进评审 | 引用时署名，质量纳入评审可见 |
最后两条不是技术问题。贡献者拿不到署名，知识库里就只剩"被要求交的东西"；删除请求落到权重上，说明入库那一刻的同意范围没写清。这与"模型和数据能不能商用"是两件事：许可问的是权利边界，这里问的是谁的知识被引用、能不能撤回。
还有一类现象不在表里：答得对、出处也对，但没人知道该不该照着做。这通常不是知识问题，是适用范围在切块时被切掉了——原文那句"仅适用于网关侧限流"正好落在上一块的末尾。
6. 边界：什么时候把治理压到一条
| 场景 | 判断 | 更轻的做法 |
|---|---|---|
| 一次性问答 | 无复用预期，沉淀无收益 | 直接问，不建库 |
| 知识变化快于沉淀速度 | 入库即过期 | 每次调用现查现给，只带当前上下文 |
| 内容本身无争议（法条、标准） | 追责需求低 | 治理压到一条：必须给出处 |
| 只有一名贡献者 | owner 与评审无意义 | 版本号 + 生效日期即可 |
治理强度该跟着什么走，有个容易搞反的地方：跟贡献者数走，不跟文档总量走。一个人写叫个人笔记；五个人写才开始需要判据和生效日期；二十个人写就必须有评审与废弃流程。文档总量只说明写得勤，不说明写得准。
// 治理强度分级：按需停在某一级，不要一路加满
L0 必须给出处
L1 L0 + 来源 owner 与生效日期
L2 L1 + 版本过滤、废弃同步
L3 L2 + 引用统计、贡献署名、删除流程
每上一级都要有人负责；没人负责的那一级不要上
一句话收口：模型能不能答对是模型问题，答对之后有没有人敢用是治理问题；治理的最小形态不是流程，是"每条答案都能指回一份可修订的原文"。
自测
- 四条进入路径里，哪一条在"撤回单条知识"上几乎无解？为什么？
- 沉淀与固化在体验上有什么区别？为什么这个区别容易被忽略？
- "收录率"为什么不是好指标？
- 可追溯性的三个要求中，哪一项区分开了检索与权重两条路径？
- 为什么版本不能让相似度排序去裁决？
- 什么情况下，治理可以只保留"必须给出处"这一条？