AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


使用本地大模型调用代码,根本就是一场骗局!
发布日期:2024-06-08 10:20:08 浏览次数: 2027



通过大模型调用其他工具到底可不可行?ChatGPT 或许能轻松搞定一切,但同样的需求落在本地大模型上,恐怕就要打个问号了。
法国开发工程师 Emilien Lancelot 尝试了多款号称具备工具调用功能的 agent 框架,来看看本地大模型到底能不能完成任务,但结果就像他总结的“一无所获”。是什么让这位工程师失望了?
用 AutoGPT,得会点“糊弄学”

AutoGPT 是款貌似强大的框架,提供很酷的 CLI 外加 Flutter UI,能够通过浏览器创建 agent。其主要功能是处理用户的文档、音频、视频等本地内容。

但是……它主要依靠 ChatGPT 或其他专有大模型服务来完成繁重工作,至少给我们的感觉是如此。

我们必须“唬弄”AutoGPT 才能使用 Ollama 端点,让其误认为是 ChatGPT。

## OPENAI_API_KEY - OpenAI API Key (Example: sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx)OPENAI_API_KEY="helloworld"
...
## OPENAI_API_BASE_URL - OpenAI API 的自定义 URL,可用于接入自定义后端。如果 USE_AZURE 为 true 则无效,注意留空以保留默认 url。# 以下为示例内容:OPENAI_API_BASE_URL=http://localhost:11434/v1
...
## SMART_LLM - 智能语言模型 (Default: gpt-4-turbo)SMART_LLM=dolphin-mixtral:8x7b-v2.7-q4_K_M
## FAST_LLM - 快速语言模型 (Default: gpt-3.5-turbo)FAST_LLM=mistral:latest

这样应该可以解决问题:

./autogpt.sh run
value is not a valid enumeration member; permitted: 'text-embedding-ada-002', 'text-embedding-3-small', 'text-embedding-3-large', 'gpt-3.5-turbo-0301', 'gpt-3.5-turbo-0613', 'gpt-3.5-turbo-16k-0613', 'gpt-3.5-turbo-1106', 'gpt-3.5-turbo-0125', 'gpt-3.5-turbo', 'gpt-3.5-turbo-16k', 'gpt-4-0314', 'gpt-4-32k-0314', 'gpt-4-0613', 'gpt-4-32k-0613', 'gpt-4-1106-preview', 'gpt-4-1106-vision-preview', 'gpt-4-0125-preview', 'gpt-4-turbo-2024-04-09', 'gpt-4', 'gpt-4-32k', 'gpt-4-turbo', 'gpt-4-turbo-preview', 'gpt-4-vision-preview' (type=type_error.enum; enum_values=[<OpenAIModelName.EMBEDDING_v2: 'text-embedding-ada-002'>, <OpenAIModelName.EMBEDDING_v3_S: 'text-embedding-3-small'>, <OpenAIModelName.EMBEDDING_v3_L: 'text-embedding-3-large'>, <OpenAIModelName.GPT3_v1: 'gpt-3.5-turbo-0301'>, <OpenAIModelName.GPT3_v2: 'gpt-3.5-turbo-0613'>, <OpenAIModelName.GPT3_v2_16k: 'gpt-3.5-turbo-16k-0613'>, <OpenAIModelName.GPT3_v3: 'gpt-3.5-turbo-1106'>, <OpenAIModelName.GPT3_v4: 'gpt-3.5-turbo-0125'>, <OpenAIModelName.GPT3_ROLLING: 'gpt-3.5-turbo'>, <OpenAIModelName.GPT3_ROLLING_16k: 'gpt-3.5-turbo-16k'>, <OpenAIModelName.GPT4_v1: 'gpt-4-0314'>, <OpenAIModelName.GPT4_v1_32k: 'gpt-4-32k-0314'>, <OpenAIModelName.GPT4_v2: 'gpt-4-0613'>, <OpenAIModelName.GPT4_v2_32k: 'gpt-4-32k-0613'>, <OpenAIModelName.GPT4_v3: 'gpt-4-1106-preview'>, <OpenAIModelName.GPT4_v3_VISION: 'gpt-4-1106-vision-preview'>, <OpenAIModelName.GPT4_v4: 'gpt-4-0125-preview'>, <OpenAIModelName.GPT4_v5: 'gpt-4-turbo-2024-04-09'>, <OpenAIModelName.GPT4_ROLLING: 'gpt-4'>, <OpenAIModelName.GPT4_ROLLING_32k: 'gpt-4-32k'>, <OpenAIModelName.GPT4_TURBO: 'gpt-4-turbo'>, <OpenAIModelName.GPT4_TURBO_PREVIEW: 'gpt-4-turbo-preview'>, <OpenAIModelName.GPT4_VISION: 'gpt-4-vision-preview'>])

