本轮只改文档(12 份,无代码改动),把 `W27` 的代码实绩(`L0` 表层判定层 + 出口 `E6` 行情)在**全部交付面文档**上对齐。 此前工程侧已入库(3e24033),但答辩面文档仍留「五出口 / 六出口」旧口径,是最容易被评委当场戳到的自相矛盾点。 ## 一、口径统一:五出口 → 七出口 + `L0` - `D3.6`(被多处引为「五出口权威定义」):加**口径更新横幅**(列明 `W20` 六出口、`W27` 七出口 + `L0` 的演进线, 并写明「不变的」——转人工仍只是 `E5c`、白名单仍 4 类、`INV-1`~`INV-5` 一条没改);§3 标题加「起步定义」; **新增 §3.0**说明 §3.1—§3.4 的适用范围;本页 `D3.7` 配套行的金标计数 46→55、10→11 项指标。 - `D1.1`:7 处索引/清单行对齐(`D2.6` / `D2.10` / `D3.6` 的描述与计数),其余「五出口」全部保留为**历史记录**。 - `D2.6`:配套行补 `D3.9` 指向;**新增 `W27` 状态更新段**(金标扩容到 55 条 + 第七个出口 + 三处真缺陷修复), 并显式声明「上一条 `W24` 的『六个出口』口径已由本条扩为七个」。 - `D3.7`:性质行/读法/§0 计数对齐(46 → 55、十项 → 十一项指标);**§4 增补 `W27` 扩容后的分母口径表** (`M-1`/`M-4`/`M-5`/`M-6`/`M-10` = 55、`M-2` = 33、`M-2b` = 20、`M-3` 明示「考检索的 C 组」,门槛不变)。 - `D2.9`:引用表新增 `D3.9` 行;判分输入件由 `cases_46.json` 更新为 **`cases_55.json`**(附两个分母的产物名)。 - `D2.8`:`W27` 判定补充行(前批已入库,本轮核对通过)。 ## 二、HTML 规格文档:只声明口径,不重写历史 `D3.1`(需求开发文档)/ `D3.2`(知识库方案)/ `D2.2`(需求收敛版)/ `D2.4`(知识库收敛版) 四处 `§0.1` 之前各加一段 `callout-warn` 口径更新:说明「五出口」是 v1.x/v2.x 时点的**起步定义**、 现行是「七出口 + `L0`」,并明确**语义与安全结论全部有效、只是不再是全集**,指向 `D3.9` 与 `D2.6` §3。 (`_build` 已标注「已过期·请勿重新生成」,故直接在成品上改,不重跑生成器。) ## 三、`D2.10`(端到端答辩文档) `六出口` → **七出口 + `L0`**(徽标 / meta / Mermaid / S8 表 / 时间分配 / 文档关系表,共 5 处); §3.8 出口表**新增 `E6` 行情行**,正文补 `L0` 段落;§4.1 阈值表后**新增口径更新块** (区间重叠 ⇒ 单点阈值不存在;阈值降为安全下限;「跨集合回退 0.65」在代码中不存在); §6.1 标题与「两个分母都报」的实测块对齐 55 条;§11 补 `D3.9` 与 `W27` 证据文件。 ## 四、`D2.5` 演示脚本(答辩当天照着念的那份) **新增 §4.8「行情走势与闲聊」**——针对上轮被点名的两类,全部用 **2026-09-21 真 HTTP 实跑**的答复: - `159382这只ETF最近走势怎么样?` → `E6`,给出近 5/20/60/120 个净值日涨跌 + 区间高低 + 数据区间; - `南方稳健增利债券A最近走势怎么样?` → `E6-miss`,如实说「查不到公开的净值序列」,**拒绝编造**; - `你好呀` / `谢谢你` / `在吗` → 闲聊,**零检索**; - **反向守卫**「在吗,想问下南方稳健增利债券A的起投金额是多少?」→ 必须走知识作答(证明 `L0` 判的是整句); - 附「口径细节」:`E6` **不调模型**(固定模板 + 纯函数,数字全部来自 `fin_nav_history`), 闲聊**调模型但完全不查库**(新跑 `_w27_probe_guard.py` 单独验证反向守卫,另有 `_w27_probe_trend/chat.txt`)。 §6 表补两行(闲聊不再进检索 / 走势是算出来的),金标计数行改为 55 条并附两个分母的指标表。 ## 五、验证 - `_sync_check.py`:权威目录 → 仓库镜像 **0 缺失 / 0 不一致**(13 份同步)。 - `git diff --name-only`:12 份变更**全部是 `.md` / `.html`**,**无任何代码改动** ⇒ 不影响已绿的 `pytest 2094 passed / 3 skipped`(3e24033 已复跑)。 - 本轮实测证据保留在 `D:\桌面\金融\_w27_probe_guard.py` / `.txt`(答辩后勿删)。
29 KiB
D3.6 · 客服 Agent 智能增强架构建议
体系编号:
D3.6· 域:三、现行权威·完整版与专项 · 编号体系见D1.1§4.0
编号:CS-ARCH-2026-021 | 版本:v1.2 | 日期:2026-09-21 | 状态:现行(专项建议;§9 八项已于 2026-09-17 拍板,裁定见 §9) 性质:建议件,不是需求来源、不是任务来源。任何一项要落地,必须先按
D1.1§1 的顺序修订上游(D2.2需求 →D2.4设计 →D2.1任务),再回填D1.5/D1.6的决策登记表。 读法:§0(结论)→ §1(为什么现在不智能,含代码取证)→ §2("智能"的 7 条可验收定义)→ §3(五出口架构,起步定义;现行已扩为七出口 +L0,见本页横幅)→ §4(安全设计,不放松反而更严)→ §5(要改哪些上游条款)→ §9(需你拍板的 8 项)。 配套:知识库侧的检索升级见D3.5;前提风险K-01~K-08见D3.5§2;验收依据见D3.7(基线 46 条 +W27扩容 9 条 = 55 条金标 / 11 项指标 / 4 项零容忍)。
🔴 口径更新(2026-09-21
W27,本件之后的口径以D3.9为准):本件 §3 的 五出口(E1—E5)是起步定义,此后经两轮扩充 —— ①W20把E2细分为E2a—E2e并新增E2c-my(以本人等级为对象的可购买范围,六出口); ②W27新增 出口E6行情(走势 / 净值 / 涨跌,独立数据源fin_nav_history),并新增L0表层判定层 (L0-a闲聊 /L0-b行情 /L0-c本人数据 /L0-d计算型参数位 /L0-e无信息量)——L0不产出任何事实,只做路由前置判定,出口码E0只作日志与审计分组名,不写入CoreResult.exit_code。 ⇒ 现行口径为「七出口 +L0层」:出口族 =E1/E2(含E2a—E2e)/E2c-my/E3/E4/E5/E6;另有安全类出口码(P0/P1/P2/COMPLIANCE/PROMPT_INJECTION/ADVICE_BOUNDARY/E8)与语义出口码(CHAT/LOGIN/CONTACT),见app/core/exit_codes.py。 不变的:转人工仍然只是E5c那一档,白名单仍是 §4.3 的 4 类,INV-1~INV-5一条没改(W27另加INV-6数字可溯源 /INV-7数据边界自陈,见D3.9§7)。 本件 §3 的出口语义(澄清 / 计算 / 知识直返 / 证据约束生成 / 分级回退)全部有效,只是不再是全集。 设计与实测以开发文档\D3.9-客服Agent智能路由与行情出口设计-2026-09-21.md为准;验收侧口径见客服agent\D2.6-客服Agent答辩报告-2026-09-19.md§3。
0. 一句话结论
不智能的根因不是知识库或模型不行,而是决策链上只有两个出口——「命中够分就原文直返」/「除此之外一律转人工」。旧实现 handle() 里 10 处失败方向全部指向转人工(§1.2 取证)。更要紧的是:旧设计文档里本来就写了澄清与"多命中就该组织语言",只是从未实现(§1.3 取证)。
⇒ 升级路线是 把出口从 2 个扩到 5 个,同时把安全从"输出侧禁词"搬到"检索层与判定层",安全边界一个都不放松。
✅ 2026-09-17 已拍板:出口扩到 5 个(
DEC-I1);允许证据约束生成(DEC-I2);DEC-I3—DEC-I6按本文件建议执行;金标评测集由 AI 产出(DEC-I7→ 见D3.7);计算型对访客档分项开放(DEC-I8→ 见 §9.1)。本文件已由"建议件"转为"已裁定件"。
1. 诊断:三条结构性缺陷(全部有代码取证)
1.1 智能被"安全"挤占了位置
安全被实现成输出侧的字面黑名单(_cs_purge_backup\app\core\customer_service_rules.py):
ZERO_TOLERANCE_WORDS含裸词「安全」「年化收益率」「预期收益率」;YIELD_TRAP_PATTERNS含裸正则年化、收益率。
⇒ 后果:客户问「什么叫七日年化」这种概念解释题,命中裸正则 → 直接进合规拒答分支 → 客户体验是"问什么都被拒"。
根子在于:把"不得承诺收益"实现成了"不得出现这几个字"。合规要求约束的是结论(我给不给你一个收益承诺),不是字面(我说没说到"年化"这个词)。
📌 另一面必须承认:
route_message()的五档确定性安全路由(P0 反诈 → 提示词注入 → 合规拦截 → P1 账户数据 → P2 转人工诉求)本身是比行业常见做法更严谨的设计——它不依赖模型、顺序有理由(P0 优先于合规,因为"有人推荐保本年化5%的产品还要我验证码"必须先拿到反诈话术)。这一层要保留,只改它误杀的那一类。
1.2 决策链只有两个出口:10 处失败方向全部指向转人工
_cs_purge_backup\app\service\agent\implementations\customer_service.py:
| # | 触发条件 | 结果 | 位置 |
|---|---|---|---|
| 1 | 安全路由 P0 / P1 / P2 命中 | 固定话术 + transfer_required=True |
handle() |
| 2 | 意图未覆盖 | 「不猜,直接引导人工」 | :238-240 |
| 3 | 知识工具调用异常 | 转人工 | :300-301 |
| 4 | 知识工具返回格式异常 | 转人工 | :303-304 |
| 5 | 检索 degraded 降级 |
转人工 | :305-307 |
| 6 | 知识库未命中 | 转人工 | :309-310 |
| 7 | 置信度不足(score < 0.75 且不满足 score ≥ 0.55 且 gap ≥ 0.07) |
转人工 | :320-322 |
| 8 | 命中内容为空 | 转人工 | :328-329 |
| 9 | 画像查询失败 / 画像为空 | 转人工 | :271-277 |
| 10 | 闲聊模型不可用 / 返回为空 | 转人工 | :565-569 |
D1.6§3.1 记录了其中与知识出口直接相关的 7 条;本表把画像出口、闲聊出口一并补全,共 10 处。这不是分歧,是同一事实的完整版。
关键观察:除第 1 条(安全,应当保留)之外,其余 9 条都是"能力不足"而非"风险"。把能力不足一律映射成转人工,就是"不智能"的直接来源。
1.3 设计里本来有澄清与生成 —— 实现里没有
旧设计文档 _cs_purge_backup\docs\superpowers\specs\2026-09-10-customer-service-agent-design.md:
| 设计要求 | 实际实现 | 差距 |
|---|---|---|
§4:「命中多条:允许调用 generate_with_model() 把这几条标准答案'组织一下语言',Prompt 必须约束'只能使用给定的几段文字,不得添加任何未出现在原文中的新事实、数字、承诺或渠道信息'」 |
_answer_from_knowledge() 的唯一出口是 text=content[:MAX_ANSWER_CHARS](原文切片,:338-341)——从不调模型 |
🔴 多命中生成从未实现 |
§4 判定表:P4 未命中/低置信度 → intent="transfer_human", … needs_clarification=True |
_guide_to_human()(:685-691)只设 transfer_required / transfer_reason,不设澄清标记;全仓亦无消费 needs_clarification 的分支 |
🔴 澄清从未发生 |
⇒ 结论:智能不是缺设计,是缺实现。 这条对答辩很重要——升级路线是「把设计完成」,而不是「推翻重做」。
1.4 已经有 8 项智能资产,被浪费了(复用清单)
备份里有相当完整的中间件,新方案应当复用而不是重写:
| # | 资产 | 位置 | 现在的作用 | 升级后应承担 |
|---|---|---|---|---|
| 1 | 五档确定性安全路由 | app\core\customer_service_rules.py → route_message() |
拦 P0-P2 | 保留为输出前的确定性守护,并加「概念题豁免」(§4.2) |
| 2 | 闲聊生成链路(含发布配置) | customer_service.py → _chitchat() :541-586 + _cs_purge_backup\tools\publish_chitchat_prompt.py + DEFAULT_CHITCHAT_TEMPLATE |
只会寒暄 | 升级为通用的「证据约束生成」出口——同一套 generate_with_model + load_active_prompt 机制,只换一个 prompt code |
| 3 | 适当性裁决 | customer_service.py → _answer_suitability() :374-540 |
只判"能不能买" | "计算型回答"的模板:推广到费率试算、赎回费递进、持有期 |
| 4 | 会话短期记忆 | app\service\customer_service_session_memory_service.py(Redis) |
未被检索充分使用 | 多轮指代消解的数据源(_search_query 现在只从回答里抠产品名,脆) |
| 5 | 话题矩阵 / 主语跟踪 | _topic_of() / _topic_in() / _previous_topic() :439-648 |
只为构造检索词 | 多轮槽位(subject slot) |
| 6 | 行级子块消歧 | _prefer_section() :343-373 |
防止产品名抢答 | 保留(这是对的) |
| 7 | 画像投影协议 | _cs_purge_backup\docs\客服Agent二期_画像投影协议_v1.md |
—— | 个性化回答的边界定义 |
| 8 | 前端接入约束 | _cs_purge_backup\docs\41-客服Agent前端开发约束_v1.md |
—— | 重建 widget 时直接用(注意:D2.3 §2.2 把已删除的 widget 写成「既有·复用」,是文档缺陷 Q-1.4) |
2. "智能"的可验收定义(7 条)
把"智能"拆成可验收的行为,否则无法证明、也无法排期:
| # | 智能表现 | 客户原话 | 现状 | 要补的能力 |
|---|---|---|---|---|
| 1 | 听懂(措辞/别名/口语) | 「你们家的手续费怎么算」 | 别名不在库里 → 未命中 → 转人工 | 术语别名归一化 + 同义词扩展(D3.5 §3-B) |
| 2 | 会答(组织语言,不是甩文档) | 「买季季盈90天要注意什么」 | 原文切片,常答非所问 | 证据约束生成(出口 E4) |
| 3 | 会问(信息不足先澄清) | 「它费率多少」(无主语) | 转人工 | 澄清回合(出口 E1) |
| 4 | 会合(组合/计算) | 「买 10 万要交多少手续费」 | 知识库里没有这句话 → 必然转人工 | 计算型出口(出口 E2) |
| 5 | 会拒(拒得具体,并给替代) | 「什么样的产品不亏钱」 | 裸词命中 → 合规拒答 + 转人工 | 意图级合规判定 + 具体替代引导 |
| 6 | 会记(多轮指代) | 「那风险高吗」 | 靠拼检索词,脆 | 多轮槽位 |
| 7 | 会交(转人工是功能,不是兜底) | 「我要找人工」 | 正常 | 保留——且只有 §4.3 白名单 4 类才该触发 |
3. 目标架构:五出口决策链(起步定义;现行七出口 + L0,见本页横幅与 §3.0)
① 确定性安全路由(P0-P3:反诈 / 注入 / 合规 / 账户 / 写操作)
└─ 不查库、不调模型 ← 保留旧实现(这是对的),只加「概念题豁免」
② L0 表层判定层(`W27` 新增,见 `D3.9` §3.1)
│ 闲聊 / 行情走势 / 本人数据 / 计算参数位 / 无信息量短句
└─ 确定性判定(不问模型、不看分数)命中即转对应出口 ──► 闲聊 / E2* / E6 / E5
②b 身份与档位边界(visitor / customer)
└─ 由「整题拒绝 + 引导登录」改为「可见部分照答 + 不可见部分引导」
③ 意图与槽位解析(含澄清判定)
│
├─ 需要澄清 ──────────────────────────────────► E1 澄清
├─ 可计算(费率 / 赎回费 / 持有期 / 适当性)──► E2 计算型回答
└─ 知识型
├─ 证据充分且唯一 ─────────────────────► E3 知识直返(原文,快路径,不调模型)
├─ 证据充分但多块(同族/组合问)──────► E4 证据约束生成
└─ 证据不足(低分 / 未命中 / 跨族并列)► E5 分级回退
E5a 澄清
└► E5b 部分答 + 引导
└► E5c 转人工(带上下文摘要)
④ 出口 E6 行情(`W27` 新增,见 `D3.9` §4)
└─ 走势 / 净值 / 涨跌:数据源 = 行情接口 + 库内净值序列;不调模型、不猜数
核心变化:转人工从「默认动作」降为最后一档 E5c,且只有 §4.3 的 4 类场景允许直接进入。
3.0 本节口径的适用范围(2026-09-21 补)
以下 §3.1—§3.4 逐条描述的是起步的五个出口。出口码与语义仍然现行有效,但已不是全集:
- 计算的细分:
E2在W20拆成E2a(类别费率试算)/E2b(单只赎回费递进)/E2c(C—R匹配矩阵一格)/E2d(适当性裁决)/E2e(本人画像与分层),并另立E2c-my(以本人等级为对象的可购买范围)。 - 新增出口:
E6行情 —— 走势是算出来的,不是某一句能检索到的;旧实现把它塞进检索,客户只能拿到静态快照(D3.9§2.3 三种实测形态)。 - 新增判定层:
L0表层判定(位置在安全路由之后、意图分类之前)—— 它只做路由判定、不产出事实;判不准就交回主路径(D3.9§3.1)。 - 判据迁移:「精确性」由分数阈值迁到实体锚点 + 证据结构;阈值只作安全下限(
D3.9§3.3—§3.4,含「分数区间重叠 ⇒ 单点阈值不存在」的实测)。
需要完整出口清单与实测时,直接看
D3.9;本件 §3 保留为决策原文(答辩时可讲「先定五出口、再按实测扩到七出口」这条演进线)。
3.1 出口 E1 澄清 —— 收益最大、成本最低
- 触发:
needs_clarification真正被消费(现在没有);低分但候选集中在同一族;缺主语(_search_query()已能识别_REFERRING_WORDS,但当前只是拼词,没有"问回去"这条路)。 - 形态:一次只问一个问题,并给候选让客户选—— 「您是问『南方季季盈90天』的费率,还是『南方稳健增利』的费率?」
- 上限:同一话题最多 2 次澄清,之后降级 E5b / E5c(否则变成审问)。
- 🔴 安全:澄清话术里出现的候选必须在该档位可见——澄清会新增一条泄露面(用"猜你要问哪个"侧信道暴露不可见条目的存在性)。必须写进不变量
INV-1。
3.2 出口 E2 计算型回答 —— "智能"最容易被感知的地方
- 把可计算的问题从知识库搬到计算层:申购费 / 赎回费递进 / 持有期 / 适当性裁决 / 风险等级查询。
- 模板已经存在:
_answer_suitability()就是"组合两个来源得结论"(产品风险等级 × 客户档案等级)。同一模式可以推广。 - 为什么重要:「买 10 万要交多少手续费」永远不可能是一份文档里的一句话,向量检索对它结构性失效;旧实现只能转人工。这类题在答辩现场被问到的概率很高。
- 安全:计算是纯函数 + 参数来源受控——费率取自档位内可见的 chunk,客户等级取自受控画像工具,不调模型、不自由发挥。
出口码细分(探针/评测用,E2 族)
| 码 | 含义 | 实测来源 |
|---|---|---|
E2a |
类别费率试算(给算法 + 区间,不给单一结论金额) | D-01/D-02/D-03 |
E2b |
单只产品赎回费(档位取自该产品自己那一块) | - |
E2c |
C—R 通用匹配规则(矩阵一格) |
D-04 |
E2d |
适当性裁决(产品风险等级 × 客户档案等级) | - |
🆕 E2e |
本人画像 / 客户分层作答(W7 新增) |
H-03 第二轮 |
🆕
E2e:问「我够哪一档」这类本人档案问题,答案只存在于customer_tier等画像字段里, 知识库结构性答不了 —— 走query_customer_profile取权威字段后不调模型直接作答, 因此与E2a—E2d同属"计算/权威参数位"族(W7实测:旧实现落E5b-suitability「给不出这个适当性结论」,属能答而不答)。
3.3 出口 E3 / E4 —— 知识直返 vs 证据约束生成
- E3(快路径):唯一命中且分数足够 → 原文直返。保持现在的确定性,省一次模型调用。
- E4:同族多块 / 组合问 → 调模型,但输入是一个「证据包」(若干 chunk + 各自 id),输出契约固定:
{ answer, used_chunk_ids[], confidence, unanswerable_reason }
- 硬约束(同时写进 prompt 和校验,不能只靠 prompt):
- 只能使用证据包内的事实与数字;
- 不得出现证据包外的任何数字;
- 不得出现推介 / 收益承诺 / 代客操作表述。
- 复用:
_chitchat()已经在用generate_with_model+load_active_prompt发布配置 —— 同一套机制,换一个 prompt code 即可,不是新架构。
3.4 出口 E5 分级回退
E5a澄清 →E5b部分答 + 引导(「您问的 X 我可以答:…;Y 需要人工核实:…」)→E5c转人工。- 🆕
W27口径更正(2026-09-21):FR-CS-008原文的「跨集合回退(阈值0.65)」作废 —— 实现侧从未存在该分支(FALLBACK_COLLECTIONS为死代码),且跨集合余弦分数量纲不可比(实测M-1100% → 91.3%)。回退不得跨集合、不得改判据;精确性由「实体锚点 + 证据结构」承担,阈值只作安全下限。详见D3.9§3.3—§3.5。 E5c必须带上下文摘要(客户问了什么 / 已试过哪些检索 / 为什么不足)。现在_guide_to_human(reason)只留一个内部reason字符串,客户看不到任何有用信息,人工也不知情。
4. 安全设计:不放松,反而更严
4.1 五条不变量(不可谈判)
| 编号 | 不变量 | 判据 |
|---|---|---|
| INV-1 | 档位不可越 | 任何回答的证据只能来自该档可见 chunk;澄清候选也不例外 |
| INV-2 | 无证据不生成事实 | 数字 / 费率 / 产品代码 / 人名必须可解析到 chunk id |
| INV-3 | 不推介、不承诺、不代办 | 「输出守护」+「工具层无写权限」双保险(合规三条红线见 D5.1) |
| INV-4 | 全程可审计 | 问题 / 证据 chunk id / 判定分支 / 生成文本 全部落库 |
| INV-5 | 失败方向 = 收敛 | 任何组件异常 → 降级到更小的能力集(澄清 / 引导),绝不放大权限 |
4.2 安全位置的重构(本方案最重要的一条)
| 维度 | 旧做法 | 新做法 |
|---|---|---|
| 判定对象 | 输出的字面(禁词表 + 裸正则) | 输入的意图 + 输出的数字与结论 |
| 挡不住 | 换个说法就绕过(「保本」→「不会亏吧」) | —— |
| 误杀 | 概念解释题("什么叫七日年化") | 无 |
| 失败方向 | 拒答(安全但呆) | 澄清 / 降级(安全且不呆) |
落地方式:ZERO_TOLERANCE_WORDS 拆成两层,判据是句式意图而非词面——
| 层 | 拦什么 | 例子 |
|---|---|---|
| 概念豁免层 | 名词解释请求 → 放行到知识出口 | 「什么叫七日年化」「年化收益率和七日年化有什么区别」 |
| 承诺拦截层 | 索取承诺 / 要求推介 / 要求代办 → 拦截 + 替代引导 | 「帮我找个保证年化 5% 以上的」「哪只不会亏」 |
4.3 允许直接转人工的 4 类场景(白名单;其余一律先走 E1—E4)
- P0 反诈(验证码 / 转账 / 盗号)—— 最高优先。
- P1 账户与个人数据(持仓 / 收益 / 订单 / 银行卡 / 投诉进度 / 风险测评结果)—— Agent 无权限读。
- P2 写操作与争议(代办交易 / 改资料 / 销户 / 投诉赔偿 / 法律争议)。
- 用户明确要求人工。
这 4 类只占客户问题的少数。旧实现里"意图未覆盖""置信度不足""未命中"这些能力问题也走转人工——那才是答辩老师说的"动不动就转人工"。
4.4 档位隔离:从"字段过滤"改为"物理隔离"
现设计靠 visibility 字段过滤,而 app\service\knowledge_search_service.py:138-154 是缺字段即放行(fail-open),且 tools\setup_milvus_knowledge_collections.py 建的集合根本没有 visibility 字段(两套 schema 撞同名集合)——见 D3.5 K-07。物理隔离(partition / 分集合)天然 fail-closed,且顺带让候选池变小、检索区分度提升(对 D3.5 §3-D 的判定策略有正收益)。
5. 要改的上游条款(只列差异,不写代码)
| 上游 | 改什么 |
|---|---|
D2.2 FR-CS-003(澄清) |
从「P0 未实现」升为出口 E1;补「澄清话术不得泄露不可见条目」约束 |
D2.2 FR-CS-008(跨集合回退) |
并入 E5 分级回退;补「跨集合回退不得跨档位」 |
D2.2 新增需求 |
建议新增 4 条:证据约束生成 / 计算型回答 / 澄清话术的档位安全 / 输出数字一致性校验。⚠️ 编号(FR-CS-049 起)是否可用需你确认 D2.2 当前最大编号 |
D2.4 检索 8 步 |
增加「同族合并」与「证据包」两个中间产物;档位过滤改为物理隔离 |
D2.1 批次 B / C |
增加 E1 / E2 / E4 三项任务;重定义转人工相关任务的触发条件(按 §4.3 白名单) |
D1.5 §7 / D1.6 §4.3 |
回填本方案 §9 的 8 项决策 |
6. 落地顺序(依赖在前,不写代码)
| 步 | 内容 | 为什么在这个位置 |
|---|---|---|
| S0 | 前提修复 K-01 / K-02 / K-03 / K-07(见 D3.5 §2) |
不修这些,后面全是在流沙上盖楼 |
| S1 | 出口 E1 澄清 + 「意图未覆盖」不再直接转人工 | 单点收益最大:立刻解掉一批"多问一句就能答"的题 |
| S2 | 出口 E2 计算型(复用 _answer_suitability 模板) |
解掉结构上检索不到的题 |
| S3 | 出口 E4 证据约束生成(复用闲聊生成链路 + 输出守护) | 智能的主要来源,也是风险最高的一步 |
| S4 | 档位物理隔离 + 安全判定分层(概念豁免 / 承诺拦截) | 把"更智能"和"更安全"同时落地 |
| S5 | 出口 E5 分级回退 + 转人工白名单 + 上下文摘要 | 收口 |
| S6 | 评测门禁(金标集 + §7 指标) | 没有它无法证明"更智能",也无法防回归 |
7. 可证伪验收
| 指标 | 现状 | 目标 |
|---|---|---|
| Top1 命中率 | 未测 | ≥ 85%(金标集 30—50 条) |
| 「r1 到 r5 分别代表什么」 | 转人工(gap 0.021) |
E3 / E4 作答 |
| 「高净值客户有什么权益」 | 转人工(gap 0.0075,同族打平) |
E4 合并作答 |
| 「什么叫七日年化」 | 合规拒答 | 概念豁免层放行 → E3 作答 |
| 转人工触发次数 | 10 条通路 | 仅 §4.3 白名单 4 类 |
| 越权读取(档位) | 有口子(K-07 fail-open) |
0 |
| 生成文本中的无出处数字 | 不适用(不生成) | 0 |
| 引用可解析率 | 不适用 | 100% |
这 8 条都可证伪——答辩时可以现场演示,这是"更智能"最好的证明方式。
✅ 已落成可执行的金标集:上述 8 条已展开为 46 条金标 + 10 项指标 + 4 项零容忍,见
D3.7。首次跑评测须如实记录修复前基线(D3.7§6),"从 ≤56% 提升到 ≥85%"比单看终点更有说服力。
8. 代价与风险
| 风险 | 压法 | 代价 |
|---|---|---|
| 生成 → 幻觉 | INV-2 + 输出数字一致性校验 + 引用必须可解析。不能只写 prompt |
必须真做守护层(一项独立工作量) |
| 生成 → 合规 | INV-3 双保险(输出守护 + 工具层无写权限) |
需你为"允许模型组织语言"背书 |
| 澄清 → 信息泄露 | 澄清候选限制在档位内 → 写进 INV-1 |
澄清逻辑必须接收档位参数(现在调用链上没有传档位) |
| 延迟 / 成本 | E3 快路径不调模型;只有 E2 / E4 调 | 需要分流策略,否则每次问答都调模型 |
| 评测缺失 | 金标集 | 🔴 需要你出题(这是本方案里唯一我做不了的) |
| 范围扩散 | 本方案会让 D2.2 / D2.4 / D2.1 三份都变 |
工作量集中在批次 B / C |
9. 决策裁定(2026-09-17 已拍板)
| # | 决策 | 裁定 | 落地口径 |
|---|---|---|---|
| DEC-I1 | 出口从 2 个扩到 5 个 | ✅ 已采纳 | 按 §3 实施 E1—E5 |
| DEC-I2 | 允许证据约束生成 | ✅ 已采纳 | 按 §3.3 实施;INV-2 / INV-3 与输出守护同批交付——不得只写 prompt |
| DEC-I3 | 做计算型回答 | ✅ 已采纳 | 按 §3.2 实施;复用 _answer_suitability() 模板 |
| DEC-I4 | 澄清策略 | ✅ 已定 | 先判断再答:同族并列 → 合并作答(E4),不澄清;跨族并列 / 缺主语 / 低分 → 澄清(E1);同一话题上限 2 次,超限降 E5b |
| DEC-I5 | 转人工白名单 | ✅ 已采纳 | 就按 §4.3 的 4 类;白名单外落转人工一律判不合格(见 D3.7 §5,M-6 ≤ 15%) |
| DEC-I6 | 档位物理隔离方式 | ✅ 已定 | 保留 3 个内容集合,集合内按可见性建 partition,检索时传 partition_names 白名单;缺省只查 public(fail-closed)。理由见 §9.2 |
| DEC-I7 | 金标评测集由谁出 | ✅ 已定:由 AI 产出 | 见 D3.7(46 条 / 10 项指标 / 4 项零容忍 / 前置阻塞 4 项)。已参考公开评测规范(ragas 指标分类)与 Milvus 官方隔离语义,来源与局限见 D3.7 §7 |
| DEC-I8 | 计算型对访客档开放 | ✅ 已定:分项开放 | 见 §9.1 |
9.1 DEC-I8 评估结论:对访客档分项开放
用户意见为「可开放」。评估结论:同意开放,但必须分项——不能笼统地"开放计算型"。
| 计算能力 | 访客档 | 理由 |
|---|---|---|
| 公开产品的费用试算(申购费 / 赎回费 / 持有期) | ✅ 开放 | ① 费率本身是公开披露信息,计算不产生新信息、不构成越权;② 「买 10 万要交多少」是访客最高频疑问之一,关掉它等于把"不智能"留在最显眼的地方;③ 体验收益远大于风险 |
风险等级 R1—R5 的定义解释 |
✅ 开放 | 属概念解释,D6.1.2 §四「概念 ≠ 参数」已定其为 public |
C—R 匹配规则的"一般性"说明("C1 只能买 R1、R2") |
✅ 开放 | 属通用规则,D6.1.2 §四 明文保持 public |
| 以访客自身为对象的适当性结论("我适合买这个吗") | ❌ 不开放 | 需要客户画像与风险测评结果 = 个人数据(P1),Agent 无权限读 → 走 E5b 引导登录 |
| 以访客自身资产为参数的试算 | ❌ 不开放 | 同上:参数来源不可得 |
🔴 开放的三个前置条件(不可省略):
- 参数来源必须档位感知——访客档的费率参数只能取自
public分区的参数位;取不到就降级,不得回退到registered分区(INV-1/INV-5)。- 输出只给算法与区间,不给"最终应收 X 元"式的确定结论(未指定具体产品时)。此条已写进
D3.7的D-01判据。D6.2.1§六 费率说明须补一个public参数位(费率区间的公开部分)。否则访客档无参数可用,DEC-I8会空转成一句"请登录查看"。
9.2 DEC-I6 为什么选 partition 而不是 9 个集合
- 现有 3 个内容集合(
fin_faq/fin_product/fin_policy)× 3 档 = 9 个集合:运维与迁移成本翻三倍,且D2.4的三集合结构要整体重写。 - 改为集合内 partition:集合名不变、
D2.4结构不变,只在检索入口把「可查 partition 列表」变成显式参数;缺省["public"]= 失败方向收敛。 - Milvus 官方文档对这一用法(Partition Key Isolation,多租户隔离)与「partition key 字段值不允许为空或 null」有明文——后者正好从写入侧堵住"缺字段即放行"(
D3.5K-07)。来源见D3.7§7。 - ⚠️ 落地时必须同时删掉两套 schema 中的一套(
tools\setup_milvus_knowledge_collections.py无visibilityvstools\load_knowledge_milvus.py有)——即D3.7的B-4;否则 partition 建在哪个 schema 上不可预期,评测结果不可复现。
维护责任:本文件为建议件,随上游修订同步更新。任何一项落地后,须在本表标注「已采纳 / 已否决 + 日期」,并回填
D1.5§7 与D1.6§4.3。编制:项目文档组 | 审核:合规稽核部 | 日期:2026-09-17
版本:v1.2(2026-09-21)—— 同步
D3.9:架构图补L0表层判定层与出口E6;E5口径更正(跨集合回退作废)。