多模态决策模型技术实践：从商品图片审核到音视频智能路由

一、什么是多模态决策模型？

传统大语言模型（LLM）擅长生成自然语言。例如，输入一张商品图片，可以让模型描述商品的颜色、外形、材质，再从描述中提取信息。

但在很多实际业务场景中，我们并不需要模型生成一段文字，而是希望它直接回答几个明确的问题：

• 商品图片与标题是否一致？
• 用户上传的照片是否存在质量问题？
• 一段客服录音是否包含投诉意图？
• 某个监控视频是否需要转交人工审核？

这些问题的共同特点是：输入可能非常复杂，但输出是有限、明确、可被程序直接使用的决策。

这正是决策模型（Decision Model）要解决的问题。

OpenRouter 提供的 Decisions API 支持调用多种决策模型，例如 Cloudflare Clef、TypeSafe Jev 等。其中，支持图像、音频和视频输入的模型可以进一步构建多模态决策系统。

与传统生成式模型不同，决策模型接收两类核心输入：

1. state：需要判断的状态，可以包含文本、图片、音频、视频等。
2. questions：需要模型回答的问题，以及允许的答案范围。

模型返回结构化决策结果及其概率，而非自由生成的解释文本。

1.1 三种核心决策类型

例如，对于一张工业设备照片，可以一次提出三个问题：

{
  "questions": {
    "has_defect": {
      "type": "noul",
      "instructions": "设备是否存在明显的外观缺陷？"
    },
    "defect_type": {
      "type": "choice",
      "instructions": "最符合图片的缺陷类型是什么？",
      "criteria": {
        "scratch": "划痕",
        "crack": "裂纹",
        "deformation": "变形",
        "none": "未发现明显缺陷"
      }
    },
    "severity": {
      "type": "score",
      "instructions": "评估设备外观缺陷的严重程度",
      "criteria": [
        "没有明显缺陷",
        "轻微缺陷",
        "严重缺陷"
      ]
    }
  }
}

这些问题可以在一次请求中同时完成。

这有两个重要优势：

第一，不必生成冗长的中间文字。

传统方案往往需要先调用视觉大模型生成图片描述，再调用分类程序完成判断。决策模型可以直接围绕预设答案进行评估。

第二，输出天然适合程序处理。

例如，对于缺陷判断，如果模型返回的 noul 值为 0.95，业务程序可以根据预先设定的规则，把图片送往人工复核队列。

需要注意：0.95 是模型给出的概率估计，不等于经过业务数据验证的实际正确率。生产系统仍需进行概率校准和阈值验证。

二、模型与技术架构

2.1 可以选择哪些模型？

截至 2026 年 10 月，OpenRouter 的多模态决策文档列出了以下代表性模型：

其中：

• Clef-flash：适合成本敏感的文本和图像分类任务。
• Clef：适合希望评估另一种模型在图文决策任务上表现的场景。
• Clef-omni：适合需要联合处理文本、图像、音频及视频的场景。
• Jev：适合结构化决策、路由及评分任务，新版本还具有特定的视觉定位能力。

具体选型仍应依据实际准确率、P95 延迟、吞吐量和成本进行测试，而不能仅根据模型名称判断。

2.2 典型技术架构

业务输入
  │
  ├── 文本
  ├── 图片
  ├── 音频
  └── 视频
        │
        ▼
多模态数据预处理
  │
  ├── 图片压缩与编码
  ├── 音频格式转换
  └── 视频截取与编码
        │
        ▼
构造 State + Questions
        │
        ▼
OpenRouter Decisions API
        │
        ▼
结构化决策结果
  │
  ├── 二元概率
  ├── 分类概率分布
  └── 等级评分
        │
        ▼
业务规则与阈值判断
  │
  ├── 自动处理
  ├── 人工复核
  └── 其他模型进一步分析

注意，这里的“路由”主要指根据模型输出决定业务处理路径，并不意味着 OpenRouter 会自动替应用选择最合适的下游处理流程。

下面通过两个典型案例说明具体实现方式。

三、实践案例一：电商商品标题与图片一致性审核

3.1 业务背景

这是 OpenRouter 多模态决策文档提供的典型应用方向。

假设我们正在开发一个电商平台，用户发布商品时，需要提交：

• 商品标题
• 商品图片

平台希望自动判断：

1. 商品图片是否符合标题描述？
2. 图片中的商品主要是什么颜色？
3. 是否需要进入人工审核？

例如：

商品标题：红色方形贴纸

上传图片：一张商品照片。

传统方案可能首先调用视觉语言模型生成图片描述，然后对图片描述与商品标题进行语义匹配。

这种方法可以实现，但会产生额外的文本生成、解析和判断环节。

使用多模态决策模型，则可以直接输入标题和图片，让模型回答预定义问题。

3.2 构造 API 请求