看来没那么好唬弄,模型名称要求必须为专有名称,例如“GPT4-turbo”或者以上列表中包含的其他名称。遗憾的是,我的模型命名不在其中。

现在看看能不能“伪造”一个合规模型名称,这里将名称设置为“GPT4-turbo”并再次运行。

./autogpt.sh run2024-05-19 16:03:01,937 ERRORInvalid OpenAI API key! Please set your OpenAI API key in .env or as an environment variable.2024-05-19 16:03:01,938 INFOYou can get your key from https://platform.openai.com/account/api-keys

这回我的 API key 没能过关。我尝试了多种不同 key,但仍然无法再进一步。

项目链接:https://github.com/Significant-Gravitas/AutoGPT

不过,奇怪的是,必要的配置文件设置现在显示“404”了。

实验小结

要想解决模型名称问题,我们可以在 Ollama 当中创建一个名为 GPT4-turbo 的自定义模型,但模型内容实际可以是任意本地模型。这单纯是在用重命名的方式唬弄 AutoGPT,但却无法解决 API key 错误。

另外需要强调的是,似乎可以在 AutoGPT 上照搬 OpenAI 模型提供的文件并删除所有不合规部分,但我不确定具体该怎么操作。

网上的相关文件https://github.com/Significant-Gravitas/AutoGPT/issues/6336#issuecomment-2119252849没有介绍使用本地模型的任何内容,也没有提到如何调用工具。

总之,我认为 AutoGPT 恐怕还没有准备好对接本地模型,只能等后续升级之后再做本地化应用尝试。

此外,网友 Wladastic 也在使用后评价道,“我没有任何本地模型可以完全与 Auto-GPT 配合使用,因为 GPT-4 可以保持上下文长度而不会过于关注它,但其他有效的模型确实过于关注给予 LLM 的提示。”

Wladastic 解释道,“我让它与 Mistral 7B AWQ、neural chat v3 AWQ 和其他模型一起运行。唯一的问题是,我必须从头开始编写自己的 Auto-GPT,因为 Auto-GPT 的提示对于本地 llms 来说太长且混乱。”

“它们有时会返回正确的提示,但有时会通过 Auto-GPT 专注于系统提示,因此它们会以“Hello,我正在使用命令 ask_user 与用户交谈,这是正确的吗?”,然后它会说“Hello,我能如何帮助你?”,大约 100 次,直到我取消它。”Wladastic 说道。

Wladastic 表示,“我目前使用 oobabooga text-generation-webui 的用例在添加 JSON 语法时效果最好。然后,它只能在非常基本的提示符和只有几个命令的情况下工作,否则它会不断生成新的命令,并开始产生幻觉、同时响应多个命令等等。”

太复杂的 LangChain

自从生成式 AI 浪潮爆发以来,Langchain 已经成为诸多项目的核心。而它之所以还没有成为客观标准,原因可能在于它的语法太过复杂,很多开发者没时间去学习和适应。

Langchain 提供的是一种相当晦涩的 Python 功能使用方式,很多经验丰富的开发者恐怕都弄不明白。举例来说:

chain = prompt | model | outputparserchain.invoke("Question.")

Python 的 LCEL 系统使用 pipes(「|」)将事物串连起来。具体在 Python 之内,就是通过覆盖 Python 的 or 方法来实现。换句话说,Langchain 会像在 C++ 那些覆盖掉运算符。

但我们真有必要这么折腾吗?这就留待各位自行判断了……

现在说说本地模型。

Langchain 提供 2 款插件:

  • Ollama chat: 允许用户与大模型对话。

  • Ollama-functions: 允许大模型通过特定输出格式回答问题。例如,假设我们希望自己的大模型以 JSON 或者 YAML 形式作答,则可定义自己期望的格式类型、键和值类型。

另外请注意“函数调用”功能!这纯纯就是 OpenAI 的恶搞,千万别被功能名称给蒙蔽了!它并不像大家想象中那样以“使用工具”的方式调用函数,而只是对大模型的输出做格式调整。

那么,工具调用(即在本地执行真实代码)到底可不可行?这个嘛……Ollama 插件不提供这项功能……

