落地实战一：知识库问答从 0 到上线

本篇解决的问题只有一个：RAG 的零件你从第 14 周学到第 21 周，全都有了，怎么把它们组装成一台真正能上线、能运营的知识库问答产品。不是新知识，是组装说明书。

学零件的时候，每周一个主题，切块归切块、重排归重排。真要上线，老板不问你 Hybrid 检索的原理，问的是三件事：给谁用、什么时候能上、答错了算谁的。这一篇就按这个顺序走：先定产品边界，再拼架构，再过决策，再查上线，最后讲上线之后怎么运营。零件全部指向站内对应周次，忘了哪件，链接点回去补。

产品定义与边界

先说为什么第一件事不是写代码。上线项目里最贵的错误从来不是技术选错，是承诺错。答应了"什么都能答"，后面每一次答不出都是事故；把边界写清楚，边界外的问题就有资格说"这不归我管"。所以产品定义先行。

目标用户：公司内部同事。三类人最典型：新员工（入职三个月内，制度类问题密度最高）、业务一线（要的是快和准，答错一次就不再来了）、客服团队（自己也要答客户的问题，把知识库问答当辅助工具用）。内部场景有个天然红利：用户容忍度比对外产品高，愿意反馈"你答错了"，这些反馈就是后面运营的原材料。

核心场景三个：

场景	典型问题	系统要做的
制度类单点问答	「出差住宿标准一晚多少钱」	检索到、答对数字、给出处
操作指引类	「超标审批流程怎么走」	多个相关切块拼出完整步骤，每步可溯源
边界探测类	「竞品公司的报销制度」	判断库外，老实说不知道，别硬编

第三个场景看着不起眼，其实是信任的分水岭。敢说不知道的助手，用户才敢信它说知道的部分。第 14 周 Day 1 里「没有就说不知道」那道闸，在这里从 prompt 技巧升级成产品承诺。

明确不做什么：两条。一是多轮复杂推理——「对比去年和前年的制度变化并给出修订建议」这种要跨文档多步规划的，是另一个产品线的活，本篇的问答是一问一答一出处，不做规划不做链式推理。二是实时数据——「今天的股价」「现在库里还剩多少库存」，答案是分钟级变化的，RAG 的知识在入库那一刻就冻结了，这类问题该走工具直连，不是知识库的错，是问错了门。

把这三条写进产品文档，上线后拿它挡需求，比拿技术名词挡管用得多。

架构：你已拥有的零件组装图

不需要发明任何新东西，你要的是把七周学的零件按位置装好。沿用第 15 周 Day 7 架构图 v2 的三条链路来清点，每件零件标注来源：

入口层（第 20 周）：
  认证 → 识别用户与租户 → 限流（第 21 周）
  → 语义缓存命中？命中直接返回，未命中进链路

在线链路（第 14、15 周）：
  提问 → 查询分类（第 15 周 Day 3 Adaptive 路由）
    chitchat → 直答
    事实型 → 向量检索
    分析型 → Hybrid（BM25 + 向量 → RRF，第 15 周 Day 1）
  → 召回 50 条 → 重排取 top 5（第 15 周 Day 2）
  → 租户过滤在检索层完成（第 20 周，见决策清单第 6 条）
  → 拼 Prompt → LLM 生成 → citations 后端构造（第 15 周 Day 4）
  → 生成失败？降级：返回检索原文 + 出处，不返回空
  记忆（第 17 周）可选挂在会话层：记住用户部门，优先检索其相关制度

离线链路（第 14、15 周）：
  文档上传（异步任务，第 15 周 Day 6 管理界面）
  → 解析 → 切块 + metadata → Embedding → pgvector（第 14 周）
  → 同时喂 BM25 索引（jieba 分词，第 15 周 Day 1）

旁路（第 15、21、18 周）：
  评估集回归（第 15 周 Day 5）：每次改动前后各跑一遍
  tracing / 成本监控（第 21 周）：每次问答留痕
  MCP（第 18 周）：知识库封装成 Resource 暴露，
  公司内其他 Agent 也能读同一份知识，不另起炉灶

三句话读这张清单。入口层管「谁在问、能不能问、是不是刚问过」，在线链路管「怎么答好这一个问题」，旁路管「这套系统怎么活得久」。离线和在线的交汇点还是那个 pgvector，第 14 周 Day 1 讲的图书馆模型原样成立。

