金融
金融行业 AI 知识库：让每一次合规回答都能回到原文
金融业务的问题往往不在缺少信息，而在信息太多且版本不一。内部制度与操作规程、监管文件与自律规则、产品说明书与合同、投研报告与尽调底稿分散在共享盘、邮件和各个业务系统里，同一个合规问题在不同分行可能得到不同答案。新员工上手靠口口相传，审批时翻十几个文件仍是常态，而监管检查要求每一个结论都能指回原文。
平台把这些材料收进一个按条线分权的私有化知识库：混合检索加 ReRank 先找到相关段落，答案再带上可点击的原文引用；空间隔离与四级 RBAC 精确到单个知识库，审计日志与跨服务链路追踪记录每一次问答的来路。模型可对接内网部署的开源模型，数据不出内网；系统给出的是可核查的依据，风险判断与审批签字仍然由人完成。
行业痛点
制度版本频繁更替
监管文件、自律规则与内部制度更新频繁，旧版本往往仍留在共享盘、邮件和聊天记录里。业务条线常常拿不准该引用哪一版，也说不清新版本从哪一天开始生效；等到检查或审计时才回头核对，成本已经很高。
同一合规问题答案不一
同一个合规问题，总行、分行与不同条线给出的解释并不一致，多数停留在口头和聊天记录里，没有形成可查的留痕。客户投诉或监管问询时，差异最终都要回到制度原文去解释。
投研材料沉在共享盘
投研报告、行业数据库和历史项目材料沉在个人电脑和共享盘目录里，命名各异，缺少统一的元数据。写过的东西难以被下一个人找到，重复劳动多，机构记忆随人员流动慢慢流失。
审批要翻十几份材料
一笔授信要翻授信申请、财务报表、尽调底稿、审批意见和贷后检查记录，关键口径散落在信贷系统、影像件和个人笔记里。审批人靠人工比对指标与结论，速度慢，事后也很难说清某条意见依据的是哪一份材料。
对应做法
整套系统装在内网，数据不出行
四个核心服务以 Docker Compose 单机或 Kubernetes 集群方式部署在机房内，可分别独立扩缩容；每个知识库还能绑定客户自己的对象存储桶。文档、向量与问答记录都留在内网，浏览器侧只需访问内部域名，不需要把材料传到外部服务。
对应能力：私有化内网部署
每个答案都能回到制度原文
检索走向量加关键词的混合通道，再由 ReRank 排序，避免只靠语义相似度错过条款号或产品代码。回答下方列出被引用的段落，点击可直接跳到原文位置；找不到依据时系统不编造出处，而是提示材料不足。
对应能力：引用溯源
按机构与条线划分可见范围
空间隔离加四级 RBAC，权限可以一路收窄到单个知识库；总行、分行、条线与项目组各自看到该看的部分。每次检索与问答写入空间级审计日志，配合 OIDC 单点登录，账号与人事系统保持一致，人员调岗或离职后权限随组织变化调整。
对应能力：空间级权限与审计
制度换版后仍能说清差异
文档入库时保留版本快照，切片编辑器里可以做行级 diff 并回滚到任一历史版本，自定义元数据可以标记适用范围、生效日期与废止状态。回答里引用的段落绑定到具体版本，制度换版之后，仍能还原当时那次问答依据的是哪一版。
对应能力：版本快照与回滚
落地场景
制度与合规问答
客户经理、柜面和分行合规岗用自然语言提问，答案给出条文原文与版本，遇到材料没有覆盖的问题直接说明，不给出没有出处的结论。
授信审批材料的结构化
把授信申请、财务报表、尽调底稿与历次审批意见放进同一空间，数据分析智能体用自然语言转查询的方式汇总关键指标，审批人再逐条核对引用段落并签字。
投研与尽调材料的复用
用 Wiki 模式把散落的报告、会议纪要与底稿整理成互相链接的页面和知识图谱，历史结论按行业、标的与时间归档，下一次写报告不必从零开始。
监管检查时的材料回溯
检查组要求说明某条结论的依据时，从审计日志定位那次问答，回放当时的检索结果、引用段落与模型调用链路，材料准备从翻档案变成导出记录。
行业术语与知识实体
- 适当性管理
- 销售产品或服务前，机构评估客户风险承受能力与产品风险等级是否匹配并留档，与投资者分类、风险揭示和双录一起执行。
- 双录
- 在销售或签约环节同步录音录像，把产品说明、风险揭示与客户确认的过程固定下来，作为后续纠纷处理与检查的原始材料。
- 反洗钱客户尽职调查
- 机构在建立业务关系时识别客户身份、了解资金来源与用途、评估洗钱与恐怖融资风险，并在关系存续期间持续更新客户信息。
- 授信审批
- 银行在发放贷款或给予信用额度前，对借款人的资信、还款能力、担保与用途进行审查，并按授权权限做出审批决定的过程。
- 贷后管理
- 贷款发放后对借款人经营、财务、担保与资金用途的持续跟踪，包括定期检查、风险分类调整和预警处置。
- 关联交易
- 公司与关联方之间发生的资源或义务转移，需要按监管要求识别关联方、履行审批程序并做信息披露。
- 内控手册
- 机构把控制目标、流程节点、职责分工、控制措施与检查方法写成的内部文件，是内控执行与审计评价的依据。
- 监管报送
- 按监管部门规定的口径、频率和模板提交数据与报告，包括报表数据、统计信息和专项报告，数据来源需可核对。
- 数据不出域
- 数据在机构自有或指定环境内处理与存储，不传输到该环境之外，是金融行业私有化部署与数据安全评估中的常见要求。
这些定义同时以结构化方式提供给搜索引擎与 AI 引擎，便于它们准确理解并引用行业概念。
行业常见问题
- 我们的知识库必须放在行内机房，能不能完全内网部署、不连外网？
- 可以。金融行业的生产知识库通常不与互联网直连，部署方式需要跟现有运维体系对齐。平台提供 Docker Compose 单机与 Kubernetes 集群两种方式，四个核心服务可以独立部署和扩缩容，每个知识库还能绑定行内自己的对象存储桶；模型既可用内网部署的开源模型，也可在允许时对接外部 API。除显式配置的模型与数据源外，系统不需要访问外网。
- 用外部大模型的话，制度文件和客户材料是不是就被传到外面去了？
- 这取决于模型接在哪一侧。平台把文档解析、切片、向量化与检索都放在内网，只有需要生成答案时才会调用所配置的模型；如果把模型换成本地部署的开源模型，整条链路都在内网完成，材料不出域。这一点在尽调与安全评估里需要写清楚，通常也要求模型调用与数据流向可被审计。
- 回答能不能指到制度原文的具体条款，而不是给一段听起来合理的总结？
- 合规问答的价值就在于可核查。平台用向量加关键词的混合检索加 ReRank 命中段落，答案里的每处引用都可点击跳转到原文，并标明来自哪份文件、哪个版本；材料里没有依据时，系统会说明检索不到，而不是补一段推测。检查人员据此可以逐条核对。
- 制度换版以后，怎么保证员工搜到的是现行有效的那一版？
- 常见做法是把生效日期、废止状态和适用范围写进元数据，并在入库时保留版本快照。平台支持自定义元数据过滤，切片编辑器可做行级 diff 与回滚；旧版本不会被物理删除，但可以被标记为已废止并在检索时排除，需要追溯历史结论时再按版本号调出来。
- 总行、分行、不同条线的知识库权限怎么分开，会不会互相看到不该看的材料？
- 金融机构的材料天然分层：总行制度全行可见，分行细则只在本机构，投行项目底稿按项目组隔离。平台用空间隔离加四级 RBAC，权限可收到单个知识库；配合 OIDC 单点登录，人员调岗后权限随目录变化，检索与问答写入空间级审计日志，谁在什么时候问了什么、看到了哪段原文都能查。
- 能不能对接我们现有的统一认证和 AD 域账号，还是要另建一套账号？
- 通常不需要另建账号，金融机构的做法是把知识库挂到现有身份体系上。平台支持 OIDC 单点登录，可以直接对接行内统一认证；角色与空间权限在平台侧配置，登录态沿用统一认证，人员离职停用账号后即失去入口。API 侧使用两级密钥，便于把检索能力嵌到既有系统而不共享个人凭据。
- 能不能在私有化环境里用我们自己部署的国产模型，比如 DeepSeek 或通义千问？
- 可以。平台按 OpenAI 兼容接口接入模型，本地通过 Ollama 或其他推理服务部署的开源模型都能挂上来，DeepSeek、通义千问、智谱、混元、MiniMax 等厂商的模型也在支持范围内；不同知识库和场景可以指定不同模型。切换模型不影响文档、切片与权限配置，历史问答仍可按原来的模型调用记录回放。
- 模型给出的合规结论能直接当审批依据吗，和人工签字的边界在哪里？
- 不能直接当依据。模型风险管理的基本要求是自动化输出可解释、可追溯，并由有权限的人做最终判断。平台把角色定位在检索、比对与起草：给出引用段落、列出差异与待确认项，审批意见与风险结论仍由人填写和签字；每次问答的操作人、时间与引用内容都留痕，便于事后复核而不是替代复核。