从“看图”到“打分”：食品安全智能体的工程化落地实践

一、问题背景：后厨监管为什么需要智能体

餐饮后厨监管长期面临三个结构性难题：人力覆盖不足、判断标准不一、证据难以留存。传统人工巡检依赖监管人员现场目视，一次巡检只能覆盖有限时段与有限区域；不同人员对“地面脏乱”“食品散落”的判定尺度存在差异，导致评分缺乏可比性；纸面记录与口头反馈难以形成可回溯的证据链。

要解决这些问题，单点算法（如目标检测模型）并不够用。真正的需求是一条完整链路：发现问题 → 给出评价 → 指导整改 → 留存记录。这正是“智能体（Agent）”形态的用武之地——它不是单一模型，而是围绕垂类大模型构建的、具备工具调用与任务编排能力的系统。食品安全垂类模型经由行业数据微调，在违规类别语义、评分口径上比通用模型更稳定，再由智能体编排识别、研判、评分、归档等多个环节，形成可运行的业务闭环。

二、整体架构：四层能力与四大功能

从工程视角看，这类系统可抽象为四层：

1. 接入层：接收后厨摄像头抓拍图、巡检任务、整改反馈等输入，统一鉴权与限流。
2. 智能层：垂类多模态大模型承担图像理解与违规研判；规则引擎承担量化评分；检索与知识库承担合规条款匹配。
3. 编排层：智能体负责任务分解、工具调用顺序、异常重试与结果聚合。
4. 数据层：对象存储保存原始图像与证据快照，关系库保存评分与工单，日志服务保存全链路审计记录。

对应到业务功能，即原文所述的四大能力：智能研判找问题、量化评分作评价、合规指导促整改、全程可溯留记录。值得注意的是，四者并非并列模块，而是串在同一条数据流上的四个阶段——前一段的输出是后一段的输入，任一阶段的结构化程度不足，都会导致下游能力退化。因此设计的核心是：让图像在每一阶段都被转化为结构化数据，而非停留在自然语言描述层面。

三、视觉识别流水线：把图像变成可量化数据

3.1 输入预处理与区域建模

后厨场景的复杂性在于：同一张图里可能同时出现操作台、地面、垃圾桶、冷柜等多个语义区域，而不同区域的违规判定标准完全不同——“地面有水渍”与“冷柜内食材裸露”属于不同条款。因此预处理阶段需要先完成区域划分，常见做法是结合摄像头安装位置预先标注感兴趣区域（ROI），或使用分割模型在线推断区域掩码。

# 示意：区域裁剪与元数据绑定（伪代码）
def build_region_payload(frame, roi_config):
    regions = []
    for roi in roi_config:
        crop = frame.crop(roi.bbox)
        regions.append({
            "region_id": roi.id,
            "region_type": roi.type,   # floor / worktop / fridge / bin
            "image": crop,
            "captured_at": frame.ts,
            "camera_id": frame.camera_id
        })
    return regions

3.2 多模态研判：从开放描述到受控输出

通用多模态模型在描述图像时倾向输出自由文本，这对下游评分不友好。垂类模型的优势在于：微调后可以按受控标签体系输出，例如将问题归入“环境脏乱”“食品散落”“交叉污染风险”“人员着装不规范”等固定类别，并附带置信度与位置框。工程上通常要求模型输出结构化 JSON，并用 schema 校验兜底：

{
  "violations": [
    {
      "category": "environment_dirty",
      "sub_type": "floor_debris",
      "region_id": "roi_floor_01",
      "confidence": 0.91,
      "evidence_bbox": [120, 340, 260, 410],
      "description": "地面存在散落食物碎屑"
    }
  ],
  "scene_quality": {"blur": 0.05, "occlusion": 0.12}
}

这里有两个容易被忽视的工程细节：其一，置信度阈值与人工复核分流——低置信度结果应进入人工复核队列，而非直接计入评分，否则误报会迅速侵蚀系统可信度；其二，图像质量门控——模糊、遮挡、逆光图像应先被拒绝或降权，避免模型在劣质输入上产生幻觉式判断。

3.3 时序与去重

