group_fqcd_jr/开发文档/D3.5-知识库检索升级备选方案建议-2026-09-17.md

D3.5 · 知识库检索升级备选方案建议

体系编号：D3.5　·　域：三、现行权威·完整版与专项　·　编号体系见 D1.1 §4.0

编号：CS-KB-2026-020　|　版本：v1.0　|　日期：2026-09-17　|　状态：现行（专项建议） 性质：补充方案池，不推翻 D2.4 的八项决策。只做三件事：① 指出 8 处会让 D2.4 "纸面成立、工程落空"的前提风险（K-01~K-08）；② 给出 8 个可升级方向（含代价、适用条件、验收判据）；③ 给出"本轮 / 下一轮 / 明确不做"的推荐组合。 权威关系：本文不是需求或任务来源。任何一项要落地，必须先修订 D2.2（需求）/ D2.4（设计）/ D2.1（任务），顺序见 D1.1 §1。 读法：先看 §0 → §2（前提风险，必须先解决，且与"更优秀的方案"无关——它们是"方案能否成立"） → §3-D（判定策略，本轮收益最大）→ §4（推荐组合）。

---

0. 一句话结论

D2.4 的安全设计（档位硬隔离）写得比行业常见做法更严、更对，不需要换；真正的问题在另外两处： ① 它有 4 个未验证的前提，其中 K-01/K-03 会让"三档已接通"变成空转，甚至让客户侧体验比改造前更差； ② 它的优化维度选得偏"保守" —— 8 项决策里 5 项是"不做"（不做混合、不做重排、不换模型、不做父子块之外的演进），整套方案没有任何一项针对"答不出"。

因此我的建议不是"换方案"，而是在 D2.4 之上补三件事：先修前提（K-01/K-02/K-03）、再补 Query 侧与判定侧的增益（§3-B / §3-D）、最后用评测集把"更智能"变成可举证的指标（§3-G）。

结论	内容
✅ 保留	三集合按知识类型划分 · 独立标量字段 + 服务端拼装 · internal 切分阶段丢弃 · 签名不接收可见性参数 · over-fetch 与过滤成对 · 缓存键含档位
🔴 先修	K-01 集合无 visibility · K-02 集合级 fail-open · K-03 检索层现状只放 public（时序风险）· K-07 重修须 drop 而非 upsert
➕ 建议补	§3-B 术语归一化 + 多查询扩展 · §3-D 分级判定（同族合并 / 异族澄清） · §3-G 评测集回归门禁
⏸ 建议缓	§3-A 混合检索（有条件）· §3-H 重排（有条件）· §3-E 文档级 + 块级双层档位（下一轮）
❌ 建议不做	物理双集合 · 换嵌入模型 · 提示词层做权限 · 新增第 4 集合（见 §5-9，改用 type 标签）

---

1. D2.4 的定位与它真实依赖的前提

D2.4 §3.2 自述"9 个组件中 6 个很可能已存在"，三个核心扩展点是：档位标注器新增 · 向量库工具签名改 fail-closed · 集合 Schema 增加 visibility 字段。

这三件事全部依赖同一个前提："三集合可以被按含 visibility 的最终结构建立或改造"。而这个前提当前既未被验证，也没有唯一落点：

依赖前提	文档现状	实际状态（本轮读码级）
集合 Schema 含 visibility	D2.4 附录A 视为既定	🔴 tools\setup_milvus_knowledge_collections.py 定义的三集合不含 visibility（字段为 knowledge_id/title/snippet/tags/version/intent/embedding）
存在唯一的建集合落点	D2.4 未点名任何脚本	🔴 两个脚本写同一批集合名、两套 schema：上述脚本 vs tools\load_knowledge_milvus.py（含 visibility）
检索层会按档位过滤	D2.1 D-01/D-02 待做	🔴 app\service\knowledge_search_service.py:138-154 现返回 visibility == "public"；:507 仍有 or "public" 回落
灌库能标注档位	D2.1 B-01 门禁待做	🔴 tools\build_knowledge_chunks.py 全部硬编码 visibility: "public"；knowledge\_chunks.jsonl 实测 617 行全 public

