金融行业如何大规模构建上下文智能：从架构到实战

做了好几年金融数据相关的工作，我最大的体会是：金融行业从来不缺数据，缺的是把数据快速变成“决策上下文”的能力。所谓上下文智能，简单说就是把一个决策发生时周边的所有相关信息——用户的行为轨迹、资金流向、设备环境、市场状态、历史交互——实时组合起来，让模型和规则引擎在一个更完整的场景里做判断。它不是某一个算法，而是一套从数据采集到特征加工再到决策服务的系统工程。这篇文章我会围绕“金融服务公司如何大规模构建上下文智能”这个题目，讲讲我在实际项目中沉淀下来的架构思路、关键选型和踩坑记录，适合正在做风控、反欺诈、智能客服或者数据平台建设的朋友参考。

1. 上下文智能到底解决什么问题

1.1 从业务场景看“上下文”的真实价值

很多人一听到上下文智能，第一反应是对话机器人要理解聊天记录，这当然对，但金融场景里的上下文要宽得多。

我举一个实际遇到过的场景。某消费金融产品在做线上借款审批时，传统模型只盯着征信分、收入流水和申请资料，结果一段时间里坏账率不稳定。后来接入上下文智能后，我们把用户的申请行为序列、设备切换记录、操作时间分布、资金用途描述、历史借款还款节奏都拼起来，发现了一批很典型的风险信号：某用户刚刚在深夜用一台新设备登录，输入资料速度比人工打字快很多，且描述的资金用途和过去三个月流水方向完全不一致，这些信号叠加起来，风险分数一下就拉高了。这就是上下文的增量价值——征信和流水是静态的，但“这个人今天是怎么来申请这笔钱的”是动态的。

再比如反欺诈场景。欺诈团伙最典型的特征是“行为上下文断裂”：设备是新换的、IP归属地和申请地区不匹配、申请时间分布异常集中、关联账户之间存在异常的资金往来。这些信息任何一个单独拿出来都不够判死刑，但组合在一起，就是高置信风险信号。上下文智能在这里干的活，就是把散落在交易、登录、设备、网络等多个域的事件，按时间轴和关系图组织起来，让风险识别有了“全景视角”。

智能客服、财富管理推送也是类似逻辑。用户刚刚查完某只基金的历史收益，客服如果还在推荐固收产品，就会显得很蠢；如果系统能记住“用户当前正在研究高风险产品，且近期有过三次风险测评未通过”，推送逻辑就能立刻调到合适档位。这就是上下文在用户体验上的价值。

1.2 为什么必须是“大规模”

如果只是给一个模型多喂几个特征，那叫特征工程，不叫大规模构建上下文智能。大规模意味着几个维度的量变：

一是数据规模。金融公司每天的日志事件以亿为单位，交易流水、App行为、渠道访问、客服通话、行情数据，全部要进入上下文体系。没有统一管道，数据就是孤岛。

二是特征广度。我见过比较成熟的金融风控上下文体系，接入的特征维度超过两千个，覆盖用户身份、设备、网络、地理位置、行为节奏、资金关系、历史营销交互等多个域。不是两百个，是两千个。

三是决策实时性。信贷审批要秒级返回，支付风控要在交易过程中实时拦截，客服机器人的理解延迟不能超过几百毫秒。这决定了上下文不能靠离线脚本算好再批量查到，必须有一套在线查询和实时更新体系。

四是模型数量和业务线覆盖。一家综合金融集团，消费信贷、信用卡、财富管理、保险理赔各条线都有自己的决策需求，每一条线都要从同一套上下文底座里取数据。重复造轮子是绝对不可接受的。

所以“大规模构建”的本质，是把上下文能力建设成一个平台级的基础设施，而不是做一个项目或者几个模型。

1.3 技术本质：从特征工程到上下文编排

我自己的理解，上下文智能的技术本质可以拆成三层。

第一层是感知层，解决的是“数据能不能拿到”。要把散落在核心系统、APP埋点、第三方数据源里的事件实时采集起来，统一成标准格式。第二层是组织层，解决的是“上下文怎么存”。事件是流的，但决策时我们需要的是主题化的上下文视图——一个用户的画像、一笔交易的关联关系、一台设备的信誉度。这需要把实时事件加工成可查询、可更新的特征和关系图谱。第三层是应用层，解决的是“怎么用起来”。规则引擎、风险模型、推荐算法、对话系统都要能从同一套服务接口拿到上下文，并且要保证拿到的数据和训练时看到的数据是一致的。

