北京
把一次大模型调用写成一个函数，是教程里最常见的写法：传进文本，拿回答案，继续往下走。用久了，人很容易把它当成一个确定性的函数——同样的输入，永远给出同样的输出，就像在跑你的业务逻辑。
到了生产环境，这个假设会以一种非常具体、非常可预测的方式崩掉。值得把原因说清楚。
两种"正确"，不是一回事
传统软件跑的是确定性逻辑：输入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.