🔑 这正是 D2.4 全文最重要的那句话的反面：它说"把权限边界从提示词层移到检索层"，但在当前工程状态下，检索层的边界是一个恒真的表达式（全库都是 public，过滤等于不过滤）。

---

2. 🔴 前提风险 K-01~K-08（先修，与方案优劣无关）

#	风险	证据	后果	修法	验收判据
K-01	集合可能根本没有 visibility 字段	建集合脚本的 VARCHAR_FIELDS 无该字段；app\core\knowledge_schema.py 文件头记录的"环境甲无可见性字段"	D2.4 的三档、AC-01、AC-04、DEC-09 全部失去载体	E-3 实测；若缺 → N-07 授权 drop 重建（含 visibility + 倒排索引）再重灌	describe_collection 返回含 visibility；三集合维度一致
K-02	集合级缺字段 = fail-open	knowledge_search_service.py:138-154：无字段的集合 _visibility_filter 返回 None，即不过滤	该集合内的 internal/registered 内容对所有人可见；而 D-02 只承诺"缺字段时不再回落 public"（那是 :507 的行解析层，管不到集合层）	判据从"有没有字段"改为 "缺该字段的集合，本轮不参与检索 + 独立计数"（宁可少答不可不设防）	造"缺字段集合"替身测试：断言其不返回任何命中且计数 +1
K-03	🔴 检索层现状是"只放 public"，与"客户可见 registered"直接冲突	同上 :154 返回 visibility == "public"；app\service\knowledge_tool.py 仍 del context 不传档位	一旦按 D2.4 §4.5 把产品参数落成 registered，登录客户也查不到费率/起投金额 → 客户侧"未命中 → 转人工"立刻变多，比改造前更差	D-01/D-02 与灌库改造必须同批上线（同一批、同一次重灌），不得先落档位	双向用例同时绿：访客查 registered → 空；客户查同一问 → 命中
K-04	over-fetch ×3 对某些集合可能不足	D2.4 §4.5 把《高净值客户服务规范》整篇放进 fin_product_collection，档位 registered（约 30–45 块）；×3 的依据是"FAQ 集合 registered 占比 < 20%"	过滤后 TopK 不足 → 被误判"无答案" → 兜底（正是 RK-16）	按集合分别定倍数：先用入库报告输出各集合档位占比，再按占比反推（registered 占比 p → 倍数 ≥ 1/(1-p) 起步，再留余量）	过滤后为空率与改造前同量级；各集合 registered 占比有数
K-05	词法回退缺档位列 → 新越权面	D2.4 §5.8 的 D1/D2 回退走"关系型库 LIKE"；而 MySQL 侧知识表结构与档位列未实测（T-10）	回退路径若无法过滤档位，它就是绕过可见性过滤的后门（D2.4 §5.5 规则一明令禁止）	本轮直接把词法回退限定为"只搜已确认 public 的白名单来源、≤3 条、标注已降级"，并在文档登记为已知降级	回退命中不含任何 registered 来源；有独立计数
K-06	FAQ 阈值 0.75 偏高	实测：短条目 + 标题与问法逐字对齐才 0.7384（gap 0.0761 刚过线）	阈值实际靠"内容写得像问法"勉强跨过；新 FAQ 稍长即掉落	降到 0.70–0.72，或按 FAQ 子类型分阈值；并把"标题逐字对齐问法"写成入库规范（§3-C）	30–50 条标注集上 FAQ Top1 命中率与兜底率同时改善
K-07	重修必须 drop 集合重建，不能 upsert	docs\演示用\知识库检索质量修复-2026-09-15.md §7：_chunks.jsonl 已是修正后 617 块（编号连续），Milvus 仍是旧编号（含 19 个空洞）	upsert 会让同一内容出现两份向量、新旧编号共存	B-04 的 DoD 明确写"drop → create → 重灌"，并先备份集合清单与行数	重灌后行数 = 617（或新统计值）；无重复正文
K-08	交付文档未点名任何灌库/建集合脚本	D2.1~D2.4 对 build_knowledge_chunks / setup_milvus_knowledge_collections / load_knowledge_milvus 的命中数为 0	T-02/T-06/DEC-04（"一次性创建 vs 改造既有"）没有可执行的落点依据，实施时只能自行猜测	D2.4 附录A 增"落点清单：脚本相对路径 + 职责"；D2.1 B-01/B-04 的落点补脚本名	按文档能唯一定位到脚本

