宠物健康AI为何要把视觉模型与规则表分离

一个把肥胖猫评为「理想身材」的Bug

构建面向宠物主人的健康识别应用时，一个看似合理的做法是：让视觉模型直接给出结论——「这只猫需要立刻看兽医」或「这只猫身材理想」。然而这种架构隐藏着风险。一位开发者分享了自己踩过的坑：视觉模型将一只明显肥胖的猫评定为「体型理想」，而这个错误一旦直接暴露给用户，就可能延误真正的健康干预。

这个案例揭示了一个核心设计原则——视觉模型负责描述，而不负责决策。模型看到的是宠物粪便的颜色与形态、耳道的状况、牙龈的色泽，它的职责是把这些视觉特征转译成结构化描述；至于「这意味着什么」「是否需要就医」，则应交由模型永远不会直接改写的一张规则表来判断。

描述与判断为什么必须分开

把感知层和决策层耦合在一起，是许多AI应用早期最容易犯的错误。视觉模型的强项是识别图像中的模式，但它对「临床严重性」没有稳定、可审计的概念。当你让同一个模型既描述又下结论时，一旦它产生幻觉或误判，错误会直接传导到用户看到的建议里，而且难以定位。

将两者拆开后，架构变得清晰：

感知层：只输出可观察的事实

视觉模型的输出被限制为对可见特征的客观描述——粪便偏黑、耳道有分泌物、牙龈苍白。这一层不做价值判断，不给出「紧急」或「正常」的标签。这样做的好处是，模型的输出可以被单独验证，也更容易在出错时排查。

这种设计在机器学习工程中通常被称为「输出约束」（Output Constraining）或「结构化提示」（Structured Prompting）。实践中，开发者会通过精心设计的系统提示词（System Prompt）或 JSON Schema 强制要求模型只返回预定义字段——例如 stool_color、ear_discharge_level、gum_color 等枚举值，而不允许模型输出任何含有价值判断的自由文本。这与大型语言模型应用中「工具调用」（Tool Calling/Function Calling）的思路类似：把模型的输出锁定在机器可解析的格式内，后续逻辑由确定性代码接管。这样做的附带好处是，结构化输出天然便于日志记录和回溯分析，出现争议时可以精确重放模型在某次请求中「看到了什么」。

决策层：一张人类可读的规则表

真正决定「是否看兽医」的，是一张由领域知识驱动的规则表（a row in a table）。每一条描述特征对应到相应的处置建议，这张表由人来编写和审核，模型无法触碰。当规则需要修正时——比如发现某种粪便特征其实需要更高的警戒级别——只需改动表中的一行，而不必重新训练模型。

这种分层还带来一个隐性优势：可审计性。当出现「肥胖猫被评为理想」这样的错误时，你能立刻判断问题出在感知层（模型误判了体型）还是决策层（规则映射有误），从而快速止损。

这张「规则表」在工程实现上可以是数据库里的一张配置表、一个 YAML 文件，或是更复杂的规则引擎（如 Drools、Open Policy Agent）。其本质是将领域专家的判断逻辑外部化（Externalize），使其独立于任何机器学习模型而存在。这一模式在传统医疗信息系统中已有数十年历史——临床决策支持系统（CDSS）的核心正是由医生和医学专家编写、审核的知识库，而非黑盒模型。将 AI 的感知能力嫁接到这类经过验证的确定性架构上，既能获得视觉识别的灵活性，又保留了规则系统的可审计性与合规性，是目前高风险垂直场景中较为成熟的工程路径。

从这个案例能学到什么

对任何构建高风险AI应用的团队来说，这套思路都有借鉴意义。医疗、健康、安全等场景的共同点是：错误的成本很高，而模型的输出不能被盲目信任。

把「模型能做什么」和「系统该建议什么」严格区分开，本质上是在AI的概率性输出之外，保留一层确定性的、人类可控的逻辑。视觉模型可能会把肥胖猫看成理想身材，但只要决策规则独立存在，一个经过审核的体型评估标准就能拦截这类误判，而不至于让用户据此做出错误决定。

规则表带来的迭代灵活性

值得强调的是这套架构在维护上的优势。模型重训练成本高、周期长且结果难以预测，而规则表的调整是即时的、可版本化的、可回滚的。当业务方发现某类症状的判定标准需要收紧或放宽时，工程团队修改一行配置即可上线，无需触碰昂贵的模型管线。

对于宠物健康这类需要不断吸收兽医专业反馈的领域，这种「模型负责看、规则负责判」的分工，恰恰让专业知识能够持续、低成本地注入系统。

小结

这个来自Reddit的开发实践提醒我们：在把AI塞进关键决策链路之前，先问一句——「结论应该由模型给出，还是由人类可控的规则给出？」把描述和判断解耦，既降低了幻觉带来的风险，也让系统更透明、更易维护。那只被误评的肥胖猫，反倒成了一个绝佳的架构教训。