做金融风控数据这几年我越来越觉得小贷行业真正缺的不是模型而是一个能把数据和决策日常化使用的入口。团队内部代号叫 DataQA 的这套“数问增长”平台最初就是想给业务、风控、管理层一个随时能对话的智能风控大脑。这篇内容不聊高深算法只讲怎么把自然语言查询、风控指标分析、策略动作串成一条能落地的闭环以及我们在真实业务里踩过的坑。1. 为什么中小金融机构需要自己的“智能风控大脑”1.1 数据不缺缺的是把数据变成决策的速度大多数小贷公司并不缺数据。核心系统里有客户进件数据、审批记录、放款还款流水征信报文也能定期拿到催收系统里还存着大量的触达记录和联系方式。但真到用数据的时候痛点往往高度一致业务方想问一个“最近三个月首逾率为什么涨了”从提需求到拿到答案正常流程是业务提数、数据团队排期、写SQL、出报表、再开会解释口径。一轮下来三到五天就过去了黄花菜都凉了。更麻烦的是业务问的数据往往是交叉的。比如“通过率下降了5个点到底是客群结构变了还是审批策略收紧了”这种问题拆开来看涉及进件量、拒绝原因分布、评分分布、策略命中率等至少四五张表。如果每次都要数据团队手动取数本质上是在用昂贵的人力做重复劳动。DataQA 的出发点就是把这个过程自动化业务直接用大白话提问系统理解问题、自动关联指标、返回可解释的分析结果。我在实际推动这个项目的时候发现一个很有意思的现象很多领导一开始期待的是“一个会说话的报表”但真正用了几个月之后大家依赖的是它能把“是什么”和“为什么”连在一起回答。比如“通过率降了”只是现象“因为B类客群进件占比提升且该客群命中率下降”才算结论。后者才是智能风控大脑该干的事。1.2 “数问增长”到底解决什么问题数问增长的完整含义我理解成两层。第一层是“数问”也就是用自然语言向数据系统提问第二层是“增长”指的不只是业务规模增长还包括风控能力的增长、团队协作效率的增长、策略迭代速度的增长。举个实际例子。过去策略同学要做一次调额复盘需要先找数据同学要“近6个月额度使用率分布”再要“各额度区间的逾期表现”然后自己用Excel透视表算交叉最后写PPT汇报。这个流程快则两三天慢则一周。有了问答式风控大脑之后策略同学可以直接问近6个月不同额度使用率区间的M1逾期率是多少按季度环比变化如何。几秒钟出结果还附带了自动归因说明。在小贷这个行业资产质量的生命周期很短可能一个策略失误三个月之后才会在贷后数据上体现。如果分析链路太慢等发现风险时损失已经发生了。所以数问增长真正解决的是把风险信号到策略响应的时间从一个星期压缩到几分钟。这是我对外讲这套系统时最核心的价值主张。另外它还能解决“数据民主化”的问题。小贷公司通常没有庞大的数据团队可能就两三个数据开发却要支撑信贷、贷后、财务、催收好几个部门的数据需求。把高频、标准化的问题交给系统自动回答数据团队才能腾出手做更复杂的建模和专项分析。这也是这套系统在中小机构里特别受欢迎的原因。1.3 这套系统适合谁不适合谁先说适合谁。第一类是持牌小贷公司、消金公司这类机构业务规模中等数据量不算巨大但维度很杂数据团队人力紧张。第二类是助贷平台的风险管理部门需要频繁跟前端渠道、资方沟通数据表现问答系统能统一口径、减少扯皮。第三类是传统金融机构里的创新部门想验证AI落地的场景风控问答是一个低风险、高可见度的切入点。不太适合的也有。如果是头部大型银行那种超大规模数据仓库每天跑几百个T的任务、有完备的数据中台和几千人的数据团队那可能需要的是更重型的机器学习平台而不是轻量问答系统。另外如果公司的数据质量极差连基础的表结构都经常变动也不建议硬上。系统再聪明也无法从垃圾进料里产出可用的风控判断。所以我在设计系统定位时一直强调它是个“大脑助手”不是“数据仓库替代品”。它需要建立在相对规范的数据基础之上才能发挥最大价值。2. 架构与设计从数据仓库到问答引擎的四层结构2.1 元数据层让机器先懂业务口径很多团队做自然语言查询一上来就死磕语义模型结果语义模型做完了业务却说答非所问。问题出在底层机器根本不懂业务口径。同一个“逾期率”有人说的是“月末逾期余额/月末总余额”有人说的是“当月新增逾期笔数/当月应还笔数”差别非常大。所以在 DataQA 里我们最先建设的不是算法而是元数据层。具体做法是把风控领域常用指标做了一次系统性梳理为每个指标建立标准定义、计算公式、统计维度、数据来源表、更新频率和业务负责人。比如“首逾率”这个指标我们明确它是“首次还款日逾期1期及以上的客户数/到期应还客户数”分子来自还款计划表分母来自放款表T1更新。这个过程叫指标标准化做完之后整个公司对同一个词有了统一的解释。元数据层的另一个关键作用是给自然语言理解提供约束。机器不像人一样懂业务它需要知道“首逾”和“首期逾期”是同义词“M1”是“逾期1-30天”的简称。我们把这类同义词、简称、上下位关系维护成语料库问答系统的准确率才能从“靠运气”变成“靠规则”。这里要给准备做类似系统的团队一个建议元数据建设一定要业务方全程参与。如果只是数据团队闭门造车做出来的指标字典大概率跟实际业务话语体系脱节。我们当时组织风控、贷后、财务、运营各出一个人组成“指标评审小组”每周过一遍新增指标耗时一个月才把首期核心指标沉淀完。虽然慢但后期收益非常大问答系统上线后的口径争议少了一大半。2.2 指标引擎层把“人话”翻译成可执行的查询元数据层解决“懂业务”的问题指标引擎层负责“懂语言”。这一层接收业务人员输入的自然语言经过意图识别、实体抽取、条件解析、SQL生成四个步骤最终输出可执行的查询语句或API调用。意图识别这块我们最初纠结过用通用大模型还是垂直小模型。通用大模型的理解能力强但响应不稳定、token成本高、在金融场景下也不敢完全放权。最终采用的是“规则路由加语义模型”的混合方案常见问题先走模板匹配比如“XX指标近X个月趋势”这种高频句式直接映射固定查询复杂问题走语义模型解析出指标、时间范围、维度、过滤条件再动态生成SQL。我举个例子。问题是“最近三个月不同渠道的件均放款额怎么变化”指标引擎会拆解成指标件均放款额等于放款总额/放款笔数时间最近三个月按月分组维度渠道过滤条件无生成SQL的大致逻辑是SELECT month, 渠道, SUM(放款金额) / COUNT(借款编号) AS 件均放款额 FROM fact_loan WHERE month DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH) GROUP BY month, 渠道 ORDER BY month, 渠道这个SQL只是示意实际上需要在元数据层做一层安全改写比如强制加上机构过滤条件、限制查询行数、防止全表扫描。这些逻辑都收敛在指标引擎层业务侧是无感的。调试过程中最容易出问题的是用户问话里带着隐含条件。比如“新户的件均放款额”和“件均放款额”是两个完全不同的指标前者需要关联客户表过滤首借标志后者不需要。所以我们在指标引擎里做了“实体消歧”模块当用户提到“新户、老户、首借、复借”这类词时自动识别并追加过滤条件避免取数错误。2.3 分析决策层从回答“是什么”到回答“怎么办”如果系统只做到查询和展示那它充其量是个智能报表工具还算不上风控大脑。DataQA 真正拉开差距的地方是在分析决策层做了三件事自动归因、异常预警、策略模拟。自动归因的逻辑听上去玄落地其实相对朴素。系统检测到某个核心指标出现显著波动时自动下钻到贡献度最高的维度尝试解释变化来源。比如“逾期率上升”这个现象系统会自动化拆解按渠道拆分哪个渠道的逾期率环比上升幅度最大按产品拆分哪个产品贡献了主要的逾期增长按客群拆分新增客群和存量客群的逾期表现差异再把结果组装成一句人话“本月逾期率4.2%较上月上升0.6个百分点主要受X渠道件均额度提升影响该渠道逾期率环比上升1.8个百分点贡献了整体上升幅度的62%。”这个能力说穿了就是“预置了下钻路径的自动化分析”但它的体验价值是巨大的。业务人员不需要自己一层层去点报表系统把“数据侦探”的工作先做了一遍。我们在做这个功能时刻意没有追求100%准确的归因因为风险变化本来就是多因素共同作用的结果能给到60%的确定性线索再靠人工判断效率已经比纯手工分析高很多。异常预警则是对关键指标设置阈值和监控频率比如逾期率日环比超过10%触发提醒、通过率周同比低于预设目标触发预警。预警消息会直接推送到企业微信或者钉钉群点开就能看到系统生成的简要分析。这种主动服务比“用户来问”更进一步也是留住黏性的关键。策略模拟是我个人最看重的模块。比如风控人员想评估“把某评分卡的拒绝阈值从600分提高到620分会怎么样”系统直接从历史进件里做模拟计算输出调整后对通过率、放款量、预期逾期率的影响估计。这一步相当于把策略实验室搬进了问答对话里。它依赖的是离线计算框架不是实时跑数所以在准确性和响应速度上做了平衡秒级返回初步估计详细报告异步生成。2.4 权限与审计金融场景绕不开的安全底线小贷行业的经营数据高度敏感客户手机号、身份证号、还款记录、逾期信息统统在里面。所以 DataQA 从设计第一天就把权限管理当成一等公民而不是事后补丁。我们设计了“数据域加数据行级权限”双重控制。数据域控制的是“能看什么表”比如催收团队能看贷后表但看不到审批策略明细行级权限控制的是“能看哪些机构、哪些产品线、哪些客群”。在指标引擎生成SQL的时候系统会自动注入权限条件试图绕过权限的提问会被拦截并记录。审计日志也是强需求。谁在什么时间问了什么问题、系统返回了什么结果、结果有没有被导出这些全都有留存。这一点在金融监管趋严的背景下尤其重要检查的时候不是听你讲管理流程而是直接看你在系统里怎么控制的。另外还有一个容易被忽视的点导出管控。问答结果再准确落到Excel满天飞也是风险。我们的做法是敏感指标禁止直接导出必须脱敏或者走审批流程非敏感指标导出时强制增加水印包含操作人标识一旦泄露可以溯源。虽然增加了一点操作步骤但业务部门都能理解毕竟金融行业的底线不是效率而是安全。3. 实战把小贷公司的风控问答跑通3.1 接入前的数据准备理论讲完说说真实项目里怎么落地。我们在某家区域性小贷公司的实施过程可以作为参考。这家公司有自营信贷产品和一条助贷合作渠道存量客户几十万日新增进件量不大但数据来源很杂核心系统一套库、催收系统一套库、合作的征信数据是接口推送没有统一的数仓。第一步不是写代码而是做数据盘点。我们花了第一周时间把核心表结构、字段含义、更新频率梳理清楚产出了一份数据地图。第二步是搭基础的数仓分层也不需要搞大而全的架构就做了两层一层是ODS贴源层把各系统的数据原样同步过来一层是DWD明细层做清洗、去重、标准化。最后在DWD之上建了一套DWS汇总表专门服务高频问答场景。摘要一下首批接入的核心表大概有六类客户信息表客户ID、年龄、性别、地区、职业、首次借款时间进件审批表申请时间、渠道、产品、额度、利率、审批结果、拒绝原因放款表放款日期、金额、期限、还款方式还款计划表应还日期、应还金额、期次还款流水表实还日期、实还金额、逾期天数贷后催收表催收次数、最近催收日期、承诺还款日这些表建好之后我们才在元数据层配置指标口径。这个过程切忌一上来就追求面面俱到先把业务最关注的十个核心指标配置完让系统能回答第一批问题跑起来之后再做扩展。3.2 常用风控问答场景演示与返回逻辑系统上线后我们整理了一批高频场景这里挑几个有代表性的展示。第一个是贷后监控类提问“昨天全量客户的M1逾期率是多少和前天比怎么样”系统返回结果时除了给出数值还会自动补充一句“M1逾期率上升0.15个百分点主要原因是周四到期量较高导致分母暂时放大预计后天回落”。这个补充判断来自规则引擎逻辑是分母到期客户数波动导致的被动上升。第二个是策略分析类提问“本月不同额度区间的新客首逾率对比如何”这类问题会自动关联客户表、放款表和还款计划表按额度区间分组计算首逾率。我们在返回结果时还会附带一个简单的显著性提示比如“10万以上额度区间样本量较小结论仅供参考”。这个小细节很受风控同事欢迎避免他们拿着不稳定数据直接做判断。第三个是渠道对比类提问“A渠道和B渠道的通过率差异主要受哪些因素影响”系统先算出两个渠道的通过率差异然后做特征维度下钻年龄分布、收入分布、申请金额分布、命中规则分布。最终返回结果时以文字加表格的形式说清楚差异来源比如A渠道通过率低主要是因为高龄客群占比高且该客群命中多头借贷规则比例较大。第四个是预测类提问“按照当前日均放款量预计本月末新增贷款余额是多少”这类问题走的是时间序列推算简单的用日均乘以剩余天数复杂一点的会叠加季节性系数。我们不会把预测结果描述成确定事实而是给出一个置信区间并注明推算逻辑。这个共识是在踩了一次坑之后建立的具体后面会讲。3.3 从问答到策略动作的闭环设计问答系统做得再好如果只停留在“问问看”的层面价值会大打折扣。我们在设计时把问答结果跟策略动作连成了闭环。举个例子。业务方提问“近两周通过率连续下降是什么原因”系统归因发现主要是一个合作渠道的进件结构发生了变化高评分的优质客群占比下滑。这时候问答结果旁边会直接挂一个“查看建议动作”按钮点击展开两个选项一是下调该渠道的通过率底线阈值以稳定资产质量二是调整渠道进件规则引导更多优质客群。点选之后系统会生成一个策略变更草稿推送给风控负责人审批审批通过后由策略引擎自动或半自动执行。这种闭环设计有几个好处。第一缩短了“发现问题到解决问题”的路径不需要从分析系统跳到策略配置系统再跳到审批流程。第二策略变更的前后效果可以自动追踪系统会在执行后按预设周期生成效果回看报告回答“调整之后怎么样了”。第三所有的洞察、决策、动作都有完整记录这对后续监管审计和策略复盘都是极大的加分项。当然闭环不意味着完全自动决策。金融业务的容错率低我们把自动执行的范围限制在“非关键的参数微调”上比如催收触达频次、营销活动的客群圈选而涉及授信审批核心环节的策略变更必须人工审批。这个边界定下来之后团队对系统的信任度才真正建立起来。4. 踩坑实录与调优笔记4.1 口径不一致问同一个指标不同部门给不同数这个坑几乎是所有数据类项目都会遇到的我们也不例外。系统刚上线测试时业务同事提问“本月的通过率”系统按照标准口径返回了数字结果负责运营的同事说“我们平时看的是另外一版数”两边差了快两个百分点。一排查发现运营口径的分子是“通过并放款的客户”分母是“进件客户”风控口径的分子是“审批通过的客户”分母也是“进件客户”。通过但未放款的那部分客户就是差异来源。这个问题不是技术能单独解决的必须在组织层面拉齐。我们当时的处理方式是把指标口径差异显性化在问答结果上标注“当前指标口径为审批通过率如需按放款口径查看请切换”。同时推动两个部门重新梳理了指标定义最终形成了公司级指标字典从此以后财务用一套数、风控用一套数、运营用一套数的混乱局面才逐渐收敛。给同行的建议是不要试图用一个技术系统强行统一业务口径这不现实。系统能做的是让不同口径的差异可见、可解释、可追溯让人为选择口径变得严肃——因为每一次查询都会被审计。4.2 语义歧义技术能解决一部分产品规则兜底更重要自然语言天生有歧义这在金融风控场景下会被放大。比如用户问“近三个月新客通过率”这个“新客”到底指的是“三个月内首次申请的人”还是“三个月内首次借款成功的人”差一个环节指标结果就完全不同。还比如“件均额度”是按放款笔数算还是按放款客户数算多人提问场景下理解不一致会导致结论完全相反。我们的经验是三层兜底。第一层在指标引擎里把常用歧义词做成规则模板自动选择业务默认含义比如“新客”默认取“首次借款成功客户”。第二层当系统检测到用户提法可能对应多个指标时不猜直接请求澄清“您问的新客通过率是指首次申请客群的通过率还是首次借款客群的通过率”这个多一次的交互成本换来准确率的明显提升。第三层在返回结果上展示计算口径说明用户可点击查看详细定义。语义歧义不可能100%消除所以系统要设计成“知道自己在不确定时保持谨慎”的模式。比起盲目给出一个可能错误的数字主动追问反而更能赢得业务信任。4.3 查询性能与稳定性不要让问答卡死生产库问答系统最大的技术风险就是业务随便问一句背后却生成了一个扫描全表的慢查询把生产数据库资源吃满。我们早期就出过一次事故。某同事问“近两年所有客户的分期还款记录中各渠道表现如何”这个查询直接扫描了上亿行明细表监控系统告警时数据库CPU已经飙升到90%多差点影响线上进件。这次事故之后我们立了几条铁律问答系统的查询只能走只读从库绝对不能碰生产主库。所有查询默认带时间范围限制近一年的数据必须单独确认才能查。查询超时时间限制在10秒超过则自动熔断并提示用户缩小范围。高频热点问题预计算结果直接查DWS汇总表不需要跑明细。性能调优最有效的手段不是靠数据库优化技巧而是把80%的高频问题提前识别出来做成预聚合结果。用户问“昨天逾期率”系统不是现场去算而是查前一天跑好的指标结果表。这样既保证了速度又降低了对底层数仓的压力。实时计算只有碰到真正需要明细下钻的开放性问题时才动用而这类问题在业务里占比其实不高。4.4 模型迭代问答系统自己的“风控”也不能少DataQA 本质上是AI系统AI系统就需要持续评测和迭代。我们建了一个“问答对测试集”选取历史上业务真实提过的300个问题标记标准答案和接受范围。每次模型或规则调整之后都要跑一遍回归测试保证A问题的修复不会导致B问题退化。评测集不是建完就不动的。新业务上线、新指标加入之后我们会把新出现的提问补充到测试集里。从上线到现在这个测试集已经扩展到了500多条覆盖了信贷审批、贷后管理、财务分析、监管报送等各个场景。迭代节奏基本是两周一个版本每次发布前过一遍回归。还有一个容易被忽略的点问答系统的回答质量本身要纳入风控。我们曾经遇到一种情况系统对某个指标的历史趋势理解错了返回了一个误导性结论差点让业务部门做出错误调整。从那之后凡是涉及“归因、预测、建议”类输出系统默认附带风险提示比如“该归因基于有限维度的自动下钻建议结合人工分析验证”。这种防御性表述虽然看起来保守但在金融场景里是必要的宁可少一分“聪明”也要多一分可靠。最后说点体会从最初的数据取数工具一路演进到现在的智能风控大脑这个项目让我最大的收获是AI在金融领域的价值不只是模型多准确更在于它能不能嵌入到日常决策流里让每一个环节的人都能更快、更准地得到自己需要的信息。我在实际使用中发现业务同事对一个问答系统的信任往往不是来自某次神奇的回答而是来自每一个普通问题都稳定、口径一致、能解释来源。这种信任一旦建立大家就会主动把更多问题抛过来系统也就在不断使用中变得越来越聪明。如果你也在做类似的风控数据产品我的建议很简单先别追求大而全的智能把元数据做扎实把高频问题跑稳把权限和审计做好再慢慢叠加归因、预测和策略闭环。等哪天业务方开始习惯“先问一下系统”而不是“先发邮件提数”这套系统就算真的长在业务里了。 
长河君 · 2026/10/17 4:16:43 · 阅读 1.2k 打造智能风控大脑：自然语言查询与指标分析闭环实践
做金融风控数据这几年我越来越觉得小贷行业真正缺的不是模型而是一个能把数据和决策日常化使用的入口。团队内部代号叫 DataQA 的这套“数问增长”平台最初就是想给业务、风控、管理层一个随时能对话的智能风控大脑。这篇内容不聊高深算法只讲怎么把自然语言查询、风控指标分析、策略动作串成一条能落地的闭环以及我们在真实业务里踩过的坑。1. 为什么中小金融机构需要自己的“智能风控大脑”1.1 数据不缺缺的是把数据变成决策的速度大多数小贷公司并不缺数据。核心系统里有客户进件数据、审批记录、放款还款流水征信报文也能定期拿到催收系统里还存着大量的触达记录和联系方式。但真到用数据的时候痛点往往高度一致业务方想问一个“最近三个月首逾率为什么涨了”从提需求到拿到答案正常流程是业务提数、数据团队排期、写SQL、出报表、再开会解释口径。一轮下来三到五天就过去了黄花菜都凉了。更麻烦的是业务问的数据往往是交叉的。比如“通过率下降了5个点到底是客群结构变了还是审批策略收紧了”这种问题拆开来看涉及进件量、拒绝原因分布、评分分布、策略命中率等至少四五张表。如果每次都要数据团队手动取数本质上是在用昂贵的人力做重复劳动。DataQA 的出发点就是把这个过程自动化业务直接用大白话提问系统理解问题、自动关联指标、返回可解释的分析结果。我在实际推动这个项目的时候发现一个很有意思的现象很多领导一开始期待的是“一个会说话的报表”但真正用了几个月之后大家依赖的是它能把“是什么”和“为什么”连在一起回答。比如“通过率降了”只是现象“因为B类客群进件占比提升且该客群命中率下降”才算结论。后者才是智能风控大脑该干的事。1.2 “数问增长”到底解决什么问题数问增长的完整含义我理解成两层。第一层是“数问”也就是用自然语言向数据系统提问第二层是“增长”指的不只是业务规模增长还包括风控能力的增长、团队协作效率的增长、策略迭代速度的增长。举个实际例子。过去策略同学要做一次调额复盘需要先找数据同学要“近6个月额度使用率分布”再要“各额度区间的逾期表现”然后自己用Excel透视表算交叉最后写PPT汇报。这个流程快则两三天慢则一周。有了问答式风控大脑之后策略同学可以直接问近6个月不同额度使用率区间的M1逾期率是多少按季度环比变化如何。几秒钟出结果还附带了自动归因说明。在小贷这个行业资产质量的生命周期很短可能一个策略失误三个月之后才会在贷后数据上体现。如果分析链路太慢等发现风险时损失已经发生了。所以数问增长真正解决的是把风险信号到策略响应的时间从一个星期压缩到几分钟。这是我对外讲这套系统时最核心的价值主张。另外它还能解决“数据民主化”的问题。小贷公司通常没有庞大的数据团队可能就两三个数据开发却要支撑信贷、贷后、财务、催收好几个部门的数据需求。把高频、标准化的问题交给系统自动回答数据团队才能腾出手做更复杂的建模和专项分析。这也是这套系统在中小机构里特别受欢迎的原因。1.3 这套系统适合谁不适合谁先说适合谁。第一类是持牌小贷公司、消金公司这类机构业务规模中等数据量不算巨大但维度很杂数据团队人力紧张。第二类是助贷平台的风险管理部门需要频繁跟前端渠道、资方沟通数据表现问答系统能统一口径、减少扯皮。第三类是传统金融机构里的创新部门想验证AI落地的场景风控问答是一个低风险、高可见度的切入点。不太适合的也有。如果是头部大型银行那种超大规模数据仓库每天跑几百个T的任务、有完备的数据中台和几千人的数据团队那可能需要的是更重型的机器学习平台而不是轻量问答系统。另外如果公司的数据质量极差连基础的表结构都经常变动也不建议硬上。系统再聪明也无法从垃圾进料里产出可用的风控判断。所以我在设计系统定位时一直强调它是个“大脑助手”不是“数据仓库替代品”。它需要建立在相对规范的数据基础之上才能发挥最大价值。2. 架构与设计从数据仓库到问答引擎的四层结构2.1 元数据层让机器先懂业务口径很多团队做自然语言查询一上来就死磕语义模型结果语义模型做完了业务却说答非所问。问题出在底层机器根本不懂业务口径。同一个“逾期率”有人说的是“月末逾期余额/月末总余额”有人说的是“当月新增逾期笔数/当月应还笔数”差别非常大。所以在 DataQA 里我们最先建设的不是算法而是元数据层。具体做法是把风控领域常用指标做了一次系统性梳理为每个指标建立标准定义、计算公式、统计维度、数据来源表、更新频率和业务负责人。比如“首逾率”这个指标我们明确它是“首次还款日逾期1期及以上的客户数/到期应还客户数”分子来自还款计划表分母来自放款表T1更新。这个过程叫指标标准化做完之后整个公司对同一个词有了统一的解释。元数据层的另一个关键作用是给自然语言理解提供约束。机器不像人一样懂业务它需要知道“首逾”和“首期逾期”是同义词“M1”是“逾期1-30天”的简称。我们把这类同义词、简称、上下位关系维护成语料库问答系统的准确率才能从“靠运气”变成“靠规则”。这里要给准备做类似系统的团队一个建议元数据建设一定要业务方全程参与。如果只是数据团队闭门造车做出来的指标字典大概率跟实际业务话语体系脱节。我们当时组织风控、贷后、财务、运营各出一个人组成“指标评审小组”每周过一遍新增指标耗时一个月才把首期核心指标沉淀完。虽然慢但后期收益非常大问答系统上线后的口径争议少了一大半。2.2 指标引擎层把“人话”翻译成可执行的查询元数据层解决“懂业务”的问题指标引擎层负责“懂语言”。这一层接收业务人员输入的自然语言经过意图识别、实体抽取、条件解析、SQL生成四个步骤最终输出可执行的查询语句或API调用。意图识别这块我们最初纠结过用通用大模型还是垂直小模型。通用大模型的理解能力强但响应不稳定、token成本高、在金融场景下也不敢完全放权。最终采用的是“规则路由加语义模型”的混合方案常见问题先走模板匹配比如“XX指标近X个月趋势”这种高频句式直接映射固定查询复杂问题走语义模型解析出指标、时间范围、维度、过滤条件再动态生成SQL。我举个例子。问题是“最近三个月不同渠道的件均放款额怎么变化”指标引擎会拆解成指标件均放款额等于放款总额/放款笔数时间最近三个月按月分组维度渠道过滤条件无生成SQL的大致逻辑是SELECT month, 渠道, SUM(放款金额) / COUNT(借款编号) AS 件均放款额 FROM fact_loan WHERE month DATE_SUB(CURRENT_DATE(), INTERVAL 3 MONTH) GROUP BY month, 渠道 ORDER BY month, 渠道这个SQL只是示意实际上需要在元数据层做一层安全改写比如强制加上机构过滤条件、限制查询行数、防止全表扫描。这些逻辑都收敛在指标引擎层业务侧是无感的。调试过程中最容易出问题的是用户问话里带着隐含条件。比如“新户的件均放款额”和“件均放款额”是两个完全不同的指标前者需要关联客户表过滤首借标志后者不需要。所以我们在指标引擎里做了“实体消歧”模块当用户提到“新户、老户、首借、复借”这类词时自动识别并追加过滤条件避免取数错误。2.3 分析决策层从回答“是什么”到回答“怎么办”如果系统只做到查询和展示那它充其量是个智能报表工具还算不上风控大脑。DataQA 真正拉开差距的地方是在分析决策层做了三件事自动归因、异常预警、策略模拟。自动归因的逻辑听上去玄落地其实相对朴素。系统检测到某个核心指标出现显著波动时自动下钻到贡献度最高的维度尝试解释变化来源。比如“逾期率上升”这个现象系统会自动化拆解按渠道拆分哪个渠道的逾期率环比上升幅度最大按产品拆分哪个产品贡献了主要的逾期增长按客群拆分新增客群和存量客群的逾期表现差异再把结果组装成一句人话“本月逾期率4.2%较上月上升0.6个百分点主要受X渠道件均额度提升影响该渠道逾期率环比上升1.8个百分点贡献了整体上升幅度的62%。”这个能力说穿了就是“预置了下钻路径的自动化分析”但它的体验价值是巨大的。业务人员不需要自己一层层去点报表系统把“数据侦探”的工作先做了一遍。我们在做这个功能时刻意没有追求100%准确的归因因为风险变化本来就是多因素共同作用的结果能给到60%的确定性线索再靠人工判断效率已经比纯手工分析高很多。异常预警则是对关键指标设置阈值和监控频率比如逾期率日环比超过10%触发提醒、通过率周同比低于预设目标触发预警。预警消息会直接推送到企业微信或者钉钉群点开就能看到系统生成的简要分析。这种主动服务比“用户来问”更进一步也是留住黏性的关键。策略模拟是我个人最看重的模块。比如风控人员想评估“把某评分卡的拒绝阈值从600分提高到620分会怎么样”系统直接从历史进件里做模拟计算输出调整后对通过率、放款量、预期逾期率的影响估计。这一步相当于把策略实验室搬进了问答对话里。它依赖的是离线计算框架不是实时跑数所以在准确性和响应速度上做了平衡秒级返回初步估计详细报告异步生成。2.4 权限与审计金融场景绕不开的安全底线小贷行业的经营数据高度敏感客户手机号、身份证号、还款记录、逾期信息统统在里面。所以 DataQA 从设计第一天就把权限管理当成一等公民而不是事后补丁。我们设计了“数据域加数据行级权限”双重控制。数据域控制的是“能看什么表”比如催收团队能看贷后表但看不到审批策略明细行级权限控制的是“能看哪些机构、哪些产品线、哪些客群”。在指标引擎生成SQL的时候系统会自动注入权限条件试图绕过权限的提问会被拦截并记录。审计日志也是强需求。谁在什么时间问了什么问题、系统返回了什么结果、结果有没有被导出这些全都有留存。这一点在金融监管趋严的背景下尤其重要检查的时候不是听你讲管理流程而是直接看你在系统里怎么控制的。另外还有一个容易被忽视的点导出管控。问答结果再准确落到Excel满天飞也是风险。我们的做法是敏感指标禁止直接导出必须脱敏或者走审批流程非敏感指标导出时强制增加水印包含操作人标识一旦泄露可以溯源。虽然增加了一点操作步骤但业务部门都能理解毕竟金融行业的底线不是效率而是安全。3. 实战把小贷公司的风控问答跑通3.1 接入前的数据准备理论讲完说说真实项目里怎么落地。我们在某家区域性小贷公司的实施过程可以作为参考。这家公司有自营信贷产品和一条助贷合作渠道存量客户几十万日新增进件量不大但数据来源很杂核心系统一套库、催收系统一套库、合作的征信数据是接口推送没有统一的数仓。第一步不是写代码而是做数据盘点。我们花了第一周时间把核心表结构、字段含义、更新频率梳理清楚产出了一份数据地图。第二步是搭基础的数仓分层也不需要搞大而全的架构就做了两层一层是ODS贴源层把各系统的数据原样同步过来一层是DWD明细层做清洗、去重、标准化。最后在DWD之上建了一套DWS汇总表专门服务高频问答场景。摘要一下首批接入的核心表大概有六类客户信息表客户ID、年龄、性别、地区、职业、首次借款时间进件审批表申请时间、渠道、产品、额度、利率、审批结果、拒绝原因放款表放款日期、金额、期限、还款方式还款计划表应还日期、应还金额、期次还款流水表实还日期、实还金额、逾期天数贷后催收表催收次数、最近催收日期、承诺还款日这些表建好之后我们才在元数据层配置指标口径。这个过程切忌一上来就追求面面俱到先把业务最关注的十个核心指标配置完让系统能回答第一批问题跑起来之后再做扩展。3.2 常用风控问答场景演示与返回逻辑系统上线后我们整理了一批高频场景这里挑几个有代表性的展示。第一个是贷后监控类提问“昨天全量客户的M1逾期率是多少和前天比怎么样”系统返回结果时除了给出数值还会自动补充一句“M1逾期率上升0.15个百分点主要原因是周四到期量较高导致分母暂时放大预计后天回落”。这个补充判断来自规则引擎逻辑是分母到期客户数波动导致的被动上升。第二个是策略分析类提问“本月不同额度区间的新客首逾率对比如何”这类问题会自动关联客户表、放款表和还款计划表按额度区间分组计算首逾率。我们在返回结果时还会附带一个简单的显著性提示比如“10万以上额度区间样本量较小结论仅供参考”。这个小细节很受风控同事欢迎避免他们拿着不稳定数据直接做判断。第三个是渠道对比类提问“A渠道和B渠道的通过率差异主要受哪些因素影响”系统先算出两个渠道的通过率差异然后做特征维度下钻年龄分布、收入分布、申请金额分布、命中规则分布。最终返回结果时以文字加表格的形式说清楚差异来源比如A渠道通过率低主要是因为高龄客群占比高且该客群命中多头借贷规则比例较大。第四个是预测类提问“按照当前日均放款量预计本月末新增贷款余额是多少”这类问题走的是时间序列推算简单的用日均乘以剩余天数复杂一点的会叠加季节性系数。我们不会把预测结果描述成确定事实而是给出一个置信区间并注明推算逻辑。这个共识是在踩了一次坑之后建立的具体后面会讲。3.3 从问答到策略动作的闭环设计问答系统做得再好如果只停留在“问问看”的层面价值会大打折扣。我们在设计时把问答结果跟策略动作连成了闭环。举个例子。业务方提问“近两周通过率连续下降是什么原因”系统归因发现主要是一个合作渠道的进件结构发生了变化高评分的优质客群占比下滑。这时候问答结果旁边会直接挂一个“查看建议动作”按钮点击展开两个选项一是下调该渠道的通过率底线阈值以稳定资产质量二是调整渠道进件规则引导更多优质客群。点选之后系统会生成一个策略变更草稿推送给风控负责人审批审批通过后由策略引擎自动或半自动执行。这种闭环设计有几个好处。第一缩短了“发现问题到解决问题”的路径不需要从分析系统跳到策略配置系统再跳到审批流程。第二策略变更的前后效果可以自动追踪系统会在执行后按预设周期生成效果回看报告回答“调整之后怎么样了”。第三所有的洞察、决策、动作都有完整记录这对后续监管审计和策略复盘都是极大的加分项。当然闭环不意味着完全自动决策。金融业务的容错率低我们把自动执行的范围限制在“非关键的参数微调”上比如催收触达频次、营销活动的客群圈选而涉及授信审批核心环节的策略变更必须人工审批。这个边界定下来之后团队对系统的信任度才真正建立起来。4. 踩坑实录与调优笔记4.1 口径不一致问同一个指标不同部门给不同数这个坑几乎是所有数据类项目都会遇到的我们也不例外。系统刚上线测试时业务同事提问“本月的通过率”系统按照标准口径返回了数字结果负责运营的同事说“我们平时看的是另外一版数”两边差了快两个百分点。一排查发现运营口径的分子是“通过并放款的客户”分母是“进件客户”风控口径的分子是“审批通过的客户”分母也是“进件客户”。通过但未放款的那部分客户就是差异来源。这个问题不是技术能单独解决的必须在组织层面拉齐。我们当时的处理方式是把指标口径差异显性化在问答结果上标注“当前指标口径为审批通过率如需按放款口径查看请切换”。同时推动两个部门重新梳理了指标定义最终形成了公司级指标字典从此以后财务用一套数、风控用一套数、运营用一套数的混乱局面才逐渐收敛。给同行的建议是不要试图用一个技术系统强行统一业务口径这不现实。系统能做的是让不同口径的差异可见、可解释、可追溯让人为选择口径变得严肃——因为每一次查询都会被审计。4.2 语义歧义技术能解决一部分产品规则兜底更重要自然语言天生有歧义这在金融风控场景下会被放大。比如用户问“近三个月新客通过率”这个“新客”到底指的是“三个月内首次申请的人”还是“三个月内首次借款成功的人”差一个环节指标结果就完全不同。还比如“件均额度”是按放款笔数算还是按放款客户数算多人提问场景下理解不一致会导致结论完全相反。我们的经验是三层兜底。第一层在指标引擎里把常用歧义词做成规则模板自动选择业务默认含义比如“新客”默认取“首次借款成功客户”。第二层当系统检测到用户提法可能对应多个指标时不猜直接请求澄清“您问的新客通过率是指首次申请客群的通过率还是首次借款客群的通过率”这个多一次的交互成本换来准确率的明显提升。第三层在返回结果上展示计算口径说明用户可点击查看详细定义。语义歧义不可能100%消除所以系统要设计成“知道自己在不确定时保持谨慎”的模式。比起盲目给出一个可能错误的数字主动追问反而更能赢得业务信任。4.3 查询性能与稳定性不要让问答卡死生产库问答系统最大的技术风险就是业务随便问一句背后却生成了一个扫描全表的慢查询把生产数据库资源吃满。我们早期就出过一次事故。某同事问“近两年所有客户的分期还款记录中各渠道表现如何”这个查询直接扫描了上亿行明细表监控系统告警时数据库CPU已经飙升到90%多差点影响线上进件。这次事故之后我们立了几条铁律问答系统的查询只能走只读从库绝对不能碰生产主库。所有查询默认带时间范围限制近一年的数据必须单独确认才能查。查询超时时间限制在10秒超过则自动熔断并提示用户缩小范围。高频热点问题预计算结果直接查DWS汇总表不需要跑明细。性能调优最有效的手段不是靠数据库优化技巧而是把80%的高频问题提前识别出来做成预聚合结果。用户问“昨天逾期率”系统不是现场去算而是查前一天跑好的指标结果表。这样既保证了速度又降低了对底层数仓的压力。实时计算只有碰到真正需要明细下钻的开放性问题时才动用而这类问题在业务里占比其实不高。4.4 模型迭代问答系统自己的“风控”也不能少DataQA 本质上是AI系统AI系统就需要持续评测和迭代。我们建了一个“问答对测试集”选取历史上业务真实提过的300个问题标记标准答案和接受范围。每次模型或规则调整之后都要跑一遍回归测试保证A问题的修复不会导致B问题退化。评测集不是建完就不动的。新业务上线、新指标加入之后我们会把新出现的提问补充到测试集里。从上线到现在这个测试集已经扩展到了500多条覆盖了信贷审批、贷后管理、财务分析、监管报送等各个场景。迭代节奏基本是两周一个版本每次发布前过一遍回归。还有一个容易被忽略的点问答系统的回答质量本身要纳入风控。我们曾经遇到一种情况系统对某个指标的历史趋势理解错了返回了一个误导性结论差点让业务部门做出错误调整。从那之后凡是涉及“归因、预测、建议”类输出系统默认附带风险提示比如“该归因基于有限维度的自动下钻建议结合人工分析验证”。这种防御性表述虽然看起来保守但在金融场景里是必要的宁可少一分“聪明”也要多一分可靠。最后说点体会从最初的数据取数工具一路演进到现在的智能风控大脑这个项目让我最大的收获是AI在金融领域的价值不只是模型多准确更在于它能不能嵌入到日常决策流里让每一个环节的人都能更快、更准地得到自己需要的信息。我在实际使用中发现业务同事对一个问答系统的信任往往不是来自某次神奇的回答而是来自每一个普通问题都稳定、口径一致、能解释来源。这种信任一旦建立大家就会主动把更多问题抛过来系统也就在不断使用中变得越来越聪明。如果你也在做类似的风控数据产品我的建议很简单先别追求大而全的智能把元数据做扎实把高频问题跑稳把权限和审计做好再慢慢叠加归因、预测和策略闭环。等哪天业务方开始习惯“先问一下系统”而不是“先发邮件提数”这套系统就算真的长在业务里了。