金融大模型落地：用户运营与决策分析的边界、落点与工程化

金融行业做用户运营和决策分析的同行，大概都经历过同一种拧巴：业务方上午提一个分层名单的需求，数据分析师排期排到两周后，等名单出来，活动窗口已经过了；月度经营分析会前三天，一堆人对着十几张报表手工扒数、写结论，写完了还要被追问“这个下滑到底是哪个人群贡献的”。大模型这两年被反复提及能在这类场景里提效，但真正落地过的团队会发现，能提效的部分和宣传里说的往往不是同一块。我所在的团队过去一年多一直在把大模型往用户运营和决策分析这两条链路上塞，踩过的坑比跑通的场景多，下面把这些经验摊开讲讲，包括哪些活能放心交给模型、哪些活交出去就是给自己挖坑、以及那些看起来不起眼但回报最高的落点在哪。

1. 金融用户运营里，大模型真正能接手和必须绕开的活

先把话说死：不是所有环节都适合上模型。团队最开始犯的错，是把“提效”理解成“全流程自动化”，结果做了一个端到端的智能运营助手，输入一句“帮我提升信用卡分期渗透率”，指望它吐出完整方案。跑出来的东西看着挺像那么回事，细看全是正确的废话。后来我们把任务拆开逐个评估，才摸清楚边界在哪。

1.1 一条实用的分界线：结果可验证还是不可验证

我判断一个任务能不能交给模型，只看一件事——输出结果能不能被低成本验证。能验证的，大胆交给模型，人来抽检；不能验证的，模型只能当草稿机，人必须全程在场。

按这个标准过一遍用户运营的常见任务：

这张表我们内部叫“分工卡”，新来的同学第一周就要背下来。它挡住的最大风险是：有人拿着模型生成的归因结论直接进了汇报材料，会上被业务方一句“这个结论和上个月的口径对不上”问穿，后面再推任何模型相关的项目都会被质疑。

1.2 三个被高估的场景，别在这上面浪费预算

第一个是“全自动策略生成”。金融产品的运营策略受限于产品规则、客群资质、渠道能力、预算约束，这些约束条件大部分存在于人的脑子里和零散的会议纪要里，模型拿不到。强行喂给它，它会用通用商业常识脑补出一套看似合理但完全落不了地的方案。我们试过让它给某款消费信贷产品设计新客激活策略，它给出的“首月免息 + 邀请返现”组合，前者产品压根没有这个权益，后者在预算上根本批不下来。

第二个是“直接对着原始明细做用户洞察”。把几百万行脱敏后的交易明细丢给模型让它找规律，除了烧钱没有任何收益。模型的强项是语言理解和结构化输出，不是在大表上做统计。这类活应该交给数仓和 BI 工具，模型只在结果出来之后介入解释环节。

第三个是“实时个性化推荐”。有人会想用大模型做千人千面的实时推荐。金融场景对响应延迟的要求通常在百毫秒级，而大模型的推理延迟和成本都撑不住这个量级。推荐该用传统的召回排序模型，大模型最多在离线阶段帮忙做特征解释或者文案生成。

1.3 三个低调但回报最高的落点

反过来看真正跑出效益的地方，反而不太“性感”。

落点一是口径问答。金融机构的指标口径混乱程度超出想象，“活跃用户”在三个部门有三套定义，新人问一次要打扰三个人。我们用一个检索增强的方案，把指标字典、字段说明、历史口径变更记录做成知识库，员工用自然语言提问，模型给出定义和出处。上线两个月，数据团队的重复答疑量掉了大概六成，这个收益比任何花哨的场景都实在。

落点二是取数环节的 SQL 初稿。分析师写一段中等复杂度的 SQL 平均二十分钟，其中大部分时间花在回忆表结构和字段名上。让模型基于表结构元数据生成初稿，分析师改一改就能用，实测节省的时间在三到五成之间，复杂的多表关联场景节省更明显。

落点三是运营文案的批量变体。一次活动要针对不同客群出十几版文案，人工写要一整天。模型基于模板和客群特征批量生成，人工只做审读和微调，这块的提效是最直观的。

2. 指标字典和标签体系：喂给模型之前必须先做的脏活