我们选择：

cloudflare/clef-flash

请求方法：

POST /api/alpha/decisions

以下代码为简化的请求体：

{
  "model": "cloudflare/clef-flash",
  "state": [
    "商品标题：红色方形贴纸",
    {
      "type": "image_url",
      "image_url": {
        "url": "data:image/png;base64,这里填写图片的Base64内容"
      }
    }
  ],
  "questions": {
    "matches_title": {
      "type": "noul",
      "instructions": "图片中的商品是否与商品标题一致？"
    },
    "color": {
      "type": "choice",
      "instructions": "图片中商品的主要颜色是什么？",
      "criteria": {
        "red": "红色",
        "green": "绿色",
        "blue": "蓝色",
        "other": "其他颜色或无法判断"
      }
    }
  }
}

这里需要关注两个技术细节。

首先，state 可以是数组，其中既有普通字符串，也有表示图像的对象。

其次，questions 可以同时包含不同类型的问题。模型能够在一次请求中给出多个判断结果。

3.3 Python 实现

首先安装依赖：

pip install requests

然后到 OpenRouter 网站的 API Keys 页面创建密钥，到 API 文档的 Decisions 页面获取完整接口地址，并将二者设置为环境变量：

OPENROUTER_API_KEY

DECISIONS_API_ENDPOINT

编写 Python 程序：

import os
import base64
import requests

# 获取 API 配置
API_KEY = os.environ["OPENROUTER_API_KEY"]
ENDPOINT = os.environ["DECISIONS_API_ENDPOINT"]

# 读取图片并编码
with open("product.png", "rb") as f:
    image_base64 = base64.b64encode(
        f.read()
    ).decode("utf-8")

# 构造决策请求
payload = {
    "model": "cloudflare/clef-flash",

    "state": [
        "商品标题：红色方形贴纸",
        {
            "type": "image_url",
            "image_url": {
                "url": (
                    "data:image/png;base64,"
                    + image_base64
                )
            }
        }
    ],

    "questions": {
        "matches_title": {
            "type": "noul",
            "instructions": (
                "图片中的商品是否与"
                "商品标题一致？"
            )
        },
        "color": {
            "type": "choice",
            "instructions": (
                "图片中商品的主要颜色是什么？"
            ),
            "criteria": {
                "red": "红色",
                "green": "绿色",
                "blue": "蓝色",
                "other": "其他或无法判断"
            }
        }
    }
}

# 发起请求
response = requests.post(
    ENDPOINT,
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    },
    json=payload,
    timeout=30
)

response.raise_for_status()

result = response.json()

print(result["answers"])

以上代码中的 product.png 是本地图片文件，接口地址由环境变量提供，因此代码中不需要写入任何网络地址。

3.4 解析模型输出

假设模型返回以下结果：

注意：以下数值为演示结构而构造的示例，并非实际 API 测量结果。

{
  "answers": {
    "matches_title": {
      "type": "noul",
      "noul": 0.96
    },
    "color": {
      "type": "choice",
      "choice": "red",
      "probabilities": {
        "red": 0.97,
        "green": 0.01,
        "blue": 0.01,
        "other": 0.01
      },
      "confidence": 0.94
    }
  }
}

我们可以得到：

• 标题与图片匹配的模型估计概率为 96%。
• 图片颜色最可能是红色，对应概率为 97%。
• 模型返回了完整的候选类别概率分布。

这里的 confidence 是模型响应中的另一个字段，不应未经验证就直接当成最高类别概率使用。

3.5 将概率转化为业务路由

在生产环境中，得到模型输出还不够。

真正重要的是将结果转化为可执行的业务逻辑。

例如，可以设计如下演示规则：

answers = result["answers"]

p_match = answers["matches_title"]["noul"]

color_probs = answers["color"]["probabilities"]

p_red = color_probs["red"]

if p_match >= 0.90 and p_red >= 0.90:
    action = "进入自动审核通过候选队列"

elif p_match <= 0.20:
    action = "转人工重点复核"

else:
    action = "进入常规人工复核"

print("处理动作：", action)

阈值 0.90 和 0.20 只是演示值，不是模型官方推荐的生产阈值。

真实系统需要结合误放行成本、人工审核资源和历史样本确定阈值。

这个案例的价值在于：无需先生成商品描述，模型就可以直接对图文一致性进行结构化判断，并触发后续业务流程。

四、实践案例二：设备安装验收中的图像、音频、视频联合决策

4.1 业务背景

第二个案例来自 Cloudflare 2026 年 10 月发布的 Clef-omni 多模态技术演示。

假设某企业需要远程检查安装完成的设备。

验收人员要求现场工作人员提交：

1. 一张设备外观照片。
2. 一段设备运行声音。
3. 一段设备风扇运行视频。

传统 AI 系统可能需要分别调用：

