使用 User Insights 识别 AI 模型过度使用

当我们在上个月 推出 User Insights 时，我们想帮助团队回答一个基本问题：人们实际上在用 AI 做什么？User Insights 为团队提供了更清晰的 AI 使用视图，显示哪些用户、应用、任务和模型在驱动流量。它还突出显示用户和代理异常，帮助团队在支出和使用失控之前识别意外或失控的情况。

我们的最新更新添加了用户一直在要求的功能：上下文。 

自推出以来，我们听到用户说模型名称和请求计数只能说明一部分情况。它们显示流量去向，但几乎不透露背后的工作：那次请求是代码审查、研究任务，还是代理为完成工作而进行多次调用？相同的 token 计数可能代表非常不同的工作类型，若不了解任务，就无法通过模型选择来评估。

User Insights 现在显示何时模型可能比任务所需更强大，哪些用户和代理在推动该使用，以及任务、模型、成本和对话模式之间的关系。团队可以利用这些洞察来调查并在组织内做出有针对性的更改。这些功能对 AI Gateway 用户免费开放。

为什么 AI 使用难以理解

考虑一个将内部 AI 流量通过 AI Gateway 路由的团队。几周后，支出增加，一些请求的响应速度比预期慢，这是组织在大规模采用 AI 时常见的挑战。

可能有多种解释。开发者可能在使用 AI 进行日益复杂的编码工作。代理可能在完成任务时进行过多的后续调用。或者少数用户或代理可能占据组织使用量的不成比例份额。

仅凭 token 和请求计数无法显示哪种模式导致增长。团队需要先了解流量代表什么，然后再决定是否更改模型、工作流或路由规则。

帮助团队发现 AI 模型过度使用的情况 

模型过度使用视图帮助团队识别所选模型似乎比任务所需更强大的对话。例如，团队可能发现用户或代理将简单的格式化或摘要请求发送到高能力的推理模型。

这为组织提供了起点。他们可以查看与该模式相关的用户、代理或应用，然后调查背后的任务。团队可能会发现模型被使用是因为它是默认的，或者用户不确定选择哪个模型，或者代理已被配置为在每一步使用相同的模型。

过度使用视图不是排行榜，也不会自动推荐替代模型。它帮助团队提出更好的问题：

• 这个模型是否适合该任务？
• 额外的能力是否提升了结果？
• 更快或更便宜的模型是否能产生相同的结果？
• 问题是否仅限于一个工作流、用户或代理？

从那里，团队可以比较成本、延迟、token 使用量和对话轮数，然后决定要更改什么。

这些洞察支持新的 Potential Savings 视图和 Auto Router，后者将在本次发布时与公共测试版一起上线。Potential Savings 视图帮助团队识别可以由更快或更便宜的模型处理的请求，而不影响输出质量。Auto Router 自动应用这些任务和模型匹配信号，帮助降低成本，无需为每个工作负载设置单独的路由规则。

Overkill 视图是评估模型匹配度的起点。团队可以比较相同类型任务的延迟、输入输出 token、对话轮数和总成本。复杂的编码或研究任务可能需要强大的推理模型，而简短的摘要或简单分类任务则不需要。目标不是将每个请求都转到最便宜的模型，而是了解所选模型是否适合该工作。

了解人们使用 AI 的目的

任务分析按所代表的工作类型对对话进行分组。初始类别包括编码、研究、写作、摘要和数据分析。

这提供了模型名称列表无法提供的上下文。一个工程团队可能主要使用 AI 进行编码和调试，而另一个团队可能用于研究和摘要。团队还可能发现，尽管这些任务被发送到高能力模型，但来自简单任务的流量却出乎意料地多。

答案因团队而异。类别数据提供了一种利用已通过 AI Gateway 的流量来调查这些差异的方法。团队可以判断模型是否被用于其最适合处理的工作，或者默认模型是否被过度使用。

了解任务的全部成本

有些任务在一次交流中完成。其他任务则需要几轮提问、纠正和跟进。轮数分析显示不同任务所需的来回次数。长对话不一定是坏事，尤其是复杂工作。但如果一个简单任务仍需多轮，可能值得检查提示、模型或工作流程。

第一次请求只是成本的一部分。团队还应查看任务完成前所花费的时间、token 和金钱。比较这些数字可以显示工作流程在哪些地方耗时更长或成本更高。

将洞察转化为自动路由

一旦团队识别出过度使用模式并在任务、成本、延迟和轮数数据上得到确认，就可以将该洞察转化为自动路由决策。

