语言模型如何赋能金融风控：从非结构化文本到结构化风险决策

语言模型和金融风险管理，这两个词放在一起，听起来像是又一篇技术趋势报告。但真做过的团队都明白，这句话背后不是搭个聊天机器人那么简单。它要回答的是两个非常硬的问题：哪些风险信号藏在非结构化文本里，以及怎么用语言模型把信号提取出来，变成能进风控决策系统的结构化证据。这篇文章把这套东西掰开揉碎讲，从任务拆解、方案选型、场景落地到流水线搭建和踩坑记录，适合正在做相关立项或POC的风控、数据工程师，也适合想了解这个交叉领域还能怎么落地的业务同学。

1. 为什么传统风控模型啃不动复杂风险评估

不是传统模型不好，而是它们处理的数据形态和复杂风险之间出现了断层。过去几年主流的信用评分模型、违约概率模型，吃的都是结构化表格——财务比率、历史还款行为、征信字段、抵质押物参数。这些字段确实能解释大部分常规风险，但一旦进入复杂场景，光靠几张表是不够的。

1.1 大量风险信号藏在非结构化文本里

我在项目里见过一个很典型的案例：某企业的财务报表上净利润是正的，资产负债率也还在合理区间，但授信报告的管理层讨论章节里写着“公司依赖单一供应商，该供应商近三个月多次出现延迟交货记录”。这条信息在结构化数据里完全看不出来，可它恰恰是影响还款能力的核心风险点。

信贷档案里占比最高的恰恰是这类非结构化信息：审计报告的附注、管理层对重大事项的说明、上下游合同的关键条款、法律诉讼的判决书摘要、舆情新闻里关于实控人的动态。它们的共同特点是：关键信息不靠数字表达，而是靠语言表达。而传统风控模型对语言几乎是无能为力的，只能靠人工去读、去判断、去摘录，这就带来了两个问题——效率低，而且每个人的判断尺度不一样。

结构化数据的优点是有统一口径、可计算、可回测。但它也意味着信息已经被“压缩过一轮”，很多过程性、情境性的风险在被压缩成数字的过程中丢失了。语言模型的价值恰恰在于，可以把文本里原本散落的信息重新结构化，让风控模型用得上。

1.2 从规则引擎到大模型的必然跃迁

早年间处理文本风险信号，靠的是关键词规则。比如在公告里匹配“诉讼”“被执行”“股权冻结”这些词，出现就触发预警。这套方案有效，但维护成本极其痛苦：词表要一直更新，语义变体防不胜防。我说“利润大幅下滑”，你说“本期经营成果不及预期”，再换一份报告写“受宏观环境影响，公司盈利能力显著走弱”，关键词规则逐字匹配很容易漏掉第二种和第三种说法，而人一眼就看出这三句话在说同一件事。

后来有团队用BERT这类预训练模型做文本分类和实体抽取，效果比规则好了不少，但本质上还是“句子分类器”和“词边界识别器”，它们不太擅长跨句推理和综合判断。比如“某公司控股股东将其持有的80%股权质押给XX信托，用于为关联企业融资提供担保”这句话，单个词看每个都是中性词，但组合在一起就是一个典型的风险传导链条，需要模型理解逻辑关系而不是单纯匹配词汇。

大语言模型带来的是另一种能力：它能在长上下文里做推理，能把分散的信息汇总成结论性的判断，能以稳定的格式输出结构化字段。它不需要你提前穷举每一种表达方式，只需要你定义清楚“我要什么”，它就能给出“答案在哪”以及“依据是什么”。这正是复杂金融风险评估最需要的——从“看见关键词”升级到“读懂语义”。

2. 方案选型：大模型不是唯一选项

听到“语言模型在金融风控中的应用”，很多团队第一反应是把财务数据全部丢给大模型，让它输出一个风险分。这其实是最大的理解偏差。大模型适合做的是理解和抽取，而不是拍脑袋打分。风险分应该有确定性的统计模型来做，语言模型只是在给这些模型喂更好的特征。把这条边界想清楚，方案选型就不会跑偏。

2.1 三条技术路线怎么选

我在实际推进过程中，一般会把可选的路线分成三种，各有各的适用前提。

第一种是直接调用通用大模型的API，把业务文档原样发过去，让它返回抽取结果。优点是落地速度快，可能一周之内就能跑出Demo，而且在任务复杂、规则不清的场景下，通用模型的表现往往比小模型好得多。但代价也很明显：调用成本随业务量线性增长，敏感数据出域的合规压力大，而且模型的幻觉责任完全不可控。一旦输出出错，你连模型参数都看不到，更别提优化了。