---

3. 八个可升级方向

3.0 总览对比

#	方向	解决的问题	代价	本轮建议	触发条件
A	双路召回 + RRF 融合（向量 + 词法）	术语/编号类问句（R1/C3/T+1）向量不敏感	需一条能过滤档位的词法路	⏸ 有条件做	标注集上出现"术语类召回不足"的实测证据（D2.4 §7.3 决策7 已给该条件）
B	Query 侧增强：术语归一化 + 多查询扩展	措辞与原文不重合；同义/缩写	1–3 次额外向量检索；多查询扩展需 1 次 LLM 调用	✅ 做（归一化必做）	立即
C	条目形态与分块：块长上限 + 标题即问法 + 同族块合并	"块太长被稀释"（实测 0.498 → 0.738 的差距）	改内容，需重灌	✅ 做（性价比最高）	立即
D	🔴 判定策略重构：分级决策	同族打平被误判"候选并列"→ 转人工	只改业务层判定 + 阈值配置	✅ 强烈建议做	立即
E	档位与集合模型演进（策略表 / 缺字段策略 / 双层档位 / 第4集合改 type）	fail-open、逐块漏标、集合数膨胀	配置项 + 元数据表	⏸ 部分本轮（策略表 + 缺字段策略），双层档位下一轮	元数据表结构实测（T-10）后
F	入库门禁与质量指标（可量化 5 项）	质量前移到入库，减少调参	脚本工作量	✅ 做	与 B-01 同批
G	🔴 评测集驱动的回归门禁	"更智能"不可举证	30–50 条标注集 + 1 个脚本	✅ 强烈建议做	立即
H	重排的低成本路线	Top1–Top3 排序质量	小模型或 LLM 调用	⏸ 缓；先用"确定性排序"	TopK 提升到 10 以上，或出现"正确块进候选但未进前 3"的实测

---

3-A 双路召回 + RRF 融合

现状其实已经有一半：app\service\knowledge_search_service.py 里已有 _product_keyword_hits()（产品名字面召回）与 _parent_hits()（父块带回）。所以"混合检索"不是从零开始，而是把现有的"字面召回"从产品名扩到通用词面。

• 做法：向量 Top20 + 词法 Top20 → RRF（Σ 1/(k+rank)，k=60）合并 → 过阈值 → 截断 top_k。
• 词法路的两条可选落点：① Milvus 侧稀疏向量/全文（pymilvus 2.5 支持）；② MySQL FULLTEXT + ngram 解析器（零新中间件，团队已有 MySQL）。
• 🔴 硬约束：词法路必须能过滤档位（D2.4 §5.5 规则一）。选 ② 就要求 MySQL 侧有档位列 —— 而该表结构未实测（K-05）。这条约束不满足就不做，否则它就是新的越权后门。
• 验收：标注集上"术语/编号类"问句 Top1 命中率提升，且访客越权用例仍 0 命中。

3-B Query 侧增强（本轮性价比最高，且不改底座）

1. 术语归一化（必做，零模型成本）：维护一张术语映射表（R1—R5 / C1—C5 / T+1 / 七日年化 / 净值型 / 业绩比较基准 …），把用户写法与文档标准写法互映，查询前归一化。当前失败案例（"r1到r5分别代表什么"）正是这类。表纳入版本控制（J-06 已建议），可审计、可单测。
2. 标题逐字对齐（已实证有效）：实测"短条目 + 标题与问法逐字对齐"把 0.6622 拉到 0.7384。这是内容侧修法，落成 §3-C 的入库规范。
3. 多查询扩展（建议做）：用 app\service\model_gateway.py 把问句改写成 2–3 个变体（含术语标准化），各查一次，取并集与最高分。合规性：仍然是多次调用既有工具 search_knowledge，不改签名、不在业务层重建检索实现 —— 与 docs/14 的 N-2/N-4 不冲突。
4. HyDE（不建议本轮）：让模型先写"答案草稿"再检索，效果强但引入幻觉面，与金融场景的"宁可答不出"取向冲突。登记为演进项。

3-C 条目形态与分块

