令人沮丧的AI开发工具

AI世界发展迅速——有时太快了。每个月，一个新的框架都承诺将彻底改变我们处理LLM的方式，但当开发者尝试实现它们时，却遇到了障碍。营销用语无处不在：“无缝的AI代理编排！”“轻松的LLM验证！”但当你打开文档时，你看到的是模糊的解释、缺失的参数和仅触及表面的例子。

许多这些工具都是在仓促中发布的，优先考虑功能公告而不是扎实的文档。我们得到的不是清晰、简洁且深入的解释，而是模棱两可的指南，这些指南只是浅尝辄止。

调试变成了一场痛苦的试错游戏，唯一可行的“文档”是GitHub问题和Discord或Slack频道中的零散讨论。

让我们来谈谈其中几个……

1、CrewAI：代理编排迷宫

CrewAI声称简化多代理协作。理论上，这很棒——只需定义代理，分配任务，然后让魔法发生。但在现实中，文档留下了许多空白。

举个例子：

from crewai import Agent, Task, Crew  
  
define_agent = Agent(role="Researcher", goal="Find recent AI papers")  
define_task = Task(description="Summarize key insights from 5 papers", agent=define_agent)  
  
crew = Crew(agents=[define_agent], tasks=[define_task])  
crew.kickoff()

这看起来很简单，对吧？直到你问：

• 如果代理卡住了怎么办？ 没有文档说明回退或重试。
• 代理如何通信？ API暗示“消息传递”，但实际使用情况不明确。
• 如果任务需要多个代理怎么办？ 没有充分的例子展示协作超过基本案例的情况。

2、Guardrails AI：验证黑盒

Guardrails AI旨在验证并强制结构化LLM输出。这个概念非常棒，但关键细节——如设置验证阈值或调试错误——被一带而过。

示例：

from guardrails import Guard  
from guardrails.hub import ProvenanceLLM  
  
guard = Guard().use(ProvenanceLLM(validation_method="sentence"))  
guard.validate("AI is the future")

现在，假设验证失败。错误信息可能会说：

Validation failed: None of the sentences match the provided context.

仅此而已。没有关于：

• 相似性是如何计算的（默认余弦相似度阈值是多少？）
• 如何调整严格性（能否降低以避免误报？）
• LLM如何检查给定段落或句子的逻辑正确性？
• 调试验证失败的情况（如何记录不匹配以进行分析？）

这些都是现实应用中的关键点，但Guardrails的文档几乎没有涉及它们。

3、LangChain：抽象怪兽

LangChain功能强大，但它是一个典型的抽象阻碍例子。该框架做了一切——内存、代理、检索、链——但祝你好运理解其背后的机制。

示例：

from langchain.chains import LLMChain  
from langchain.chat_models import ChatOpenAI  
from langchain.prompts import PromptTemplate  
  
llm = ChatOpenAI(model_name="gpt-3.5-turbo")  
prompt = PromptTemplate.from_template("What is {topic}?")  
chain = LLMChain(llm=llm, prompt=prompt)  
  
print(chain.run({"topic": "AI"}))

问题：

• 缓存是如何处理的？ （你会看到“缓存命中”的日志，但无法控制它。）
• 如果API调用失败会发生什么？ （有重试吗？退避策略？）
• LangChain如何处理令牌限制？ （它抽象了提示管理，但如果响应太长怎么办？）

LangChain有时不仅没有简化LLM的使用，反而使理解实际发生的事情变得更加困难。

4、现实检查

LLM工具仍在不断发展，成长的阵痛是可以预料的。但随着越来越多的开发者采用这些库，文档需要跟上现实应用的复杂性。我们需要：

• 清晰的API参考（不仅仅是“调用这个函数”，而是为什么和何时使用它。）
• 调试指南（真实的错误会发生。展示如何处理它们！）
• 更详细的例子（覆盖边缘情况，而不仅仅是理想场景。）

这些工具具有潜力，但现在使用它们感觉像是在调试一个黑盒。

5、开发者的困境：为什么会这样？

公平地说，构建这些工具的人并不是懒惰的，也不是故意让我们的生活更艰难。他们面临着自己的挑战：

• 仓促发布：AI行业发展极其迅速，迫使团队尽早发布并在以后迭代。
• 不断变化的LLM API：像OpenAI和Anthropic这样的LLM提供商经常更新他们的API，要求不断更新库。
• 多样化的用例：每个开发者想要的东西不同——平衡灵活性与简单性很难。
• 有限的资源：许多这些项目是开源的，团队很小，通常依赖社区贡献来改进。

6、结束语

LLM工具确实在进步。社区驱动的改进、更清晰的API设计和更好的开源贡献正在逐渐缩小承诺与现实之间的差距。在此期间，我们能做的最好的事情是：

• 阅读源代码——有时，这是理解发生了什么的唯一方法。
• 依靠社区讨论——GitHub问题、论坛和Discord通常比官方文档更有用。
• 推动更好的文档——开源项目依赖于反馈，所以让我们要求更好。

自2022年9月以来一直在使用LLM工具，但老实说，感觉我整个职业生涯都在使用它们——因为每个新工具都会让我重新学习基础知识，由于糟糕的文档。

尽管如此，我还是乐观的。AI领域发展迅速，随着生态系统的成熟，希望文档也会随之成熟。在此之前，我们将继续通过黑客方式解决问题。

原文链接：The Frustrating Reality of AI Tooling: A Developer’s Perspective

汇智网翻译整理，转载请标明出处