Both 指出,LangChain 最初在满足简单需求方面表现出色,但其高层抽象很快使得代码变得难以理解和维护。他以一个简单的翻译任务为例,展示了 LangChain 如何增加了代码的复杂性,却没有带来明显的好处。
以下是使用 OpenAI 包的 Python 代码示例:
from openai import OpenAI
client = OpenAI(api_key="<your_api_key>")
text = "hello!"
language = "Italian"
messages = [
{"role": "system", "content": "You are an expert translator"},
{"role": "user", "content": f"Translate the following from English into {language}"},
{"role": "user", "content": f"{text}"},
]
response = client.chat.completions.create(model="gpt-4o", messages=messages)
result = response.choices[0].message.content
以下是使用 LangChain 的 Python 代码示例:
from langchain_openai import ChatOpenAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
os.environ["OPENAI_API_KEY"] = "<your_api_key>"
text = "hello!"
language = "Italian"
prompt_template = ChatPromptTemplate.from_messages(
[("system", "You are an expert translator"),
("user", "Translate the following from English into {language}"),
("user", "{text}")]
)
parser = StrOutputParser()
chain = prompt_template | model | parser
result = chain.invoke({"language": language, "text": text})
Both 认为,LangChain 在这个例子中引入的“提示模板”、“输出解析器”和“链”等抽象概念,实际上增加了代码的复杂性,却没有带来任何实际价值。
抽象的代价:速度与灵活性
Both 进一步指出,LangChain 的高层抽象限制了团队的迭代速度和灵活性。当他们试图构建更复杂的 AI 代理时,LangChain 框架成为了绊脚石。
例如,当 Octomind 团队希望根据业务逻辑动态更改 AI 代理可以访问的工具时,他们发现 LangChain 无法满足这一需求。最终,他们不得不放弃 LangChain,转而采用更灵活的模块化构建块方法。
模块化构建块:大道至简
Both 认为,在大多数情况下,开发者并不需要像 LangChain 这样复杂的框架来构建 AI 应用。他建议采用模块化构建块的方法,只使用少量经过精心挑选的外部软件包,保持架构精简。
他列举了构建 AI 应用所需的核心组件:
用于 LLM 通信的客户端
用于函数调用的函数/工具
用于 RAG 的向量数据库
用于跟踪和评估的可观测性平台
通过将这些模块化的构建块组合在一起,开发者可以构建出灵活且易于维护的 AI 应用。
结论:拥抱简单,回归本质
Octomind 团队放弃 LangChain 的故事,为我们敲响了警钟:在 AI 领域,抽象并不总是有益的。过度的抽象可能会导致代码复杂、难以维护,并最终阻碍创新。
正如 Both 所说:“在大多数情况下,你对 LLM 的使用将是简单而直接的。你主要是在编写顺序代码,迭代提示,并提高输出的质量和可预测性。大多数任务都可以通过简单的代码和相对较少的外部软件包来完成。”
因此,在构建 AI 应用时,我们应该始终牢记“大道至简”的原则,避免过度依赖框架,而是专注于解决实际问题。
参考文献
Both, F. (2024). Why we no longer use LangChain for building our AI agents. Octomind Blog. Retrieved from https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents✅
作为一名资深科技专栏作家,我最近关注到人工智能领域的一个有趣现象:越来越多的开发者开始质疑框架的必要性。Octomind 公司的深度学习工程师 Fabian Both 近期发表了一篇博文,分享了他们团队在构建 AI 代理时放弃 LangChain 框架的心路历程,这篇文章引发了我的思考。
LangChain 的诱惑与困境
Octomind 团队最初选择 LangChain 的原因很简单:它提供了一系列令人印象深刻的组件和工具,并且在当时非常流行。正如 LangChain 的承诺那样,它似乎可以让开发者“在一个下午的时间里,从一个想法变成可运行的代码”。然而,随着 Octomind 团队需求的不断提高,LangChain 的弊端也逐渐显现。
Both 指出,LangChain 最初在满足简单需求方面表现出色,但其高层抽象很快使得代码变得难以理解和维护。他以一个简单的翻译任务为例,展示了 LangChain 如何增加了代码的复杂性,却没有带来明显的好处。
以下是使用 OpenAI 包的 Python 代码示例:
以下是使用 LangChain 的 Python 代码示例:
Both 认为,LangChain 在这个例子中引入的“提示模板”、“输出解析器”和“链”等抽象概念,实际上增加了代码的复杂性,却没有带来任何实际价值。
抽象的代价:速度与灵活性
Both 进一步指出,LangChain 的高层抽象限制了团队的迭代速度和灵活性。当他们试图构建更复杂的 AI 代理时,LangChain 框架成为了绊脚石。
例如,当 Octomind 团队希望根据业务逻辑动态更改 AI 代理可以访问的工具时,他们发现 LangChain 无法满足这一需求。最终,他们不得不放弃 LangChain,转而采用更灵活的模块化构建块方法。
模块化构建块:大道至简
Both 认为,在大多数情况下,开发者并不需要像 LangChain 这样复杂的框架来构建 AI 应用。他建议采用模块化构建块的方法,只使用少量经过精心挑选的外部软件包,保持架构精简。
他列举了构建 AI 应用所需的核心组件:
通过将这些模块化的构建块组合在一起,开发者可以构建出灵活且易于维护的 AI 应用。
结论:拥抱简单,回归本质
Octomind 团队放弃 LangChain 的故事,为我们敲响了警钟:在 AI 领域,抽象并不总是有益的。过度的抽象可能会导致代码复杂、难以维护,并最终阻碍创新。
正如 Both 所说:“在大多数情况下,你对 LLM 的使用将是简单而直接的。你主要是在编写顺序代码,迭代提示,并提高输出的质量和可预测性。大多数任务都可以通过简单的代码和相对较少的外部软件包来完成。”
因此,在构建 AI 应用时,我们应该始终牢记“大道至简”的原则,避免过度依赖框架,而是专注于解决实际问题。
参考文献