客户经理版信贷 FAQ Bot
面向一线客户经理的智能知识助手，聚焦「产品政策查询 / 申请资料清单 / 后台审批流程」三大高频场景，四轮迭代优化使回答准确率提升至82%
一、项目背景
银行零售信贷业务涵盖抵押经营贷、消费贷、信用经营贷等多条产品线，产品政策复杂、利率额度频繁更新。一线客户经理在面对客户咨询、做方案、做进件时，往往面临以下困扰：
1. 政策记不住：不同产品的当前利率、额度规则、进件条件经常调整，总行分行单独政策又易混淆，对客报价心里没底。
2. 资料清单散落：消费贷要哪些材料、抵押经营贷要哪些材料、信用经营贷要哪些材料，分散在多个文档/聊天记录里，且每次更新迭代仅做部分资料更新，新人上手容易找不齐资料、老员工也需反复确认资料是否为最新版本。
3. 进件流程不熟：一笔贷款从客户申请到放款，要经过哪些系统（如个贷系统、抵质押系统等）、哪些环节（面签、审批、抵押、出账）、哪些领导/同事审批，新客户经理做进件时心里没谱，单一业务问题往往需横向沟通多个节点同事才能闭环，跨部门沟通成本极高。
4. 产品经理沟通瓶颈：当前流程答疑过度依赖产品经理，而单名产品经理需对接上百名业务人员，服务严重过载，难以满足业务响应时效。
基于以上痛点，我总结了我的业务经验与行内政策，搭建了面向客户经理的 FAQ Bot，目标不是替代客户经理回答客户问题，而是成为客户经理的「口袋知识助手」——遇到政策、资料、流程问题时，极大降低了政策与流程的检索成本，变‘费时找答案’为‘秒级获答案’，辅助客户经理快速扫清知识盲区，回归服务本位。
二、迭代成果
经过三轮迭代优化，Bot 在质量、速度、成本三个维度均取得显著提升：
| 指标 | 优化前（v1） | 优化后（v3） | 变化幅度 |
|---|---|---|---|
| 响应延迟（ms） | 15,031 | 3,729 | -75% ↓ |
| Token 消耗 | 1,562 | 1,110 | -29% ↓ |
三、知识库设计
3.1 知识库三大类目（按客户经理查询场景组织）
不同于 ToC 场景的「用户问什么答什么」，ToB 客户经理的知识库要按「客户经理的工作场景」来组织，每个类目对应客户经理的一个具体动作：
3.2 RAG 全链路架构
RAG（检索增强生成）分为离线阶段和在线阶段两个部分：
当前架构未引入Rerank模块，v4规划中考虑在召回后追加Rerank提升相关性，属于未实现项——此为认知迭代而非交付实绩。
3.3 关键参数调优
| 参数 | 优化前（v1） | 优化后（v4） | 说明 |
|---|---|---|---|
| TopK | 5 | 3 | 减少噪声召回，避免「政策A和政策B利率串答」 |
| 相似度阈值 | 未设置 | 0.7（建议） | 高于0.7才召回，过滤无关片段 |
| 分块大小 | 默认 | 500字 | 保证一个完整的「政策/资料/流程节点」单元不被切断 |
| 重叠比例 | 默认 | 20% | 防止跨章节的关键信息丢失 |
参数决策过程：
- TopK选择：v1取TopK=5时出现跨产品串答（如问消费贷利率召回到抵押经营贷文档），做了TopK=3/5/7对比测试后选TopK=3（无关文档干扰减少且召回覆盖率仍达标）
- 分块策略：500字/块+20%重叠。500字是基于行内政策/资料条目平均长度（约400-600字）确定的，保证一个完整业务单元不被切断；20%重叠防止跨章节关键信息丢失
- 相似度阈值：阈值0.7是在评测集上做ROC校准后选的，平衡召回率与准确率
模型选型：
生成模型选择Qwen-32B-Instruct，选型理由：
- ①在推理速度与效果之间平衡——比7B/14B模型语义理解更精准，比72B模型推理更快、成本更低
- ②中文政策文本语义理解能力强，对金融场景的政策术语、合规表述理解准确
- ③支持128K长上下文，适合知识库检索后多文档拼接的生成场景
五、迭代优化：从v1到v3的三轮复盘
整个优化过程遵循"发现问题 → 定位根因 → 优化策略 → 量化验证 → 再发现新问题"的迭代飞轮模式。下面三轮迭代均围绕客户经理的真实工作场景展开。
5.1 评测机制
5.1.1 评测集构建方法：
从客户经理真实问题日志中选取40条+人工补充10条边界case，共50条。
覆盖场景分布：政策查询20条/资料清单5条/流程节点15条/方案判断10条。
5.1.2 评分标准（100分制）：
内容准确40分（引用政策正确/版本最新/无跨产品串答）
资料完整40分（清单无缺项/流程节点齐全）
拒绝合理20分（非业务问题能否礼貌拒绝而非胡说）
5.1.3 评测流程与局限：
评测流程采用"工具评分+人工复核"双层机制：先由平台评估器对回答做自动评分，再逐条人工复核并做评分纠正——纠正评估器对边界case的误判。
局限说明：
①评估器本身存在算法偏差，人工纠正虽能弥补部分误差，但引入了个人主观判断的偏差；
②评测集仅50条，覆盖面有限，未做交叉验证；
③v4规划引入双人评分+一致性检验提升可信度。
5.2 第1轮迭代：政策版本混淆 + 资料版本过期
发现的问题：
- 客户经理问「消费贷现在利率多少」，Bot 把 v1/v2 旧版利率当新版答，对客报价偏差
- 手工测试20条，约15%（3条）的回答引用了知识库外数据或过期版本
优化策略：
- 新增「政策版本声明」规则：每条政策回答必须标注「政策生效日期+版本号」，优先返回最新生效日期政策
- 知识库 TopK：5 → 3，减少跨产品利率串答
5.3 第2轮迭代：资料清单缺项 / 流程节点串答
发现的问题：客户经理问「抵押经营贷要哪些资料」，Bot 把按揭贷款的资料清单也答进去了，或者有时只引用了部分资料未全部引用。退回率上升。
优化策略：新增「产品强绑定」规则——资料清单、流程节点必须与产品一一对应，禁止跨产品串答；每个回答末尾附「资料清单来自《XX产品进件指引v2.3》」溯源标签。
5.4 第3轮迭代：意图识别架构重建
发现的问题：评测集 100 条中约 32% 出现意图错判。例如「如何注销客户抵押」本是流程类问题，被当作产品咨询回复了抵押易业务流程。
优化策略：三路意图分层（按客户经理工作动作分）
| 路径 | 触发场景 | 处理逻辑 |
|---|---|---|
| 路径A · 政策查询 | 「利率/额度/准入/期限」类问题 | 直接给出当前最新生效政策 + 版本号 + 生效日期 |
| 路径B · 资料 / 流程查询 | 「要哪些材料/找谁批/走什么系统」 | 按产品强绑定清单 / 流程节点回答，附节点负责人和系统 |
| 路径C · 方案判断 / 边缘情况 | 「能不能批/要不要上会/这单怎么办」 | 通过追问引导客户经理补全关键变量后再判断，不直接给结论 |
5.5 Prompt演进
| 版本 | 核心改动 | 评测分数 | 延迟(ms) |
|---|---|---|---|
| v1（基线） | 基础Prompt + 政策/资料/流程三大知识库接入 | 48 | 15,031 |
| v2 | 政策版本声明 + TopK优化 + 资料版本溯源 | ~56 | — |
| v3 | 产品强绑定规则：资料/流程禁止跨产品串答 | 82 | 3,729 |
5.6 错误类型分析
通过对评测集错题的归类分析，主要错误类型（按客户经理使用场景归类）：
| 错误类型 | 占比 | 典型表现 | 优化方向 |
|---|---|---|---|
| 政策版本混淆 | ~15%（v1） | 把 v1/v2 旧版利率当新版答，对客报价偏差 | 政策版本声明 + 政策生效日期标注 |
| 资料/流程跨产品串答 | ~18%（v2前） | 抵押经营贷的资料清单混入消费贷条目 | 产品强绑定 + 资料清单溯源 |
| 意图错判 | ~32%（v3前） | 流程类问题被当作产品咨询，强行追问 | 三路意图分层（政策/资料流程/方案判断） |
| 模糊方案 | ~10%（v3） | 面对「办A还是办B」答「都可以」 | 跨产品方案比对模板 + 模糊表达禁用 |
六、项目复盘与反思
做得好的地方：
- 把 ToB 知识库按「客户经理工作动作」（政策查询/资料清单/流程节点）组织，而非「产品文档堆叠」
- 建立了量化评测体系（100条测试集），每轮迭代有据可依
- 采用迭代飞轮模式，逐步定位问题、逐步优化，避免一次性大改难以归因
- Prompt 优化从"规则堆砌"转向"架构分层"（三路意图），质量跃升明显
不足与改进方向：
- 政策更新机制未自动化，目前仍依赖人工更新知识库，v4 计划接入政策变更流自动触发更新
- TopK 从5改为3未配合相似度阈值做 A/B 对比，无法确认是否为最优组合
- 评测集以单轮问答为主，缺少「客户经理连续问 5 轮做一单」的多轮场景
- 尚未引入 Rerank 重排序，检索精度仍有提升空间
- v4 规划：政策自动同步 + 跨产品方案模板化 + 边缘 case 补充，目标 65 分