这一章是我最想强调的部分。很多团队上来就调提示词、选模型，跳过了数据侧的准备，最后效果不行就归因于“模型能力不够”。实际情况往往是，模型拿到的输入本身就是一锅粥。

2.1 口径不统一，模型只会把错误放大十倍

我们做过一次对照测试。同一个问题“上个月新增绑卡用户数是多少”，分别让模型基于两套不同的元数据去生成 SQL。第一套是原始的数仓表结构，字段名叫crd_bind_cnt、user_new_flag、stat_dt这类，没有任何注释；第二套是加过业务注释和口径说明的版本。结果第一套生成的 SQL 有七成跑出来的数和业务方认知对不上，第二套的准确率接近九成。

原因很朴素：字段名user_new_flag到底是“新注册”还是“新绑卡”，模型只能猜。它猜错了不会报错，会给你一个能跑通但含义错误的 SQL，这比直接报错危险得多。

所以做这件事的顺序应该是：先花两周把核心指标的元数据补齐，再动模型。补齐的内容包括：

• 字段的业务含义，一句话说清楚，别写“用户标识”这种等于没写的话
• 枚举值的含义映射，比如status字段的 1/2/3 分别代表什么
• 常用指标的加工逻辑，尤其是那些涉及去重、跨表关联、时间窗口的
• 历史口径变更记录，标明哪一年改过定义

2.2 给模型看的指标字典，和给人看的不是一回事

人看的指标字典通常是一份几十页的文档，带目录带版本号。直接塞给模型效果很差，因为检索的时候容易捞到不相关的段落。我们改造后的做法是一条指标一条记录，扁平化存储，每条包含：指标名、同义词（业务方口中的各种叫法）、口径定义、计算公式、依赖的表和字段、常见误用提示。

举个实际的例子，“月活跃用户”这条记录长这样：

{ "metric": "月活跃用户数", "aliases": ["MAU", "月活", "活跃用户数", "当月活跃"], "definition": "统计周期内发生过至少一次登录或交易行为的去重用户数", "formula": "COUNT(DISTINCT user_id) WHERE login_flag=1 OR trade_flag=1", "tables": ["dwd_user_active_di"], "note": "不含仅浏览未登录的访客；与'日活'不可直接相加求月活" }

那个note字段是关键。我们统计过，模型出错的高频原因里，跨周期指标不可加总这一类占了三成以上。把这类“常见误用”显式写进去，比在提示词里写十遍“请注意口径”都管用。

2.3 标签体系的语义化改造

用户运营离不开标签，但标签体系的混乱程度往往比指标更严重。一个“高价值客户”标签，可能是按资产规模算的，也可能是按贡献收入算的，还可能是按 AUM 加上持有产品数算的。模型不知道区别，业务方也经常搞混。

我们的做法是给每个标签补一段适用场景说明，明确写出“这个标签适合用在什么决策上，不适合用在什么决策上”。比如“高价值客户”标签会注明：适用于权益投放优先级排序，不适用于风险定价。这段说明同时服务两个对象——业务方看它避免用错，模型看它避免答错。

改造完之后还有一个额外收益：标签的重复建设明显减少了。以前不同团队各自建标签，改造过程中一梳理，发现三十多个标签里有十几个是重复或者高度重叠的，直接合并掉。

3. 用户分层与策略草稿：让模型做“翻译”而不是做“决策”

用户分层这件事，业内的主流做法还是规则分群加人工经验，模型很难替代。但模型在中间能承担一个很有价值的角色——把业务语言翻译成可执行的规则，把分析结果翻译成策略草稿。

3.1 分层逻辑为什么不能直接丢给模型

有人会想，既然模型懂业务，那就让它直接设计分层方案。这条路走不通，原因是分层本质上是资源分配决策，牵扯到预算、渠道容量、客群资质、风险偏好，这些约束模型拿不到。它设计出来的分层往往在数学上很漂亮，在业务上一塌糊涂。

正确的用法是反过来：人定分层框架，模型做规则转译和边界检查。业务方说“我想要一批近三个月有登录但没交易的客户，资产在五万以上，排除掉最近被投诉过的”，模型把这句自然语言转成结构化的筛选条件，同时提示“最近被投诉过”这个条件在现有标签体系里没有对应字段，需要确认口径。这后半句提示才是真正的价值所在，它把一个容易在两周后才暴露的问题提前到了当下。

