最近在思考一个问题, 在真正的产品应用中, 真的需要Langchain吗?

工业应用

请求量级

笔者之前在某家ChatBot工作, 可以提供的数据量级大概是这样的

QPS基本在5000左右, 目前看来这是业界中比较高的量级

如果考虑到需要额外的搭配的其他组件, 存储, MQ, Cache等等, 会有一些更大的扩散

请求特点

一个需要特别注意的事情是, 在业务比较稳定的情况下, 实际上Prompt是比较稳定的, 在实际应用中主要有以下:

1. RolePlay(单体角色扮演)
2. Group RolePlay(群聊)
3. Translate(翻译)
4. Summarize(记忆总结)

可以看到的是, 用到的Prompt的特点是比较少的, 而且通常来说格式是固定的, 而且改动频率较低

Prompt

以RolePlay作为例子, Prompt的结构类似于

{Role Play 角色扮演指令}

{Character Profile 角色信息}

{Context Messages 上下文消息}

{Jail Break 越狱指令}

{Language Instruction 语言指令}

其中只有角色信息以及, 上下文消息是需要动态拼接

而且由于请求量级非常大, 所以会单独的拆分一个包含存储/缓存的模块服务来提供Prompt的组织

Langchain

很好, 如果是想要构建一个Demo来进行测试或者是进行演示, 那么毫无疑问, Langchain是非常好用的.

搭配上非常丰富的生态, 构建的速度确实非常快速, 而且现在Langchain hub是有很丰富的Prompt资源.

大部分情况下, 可以在30行的量级上就构建出一个Demo

一切看起来都很美好, 但是有这么几个问题

1. LLM Client的负载能力没法拓展, 实际上在业务量级较大的情况下, 必须进行功能的拆分
2. 如果只把Langchain作为组装Prompt的组件, 似乎这个组件又太重了
3. 如果作为Prompt的来源, 一些业务又存在定制的问题

甚至我认为在必要的情况下, 如果你的业务不太复杂, 你完全不需要引入任何所谓的LLM框架

LLM 框架

现在的LLM框架想要做太多的事情, 想要做LLM API Client, 想要做Prompt, 想好做memory, 想做index, RAG ....

太贪心了, 真的太贪心了

在产品实践之后, 我认为最重要的事情从来都不是把所有的事情都结合到一起, 最重要的事情是知道自己需要什么东西

就现在看来, 我完全不觉得现在这些LLM 框架有真正的生产价值, 依然需要工程师进行大量的适配工作

而这些适配的工作量可能要比使用LLM框架的成本更高

反例

但是实际上还是有反例的, 如果我们还是以传统的轻客户端来看, 那么以上的批评是没有问题的, 如果是重客户端的话, 我认为是完全没有问题的

但是用python做客户端吗?NO,NO,NO

不过这倒是引入了另一个问题, 会有多少人原因用python来构建客户端呢?

总结

好好学习构建Prompt要比学习使用这些LLM框架更有用

抛开这些名不副实的LLM框架吧, 用他们来做原型而不是做产品应用