北京
把大模型当成一个函数来调用，是教程里最常见的写法：传进一段文字，拿回一个答案，然后继续往下走。这种写法太顺手了，顺手到很多人会下意识地认为，模型在评估业务逻辑时，和普通函数一样是确定性的——同样的输入，永远得到同样的输出。
在生产环境里，这个假设会以一种非常具体、非常可预测的方式崩掉。值得把原因说清楚。
两种"正确"，不是一回事
传统软件跑的是确定性逻辑：输入A满足条件B，就输出C，每一次都如此，而且这个过程可以写在白板上证明给你看。大模型跑的是统计概率：它根据训练数据里的模式，预测下一个最可能出现的词元。这是两种完全不同的"正确"。
摩擦恰好出现在一个团队让第二种正确去干第一种正确的活的时候。
下面这些是这类失败在真实系统里会呈现出的典型形态，是基于失败模式的示意场景，不是某一次具体事故。
发票算税：从"几乎全对"到"大部分时候对"
假设一条流水线先从一批发票里抽取明细行，然后让同一个模型调用顺便算出小计、套上税率、返回总额。
在短小简单的发票上，它几乎每次都对——因为短而简单的算术在训练数据里出现得极多，也极容易被模式匹配。但换成一张40行、混合税率、还带一条舍入规则的发票，它就开始"大部分时候对"了。这和"对"是两件完全不同的事，而且是更糟的那件。
没有任何地方抛错。那个数字只是看起来合理，而不是正确。而"看起来合理而不是正确"这件事，在有人去对账之前是完全隐形的。
退款边界：第29天、第30天、第31天
假设业务规则是"购买后30天内可以退款"。把这条规则写进提示词，让模型逐个判断资格，简单情形它都能答对：半年前买的，显然不行；昨天买的，显然可以。
有意思的地方在边界上：第29天、第30天、第31天，跨时区，购买时间戳是一种格式，而传入的当天日期又是另一种格式。确定性的日期比较，从构造上就保证每一次都对。而模型做的是根据训练数据里那些退款决策的表述方式，去猜"一个靠近边界的退款决策"长什么样。哪怕它十次里有九次碰巧输出了正确答案，这也是一次性质完全不同的操作。
危险之处：错的答案和对的答案长得一模一样
这才是这种失败模式危险而不只是烦人的原因：一个统计出来的错误答案，和一个正确答案在外观上没有任何区别。同样的JSON结构，同样笃定的语气，同样没有异常抛出。
响应本身不包含任何信号，告诉你这是一次猜测而不是一次计算。你是后来从客服升级工单或者财务对账里发现的，而不是从日志里发现的。
这些都不意味着不能让模型靠近你的业务逻辑。它意味着，你得精确地知道，这份工作里你交给它的是哪一半。
模型擅长的是把非结构化的东西转成结构化的东西——这部分它做得很好。至于需要确定性结果的那一半，交给确定性的代码。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