3.2 用模型做规则转译的具体做法

我们在内部工具里做了一个分群条件解析器，输入是一段业务描述，输出是结构化的 JSON 条件树，附带一份“待确认项”清单。提示词的结构大致是：

你是用户分群条件解析器。请把用户描述的业务条件转成结构化条件树。 必须遵守： 1. 只使用下方标签清单中存在的标签，不存在的条件放入 unresolved 数组 2. 时间窗口必须明确起止，模糊表述（如"近期""最近"）默认取近30天并在 warnings 中标注 3. 互斥条件（如同时要求"新客"和"老客"）放入 conflicts 数组 4. 不要自行补充业务方未提及的筛选条件 可用标签清单： {tag_list}

这里最容易被忽略的是第 4 条。不加这条约束，模型会非常“热心”地帮你补充条件，比如你只说“高资产客户”，它自动加上“且近一年无逾期”。听起来很合理，但业务方的活动本来就是要唤醒有逾期记录但资产高的客户，这一加就把目标客群改掉了。这类“善意越权”在早期让我们出过好几次错，后来靠这条约束卡住了。

3.3 触达文案的批量生成与前置合规校验

文案生成是提效最明显的环节，但金融场景有它的特殊性——文案里不能有承诺收益、不能有误导性表述、不能出现绝对化用语。纯靠人审，量大之后必然漏。

我们的流水线是两段式的：第一段模型按客群特征批量生成文案变体，第二段用规则加模型做双重校验，把命中的风险点标出来。规则部分覆盖那些明确的禁用词和必带要素（比如风险提示语必须出现），模型部分负责判断语义层面的问题，比如“稳赚”“必过”这类虽然不在词表里但意思差不多的表述。

实测下来，纯规则的拦截率大概在七成，加上模型语义判断能到九成以上。剩下那一成还是得靠人，但人工从“逐条读”变成了“重点看被标记的”，工作量降了一个量级。

这里有个容易踩的坑：校验规则不要写得太死。早期我们把“最高”列进了禁用词，结果连“最高可借额度”这种正常表述都被拦了，误报率高到业务方直接弃用。后来改成按上下文判断，才把误报压下来。

4. 决策分析的三条链路：问数、归因、成稿

决策分析这块，我们拆成了三条相对独立的链路，分别对应分析工作的三个环节：拿数、找原因、写结论。三条链路的成熟度差别很大，落地策略也应该不一样。

4.1 自然语言问数：Text2SQL 在金融数仓里的真实命中率

先说结论：在指标明确、表单一的简单问题上，准确率可以做到很高；一旦涉及多表关联、窗口函数、复杂去重，准确率会断崖式下跌。我们内部统计过一个数据，单表查询的首次执行成功率在八成五左右，三表以上关联的首次成功率不到四成，五表以上基本没法用。

提高命中率的几个实际手段：

第一，把宽表用起来。与其让模型去关联五张表，不如提前建好面向分析场景的宽表，把常用维度都打进去。模型只需要在宽表上做筛选和聚合，复杂度直线下降。这个改造投入不小，但收益是持续的。

第二，给示例，并且给“错例”。少样本提示里放三到五个正确示例是常规做法，我们还额外放了两三个典型错误示例，标注出“这样写会漏掉退款订单”“这样写会把测试账号算进去”。加上错例之后，同类错误的复发率明显下降。

第三，执行前的静态校验。生成的 SQL 不直接跑，先过一遍校验：表名和字段名是否存在于元数据、是否有全表扫描风险、是否缺少时间分区条件。缺分区条件这条特别重要，有一次模型生成的查询没带分区，直接扫了全表，把当天的查询队列堵了半小时。

第四，结果的对数机制。关键指标的问数结果，自动和 BI 看板上的同口径数字做比对，偏差超过阈值就提示“结果可能与标准口径不一致”。这个机制救过我们好几次，因为模型生成的 SQL 语法完全正确、也能跑出数，但逻辑上少了一个过滤条件。

4.2 指标异动归因：把分析方法论写进提示词

归因是分析工作里最耗时的部分。一个指标下滑，分析师要做的是：拆维度、找贡献度最大的子群、排除数据问题、给出可能原因。这套方法论其实是标准化的，非常适合沉淀进提示词。

