BTW: 这是使用 Haye AI 的翻译功能翻译的.

背景

在过去的几周里，我和 Caicai 一起致力于开发产品 Haye AI，这是一个上下文感知的人工智能助手。

我们抽出业余时间来开发这个产品，并且我们一直追随着时髦的想法和最先进的技术，以使其变得更好。

几天前，Meta 发布了 llama 3，这真的改变了一些东西。

新的开源模型：LLaMA 3

LLaMA 3在各个方面都非常令人印象深刻：

  • 它支持多种语言的回复，比如中文。（但有时它会用拼音回复，而且有些单词仍然是英文。）
  • 总体表现比 LLaMA 2 要好得多，接近GPT 4
  • 一些在线 API 提供商以极低的成本和快速的响应速度提供 llama 3，使其成为目前最具性价比的 AI 模型。

我们过去通常使用 gpt-3.5-turbo 作为大多数任务的主要模型，配合一些预定义的预设。我花了很多时间修改 playground 中的提示，但结果并不总是好的。一旦我将模型改为 gpt-4，结果就好得多，但我们不能这样做，因为成本太高（大约是 gpt-3.5-turbo 的 10 倍 - 15 倍）。

因此，我们非常高兴看到 llama 3，并且正在尝试将其集成到我们的产品中。

遇到的问题

我们面临着几个问题：

  • llama 3不支持原生的函数调用，这是一些任务中的关键功能
  • 仍然没有可靠的 LLM 提供商提供 llama 3 的API
  • 即使不同的 LLM 提供商都宣称与 “Open AI” 兼容，但它们兼容 Open AI API 的方式也不尽相同
    • groq 不支持使用 Streaming API 进行 tool call，这意味着我必须根据是否需要 tool call 手动拆分任务。
    • deepinfra、fireworks 和 together 直接忽略请求中的 tool call。
    • openrouter 可以支持使用 stream 进行 tool call，但它直接在content中回应了工具调用，而不是预期的tool_call字段，这不符合 Open AI API 的标准。

我们仍在等待 Azure 或其他大型云服务提供商提供可靠的资源，以便我能够信任其可靠性。同时，我也希望能够开发函数调用功能，可能会基于 “Reason - Act” 提示构建一个简单的层作为 LLM 不可知的"函数调用"适配器。