lzf_0626
d2aff7c129
一、知识库建设 - 新增 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/ 内含公司内部制度与产品资料， 是否入远程库待确认。
20 lines
2.5 KiB
Plaintext
20 lines
2.5 KiB
Plaintext
场外申购赎回单的确认核对
|
|
传统业务流程：场外不同代销机构申购/赎回单 → 中国结算 → 运营人员（提取申购/赎回金额，基金代码等关键字，判断是否有：单一投资者申购后持有比例超过阈值；单日投资者申购金额超过上限；触发巨额赎回；金额日期不符合格式；赎回份额大于可份额；涉嫌反洗钱；汇总申购赎回规模通知资金清算岗） → 内部风控 →运营人员 → 中国结算。
|
|
Agent功能：自动检测申购赎回单、解析申购赎回扫描件关键字段（异常数据标记和规则格式清洗）、智能对比实际情况进行风险提醒、智能回复风控和中国结算（需要人在回路确认）、标准化输出申购赎回整合数据
|
|
具体流程图：中国结算发送不同申购/赎回单给运营邮箱（LLM自动提取邮箱有关中国结算邮件） → LLM自动解析各类文件（进行关键字段提取，并做格式校验） → LLM自动把关键字段与公司实际产品进行对比（自动标注异常数据和字段格式） → 运营人在回路进行NL2SQL进行确认（确认完成的进行产品申购赎回汇总数据统计） → 是否上报风控（异常数据） → 是否需要把汇总数据给资金清算岗（确认申购和赎回的） → 返回申购/赎回单给中国结算。
|
|
核对字段：
|
|
申购：
|
|
申购后单一持有份额比例是否超过基金总份额规定上限；（产品表）
|
|
申购金额是否超过产品单日上限金额；（产品表）
|
|
检查金额格式；（小数点两位，金额格式为：人民币 万元）
|
|
日期格式字段；（年月日）
|
|
赎回：
|
|
是否巨额赎回；（产品表）
|
|
赎回金额是否大于该账户可用金额，申购金额是否大于最低申购金额；（个人账户表）
|
|
通用：
|
|
日期是否在开放期；（产品表）
|
|
根据申购金额和用户画像判断，是否涉嫌反洗钱；（用户画像表）
|
|
待工作：不同的申购赎回单子，以作实际操作案例。
|
|
新成立产品推介材料的自动生成
|
|
传统业务流程：收集基金经理头像照、制作基金经理最新的历史业绩表、整理产品的基本信息、整理管理人及团队信息，然后给专业的人员进行制作推介材料。
|
|
Agent功能：把新产品的基本信息，最新基金经理业绩给Agent后，Agent自动根据公司内部的风格一键生成实时的推介材料 → 推介资料保存到本地的同时发送给投顾端 |