措施	依据	做法
块长上限	实测：同一条目 488/433 字时 0.6622，272 字时 0.7214	超长块必须拆；建议正文上限 ~350 字（与 512/64 并存，作为上限而非目标）
标题即问法	同上；标题-问法逐字对齐 → 0.7384	入库规范：块标题必须含该块能回答的问法核心词面（概念块用术语原词，FAQ 块用问句原句）
同族块归并	"高净值权益" gap 0.0075：HNW-004 金卡 vs HNW-005 白金天然接近	同一主题的同族块合并为一张对比表（层级 × 权益），而不是靠调阈值
表格整表	D2.4 §5.1 已有	保留；超限按行组切分并重复表头

📌 这四项全是内容侧改动，与"权限/合规"无关，且收益已被你自己的三次实测证明（切分 → 父块 → 短条目）。相比检索侧调参，这是收益最高、风险最低的方向。

3-D 🔴 判定策略重构（本轮解决"强制转人工"的核心）

现状：score ≥ 0.75 → 直答；否则 score ≥ 0.55 且 gap ≥ 0.07 → 答；否则转人工。

它的问题不是数值，而是维度：把"打平"当成一种失败。但打平在语义上分两种，处置应当不同：

打平类型	例子	现状处置	应当处置
同族打平：top1/top2 语义上是同一主题的不同分支	「高净值客户有什么权益」→ 金卡权益 vs 白金权益（gap 0.0075）	转人工（错）	合并作答：把同族块一起给，明确"分层级/分档位列出"
异族打平：top1/top2 来自不同集合/不同主题	一问问到"费率"的同时撞上"赎回流程"	转人工（错）	澄清：反问"您问的是 X 还是 Y"，给出可答范围
低分：top1 低于下限	完全没收录的问题	转人工（对）	保持，但兜底前先澄清一次

建议的分级决策（G1~G4）：

级	判据	动作
G1	top1 ≥ T_high	直答（或按 N-02 受限改写）
G2	T_mid ≤ top1 < T_high 且 次优与 top1 同族（同父块 / 同章节前缀 / 同来源文件）	合并同族块作答，回答中显式分列
G3	T_mid ≤ top1 < T_high 且 次优异族	澄清（列出可答范围，等价 FR-CS-003 的落点）
G4	top1 < T_mid	先澄清一次；再失败 → 兜底 + 建议转人工⚠️ 本条已过时（2026-09-19 标注）：FR-CS-023 的「连续 2 轮兜底」已在 v2.5 删除，改由 FR-CS-003（澄清）与 FR-CS-008（分级回退 E5b）承接；转人工仅限白名单 4 类

🔑 "同族"是结构性判据（doc_id 前缀 / section 父块 / 来源文件），不是相似度数值 —— 这正好复用了检索服务里已有的 _parent_of() / section_ids 机制，不需要新架构层。 🔑 收益：docs\演示用\ 里两例"必然转人工"（gap 0.021 / 0.0075）在 G2/G3 下都会变成有答复，且不需要放宽阈值、不需要重灌库。 ⚠️ 前提：G2/G3 的落点必须在客服业务层出口（handle() 之后的自有分支），不得改检索服务签名、不得在业务层自建检索（N-2/N-4）。

3-E 档位与集合模型演进

子项	内容	本轮
E1 策略表配置化	把"主体 → 允许档位集合"从代码常量升级为配置项（D2.4 §10.2 已有 VISIBILITY_DEGRADED_LEVELS 的先例可循），使"访客档位可实时收紧"落在配置上	✅ 做
E2 缺字段策略显式化	新增配置 TIER_FIELD_MISSING_POLICY = "exclude_collection"（默认最严），把 K-02 的隐式 fail-open 变成显式配置 + 启动自检	✅ 做
E3 双层档位	文档级默认档 + 块级覆盖（D6.1.2 那次 Q47/Q53 漏标就是逐块标注的固有风险）	⏸ 下一轮（需元数据表结构，T-10）
E4 集合数量最小化	见 §5-9：DEC-08 的"第 4 集合"建议改为 fin_policy_collection + type 标签	✅ 建议改

3-F 入库门禁与质量指标（可量化 5 项）

在 D2.1 B-01（四查）之上补 5 项可量化门禁，全部进报告：