第二种是选择开源的底座模型做领域微调。优点非常直接：模型可以部署在自己的私有化环境里，数据不出域，推理成本可控，而且可以通过微调和数据筛选持续迭代。缺点是训练和评估本身需要专业团队，如果公司里没人做过模型微调，学习成本会拖慢项目节奏。

第三种是大小模型协同的级联架构。核心思路是：简单的字段抽取和规则判断交给小而快的模型，比如几亿参数的文本分类模型；复杂的语义理解和跨文本推理交给大模型；最后再用一个可解释的评分模型把大模型输出的结构化特征融合成风险评分。这样一个任务拆成三段，各取所长，成本也能压得住。

我接触的多个落地案例中，长期跑得稳的基本都是第三种路线。这里有一张对比表供参考：

2.2 我的选型思路

很多团队一开始就说要做微调，我不太建议。就算数据量很大，第一步永远是用API或者大模型快速验证效果——验证的是“这件事本身能否用语言模型做出来”。如果零样本效果就已经很好，说明任务对模型的语义理解要求没那么特殊，没必要一上来就投入昂贵的微调工程；如果效果不行，你也要先判断是“模型不懂这个任务”，还是“数据样本不给力”，这个判断必须用快速试验来获得，而不是直接假设。

反过来，如果零样本抽出来的质量不行，但你把几条典型样本写进Prompt，效果立刻变好，这通常意味着任务是可学的，只是需要知识注入。这个时候再启动微调，成本是花在刀刃上的。我自己一般用这个判断标准：提示词工程能解决的任务，绝不上微调；微调能解决的任务，绝不上全参数训练。每上一个档次的投入，都要有清晰的效果增量论证。

还有一点值得单独说：不是所有模块都用得上语言模型。比如抽取合同编号、营业执照号码这类格式高度固定的字段，正则表达式几行就能解决，没有必要让大模型参与。把任务难度分阶梯，用最便宜的方案解决最简单的问题，这是控制成本最有效的手段。

3. 四个能落地的核心场景拆解

场景不在多，在真实。下面这四个是我亲测或者近距离观察过、确实跑通了的数据链路。每个场景的任务复杂度不一样，但共同点是：语言模型输出的不是一个人看的结论，而是能被业务系统消费的结构化数据。

3.1 信贷审批中的文本因子抽取

授信审批阶段最耗人力的工作之一，是从一堆材料里把关键信息摘出来。信贷员的调查报告、上下游合同、实控人个人履历、保证合同，这些文本里的风险因子高度分散。传统做法是人工阅读后录入系统，效率低不说，漏录的风险一直存在。

语言模型在这个场景里能做一件事：按业务团队定好的字段清单，把文本变成JSON结构输出。比如从一篇授信报告里抽取对外担保情况、近两年涉诉记录、股权质押比例、关联交易金额，每个字段都要求模型给出来源原文，方便人工复核。

实操时要注意，抽取字段的定义一定来自业务方，不能是算法团队自己拍的。业务方说“我们要识别实控人是否存在大额对外担保”，你才能把这个抽象需求拆成具体的抽取规范：担保金额≥多少算大额、保证方式是哪几种、关联关系怎么判定。模型输出之前，先让业务确认字段清单，再让模型对齐，这个顺序不能反。

Prompt模板通常长这样：

{ "role": "信贷资料分析助手", "task": "抽取授信报告中的风险因子，只输出JSON，不要解释", "fields": [ {"name": "borrower_name", "desc": "借款人全称", "type": "string"}, {"name": "external_guarantee", "desc": "对外担保事项列表", "type": "array"}, {"name": "litigation_records", "desc": "涉诉记录列表", "type": "array"}, {"name": "pledge_ratio", "desc": "股权质押比例", "type": "number"} ], "constraint": "每个字段必须附带原文引用；如原文未提及，输出null" }

模型输出的缺口字段会进人工复核队列。这样做的直接收益是，原本一个审批团队一天处理几十份报告，现在可以先把重复性的摘录劳动交给模型，人工只需要检查置信度低的部分。注意，这是一个辅助系统，不是自动决策系统，边界必须划清楚。

3.2 企业违约预警的财务文本信号

财务预警这件事，只看数字报表经常不够。企业财务造假或者经营恶化，往往在文字里留下的痕迹比数字更早，也更诚实。审计报告里的“持续经营存在重大不确定性”这种表述，基本是明文风险信号；而“应收账款周转天数显著增加”“存货规模持续攀升且库龄结构偏老化”这类管理层讨论则要结合上下文和趋势判断。

