LangChain太坑人


LangChain 由 Harrison Chase 开发，是一个 Python 和 JavaScript 库，用于与OpenAI的 GPT API（后来扩展到更多模型）接口以进行 AI 文本生成。

更具体地说，它是 2022 年 10 月发表的论文《ReAct：在语言模型中协同推理和行动》的实现，俗称 ReAct 论文，该论文演示了一种允许模型“推理”的提示技术（通过一系列思想） ）和“行动”（通过能够使用一组预定义工具中的工具，例如能够搜索互联网）。这种组合被证明可以极大地提高输出文本质量，并使大型语言模型能够正确解决问题。

LangChain 流行的 ReAct 工作流程在InstructGPT /text-davinci-003 上特别有效，尽管成本高昂且对于小型项目来说并不容易使用。

在BuzzFeed的工作中，我的任务是为Tasty品牌创建一个基于 ChatGPT 的聊天机器人（后来在 Tasty iOS 应用程序中以[url=https://www.buzzfeed.com/buzzfeedpress/buzzfeeds-tasty-introduces-botatouille-the-first-of-its]Botatouille 的[/url]形式发布），它可以与用户聊天并提供相关食谱。源食谱被转换为嵌入并保存在向量存储中：例如，如果用户询问“健康食品”，则查询将转换为嵌入，并执行近似最近邻搜索以查找与嵌入相似的食谱查询，然后将其作为添加的上下文提供给 ChatGPT，然后可以向用户显示。这种方法通常被称为检索增强生成。

LangChain 是迄今为止 RAG 首选的流行工具，所以我认为现在是学习它的最佳时机。我花了一些时间阅读 LangChain 相当全面的文档，以更好地了解如何最好地利用它：

  • 经过一周的研究，我一无所获。运行 LangChain 演示示例确实有效，但任何调整它们以适应菜谱聊天机器人约束的尝试都会破坏它们。
  • 解决bug后，聊天对话的整体质量很差而且无趣，经过紧张的调试也没有找到解决方案。
  • 最终，我遇到了一场生存危机：我是不是一个毫无价值的机器学习工程师，因为我无法弄清楚 LangChain，而其他许多机器学习工程师却可以？

总而言之，我浪费了一个月的时间来学习和测试 LangChain，最大的收获是流行的 AI 应用程序可能并不一定值得大肆宣传。在看到一个Hacker News 的帖子，说有人用 100 行代码重新实现了 LangChain，我的生存危机就解决了，大部分评论都发泄了对 LangChain 的不满

LangChain 的问题在于：
它让简单的事情变得相对复杂，而这种不必要的复杂性造成了部落主义，损害了整个新兴的人工智能生态系统。

如果你是一个只想学习如何与 ChatGPT 交互的新手，绝对不要从 LangChain 开始。

详细点击标题

其他网友观点：
1、对我来说，现在我主要是反框架的，我更喜欢可以从中挑选的积木式框架。以下是我想到的一些痛点：

  • 上下文管理：我创建了一个小型的 LLM 上下文管理工具来处理聊天记录、RAG 和其他数据。在我创建完整应用之前，它一直运行良好，而现在我却无法针对每个实例进行调整（影响分数容易、顺序等），也无法确定有限上下文中包含哪些内容，这让我感到很痛苦。
  • 链/循环：我建立了一个小型的链库，这样我就可以编写自定义提示并循环使用。这很有用，但我发现许多链 "条目 "需要自定义函数来控制流程。这对其他人来说几乎是不可能的
  • 文件导入：我使用 pymupdf，因为它似乎可以对 PDF 进行较低级别的访问，足以让我从文件中生成带标题的标记符。在线提取图片和表格似乎很困难，多栏页面更是灾难。我希望能有一个库，可以将任何文档转换为 markdown。
  • 分块：我自定义了一个 markdown 分块功能，这样我就可以按标题将文档分块，并在分块中包含标题/文档标题元数据。但它仍然很混乱，每次使用 RAG 时我都会感觉到它的局限性。

我还对一些更高层次的问题感兴趣：
  • 流畅地处理聊天/RAG/代理--这样 LLM 就能在必要时快速响应，必要时使用 RAG，否则就使用助手/代理循环。

了解多轮 RAG/代理：
例如，如何处理一个 RAG 问题，然后再处理一个上下文较少的通用后续问题？第一条信息会返回大量结果，而第二条信息则不会返回任何结果（"好吧，第二部分是什么意思？）您是否会在上下文中包含原始 RAG 数据，并随着聊天的继续不断填充更多数据？我的 RAG 和助手聊天感觉像是一次性的，而不是流畅的对话。

2、我非常喜欢 LangChain 的总体抽象水平，但我最大的问题是文档中的承诺太多，而实际能实现的却很少。

举个例子：
你会认为你可以在他们的 OpenAI LLM 类中使用与 OpenAI 兼容的 API，尤其是因为他们有很多合并的 PR 专门用来添加该功能。
只是有点。
他们不会对返回的字段进行任何数据验证，只会对返回的映射/字段进行原始索引，因此，如果后端 API 有不同的令牌概念，你很可能会因为 KeyErrors 而导致他们的实现崩溃，你必须重写类的内部实例变量才能让它正常工作。
是哪些？
请尽情阅读他们的代码以及他们使用的客户端代码。

同样，如果你的 LLM 对格式非常挑剔，你就会认为你可以像他们的文档声称的那样，在列表中生成一个系统、人工智能和用户提示的列表，然后将其输入 LCEL 模型链。但事实并非如此！ChatMessage 和 LCEL 模型链之间的兼容逻辑是在 ChatMessage 的特定子类中实现的，尽管文档声称所有 ChatMessage 都与 LCEL 模型链兼容。

如果 LangChain 能够变得更加注重测试，并对其承诺进行更全面的集成测试，我认为该框架将会非常出色。从最初的笨拙到现在的成熟，LangChain 已经走过了很长一段路，但还有很多事情要做。

在纯功能层面上，我目前最喜欢的是 https://lmql.ai/，但它没有那么流行，而且随着时间的推移，主要贡献者的提交频率也在下降，所以我对它不抱太大希望。