Install
openclaw skills install @gechengling/finance-knowledge-baseManages financial knowledge bases with document organization, knowledge graph, semantic search, and intelligent Q&A for internal financial institutions.
openclaw skills install @gechengling/finance-knowledge-base⚠️ SECURITY NOTICE / 安全声明
- Type: Educational reference / analytical framework ONLY
- Code snippets in this document are illustrative reference material — they show a structure you can adapt in your own environment. Nothing here is executed, and no scripts, binaries, or installers are bundled.
- No persistent storage, network calls, background execution, or credential collection
- All outputs are for reference only and require human review before real-world application
- This skill does NOT provide financial, legal, or insurance advice
- Users must exercise their own judgment and consult qualified professionals
English: AI-powered knowledge base manager — covers document organization, knowledge graph, and semantic search.
中文: 知识库管理器——覆盖文档组织、知识图谱、语义搜索、版本治理与智能问答。
| Pain Point / 痛点 | Impact / 影响 | 量化基线(示例口径) | Solution / 本Skill解决方案 | 常见误判 |
|---|---|---|---|---|
| 知识分散 | 文档散落各处,难找 | 平均查找一份制度耗时 10–20 分钟 | 统一知识库管理 | 以为换个检索工具就能解决 |
| 知识孤岛 | 部门间知识不共享 | 同一问题在三处重复起草 | 跨部门知识共享与唯一来源 | 把共享等同于建群传文件 |
| 更新滞后 | 制度更新后知识未同步 | 新旧版本并存,误用旧口径 | 知识版本管理与失效标记 | 只更新正文不标失效 |
| 检索不准 | 关键词搜索效果差 | 关键词命中但答非所问 | 语义搜索 + 重排 | 只调模型不调分块与权重 |
| 口径不一 | 同一指标多种解释 | 同一报表出现 2 套口径 | 指标口径登记与唯一来源 | 认为口径问题靠开会能解决 |
| 无人负责 | 知识无人维护 | 文档平均两年未复核 | 责任人 + 复核周期 | 指定了责任人但无复核触发机制 |
| 权限错配 | 可见范围与岗位不匹配 | 敏感内容对全员可见 | 按岗位设定可见范围 | 只在事后补救而非入库前拦截 |
| 来源不可溯 | 答案无法定位原文 | 引用无法复现 | 强制附出处与版本 | 把出处当作可选项 |
Scope(适用范围): 金融机构内部知识管理的设计与治理工作——分类分层设计、指标口径登记、检索效果评估、版本与生命周期治理、问答质量抽检。
English Triggers(须落在知识管理设计任务上):
English Non-Triggers(不触发):
中文触发词(须落在知识管理设计任务上才触发):
中文不触发清单:
路由判定三步:
使用示例(完整提问):
触发边界:本技能面向金融机构内部知识管理场景(制度、产品、流程、口径类知识)。通用笔记整理、个人待办、日程安排等不属于本技能范围。
# 示例:知识分类骨架(供参考,可按机构实际调整)
KNOWLEDGE_STRUCTURE = {
"regulations": {
"banking": ["监管法规", "合规要求", "检查清单"],
"insurance": ["监管法规", "产品规则", "偿付能力"],
"securities": ["证监会规则", "交易所规则", "自律规则"]
},
"products": {
"banking": ["存款产品", "贷款产品", "理财", "信用卡"],
"insurance": ["寿险", "财险", "健康险", "团险"],
"securities": ["股票", "债券", "基金", "期权"]
},
"processes": {
"操作规程": ["受理", "审批", "复核", "归档"],
"风险控制": ["识别", "计量", "监测", "报告"],
"客户服务": ["咨询", "办理", "投诉", "回访"]
},
"metrics": {
"口径登记": ["指标名", "计算公式", "数据来源", "责任人"]
}
}
知识分层与责任人对照表
| 层级 | 内容示例 | 更新频率 | 责任人 | 未更新后果 | 入库门槛 |
|---|---|---|---|---|---|
| 一级:监管依据 | 法律、部门规章、监管通知 | 随发布更新 | 合规条线 | 合规风险 | 必须有发布文号与生效日期 |
| 二级:内部制度 | 管理办法、操作规程 | 按修订 | 制度牵头部门 | 执行口径混乱 | 必须有正式版本号与生效日期 |
| 三级:业务知识 | 产品说明、话术要点 | 按产品变更 | 业务条线 | 对外表述不一致 | 必须能追溯到二级制度 |
| 四级:口径与指标 | 指标定义、取数规则 | 按季度复核 | 数据条线 | 报表口径打架 | 必须有公式与数据来源 |
| 五级:经验沉淀 | 案例、常见问题 | 持续补充 | 各条线 | 重复踩坑 | 必须标注不具约束力 |
归类示例(一批混装文件):
| 原始文件 | 归入层级 | 责任人建议 | 处置 |
|---|---|---|---|
| 《关于 X 业务的通知》(监管部门发布) | 一级:监管依据 | 合规条线 | 随发布更新,登记生效日期 |
| 《X 业务管理办法(2026 修订)》 | 二级:内部制度 | 制度牵头部门 | 替代 2024 版,旧版标失效 |
| 《X 产品销售话术要点》 | 三级:业务知识 | 业务条线 | 按产品变更同步 |
| 《X 指标计算说明》 | 四级:口径与指标 | 数据条线 | 入口径登记,与报表引用关联 |
| 《X 业务常见问题 20 问》 | 五级:经验沉淀 | 各条线 | 持续补充,不设强制复核 |
归类时的两个常见错误: ① 把监管通知当成内部制度(层级错配会导致复核责任人错);② 把口径说明散落在业务知识里(应在第四级单独登记,否则报表口径必然打架)。
命名与归档规范(示例)
| 要素 | 规范 | 反例 | 检查方法 |
|---|---|---|---|
| 文件命名 | 类型-主题-版本-生效日期 | 最新版终版2.docx | 能否不看正文就判断版本先后 |
| 版本标识 | 与制度正式版本号一致 | 用日期代替版本号 | 与正式发文版本号是否一致 |
| 生效日期 | 必填,与发布批次对应 | 留空或写即日 | 是否能对应到具体发布批次 |
| 失效标记 | 旧版本显式标注已失效 | 旧新版本并存不区分 | 检索旧版时是否会被拦下 |
| 责任人 | 每层标注维护责任人 | 只有部门没有到人 | 到期能否找到具体复核人 |
实体与关系示例
| 实体类型 | 示例 | 关键属性 | 建模要点 |
|---|---|---|---|
| 制度 | 某业务管理办法 | 版本、生效日期、责任部门 | 版本是这个实体的必填属性 |
| 产品 | 某净值型产品 | 风险等级、适当性要求 | 与制度通过「适用」关系连接 |
| 角色 | 客户经理 | 职责、审批权限 | 用于回答「这件事谁负责」 |
| 指标 | 某项比率 | 公式、数据来源、口径 | 与报表通过「引用」关系连接 |
| 事件 | 监管检查 | 时间、结论、整改要求 | 用于追溯整改是否闭环 |
| 来源文件 | 某通知原文 | 文号、发布日期、出处 | 无出处的实体不入库 |
| 报表 | 某监管报送表 | 报送口径、频率、责任部门 | 指标变更时做影响面分析 |
| 关系类型 | 示例 | 用途 | 若缺失的后果 |
|---|---|---|---|
| 依据关系 | 内部制度 → 依据 → 监管规定 | 追溯合规来源 | 无法回答「这条依据从哪来」 |
| 适用关系 | 制度 → 适用 → 产品 | 判断某项业务受哪些约束 | 新业务上线时漏掉约束 |
| 责任关系 | 流程节点 → 责任 → 角色 | 明确到人 | 出事时找不到责任人 |
| 版本关系 | 新版本 → 替代 → 旧版本 | 避免误用旧口径 | 旧版仍被检索到并使用 |
| 关联关系 | 指标 → 引用 → 报表 | 口径变更影响面分析 | 改口径后不知道影响哪些报表 |
| 整改关系 | 检查事件 → 整改 → 制度/流程 | 跟踪整改闭环 | 整改是否完成无法追溯 |
图谱构建四步
| 步骤 | 动作 | 交付要点 |
|---|---|---|
| 1 定实体 | 确定要管住的几类核心对象 | 类型不超过 6 类,避免过度建模 |
| 2 定关系 | 只建"会用于判断"的关系 | 每个关系都要能回答一个实际问题 |
| 3 挂来源 | 每个实体标注出处与版本 | 无出处的实体不入库 |
| 4 设复核 | 按层级设定复核周期 | 到期未复核自动降权提示 |
建模取舍示例: 一个常见的失败案例是把组织架构、岗位、人员也建进知识图谱,结果实体类型膨胀到十几类,维护成本远超收益。正确做法是只保留会用于判断的实体——如果某个实体类型从来没有被用于回答过一个实际问题,它就不该在图谱里。
检验方法: 随机取十条近期真实提问,看有多少条需要用到该实体类型才能回答。低于两条的,考虑合并或删除。
class KnowledgeBaseSearch:
"""知识库语义搜索(结构示意)"""
def semantic_search(self, query: str, top_k: int = 5) -> dict:
# 1. 查询向量化
query_vector = embed_text(query)
# 2. 向量相似度召回
results = vector_search(query_vector, top_k)
# 3. 重排(按相关性、版本有效性、权威层级)
reranked = rerank(query, results)
# 4. 组织答案(必须带出处与版本)
context = "\n".join([r["content"] for r in reranked])
answer = compose_answer(query, context)
return {"answer": answer, "sources": reranked}
分块策略对照表
| 分块方式 | 适用内容 | 优点 | 风险 | 缓解措施 |
|---|---|---|---|---|
| 按条款 | 监管规定、制度条文 | 引用精确 | 条款过短时上下文不足 | 保留上一级标题作为上下文前缀 |
| 按章节 | 操作规程、产品说明 | 上下文完整 | 检索定位较粗 | 章内再按小节切分并保留路径 |
| 按表格 | 指标、费率、限额 | 数据完整 | 需保留表头 | 每块强制附带表头 |
| 按问答对 | 常见问题、客服知识 | 命中率高 | 覆盖面依赖积累 | 定期从真实提问中补充 |
| 按条款+引用 | 需精确追溯的制度 | 引用与上下文兼顾 | 块数变多 | 用重排控制返回条数 |
检索效果评估表
| 指标 | 含义 | 测法示例 | 目标方向 | 不达标的优先动作 |
|---|---|---|---|---|
| 召回率 | 该找到的是否都找到 | 用已标注问题集测 | 越高越好 | 先查分块,再查向量模型 |
| 精确率 | 返回的是否都相关 | 人工判定前 K 条 | 越高越好 | 加有效性过滤与权威层级权重 |
| 引用正确率 | 出处与版本是否对得上 | 抽查答案引用 | 应接近 100% | 低于 100% 即应暂停对客使用 |
| 失效内容拦截率 | 旧版本是否被拦住 | 构造已失效问题 | 应接近 100% | 检查失效标记是否真的生效 |
| 拒答率 | 无依据时是否明确说没有依据 | 构造超范围问题 | 应有明确拒答 | 补拒答模板与阈值 |
| 时效性 | 答案引用的版本是否仍有效 | 抽查近三个月答案 | 应接近 100% | 接入复核到期提醒 |
原则:宁可说"未找到依据",也不要生成一个看起来合理的答案。 金融知识库的错误代价远高于"没答上"。
评估实操示例(30 题小样本): 设计 30 道有标准依据的问题,其中 20 道在库内有明确依据、5 道依据已失效、5 道库内根本没有依据。人工判定:20 道是否被正确召回并引用到有效版本;5 道失效题是否被拦截;5 道超范围题是否明确拒答。这个小样本半天就能跑完,且能同时暴露召回、失效拦截与拒答三类问题。
只看整体准确率会掩盖问题。 必须把「有依据」「依据已失效」「无依据」三类分开统计——三类的错误代价完全不同: 有依据却答错会直接导致错误决策,依据已失效却仍被引用会埋下合规隐患,无依据却硬答则是最危险的一类。
知识生命周期五阶段
| 阶段 | 关键动作 | 留痕要求 | 常见失败模式 |
|---|---|---|---|
| 入库 | 校验出处、版本、生效日期 | 记录来源与审核人 | 无出处即入库,事后无法追溯 |
| 生效 | 标记生效日期,旧版转已失效 | 记录替代关系 | 只标新不标旧,旧版仍在被引用 |
| 使用 | 检索时优先返回有效版本 | 保留检索与引用记录 | 只在出问题后才补留痕 |
| 复核 | 按周期确认仍适用 | 记录复核结论 | 定了周期但无到期触发,等于没定 |
| 归档 | 失效知识可查不可默认引用 | 保留完整版本链 | 直接删除,版本链断裂 |
版本冲突处理表
| 冲突情形 | 判断原则 | 处理动作 | 为什么这样判 |
|---|---|---|---|
| 新旧制度并存 | 以生效日期晚者为准 | 旧版标失效并说明被谁替代 | 生效日期是可核验的客观事实 |
| 上位与下位规定不一致 | 以上位规定为准 | 触发下位文件修订 | 效力位阶优先于发布时间 |
| 同一指标两套口径 | 以口径登记为准 | 修订未登记方并统一 | 口径登记是机构内唯一的约定点 |
| 部门口径与全行口径不同 | 以全行口径为准 | 部门口径改为备注说明 | 避免同一报表出现两套数 |
| 正文与附表不一致 | 以正文为准,并标注附表待修订 | 同步修订附表 | 正文是效力主体 |
| 制度与监管新规冲突 | 以监管新规为准 | 立即停用并触发修订 | 合规底线,不等内部修订完成 |
冲突处理示例(同一指标两套口径): 数据部门定义的「有效保单」按是否过犹豫期计算,业务部门按是否已缴费计算,两个部门各自出数,同一张月报出现两个值。正确处理不是开会协调出一个折中值,而是先入口径登记表确定唯一公式与取数来源,再把未登记那一方修订为「业务口径(备注)」,并在报表上标明使用的是哪一套。
关键原则: 口径问题不能靠协商,只能靠登记。协商的结果会随人变,登记的结果才稳定。
答案组织要求
| 要素 | 要求 | 说明 | 缺失后果 |
|---|---|---|---|
| 结论 | 先给结论 | 一句话回答是什么/能不能 | 用户读完仍不知道答案 |
| 依据 | 附制度名称与条款 | 便于人工复核 | 无法复核,错误无声 |
| 版本 | 标注版本与生效日期 | 防止旧口径误用 | 引用了已失效文件 |
| 边界 | 说明不适用的情形 | 避免过度外推 | 被套用到不适用的场景 |
| 提示 | 超出知识库范围时明确拒答 | 不臆测 | 生成看似合理却无依据的答案 |
| 来源链接 | 能定位到原文位置 | 便于一键核对 | 知道有这条但找不到在哪 |
问答质量抽检表
| 抽检项 | 合格标准 | 处理方式 | 抽检方法 |
|---|---|---|---|
| 依据真实存在 | 引用可定位到原文 | 不实引用立即下线 | 随机抽 10 条引用逐条回原文核对 |
| 版本为有效版本 | 非已失效文件 | 更新检索权重 | 比对引用版本与当前有效版本 |
| 结论与依据一致 | 无跳跃推论 | 补中间依据或改为拒答 | 人工读依据再看结论是否跟得上 |
| 敏感数据合规 | 无客户身份信息 | 按数据规范处理 | 全文检索客户标识类字段 |
| 边界说明充分 | 写明例外情形 | 补写适用范围 | 检查是否只说能做什么 |
| 来源可定位 | 附原文位置而非仅文件名 | 补齐定位信息 | 让复核人能否在 2 分钟内找到 |
| 拒答是否到位 | 超范围问题明确拒答 | 补拒答模板 | 用 5 道超范围题测试 |
抽检示例(发现不实引用): 一条问答回答「X 业务的留存期限为 5 年」,引用了《X 业务管理办法》第 12 条。回原文核对后发现第 12 条写的是「至少 3 年」。处置不是改数字了事,而是三件事一起做:① 该条答案立即下线;② 检查同批还有多少条引用了同一条款;③ 排查是分块错误、重排错误还是生成环节的自由发挥。
只改答案会掩盖根因。 不实引用如果只是逐条修补,下一次还会以另一种形式出现;定位到环节才能真正降低发生率。
| 检查项 | 通过标准 | 不通过的直接后果 |
|---|---|---|
| 唯一来源 | 每类知识只有一个权威存放位置 | 同一问题多处答案不一 |
| 责任人明确 | 每一层知识都有指定责任人 | 到期无人复核 |
| 版本可追溯 | 能查到任一文件的完整版本链 | 无法证明当时依据是什么 |
| 失效可识别 | 已失效内容在检索结果中被明确标注 | 旧口径被当现行使用 |
| 口径有登记 | 指标类知识统一登记公式与来源 | 同一报表两套数 |
| 出处可定位 | 每条知识都能追溯到原始文件 | 无法人工复核 |
| 复核有周期 | 按层级设定复核频率并有到期提醒机制 | 制度过期仍在生效 |
| 权限有边界 | 按岗位设定可见范围 | 敏感内容越权可见 |
| 入库有门槛 | 无出处、无版本的内容不得入库 | 知识库快速劣化 |
| 项目 | 要求 | 检查人 |
|---|---|---|
| 数据最小化 | 只处理完成当前任务所必需的内容 | 使用人 |
| 去标识化 | 涉及客户信息时先做去标识处理 | 使用人 |
| 权限最小化 | 按岗位授予可见范围,不做超额开放 | 知识库管理员 |
| 访问留痕 | 保留检索与引用记录以备审计 | 知识库管理员 |
| 外部共享 | 未经审批不将内部知识对外提供 | 合规条线 |
| 敏感内容 | 涉及客户身份、账户信息的内容不纳入通用知识库 | 入库审核人 |
| 生成物先预览再确认 | 生成的分层方案、口径登记表、评估报告在写入任何文件前,必须先输出预览(条数、是否含客户标识、是否含未脱敏内容),经用户明确确认后再保存;未经预览与确认不落盘 | 使用人 |
| 不代为操作系统 | 不代为向知识库系统写入、迁移或删除数据,不代为调整任何人的访问权限 | — |
| 不代为定权威 | 本技能可建议「唯一来源」,但唯一来源的指定权在机构,不由本技能认定 | — |
入库存前的脱敏自检: 一批文档进入通用知识库之前,至少检查四类内容——客户身份信息、账户与合同编号、未公开的经营数据、以及仅在限定范围内流转的内部意见。命中任一类即不进入通用库,或转入限定可见范围。
整理一批制度文件:
帮我把以下制度文件按知识分层归类,输出:
1. 所属层级与责任人建议
2. 命名规范化后的名称
3. 需要标记失效的旧版本
文件清单:[文件列表]
建立指标口径登记:
整理以下指标的口径登记表,字段包括:
指标名 / 计算公式 / 数据来源 / 责任部门 / 复核周期
指标清单:[指标列表]
评估检索效果:
针对以下问题集合,评估知识库检索效果,
输出召回情况、引用正确性、是否存在失效内容被引用:
问题集合:[问题列表]
核查知识时效:
核查以下知识条目的时效性,
标出已超出复核周期或已被替代的条目:
知识条目:[条目列表]
排查一处口径冲突:
以下两个部门对同一指标给出了不同结果,帮我定位冲突点:
1. 两套口径的差异在哪里(公式/取数范围/时间口径)
2. 哪一套应作为唯一登记口径,依据是什么
3. 未登记那套应如何标注
指标:[指标名]|A 部门口径:[描述]|B 部门口径:[描述]
设计复核触发机制:
为以下知识条目设计复核触发机制,包含:
1. 各类知识的复核周期建议
2. 到期后的自动处置(提醒/降权/标注)
3. 复核结论的记录字段
条目清单:[条目列表]
| 动态类型 | 内容摘要 | 对知识库的影响 | 建议动作 | 优先级 |
|---|---|---|---|---|
| 数据治理 | 金融数据分级分类与数据治理要求持续深化 | 知识库需区分数据敏感级别 | 按敏感级别设定可见范围 | 高 |
| 个人信息保护 | 个人信息处理需遵循最小必要原则 | 含客户信息的文档不得进入通用库 | 建立入库存前检查 | 高 |
| 生成式AI治理 | 生成合成内容需可识别、可追溯 | AI 生成的问答内容需标注来源 | 答案强制附出处与版本 | 高 |
| 知识溯源 | 内部制度与监管依据需可追溯 | 需维护制度—监管依据映射 | 建立依据关系登记 | 中 |
| 版本管理 | 制度修订频繁,旧版本误用风险上升 | 需强制失效标记 | 检索结果标失效并降权 | 中 |
| 权限管理 | 岗位权限与信息可见范围需匹配 | 知识库需按岗位授权 | 定期核对权限清单 | 中 |
| 留痕与审计 | 关键操作需可回溯 | 检索与引用记录需保留 | 明确留存范围与期限 | 中 |
| 新增·AI 生成内容入库存 | AI 生成的摘要、问答若进入知识库需可识别 | 需标注生成方式与审核人 | 建立「AI 生成」标记字段 | 高 |
| 新增·引用可核验 | 对客或对外材料引用的制度条款需可一键核验 | 引用需附可定位位置 | 引用字段增加原文定位 | 中 |
| 新增·复核到期自动降级 | 超期未复核知识的引用风险被重点关注 | 需到期自动降权而非仅提醒 | 接入到期自动降权 | 中 |
- AI 生成内容进入知识库带来的溯源问题:由模型生成的摘要与问答若与人工撰写内容混存,事后难以区分来源。建议为这类内容设置独立标记字段与审核人字段,并在检索权重上与人工审核通过的内容区分处理。
- 「超期未复核」从提醒转向自动处置:仅靠提醒往往无人响应,越来越多做法是把到期未复核的知识自动降权或标注「待复核」,而不是照常返回给用户。
数据截止: 2026-10-12 | 来源:监管公开信息与行业实践整理 声明: 以上动态供参考,具体以官方最新发布为准。
This skill provides knowledge management frameworks and illustrative reference material for educational purposes. It does not execute code, does not access external systems, and does not constitute financial, legal, or compliance advice. All classifications, mappings, and answers produced with its help must be reviewed by the responsible business and compliance functions before being used in production.