多解释一句 MCP 的位置。知识库不该只服务你做的那一个聊天界面，用第 18 周学的协议把知识库挂成 Resource，公司里其他 Agent（比如运维 Agent 查故障复盘）读到的和你界面里读到的是同一份。知识源只有一份，消费方可以有很多，这是第 18 周 Day 1 讲 Resource 时埋下的用法。记忆是全清单里唯一的可选件：会话里记住用户部门和角色，检索时优先喂他相关的制度，第 17 周的两层记忆直接够用；用户不跨部门混用就先不装，别为了可选项拖上线。

关键决策清单

零件的连接方式里有六个决策，做之前想清楚，每个都是「先问为什么，再定怎么做」。

1. 切块参数怎么定：让评估集说话。 第 14 周 Day 1 给的起点是每块 300 到 500 字、重叠 10% 到 20%，但那是通用起点，不是你的答案。正确姿势：建好评估集（第 15 周 Day 5 的 golden set，10 到 20 题起步），改一次切块参数跑一轮指标，让 Hit@3 和 nDCG 替你吵。费率表、条款编号密集的文档往往要切得更小且不能拦腰切断，这个结论只有你的语料能给你。

2. 混合检索还是纯向量：看查询画像。 把评估集里的真实问法摊开数一数：带编号、型号、专有名词的占比高，就上 Hybrid，因为第 15 周 Day 1 证明了字面匹配对「ORDER-2024」这类查询一锤定音，纯语义反而模糊；全是口语化语义问法，纯向量更简单，少维护一路 BM25 索引。别凭偏好选，凭查询分布选。

3. K 与 Rerank 的取舍：宽进严出。 召回 50、重排后取 5，这个格局来自第 15 周 Day 2 的账：召回模型便宜但排序糙，相关文档常卡在 4 到 10 名；交叉编码器准但贵，只能审 50 条。要不要动这两个数？延迟扛不住就缩召回宽度，命中率顶不住就扩。动之前跑评估，动之后跑评估，没数字的调整都是玄学。

4. 引用是必须还是可选：必须。 内部制度场景，答案直接影响报销和审批，没出处的答案等于「你自己看着信」。第 15 周 Day 4 那套「后端从检索真 metadata 构造 citations、answer 分字段返回」直接搬过来，模型只标 [n]，编不了页码。引用不是锦上添花，是这个产品的最低门槛。

5. 语义缓存阈值：宁高勿低。 第 21 周讲语义缓存时算过账：内部场景「住宿标准」这种题每天被问几十遍，缓存收益极大。但阈值定低了，「住宿标准」会命中「住宿超标怎么审批」，答案错位比慢更糟。建议从高阈值起步，只吃完全同义的说法，看缓存命中率再逐步下调，每下调一轮抽检一轮答案对应关系。

6. 多租户隔离做在哪一层：检索层，不是应用层。 第 20 周讲认证与多租户时给过原则：隔离必须在查询层面强制生效——pgvector 检索的 WHERE 条件里带租户标识，BM25 索引按租户分开建。若只在应用代码里过滤，总有一条新写的查询路径会忘掉，漏一次就是 A 公司看到 B 公司制度。隔离是数据库的活，不是程序员的记性。

上线前检查清单

十项，逐条打勾，缺一条就不发版。

• [ ] 评估集基线达标：golden set 跑出的 Hit@3、nDCG 不低于第 15 周 Day 5 记录的基线值，且基线数字是最近一次跑的，不是三周前的
• [ ] 引用抽样人工核验 20 条：随机抽 20 条带 citations 的回答，逐条点开核对出处真的支撑结论，重点抓「幽灵引用」——出处存在但内容和结论对不上
• [ ] 权限过滤测试：拿两个租户的测试账号互相问对方知识库的内容，确认检索层过滤生效，返回的是「不知道」而不是对方数据
• [ ] 库外题降级测试：评估集里那几道知识库外的题，系统老实说不知道，没有硬编
• [ ] 成本预算与限流：单次问答成本算清（第 21 周的成本账），月度预算和单用户限流阈值配置生效，超限有明确提示而不是静默失败
• [ ] 降级预案：手动停掉 LLM 服务模拟故障，链路自动降级返回检索原文加出处，用户拿到的是没润色的资料而不是报错页
• [ ] 监控面板就绪：tracing 能看到每次问答的完整链路（路由结果、召回数、重排耗时、生成延迟），成本看板按天更新
• [ ] 语义缓存抽检：缓存命中与非命中各抽 10 条对比答案一致性，阈值没有误伤相邻问题
• [ ] 删除与更新链路验证：删一篇文档后检索全链路查不到残留（第 15 周 Day 6 的清三路：pgvector 行、BM25 索引、管理列表）
• [ ] 回滚方案：当前版本代码打 tag，配置快照存档，出问题能在 30 分钟内回到上一个版本

