银行机构的指标查询，看似是数据部门的日常支持工作，实则连接着信贷投放、风险监测、经营分析和监管报送。某银行业头部集团在业务扩张与精细化管理并行推进时，发现传统取数模式难以支撑基层业务人员对信贷、风控指标的即时理解与追问：口径分散、权限复杂、需求排队、解释成本高。数商云围绕该集团实际诉求，搭建银行问数智能体，把指标语义、数据权限、业务知识与大模型问答能力组织到统一工作入口，让信贷指标智能查询和风控指标智能查询从提需求、等结果转向自然语言提问、上下文追问、答案可追溯。本案例复盘项目从问题识别、方案设计到场景落地的全过程，为银行同业推进数据智能问答提供参考。
一、项目背景与客户挑战
该项目的起点并非单纯引入大模型，而是重新梳理银行指标查询中业务、数据与技术的衔接方式。数商云项目组在调研中发现，客户真正需要的不是演示型问答，而是能进入信贷、风控日常流程的指标查询入口。
1. 客户概况与项目缘起
(1) 「某银行业头部集团」业务覆盖公司金融、零售金融、金融市场与风险管理等领域，数据基础较为完整，指标管理也有专门团队负责。集团在推进精细化管理时，对信贷投放、资产质量、风险暴露、客户结构等指标的查询需求持续增加。业务人员不再满足于固定报表，而是希望围绕一个指标继续追问，了解变化来源、机构分布和客户特征。
(2) 过去，指标查询主要由数据团队承接。业务人员提交需求，数据团队理解口径、编写查询、导出结果，再经过确认后反馈。这种方式在需求相对稳定时有效，但面对临时性、组合式、追因式问题，沟通成本和等待成本都会上升。尤其信贷与风控场景对时效要求高，报表出来之后，业务问题往往已经发生变化。
(3) 数商云在项目沟通中意识到，客户需要的不是会聊天的工具，而是能理解银行指标、遵守权限边界、给出可解释答案的银行问数智能体。项目因此从指标梳理和场景选择入手，而不是先追求问答覆盖范围。这个判断，为后续建设定下了务实基调。
2. 信贷与风控指标查询的现实难题
(1) 指标口径分散是最先暴露的问题。相同名称的指标在不同报表、不同系统中可能存在定义差异，业务人员看到结果后难以判断该以哪个口径为准。数据团队则需要反复解释计算逻辑、统计范围和适用场景，沟通成本高，也容易在跨部门讨论中产生理解偏差。
(2) 查询需求排队影响业务节奏。客户经理、审批人员、风险经理提出的问题往往带有具体背景，单纯依靠需求单很难完整表达。数据团队在接收需求后，需要反复确认筛选条件、维度组合和结果呈现方式。需求越临时，沟通越频繁，业务等待越明显。
(3) 权限与合规要求高。银行指标涉及客户信息、资产质量、风险分类等敏感内容，不能简单开放查询能力。不同角色可见的机构范围、客户范围和指标范围存在差异，智能体必须理解权限边界，并在返回结果时做好控制与留痕。
(4) 风险场景追问多。风险经理不仅想知道指标结果，还想知道变化原因、结构分布、关联客户群体和异常线索。传统看板擅长展示固定结果，却不擅长承接连续追问。业务人员需要在多个报表之间切换，效率与体验都受到影响。
3. 项目目标与建设边界
(1) 项目目标明确为面向信贷、风控等业务人员提供自然语言问数能力，做到指标可查、口径可释、来源可追、权限可控。数商云没有把智能体定位成替代报表的工具，而是把它作为指标查询与解释的新入口，帮助业务人员更快获得答案，也帮助数据团队减少重复沟通。
(2) 建设边界同样清晰。项目优先聚焦信贷与风控指标，不追求一次性覆盖全部业务领域；智能体不替代核心业务系统，不直接修改业务数据；对外提供的能力必须经过权限校验和口径审核。这样的边界安排，让项目能够在可控范围内验证价值。
(3) 客户与数商云共同确定了评价标准：业务人员能否独立完成常见指标查询，数据团队重复取数压力是否下降，指标口径争议是否减少，风控与信贷管理响应是否更快，智能体能否形成持续运营机制。评价标准不只看问答次数，更看业务是否真正采纳。
二、解决方案与实施路径
数商云项目组没有把问数智能体做成孤立应用，而是把它放在集团数据治理与指标管理体系的延长线上。方案以金融指标语义层为核心，以权限和安全为底座，以业务知识和大模型交互为入口，形成可持续运营的银行数据智能问答能力。
1. 总体思路：用指标语义层承接自然语言问数
(1) 大模型擅长理解自然语言表达，但不天然理解银行指标口径。数商云在方案中设置金融指标语义层，把业务术语映射到数据模型、计算逻辑、统计维度和权限规则。业务人员说出的简称、别名和口语化表达，先经过语义层识别，再进入查询生成环节。
(2) 智能体的回答过程被拆分为问题理解、指标识别、权限校验、查询生成、结果解释等环节。关键环节可配置、可审计，避免出现“答案看似合理但口径不可追溯”的情况。对于涉及敏感指标的请求，系统会先判断角色与数据范围，再决定返回结果还是提示无权限。
(3) 对复杂问题采用多轮澄清。业务人员提问“这个指标为什么变化”时，智能体会结合上下文引导选择机构范围、产品维度或客户群体，避免因条件缺失产生误读。澄清过程不追求一次问完，而是贴近真实业务对话，让业务人员逐步聚焦问题。
2. 数据治理与指标口径统一
(1) 项目组联合业务、数据、风控和科技团队，梳理信贷与风控指标，明确名称、定义、口径、维度、责任部门和适用场景。指标不再只是报表中的一列结果，而是带有业务解释和治理责任的知识对象。这个过程工作量不小，却决定了智能体能否被业务信任。
(2) 数商云帮助客户建立指标知识库，把同义词、业务解释、常见问题、取数规则和权限要求纳入其中。智能体回答时不仅给出结果，还能说明指标含义、数据来源和适用范围。业务人员看到的不是孤立结果，而是可以理解、可以复核的指标答案。
(3) 对存在争议的口径设置评审与版本管理。指标定义发生变化时，智能体引用当前生效版本，变更过程留痕。这样既保证业务使用的稳定性，也为后续审计和指标运营提供依据。口径治理与智能问答由此形成互相促进的关系。
3. 信贷指标智能查询场景落地
(1) 在信贷场景中，智能体面向客户经理、审批人员、贷后管理等角色提供自然语言查询。业务人员可以围绕贷款余额、投放变化、客户结构、逾期情况、担保方式等指标提问，系统根据角色权限返回结果，并以图表、摘要和明细线索等方式呈现。
(2) 智能体支持组合条件提问。例如业务人员询问某区域、某产品近期的投放变化及主要贡献客户，系统能够识别区域、产品、指标和时间条件，生成查询并给出解释。业务人员还可以继续追问客户结构或变化原因，减少在多个报表之间来回切换。
(3) 查询能力与信贷管理流程衔接。客户经理可在贷前调查中了解客户相关指标，审批人员可在审查环节查看结构与风险线索，贷后管理人员可围绕变化情况开展检查。智能体提供数据参考，但不替代人工判断，信贷决策仍由业务流程和责任人完成。
4. 风控指标智能查询与权限控制
(1) 风控场景对准确性和响应速度要求更高。智能体支持风险指标查询、异常波动追问和客户群体分布查看，帮助风险经理快速定位问题机构、问题产品或风险集中领域。对于指标波动，系统可引导业务人员继续查看结构变化和关联线索。
(2) 权限控制嵌入问数链路。系统根据角色、机构范围、客户范围和指标敏感级别判断可见内容，越权请求会被拦截并记录。业务人员看到的结果与其职责范围保持一致，既提升查询便利性，也守住数据使用边界。
(3) 对敏感指标增加解释与审计。答案附带指标口径、数据来源、数据批次和操作留痕，便于后续复核。风控人员在使用智能体时，不仅关注结果本身，也能理解结果从何而来、适用于什么场景。这种可解释能力，是银行问数智能体进入生产环境的重要前提。
5. 智能体运营与持续优化机制
(1) 上线不是终点。数商云与客户共同建立问题样本库，收集未命中问题、歧义表达、权限拦截和口径争议，分类推进优化。业务人员提出的新问法会被转化为语义配置或知识补充，让智能体逐步适应真实语言习惯。
(2) 业务部门参与运营。指标负责人对口径解释和变更负责，数据团队维护语义与权限，科技团队保障系统稳定，数商云提供运营建议与能力支持。各方通过评审机制形成“提问、反馈、优化、复用”的闭环，避免智能体成为无人维护的技术展台。
(3) 运营关注业务采纳而非问答数量。项目组更关心常见问题能否被独立解决、口径解释是否被业务理解、数据团队重复取数是否减少、风控与信贷人员是否愿意持续使用。围绕这些信号持续迭代，智能体才能从可用走向好用。
三、项目成效与客户评价
项目价值不只在查询速度变化，更在于业务人员获取数据的方式、数据团队的协作方式以及风控管理的响应方式发生改变。以下从业务体验、管理支撑和组织协同角度呈现项目成效。
1. 业务人员获取指标的方式发生变化
(1) 过去，业务人员提出指标需求后需要等待排期、接收报表、核对结果。现在，业务人员可以在统一入口用自然语言提问，即时获得结果与解释。常见指标查询不再完全依赖数据团队，业务人员对数据的使用从被动接收转向主动探索。
(2) 对临时性、组合式问题，智能体可以承接连续追问。业务人员先看总体结果，再查看机构分布、产品结构和客户特征，问题在对话中逐步清晰。数据团队从大量重复取数中释放出来，更聚焦指标治理、数据质量和复杂分析。
(3) 口径解释被前置到答案中。智能体展示指标定义、数据来源和适用范围，减少“同名不同义”的争议。业务人员在使用结果时更有把握，跨部门讨论也更容易回到统一口径和事实基础。
2. 信贷管理与风控协同获得支撑
(1) 在信贷管理中，客户经理和审批人员能够更快了解客户结构、投放变化和逾期情况，为贷前调查、贷中审查和贷后检查提供数据参考。查询过程围绕业务问题展开，不再需要在多个固定报表中寻找线索。
(2) 在风控管理中，风险经理可以围绕指标波动进行追问，快速查看机构、产品和客户群体分布，支持风险监测与预警。智能体把指标结果与解释放在一起，帮助风险人员判断问题是普遍变化还是局部异常。
(3) 管理层也能通过自然语言获取经营与风险指标，减少层层报表传递带来的信息损耗。讨论更聚焦指标变化、业务原因和应对措施，数据在管理沟通中的角色从“结果展示”转向“问题澄清”。
3. 数据团队角色与协作模式升级
(1) 数据团队从接需求、写查询，逐步转向管指标、管语义、管权限、管运营。重复取数减少后，团队可以把精力投入到指标治理、数据质量、模型建设和复杂分析中，工作价值更容易被业务感知。
(2) 业务部门对指标定义和使用边界有了更清晰的认识。通过智能体的解释与反馈机制，业务人员不再只是提出需求，也会参与口径评审和问题样本反馈。数据团队与业务团队之间的沟通，从反复确认条件转向共同维护指标知识。
(3) 数商云与客户形成联合项目机制，业务、数据、科技、风控共同参与。智能体不再是技术部门的单独项目，而是嵌入指标治理和业务运营的协作平台。这种组织方式，为后续扩展经营分析、客户经营和合规检查等场景打下基础。
4. 客户评价与后续深化方向
(1) 客户评价认为，智能体的价值不是替代报表，而是把报表背后的指标逻辑和追问能力交给业务人员。业务人员能够更快理解指标、发现问题，数据团队也能从重复解释中抽身，双方围绕口径治理形成更顺畅的协作关系。
(2) 后续深化将围绕高频业务场景展开，包括经营分析、客户经营、合规检查等方向。客户明确表示，扩展场景仍要坚持先治理指标、再开放问答的原则，不盲目追求覆盖范围，而是确保每个场景都有清晰口径、明确责任和可用运营机制。
(3) 数商云建议银行机构建设问数智能体时，从高频、刚需、口径相对清晰的指标切入，先让业务人员感受到查询方式的变化，再逐步扩展能力。智能体需要与指标管理、权限体系、数据治理协同推进，才能形成稳定的银行数据智能问答能力。
5. 对银行同业的复制启示
(1) 先指标后问答。没有指标治理基础，大模型问答容易放大口径风险。银行机构应先把指标定义、计算逻辑、责任部门和适用范围梳理清楚，再让智能体承接自然语言查询。指标越清晰，问答越可靠。
(2) 先场景后平台。围绕信贷指标智能查询、风控指标智能查询等高频场景先做深，形成可验证的业务价值，再抽象平台能力。场景选择不必追求宽泛，关键是与业务刚需贴合，能够持续被使用。
(3) 先权限后开放。银行数据敏感，权限、审计和解释必须前置。智能体只有在明确数据边界、操作留痕和口径解释的前提下，才能真正进入生产环境。开放查询能力的同时守住安全底线，是项目可持续的基础。
(4) 先运营后规模。问数智能体不是上线即完成，需要业务反馈、指标评审和语义优化持续投入。对银行同业而言，建设银行问数智能体的难点不在演示效果，而在长期运营与业务采纳。数商云在本项目中的实践表明，把指标治理、权限控制、场景运营与智能问答结合起来，银行数据智能问答才能从概念走向日常业务。
评论