原贴链接

我不知道你们怎么想，但相比128k上下文，LLaMA支持工具调用对我来说更令人兴奋。

创建了一个Python笔记本，用于测试在我的本地自动化作业中可以使用工具调用的不同场景，包括：

  • 并行调用工具

  • 顺序调用工具

  • 调用带有复杂JSON结构的工具

你可以在https://github.com/AgiFlow/llama31找到这个笔记本。我不太确定我是否正确使用了来自https://huggingface.co/lmstudio-community/Meta-Llama-3.1-8B-Instruct-GGUF/tree/main的量化模型，使用的是llama.cpp。看起来需要更新分词器以包含<|python_tag|>。无论如何，对我来说看起来很有前景。

讨论总结

本次讨论主要围绕LLaMA 3.1的工具调用功能展开，用户们分享了他们的体验、测试结果以及在集成和使用过程中遇到的问题。讨论涵盖了工具调用的优势与局限、量化模型的使用、代码测试的必要性以及缺乏官方代码示例的问题。整体氛围较为积极，用户们互相帮助，共同探讨解决方案。

主要观点

  1. 👍 工具调用功能令人兴奋
    • 支持理由：用户认为工具调用功能为本地自动化任务带来了新的可能性。
    • 反对声音：部分用户担心多提示方法会增加输入令牌，减慢执行速度。
  2. 🔥 128k 上下文与工具调用的比较
    • 正方观点：128k 上下文在某些场景下比工具调用更有优势。
    • 反方观点：工具调用在本地自动化任务中更为实用。
  3. 💡 量化模型的使用问题
    • 解释：用户在测试量化模型时遇到了一些问题，不确定是否正确使用了这些模型。

金句与有趣评论

  1. “😂 segmond：128k context > tool calling, you can take a model that doesn’t have tool calling and use multi prompt to show it how to call tools.”
    • 亮点：强调了128k上下文的优势。
  2. “🤔 vuongagiflow：You are right, but not for local environment automation job with cpu. Multishot would work, it doesn’t guarantee the arguments passed to function calling are correct compared to model trained with it. More input token slowdown execution too, it’s not free estate.”
    • 亮点：指出了多提示方法在本地自动化任务中的局限性。
  3. “👀 sanobawitch：We don’t have any minimal, working code for devs, either from Meta or Huggingface, similar to what they did in the paper’s "4.3.5 Tool Use" section?”
    • 亮点：反映了用户对官方代码示例的需求。

情感分析

讨论的总体情感倾向较为积极，用户们对LLaMA 3.1的工具调用功能感到兴奋，并积极分享自己的体验和遇到的问题。主要分歧点在于128k上下文与工具调用的比较，以及量化模型的使用问题。这些分歧可能源于用户对新功能的期待与实际应用中的挑战。

趋势与预测

  • 新兴话题：量化模型的进一步优化和官方代码示例的提供可能会成为后续讨论的热点。
  • 潜在影响：LLaMA 3.1的工具调用功能有望推动本地自动化任务的发展，但也需要更多的技术支持和优化。