 张胜宇
|
dd5e9f8435
|
fix(W21): 智能度体检 → 3 类真实缺陷修复（C-8/C-9/C-10）+ 1 类待裁登记（C-11）
甲方反馈「客服 agent 还是不太智能」。本轮不新增出口、不改需求，
把"不智能"拆成可复现的实测条目：81 条真实口语问法 + 8 组多轮追问链
（真 HTTP：API → 队列 → Worker → 治理层），逐条定位根因并修复。
已修复（每条都有真机 HTML 证据，见 开发文档/D4.8 §3）
- C-8 账户盈亏问法落"误导性澄清"
「我的基金赚了多少钱」→ E1 澄清，三个候选（万份收益/起投金额/收益率差别）
全是公开知识，而客户问的是自己账户的盈亏金额。
修法：P1_PATTERNS 补「第一人称 + 盈亏动词 + 金额疑问词」骨架，
金额疑问词是必要条件 —— 「我买的基金亏了怎么办」照旧走知识检索（库里有解）。
- C-9 多轮指代断链，把"已经说过的"又问一遍
「我想买个债基」→「它适合我吗」落 E2d「请告诉我具体的基金名称或代码」，
而客户刚刚才被告知是那只产品；「赎回费怎么算」→「持有 8 个月呢」同因。
两个根因：① _topic_of 只在答复前 4 行的固定形状里取主语，FAQ 型答复
（首行「问：…」）反解为空；② 意图分类把短追问标成 suitability_check，
绕开了知识出口里已做好的追问继承逻辑。
修法：_answer_suitability 建成四级降级链（严格主语 → 形状反解
_product_name_in_history → 有上文交回检索 → 首轮才澄清）+ 纯参数追问前置闸门。
安全边界三条不放宽：不给访客"能不能买"结论；推测出的名字查不到风险等级时
回落检索而非回"给不出结论"；首轮指代保留澄清（金标 E-01 口径）。
- C-10 「你们投诉电话是多少」被强制转人工
根因：P2_WRITE_DISPUTE_KEYWORDS 里的裸词「投诉」子串命中，把"问投诉渠道"
和"提交投诉"撞在同一判据上；而答案就在库里（POL-SPM-036-01 / FAQ-0054）。
修法：新增 _is_p2_contact_inquiry() 作为第二类 P2 豁免（渠道词 + 疑问词，
且不带明确投诉意图）。「我要投诉，让你们经理来找我」照旧建单。
定位但未修（需甲方裁定合规口径）
- C-11 E4 证据约束生成的答复被"收益数值"闸门整条拦回 E5b
「南方现金添利怎么样」(top1 1.0000) / 「买基金要手续费吗」(0.7328) /
「债基和货基哪个收益高」(0.5457) 三条同因：生成稿出现 YIELD_METRIC_TERMS
→ hits_zero_tolerance → _exit_partial → E5b 兜底。
试过"先净化再判合规"，实测更差（drop_yield_claims 整行丢弃 + 生成稿常是
单行长段 ⇒ 整条被删空），已回退并把原因写进代码注释留痕。
建议方案：改 E4 提示词禁止输出收益数值（源头消除，不动红线代码）。
待判物
- _chunks_report.txt 判定可删：无代码引用 / 内容可从 knowledge/_chunks.jsonl
复算 / 从未入库 / 统计口径已写进 D2.4 §6 与 D2.8 §2。已删 + 加 .gitignore。
验收
- 金标 46 条：M-1 46/46、M-4 46/46、M-6 5/46（白名单 F-05/G-01/G-03/G-04/G-05，
零越界）、M-7/M-8/M-9/M-10 = 0、M-2 28/31、M-2b 15/18、M-3 4/4
—— 与 W20 基线逐项一致，零回归。
- 全量回归 1985 passed / 3 skipped（W20 基线 1969 passed / 3 skipped）。
- 新增守卫单测 16 条（含 C-8 两条 / C-9 四条 / C-10 两条）。
- ruff 仅剩 4 条既有告警，未顺手改，避免混入无关 diff。
文档
- 新增 开发文档/D4.8-客服Agent智能度体检与整改报告-W21-2026-09-21.md
- 客服agent/D2.1 升 v6.37；开发文档/D1.1 升 v1.13；D1.6 增 §9 上下文提取
|
2026-09-21 10:55:16 +08:00 |
|
|
张胜宇
|
5d0becb67d
|
客服 Agent 重构收口：五出口决策链 + 知识库档位隔离 + 前端入参边界（答辩演示版本）
一、客服 Agent 智能增强（正面回应"不智能、动不动就转人工"）
- 决策链由 2 个出口扩到 5 个：E1 澄清 / E2 计算型 / E3 知识直返 / E4 证据约束生成 / E5 分级回退
- 转人工从"默认动作"降为最后一档 E5c，只保留 4 类白名单：
P0 反诈 / P1 账户与个人数据 / P2 写操作与争议 / 用户明确要求人工
- 46 条金标实测（修复前 → 修复后）：
转人工率 43.5% → 10.9%；出口准确率 45.7% → 100%；事实正确率 69.6% → 100%
禁忌违反 1 → 0；档位越权 / 无出处数字 / 误拒 四项零容忍全 0
- 安全不变量 INV-1~INV-5；零容忍规则未删，改的是挂载点
（输出侧字面黑名单 → 检索层档位隔离 + 判定层合规词表 + 输出守护）
二、知识库：档位单点化与物理隔离
- 新增 app/core/knowledge_tier.py 作为档位规则唯一落点（G-03），
knowledge_contracts.py 原定义块改为显式再导出（X as X，非副本）
- 档位过滤由 bool 默认值（fail-open）改为 tiers 必填集合（缺参即 TypeError）
- Milvus 侧四集合按 visibility 分区键物理隔离；双 schema 收敛为一套
- 新增 app/core/actor.py：访客三元组与匿名判定的唯一构造/判定点（G-01/G-01b）
- 新增 app/core/fund_fee_rules.py：费率计算纯函数
三、前端入参边界对齐（本轮 W11 新修，4 处"校验宽于存储"）
- message 加 max_length=8000（与浮窗 widget.js 的 maxlength 一致）
- session_id 加 1—64；idempotency_key 上限 128 → 64（对齐列宽 String(64)）
- feedback_type 加 max_length=32（对齐列宽 String(32)）
- 8 条路径参数补 min_length=1 + max_length=64 + 字符集正则
（{session_id} / {run_id} / {handover_id}）
- 改前超限值会落到 MySQL 才失败（500）；改后一律 422 AGENT_INPUT_INVALID + 字段级定位
- 新增 tests/unit/api/test_frontend_boundaries.py（33 例），含"端点表 ↔ OpenAPI 全量对照"
四、投顾模块整体清除（D4.4 / D4.5）
- 删除投顾相关 controller / schema / model / repository / service 及门户页面
- tools/portal_api_check.py 同步作废 AD003/AD005/AD011/A047 四条用例与 advisor_t 登录
（端点与账号均已不存在，此前稳定报 3 条假红）
五、验证（提交前实测）
- pytest -q：1856 passed / 2 skipped / 0 failed
- ruff check app tools tests：19（= 基线）；mypy app：2（= 基线）
- 前端接口契约体检 portal_api_check.py：38 项，通过 34，失败 0，跳过 4
- 全链路冒烟 e2e_smoke_test.py --read-only：31/31
- HTTP 全链路探针 http_probe.py：11/11 succeeded
- 跨文档一致性 _consistency.py：GATE PASS
- 真机边界复验 12 条：12/12 符合预期
六、纪律与文档
- 可改文件白名单 A-09（docs/46）与底座会签申请单 A-10（docs/47，组 1—组 4 全部受理）
- 零 DDL：未新增/修改任何表结构，89 张业务表与基线一致
- 证据留痕：docs/evidence/**（含 46 条金标 score、快照、清除与重建记录）
- 未提交（刻意排除，见提交说明）：仓库内 客服agent/ 与 开发文档/ 是 2026-09-16 前的
过期副本（Todolist 440 行 vs 权威 D2.1 1167 行），权威正本在仓库外；
_chunks_report.txt 是 tools/build_knowledge_chunks.py 生成的本地产物
|
2026-09-20 14:33:30 +08:00 |
|
 lzf_0626
|
d2aff7c129
|
feat: 建客服知识库（Milvus 三集合）并修复模型端点筛选缺陷
一、知识库建设
- 新增 tools/build_knowledge_chunks.py：把 knowledge/ 下文档切成可检索知识块。
采用「叶子标题」策略（其后没有更深标题的标题即切分点），同时覆盖三种真实结构：
带子条款的按子条款切、无子条款的条款单独成块、无小节的章整章成块。
第一版按固定标题级别切是失败的——适当性指南的条款是 ### 而没有 ####，产品手册的
### 1.1 又不匹配「第X条」，两条规则互相打架，导致 4 个文件一块都没切出来。
- 新增 tools/load_knowledge_milvus.py：向量化并写入 Milvus，用 upsert 保证幂等。
schema 按方案 §4.2 统一字段，另加 chapter/section/source_file/doc_no/visibility 五个
检索与合规必需字段；索引 IVF_FLAT + COSINE + nlist=128；向量输入取「标题+正文」，
标题含条款号与章节名，是比正文更干净的检索信号。
- 知识内容按业务范围裁剪：反洗钱合规操作手册不入客服知识库（业务只做公募基金、
不涉及资金划付，且该手册标注内部机密、禁止向客户透露可疑交易信息），留给后续风控；
高净值客户服务规范只保留「客户分层标准」与「各层级专属权益」两章，
家族信托、资产配置流程、客户经理考核、隐私应急预案等内部管理章节不入库。
- 入库现状：fin_faq_collection 61 块、fin_product_collection 26 块、
fin_policy_collection 73 块，合计 160 块。检索自检 5/6——未命中的一条分数 0.660
落在中置信区间，按三档兜底策略本应提示信息可能不完整，属于预期行为。
二、embedding 端点
- 新增 tools/configure_embedding_endpoint.py：走管理 API（draft→approved→active）
配置并激活 qwen-embedding 端点，而不是直接写库。理由是状态机与审计都要留痕，
且 DatabaseModelGateway 只认 status='active'，手工写错状态会报成与病因无关的
「模型端点未注册或未激活」。脚本先查 endpoint_code 是否已存在，幂等可重跑。
三、修复模型端点筛选缺陷（app/service/model_gateway.py）
- 原 DatabaseModelEndpointResolver 忽略 agent_type 与 task_type、直接返回全部 active
端点，而 ModelDispatchService 只按顺序尝试前 max_attempts（默认 2）个。两者叠加使
「能否选到支持该任务的端点」取决于端点表顺序：实测每次 embedding 都先拿文本生成
端点失败一次再落到向量端点（0.61s，修复后 0.42s）。
- 新增 TASK_CAPABILITY 显式映射后按能力筛选。用映射而不是同名筛选是必需的：
memory_extraction 并不是任何端点的能力名（deepseek 声明的是 text_generation 等），
按同名筛会得到空集、把记忆抽取打成失败关闭——这是本次修复最容易引入的回归。
- 保守兜底：未映射的 task_type、以及没有任何端点声明该能力时，都退回全部端点，
让配置缺口表现为调用失败，而不是让上层收到「解析为空」这种与病因无关的报错。
- 验证结果：embedding→[qwen-embedding]、intent_classification→[deepseek-flash]、
memory_extraction→[deepseek-flash]、未映射 task_type→全部；ruff 通过、
mypy 103 文件无错、unit+contract 447 passed。
四、需求文档提取物
- 新增 _flows/：三份流程文档（智能客服 Agent 专项设计方案、投资顾问流程、基金运营流程）
的纯文本提取，供开发期对照。原始 .docx/.html 保留在业务方目录侧。
说明：本次仅本地提交，未推送远程仓库。knowledge/ 内含公司内部制度与产品资料，
是否入远程库待确认。
|
2026-09-10 20:15:09 +08:00 |
|