后厨摄像头是连续采集的，同一处地面污渍可能在多帧中出现。若逐帧计分，会导致同一问题被重复扣分。常见方案是引入时间窗口聚合与空间去重：在滑动窗口内按区域与类别聚类，保留置信度最高的证据帧作为代表，并记录持续时间。持续时间本身也是有价值的量化指标——短暂水渍与长期堆积的卫生隐患，严重程度显然不同。

四、量化评分：规则引擎与模型的分工

评分环节最忌讳“让大模型直接给分”。大模型的优势在语义理解与开放场景泛化，弱势在数值一致性与可复现性。更稳妥的架构是模型负责识别与归类，规则引擎负责计分：

• 权重表：每个违规类别配置基础扣分权重，可按业态（正餐、快餐、饮品店）差异化。
• 严重度修正：结合违规面积占比、持续时长、是否涉及直接入口食品等因子做乘数修正。
• 归一化：将扣分映射为百分制或分级（优/良/合格/整改），保证跨门店可比。
• 可解释输出：每条扣分项必须回链到证据帧与条款编号，否则评分无法用于执法或申诉。

# 示意：可解释评分函数（伪代码）
def score(violations, weights, policy):
    total = 0.0
    items = []
    for v in dedup(violations):
        base = weights[v.category]
        severity = policy.severity_factor(v)
        deduction = base * severity
        total += deduction
        items.append({
            "category": v.category,
            "deduction": round(deduction, 2),
            "evidence_id": v.evidence_id,
            "clause_ref": policy.clause_of(v.category)
        })
    return {"score": max(0, 100 - total), "items": items}

这种分工带来的直接收益是可审计：评分结果不是黑箱，任何一分扣减都能追溯到图像证据与规则版本。规则版本号必须与评分结果一同落库，否则历史评分在规则调整后将无法解释。

五、闭环整改与全程可溯

5.1 合规指导：从“指出问题”到“给出动作”

仅仅输出违规标签对商户的帮助有限。智能体可基于知识库检索对应条款与整改建议，生成面向门店人员的行动清单，例如“清理地面散落物并检查垃圾桶加盖情况，2 小时内上传整改后照片”。这里的关键是建议必须可执行、可验证：每条建议应绑定一个可再次拍摄验证的检查点，形成“问题—动作—复检”的闭环。

5.2 证据链与审计日志

可追溯性要求三类数据同时留存：原始图像（含时间戳与设备标识）、模型输出（含模型版本与置信度）、评分与规则版本。三者通过统一的事件 ID 关联，写入日志服务并归档至对象存储。审计时应能回答：某次评分依据了哪几张图、由哪个模型版本产生、适用哪版规则。这不仅是合规需要，也是模型迭代时做离线评测的数据基础。

5.3 反馈回流

人工复核结果与商户申诉结论应作为标注数据回流，用于垂类模型的持续微调与规则权重校准。建议建立月度回归评测集，在模型或规则变更前跑一遍固定样本，防止指标漂移。

六、工程实践建议与常见陷阱

1. 先定标签体系，再谈模型选型。标签粒度决定了下游评分与整改建议的表达能力，过早锁定模型会限制业务扩展。
2. 把不确定性显式化。置信度、图像质量分、复核状态都应作为一等字段存储，而非隐式处理。
3. 警惕“全自动”预期管理。高风险判定（如涉及直接入口食品的污染）建议保留人工确认环节，系统定位为“提效”而非“替代”。
4. 关注端侧与带宽成本。高频抓拍场景下，可在边缘侧做初步筛选与压缩，仅将候选帧上传云端，降低存储与推理开销。
5. 接口幂等与重试。巡检任务可能因网络抖动重复提交，事件 ID 需保证幂等，避免重复计分。

七、小结

食品安全智能体的技术本质，是把非结构化的视觉信息转化为可计算、可解释、可追溯的结构化数据，并以此支撑评分、整改与审计。对开发者而言，落地重点不在追逐单一模型的榜单表现，而在流水线的工程严谨性：受控输出、规则与模型分工、证据链完整、反馈闭环。这四点做到位，系统才具备从演示走向生产的基础。