• 图片识别模型，检查铭牌。
• 音频模型，识别是否存在异常机械噪声。
• 视频理解模型，判断风扇是否运转。

最后再把三类结果聚合到一个业务系统中。

这种方案技术上可行，但涉及多个模型、多个接口以及额外的数据处理。

使用 cloudflare/clef-omni，则可以通过一次决策请求对三种媒体输入进行联合分析。

4.2 设计决策问题

我们希望回答：

进一步还可以加入一个 choice 问题，判断应该进入常规验收、补充资料还是重点人工检查。

但为了突出多模态输入，我们先实现三个独立的二元判断。

4.3 API 请求结构

使用：

cloudflare/clef-omni

请求体结构如下：

{
  "model": "cloudflare/clef-omni",

  "state": [
    "检查设备安装后的运行状态",

    {
      "type": "image_url",
      "image_url": {
        "url": "data:image/png;base64,设备图片"
      }
    },

    {
      "type": "input_audio",
      "input_audio": {
        "data": "设备音频的原始Base64内容",
        "format": "mp3"
      }
    },

    {
      "type": "video_url",
      "video_url": {
        "url": "data:video/mp4;base64,设备视频"
      }
    }
  ],

  "questions": {
    "label_visible": {
      "type": "noul",
      "instructions": "照片中设备铭牌是否清晰可见？"
    },

    "sounds_normal": {
      "type": "noul",
      "instructions": "设备运行声音是否正常，没有明显的异响、撞击或摩擦声？"
    },

    "fan_running": {
      "type": "noul",
      "instructions": "视频中的设备风扇是否正在运转？"
    }
  }
}

这里有一个非常容易出错的细节。

Cloudflare 原生 Workers AI 接口的部分示例使用独立的 images、audio、videos 字段。

但通过 OpenRouter 的 Decisions API 调用时，应该按照 OpenRouter 的格式，把对应的多媒体对象放入顶层 state 数组。

因此，两个服务的请求体不能完全照搬。

4.4 Python 实现

假设本地已有三个文件：

device.png
device.mp3
device.mp4

它们分别对应照片、声音和视频。

以下程序沿用案例一设置的 API 环境变量。

import os
import base64
import requests

API_KEY = os.environ["OPENROUTER_API_KEY"]
ENDPOINT = os.environ["DECISIONS_API_ENDPOINT"]


def encode_file(path):
    """读取文件，转换为Base64字符串"""
    with open(path, "rb") as f:
        return base64.b64encode(
            f.read()
        ).decode("utf-8")


# 读取多模态文件
image_data = encode_file("device.png")
audio_data = encode_file("device.mp3")
video_data = encode_file("device.mp4")


# 构建请求
payload = {
    "model": "cloudflare/clef-omni",

    "state": [
        "检查设备安装后的运行状态",

        # 图像
        {
            "type": "image_url",
            "image_url": {
                "url": (
                    "data:image/png;base64,"
                    + image_data
                )
            }
        },

        # 音频
        {
            "type": "input_audio",
            "input_audio": {
                "data": audio_data,
                "format": "mp3"
            }
        },

        # 视频
        {
            "type": "video_url",
            "video_url": {
                "url": (
                    "data:video/mp4;base64,"
                    + video_data
                )
            }
        }
    ],

    "questions": {
        "label_visible": {
            "type": "noul",
            "instructions": (
                "照片中设备铭牌是否清晰可见？"
            )
        },

        "sounds_normal": {
            "type": "noul",
            "instructions": (
                "设备运行声音是否正常，"
                "没有明显的异响、撞击或摩擦声？"
            )
        },

        "fan_running": {
            "type": "noul",
            "instructions": (
                "视频中的设备风扇是否正在运转？"
            )
        }
    }
}


# 调用 OpenRouter
response = requests.post(
    ENDPOINT,
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    },
    json=payload,
    timeout=60
)

response.raise_for_status()

result = response.json()

print(result["answers"])

这段程序实现了：

一次 API 调用，同时输入图片、音频、视频，并回答三个结构化业务问题。

与逐个调用不同模态模型的方案相比，这种方式可以简化业务编排逻辑。

但由于视频解码和多模态编码仍然存在计算开销，不能直接推断其端到端延迟一定小于多个专用模型组成的系统。

4.5 设计业务决策规则

假设模型返回：

{
  "answers": {
    "label_visible": {
      "type": "noul",
      "noul": 0.98
    },

    "sounds_normal": {
      "type": "noul",
      "noul": 0.42
    },

    "fan_running": {
      "type": "noul",
      "noul": 0.96
    }
  }
}

以上为模拟响应。

可以解读为：

• 铭牌清晰可见的估计概率较高。
• 设备声音正常的概率只有 42%，存在较大不确定性。
• 风扇正在运行的估计概率较高。

接下来，可以编写一个简单的业务路由函数：