这份清单看着烦，跑一遍两小时，上线后每次事故复盘你都会感谢它。

上线后运营

上线不是终点，是运营的起点。三件事撑住长期质量。

差例周会制度。 每周固定一小时，流程四步：收集本周 bad case（用户点「答案没用」的记录加客服转来的投诉）→ 归因五桶 → 逐条修复 → 评估集回归。五桶是关键，按第 15 周 Day 7 说的「用户感知到的答错了，病根埋在前面任何一环」来分：切块桶（答案被拦腰切断）、检索桶（该捞的没捞到）、重排桶（捞到了没排进 top 5）、生成桶（资料对了答错了）、内容桶（知识库里根本没这条知识）。前四桶是工程的，第五桶是内容的，归因不同，动手的人就不同——分错桶，修复就使错劲。修完必须跑评估集回归，确认修了这个没坏那个。

知识库内容运营。 知识库是活物，制度每季度改一次，你的库也得跟着动。两件事定节奏：更新跟着源头走——财务改了报销制度，当天重新入库对应文档，别攒着；失效要清干净——旧版制度下架时按第 15 周 Day 6 的删除链路走完三路清理，最怕的就是新旧两版同时在库里，检索随机命中，一半用户拿到作废答案。给每篇文档标生效日期，管理界面上过期文档一眼可见。

指标看板三个数。 命中率：回答带引用且引用被判定相关的比例，衡量检索质量；引用点击率：用户点了 citations 的比例，衡量出处是不是真有用——点击率高说明用户真在核验，这是第 15 周 Day 4 做 citations 分字段的直接回报；解决率：用户没有紧接着换种问法重问、也没有转人工的比例，衡量产品整体是否真的解决了问题。三个数每周进周会，和上周比，和基线比。

自测 5 题

先口头答，再展开对照。答不上来的，回对应小节。

1. 为什么产品定义要先于架构设计？「不做什么」为什么值钱？

答案

最贵的错误不是技术选错，是承诺错。答应了什么都能答，之后每次答不出都是事故；边界写清楚，边界外的问题就有资格说「不归我管」。本篇明确不做多轮复杂推理和实时数据：前者需要跨文档规划，属于另一个产品线；后者的答案是分钟级变化的，该走工具直连，RAG 的知识入库那一刻就冻结了。

2. 六个关键决策里，哪几个必须靠评估集数据拍板？为什么不能靠经验？

答案

切块参数、K 与 Rerank 的取舍、语义缓存阈值，三个都得让数字说话。切块的最优值依赖语料形态（费率表和散文的最优切法不同）；召回宽度 50 和 top 5 是第 15 周 Day 2 的典型格局，但延迟和命中率的平衡点因场景而异；缓存阈值低了会把「住宿标准」错配给「超标审批」，只有抽检数据能告诉你阈值压到了哪条安全线。共同原因：这三个参数的效果用户感知直接、因果路径长，拍脑袋定等于把风险藏进上线后。

3. 降级预案为什么选择返回检索原文，而不是返回「系统繁忙请稍后再试」？

答案

LLM 挂了，但检索链路（Embedding、pgvector、BM25）是好的，检索原文加出处对用户仍然有价值，只是少了润色。返回「系统繁忙」是把能给的也不给了；硬等 LLM 恢复则让故障面扩大到全链路。降级的原则：链路上哪一段还活着，就把哪一段的产出交出去。

4. bad case 归因五桶是哪五桶？分错桶的代价是什么？

答案

切块、检索、重排、生成、内容五桶。前四桶是工程问题（答案被切断、没捞到、没排进、答错了），第五桶是知识库里根本没有这条知识。代价：归因分错桶，修复就使错劲——比如把内容桶的 case（库里没这条知识）当检索桶去调参数，怎么调都修不好，周会开成无限循环。五桶对应「用户感知的答错，病根埋在前面任何一环」，先归因再动手。

5. 引用点击率这个指标衡量什么？它偏低可能说明什么？

答案

衡量用户是否真的在用 citations 核验答案，是引用质量的间接信号。偏低有两种可能：一是答案足够可信，用户不需要核验（好事）；二是引用本身不痛不痒，点开发现和结论关系不大，用户点几次就不点了（坏事，要抽查幽灵引用）。单看一个数下不了结论，要结合命中率看板和人工抽检交叉判断。

---

零件到这里全部装完。第 14 周你画的那张三框流程图，如今长成了带认证、缓存、监控和运营制度的完整产品。下一篇落地实战，换个产品线，继续用同样的方法：先定边界，再拼零件，再谈上线。