模型为什么不被允许编造编码

我们做关务 AI 的第一条规矩，就是不许模型自由发挥。在 Urgenth 的代码库里，生成自由度是被物理掐死的。

上一篇现场笔记里我们写过，先懂行业，再谈 AI。这一篇说具体做法，讲讲这句话怎么落进我们的系统架构里。

Urgenth 是我们自研的关务工具，做的事情很明确：输入货物的商业描述，输出合规的 HS 编码。在普通聊天软件里，模型说胡话顶多是个笑话；但在报关场景里，幻觉是一场直接的事故。

HS 编码错一位，对应的税率就全错了。申报税率一错，要么多缴关税，要么少缴关税。多缴了直接亏损成本，少缴了海关查验直接面临补缴和罚款。

很多 AI 团队不敢碰关务、医疗或者财务这种高风险场景，核心原因就是模型不可控。大模型本质上是个概率生成器，你让它自由发挥，它就会在没有对应知识的时候，凭空编造一个看似合理的编码交差。

现场不需要概率意义上的合理，现场只要确定性。解决不可控的办法不是等模型变得更聪明，而是用架构把它的手脚捆住。我们用的方案是约束生成，而不是自由生成。

具体到 Urgenth 的架构，我们把归类任务拆成了两步：检索先行，生成受限。

第一步，模型不负责直接给编码。用户输入一段产品描述，模型只做一件事情：把这段自然语言拆解，提炼出符合海关规范的关税术语。

拿到关税术语之后，系统不让模型往下猜，而是直接去撞美国官方的 HTS 数据库。我们对接了 USITC 的公开接口，按提取出的术语去拉取真实有效的候选编码，包括完整的 4 位 heading 子树。

第二步，是严格受限的选择题。我们把从 USITC 接口查到的候选子树重新送回模型，并立下一道硬边界：模型只能从这些官方已经存在的编码里做选择，绝对不能自己拼凑。

只要候选集里没有，模型一个字符都不准多写。选出准确的编码之后，程序再去解析对应的子码税率。整个链路里，模型没有一秒钟拥有随意输出数字的权限。

这样设计看起来不那么神奇，但很管用。很多做大模型应用的人迷信端到端，觉得把 prompt 写得天花乱坠就能解决问题，结果在工业现场错漏百出。

在高风险场景下，模型越自由，工程就越危险。真正的 AI 落地，不是看你选的模型参数有多大，而是看你敢不敢给模型划死边界。

划边界的能力，来自你对业务的理解。你必须知道 USITC 的数据结构长什么样，知道 4 位 heading 怎么展开，知道海关规则在哪个环节最容易出偏差。把这些行业知识做成铁笼子，模型才能在里面安全地干活。