answers = result["answers"]

probabilities = [
    answers["label_visible"]["noul"],
    answers["sounds_normal"]["noul"],
    answers["fan_running"]["noul"]
]

if all(p >= 0.90 for p in probabilities):
    action = "常规验收队列"

elif any(p <= 0.20 for p in probabilities):
    action = "重点人工检查队列"

else:
    action = "补充材料或人工复核队列"

print("设备验收路由：", action)

在本例中，由于设备声音正常的概率只有 0.42，设备会进入补充材料或人工复核队列。

需要强调的是，这种模型适合做初步筛查和任务分流，不应仅凭模型概率判断设备是否达到安全运行标准。关键设备仍应依据检验规范和实测数据验收。

4.6 为什么这个案例有价值？

它体现了多模态决策模型与传统单模态分类系统的重要差异。

一是统一输入。

文本、图像、音频和视频不再必须被拆分到不同的模型服务中。

二是统一决策接口。

不同模态的信息最终进入同一组结构化问题。

三是联合判断的潜力。

例如，视频显示设备正在运行，但音频中存在异常声音。这些信息可以共同用于判断设备是否需要进一步检查。

不过，如果业务需要精确确定异响发生的时间点、识别微小部件缺陷或者完成复杂的因果诊断，仍可能需要专门的识别模型、信号处理算法或生成式多模态模型。

五、落地实践中需要注意的问题

5.1 多模态输入格式不是完全一致的

在 OpenRouter Decisions API 中，不同模态有不同的数据格式。

图像必须按照文档要求进行 Base64 编码，不能直接提供网络图片地址并期待服务端自行下载。

5.2 多模态输入存在数量和大小限制

以 OpenRouter 当前公布的规则为例：

• Clef、Clef-flash、Clef-omni 单次最多接收 4 张图片。
• Clef-omni 单次最多接收 4 段音频和 2 段视频。
• 单段音频最长 300 秒，最大 8 MiB。
• 单段视频最长 60 秒，最大 16 MiB。
• 音视频解码后的总大小不能超过 16 MiB。
• Clef-omni 对视频按每秒 2 帧采样。

这意味着它适合短音视频的结构化决策，但不适合把数小时的长视频直接作为一次完整请求。

对于长视频，更合理的方案是先分段，再根据业务需要对每个片段进行判断。

5.3 决策概率不代表绝对置信度

如果模型返回：

{
  "choice": "complaint",
  "probabilities": {
    "complaint": 0.85,
    "consultation": 0.10,
    "other": 0.05
  }
}

我们可以说，模型认为 complaint 是最可能的类别，概率估计为 0.85。

但不能直接说该判断有 85% 的实际正确率。

生产环境应该准备包含人工标注的数据集，评估：

• Accuracy：总体分类准确率。
• Precision：各类判断的精确率。
• Recall：各类判断的召回率。
• Macro-F1：类别不均衡时的综合分类表现。
• ECE、Brier Score：概率校准情况。
• P50、P95：接口延迟分布。
• 单次请求成本和吞吐量。

特别是在需要根据阈值进行自动路由的系统中，概率校准比单纯观察准确率更重要。

5.4 不应把结构化决策模型当作通用视觉理解模型

决策模型更适合回答：

图片中是否存在裂纹？

而不是：

请详细分析这张图片里的所有机械结构，并提出完整维修方案。

前者的答案空间明确，适合二元判断。

后者需要开放式描述、复杂推理以及专业知识，更适合生成式多模态模型。

两者并不是完全替代关系。

在实际架构中，可以采用：

多模态输入
     │
     ▼
轻量决策模型
     │
     ├── 高确定性、低风险结果
     │         │
     │         ▼
     │      自动处理
     │
     └── 不确定或复杂结果
               │
               ▼
       更强的多模态理解模型
               │
               ▼
           人工复核

这样的分层架构有机会在准确率、成本和延迟之间取得更好的平衡。

但是否真正优于单模型方案，需要通过真实业务数据验证。

六、总结：多模态决策模型适合解决什么问题？

通过以上两个案例，可以总结出多模态决策模型的主要定位。

案例一说明：对于商品标题和图片的一致性审核，多模态决策模型可以直接完成图文匹配和类别判断。

案例二说明：对于设备运行检查，可以将照片、声音和视频整合进同一个决策请求，减少传统多模型工作流中的部分编排环节。

二者背后的共同思想是：

将复杂的多模态信息理解任务，转化为一组具有明确答案空间、可输出概率、可由程序执行后续动作的决策问题。

在需要高吞吐、低延迟、结构化输出和自动化业务处理的场景中，这是一条值得实际评测的技术路线。

不过，模型的实际价值最终取决于业务数据上的分类质量、概率校准、端到端延迟以及错误决策成本，而不只是它能否返回一个看起来合理的概率。