AIP Analyst 的计算用量

AIP Analyst 是一个智能体式应用：单个问题可能会引发大量模型调用和对 Foundry 的大量查询。理解这些用量来自哪里，有助于你预测成本、选择模型并设计高效的分析。

来自 AIP Analyst 的用量分为两类：

• LLM tokens： 每次模型调用都会消耗输入和输出 token，它们会按取决于模型的速率转换为 compute-seconds（计算秒）。请参阅 LLM token usage。
• Federated Foundry compute： 每次工具调用都会针对底层 Foundry 系统运行，例如 Ontology、数据集或 function，并消耗该系统的计算，此外还会消耗用于请求和读取结果所花费的 token。请参阅 Federated Foundry compute。

AIP Analyst 的工作方式是反复将对话发送给模型，并根据响应采取行动。每个请求都包含系统指令、你的消息、已启用工具的定义，以及仍在上下文中的先前工具调用结果。模型的回复（包括任何扩展思考）都计为输出 token。

这种设计带来三个后果：

• token 用量会随着对话的继续而增长， 因为先前的消息和工具结果会在每一新轮次中重新发送。一次很长的分析在末尾时每个问题的成本比开头更高。
• 庞大的工具结果是主要驱动因素。 加载数千个对象、返回很宽的 SQL 结果集，或读取很长的 PDF，都会把大量文本放入上下文，而它会在之后的每一轮次中重新发送，直到被移除。
• 已启用工具的集合本身也有成本， 因为工具定义会包含在每个请求中。在 Tools 菜单中禁用你不需要的类别，可以减小分析中每个请求的大小。

不同模型之间 token 到 compute-second 的速率差异很大。关于当前速率，请参阅 Usage-based pricing compute translation for AIP。关于 token 如何计数的一般背景，请参阅 Tokens in AIP。

一次分析所用的模型会与该分析一同记录，因此已保存的分析重新打开时会使用相同的模型。请参阅 Per-analysis settings。

大多数 AIP Analyst 工具本身不执行计算。相反，它们代表你调用现有的 Foundry 系统，并适用该系统通常的计算模型。下表将每个工具类别映射到执行该工作的系统。

Visualization 和 Planning 类别中的工具，例如 Create visualization 和 Context cleanup，不会查询单独的后端。它们的成本是用于生成和读取结果所花费的 token。Workshop lookup 和 Machinery lookup 工具的行为方式相同。它们各自读取某个资源的配置，而不是运行查询，因此其成本是用于读取所返回定义所花费的 token。之后对其呈现出的对象类型、functions 或 action types 进行的任何工作，都计入相应的类别。

AIP Analyst 创建的资源在分析结束后仍会继续消耗计算。一个已发布的 Quiver 仪表板或一个已保存的 Contour 分析，每次有人打开时都会消耗计算，并归因到该资源，而不是 AIP Analyst。

Foundry 中的 compute-seconds 通常归因到资源而不是用户。对于 AIP Analyst，token 用量按如下方式归因：

• Saved analyses： 用量归因到分析资源。
• Embedded analyses： 用量归因到所属资源，例如包含 AIP Analyst widget 的 Workshop 模块。
• Unsaved analyses： 默认情况下，用量归因到运行该分析的用户。如果配置了 Unsaved analysis cost attribution 设置，用量则改为归因到该设置中所选的项目。请参阅 General settings。

AIP Analyst 联合（federate）到其他应用的计算遵循这些应用自己的归因规则。特别是对于 Ontology 查询，计算会附加到查询发起所在的资源（如果存在），否则附加到被查询的对象类型。请参阅 Investigating Foundry compute usage from Ontology queries。

你可以在几个粒度级别上查看用量：

• During an analysis： 会话中的 token 估算器显示当前上下文大小。大纲会报告每次单个工具调用的 token 用量，这使得找出加载了过多数据的步骤变得很直接。
• Across your enrollment： 从 Control Panel 导出 AIP Token Usage 数据集，以获得按模型和资源细分的每日 token 消耗。请参阅 Exporting AIP token usage data。
• Alongside other usage： 在 Resource Management 中查看按项目和资源细分的 compute-seconds，并使用 AIP usage metrics 跟踪随时间变化的模型请求。

下面的手段可以减少用量，而不会改变你可以提出的问题。

Keep context small

• 移除你不再需要的数据。 使用上下文清理工具，或从大纲中隐藏单个工具结果，使庞大的结果不再在每一轮次中重新发送。
• 用分支代替继续。 当你转向一个不相关的问题时，创建一个新标签页，而不是延长一个很长的对话。请参阅 Tabs and branching。
• 用聚合代替加载。 优先使用 Ontology aggregation 或 Ontology SQL，而不是加载一个庞大的对象集并要求模型对其进行摘要。一行聚合输出的成本只是其背后对象的一小部分。

Narrow the search space

• 限制搜索范围。 限制 Ontology、对象类型组、项目、状态和可见性，既能减少智能体发起的搜索查询数量，也能减小其结果大小。请参阅 Limit search scope。
• 提前加载正确的上下文。 事先添加相关的对象类型或数据集可以完全省去探索性搜索。在 Workshop widget 中，预加载上下文并固定已启用的工具，会让引导式工作流的用量可预测得多。
• 禁用未使用的工具类别。 已启用工具越少，意味着请求越小，智能体走入无成效路径的机会也越少。

Choose an appropriate model

最大与最小模型之间的速率差异超过一个数量级。将能力最强的模型保留给真正困难的推理，而日常的查找和摘要则优先使用较小的模型。对于问题事先已知的嵌入式工作流，明确设定模型并隐藏模型选择器，使用量保持可预测。请参阅 View options 和 Chat controls。

当某个工作流已被充分理解时，你可以将工作从智能体的工具循环中移出，放入 AIP Analyst 所调用的资源，或放入完全独立运行的资源。这样做会同时改变成本结构和结果的可靠性。

使用以下指导在它们之间进行选择：

• 当问题仍在成型时，优先使用集成工具。 它们的优势在于不需要预先建模，且 graph 视图让每个步骤都可审计。它们的代价是中间数据会经过模型的上下文。
• 一旦逻辑稳定下来，就将其移入 function。 一个 function 会将原本需要多次工具调用的工作压缩为一次。它的中间数据永远不会进入分析上下文，其结果由确定性逻辑产生而非推理得出，其计算也归因到该 function。对于你预期会重复进行的计算，这通常是正确的选择，而且通常既比要求智能体每次都重新推导逻辑更便宜，也更可靠。
• 使用 skill 来记录方法，而不是记录计算。 一个 skill 记录如何应对某一类问题。由于智能体仍使用集成工具来执行它，skill 能提升一致性，但本身不会减少联合计算。
• 对于不应阻塞交互式会话的工作，使用 pro-code agent。 Pro-code agents 异步运行，且不受同步 function 执行限制的约束，这使它们适合长时间运行的任务。

一个实用的模式是结合使用这些方式。用集成工具进行探索，直到你理解该分析，然后将稳定、昂贵的部分移入 function，并将 AIP Analyst 保留用于围绕它的解释和呈现。

• Compute usage with AIP
• Compute usage with Ontology queries
• Usage types
• Supported LLMs