我为什么放弃了 LangChain？( 五 ) _人工智能

坏消息是，它坏了，但又是为什么呢？我这一次没有做任何奇怪的事情。
有趣的事实：这些大量的提示也会成比例地增加 API 成本。
这样做的后果是，正常输出结构中的任何重大变化，例如由自定义系统提示引起的变化，都有可能破坏 Agent 。这些错误经常发生，以至于有一个文档页面专门用于处理 Agent 输出解析错误。
我们暂时把与聊天机器人对话看作是一个边缘案例。重要的是，机器人能够返回菜谱，因为如果连这一点都做不到，那么使用就没有意义了。
在不使用系统提示的情况下创建一个新的 Agent，然后问它什么是简单有趣的晚餐？
> Entering newchain...{"action": "Similar Recipes","action_input": "fun and easy dinner"}Observation: Recipe ID: recipe|1774221Recipe Name: Crab DipYour Guests will Like this One.---Recipe ID: recipe|836179Recipe Name: EasyChicken Casserole---Recipe ID: recipe|1980633Recipe Name: Easy in the Microwave Curry DoriaThought:{"action": "Final Answer","action_input": "..."}> Finished chain.Here are some fun and easy dinner recipes you can try:1. Crab Dip2. Easy Chicken Casserole3. Easy in the Microwave Curry DoriaEnjoy your meal!
至少它成功了：能够从上下文中提取出菜谱，并对其进行适当的格式化（甚至能够修正名称中的错别字），并且能够在适当的时候进行判断。
这里真正的问题是，输出的声音很无聊，这也是基础版的共同特点和诟病。即使通过系统提示工程解决了 ID 缺失的问题，这般听上去的效果也不值得将其发布。就算真的在语音质量和输出质量之间取得了平衡，Agent 计数仍然会随机失败，而这并不是我的过错。
实际上，Agent 工作流是一个非常脆弱的纸牌搭成的房子，凭良心说，生产应用中估计无法使用。
确实有Agent 和Chain 的功能，所以你可以在堆栈的某些部分重写逻辑（也许文档很少），这可以解决我遇到的一些问题，但在这一点上，你会感觉到更加复杂，还不如创建你自己的库。
工作要讲究方法
大量随机集成带来的问题比解决方案更多。
当然，确实也有很多实用功能，比如文本分割器和集成向量存储，这两种功能都是「用 PDF / 代码聊天」演示不可或缺的（在我看来这只是一个噱头）。
所有这些集成的真正问题在于，只使用基于的代码会造成固有的锁定，而且如果你查看集成的代码，它们并不十分稳健。
正在建立一条护城河，这对的投资者来说是好事，因为他们想从 3000 万美元中获得回报，但对使用它的开发者来说却非常不利。总而言之，体现了「它很复杂，所以它一定更好」这一经常困扰后期代码库的哲学，可是甚至还不到一年。
要想让做我想让它做的事，就必须花大力气破解它，这将造成大量的技术负担。与现在的人工智能初创公司不同，我自己的项目的技术债务无法用风险投资来偿还。在使用复杂的生态系统时，应用程序接口封装器至少应该降低代码的复杂性和认知负荷，因为使用人工智能本身就需要花费足够的脑力。是为数不多的在大多数常用情况下都会增加开销的软件之一。
我得出的结论是，制作自己的软件包要比让来满足自己的需求容易得多。因此，我开发并开源了：一个用于轻松连接聊天应用程序的程序包，它强调代码的最小复杂度，并将向量存储等高级功能与对话逻辑解耦。