例如，任务视图可能显示团队的大部分 AI 使用是摘要和格式化。模型视图可能显示这些请求被发送到大型推理模型，而轮数视图显示大多数对话在一次轮中完成。综合这些信号，团队可以获得一个具体的工作负载进行评估。

除了对 User Insights 的更新外，Auto Router 现已在封闭测试版中提供。Auto Router 使用对话轨迹、任务类别、任务复杂度和模型匹配信号，自动将请求路由到合适的模型，同时考虑成本。

与其为每个工作负载创建单独的路由规则，beta 版的客户可以让 Auto Router 在其应用可用的模型中进行选择。路由器并不会简单地把每个请求都发送到最便宜的模型，而是为当前任务选择合适的模型。复杂的编码或研究工作可能仍需更强大的模型，而更简单的任务则可由更快或更便宜的选项处理。

了解更多关于 Auto Router 并报名参加封闭 beta，在此阅读博客文章。

Auto Router 使用与 User Insights 相同的任务和对话信号。下面的章节解释了这些信号是如何生成的。

User Insights 如何分类流量

每个对话都会收到一个可在 User Insights 中分组的分析信号。该信号用于报告和路由分析，并不旨在替代或公开原始请求。

分类引擎是一个专用的 Cloudflare Worker，用于处理符合条件的 AI Gateway 日志。它检查对话轨迹，包括用户请求、助手回复、工具调用和工具结果，并识别正在执行的工作类型，例如编码、调试、研究或摘要。它还返回置信度得分，并评估任务复杂度、意图模糊度、风险和上下文依赖等维度。

Worker 返回一个类别，可与仪表盘使用的日志元数据关联。这些信号也可用于通过比较候选模型在任务适配度与成本之间的表现来评估模型匹配度。目前的实现聚焦于一小组易于理解的类别，而不是尝试推断用户工作中的每个细节。

该管道遵循现有的 AI Gateway 日志架构。元数据与日志主体分开存储，当前实现使用 Durable Objects 存储元数据，使用 R2 存储日志主体。User Insights 暴露派生类别和聚合视图。它不会将仪表盘变成原始提示浏览器。对底层日志主体的保留仍遵循配置的 AI Gateway 日志行为，因此团队在决定通过分类器发送哪些内容时应审查这些设置。

分类是异步的，这意味着它在 AI Gateway 处理完请求后才发生，而不是在用户等待响应时进行。AI Gateway 先将日志写入现有存储路径，然后分类 Worker 之后处理它。这将分类从请求路径中移除，并不会为用户响应增加延迟。

权衡是 User Insights 不是实时视图。新接收的对话可能不会立即出现在仪表盘上，分析可能会滞后约一天，因为日志需要处理和聚合。团队应使用 User Insights 来识别随时间变化的使用模式，而不是监控实时请求活动。

流程如下：

将使用情况与用户、团队和工具关联

当任务类别可以按用户、团队或应用查看时，它们会更有用。AI Gateway 具备身份感知功能，提供该上下文，而无需团队构建单独的报告管道。

这不仅适用于团队自行构建的应用程序，也适用于诸如 Claude Code、Codex 和 OpenCode 等开发者工具和代理工具包。通过将 AI Gateway 放置在 Cloudflare Access 后端，团队可以将已认证的用户和会话与其 AI 流量关联，使 User Insights 能够将活动与正确的人和对话关联起来。

对于自定义应用程序，请在请求中同时包含稳定的 user_id 和 session_id，以供 User Insights 分析。确切的身份配置和字段名称取决于应用程序或工具的设置。重要的是提供稳定、非敏感的用户和会话标识符，以便在不将身份数据放入提示本身的情况下对使用情况进行分组。

对于自定义应用程序，请求元数据可能如下所示：

请求体包含对话的模型和消息。

在 AI Gateway 前配置 Access 后，诸如 Claude Code、Codex 和 OpenCode 等工具可以自动继承此身份上下文。Cloudflare Access 对最多 50 名用户的团队免费提供，使其成为一个轻松入门的方式。

开始使用 AI Gateway User Insights

AI 使用正迅速变化。模型在变，团队在开发新工作流程，适合一个团队的最佳选择可能不适合另一个团队。

User Insights 让团队通过识别某些模型可能过度使用来开始做出更明智的选择。他们随后可以查看哪些用户和代理在驱动该使用，了解背后的任务，并比较完成工作的成本。

了解更多关于 AI Gateway User Insights 的信息，请查看 documentation。在 Cloudflare dashboard 中打开 AI Gateway，并利用所学做出更有针对性的模型和路由决策。