@tooldef multiply(first_number: int, second_number: int):"""Multiplies two numbers together."""return first_number * second_number
model = ChatOllama(model="mistral:latest")model_with_tools = model.bind_tools([multiply]) # <== Binding tool here

这项操作的运行输出为:

ChatOllama doesn't have a method bind_tools()

可以确定它办不到,咱们又被耍了……

实验小结

必须承认,我感觉有点失望。因为这套框架在为 CrewAI 等许多其他框架提供支持,所以我本以为它能跟本地工具良好集成。但事实证明,它做得并不好,这个复杂的烂摊子同样没办法帮我们解决核心需求。

缺少工具支持的 Rivet

靠谱的选手终于来了!虽然 Rivet 还很年轻,但前景光明、未来可期。

Rivet 用于创建复杂的 AI 代理和提示链,它是某种用于跟大模型交互的 IDE,使用画布创建执行图(DAG)。Rivet 能够在浏览器中运行,同时允许用户导出 DAG 并作为代码运行以增强软件功能。

Rivet 目前支持的大模型有:GPT-3.5、GPT-4、Claude 2、 Claude 3 系列、用于语音数据的 AssemblyAI LeMUR 框架等。

大伙看看,这界面太酷了,Rivet 还提供 Ollama 插件以支持本地使用。

请注意单击右上角的三个点并将执行器更改为“节点”,否则可能无法运行。

遗憾的是,我没有找到调用自定义工具的方法,而且 Rivet 的项目文档也不够完备。这个项目显然还需要进一步更新,但强烈建议大家关注。

实验总结

这软件很酷,免费而且开源。我喜欢它的画面系统设计,用起来感觉就像做对了的 LangGraph。

要让它真正发挥作用,还得配合工具调用。但如果各位已经拥有 ChatGPT 账户,那还犹豫什么,赶紧把 Rivet 用起来。

让人看不懂教程的 AutoGen

作为本份榜单中表现最好的方案之一,AutoGen 微软公司开源的多智能体(Mutiple Agents)应用开发框架,多智能体应用让不同的 Agent 之间相互交流沟通来解决问题。

我已经按说明走完了教程,必须承认……其中大部分步骤我都没搞明白!刚开始几页还可以,但情况很快陷入失控,我可能得借助 AI agent 框架才能理解这一切到底是怎么起效的。

但 Autogen 确实具备我们需要的一切,而且开箱即用支持 Ollama:

code_writer_agent = ConversableAgent("code_writer_agent",system_message=code_writer_system_message,llm_config={"config_list": [{"model": "dolphin-mixtral:8x7b-v2.7-q4_K_M","api_key": "hello world","base_url": "http://127.0.0.1:11434/v1"}]},code_execution_config=False,)

在我看来,Autogen 最棒的特性包括:

  • 动态生成代码并执行;

  • 调用工具(即调用我们的代码);

  • 支持人工输入。

但工具调用真能起效吗?

还是不行……必须调用大模型的 OpenAI 兼容工具才能实现这项功能,所以 Ollama + Mistral 的理想终究只是理想。但是,Autogen 的代码生成和执行功能都运行良好。另外需要注意,它不支持调用 LangChain 工具。

可供使用的聊天机制
  • 双模型聊天模式:允许两个大模型相互对话以完成任务
  • 按序对话:任务将按照您指定的顺序进行评估。

这就有点复杂了。涉及多轮对话中积累的上下文延续机制,的确是个难以理解的概念。为什么每项任务仍然表现成两个 agent 之间的对话?为什么是 A 对 B、A 对 C、A 对 D 和 A 对 E?为什么永远是从 A 开始?我实在是整不明白。

  • 群组对话:彻底无法理解了……

看这意思,好像是某个 agent 充当主脑,在其他各 agent 之间建立了某种层次结构。这个概念可能很有吸引力,但文档示例实在起不到帮助理解的作用。

它还支持最新的提示工程方式,例如:

  • ReAct:允许拆分操作并制定计划。之后它会尝试执行各个步骤,一旦出现问题,则会制定新的计划并重新开始。通过这样的方式,即可创建对于大模型具备语义含义的上下文,并帮助其专注于当前需要解决的任务。

  • Reflection:跟 ReAct 有点类似,但强调的是自己的输出。在“说话”之后,它会问自己“这个结果对吗?”而且自我迭代似乎确能提升答案质量。

与往常一样,所谓提升答案质量也就是减少幻觉,这正是当前困扰大语言模型的核心问题。

如果各位不想被代码吞没,也可以尝试下载 AutoGenStudio 软件,它能在不编写任何代码的前提下完成 agent 定义。这是一款有趣的软件,但并不能帮助我们真正掌握框架的核心功能。