#	指标	阈值建议	为什么
1	块长上限	正文 ≤ ~350 字（超限必须拆）	实测"块越长分越低"
2	标题-问法重合度	概念块标题含术语原词；FAQ 块标题与问句原句逐字一致	实测 0.662 → 0.738
3	档位分布	集合级 registered 占比有数；FAQ 集合 registered < 20%（否则重估 over-fetch，见 K-04）	支撑 over-fetch 取值
4	同族块数量	同一 section 下子块数超阈值（如 > 8）→ 建议改造成独立 FAQ 或对比表	治"同族打平"的根
5	未命中清单签收	报告未签收即视为本次入库无效（D2.4 §4.4 已有，须真正执行）	防"默认放行且无人复核"

3-G 🔴 评测集驱动的回归门禁（让"更智能"可举证）

D2.4 §5.6 已要求"30–50 条标注数据做阈值校准"，但没有要求把它固化。建议升级为仓库内资产 + 门禁：

• 资产：30–50 条标注问句（query + 期望命中块 + 期望档位 + 期望主体），覆盖三类意图与两类主体，落进仓库（J-06/J-08 的延伸）。
• 三个可证伪指标：① Top1 命中率（目标 ≥ 85%）；② 兜底率（目标与 N-01 口径一致，演示时打印）；③ 档位越权命中数（目标恒 0）。
• 门禁化：一个脚本（如 tools\eval_knowledge_recall.py）跑三指标，输出带日期与语料批次号的报告；知识库版本变更后必须重跑，指标劣化超过阈值即为回归。
• 为什么最关键：答辩时"我的客服能答 85% 的问题"这句话，只有标注集 + 报告能证明；否则仍然是"我觉得它更聪明了"。

3-H 重排的低成本路线

• 第 0 步（零成本，建议本轮做）：确定性排序——三集合合并后按元组 (score, 是否字面命中, 是否档位匹配, 块长惩罚) 排序。不需要模型，可单测。
• 第 1 步（可选）：只在 G2/G3 分支（候选 ≤ 10 条）触发重排，可用小 cross-encoder 或 LLM 重排；CPU 可接受，且不进入主链路延迟预算。
• 不建议：对全部请求做重排（D2.4 决策8 的否决理由成立：TopK 仅 3–5 条时收益有限、扩大延迟）。

---

4. 推荐组合（与 DEC-11 交付节奏耦合）

4.1 若 DEC-11 选 (b)"只做 P0 路径保演示"

优先级	动作	理由
P0-1	修 K-01/K-02/K-03/K-07（实测 → drop 重建 → 重灌 → 与 D-01/D-02 同批）	不修则"三档"是空转，且客户侧体验倒退
P0-2	§3-D 分级判定 + §3-B 术语归一化	直接消灭两例已知"必然转人工"，零重灌成本
P0-3	§3-C 的四项内容侧措施（含 K-06 阈值下调）	已被三次实测证明收益最大
P0-4	§3-G 评测集 + 三指标（含 N-01 口径）	让"更智能"可举证
P0-5	前端入口重建（Q-1.4 / N-06）	AC-12 的可见前提
缓	§3-A / §3-H / §3-E3	有前置或收益低

4.2 若 DEC-11 选 (a)"7 批次全做"

在 4.1 之上加：§3-A（须先解决 K-05 的档位列）、§3-E1/E2、§3-E3、§3-H 第 1 步。

4.3 明确不做

物理双集合 · 换嵌入模型（会与底座既有集合不同维）· 提示词层做权限 · 对全部请求重排 · 把 internal 留在库里靠检索过滤。

---

5. 对 D2.4 / D2.1 的具体修订建议