语言模型在这个场景要做的是事件抽取加严重程度分级。你可以把所有历史财报和公告喂给模型，让它输出一段文字里隐含的风险事件类型，比如债务逾期、业绩变脸、资产减值、股权质押爆仓、非标意见，并按无风险、提示性风险、实质性风险做三档标注。

我曾经观察过一个做供应链金融的团队，他们监控的是某区域几十家中小制造企业的舆情和公开数据。传统模型只盯财务指标的时候，季度数据还没出来，风险已经被市场消化了一轮；引入语言模型做公告和新闻事件抽取之后，很多预警在相关公司被列为被执行人的公告当天就触发了，比财务报表最早披露时间提前了将近一个季度。

这里有一个实操心法：风险事件抽取模型不要直接对接预警，要加一层“严重程度阈值”判断。因为新闻标题很容易出现“某公司新增立案信息”这类高频率的提示性事件，一触发就预警会让业务部门产生狼来了效应。把频率维度和严重程度联合起来，比如“三个月内三次被列为被执行人”才升级为预警，误报率才能压下来。

3.3 舆情与突发风险事件的传导分析

舆情数据有典型的噪声大、时效性强、样本不均衡的特点。绝大多数新闻和讨论是中性或者无关的，少数几条才是真正的风险触发点。筛掉噪声本身就是语言模型的核心任务。

中文互联网上同一家企业在不同语境下可能有不同的叫法：全称、简称、股票代码、曾经的曾用名、甚至错别字。实体归一化这步如果做不干净，后面所有的舆情关联分析都是空的。语言模型可以结合上下文完成实体识别和归一化，比纯规则词典的方式鲁棒得多。

传导分析是这个场景里更进阶的一步。供应链金融中经常要判断：“上游某核心企业的停产消息，会不会传导到下游制造成本？”这类问题的难点不在于识别“停产”这个事件，而在于判断该企业与目标企业的关联路径——它们之间是否有直接供应关系，供应依赖度有多高，有没有替代供应商。语言模型能读合同文本、读上下游官方公告、读行业研究报告的片段，把关联路径提取出来，再由图算法去计算传导强度。

这个场景里最有价值的不是模型本身，而是事件脉络的组织方式。我建议把舆情结果按“时间轴+实体关系+事件类型”三个维度存储，后续不管做预警还是做复盘报告，查询效率都会高很多。

3.4 监管文件与合同的合规审查

无论是贷款合同、担保合同，还是投资协议里的回购条款，每一份里都有几十个关键条款需要核对。语言模型在这类任务里扮演的角色更像是“条款摘录员”而不是“法官”——它把条款抽出来，把潜在风险点标出来，但最终判断必须由法务或业务人员来做。

实际操作中，我最常用的方法是一次性把合同全文交给大模型，让它按预先定义的提纲输出结构化摘要：涉及到金额的条款、还款计划、违约触发条件、担保方式、管辖法院、提前还款的罚息安排。对于一份50页的合同，人工通读可能需要两三个小时，语言模型把它压缩成两页结构化表格，这个提效非常可观。

风险点是长合同超出上下文窗口。解决办法是切分加递进摘要：先按章节切分，分别抽取每章要点，再把要点合并成全局摘要。切分时注意保留条款跨页的连续性，有些合同会有“见第X条第Y款”这种交叉引用，单纯按页截断会丢失关联。

做这个场景之前要跟业务方把边界谈清楚：模型输出的法律条款风险提示不是法律意见，只做信息辅助。不要试图让模型回答“这个条款是否合法”，那是法务和律师的工作；模型只做“把条款提取出来并标出与预设规则的偏离”，这样既安全又有实际价值。

4. 从零到一搭建一套可上线的风险评估流水线

跑通一个单独的场景Demo和跑通一个能稳定复现结果的流水线，中间隔着大量的数据处理工程。不少人以为核心是模型调参，但我的经验恰恰相反：金融文本的数据质量、任务定义的清晰度、评估口径的严谨程度，这三件事决定了项目能不能从POC走向生产环境。

4.1 金融文本的数据清洗

金融领域的原始文档形态极其复杂。有扫描版的PDF、有盖章后拍照的图片、有从系统导出的乱码表格、有页眉页脚混入正文的情况。如果前面这些不处理干净，语言模型的能力再强也会被噪声干扰。

