AIP Logic 常见问题

本页详细介绍了关于 AIP Logic 应用的一些常见问题。

• How can I use AIP Logic with the rest of the platform?
• How do I reduce my token count?
• When should I keep my Logic function in one block versus splitting into multiple blocks?
• How do I improve the performance of an AIP Logic block?
• Is there a way to modify the temperature of the LLM or other model parameters?
• Is it possible to support semantic search workflows using Logic?
• How can an LLM “learn” from feedback?
• How can I ensure the output of my Logic is correct?
• How can you create test cases from previous executions?

请查阅关于如何使用 Logic 函数的文档。

AIP Logic 中的所有活动都会计入 token 限额，包括工具响应。Token 限额按 block 重置。你可以在 Debugger 中每条消息的末尾看到所使用的 token 数量。如果进度条显示为红色，请考虑减少你的 token 数量以确保性能可靠。

我们建议采取以下步骤来减少 token 数量：

• 从输入对象中选择所需的特定属性，或指定你想查询哪些对象属性，以缩减 LLM 发送和接收的字符串大小（OBJECT_NAME property1 property2 等）；你可以在 Debugger 中选择 Show raw 来查看它。
• 使用 Query objects 工具时，选择要发送给 LLM 的属性子集。
• 考虑将单个 block 拆分为多个 Use LLM block；每个 block 都有 token 限额，因此你可以尝试将一个 block 拆分为多个中间步骤。
• 将你的 LLM 模型改为 32k。
• 尽可能使用确定性 block，例如 transform block、execute block 和 apply action block。这些 block 有助于产生更可预测的结果，并且不消耗任何 token，从而使你的 logic 更高效、更易管理。

单个大 block 让你可以在试验 LLM 能力时快速迭代并轻松做出较大改动，但在以下情况下，你可能希望将你的 Logic 拆分为多个 block：

• 你希望 LLM 执行多个步骤，但得到的结果不一致。
• 该 block 正接近其上下文限制。
• 每次运行执行耗时过长。

由于每个 block 都有自己的上下文窗口，拆分为多个 block 可以带来以下优势：

• LLM 只能访问你传入的内容；单个大 block 中的中间结果可能是不相关的。
• 你不太可能耗尽 token。
• 若干较小的任务可能比一个长任务执行得更快。

要改进 AIP Logic block 的性能，请尝试以下建议：

• 选择 5-10 个输入/输出对示例，并在每次修改 prompt 时运行它们。将它们保存为 AIP Logic 中的单元测试。
• 向 LLM 提供 few-shot 示例；通过让模型更容易理解任务，这可以显著提升 LLM 性能。你可以输入一个供 LLM 参考的 system prompt。
• 如果你看到意外的失败，请通过让 LLM 解释其计划和对问题的理解，来验证模型对你的数据有正确的「理解」——这可以让你了解缺失了哪些上下文。
• 考虑构建一个带有动态 few-shot 示例的反馈闭环。
• 使用确定性 transform board，例如 transform block、execute block 和 apply action block。
• 使用 AIP Evals 来运行评估。Results 视图中的结果分析器会将失败案例聚类为根因类别，并在你迭代 prompt 时提出有针对性的 prompt 修改建议。

你可以通过编辑 Use LLM block 的 Configuration 文本字段中的 temperature，来修改 LLM 的 temperature，该参数表示 LLM 响应的随机性。默认 temperature 为 0。较低的 temperature 会返回更具确定性的输出。

示例代码：

{
    "temperature": 0.9
}

可以，你目前可以添加一个工具，让 Logic 能够对 Ontology 执行语义搜索，这可以通过一个 action 或编写一个对象函数（function-on-object），然后再从 AIP Logic 调用它来实现。请查阅语义搜索工作流教程以了解更多。

如果它适合你的工作流，你可以用这种设计模式帮助 LLM 从反馈中「学习」：

1. 每当 LLM 给出建议时，捕获 (1) 该建议以及 (2) 其推理。然后，在将该 Logic 函数连接到 Workshop 并构建人工审核流程时，写回 (3) 人工反馈以及 (4) 经人工验证的正确决策。为了方便举例，我们假设将这个写回对象称为「Suggestion」对象。
2. 在你的 Logic 函数中，让 LLM 能够对「Suggestion」对象使用 Query objects 工具，搜索 LLM 曾给出相同建议的其他实例。让 LLM 处理人工反馈，然后就 LLM 的建议是否应当继续推进向 LLM 发起查询。

添加单元测试，以检查该函数在给定输入上是否能成功运行。你还可以使用 AIP Evals 为你的 Logic 函数创建评估套件。要生成套件，请打开右侧边栏中的 Evals 标签页并选择 Generate evals。AIP Evals 会根据你的函数为套件引导生成测试用例、评估器和指标。在运行评估之前，请检查并完善所生成的测试用例和评估器。Results 视图包含一个内置的结果分析器，它会将失败案例聚类为根因类别、呈现具有代表性的示例，并提出有针对性的 prompt 修改建议以提高准确率。更多信息请参见 AIP Evals：快速入门。

在 Run history 中，使用 Add as test case 将历史执行结果转换为新评估套件或现有评估套件的测试用例。这有助于你从函数执行中构建全面的测试套件。

可以，你可以使用版本历史侧边栏查看并回滚到先前保存的版本。

从列表中选择一个较早的版本，即可与当前状态进行比较。

可以。通过使用「Struct」输出类型，你可以返回多个具名值。

可以，当你在 LLM block 中为 Function 工具添加 Object Query 工具时，你可以选择 Configure object return limits 来选择你希望从任何工具使用中返回的对象数量。

在 Debugger 中测试和开发你的 AIP Logic 函数时，该函数不受五分钟执行时间限制的约束。然而，当该函数从 Workshop 环境调用或通过函数执行 API 调用时，五分钟执行时间限制就会被强制执行。