这套逻辑值得每个打算做上下文智能的团队先想清楚。因为很多项目失败，不是模型不行，而是感知层没打通、组织层结构混乱、应用层各自为政。

2. 整体架构与关键选型

2.1 分层架构怎么搭

我参与过几次从零到一搭建上下文智能平台的经历，最后沉淀下来的架构是四层：数据接入层、上下文存储层、计算决策层、统一服务层。

数据接入层负责连接各类数据源。业务数据库的变更通过CDC接入，APP行为通过埋点SDK上报，交易系统通过MQ广播事件，外部数据商通过API回调。这一层最怕的是数据源口径混乱，所以我一般要求团队建立严格的事件Schema管理，所有事件必须走统一的协议，宁可前期多花时间定规范，也不要后面每个业务部门各传各的。

上下文存储层是核心。这里我会放三类存储：特征存储，用来存用户、设备、法人等实体的实时画像和标签；关系图谱，用来存账户之间、用户与设备之间的关联关系；事件明细仓库，用来做历史回溯和二次加工。特征存储我一般用高并发读写的在线存储，关系图谱用图数据库，事件仓库用列式存储。

计算决策层包括实时计算引擎、规则引擎和模型推理服务。实时计算引擎处理流式事件，做窗口聚合和特征更新；规则引擎负责可解释的硬规则；模型推理服务承载评分模型和深度学习模型，响应线上请求。

统一服务层是整个平台的出口。它封装一个统一的上下文查询API，对外屏蔽底层存储差异。业务方只需要调用一句话，就能拿到某个用户ID、设备ID或订单ID的完整上下文视图。

这里我想特别强调一个容易被忽视的点：统一上下文API的字段文科要精心设计。我见过不少团队，接口字段跟着底层表结构走，底层表加了一列，接口就要变。我的建议是API返回的是语义化的上下文包，是“用户本次借款申请相关的风险信号列表”，而不是“t_user_risk_score这个字段的值”。

2.2 为什么优先建特征平台而不是逐个建模

这个问题我几乎在每个项目评审会上都会被问到。业务方说得很直接：“我们团队自己从库里拉几个字段就能建模，为什么要用你们的特征平台？”

原因有三个，都是我在实战中撞了墙才知道的。

第一是特征复用。一家公司里面，做审批模型的团队需要“用户90天内的总借款笔数”，做额度模型的团队也需要，做贷后预警的还需要。如果每个团队自己拉数据、自己加工，同一个口径会算出三个不同的结果，而且谁也不知道哪个是对的。特征平台把口径统一了，一次加工，处处使用。

第二是线上线下一致性。这是最容易出大事故的点。很多模型训练时用的是离线脚本跑出来的特征，上线服务时又让业务系统现场算一遍特征，两个管道很容易出现细微差异，比如离线用了当天全量数据，在线只用了截至请求时刻的数据，模型效果就崩了。特征平台用同一套加工逻辑覆盖离线和在线两条链路，能从根本上避免这个问题。

第三是治理和血缘。金融行业监管严，监管问下来“你这个分数是怎么算出来的”，如果没有特征血缘，连排查都要查半天，更别提解释了。平台化的特征管理，让每一个特征都有明确的定义、版本、负责人和加工逻辑。

所以我的结论非常明确：任何强调“大规模”的上下文智能项目，都应该先建特征平台，而不是先堆模型。

2.3 关键技术与存储选型经验

选型这件事，没有银弹，只有权衡。我把几个关键组件的情况列出来，都是我实际用过的思路。

选型上我有一条核心原则：在金融公司里，稳定性和可维护性永远优先于技术新鲜度。团队如果对某个新技术没有两年以上的维护信心，就不要为了追求先进去引入。上下文智能的核心不是用多牛的组件，而是把组件的协作关系理清楚。

3. 上下文生产与在线推理的实操细节

3.1 实时上下文管道怎么搭

这一节直接给实操方案。假设我们要为线上信贷审批构建“用户实时申请上下文”，管道大致分四步。

第一步，接入事件。通过APP埋点和网关日志采集用户关键行为：进入借款页、勾选协议、填写资料、提交申请、跳转结果页，每一类行为都要带时间戳、用户ID、设备ID、Session ID。这些字段一个都不能少，少了后面做行为序列分析就没法做。

第二步，清洗与归一化。把不同来源的日志统一成标准事件格式，做完格式校验和字段补齐。这里特别要处理的是数据漂移问题：埋点版本升级可能导致字段含义变化，必须有一套版本兼容机制。

第三步，实时聚合与特征更新。这一步我用Flink做，伪代码大致是这样的：