我们的做法是把归因拆成两步。第一步是结构化拆解，用程序完成，不经过模型——按预设的维度树（渠道、产品、客群、地域、时间）逐层计算贡献度，找出变化最大的几个子群。这一步是纯计算，模型不参与，保证结果可靠。

第二步是解释与假设，这一步交给模型。输入是拆解结果加上业务背景信息，输出是可能的原因假设和验证建议。提示词里会明确要求：区分“数据事实”和“推测假设”，推测部分必须给出验证方法。

举个实际输出的例子。某月分期交易额环比下降 12%，拆解发现主要来自某个渠道的新客群体。模型给出的输出是：

• 事实：该渠道新客分期交易额环比下降 34%，贡献了总降幅的 71%
• 事实：该渠道新客进件量环比持平，但授信通过率下降 8 个百分点
• 推测：可能是风控策略调整导致通过率下降（验证方式：调取该时段风控规则变更记录）
• 推测：可能是渠道端流量结构变化，低资质客群占比上升（验证方式：对比两期进件客群的资质分布）
• 建议排除项：同期该渠道无系统故障记录，可排除技术原因

这份输出的价值不在于它说对了，而在于它把分析师要查的东西列全了，而且分清了哪些是板上钉钉的、哪些是需要验证的。分析师顺着查，效率提升很明显。

4.3 经营分析报告的自动成稿与人工兜底

报告成稿这块，我们的定位始终是“生成初稿，人来定稿”。具体做法是给模型一个固定的报告骨架，每个章节填入对应的数据和分析结论，模型负责组织语言、补充过渡、生成图表说明文字。

有几个细节值得说。数字必须来自程序注入，不能让模型自己算。我们所有报告里的数字都是先用程序算好，以占位符的形式嵌入模板，模型只负责文字部分。早期试过让模型从明细里自己算汇总，出过一次把两个口径的数加在一起的事故，之后这条就变成了硬规则。

结论段落要限定长度和结构。不限定的话模型容易写出一大段四平八稳的套话。我们要求每个结论段落不超过三句话，第一句说现象，第二句说原因或假设，第三句说建议动作。限定之后，可读性提升非常明显。

留出人工改写的位置。报告模板里每个章节末尾都有一个“分析员补充”的空位，强制要求填写。这个设计一开始被吐槽是形式主义，但运行几个月后大家发现，这个空位实际上是在逼着人认真读一遍模型写的内容，避免直接复制粘贴。它起到了一个心理上的阻断作用。

5. 效果评估：怎么证明提效是真提效而不是自我感动

这块是最容易糊弄过去的。很多团队上线之后做个满意度调研，大家都说好用，然后就结项了。真到年底复盘要算 ROI 的时候，拿不出硬数据。

5.1 三类指标，缺一不可

我们最终定下来的评估体系是三层的：

效率层最容易做，也最容易虚高。比如文案生成耗时从 40 分钟降到 5 分钟，但如果人工审读和修改要花 25 分钟，实际节省只有 10 分钟。所以效率指标必须统计端到端耗时，不能只算模型那一段。

质量层的核心是首次采纳率——输出内容未经修改直接使用的比例。这个指标很残酷，但最能反映真实价值。我们的 SQL 生成首次采纳率大概在五成，文案生成在三成左右，指标问答能到七成。数字不好看，但它诚实地告诉我们应该往哪个方向优化。

5.2 人工基线怎么建，别拍脑袋

要说提效多少，得先知道不提效是多少。基线的建法有两种，我们都用过。

一种是回溯法，从历史工单或者任务记录里捞同类任务，统计人工耗时。好处是不打扰现行业务，坏处是历史记录往往不全，而且人工记录的时间普遍偏乐观。

另一种是并行对照法，同一批任务，一部分走人工，一部分走模型辅助，同时记录耗时。这种方法数据准，但会占用额外人力，只能在小样本上做。我们的做法是先做两周的并行对照，拿到靠谱基线，之后长期只用系统埋点做监控。

有个细节要注意：并行对照期间，做人工那一组的人会不自觉地加快速度，因为他们知道在被观察。这个效应在初期能把人工耗时压低两成左右，如果不校正，会得出“模型提效不明显”的错误结论。我们的处理方式是让两组人角色互换再测一轮，取平均。

