大模型这个词喊了三年真正能在线上风控链路里稳定跑起来的项目我见的其实不多。“大模型智慧风控之旅”听起来像一句口号背后却是把大模型这种通用能力硬塞进风控这种对稳定性和可解释性要求极高的生产系统。我参与的这个项目前后做了大半年从最开始“让大模型当个智能客服”的模糊想法逐步收敛成一条可量化、可回滚、可持续迭代的风控增强链路。直白讲这篇内容适合三类人一是正在评估“要不要在大模型上投入”的风控策略团队二是设计风控系统架构的后端工程师三是对大模型产品化感兴趣、想找一个既有业务价值又有落地深度案例的产品同学。我不是在聊一个只有PPT的概念而是把数据准备、Prompt设计、模型部署、老系统集成、评估回归、线上踩坑这一整条路径按我实际折腾过的方式复述一遍。1. 大模型风控的定位与整体设计拆解1.1 大模型不是来替代规则的是来补“读不懂”的地方很多深耕风控多年的人第一次接触大模型时会问这玩意到底能帮我做什么传统风控决策是建立在结构化数据上的征信字段、还款流水、设备指纹、交易次数、关联图谱这些都能在表格里存下来也能被规则引擎或者传统树模型消费。但现实中大量有效的信号偏偏存在表格之外客户申诉文本里藏着对某个流程节点的强烈不满客服对话录音转写里能看出业务员是否做了误导上传的截图和合同里能读到关键争议点。这些内容过去只能靠人工一步步去读成本高、速度慢而且不同人读出来的结论还不一样。大模型最直接的价值就是把这些非结构化文本变成结构化标签和证据片段再喂给原有的规则引擎和评分卡。你不需要推翻任何现有系统只需要在最前面加一层理解能力。打个比方老风控系统像一个严格的门卫只认身份证号、银行卡和固定格式的申请单大模型像一个翻译能把各种乱七八糟的信纸、口述、便签都转成标准表单再交给门卫判断。门卫没有换标准也没有乱只是信息来源变多了。这里有一个常见的认知偏差有人一上来就希望“用大模型替换整个风控引擎”我坚决反对。老引擎的决策路径是可解释、可回溯的单条处理成本可能只有几毫秒而且经过多年极端场景的洗礼稳定性已经被验证过了。大模型在语义理解和复杂推理上确实强但在实时性、确定性和服务稳定性上并不占优势。一次灾难性故障或者一次给不出理由的决策足够让整个项目被业务部门打入冷宫。所以我们从一开始定下的原则就是八个字外围增强核心保留。如果让我给大模型在风控体系里排一个位置它应该站在“信息入口”和“决策引擎”之间只负责把人类语言翻译成机器可用的特征和依据而不是去扮演法官。法官还得是规则引擎和人工审批团队因为风险决策需要承担后果需要有人负责。模型可以犯错但责任最终必须落在明确的规则和责任人身上这是金融风控和一般文本处理最大的区别。1.2 整体链路接入、理解、决策、运营四层怎么搭项目立项后我们第一个动作不是选模型而是画链路。整个大模型智慧风控体系一共分四层接入层、理解层、决策层、运营层。接入层负责把不同类型的非结构化入口统一起来包括申诉文本工单、在线对话记录、语音转写结果、图片OCR出来的文本。最开始我们没有铺开全渠道只挑了一个渠道试点就是客户申诉文本。原因很实际这个渠道的数据最干净、格式最统一、业务目标也最明确哪怕模型理解错了也有清晰的人工兜底路径。把试点放在这里相当于用最小成本验证整条链路能不能走通后续再复制到其他渠道就有了底气。理解层是大模型的主场负责把文本转成结构化标签意图类别、情绪强度、涉及的业务环节、诉求方向、冲突点、证据片段。这个阶段的产出是数据不是决策。工程层面必须有足够的保障包括Prompt版本管理、输出JSON Schema校验、字段归一化映射、置信度输出这些后面会单独展开。理解层输出质量直接决定了决策层能做出多准确的下游判断。决策层依然是专家规则加传统机器学习模型。它读取大模型输出的特征再叠加原有业务变量比如历史逾期次数、登录设备、关联网络数据拼装出最终的决策码。决策层不关心特征是人工填的表单还是大模型抽取的它只关心值合不合理、字段缺不缺。这样做的好处是即使大模型服务整体不可用决策层依然可以用其他变量走完原有流程。运营层是最容易被忽视的一层包括模型监控、样本回流、人工复核工单、月度回测、规则仿真。没有运营层系统上线三个月之后大概率会悄悄变钝。客户表达方式在变业务口径在变渠道结构也在变如果不能持续把新样本送回评估流程别说大模型传统模型一样会漂。我们曾经因为一周没盯风险等级分布的变化结果线上高风险标签占比悄悄翻了两倍还好被监控告警抓到了。所以这四层的关系很清晰接入层决定数据质量理解层决定理解深度决策层决定最终判断运营层决定长期生命力。缺任何一层项目都只是试验品不是生产系统。1.3 场景优先级先弱决策再强决策项目实施节奏按四个阶段走准备期、试点期、扩展期、固化期。准备期主要做数据梳理和Prompt原型大约三周试点期只做一个高频场景就是申诉文本的自动分拣每天处理数万条文本但结果只用于排序和打标不直接给审批结论扩展期才逐步加入辅助审批摘要、候选规则生成这类更高价值的场景固化期把大模型调用封装成标准的内部服务配套灰度、监控和回滚机制跟普通后端服务一样运维。在场景选择上我强调了四个筛选标准。第一业务量要大模型每天都能见到新样本评估结果才有统计意义。第二判断标准相对客观最好有现成的人工标注结果可以直接对比。第三出错影响要可控即使模型判断错误也不至于立刻造成资损或者合规风险。第四有清晰的人工兜底路径。满足这四点再推进项目过程中的扯皮会少很多业务团队也更愿意配合标注和反馈。反过来讲如果一上来就选择反欺诈、催收策略这类特别复杂、特别敏感的领域团队会陷入永无止境的边界case里很快失去信心。不是大模型做不了而是你还没有足够的评估体系和业务信任去支撑它。先用一个简单的场景跑通流程是给整个团队上保险。2. 核心细节解析大模型在风控里到底干哪些活2.1 把一段话变成可入库的信号大模型在风控场景里最常被用到的能力就是信息抽取。最典型的例子客户一段申诉文本里可能有事实描述、情绪宣泄、对某个环节的不满、希望得到的结果甚至威胁性表达。过去人工处理要逐字逐段去读现在模型可以直接输出结构化结果。举一个我们实际用过的字段集意图、风险等级、冲突标记、涉及环节、诉求类别、情绪强度、关键时间点、证据引用。每个字段都有严格枚举不允许模型自由发挥。比如风险等级只给低、中、高、不确定四个值情绪强度只给弱、中、强、极强四个值。为什么强制枚举因为风控下游要统计、要监控、要做规则判断枚举值才是最稳定的接口。实际工程里有一个反直觉的教训模型输出越丰富出错的概率就越高。所以我们反过来做让模型只输出最小必要字段能用一个字段表达的不用两个。宁可在后续链路通过逻辑推导得到额外信息也不要让模型一次性吐出大量交叉字段。字段越多交叉之处越容易产生幻觉最后的清洗成本反而更高。另一件必须做的事是把“不确定”作为合法输出。文本信息不足时模型可以直接返回“不确定”然后路由到人工审核。刚开始团队会担心这样降低自动化比例但真实业务里把低置信度样本交给人处理比让模型硬猜然后出错要划算得多。风控场景对错误率的容忍度极低一次错判引发的投诉、资损和合规压力远超省下来的那点人工成本。2.2 从特征抽取到候选规则生成试点稳定之后我们尝试了一个更有价值的场景候选规则生成。做法是按周汇总通过样本和拒绝样本把风险等级分布、文本关键词、关联变量做成脱敏摘要让大模型做离线分析请它输出几条可能值得验证的新规则比如“同一设备在一小时内关联超过五个不同账号风险提升一级”。这个动作不在线执行结果只提供给策略分析师参考。这里有一条红线模型生成的规则建议永远不能直接生效。原因很简单模型看不到规则上线之后会影响哪些真实客户也看不到误伤率更不会为错误规则承担后果。正确流程是候选规则进入仿真平台用过去三个月的历史样本回放计算命中率、误伤率、提升度、对原有业务指标的边际影响最后由有经验的策略分析师拍板。大模型做的事情只是把分析师从几万行数据里手工归纳的过程加速而不是取代人的判断。实测下来原先整理一轮潜在规则大约需要两天后来一天不到就能拿到候选人工验证和仿真再花半天整体迭代节奏大约快一倍。这个提升不是颠覆性的但累积到一个月、一个季度对策略迭代速度的帮助相当明显。而且模型给出的规则描述往往带上了数据分布特征分析师的思路也能被打开一些。2.3 辅助审批摘要让审批员愿意信任工具再往深处走我们接入了辅助审批摘要场景。以前审批员处理一笔复杂申诉需要同时在多个系统间来回切换看流水、看设备信息、看历史进件、看关联账户自己把信息拼装成判断。现在大模型会提前把素材整合成一页摘要包含客户诉求、关键时间线、冲突点、历史行为摘要、建议风险等级。审批员看摘要就能快速定位问题再一键进入原有审批流。这个环节最大的挑战不是生成质量而是信任。审批员如果发现摘要里有一个字段跟原始系统对不上哪怕只是日期错了下一次他可能就不再依赖摘要了。所以我们强制要求所有输出都带依据来源并且只能引用输入文本中出现过的信息模型被明确禁止补充任何外部事实。技术上我们做了两个保证一是输出关键字段和原始文档的匹配校验日期、金额、账号这些硬信息必须能在原文里找到找不到自动隐藏并标记为待人工确认二是在摘要末尾附上关联证据片段列表让审批员可以一键跳转原文核对。这个设计对项目公信力的贡献非常大我建议所有做大模型辅助审核的人都把“可核对”纳入第一版设计不要后期再补。2.4 多语言和复杂场景的处理方式业务里经常会遇到多语言客服对话和方言口语化的表述。传统方法要为每一种语言单独训练模型维护成本成倍增长。大模型天然具备跨语言迁移能力同一个Prompt模板可以处理中文、英文以及不少小语种。实测下来中文和英文的抽取准确率基本接近小语种上差距就明显一些所以对小语种我们设置了更保守的置信度阈值也提高了人工抽检比例。复杂场景我们采用了很朴素的思想拆任务。最开始我们把意图识别、字段抽取、冲突判断、情感判断全部塞进一个Prompt结果输出的格式经常自相矛盾。后来改成链路式第一层先做粗粒度意图识别根据意图选择后续的抽取模板每个模板只管自己那一部分。这样做还有额外的好处线上一旦出现问题可以快速定位是哪一个环节出的错调试成本直线下降。产品同学可能觉得链式调用不如一个大而全的Agent高级但在风控场景里可定位性和可控性远比“看起来智能”重要。3. 实操过程从数据清洗、模型选型到生产集成3.1 数据准备和标注体系怎么搭大模型任务的上限很大程度上由数据准备决定而不是模型参数有多少。我们整理了几十万条脱敏申诉文本覆盖主流渠道和异常通道。预处理阶段做了三件事。第一个人信息全部替换姓名、手机号、身份证号、银行卡号统一替换成占位符从源头保障隐私安全。第二标准化表达但保留关键原文口语文本不强行改写而是增加一层归一化标签比如“钱没到账”和“没收到钱”都归一到“到账异常”标签原文仍然保留在特征来源里。第三样本分层按业务类型、风险等级、渠道、时间区间做分层抽样避免模型只见过某一类文本。标注环节我们没有把活全部外包给外面的人而是让风控策略专员先编写标注规范把每个字段的含义、边界场景、反例写清楚再由标注团队按规范执行最后抽查一致性。有一个痛点是正负样本不平衡申诉文本里高风险样本占比很小模型很容易在多数类上表现良好却在少数类上一塌糊涂。所以抽样时要人为提高高风险样本的比例同时单独统计高风险类别的准确率和召回率。除了样本比例标注一致性也要定期关注。不同标注员对同一段文本给出不同结果时要把争议样本拿出来重新确认标注规范。我们在启动阶段做了一次标注一致性统计发现“客户不满”和“强烈冲突”两个标签即使对老员工来说也容易混淆于是干脆合并成一个字段从源头消除了分歧。这类工作很苦但它们是整个系统准确率的地基。3.2 Prompt 模板设计的三个必要层次Prompt是这个项目里最核心、迭代最多的交付物之一。我把我们的模板抽象成三个层次角色与任务定义、枚举约束、示例。角色和任务定义要明确你是一名风控审核助手只根据给定文本提取字段不要补充外部信息。紧接着给出输出格式要求明确要求JSON结构。枚举约束要写全把每个字段的可取值列出来并标明含义。示例至少要覆盖两个正例和一个反例。正例让模型学会格式和口径反例则告诉它什么情况不能算作某个标签这比只给正例重要得多。下面是一个生产环境里的骨架示例具体业务枚举值已经做了脱敏简化你是一名风控审核助手。你将收到一段客户申诉文本。 任务提取以下字段并输出JSON。 字段定义 - intent: 申诉意图取值只允许 [withdraw, refund, complaint, fraud_report, other] - risk_level: 风险等级取值只允许 [low, medium, high, uncertain] - conflict: 是否与既有记录存在冲突取值只允许 [yes, no, uncertain] 要求 1. 只能基于文本内容做判断不能补充外部信息。 2. 无法判断时使用 uncertain。 3. 只输出JSON不要输出解释。 示例1 文本“我昨天申请退款今天都没到账客服也没回复我。” 输出{intent: refund, risk_level: medium, conflict: no} 示例2 文本“你们突然把我账户冻结了也不说明原因我要投诉” 输出{intent: complaint, risk_level: high, conflict: uncertain}注意骨架只是模板基础线上版本需要把枚举值定义和JSON Schema写得更细并且每个字段都要有边界解释。Prompt里加一句话、删一个示例都可能改变大量线上样本的输出所以正式环境必须对Prompt做版本管理任何改动都要重新过一遍回归集。还有一个必须配套的东西输出校验。哪怕Prompt写了“严格按照JSON输出”模型依然可能输出多余标点、大小写不一致的枚举值甚至夹杂一段解释文本。所以线上一定有一层代码后处理解析第一个合法的JSON片段枚举值做强制的归一化映射遇到非法值替换为默认类别并记录告警。框架和逻辑只能减小出错的概率代码兜底才能防止线上出现脏数据。3.3 模型选型与部署方案怎么取舍模型选型阶段我们在闭源API和开源可自部署模型之间纠结了很久。闭源API在通用语言理解能力上确实更胜一筹但风控数据高度敏感把客户真实文本传到外部服务需要过大量合规评审。从实践中看这种评审几乎很难在项目周期内顺利通过。所以最终我们选择了自建推理服务部署一个开源底座模型然后用已经标注的数据做轻量微调让抽取能力达到可用水平。部署细节上我们采用标准化的模型服务化方案GPU资源池化、请求队列、超时控制、故障自动降级。预算有限不能一味堆硬件所以把并发副本设在一个偏保守的水平长尾延迟目标定在P95不到800毫秒。这里有个认知要调整风控主链路仍然在老引擎上所以大模型服务偶尔抖几下影响有限可以接受关键是别让它拖垮整条链路。实时场景下宁可让部分请求超时降级也不要让GPU排队时间无限膨胀。微调程度上我们没有做过度。对于抽取和摘要任务LoRA级别的微调就足够把业务词汇和格式偏好学进去即可。全参数微调成本高周期长而且容易破坏底座模型的通用能力。我们前期用少量数据验证LoRA效果达到指标后再扩大数据规模整个过程大概用了两周比想象中快。3.4 和旧风控引擎的集成方式这一步最枯燥但也最决定成败。对外的接口很简单输入一段脱敏文本输出一个JSON。网关再把JSON转成风控引擎内部统一的事件数据格式送入规则引擎参与计算。大模型不直接产生决策而是作为特征来源之一。规则引擎结合原有变量、设备指纹、关联图谱以及大模型输出的标签最终算出决策码。集成阶段我们定了三条铁律。一是可降级大模型超时、报错、返回结果为空时自动跳过该特征系统继续以旧逻辑跑。二是特征命名规范所有大模型相关特征统一加前缀方便报表、监控和回溯。三是灰度先行大模型特征先以旁路模式接入只写日志不做决策积累足够多的对比样本后再逐步放开流量。旁路模式值得重点讲。旁路模式的意思就是模型真实计算结果并写入日志和数仓但不干预任何业务判断安静地跑两到四周。这个阶段把模型输出和历史人工决策逐条比对只有当准确率达到预期阈值后才有限度地打开线上决策开关。这样做既给算法团队留出打磨时间也让业务部门在正式上线前就看到可信的对比数据远比第一天就上真实决策稳妥得多。3.5 评估体系和回归测试的设计评估分三层字段准确率、结果结构准确率、业务指标变化。字段准确率逐字段对比结果结构准确率要求整条JSON所有字段全部正确才算作正确这一条更严格也更接近用户的真实体感业务指标变化包括处理时效、人工干预率、投诉升级率、高风险召回变化等这一层才是项目价值的最终证明。回归测试每周跑一次覆盖超过一万条标注样本每次Prompt或模型版本改动都必须通过回归才能发布。改Prompt最常见的失误是只改了一个场景示例结果连带影响了许多其他字段的输出这些隐性变化靠单点测试根本发现不了回归集就是用来兜这种不可预见的全局变化。评估时还有一个很容易掉进去的陷阱只看整体准确率。比如模型风险等级准确率到了90%看起来不错但如果高风险样本全部被误判成低风险整体准确率依然接近90%因为高风险样本本来就少。所以报表里必须把混淆矩阵单列出来重点盯高风险样本的召回率。风控场景的价值观是宁可错杀不愿意漏放漏放一个真正的高风险案例造成的损失往往大于拒绝掉大量正常样本。4. 常见问题与排查技巧实录4.1 幻觉问题怎么防止模型编造事实幻觉是大模型风控里必须正面面对的问题没有哪种模型能完全避免。最典型的情况是模型在摘要里写客户在12月3日提交过申请但原文根本没有这个日期。排查发现是Prompt里的示例反复出现日期字段诱导模型在缺省时自我补全。解决办法可以分成三件套。首先指令里写死“只能引用原文信息禁止补充任何外部事实”。其次对关键字段做一致性校验把模型输出的日期、账号、金额等与原始文本做匹配匹配不上的自动标记或丢弃。最后把开放填空改成判断型提问比如问模型“原文是否提到过退款金额”让模型回答是或否比问“具体金额是多少”更不容易触发幻觉。三个措施同时启用后人工抽查中明显编造案例的比例下降了一个数量级。需要注意的是幻觉不能靠模型微调彻底消除。即使在做完LoRA之后模型在某些长尾样本上依然会自主补全。所以我们的态度是把幻觉当成一种必然存在的噪声来管理通过校验和人工复核去拦截而不是寄希望于某个版本的完美模型。4.2 延迟和成本给大模型减负调用量降了六成线上系统刚开放时高峰期的模型服务经常排队P95延迟冲到好几秒。一开始以为GPU不够后来分析链路才发现问题不是单次推理太慢而是大量只有一句话的简单咨询也涌到大模型这边。本来这种文本用传统分类器一瞬间就能跑完非要让大模型跑一遍完整抽取流程队列当然堵住。优化方案是加一层前置路由先让老分类器或规则做粗分拣短文本、简单诉求直接走传统路径只有长文本、语义复杂、多意图混合的内容才进入大模型通道。这个调整之后大模型调用量降了大概六成高峰期延迟立刻回到可控范围推理成本同样降了六成。大模型不是万能入口把它用在刀刃上才是真正的工程优化。成本核算上除了推理算力还要把标注、人工复核、监控开发、压测环境这些隐性成本全部算进去。如果业务收益算不过来项目在二期很容易被砍。所以项目一开始就要确定北极星指标比如人工处理时长下降比例或者高风险漏报率下降比例用数字去说服管理层。4.3 隐私合规上线前最容易被忽视的一环风控数据天然涉及大量个人信息和财务信息。我们的全链路都把匿名化放在第一位模型服务只接收脱敏后的模板化文本输出侧再做一次脱敏校验手机号、身份证号、银行卡号一旦出现立即拦截替换。日志只保留必要字段留存周期明确限定到期自动清理。这件事没有太多炫技空间但做不好会让整个项目停摆。我们有一个很深的教训合规评审不是上线前的最后一道流程而应该从项目第一天就并行推进。等模型训练完了、联调都做完了再补合规流程通常意味着推翻重做或者无限期延期。把评审排进项目启动清单代码怎么写都行但职责要前置隔离。看起来是多了几条流程其实是总工期最短的一条路。4.4 模型漂移与长期监控语言是会漂移的。客户申诉的表达方式、业务热点、渠道偏好都会随时间改变。比如某个新功能上线后相关投诉文本总量和关键词分布会突变。如果模型不做持续学习它的准确率会在两三个月内肉眼可见地下降。我们建立了一套月度回测加季度微调的节奏每月跑一次全量回归测试每季度用最新标注数据做一次轻量微调。线上侧保留小流量灰度开关先看一段时间再全面放开。监控指标除了常规的请求量、成功率、延迟还要看业务语义指标比如风险等级分布偏移、各渠道准确率差异、高置信度样本占比变化。这些指标一头连着模型健康度一头连着业务稳定性任何一项异常都应该能触发告警。这里放一张当时帮了大忙的问题定位速查表简洁写了症状、原因和排查动作。症状可能原因排查思路输出格式不稳定Prompt缺少强格式约束 / 后处理缺失增加JSON Schema、枚举映射、代码兜底高风险样本召回率低样本不平衡 / 优化目标集中在多数类重采样、单独统计高风险混淆矩阵高峰延迟飙升路由策略不精细 / 队列堆积短文本前置分流、限流降级摘要出现编造事实提示词诱导补全 / 示例干扰只允许引用输入、一致性校验、少开放填空线上指标缓慢下滑表达漂移 / 标注口径变化月度回测、季度微调、持续样本回流4.5 一个隐蔽的坑模型输出里突然冒出了“我认为”项目后期遇到一个特别让人头疼的问题。摘要质量整体稳定但有一阵子很多输出里出现了“我认为这笔订单应该拒绝”“可能会引发投诉”这类第一人称表达审批员一看就皱眉团队好不容易建立的信任感立刻开始松动。追查下去是新版本Prompt里的角色描述写得太“人性化”导致模型在部分样本上自动切换成了第一人称口吻。这个教训告诉我生产环境里的Prompt要像代码一样被对待任何一句不经意的措辞都可能改变输出行为。必须做版本管理、做diff、做回归而不是写完就放着不管。后来我们干脆在输出校验里加了敏感句式过滤把“我认为、我觉得、可能应该、或许可以”这类词直接从结果里拦截掉问题才彻底消失。5. 落地经验与后续扩展思路5.1 场景优先级怎么排如果再做一遍我会把推进顺序钉死成这样先辅助理解、再辅助分拣、再辅助决策、最后才是自动化处置。每走一步都要配一个独立的开关和一套评估口径。千万不要为了展示项目价值一开始就搞“全自动审批”。一旦出了问题项目被叫停只是其次团队的经验积累和业务信任都会受到很大打击。辅助理解阶段的产出是标签和摘要辅助分拣阶段的产出是风险排队和工单分派辅助决策阶段的产出是处理建议但仍由人拍板自动化处置只适合那些规则已经非常成熟、出错影响足够小的场景。这个阶梯最大的好处是每一步都能单独评估、单独回滚每一步也都能让业务团队逐步适应新工具的存在。走得慢一点反而走得更远。5.2 大模型风控团队怎么协作做这种项目天然需要风控策略、算法工程、后端开发、数据治理和质量运营几类角色坐在一起。分工上风控策略提供业务口径和评估标准算法工程负责微调和推理优化后端开发负责链路集成和监控数据治理保障清洗和合规质量运营维护回归集和样本回流。最容易出问题的不是某个技术环节而是角色之间的信息断层。策略团队改了一个标签定义数据团队三周之后才同步到标注规范后端版本上线了算法还不知道Prompt已经改动。解决方式很笨但有效所有变更都走同一个变更单把模型版本、Prompt版本、数据版本、标注版本锁定在一起保证回归测试能复现任何一次线上的表现。这个过程需要有人专门做别指望各团队自觉同步。5.3 后续还可以往哪走这个项目做下来我觉得值得继续投入的方向有三个。第一是多模态风控目前不少客户上传截图、语音、视频这些素材大多只存档不分析如果能把图片、语音、视频证据统一接入理解层价值会非常大。第二是知识库增强的合规问答把监管要求、内部制度、操作手册结构化之后让大模型做合规咨询和尽调辅助比单纯做文本分类空间更大。第三是自动生成拒绝原因让客户在被拒绝时看到更具体、更友好的解释既能降低投诉量也能倒逼业务口径收敛这个场景虽然不起眼但实际收益很直观。这些都是在大模型服务之上做加法不需要推翻现有架构。每加一个新场景都要重新走一遍数据准备、Prompt设计、评估、灰度、回滚、监控这条流程稳比快重要。最后再分享一点个人体会。做了大半年这个方向之后我越来越觉得决定项目上限的不是模型参数而是团队对业务边界的敬畏。大模型是一个能力放大器它能把好的流程加速也能把混乱的流程加倍放大。上线之前多花一个星期去设计评估指标和回滚机制远比多调几个Prompt示例更能决定整个项目的命运。技术项目做到最后拼的都是这种一开始不容易被看见的耐心。