原贴链接

厌倦了等待LlamaCPP服务器中的正确实现，我决定自己从头开始实现它。这使用了LlamaCPP Python绑定的generate()函数，利用原始令牌将模型的“动作”与“对话”分开。

这实际上对我来说有点混乱。当模型调用其内置工具时，例如“Wolfram Alpha”或“Brave Search”或“Python解释器”，它会在特殊令牌内封装函数调用，这很容易分离。然而，当定义自定义函数时，它正常调用，就像生成对话一样，这使得识别和分离变得复杂。Mistral模型有更好的模板。

像LLaMA 3.1 8B这样的小模型在决定何时使用工具时遇到了困难，如这个屏幕截图所示，需要特别指示才能使用它们。我注意到Hugging Face的实现每次用户消息都会发送函数/工具模式。

代码解释器在行动，LLaMA 3.1 8B最初没有使用它

此外，我不喜欢基于JSON的函数调用概念。原因最好在这张图片中描述：

image

老实说，我真的很想要一个能够流式传输原始令牌的LLM服务器。LlamaCPP服务器接受原始令牌，但将它们输出为字节字符串。我正在考虑要么从头开始编写自己的REST服务器，要么通过类似v1/generate端点请求流式传输原始令牌。

讨论总结

本次讨论主要围绕从零实现 Llama 3.1 8B 的功能调用，涵盖了从模型内置工具与自定义函数调用的区分困难，到小模型在使用工具时的决策问题。此外，讨论还涉及了对基于 JSON 的函数调用方式的不满，认为 YAML 格式更节省令牌，并提到了 Hugging Face 的实现方式。参与者还表达了对能够流式传输原始令牌的 LLM 服务器的需求，以及对生成前200个标记分布概率的期望。讨论中还涉及了 JSON 与 YAML 的可读性和成本比较，以及不同模型对特定功能调用的响应差异。

主要观点

  1. 👍 自定义函数调用复杂性
    • 支持理由：模型内置工具与自定义函数调用的区分困难。
    • 反对声音：小模型在使用工具时需要明确指示，决策能力有限。
  2. 🔥 JSON vs YAML
    • 正方观点：YAML 格式更节省令牌，更清晰易读。
    • 反方观点：JSON 可以通过去除空格来减少冗余。
  3. 💡 流式传输原始令牌的需求
    • 解释：希望有一个能够流式传输原始令牌的 LLM 服务器。
  4. 👀 生成前200个标记分布概率
    • 解释：现有的推理引擎难以获取这些信息。
  5. 🤔 模型决策能力的微调
    • 解释：微调模型以提高其决定何时进行函数调用的能力。

金句与有趣评论

  1. “😂 Yaml > Json”
    • 亮点：强调 YAML 相对于 JSON 的优势。
  2. “🤔 +100 to an endpoint to generate raw tokens.”
    • 亮点：对生成原始令牌端点的强烈支持。
  3. “👀 Gotta fine tune it. Not necessarily on the function call schemas, rather fine tune it to be better at deciding when to function call.”
    • 亮点：强调微调模型决策能力的重要性。

情感分析

讨论的总体情感倾向较为积极，参与者对技术实现和优化表现出浓厚兴趣。主要分歧点在于 JSON 与 YAML 的选择，以及模型决策能力的微调。这些分歧可能源于不同用户对可读性、成本和效率的不同偏好。

趋势与预测

  • 新兴话题：流式传输原始令牌的实现和模型决策能力的微调。
  • 潜在影响：这些技术改进可能显著提升模型在实际应用中的性能和效率。