DataStream<Event> eventStream = kafkaSource.getStream(); eventStream .keyBy(e -> e.getUserId()) .window(SlidingEventTimeWindows.of(Time.minutes(30), Time.minutes(1))) .aggregate(new RiskBehaviorAggregator()) .map(new FeatureUpdater("user_latest_risk_stat"));

这段逻辑做的事情是：按用户ID分组，每30分钟窗口内统计行为次数、深夜操作占比、资料修改频率等风险指标，每分钟滑动输出一次，最后把结果更新到特征库。

第四步，在线查询时拼接上下文。用户点提交申请的那一刻，服务端调用统一上下文API，传入用户ID、设备ID、订单ID，API返回的数据包至少包括以下内容：

• 用户静态画像（历史额度、在贷余额、早期逾期次数）
• 实时行为特征（本次申请耗时、输入抖动率、设备切换记录）
• 关系上下文（关联设备数、关联账户风险分）
• 时序上下文（近7天访问频次分布，本次是否在异常时间段）

这些数据拼在一起，就是一个相对完整的上下文视图，模型拿去做推理，比只看静态表要准得多。

3.2 在线推理的关键参数与计算过程

上下文质量好不好，通常要盯几个关键参数，这是我在实际运维里总结出来的。

第一是特征新鲜度。实时特征从事件发生到写入特征库，链路延迟要控制在秒级。我们内部一般规定，风控场景的实时特征新鲜度P95必须小于3秒，如果超过这个值，实时特征的意义就打折扣了。

第二是上下文有效期。很多金融决策里的上下文不是永久有效的，比如“用户登录设备发生变化”这个特征，如果登录发生在三个月前，对今天的借款申请意义就很有限。所以每个时间敏感特征都要配TTL（有效期），过期自动失效。这个工作在别人看来是小事，但我建议团队专门排人力来维护，因为TTL设得太短会丢失有效信号，设得太长又会引入噪声。

第三是优先级与计算成本。实时计算每秒处理的事件量是有限的，不同特征的颗粒度不一样，成本也差很多。我的经验是把特征分成三个等级：核心决策特征（比如申请打分必用的行为特征）走全量实时计算；重要辅助特征（比如营销触发类特征）走批量计算加小时级更新；探索性质特征（比如实验中的新信号）走离线计算。这样既控制了成本，也不牺牲核心决策质量。

举个例子，一个信贷审批请求进来，模型需要三个信号：用户历史逾期次数、最近30天申请次数、本次申请的设备风险分。这里第一个特征是低频静态的，从特征存储直接读；第二个特征是高频更新的，靠实时管道维护；第三个特征是事件触发的，需要实时计算设备维度聚合。整个推理链路的目标是把全部特征取齐到模型打分的时间控制在100毫秒以内。

3.3 模型监控与上下文质量保障

上下文智能平台上线之后，最怕的不是模型不准，而是上下文悄悄变脏了。我见过的最隐蔽问题是特征覆盖率下降。某一天某个上游数据源停止更新，实时管道还在正常运行，但相关特征的所有取值都变成了空值。模型不会报错，只是默默地在用残缺的上下文做决策。等发现时，已经影响了好几天的审批结果。

所以我强烈建议做一个上下文质量监控看板，重点盯四类指标：

另外，灰度发布策略也很重要。上下文智能涉及的模型和特征改动，不可能一下就全量上线。我的做法是影子模式先行：新特征先同步进决策链路，但不对最终决策生效；跑一段时间对比新旧特征下的分数分布和业务结果分布，确认没有明显偏差后再切换决策。

4. 合规、治理与组织推进

4.1 金融场景的特殊约束

上下文智能在金融领域会撞上比其他行业更硬的墙，这是必须提前想清楚的。

第一是数据最小化。上下文看起来很强大，但不是什么数据都能拿。用户的行踪轨迹、通讯录关系、部分生物特征，在金融场景里是受严格限制的。设计特征体系时，必须先过合规评审，明确哪些信息可以采集、哪些必须脱敏、哪些只能用掩码结果。

第二是留存期限。金融数据的保存期限有明确要求，太久了不行，太短了也不行。我们做特征存储时，需要给每个特征打上留存标签，到了期限就自动清理或者做聚合处理。曾经有一个项目因为忘了给特征设置留存策略，被合规部门要求临时下线整个服务做整改，教训很深刻。

第三是用户授权链路。拿用户的某个数据来构建上下文，需要在用户协议和授权书中写清楚用途。这里要特别注意“用途跨越”的问题——用户授权时同意的是借贷审批，如果拿这个上下文里的信息去做营销投放，就是违规。

4.2 可解释性与模型治理