金融文本预处理有几个特有的坑。第一个是PDF表格区域，财报里的表格和正文混在一起，直接转文字会出现大量断行和错位，需要提前做版面分析。第二个是重复性声明，公告里那些模板化的免责声明、标准段落，对模型理解没有增量信息，但会无谓消耗上下文窗口，最好在进模型之前用规则先去掉。第三个是数字格式，中文数字、带逗号的千分位数字、以万元为单位的表述，抽取后要统一转成标准数值型字段。

数据清洗阶段最容易被低估的是标注环节。对于抽取类任务，你至少需要几百条业务方认可真实结果的样本。标注过程一定要让业务人员参与，不能只靠算法团队自己标，因为风控场景里的很多判断标准不具备领域经验很难领会。两个标注人之间的判断一致性指标建议以初始的一致率不低于80%为目标，低于这个数，不是标注标准没定义清楚，就是任务边界本身有歧义。

4.2 提示词工程和指令微调的配合

提示词工程不是写几句套话让模型扮演角色，而是把输出格式约束清楚。我的经验是，Prompt里最核心的不是角色设定，而是“输出契约”——字段名、类型、是否允许缺省、是否要附原文引用、空值的表达方式。把这些在Prompt里写明，比塞进几个示例管用得多。

思维链在这个领域要慎重使用。让模型展示推理链条，虽然有时能提升答案质量，但在风控场景里会带来两个副作用：一是输出token变长，推理成本成倍上涨；二是模型的“推理过程”反而成了审计上说不清楚的东西——到底依据是真实原文，还是模型自己在编故事。我一般推荐两段式策略：先让模型抽取并引用证据，再让一个判别式步骤基于抽取结果做状态判断，而不要求模型输出大段推理过程。

指令微调的数据量不用贪多。以开源的7B级参数底座模型为例，500到1000条高质量的有标注样本通常就能让模型稳定输出目标格式。这里的高质量指的是每条样本都要经过业务校验，而不是从历史数据里批量捞出来的。样本构造上，要把业务中会遇到的边界情况都覆盖到：原文没有对应字段的情况、字段可以取多个值的情况、数值范围模糊的情况。这些边界样本决定了模型的鲁棒性上限。

4.3 评估体系不能只看准确率

在金融风控里，模型输出错误有两种完全不同的代价：漏报可能意味着错过了一个实质性风险事件；误报则意味着浪费人工审查资源。这两个代价不对称，所以评估指标不能笼统看一个准确率。做抽取任务，要看每个字段的类型级别F1值，特别是重要字段（担保金额、涉诉金额、关联方名称）的召回率，宁可多抽出来让下游过滤，也不能漏掉。做事件分级，要看严重程度的混淆矩阵，比如把一个高风险事件分成了中风险，这比把中风险分成了低风险更致命。

校准度是另一个容易被忽视的维度。金融风险评估最终要把模型结果跟业务决策串在一起，模型给出的概率必须是真实的置信度。一个对业务毫无意义的场景是：模型对20%的样本说“这个企业有80%的概率违约”，但这个比例里实际违约的只有40%。这种概率输出会导致决策层完全不信任模型。处理方式是在校准集上算期望校准误差，低于5%才比较可靠。

另一个关键动作是数据集划分，必须按时间切分，不能随机切。金融数据的时序特征非常强，用今年上半年的文本去预测去年下半年的结果，本质上就是数据泄露。正确做法是按月度滚动划分训练集和验证集，再按季度做回溯测试，观察模型跨时间窗口的稳定性。

5. 部署落地中的性能和成本账

模型效果好只是第一步，上线之后，性能、成本、稳定性都是绕不开的工程问题。很多POC项目死在最后这100米，不是模型不行，而是部署方案没有认真做。

5.1 推理加速和模型压缩的手段

金融风控数据处理通常有两种节奏：一种是日终批处理，比如每天夜里跑全量客户的舆情和公告扫描；另一种是准实时触发，比如某客户出现突发风险事件，需要在几分钟内完成解析并推送预警。两种节奏对推理引擎的要求完全不同。

批处理场景下，吞吐量比单条延迟重要，可以放心使用较大的模型并在GPU上批量推理。准实时场景则要把延迟压在秒级以内，这时候模型量化基本是必选项。我用过INT8和INT4量化，实测在7B模型上，INT8量化几乎不损伤抽取类任务的精度，但推理速度可以提升两到三倍，显存占用明显下降。如果你的任务容许更宽松的精度，也可以尝试蒸馏出一个小参数模型来承接高频简单任务，大模型只处理长尾复杂样本。

还有一个容易被忽略的手段是缓存复用。同一份公告或者同一份财报，可能被多个任务同时处理，导致重复调用模型。在系统设计上做好文本指纹去重，你会发现不少计算量是可以直接跳过的。

