@whichxjy

@whichxjy

💭💭💭💭💭💭

聊聊 LangChain

最近调研了下 LangChain 以及 LLM 相关的一些技术，简单记录一些想法：

  1. 如果想让 LLM 返回更符合应用需求的结果，可以分为两个大方向：

    • LLM 输入优化：

      • Prompt 工程：比如 Few-Shot Prompting（在 Prompt 中提供例子作为上下文）和 RAG（提前将文本向量化，保存到向量数据库，并在提问时根据问题检索相关文本，作为 Prompt 上下文）。针对更为复杂的任务，又有了 ReAct 等更高阶的 Prompt 范式。

      • LLM 参数调整：比如 temperature 参数可以调整 LLM 回答的随机程度。

    • LLM 调优：用训练数据通过 Fine-tuning 微调基础 LLM，比如 OpenAI 就提供了这样的能力。这种方法的成本更高，且只能满足特定需求（与训练数据相关）。

  2. LangChain 中最让我兴奋的是 Agent 能力，可以让 LLM 作为应用的大脑（或引擎）。它最初提供了类似 ReAct 论文中基于纯粹的 prompt 驱动推理的实现；在 OpenAI 推出 Function Calling 能力后，LangChain 也支持了基于 Function Calling 的 Agent 实现，将 Tool 描述转换为 OpenAI API 中的 Function Calling 参数，是一种更标准化的实现。

  3. 我喜欢 LangChain 的另一个点是节点编排能力。由于各类组件都有一套基础的接口（包括 Prompt、ChatModel、Retriever，以及更底层的 Runnable），除了可以实现复杂的组件编排，还可以灵活地切换组件的底层实现（比如替换 LLM 或者替换向量数据库）。

  4. LangChain 初版的发布时间很早（在 ChatGPT 推出之前），且一直在跟随 LLM 的技术更迭做调整。如果整体看 LangChain 的具体代码实现以及对外提供的接口，其实算不上优雅和简洁，但是作为一个 LLM 框架而言，功能已经足够丰富了。加上社区开发者贡献的各种接口实现，目前再造一个类似 LangChain 的轮子（或者实现一个其它编程语言的版本）的工作量会比较大，比如社区实现的 langchaingo 和官方 Python 版本相比还是比较简略。

  5. 目前 LLM 应用中间件的两个方向：

    • Dify 等平台产品：更易用，对非技术人员更友好，通过 API 请求可以不受编程语言限制，但可能有定制化的需求不能满足的情况（依赖平台的开放性，可能需要二次开发）。

    • LangChain 等基础代码库：对开发者来说更灵活，但有一定的开发成本，并且有编程语言限制，适合需要自己搭建后端的场景。

  6. 参考 LangChain 最近推出 LangSmith 平台，LangChain 可能还是会走产品化的方向来盈利。个人感觉一种思路是在 LangChain 框架中嵌入产品化的功能，比如做 trace 和数据分析；另一种思路是基于 LangChain 搭建产品化的平台，未来 LangChain 自身推出一个 LLM 应用搭建平台也不是没有可能。

Updated: