最近在帮一个团队评估合同审核方向的AI落地遇到了一件很典型的事。同一个合同模板同一个LLM同样的问题连跑三次出来三份略有差异的审查意见。第一次漏掉了一条风险条款第二次把风险程度标得太高第三次看起来正常。团队负责人盯着屏幕问我“是不是参数没调好”我说更准确地说是我们正在让一个掷骰子的引擎去做需要稳定输出的工作。这不是个别现象。过去一年里越来越多垂直领域的AI产品开始强调“Agent”“RAG”“MCP”这些词合同审核、客服助手、代码审查、招聘筛选、合规初筛几乎每一个方向都在往LLM上靠。大家默认了一件事只要把模型接进业务流配一个足够详细的提示词它就能像传统软件一样稳定输出。但问题恰恰出在这里LLM不是传统软件。它不是函数而是概率分布。这篇文章想说的其实是一句话垂直AI真正的泡沫不是模型能力被高估而是我们把一个随机生成器当成了确定性计算器在验收、部署和兜底。想明白这件事很多“翻车”现场都能提前避开。1. 垂直AI热潮里被低估的“概率本质”1.1 我们期待的是函数得到的却是分布传统软件里一个函数给定同样的输入返回的一定是同样的输出。这是最底层的确定性。过去几十年所有系统设计、自动化流程、测试用例、合规审计都默认建立在“输入不变行为就不变”这条规则上。但LLM完全不是这样。它做的事情是给定一段文本作为条件从词表上计算出一个概率分布然后根据这个分布去采样下一个token。同一个 prompt同一个模型两次运行得到的输出可能不同。随机性不是bug而是生成模型的底层机制。很多垂直AI产品在宣传时会把“智能审核”“自动生成报告”包装得像一个更高配的规则引擎。但到了真实项目里业务方会问为什么这条条款上次被标记了这次没被标记为什么同样的问题上午和下午回答不一样这些问题的答案往往不是因为模型变笨了而是因为我们用函数的预期去使用了一个概率系统。我见过不少团队在做一个垂直AI Demo时非常兴奋因为单次演示效果很好。但只要进入测试阶段把同样的测试集跑两遍就会发现输出存在漂移。这个漂移率在低风险场景里可以接受但在合同、医疗、金融、代码安全这类场景里会成为决策障碍。1.2 “掷骰子”不是比喻是采样机制“LLMs Roll Dice”这个说法容易让人觉得是夸张的批评。其实从工程角度看它是很准确的描述。一个生成模型在推理时通常要经过下面这些环节把输入文本转成 token 序列。模型前向计算输出下一个 token 的概率分布。按某种采样策略从概率分布中选出一个或一组 token。把新 token 拼到输入后重复直到结束。采样策略里最重要的参数是 temperature。temperature 越高分布越扁平低概率 token 被选中的机会越大输出越多样。temperature 越低输出越倾向于高概率 token但并不意味着完全消除随机性。即使在 temperature 等于 0 时很多推理框架也会因为浮点运算、批处理、并行调度、FlashAttention 实现差异导致输出不完全一致。更关键的是temperature0 选择最高概率 token只是让“单次采样”更确定并不保证“语义正确”“符合规范”或“一定不幻觉”。对垂直AI产品来说这种概率本质带来的直接后果是我们不能再用“跑通一个用例”来证明系统可用。可复现性、稳定性、错误率、失败兜底这些传统软件里最基础的能力在LLM应用中反而成了最需要设计的部分。2. 为什么单点看起来很好垂直落地却全面翻车2.1 垂直场景要求的是稳定可复用不是偶尔惊艳垂直AI和通用聊天机器人有一个本质区别垂直场景是为了稳定地重复完成一类任务。风险审核、代码审查、客服工单分类、合同条款提取这些任务要求的是“每次都达到及格线以上”而不是“十次里有一次惊艳”。在评估一个LLM应用时很多团队会陷入一个认知误区看到模型在某几个精心挑的例子上表现很好就认为它具备了相应能力。但真实业务数据分布很宽边缘情况很多而且LLM的输出波动会把“偶尔正确”放大成“不可预测”。打个比方这就像你请了一个很聪明但偶尔会走神的实习生。他每次完成任务的质量大概在70分到95分之间波动。对于一个低风险的文字润色任务这完全没问题但对于一个需要写入合同或影响订单状态的自动流程这种波动就是不可接受的。所以垂直AI的“翻车”往往不是模型一次性犯大错而是它在一个长周期里不断产生小概率错误。这些小概率错误单看不致命堆在每天几万次调用里就成了每天几十起需要人工介入的异常。2.2 随机性从哪来参数、上下文、外部知识、模型路由当你说“LLM输出不稳定”时不要急着怪模型。一定要先拆清楚随机性到底是从哪个环节进来的。我一般会按下面几个来源去查。采样参数。temperature、top_p、max_tokens、seed这些直接决定生成过程的随机程度。很多应用上线时根本没有冻结这些参数默认值可能偏向多样性这在对话场景没问题但在结构化输出场景可能造成字段时有时无。上下文动态部分。如果prompt里拼接了时间、用户输入、客服备注、session信息那么即使主任务相同模型看到的上下文也不同。有些场景需要这种动态但要注意动态部分本身会引入输出方差。外部知识检索。现在很多垂直应用都用了RAG。RAG的一个隐蔽问题不是“检索不到”而是“检索结果排序不稳定”。同一个query向量库返回的相关文档可能因为索引更新、Embedding版本、切片方式、重排模型变化而不同。检索结果一变LLM输出自然变。模型路由和版本。应用层可能配置了多个模型自动降级或者供应商后台做了灰度更新。你以为是同一个模型实际在跑的是不同版本。模型版本一变分布就变很多线上问题其实来自这里。在排查不稳定问题时建议先用固定日志把每次请求的模型版本、采样参数、输入摘要、RAG检索结果都记录下来。没有这份日志你很难判断输出波动是来自模型、检索还是prompt。2.3 更隐蔽的问题用确定性思维验收随机系统传统项目验收方式是准备一批测试用例跑一遍看通过率。但在LLM项目里这样做有两个致命缺陷。第一个缺陷是单次跑通过的用例不代表下次还能通过。如果你只用一组静态样例验收那你验收到的其实是“在特定随机种子和采样参数下的表现”而不是系统的真实分布。第二个缺陷是你只评估了“模型输出”是否正确没有评估“输出到业务动作”这一整条链路是否可靠。LLM生成的JSON字段被下游解析只要字段名偶尔变化下游就会崩。这种问题不是模型能力问题而是接口契约问题。更合理的验收方式应该是准备一个覆盖正常、边缘、异常三类样本的评估集在固定一组配置下多次运行记录输出分布计算关键指标的均值和方差。比如字段缺失率、格式错误率、语义一致性、需要人工介入的比例。只有把这些指标纳入验收你才是在验收一个随机系统。3. 构建垂直AI的正确姿势先接受随机再控制边界3.1 三层防护输入约束、输出校验、人工兜底既然LLM是随机引擎就不能指望它自己稳定。工程上能做的是在它外面套上确定性护栏。我一般把防护拆成三层。第一层是输入约束。在进入LLM之前先确定任务边界这个任务是不是只允许模型处理某类输入输入格式是否已经标准化长度、字段、数量有没有限制如果输入是合同可以先做PDF解析和章节切分只取出相关条款而不是把几百页原文直接丢给模型。输入越规整模型的输出方差越小。第二层是输出校验。LLM返回结果后不要直接信任。用代码做结构化校验必填字段是否存在枚举值是否合法格式是否是JSON或特定模板数字范围是否合理如果校验失败可以重试一次或者进入降级流程。输出校验层的价值是把概率问题转化成“可捕获的异常”。第三层是人工兜底。任何高风险的垂直场景都应该在流程上保留人工确认环节。这不丢人反而说明你理解了LLM的边界。自动生成初筛意见、人工复核确认是现在最成熟的落地方式。完全去掉人的流程至少在强合规场景里还不到时候。这三层不是可选项而是必选项。跳过任何一层都是在把随机性直接暴露给业务。3.2 温度、种子、评估集让实验可复现“可复现”是开源社区反复强调的词但在LLM应用开发里很多人反而不重视。我建议从第一天起就把下面这些配置固定下来写进工程规范。temperature结构化任务建议从0.0开始调不要直接从0.7起步。top_p如果需要更保守的输出可以配合temperature一起调。seed如果平台支持固定seed实验阶段一定要固定。不过要记住seed固定不代表跨版本一定可复现。模型版本在生产环境锁死模型版本不要用latest这种标签。prompt版本每次修改prompt都要记录版本号并跑一遍回归测试。外部知识版本RAG里的知识库、Embedding模型、切分方式都要版本化。同时建立你自己的小评估集。这个评估集不需要很大三五十个典型case覆盖正常、边界、异常三类。每一轮改动后用同一个评估集、同一组采样参数跑三到五遍记录输出。不是为了“验证效果”而是为了观察稳定性。3.3 一份可执行的LLM输出排查链路当线上出现输出不稳定、字段缺失、结果错误时建议按下面这个顺序排查而不是一开始就去改prompt。先看日志采样参数是什么模型版本是什么输入摘要是否完整RAG检索命中了哪些文档固定环境重跑把同样的输入、同样的配置、同样的知识库版本用固定seed重跑看是否稳定复现。切换输入动态部分把prompt里的时间、客服备注等变量去掉只保留核心输入看输出是否恢复稳定。这一步能判断是否上下文动态内容干扰。检查RAG检索将检索结果打印出来看排序是否稳定。如果同一query在不同时间命中的文档不一致问题可能在检索层。检查输出解析如果下游解析失败检查字段名、类型和枚举值是否变化。有些模型在长输出时会自行加引号或换行导致JSON解析失败。最后再动prompt前面的链路都排查完再调整prompt否则你很难知道改动到底解决了什么。这套排查链路本质上是在回答一个问题输出波动到底是模型造成的还是前面任意一层造成的把问题定位准确比盲目调参更有效。4. 垂直AI的准入线场景、成本、风险三维评估4.1 适合生成的场景低风险、强辅助、人审闭环垂直AI并不是不能做而是要选对场景。从我的经验看下面这几类场景现在更适合落地。第一类是“内容草稿生成”。比如营销文案初稿、周报生成、产品说明起草。这类任务允许一定程度的差异核心价值是帮人省去从空白页开始的时间。只要人有最终审阅和修改权随机性就是可控的。第二类是“知识辅助问答”。比如企业内部知识库搜索、研发手册问答、政策法规初步解释。这类场景的答案需要人来确认同时需要标注“仅供参考”。适合把LLM当检索增强助手而不是最终裁决者。第三类是“结构化数据提取”。从非结构化文本中抽取字段、实体、关系例如从简历里提取技能、从发票里提取金额。这类任务可以用强校验层把输出限制在固定Schema里即使模型偶尔出错也能被规则拦截。这几类场景有一个共同点LLM的输出不是直接产生业务结果而是作为“初稿”或“候选”进入后续流程。人还在链路上随机性就不会无限放大。4.2 不适合直接决策的场景强规则、强一致、强合规我也见过一些场景从一开始就不适合用LLM直接做决策但团队因为“大家都在做AI”而强行接入。比如涉及数字计算的场景。LLM擅长自然语言不擅长精确算术。即便看起来算对了也可能因为推理过程不同而中途出错。正确的做法是让LLM负责抽取算式用代码引擎执行计算。再比如强规则一致性的场景。优惠活动规则、权限判定、费率计算这类逻辑要求同一条件永远得到同一输出。LLM不适合用来做这类规则引擎至少不适合在缺少校验和回退方案的情况下直接承担。还有强合规和高风险场景。医疗诊断、征信审批、法律最终意见等直接让LLM输出结论风险高且难以追溯。这类场景更适合让LLM做信息整理、证据链汇总、倾向性提示最终结论由持证或负责人完成。不是所有“AI能懂”的任务都适合“AI负责”。垂直AI的价值不是替代规则系统而是在规则系统覆盖不到的开放语义空间里提供辅助。4.3 用“不确定性预算表”做选型我在实际评估一个垂直AI机会时会画一个“不确定性预算表”。不是看模型能力多强而是看业务能容忍多少不确定性。评估维度可以接受不确定性的低风险场景不能接受不确定性的高风险场景输出一致性同一问题多次回答可以略有差异同一问题必须给出同一结论错误容忍度偶发错误可由人审发现错误直接影响决策或交易可追溯性不需要解释完整推理过程必须保留证据、引用和决策依据人工介入成本可以安排人工快速复核人工复核成本高但必需规则覆盖程度规则无法穷尽的开放问题规则清晰可枚举合规压力内部辅助不对外承诺面向客户有强监管表格的用法是如果某个场景在右边一列占了三条以上就要谨慎。不要因为demo效果不错就冲进去。一个垂直AI产品能不能成立不是看模型答得好不好而是看整条业务链能不能容忍波动。预算里面不确定性是一种必须支付的成本。成本不能无限大。5. 从“AI替代人”回到“AI增强人”我的一些实操建议5.1 先跑通单点再做批量这是底线每次有团队问我垂直AI怎么落地我第一个建议都是不要一开始就规划宏大平台先选一个真正高频、低风险、反馈快的单点场景把整条链路跑通。这个单点要满足三个条件频率非常高大家每天都会遇到。错误后果可控即使输出错了也不会造成大事故。有明确的输入输出边界方便做校验。把单点跑通之后再观察指标调用失败率、人工介入率、输出一次性通过率。如果这三个指标稳定再考虑横向扩展。如果单点都不稳就不要扩。扩得越快滚雪球越大。“AI替代人”是结果不是起点。起点永远是“AI辅助人把人的一部分重复工作抽出来”。抽出来的前提是你已经为随机性设计好了退路。5.2 把一次性经验沉淀成可复用流程在垂直AI项目里真正值钱的资产不是 prompt也不是模型调参记录而是一套围绕随机引擎建立的确定性流程。这套流程包括每次调用的运行日志包含输入、采样参数、模型版本、知识库版本、输出和耗时。一套可重复运行的评估集覆盖正常、边界、异常三类输入。一个输出校验模板针对每个任务定义必填字段、类型、取值范围和兜底动作。一个人工复核SOP说明哪些情况必须人工哪些情况可以自动放行。一个结果反馈闭环持续从生产环境收集badcase每周更新评估集。有了这套流程你团队里的任何一个人换到项目里都能在一个下午恢复上下文。没有这套流程项目就会一直停留在“只有写prompt的人能维护”的状态。现在很多人在讨论LLM框架、Agent编排、知识库Wiki化背后其实都是同一个诉求把不确定性变成可观测、可控制、可迭代的工程对象。这种“工程化”程度才是垂直AI能不能长期跑下去的分水岭。5.3 回到开头那个判断再回到合同审核那个案例。后来我们做的事情很简单把LLM输出的审查意见从“最终结论”降级为“初筛建议”再用规则脚本校验必查条款最后强制人工确认风险条款。改动之后系统没有变得更“聪明”但错误率显著下降了。这才是垂直AI该有的样子。不要追求让模型变成永不犯错的业务大脑而是接受它是个聪明但会掷骰子的助手。你真正要做的是为每一次“掷骰子”设好边界能校验的校验能重试的重试必须交给人的就交给人。垂直AI泡沫会不会破不在于资本什么时候降温而在于我们什么时候愿意承认LLM roll dice。承认之后才会认真设计护栏才会把评估指标从“看一个demo”改成“看一段运行数据”才会让AI真正走进生产环境。先接受随机再谈智能。这听起来没有“AI替代人”带感但它才是垂直AI从demo到产品的那条窄路。
垂直AI落地：LLM是概率引擎，用确定性护栏驾驭随机性
最近在帮一个团队评估合同审核方向的AI落地遇到了一件很典型的事。同一个合同模板同一个LLM同样的问题连跑三次出来三份略有差异的审查意见。第一次漏掉了一条风险条款第二次把风险程度标得太高第三次看起来正常。团队负责人盯着屏幕问我“是不是参数没调好”我说更准确地说是我们正在让一个掷骰子的引擎去做需要稳定输出的工作。这不是个别现象。过去一年里越来越多垂直领域的AI产品开始强调“Agent”“RAG”“MCP”这些词合同审核、客服助手、代码审查、招聘筛选、合规初筛几乎每一个方向都在往LLM上靠。大家默认了一件事只要把模型接进业务流配一个足够详细的提示词它就能像传统软件一样稳定输出。但问题恰恰出在这里LLM不是传统软件。它不是函数而是概率分布。这篇文章想说的其实是一句话垂直AI真正的泡沫不是模型能力被高估而是我们把一个随机生成器当成了确定性计算器在验收、部署和兜底。想明白这件事很多“翻车”现场都能提前避开。1. 垂直AI热潮里被低估的“概率本质”1.1 我们期待的是函数得到的却是分布传统软件里一个函数给定同样的输入返回的一定是同样的输出。这是最底层的确定性。过去几十年所有系统设计、自动化流程、测试用例、合规审计都默认建立在“输入不变行为就不变”这条规则上。但LLM完全不是这样。它做的事情是给定一段文本作为条件从词表上计算出一个概率分布然后根据这个分布去采样下一个token。同一个 prompt同一个模型两次运行得到的输出可能不同。随机性不是bug而是生成模型的底层机制。很多垂直AI产品在宣传时会把“智能审核”“自动生成报告”包装得像一个更高配的规则引擎。但到了真实项目里业务方会问为什么这条条款上次被标记了这次没被标记为什么同样的问题上午和下午回答不一样这些问题的答案往往不是因为模型变笨了而是因为我们用函数的预期去使用了一个概率系统。我见过不少团队在做一个垂直AI Demo时非常兴奋因为单次演示效果很好。但只要进入测试阶段把同样的测试集跑两遍就会发现输出存在漂移。这个漂移率在低风险场景里可以接受但在合同、医疗、金融、代码安全这类场景里会成为决策障碍。1.2 “掷骰子”不是比喻是采样机制“LLMs Roll Dice”这个说法容易让人觉得是夸张的批评。其实从工程角度看它是很准确的描述。一个生成模型在推理时通常要经过下面这些环节把输入文本转成 token 序列。模型前向计算输出下一个 token 的概率分布。按某种采样策略从概率分布中选出一个或一组 token。把新 token 拼到输入后重复直到结束。采样策略里最重要的参数是 temperature。temperature 越高分布越扁平低概率 token 被选中的机会越大输出越多样。temperature 越低输出越倾向于高概率 token但并不意味着完全消除随机性。即使在 temperature 等于 0 时很多推理框架也会因为浮点运算、批处理、并行调度、FlashAttention 实现差异导致输出不完全一致。更关键的是temperature0 选择最高概率 token只是让“单次采样”更确定并不保证“语义正确”“符合规范”或“一定不幻觉”。对垂直AI产品来说这种概率本质带来的直接后果是我们不能再用“跑通一个用例”来证明系统可用。可复现性、稳定性、错误率、失败兜底这些传统软件里最基础的能力在LLM应用中反而成了最需要设计的部分。2. 为什么单点看起来很好垂直落地却全面翻车2.1 垂直场景要求的是稳定可复用不是偶尔惊艳垂直AI和通用聊天机器人有一个本质区别垂直场景是为了稳定地重复完成一类任务。风险审核、代码审查、客服工单分类、合同条款提取这些任务要求的是“每次都达到及格线以上”而不是“十次里有一次惊艳”。在评估一个LLM应用时很多团队会陷入一个认知误区看到模型在某几个精心挑的例子上表现很好就认为它具备了相应能力。但真实业务数据分布很宽边缘情况很多而且LLM的输出波动会把“偶尔正确”放大成“不可预测”。打个比方这就像你请了一个很聪明但偶尔会走神的实习生。他每次完成任务的质量大概在70分到95分之间波动。对于一个低风险的文字润色任务这完全没问题但对于一个需要写入合同或影响订单状态的自动流程这种波动就是不可接受的。所以垂直AI的“翻车”往往不是模型一次性犯大错而是它在一个长周期里不断产生小概率错误。这些小概率错误单看不致命堆在每天几万次调用里就成了每天几十起需要人工介入的异常。2.2 随机性从哪来参数、上下文、外部知识、模型路由当你说“LLM输出不稳定”时不要急着怪模型。一定要先拆清楚随机性到底是从哪个环节进来的。我一般会按下面几个来源去查。采样参数。temperature、top_p、max_tokens、seed这些直接决定生成过程的随机程度。很多应用上线时根本没有冻结这些参数默认值可能偏向多样性这在对话场景没问题但在结构化输出场景可能造成字段时有时无。上下文动态部分。如果prompt里拼接了时间、用户输入、客服备注、session信息那么即使主任务相同模型看到的上下文也不同。有些场景需要这种动态但要注意动态部分本身会引入输出方差。外部知识检索。现在很多垂直应用都用了RAG。RAG的一个隐蔽问题不是“检索不到”而是“检索结果排序不稳定”。同一个query向量库返回的相关文档可能因为索引更新、Embedding版本、切片方式、重排模型变化而不同。检索结果一变LLM输出自然变。模型路由和版本。应用层可能配置了多个模型自动降级或者供应商后台做了灰度更新。你以为是同一个模型实际在跑的是不同版本。模型版本一变分布就变很多线上问题其实来自这里。在排查不稳定问题时建议先用固定日志把每次请求的模型版本、采样参数、输入摘要、RAG检索结果都记录下来。没有这份日志你很难判断输出波动是来自模型、检索还是prompt。2.3 更隐蔽的问题用确定性思维验收随机系统传统项目验收方式是准备一批测试用例跑一遍看通过率。但在LLM项目里这样做有两个致命缺陷。第一个缺陷是单次跑通过的用例不代表下次还能通过。如果你只用一组静态样例验收那你验收到的其实是“在特定随机种子和采样参数下的表现”而不是系统的真实分布。第二个缺陷是你只评估了“模型输出”是否正确没有评估“输出到业务动作”这一整条链路是否可靠。LLM生成的JSON字段被下游解析只要字段名偶尔变化下游就会崩。这种问题不是模型能力问题而是接口契约问题。更合理的验收方式应该是准备一个覆盖正常、边缘、异常三类样本的评估集在固定一组配置下多次运行记录输出分布计算关键指标的均值和方差。比如字段缺失率、格式错误率、语义一致性、需要人工介入的比例。只有把这些指标纳入验收你才是在验收一个随机系统。3. 构建垂直AI的正确姿势先接受随机再控制边界3.1 三层防护输入约束、输出校验、人工兜底既然LLM是随机引擎就不能指望它自己稳定。工程上能做的是在它外面套上确定性护栏。我一般把防护拆成三层。第一层是输入约束。在进入LLM之前先确定任务边界这个任务是不是只允许模型处理某类输入输入格式是否已经标准化长度、字段、数量有没有限制如果输入是合同可以先做PDF解析和章节切分只取出相关条款而不是把几百页原文直接丢给模型。输入越规整模型的输出方差越小。第二层是输出校验。LLM返回结果后不要直接信任。用代码做结构化校验必填字段是否存在枚举值是否合法格式是否是JSON或特定模板数字范围是否合理如果校验失败可以重试一次或者进入降级流程。输出校验层的价值是把概率问题转化成“可捕获的异常”。第三层是人工兜底。任何高风险的垂直场景都应该在流程上保留人工确认环节。这不丢人反而说明你理解了LLM的边界。自动生成初筛意见、人工复核确认是现在最成熟的落地方式。完全去掉人的流程至少在强合规场景里还不到时候。这三层不是可选项而是必选项。跳过任何一层都是在把随机性直接暴露给业务。3.2 温度、种子、评估集让实验可复现“可复现”是开源社区反复强调的词但在LLM应用开发里很多人反而不重视。我建议从第一天起就把下面这些配置固定下来写进工程规范。temperature结构化任务建议从0.0开始调不要直接从0.7起步。top_p如果需要更保守的输出可以配合temperature一起调。seed如果平台支持固定seed实验阶段一定要固定。不过要记住seed固定不代表跨版本一定可复现。模型版本在生产环境锁死模型版本不要用latest这种标签。prompt版本每次修改prompt都要记录版本号并跑一遍回归测试。外部知识版本RAG里的知识库、Embedding模型、切分方式都要版本化。同时建立你自己的小评估集。这个评估集不需要很大三五十个典型case覆盖正常、边界、异常三类。每一轮改动后用同一个评估集、同一组采样参数跑三到五遍记录输出。不是为了“验证效果”而是为了观察稳定性。3.3 一份可执行的LLM输出排查链路当线上出现输出不稳定、字段缺失、结果错误时建议按下面这个顺序排查而不是一开始就去改prompt。先看日志采样参数是什么模型版本是什么输入摘要是否完整RAG检索命中了哪些文档固定环境重跑把同样的输入、同样的配置、同样的知识库版本用固定seed重跑看是否稳定复现。切换输入动态部分把prompt里的时间、客服备注等变量去掉只保留核心输入看输出是否恢复稳定。这一步能判断是否上下文动态内容干扰。检查RAG检索将检索结果打印出来看排序是否稳定。如果同一query在不同时间命中的文档不一致问题可能在检索层。检查输出解析如果下游解析失败检查字段名、类型和枚举值是否变化。有些模型在长输出时会自行加引号或换行导致JSON解析失败。最后再动prompt前面的链路都排查完再调整prompt否则你很难知道改动到底解决了什么。这套排查链路本质上是在回答一个问题输出波动到底是模型造成的还是前面任意一层造成的把问题定位准确比盲目调参更有效。4. 垂直AI的准入线场景、成本、风险三维评估4.1 适合生成的场景低风险、强辅助、人审闭环垂直AI并不是不能做而是要选对场景。从我的经验看下面这几类场景现在更适合落地。第一类是“内容草稿生成”。比如营销文案初稿、周报生成、产品说明起草。这类任务允许一定程度的差异核心价值是帮人省去从空白页开始的时间。只要人有最终审阅和修改权随机性就是可控的。第二类是“知识辅助问答”。比如企业内部知识库搜索、研发手册问答、政策法规初步解释。这类场景的答案需要人来确认同时需要标注“仅供参考”。适合把LLM当检索增强助手而不是最终裁决者。第三类是“结构化数据提取”。从非结构化文本中抽取字段、实体、关系例如从简历里提取技能、从发票里提取金额。这类任务可以用强校验层把输出限制在固定Schema里即使模型偶尔出错也能被规则拦截。这几类场景有一个共同点LLM的输出不是直接产生业务结果而是作为“初稿”或“候选”进入后续流程。人还在链路上随机性就不会无限放大。4.2 不适合直接决策的场景强规则、强一致、强合规我也见过一些场景从一开始就不适合用LLM直接做决策但团队因为“大家都在做AI”而强行接入。比如涉及数字计算的场景。LLM擅长自然语言不擅长精确算术。即便看起来算对了也可能因为推理过程不同而中途出错。正确的做法是让LLM负责抽取算式用代码引擎执行计算。再比如强规则一致性的场景。优惠活动规则、权限判定、费率计算这类逻辑要求同一条件永远得到同一输出。LLM不适合用来做这类规则引擎至少不适合在缺少校验和回退方案的情况下直接承担。还有强合规和高风险场景。医疗诊断、征信审批、法律最终意见等直接让LLM输出结论风险高且难以追溯。这类场景更适合让LLM做信息整理、证据链汇总、倾向性提示最终结论由持证或负责人完成。不是所有“AI能懂”的任务都适合“AI负责”。垂直AI的价值不是替代规则系统而是在规则系统覆盖不到的开放语义空间里提供辅助。4.3 用“不确定性预算表”做选型我在实际评估一个垂直AI机会时会画一个“不确定性预算表”。不是看模型能力多强而是看业务能容忍多少不确定性。评估维度可以接受不确定性的低风险场景不能接受不确定性的高风险场景输出一致性同一问题多次回答可以略有差异同一问题必须给出同一结论错误容忍度偶发错误可由人审发现错误直接影响决策或交易可追溯性不需要解释完整推理过程必须保留证据、引用和决策依据人工介入成本可以安排人工快速复核人工复核成本高但必需规则覆盖程度规则无法穷尽的开放问题规则清晰可枚举合规压力内部辅助不对外承诺面向客户有强监管表格的用法是如果某个场景在右边一列占了三条以上就要谨慎。不要因为demo效果不错就冲进去。一个垂直AI产品能不能成立不是看模型答得好不好而是看整条业务链能不能容忍波动。预算里面不确定性是一种必须支付的成本。成本不能无限大。5. 从“AI替代人”回到“AI增强人”我的一些实操建议5.1 先跑通单点再做批量这是底线每次有团队问我垂直AI怎么落地我第一个建议都是不要一开始就规划宏大平台先选一个真正高频、低风险、反馈快的单点场景把整条链路跑通。这个单点要满足三个条件频率非常高大家每天都会遇到。错误后果可控即使输出错了也不会造成大事故。有明确的输入输出边界方便做校验。把单点跑通之后再观察指标调用失败率、人工介入率、输出一次性通过率。如果这三个指标稳定再考虑横向扩展。如果单点都不稳就不要扩。扩得越快滚雪球越大。“AI替代人”是结果不是起点。起点永远是“AI辅助人把人的一部分重复工作抽出来”。抽出来的前提是你已经为随机性设计好了退路。5.2 把一次性经验沉淀成可复用流程在垂直AI项目里真正值钱的资产不是 prompt也不是模型调参记录而是一套围绕随机引擎建立的确定性流程。这套流程包括每次调用的运行日志包含输入、采样参数、模型版本、知识库版本、输出和耗时。一套可重复运行的评估集覆盖正常、边界、异常三类输入。一个输出校验模板针对每个任务定义必填字段、类型、取值范围和兜底动作。一个人工复核SOP说明哪些情况必须人工哪些情况可以自动放行。一个结果反馈闭环持续从生产环境收集badcase每周更新评估集。有了这套流程你团队里的任何一个人换到项目里都能在一个下午恢复上下文。没有这套流程项目就会一直停留在“只有写prompt的人能维护”的状态。现在很多人在讨论LLM框架、Agent编排、知识库Wiki化背后其实都是同一个诉求把不确定性变成可观测、可控制、可迭代的工程对象。这种“工程化”程度才是垂直AI能不能长期跑下去的分水岭。5.3 回到开头那个判断再回到合同审核那个案例。后来我们做的事情很简单把LLM输出的审查意见从“最终结论”降级为“初筛建议”再用规则脚本校验必查条款最后强制人工确认风险条款。改动之后系统没有变得更“聪明”但错误率显著下降了。这才是垂直AI该有的样子。不要追求让模型变成永不犯错的业务大脑而是接受它是个聪明但会掷骰子的助手。你真正要做的是为每一次“掷骰子”设好边界能校验的校验能重试的重试必须交给人的就交给人。垂直AI泡沫会不会破不在于资本什么时候降温而在于我们什么时候愿意承认LLM roll dice。承认之后才会认真设计护栏才会把评估指标从“看一个demo”改成“看一段运行数据”才会让AI真正走进生产环境。先接受随机再谈智能。这听起来没有“AI替代人”带感但它才是垂直AI从demo到产品的那条窄路。