实验小结

AutoGen 显然有着光明的未来。但因为是由微软开发而成,我们唯一担心的就是它可能会被最终抛弃、或者成为仅限跟 OpenAI 搭配使用的软件。

但哪怕是它,也仍然实现不了本地大模型的工具调用功能。:-(

要写大量提示词的 CrewAI

另一款出色的软件。CrewAI 是一款用于协调角色扮演、自主 AI 代理的框架。通过促进协作智能,CrewAI 使代理能够无缝协作,解决复杂的任务。

但除了文档不错、框架简单之外,CrewAI 也有自己的问题。

先来看优点:

  • 支持 Ollama;

  • 支持 LangChain 工具调用;

  • 支持自定义工具调用;

  • 支持人工输入。

坏的一面:

  • 工具调用仍然无法起效;

  • 人工输入有时无法触发;

  • 一致性差、无限循环;

  • Bug 频出;

  • 需要编写的提示词太多。

可供选择的聊天机制

这里提供“按序”和“分层”两种选项。按序允许大模型按照我们指定的顺序完成任务;而分层则是创建一个幽灵 agent,由该 agent 自动决定应该根据描述触发哪个 agent。

分层设计其实想法挺好,可问题是它在寻找协作 agent 的过程中老是出错,会让人快速失去耐心。

这套框架提供三种使用模式:

第一,你已经拥有 agent,则可使用以下提示词将其绑定:

  • 角色:该 agent 的职能定位

  • 目标:该 agent 在团队中需要做什么

  • 背景故事:该 agent 的来历……

writer = Agent(role='Writer',goal='Write a fake anecdote using a number.',backstory='An experienced writer with vivid imagination.',llm=ollama_mistral,verbose=True)

第二是在提示词中描述任务:

  • 描述:应该执行什么任务

  • 预期输出:该任务的预期输出

teacher_task = Task(description='Decompose the arithmetic operations.',expected_output='A consise list of operation to execute',agent=teacher)

最后是工具:可以将工具绑定至 agent 以实现功能。但出于某种考虑,此框架也支持将工具绑定至任务……但我觉得好像没什么意义。

@tool("sleep")def my_sleep(nb_seconds: int) -> str:"""Will sleep the amount of specified seconds provided as a number"""print(nb_seconds)return time.sleep(nb_seconds)

我喜欢使用 @tool 装饰符。这里只需传递一条工具描述字符串,大模型就能知道是否需要使用。

总而言之,这个过程需要编写大量提示词,很容易把人搞得晕头转向。

比如说这条提示词属于任务还是 agent?这个工具是属于 agent 甲还是 agent 乙?或者说要不要把工具绑定至任务本身?问题很多,答案却非常有限,因为 CrewAI 的说明文档很不完备!

实验小结

如果大家想要各 agent 之间能相互交流,那 CrewAI 确实是个简单的框架。它速度快、设计简洁,唯一的问题就是需要编写大量提示词。但它也没办法实现工具调用,所以我们的实验目标仍然没能解决。

另外,CrewAI 的一致性相当差,我们经常会看到 agent 陷入无限循环。

相信很多朋友都注意到,最近 YouTube 上出现了很多看似热门、但实际上没什么帮助的视频。不少 YouTube 用户都发布了关于 agent 框架的视频,浅浅讨论一下 AI 趋势和如何制作糟糕的 RAG 系统。之所以帮助不大,就是因为现在我们还无法调用本地工具,有限的选项全都集中在 ChatGPT、Grok 或者 Claude 身上。

总    结

一无所获!

老实说,现在我们真的需要一种更好的方法,来以较低的成本把大模型整合到自己的应用程序当中。调用工具在特定场景下可行,但仍需要更简单的架构,而且最好能脱离 OpenAI 的复杂格式。

毕竟对于 Phi 这样只能输出文本的小模型,如果无法与我们的应用程序相集成,那它跑在移动设备上还有什么意义呢?

附试验配置:
32 GB 显存的 RTX4090;
使用以下大模型进行测试:
  • llama3:8 B
  • dolphin-mixtral:8x7b-v2.7-q4_K_M
  • mistral:latest
由 Ollama 提供本地支持。
原文链接:

https://itnext.io/calling-code-with-local-llm-is-a-hoax-098abc6b85bf


53AI,企业落地应用大模型首选服务商

产品:大模型应用平台+智能体定制开发+落地咨询服务

承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

与创始人交个朋友

回到顶部

 
扫码咨询