原贴链接

过去几年，我在读研期间花了大量时间使用大型语言模型（LLM）构建应用。在整个开发过程中，我发现当前人工智能应用开发生态系统存在一个常见问题。现有的框架（如LangChain）有太多的抽象内容。为什么这是个问题呢？有以下几个原因：1. 黑盒效应：它让后端变成黑盒，难以看清管道中正在发生的事情；2. 过于通用：当你想要构建特定功能时，它们的工具太通用了，不容易理解源代码并进行定制；3. 学习曲线：它们定义全新的语法，我们必须学习如何使用它们。框架应该是为了降低重复任务的难度而存在的，但当我们必须花大量时间学习如何使用框架来简化一些基本流程时，这就是浪费时间。这个问题的根源是什么？这个问题的根源很简单。它们的架构设计是以“框架为中心”的，并试图尽可能隐藏类似数据库的操作，这使得框架高度抽象化。建议的解决方案：解决这个问题的方法是创建一种新的以“数据库为中心”的抽象架构，这意味着你可以像使用数据库而不是框架那样使用它。我将这个数据库称为“CapybaraDB”，你可以在此查看文档（https://docs.capybaradb.co）。新架构（CapybaraDB）的示例：想象你有一个日记应用，想要保存用户数据以便之后用于检索式增强生成（RAG）管道。使用现有的框架，你需要精心设计模式和管道以使其符合框架语法。但在我的新数据库中，你可以像使用MongoDB一样保存数据。CapybaraDB和MongoDB之间唯一的区别是，你必须用“EmbText”类包裹你想要嵌入的文本。这就是你要做的全部！包括文本分块、嵌入和索引在内的一切都将由CapybaraDB服务器端处理。任何用“EmbText”包裹的文本数据都将自动、异步地进行分块、嵌入和索引。你也可以在嵌套字段中使用它。CapybaraDB服务器端的数据处理：检测保存文档中的所有EmbText数据，然后分块成更小的字符串，接着嵌入，保存文档和向量，随时可进行语义搜索。提供了最少但必要的抽象：如你所见，CapybaraDB没有提供太多抽象内容，它只提供最少且必要的抽象，这样你就可以根据喜好在其之上添加自定义管道。你可以像使用带有额外嵌入功能（原始MongoDB不提供的用于人工智能应用的功能）的MongoDB一样使用它。这个项目最初是一个内部工具，但我认为我可以帮助其他人，于是决定将其产品化。（整个文档可在此查看：https://docs.capybaraadb.co/document/query）。附言：为什么叫CapybaraDB？因为它很可爱。

讨论总结

原帖作者指出LangChain等框架存在抽象度过高的问题，如黑箱操作、过于通用、学习曲线高等，并提出以数据库为中心的CapybaraDB作为解决方案。评论者们从不同角度发表看法，包括分享自己使用LangChain的经历、提出其他替代方案、对CapybaraDB提出质疑等，整体讨论热度不高，但部分话题引发了较多讨论。

主要观点

  1. 👍 LangChain存在抽象度过高的问题，如黑箱操作、过于通用、学习曲线高等
    • 支持理由：原帖作者详细阐述了这些问题的表现和影响。
    • 反对声音：部分评论者认为LangChain学习曲线不陡峭，或者其功能有优势。
  2. 🔥 不需要LangChain或类似框架，纯Python方式更好
    • 正方观点：纯Python更直接，可根据需求定制，避免框架的抽象问题。
    • 反方观点：框架可利用现有工具，即插即用更方便开发。
  3. 💡 Haystack或者LlamaIndex比LangChain更好，更稳定
    • 解释：Haystack用于生产应用，每次发布变动小，不像LangChain那样不断变动。
  4. 👍 认为有比LangChain更好的存在，这个更好的存在是Python
    • 支持理由：未详细阐述，直接表明观点。
    • 反对声音：无（评论未涉及反对观点）
  5. 🔥 原帖应直接宣传CapybaraDB，对LangChain的抱怨可能是多余的
    • 正方观点：原帖为推崇CapybaraDB而抨击LangChain的铺垫可能不必要。
    • 反方观点：无（评论未涉及反对观点）

金句与有趣评论

  1. “Langchains code under the covers is ugly, but it was first and you should expect it to be ugly.”
    • 亮点：直接指出LangChain代码底层的丑陋问题。
  2. “mwmercury：Wrong. It’s not "we need something better than LangChain", it should be "we don’t need LangChain or anything similar".”
    • 亮点：鲜明地提出不需要LangChain或类似框架的观点。
  3. “I don’t think LangChain/LangGraph’s learning curve is that steep.”
    • 亮点：与多数人认为LangChain学习曲线高的观点相反。
  4. “You could have just made a fan post about capybaraDB instead of ranting about LC 🤣”
    • 亮点：以诙谐的方式表达原帖不必抨击LangChain来宣传CapybaraDB。
  5. “I even attended courses on langchain last year and found it entirely underwhelming and broken.”
    • 亮点：通过自身经历表达对LangChain的不满。

情感分析

总体情感倾向较为复杂。原帖作者对LangChain持负面态度，部分评论者也表达了对LangChain的不满，如认为其代码底层丑陋、抽象晦涩等；但也有评论者对LangChain表示支持，认为其有不错的功能，如pydantic输出解析器，或者认为其学习曲线不陡峭、能解决一些问题等。主要分歧点在于LangChain是否真的存在严重问题以及是否有必要使用替代方案，这可能与评论者的个人使用体验、开发需求等因素有关。

趋势与预测

  • 新兴话题：可能会有更多关于CapybaraDB以及其他替代方案（如Haystack、LlamaIndex等）的深入讨论，包括它们的实际应用、性能比较等。
  • 潜在影响：如果越来越多的人认可某些替代方案，可能会影响相关AI应用开发框架的市场份额，促使开发者对框架进行改进或者重新评估自己的开发工具选择。

详细内容：

标题：对 LangChain 替代品的热烈讨论

在 Reddit 上，一篇题为“We deserve something better than LangChain”的帖子引发了广泛关注。该帖子获得了众多点赞和大量评论。帖子的作者在研究生期间花了大量时间使用大语言模型构建应用程序，认为现有的框架如 LangChain 存在过度抽象的问题，比如造成后端黑箱化、工具过于通用难以定制、学习曲线陡峭等。

作者提出了解决方案，即创建一个以“数据库为中心”的新抽象架构“CapybaraDB”，并提供了详细的示例和说明。还附上了相关文档的链接[https://docs.capybaradb.co] 。

讨论中的焦点观点众多。有人认为不需要 LangChain 或类似的框架，应全程使用纯 Python 。也有人认为框架的好处在于能通过即插即用利用现有工具，更便于开发。还有人指出 LangChain 存在代码不美观、抽象复杂等问题，同时提到了一些替代方案如 AG2、llama index workflows 等。

例如，有用户分享道：“我花了大约 7 - 8 天（每天 3 - 4 小时），就已经能够做几乎所有我计划做的事情了。”

对于新提出的“CapybaraDB”，有人质疑其是否也存在过度抽象的问题，作者回应称重点在于工具是否易于理解其运作。

讨论中存在的共识是大家都关注框架的易用性和可理解性。一些独特的观点，如关于“不可简化的复杂性”的讨论，丰富了整个话题。

总的来说，这场关于 LangChain 及其替代品的讨论，反映了开发者们对于人工智能应用开发框架的深入思考和多样需求。