在教程中，我们经常将大模型的调用描述为一个函数：输入文本后得到响应并继续执行后续任务。长时间使用后，我们很容易将其视为一种确定性的函数——相同的输入总是能产生相同的输出，就像处理我们的业务逻辑一样。然而，当这种假设应用在生产环境中时，问题会以一种非常具体且可预见的方式显现出来。这一现象的原因值得深入解析。

确定性与统计概率之间的差异并非无关紧要。传统软件基于明确的逻辑：输入A符合条件B时，输出C，这是一个重复不变的过程，且可以在白板上清晰展示给他人。而大模型则基于统计概率：它通过分析训练数据中的模式预测下一个最可能出现的词。这两者的"正确"性质存在根本区别。当一个团队迫使第二种机制去执行第一种任务时，问题便产生了。

以发票处理为例：我们设想一个流程，从一组发票中提取细节，然后通过同一模型调用进行简单的计算并加税，最终返回总金额。在简短且清晰的发票上，模型几乎每次都是正确的，因为简单的算术运算在训练数据中频繁出现，模型易于匹配。然而，当面对一张包含40行、混合税率并带有舍入规则的复杂发票时，模型只能在“大多数情况下正确”。这种模糊的“正确”与“真正确”之间存在巨大差距，且后者的错误更加严重。错误的结果看似合理，实际上却是错误的，而这种错误在经历对账之前通常是无法发现的。

接着，考虑一个业务规则：购买后30天内可退款。将该规则转化为模型提示，要求其判断每单是否符合条件。在简单的示例中，模型判断相对准确：半年前购买的显然不可退款，昨天购买的自然可以。问题出现的边界条件，例如第29天、第30天与第31天的判断，因跨时区导致的时间戳格式差异，使得模型的判断变得复杂。确定性的日期判断保证了每次的结果都是正确的，而大模型只能基于其训练数据中退款决定的表达方式，去推测“临界范围内的退款判断”。即便其有十次中九次能正确输出，操作的本质仍然截然不同。

这种失败模式的危害不仅仅令人烦恼，因为统计上错误的答案与正确答案在外观上是难以区分的。它们具备相同的JSON结构、同样的自信语气，且没有抛出异常。响应本身并未携带任何信息来提示你这是基于猜测而非计算的结果。我们往往是在事后——通过客服反馈或财务对账中才意识到这些差异，而并非从日志信息里获取。

这并不是说不可以在业务逻辑中使用模型，而是要清楚地知道自己将哪部分工作交给了它。模型最擅长的领域是将非结构化数据转化为结构化数据。而对于那部分需要严格一致性的任务，模型从未真正承担过这种责任。