#	修订对象	建议
1	D2.4 §5.4	补"缺该字段的集合本轮不参与检索 + 独立计数"（K-02），明确这是 exclude 而非 skip filter
2	D2.4 §5.5	回退不降标准：保留 0.65 但要求"回退命中必须标注来源集合与置信提示"；回退命中不得用于适当性/合规类结论
3	D2.4 §5.8	词法回退限定 public 白名单来源 + ≤3 条 + 独立计数（K-05）
4	D2.4 §5.6	FAQ 阈值由 0.75 调整为 0.70–0.72（或按子类型分档），并注明"以标注集实测校准为准"（K-06）
5	D2.4 §4.1	over-fetch 由全局 ×3 改为按集合取值，并给出取值方法（K-04）
6	D2.4 附录A	增"脚本落点清单"：tools\build_knowledge_chunks.py（分块+档位标签）、tools\setup_milvus_knowledge_collections.py（建集合，须加 visibility）、tools\load_knowledge_milvus.py（写入）、app\infrastructure\milvus_knowledge_writer.py（API 入库，档位默认值属已知未修项）（K-08）
7	D2.4 §4.4 / §5.2	把"未签收即入库无效"从原则改为报告字段 + 门禁判据
8	D2.1 B-04	DoD 增：drop → create → 重灌（不是 upsert）；重灌后行数留档（K-07）
9	D2.1 / D2.2（DEC-08）	🆕 不建议新增第 4 集合：金融行业基础信息（概念/术语/时限/风险等级含义）并入 fin_policy_collection，用 type=basic 标注。理由：① 内容量小（40–60 块），第 4 集合的语义收益有限；② 新增集合会牵动 D2.4 全篇"三集合"表述、AC-01、over-fetch、回退顺序、前端与监控指标，改动面远超收益；③ 若未来该类内容超过 ~100 块，再独立成集合（把"集合数"做成可演进而非现在拍死）。若你仍选新增集合，则 D2.4 全篇的"三集合"必须逐个改为"四集合"，不能只改 §4.1
10	D2.1	补任务：E-09 受限改写（N-02）· E-10 跨集合回退（FR-CS-008）· E-11 澄清（FR-CS-003）· E-12 分级判定与常数（N-03）· E-13 前端入口重建（N-06）· E-14 发布脚本 + 重发 config_release（P-6/P-7）

---

6. 验收与可证伪性补充

#	判据	怎么验	对应风险
1	三集合含 visibility 且维度一致	describe_collection 输出留档；维度不符拒绝启动	K-01
2	缺字段集合不返回任何命中	替身测试：缺字段集合 → 命中 0 且计数 +1	K-02
3	客户查产品参数能命中、访客查同一问为空	双向用例（同一 query 两主体）	K-03
4	过滤后为空率不上升	与 A-04 基线对比	K-04
5	回退路径无越权	回退命中的来源集合与档位全部留痕、无 registered	K-05
6	兜底率与 Top1 命中率	§3-G 的三指标报告（带语料批次号）	全局
7	两例已知转人工问句可答	「r1到r5分别代表什么」「高净值客户有什么权益」两条进标注集，作为回归用例	§3-D
8	无重复向量	重灌后无同正文双份	K-07

---

7. 代价与风险总表

动作	代价	风险	对策
drop 重建集合	需重灌 617 块；Milvus 运维	重灌期间检索不可用	低峰执行；先备份集合清单与行数
阈值下调（0.70–0.72）	误答概率上升	金融场景"答错 > 答不出"	必须配套 §3-G 的标注集证明"误召回率"未明显上升；不合规表述仍由既有输出侧词库兜住
分级判定（G2 合并作答）	回答变长、可能含无关分支	同族判据写错 → 答非所问	"同族"用结构性判据 + 单测；回答中显式分列（可读性即可发现错）
多查询扩展（§3-B3）	1 次额外 LLM 调用 + N 次检索	延迟上升（NFR-CS-001 < 2s）	并发检索；对延迟设超时与降级（退化为单查询）
新增评测集门禁	标注工作量（30–50 条）	无人维护会腐烂	纳入版本控制 + 批次号绑定（J-06）

---

8. 维护责任与同步义务

1. 本文为建议：任一项被采纳后，须先改 D2.2（若涉及需求/验收）→ 再改 D2.4（设计）→ 最后改 D2.1（任务），顺序见 D1.1 §1，不得反向。
2. K-01~K-08 全部闭环后，在本文对应行标注"已闭环 + 日期 + 证据（脚本输出或测试名）"。
3. §5-9（第 4 集合）与 D1.5 DEC-08 冲突：若采纳本文建议，必须同步改 DEC-08 的选项与 D2.4 全篇"三集合"表述；若维持原建议，则本文该行标注"未采纳 + 理由"。
4. 引用约定遵守 D1.1 §9（体系编号优先，代码用 仓库内相对路径:行号）。