5.2 人机协同的复核闭环

金融风控场景里，模型输出必须嵌进一个带有人工复核的闭环里。我一般的做法是把模型输出的置信度分为三档：高置信度的抽取结果直接进决策流程；中等置信度进入人工抽检；低置信度转入人工全量复核。后面两档的复核结果会定期回流成标注数据，用于下一轮模型迭代，形成可持续的数据飞轮。

审计追踪是这套系统里最容易被裁掉的模块，但我强烈建议保留。每一次模型调用，都应该记录下来模型版本号、Prompt版本号、输入文档摘要、输出结果快照、人工复核结论、采纳情况。这些日志平时用不上，但在审计抽检和模型迭代复盘时，它们是唯一可信的依据。

部署方案还要考虑模型更新的灰度发布机制。风控系统最怕的是模型突发行为变化：你今天升级了模型，结果新模型对某种文档的抽取行为变了，导致预警数量突然暴涨。正确的做法是新旧模型并行跑一段时间，比较两者在最近一个时间窗内的输出差异，确认风险指标没有突变之后，再把流量切过去。

6. 常见问题与排查清单

整理几个在这个领域反复出现的问题和对应的排查思路。这部分内容大概率是常规技术文档里查不到的，是项目推进过程中一步步填坑填出来的经验。

6.1 模型幻觉：输出原文中不存在的财务数据

这是语言模型在金融领域落地被问最多的问题。模型可能输出一个合同里根本没有的担保金额，或者一本正经地告诉你某企业的净利润下降了30%，其实原文里关于利润的描述只有一句“同比有所波动”。

我的处理方式分三层。第一层是Prompt硬约束，明确要求“只允许输出原文中明确出现的事实；如原文未提及，对应字段输出null”，并强制要求每个字段附带原文引用句子。第二层是后验校验，用规则算法检查抽取出的数字和金额是否能在原文里找到对应文本片段，找不到就打回重抽或者转人工。第三层是检索增强，让模型先检索相关原文段落，再基于检索结果做抽取，减少无依据的自由生成空间。三层叠加之后，幻觉比例会被压到可接受的范围。

6.2 违约样本严重不足时的分类训练冷启动

风险评估最常见的数据问题是正负样本极度不平衡：违约客户可能只占全量的1%到2%。直接拿原始比例训练模型，模型会学会“全部输出非违约”就能拿到98%准确率的偷懒方式。

解决思路是主动学习。先让模型对大量无标签样本做预测，只挑出模型置信度中等的那部分——通常这类样本最有信息量——交给人工标注，再用扩充后的数据集迭代训练。这个方法我试过，两三轮迭代之后，模型对少数类的召回率能有明显提升。另一个有效手段是对违约样本做特征级增强，把不合格报告的风险描述改写成不同表达方式，训练模型理解同一风险的不同措辞。

冷启动也常出现在新业务线。新业务没有历史标注数据，可以先从通用新闻舆情模型开始，用关键词规则生成一批弱标注，跑通流程后再用抽样复核的方式逐步清洗，两三个周期后就过渡到纯模型标注。

6.3 时间漂移和数据泄露陷阱

金融文本的表达习惯会在两三年内发生变化。比如“爆雷”“踩雷”这类说法在某个时间点集中出现，而更早的文本里用的是“逾期兑付”“无法兑付”这类相对正式的措辞。用近两年数据训练的模型，回看五年前文本，效果下降几乎是必然的，除非你有意识地做跨时间的数据增强。

更隐蔽的是数据泄露。我曾经见过一个团队的评估结果好看得异常，后来排查发现，他们用于抽取某些财务字段的模型，在预训练阶段接触过后续年份的财报文本。这就相当于考试时提前看到了答案。避免方法只有一个：从数据源头做好版本管理，明确模型预训练语料的截止时间，并且永远用最新时间窗数据做测试。

检查数据泄露有个粗糙但有效的方法：把模型在历史时间窗上的预测误差按季度画一条曲线，如果模型对很久以前的数据表现异常好，你有理由怀疑它见过未来数据。

这类经验还有很多，比如模型在金融文本上的实体识别效果跟文本来源渠道强相关，从官方公告上学到的模式，套用到论坛讨论帖上经常失效。通用的建议是做任何跨语料库迁移之前，先抽几十条样本人工评估一下分布差异，别假设模型的能力是通用的。我在实际项目中反复体会到，语言模型工程在金融风控里的成败，技术含量最高的部分往往不在模型本身，而在于风险任务的定义、数据质量的控制和评估口径的严谨——模型是放大器，输入质量决定输出上限。