关于 LangChain 的思考

我会第一个赞扬 LangChain。有了新想法，它很容易上手。我用它来编写了一个小型学习指南工具，用于从技术阅读中提出问题。它提供了足够的文本数据，可以轻松连接到 LLM。

然而，在我现在的职位上，我用得越多，我编写的自定义组件就越多地支持它，而且我感觉准确的答案变得越来越难以获得。

这是我最大的抱怨。

当我开始使用 LangChain 时，创建概念证明很简单：哦，切换向量存储，就完成了。对于这种情况，这是一个非常即插即用的框架。令人沮丧的是，你最终会编写用于解析、分块和存储数据的类，因为接口不适合所需的用例。这是主要提供标准接口的开放式框架的预期问题。例如，我编写了一个自定义文档加载器，因为编写它时唯一的选择是制作一个复杂的 JQ（用于 JSON 解析的 CLI 工具）命令。

也许您想通过在源的开头添加标头但保持块分离来以不同的方式对数据进行分块。要执行此操作，您需要一个自定义类。

将数据加载到向量存储中需要一些额外的编码。这不是你花钱买的吗？让人工智能更快。

抛开笑话不谈，这个问题的另一面是使用接口。例如，我想使用 Wea​​viate 中的租户来隔离客户数据集。此功能在文档中说明得很清楚。那么我的抱怨是什么呢？

我想使用检索器来调用单个客户数据集。这没有记录，除非您了解 LangChain 代码的工作原理，否则很难弄清楚。

这是通过提供文档来使用租户的代码片段。

db_with_mt = WeaviateVectorStore.from_documents（
    文档，嵌入，客户端=weaviate_client，租户= “Foo”
）

如果您已存储所有文档并需要使用检索器，该怎么办？您可以大胆假设这样做。

WeaviateVectorStore（
  客户端，
  “MyIndex”，
  “文本”，
  嵌入=嵌入，
  属性= [ “源” ] 
）.as_retriever（search_type = “mmr”，租户= “Foo”）

有趣的事实：这有两个问题。首先，必须启用多租户，并且必须在搜索参数中传递租户。

WeaviateVectorStore （
  客户端，
  “MyIndex”，
  “text”，
  嵌入=嵌入，
  属性= [ “source” ]，
  use_multi_tenancy = True，
 ）。as_retriever （
      search_type = “similarity”，
     search_kwargs = { 
       “tenant” ： “Foo”，
     } 
 ）

这需要大量挖掘才能找到答案。Weaviate 存储库包含许多 Protobuf 文件，标记了映射回此的参数。

这是我的第二个抱怨：你使用 LangChain 越多，你就越需要了解 LangChain 代码。我对我经常使用的其他库（如 Boto3 或 Flask）一无所知。

这是快速推进 AI 未来的普遍问题。这些问题都无法解决，但需要投入数百万美元。

我们知道抽象很有挑战性，有时会让生活变得更加复杂。妈的，我部署了多个负载均衡器，但对 BGP 一无所知。有时抽象是件好事，因为网络很复杂。

我感觉到了。

LangChain 链非常棒。我可以流媒体，我可以不流媒体，我可以用我的数据得到那些对我的问题来说非常非常有价值的答案。

直到我想弄清楚我的链代码中的瓶颈是什么，是我的矢量数据库还是对 OpenAI 的 API 调用？谁知道呢？因为我不知道。现在，我已将日志记录设置为调试模式，并编写代码来查看是什么占用了我所有的时间，以确保 AI 运行缓慢。

这让我想起一个常见的话题：多少抽象才算太多？我觉得这是 LangChain 面临的一个问题。如果不存在，我必须编写代码（我不是 10x 开发人员；因此，这需要一点时间）。我必须深入挖掘才能了解什么是可能的。我必须施展一些魔法来深入挖掘并了解正在发生的事情，才能知道我正在构建什么。

我认为 LangChain 是快速启动小型项目的绝佳方式。我喜欢它展示快速演示的简单性。但是，一旦你处理软件开发世界中可怕的细微差别，它的功能就相当有限了。

不要迷失在抽象概念中，因为我的观点是 LLM/AI 的缩写。这是我一年前才拒绝遵循的一般规则。

总体而言，Langchain 是完美的 5/7。