AI Gateway User Insights 新增了任务、模型、对话轮次和用户四类分析维度。对团队来说，这不只是多了几张统计图，而是能更具体地回答一个成本治理问题：哪些请求确实需要昂贵或能力更强的模型，哪些请求正在被“默认配置”推向过度使用。
这项能力对 AI Gateway 用户免费开放，因此适合先用于建立使用基线，再逐步调整模型路由，而不是一上来就限制调用。
四个维度如何拼出真实使用情况
单看模型调用次数，很容易得出错误结论。例如，某个高级模型占据了 80% 的请求，并不必然意味着浪费：如果大部分任务都是复杂代码生成或长文档推理，这个比例可能合理。
新增维度让团队可以把调用量拆开来看：
- 任务（task）：区分摘要、分类、抽取、代码生成、复杂推理等工作负载。
- 模型（model）：观察不同任务实际使用了哪些模型，以及模型份额是否异常集中。
- 轮次（turn）：判断一次任务需要多少轮交互。轮次持续偏高，可能意味着提示词不清晰、模型能力不匹配，或者应用缺少必要上下文。
- 用户（user）：识别使用模式来自少数高频用户，还是整个团队的默认行为。
四个维度组合后，分析才真正有行动价值。例如：
| 观察结果 | 可能原因 | 可验证的治理动作 |
|---|---|---|
| 文本分类几乎全部使用高级模型 | 路由规则只有一个默认模型 | 用小模型做离线准确率对比 |
| 某类任务平均轮次很高 | 提示词不完整或首轮结果质量不足 | 补充结构化输入与输出约束 |
| 少数用户产生大量高级模型请求 | 自动化脚本、测试循环或异常重试 | 检查调用来源并设置预算告警 |
| 所有任务都落到同一模型 | 应用没有按任务分流 | 增加任务标签和路由策略 |
需要注意的是，这些现象只是调查入口，不是自动定罪规则。模型成本高并不等于使用不合理，低价模型也不一定能满足质量、时延或合规要求。
把“过度使用”变成可计算的信号
团队可以先定义一组简单、可解释的内部规则。例如：
- 某个任务中，高成本模型的请求占比超过 70%。
- 该任务至少有一定调用量，避免被小样本误导。
- 这个任务已经存在可接受的低成本候选模型。
- 高级模型没有在成功率、质量评分或平均轮次上体现明显优势。
其中前两项可以直接从使用数据计算，后两项则需要结合评测结果。不要只根据调用占比自动切换生产模型。
下面是一个可复制运行的 Python 示例。它使用模拟数据演示如何按任务统计模型使用比例，并标记可能需要审查的组合。实际使用时，可将 rows 替换为从内部分析流程导出的数据；这里不假设 User Insights 提供特定导出 API。
from collections import defaultdict
# 示例数据。生产环境中可以改为读取 CSV、数据仓库或日志管道。
rows = [
{"task": "classification", "model": "premium", "user": "u-101", "turns": 1},
{"task": "classification", "model": "premium", "user": "u-102", "turns": 1},
{"task": "classification", "model": "premium", "user": "u-103", "turns": 2},
{"task": "classification", "model": "small", "user": "u-104", "turns": 1},
{"task": "code_generation", "model": "premium", "user": "u-101", "turns": 4},
{"task": "code_generation", "model": "premium", "user": "u-102", "turns": 3},
{"task": "code_generation", "model": "small", "user": "u-103", "turns": 7},
]
PREMIUM_MODELS = {"premium"}
MIN_REQUESTS = 3
OVERUSE_THRESHOLD = 0.70
stats = defaultdict(lambda: {"total": 0, "premium": 0, "turns": 0, "users": set()})
for row in rows:
item = stats[row["task"]]
item["total"] += 1
item["turns"] += row["turns"]
item["users"].add(row["user"])
if row["model"] in PREMIUM_MODELS:
item["premium"] += 1
for task, item in sorted(stats.items()):
premium_ratio = item["premium"] / item["total"]
average_turns = item["turns"] / item["total"]
needs_review = (
item["total"] >= MIN_REQUESTS
and premium_ratio >= OVERUSE_THRESHOLD
)
print(
f"task={task:16} "
f"requests={item['total']:2} "
f"premium_ratio={premium_ratio:.0%} "
f"avg_turns={average_turns:.1f} "
f"users={len(item['users'])} "
f"review={'YES' if needs_review else 'NO'}"
)
运行后，classification 会因为高级模型占比达到 75% 而被标记为待审查。这个结果并不表示必须降级，而是提示团队发起一次针对性评测。
从洞察走向安全的模型路由
发现疑似过度使用后，比较稳妥的做法是先影子评测，再修改生产路由。可以这样实践：
# 假设性的内部路由配置，字段需按实际网关或应用框架调整。
routes:
- task: classification
primary_model: small-model
fallback_model: premium-model
fallback_when:
- confidence_below: 0.80
- output_invalid: true
- task: code_generation
primary_model: premium-model
experiments:
shadow_sample_rate: 0.10
compare:
- quality_score
- latency_ms
- estimated_cost
- average_turns
这段配置表达了两个重要原则：
- 对结构清晰、可验证的分类任务，先尝试小模型，在低置信度或输出不合法时回退。
- 对更复杂的代码生成任务，不因成本压力直接降级，而是保留高级模型，并持续收集质量与轮次数据。
“轮次”尤其值得纳入评测。一款单次调用价格较低的模型，如果经常需要额外三轮纠正，最终成本和用户体验都可能更差。
落地时别忽略用户数据边界
用户维度有助于定位高频调用者，但也带来隐私与组织治理问题。建议使用稳定的伪匿名标识，而不是把邮箱、姓名或客户资料直接写入分析标签。同时明确数据保留周期和访问权限，避免让成本分析系统变成不必要的行为监控工具。
可以按以下清单推进：
- 为主要请求补齐稳定的任务标签。
- 统一模型命名，避免同一模型因别名被拆成多组。
- 记录轮次时明确会话边界，排除无限重试和测试流量。
- 对用户标识做哈希或映射，并限制明细访问权限。
- 先观察一到两个发布周期，建立正常使用基线。
- 将高占比视为评测触发器，而不是自动降级条件。
- 比较质量、时延、总轮次和成本，而非只看单次请求价格。
- 为任何新路由保留回退模型和快速撤销机制。
User Insights 的价值，不在于简单指出“哪个模型用得最多”，而在于把任务、模型、轮次和用户放到同一个分析框架中。只要团队把这些洞察与离线评测、灰度路由和隐私控制结合起来，就能在不牺牲质量的前提下，逐步减少不必要的高级模型调用。