金融模型的可解释性不是可选项，是必选项。应用到信贷、定价、保险核保等环节的模型，按监管要求必须能向用户解释“为什么被拒绝”“为什么是这个价格”。上下文智能模型因为用的特征多、链路长，解释起来更难，所以更要把治理做在前面。

我的建议是：每一个进入决策链路的特征都要有解释文理科，说明这个特征的创建目的、数值含义、验证结论。线上模型每次推理都要保存上下文快照，这个快照是决策审计的证据。一旦出现投诉或者监管问询，要能快速还原“用户在那一刻看到了什么上下文、模型给了什么结论、理由是什么”。

特征血缘和模型版本管理也要体系化。一个特征改了加工逻辑，哪些模型受影响，必须能在血缘系统里查清楚。这个能力平时感觉不到价值，出了事故才知道多重要。

4.3 跨团队协作模式

建设上下文智能平台，不是数据团队一个部门能完成的事。我见过最顺的项目，参与方包括数据工程、算法、业务策略、风险合规、法务、APP客户端研发，任何一个环节缺位都会出问题。

我的建议是成立一个虚拟的上下文智能专项小组，把各方的接口人固定下来。数据工程负责管道和平台稳定；算法负责特征与模型效果；业务策略负责决策逻辑和业务闭环验证；风险合规负责数据权限和解释性审查；客户端研发负责埋点和数据采集质量。每周至少有一个小时的固定同步，专门对上下文特征新增、口径调整、数据源变更进行决策。

还有一个容易被忽略的角色是“上下文产品经理”，这个人不一定有专门编制，但必须有人承担。他的职责是把业务需求翻译成上下文技术需求，比如业务说“我们要拦截异常申请的团伙”，他要能拆解出需要哪些关系图谱查询、哪些实时特征、哪些模型输入，并且能评估数据成本。

5. 常见问题与排查实录

5.1 线上线下特征不一致

这个问题的典型表现是：模型在离线评测时AUC表现很好，一上线通过率突然暴跌。排查后发现，训练时用的“近30天申请次数”是离线批处理算好的，覆盖了截止到昨天全天的数据；但在线推理时，同一个特征是从特征库读取的，而特征库的更新有延迟，导致在线拿到的只是最近10分钟的新事件数。两边口径完全不一致。

解决方案是把特征加工逻辑收敛到同一套代码。离线训练、在线推理、离线回溯三个环节必须调用相同的特征函数，并且测试案例要覆盖边界情况，比如空值、极端值、数据源中断。

5.2 实时特征延迟

有一段时间线上审批服务的特征延迟P95从3秒涨到了20秒，排查原因是消息队列消费组的并发度不够，上游在业务高峰期流量翻倍，一下子堆积了上亿条事件。

定位过程分两步：先看队列堆积指标，确认是消费端处理能力不足；再看具体算子耗时，发现某个窗口聚合函数在数据量大时触发了频繁的状态备份，性能退化严重。后来把状态后端改为增量Checkpoint，再把消费并发从8调到了24，延迟回归正常。

5.3 上下文错配与串线

共享设备和Session串线是金融场景里极容易出问题的点。一台门店的公用设备，几十个客户都会登录，如果上下文平台用设备ID关联所有用户的历史行为，风险特征马上就污染了。

处理方案分两端：数据端要把“设备-用户绑定强度”作为一个特征建模，绑定时长越长、绑定越稳定，设备数据才越可信；决策端则引入登录态和Session判断，避免把同一物理设备上不同用户的行为串成一条上下文。

5.4 上下文成本膨胀

随着特征越来越多，实时计算和存储成本会一路飙升。我见过一个平台上线一年后，特征从800个膨胀到2000个，其中超过30%的特征在近90天没有被任何业务方查询过。

治理办法是定期的特征下线机制。平台会统计每个特征的查询频率和业务归属，连续一个季度零查询、且有替代特征的特征，全部列入下线清单。同时上线新特征时，要求申请方给出预期业务价值和成本预算，倒逼业务方认真对待每一次特征新增。

结合我自己的经验，还有一个小建议：宁可把特征做得少而精，也不要贪多。保持一套“高质量核心特征+适量辅助特征+极少量探索特征”的结构，无论从效果还是成本角度，都是最稳妥的。

这个方向后续还可以延展一些有意思的能力，比如把用户旅程上下文和大模型结合，让客服能够基于完整上下文给出更有温度的解释；或者把跨业务线的上下文共享机制做得更细，让信贷、理财、保险之间形成更聪明的联动。上下文智能的建设是长期的，但它带来的回报也在持续放大。