2 Commits

Include renames

Author	SHA1	Message	Date
lzf_0626	66595ce080	fix: 客服置信判定改为「绝对阈值 + 相对间隙」混合判定 ... 问题（业务方实测发现）：问「我们公司叫什么名字」被引导人工，但公司名称就在知识库里 ——FAQ-0001「公司全称是什么?」与 COMP-001 都稳定命中 top1。所以根因不是检索不准， 而是判定规则不完整：客服方案 §2.3 要求的是「绝对阈值 AND（相对间隙 OR 分布优势）」， 实现里只做了绝对阈值 0.60。 实测校准（qwen3.7-text-embedding-flash，COSINE）： 库内问法 top1 top1-top2 我们公司叫什么名字 0.592 0.100 你们公司名称是什么 0.579 0.090 公司全称是什么 0.671 0.098 你们公司总部在哪 0.764 0.245 南方科技的全称 0.855 — 库外 / 越界 top1 top1-top2 你们公司什么时候上市 0.500 0.046 推荐明天肯定涨的基金 0.488 0.023 我要投诉 0.492 0.025 今天天气怎么样 0.416 0.035 量子计算机退相干 0.416 0.044 两条结论：一是同为正确命中，口语问法的相似度天然偏低（0.592 vs 0.855），单用绝对阈值 必然误判；二是库内命中的 top1 领先幅度（≥0.09）显著大于库外（≤0.046），间隙是有效判别信号。 新规则：≥0.75 直接答（不再要求间隙）；≥0.55 且间隙 ≥0.07 则回答并附「信息可能不完整」 提示；其余一律引导客户致电人工客服。两侧余量：库内最低 0.579、库外最高 0.500。 验证：ruff 通过、mypy 107 文件无错；ask_customer_service 对「我们公司叫什么名字」 正确返回南方科技有限公司；customer_service_check 由 8 项扩为 9 项，全部通过， 其中「推荐明天肯定涨的基金 / 我要投诉 / 量子计算机退相干」三条必须引导人工的用例 未被放宽后的阈值误答。	2026-09-10 20:29:12 +08:00
lzf_0626	13bab7c3d0	feat: 客服 Agent 端到端跑通（知识直返 + 答不了引导人工客服） ... 按业务方确定的取向实现：金融场景确定性优先，能溯源到公司资料的才答，答不了就 引导客户拨打客服热线，绝不用模型猜答案。端到端验收 8/8 通过。 新增： - app/service/knowledge_search_service.py：知识检索。未复用记忆的 VectorMemoryAdapter 是因为它只返回 (memory_uuid, score)，会丢掉知识块的标题与正文，而客服回答必须能把 原文与出处一起交付。检索失败一律返回 degraded 而不抛异常，由 Agent 走兜底。 - app/service/knowledge_tool.py + app/core/knowledge_contracts.py：只读工具 search_knowledge。 走 ToolExecutor 而不是让 Agent 直接持有检索服务，是为了让白名单、权限、审计、超时 都归基座统一管理；工具只读也符合 ToolRegistry 的硬约束。复用既有权限码 knowledge:reference:read（customer 角色已具备），不新增权限点。 - app/service/agent/implementations/customer_service.py：Agent 本体，刻意保持薄—— 意图分发 + 四条出口（faq/产品/政策直返、闲聊走模型、其余与异常引导人工）。 直接返回知识原文而不经模型改写，答案的字面内容全部来自公司已发布资料。 - tools/publish_customer_service_config.py：发布意图工具白名单。 - tools/customer_service_check.py：端到端验收（8 个用例，含越界请求与知识库外问题）。 装配： - bootstrap 新增 get_knowledge_search_service 工厂，注册 search_knowledge 工具与 customer_service Agent。 - runtime_config_service 新增 load_active_prompt：提示词绑定 release_id，按当前生效 版本读取，未发布时回落代码默认值。闲聊话术因此可审核、可回滚，不必改代码发版。 过程中发现并处理的三个问题： 1. 自造 source_references 被基座合规闸门拒绝。governance.review_output 只接受 「本次召回的记忆」与「本次成功调用的工具」两类引用（用于防止伪造来源）， knowledge 类型会被判非法并使整个 run 失败。处理方式是**不放开那道校验**， 而把知识出处（文件标题与内部编号）写进正文，source_references 交给基座自动附加。 2. 发布配置是整版本替换语义：新版本会清空旧版本的全部配置项。若只发客服白名单， 示例 Agent 的 fund_query_demo:fund_quote 会被静默清空。故发布脚本先读取当前生效 版本的全部配置项并原样继承，再追加新增项。 3. 验收脚本自身两处自伤：打印 emoji 触发 GBK UnicodeEncodeError、以及读错结果字段 （RunQueryService 返回的答案键是 content 不是 text）。 已知缺口（未修，已记录）： - CoreResult.transfer_required 未持久化：conversation_message 不存该标记， API 读不到"本次是否引导了人工"。当前靠正文里的固定话术判断。 - 知识块引用（source_type=knowledge）尚未启用，需先让 ToolExecutor 把工具返回的 doc_id 登记为本次可引用来源。 验证：ruff 通过、mypy 107 文件无错、unit+contract 447 passed； tools/customer_service_check.py 8/8 通过（含越界请求、投诉、知识库外问题三类 必须引导人工的场景，以及 7 个零容忍负面词零命中）。	2026-09-10 20:22:42 +08:00