内置工具调用的想法很棒。然而，文档很简略，假设你已经对自定义工具调用、Wolfram 和 Brave 有很多了解。我并不了解。要运行简单的示例真的很困难。
现在我已经让 Brave 和 Wolfram 完全运行起来了，我想创建这个简短的指南来帮助其他同样缺乏经验的工具调用者入门：
首先，llama 3.1 内置工具调用到底是什么意思？这意味着一个三部分的过程：
- 第一部分：使用 llama 3.1 模型将用户问题转换为适当的工具调用查询格式。
- 第二部分：使用这个查询调用 Wolfram（或 Brave）API（使用你自己编写的函数）来获取结果。
- 第三部分：使用 LLM 从第二部分的结果和之前的消息生成自然语言响应。
起初，我并不清楚我应该为第二部分自己编写函数，因为在这之前我唯一接触过的工具调用是 Cohere 的 Command R+ API，它基本上为我完成了工具调用。显然，那是一个例外。
要明白，llama 3.1 模型不会为你执行 Python API 调用。它可以在进一步准备后生成你可以用于自己函数调用的代码。但执行者，你编写的代码，必须完成这第二部分。
现在我将详细介绍每个部分和潜在的障碍。
第一部分：第一部分是简单的部分。你可以使用任何 llama 3.1 模型来完成它，尽管我发现 8b 可能会添加一两个额外的单词，或者有时是很多无意义的单词。我总是从 70b 得到一个干净且可预测的结果，看起来像这样：
<|python_tag|>wolfram_alpha.call(query="solve x^3 - 4x^2 + 6x - 24 = 0")
我的 16GB RAM 系统，一台 Mac Mini M2 Pro，没有足够的内存来运行 70b，所以我使用了 Groq。你用于第一部分和第三部分的模型可以不同也可以相同。在我的情况下，我使用了 Groq 70b 用于第一部分，而我本地的 llama 3.1 8b Q4_K_M 服务器用于第三部分。
第二部分。Meta 没有提供简单的 Brave 或 Wolfram 函数调用示例代码。（你可以在 llama 代理系统 中找到一些隐藏的提示。但这个 Wolfram 和 Brave 代码是更大、更复杂的代理系统的一部分，当你刚开始时可能不想花时间去弄清楚）。
这是我的 Wolfram Alpha 调用函数：
def get_wolfram_response(verbose_query, app_id):
# Wolfram API 在 verbose_query 下失败。使用正则表达式获取引号内的查询。
queries = re.findall(r'"([^"]*)"', verbose_query)
query = queries[0]
params = {
"input": query,
"appid": app_id,
"format": "plaintext",
"output": "json",
}
response = requests.get(
"https://api.wolframalpha.com/v2/query",
params=params)
full_response = response.json()
pods = full_response["queryresult"]["pods"][1]["subpods"]
return pods
我期望第一部分的结果：
<|python_tag|>wolfram_alpha.call(query=“solve x^3 - 4x^2 + 6x - 24 = 0”)
会是 Wolfram API 能理解的格式。不。
Wolfram 只想要引号内的部分：
solve x^3 - 4x^2 + 6x - 24 = 0
当然，你还需要在 Wolframalpha 上注册并获取 api_key，他们称之为 app_id。这个过程有点混乱。我无法让他们的任何 URL 示例代码工作。但是……
一旦我有了 app_id，并弄清楚了正确的传递格式，它返回了一个“200”响应。这一行：
full_response = response.json() line
获取你需要的 JSON 响应。
我从 JSON 响应中挑选出结果返回给函数，省略了不需要的元数据。我不确定这是否是最好的方法，因为元数据可能有一些用途，但这意味着如果我只保留相关部分，处理的令牌会更少，这在我的本地消费级硬件上意味着更快的响应。
第三部分：我也希望能使用 Groq 70b 来完成这一部分，但由于某种原因，Groq 不识别 ipython 角色：
messages += [
{
“role”: “assistant”,
“content”: assistant_response1
},
{
“role”: “ipython”,
“content”: str(wolframalpha_response) # 需要引号，否则内容会被忽略
}
]
由于 Groq 不识别 ipython 角色，我使用了我的本地 llama 3.1 8b。
起初，我所有的结果都是幻觉般的无意义内容，与传递给 ipython 角色的内容无关。然后我意识到服务器处理的令牌数量非常少——它忽略了内容。将 JSON 转换为字符串，然后它就工作了。
这对于 Wolfram 的简短答案来说很好，但 8B Q4_K_M 在将 Brave 的长搜索结果转换为好的结果方面能力有限。所以我希望能用 70b 进行实验，看看它与 Cohere 的 Command R+ 相比如何，后者处理基于搜索的事实查询非常出色。
注意：Groq 确实支持工具调用，有一个“工具”角色。我尝试使用他们的工具角色来构建一个定制的天气工具。但没有“ipython”角色，我不知道是否有可能使用 Groq 进行 llama3.1 内置工具调用。有人知道支持 ipython 角色的（有限使用）免费 llama3.1 API 吗？
希望这对你们中的几个人有帮助。如果有人问，我会整理我的代码并上传到 Github。
讨论总结
本次讨论主要围绕llama 3.1内置工具调用的实现细节和挑战展开。参与者分享了在使用Wolfram和Brave API时的经验，讨论了文档不足、模型选择、API调用格式、内存限制等问题，并提供了详细的代码示例和解决方案。此外，还有关于API成本和注册流程的讨论，以及对简化集成过程工具的询问。整体氛围积极，参与者互相帮助，共同探索和解决问题。
主要观点
- 👍 llama 3.1内置工具调用包含三个主要步骤
- 支持理由：详细描述了从用户问题转换到API调用再到生成自然语言响应的过程。
- 反对声音：文档不够详细，需要用户自行编写部分代码。
- 🔥 使用特定模型可以提高处理效率
- 正方观点：使用Groq 70b模型可以获得更清晰的结果。
- 反方观点：本地硬件限制了模型选择和处理能力。
- 💡 调用Wolfram API时需要正确处理查询格式和API密钥
- 解释：提供了详细的代码示例和处理方法。
- 👍 本地硬件限制了模型选择和处理能力
- 支持理由：作者分享了在16GB RAM系统上的实际经验。
- 反对声音：无
- 🔥 需要将JSON响应转换为字符串以避免内容被忽略
- 正方观点：这是解决内容被忽略问题的有效方法。
- 反方观点：无
金句与有趣评论
- “😂 fairydreaming：If anyone wants to experiment with Llama 3.1 tool calling using llama.cpp as a backend, I created a simple script that connects to the llama-server, allows to chat with the model, monitors the conversation and handles tool calls (only ipython at this moment).”
- 亮点：作者分享了一个实用的脚本，帮助其他用户实验工具调用功能。
- “🤔 zeaussiestew：Isn’t calling the Wolfram Alpha API extremely expensive?”
- 亮点：引发了关于API成本的讨论。
- “👀 choose_a_usur_name：Is anyone aware if tools like anythingllm that might help with this integration?”
- 亮点：询问是否有工具可以辅助集成过程，反映了用户对简化工具调用过程的需求。
情感分析
讨论的总体情感倾向积极，参与者互相帮助，共同探索和解决问题。主要分歧点在于文档的详细程度和API调用的复杂性。可能的原因是llama 3.1的内置工具调用功能相对较新，用户需要时间来适应和掌握。
趋势与预测
- 新兴话题：简化工具调用过程的工具和方法可能会成为后续讨论的热点。
- 潜在影响：随着更多用户掌握llama 3.1的工具调用功能，可能会推动相关领域的技术发展和应用扩展。
感谢您的耐心阅读！来选个表情，或者留个评论吧！