5.3 灰度发布和 A/B 的坑

模型类应用的 A/B 测试和传统功能不一样，因为模型输出有随机性，同一个输入两次跑出来的结果可能不同。我们踩过的坑包括：

• 样本量估计不足。按传统功能的样本量算，结果跑了两周发现差异不显著。模型输出的方差大，需要的样本量比预想的多不少。
• 评估标准漂移。评估人员看多了模型输出，标准会不自觉地放松，导致后期样本的评分普遍偏高。解决办法是定期把早期样本混进去重评，做一致性校验。
• 版本混淆。测试期间模型供应商做了一次小版本更新，导致前后数据不可比。之后我们固定了模型版本号，任何变更都要重新走一遍基线。

6. 成本、延迟和工程化：那些上线之后才冒出来的问题

Demo 阶段没人关心成本，上线第一个月账单出来，所有人都安静了。这一章讲讲账怎么算、怎么省，以及版本管理上那些容易忽略的雷。

6.1 成本结构拆解，钱到底花在哪

我们第一个月的调用成本里，超过一半花在了三类低价值调用上：重复问同一个问题、超长上下文但只用到了开头一点信息、以及大量无意义的问候和试探性提问。

拆开看，单次调用的成本大致由输入 token、输出 token、以及上下文长度决定。金融场景的特点是输入远大于输出——指标字典、表结构、示例 SQL 这些东西很长，而生成的 SQL 或文案很短。所以优化的重点应该放在输入端。

具体手段有几个。一是上下文裁剪，不要把所有表结构都塞进去，先做一次表名检索，只把相关的几张表结构放进上下文。这一招把平均输入长度压掉了六成多。二是提示词压缩，把那些冗长的说明性文字改成结构化的规则条目，字数能减少一半，效果反而更好。三是结果缓存，口径类问答的重复率极高，同样的问法在两周内可能被问几十次，加一层语义缓存之后，重复调用量下降了四成。

6.2 分级路由：不是所有问题都值得用大模型

一个简单但极其有效的策略是分级路由。我们按任务复杂度把请求分成三档：

• 简单档：格式化、字段翻译、简单分类，用小模型或者规则处理
• 中等档：单表取数、文案生成、口径问答，用中等规模模型
• 复杂档：多表取数、归因解释、长文成稿，用大模型

刚开始我们没做分级，所有请求都走同一个大模型，成本高而且延迟长。加了路由之后，大约六成的请求被分流到前两档，整体成本降了一半以上，平均延迟也明显改善。路由的判断逻辑用的是简单的规则加一个小分类模型，判断错误率不高，偶尔误判的代价也就是多花点钱或者效果差一点，可以接受。

6.3 供应商换版本带来的静默回归

这个问题比较隐蔽，值得单独说。模型服务方的版本更新往往不会大张旗鼓通知，即使通知了，也常常写着“小幅优化”。但对我们的具体任务来说，影响可能是灾难性的。

有一次更新之后，我们发现在生成 SQL 时，模型开始倾向于使用 CTE（公用表表达式）而不是子查询。语法上没毛病，但我们的静态校验规则里有一条是“禁止三层以上嵌套”，CTE 没有被这条规则覆盖，导致一批复杂 SQL 绕过了校验直接执行。问题是在上线三天后才发现。

之后我们建了一套回归测试集，从历史任务里挑了 200 条有代表性的样本，每条都有人工确认过的标准答案，每次模型版本变更或者提示词调整，都跑一遍回归。这套机制现在是我们最依赖的保障手段，跑一次大概二十分钟，能挡住九成以上的静默回归。

补一句：回归测试集要定期更新。我们的做法是每个月从新增任务里挑十条加进去，同时淘汰掉那些已经被新业务淘汰的样本。测试集不更新的话，跑出来的分数会虚高，因为模型可能已经“见过”类似的题了。

体系建起来之后，我最深的体会是：模型能力决定了天花板，但决定你能不能摸到天花板的，是数据准备和工程配套这些完全不性感的部分。指标字典补齐、上下文裁剪、回归测试集，这三件事做与不做，效果差距比换一个更强的模型大得多。如果重来一次，我会先把这三样做扎实，再去谈场景。