为何大语言模型调用不算应用：LangChain在RAG流程中的定位
通过追踪一个从PDF上传到生成精准答案的文档问答应用，了解LangChain的实际功能，并判断在何种情况下其他框架更为适用。
调用大型语言模型很简单：发送提示语，就能得到文本回复。但要在该调用基础上构建出实用的功能却并非易事。一个真正的应用需要能够读取文档、找出关键段落、记录对话内容、组合提示语，并通过界面呈现所有信息，而模型仅仅是这些组成部分之一。本文将以文档阅读助手为例，详细讲解LangChain背后的相关机制，帮助你了解其运作方式。读完后，你应该能够描述检索流程的各个阶段，明白像LangChain这样的框架能为你分担哪些工作，进而判断它或其它类似工具是否适合你的项目。
用一段话概括LangChain是什么
LangChain是一个用于在大型语言模型之上构建应用程序的开源框架。它并不直接提供模型，而是为与模型相关的各个组件提供模块化的构建块以及端到端的工具：提示词模板、输出解析器、文档加载器、检索器、内存系统、各种工具，以及连接这些组件的机制。该框架可与主流模型提供商配合使用，还能与大量第三方工具集成，且完全免费，并处于持续开发中。团队通常利用它来构建聊天机器人、问答系统、检索增强生成（RAG）系统以及自主智能体。
关键的思想转变在于：LangChain 并非大型语言模型本身，而是让大型语言模型与你的数据、提示词以及用户协同工作的中间层。如果你只发送一个提示词并打印回复结果，那就无需使用它。一旦你的应用包含多个处理步骤，你就需要开始运用 LangChain 已经提供的相关功能。
整体架构概览
在深入研究之前，先了解整个框架结构会很有帮助。学习 LangChain 通常可分为三个部分，每一部分都建立在前一部分的基础之上。
基础知识
以下是每个 LangChain 应用都会用到的核心要素：
- 整体组件模型
- 模型，即用于封装聊天和补全 API 的层
- 提示词及提示词模板
- 输出解析，将自由文本转换为结构化数据
检索增强生成
RAG是一种让模型从用户自有文档中获取答案的技术。相关组件包括：
- 文档加载器
- 文本分割器
- 嵌入模型
- 向量存储库
- 检索工具
- 将上述组件整合为可用的RAG应用
智能体
智能体能让模型自行决定执行哪些操作。相关内容涵盖：
- 工具与工具包
- 工具调用功能
- 构建使用这些工具的智能体
本文其余部分将重点介绍前两个领域，因为它们解释了该框架存在的根本原因。
LangChain解决的问题
一个成熟的LLM系统很少只处理单个请求。看看即便是功能较为简单的助手也需要处理哪些任务：
- 读取文档
- 执行语义搜索
- 生成并存储嵌入向量
- 实现检索增强生成
- 管理上下文与对话状态
- 协调一个或多个LLM调用
- 提供聊天界面
这些任务单独来看都是可以处理的。但若手动将它们组合在一起，就会形成一堆复杂的自定义代码，此时要修改模型、向量存储或提示词格式，就不得不改动多个文件。LangChain的价值在于为每项功能提供标准接口和可重用的抽象层，从而使各组件能够轻松组合成处理流程，并且可以独立更换。
实际案例：AI读书器
设想这样一个应用：用户上传书籍或PDF文件，在内置阅读器中阅读，然后就所读内容向助手提问。以一本机器学习教材为例：学生可能会询问偏差-方差权衡问题、某种特定CNN架构的结构、反向传播的原理、注意力机制的工作方式，或是哪种优化算法适合解决某类问题。
只有看到正确的页面，助手才能给出准确答案。这一要求牵涉到一整套工作流程：加载上传的文件、找出与问题相关的段落、保持对话历史的连贯性、构建将问题与这些段落结合的提示语，最后将其发送给模型。
在这个应用中，LangChain将负责：
- 加载并解析上传的文档
- 将聊天界面与大语言模型连接起来
这最清楚地说明了为何仅靠大型语言模型无法构成完整的应用程序。模型提供语言处理能力；而与特定书籍相关的所有信息都来自其周围的组件。
语义搜索：通过含义查找文本
图书阅读器的核心功能是从海量内容中提取合适的段落。关键词搜索在此处存在局限，因为学生的提问很少会使用与教科书完全相同的词汇。语义搜索则通过嵌入技术解决这一问题：这些数值向量能将含义相似的文本片段在高维空间中放置得彼此靠近，从而通过查找与问题向量最接近的存储向量来实现搜索。
一个简单的例子
假设查询内容是“法国的首都是哪里？”。语义搜索系统不会去查找那些仅与问题有部分词汇重叠的文档，而是会寻找含义最接近的段落——即关于巴黎的段落，而非关于柏林或马德里的段落，尽管后两者也涉及欧洲首都的内容，在词汇重叠度上可能得分更高。
这就是两者在实际应用中的区别。关键词引擎是根据词汇重叠程度来排序的，而语义引擎则是根据含义的相似度来排序。在实践中，许多系统会将两者结合使用，因为产品代码或错误信息这类精确的术语仍然可以从关键词匹配中获益。
这对大语言模型应用为何重要
当模型获得相关上下文时，其回答质量会大幅提升。因此，良好的信息检索能够直接带来：
- 更优质的文档检索效果
LangChain 并不直接实现向量搜索功能，而是整合了所需的各种组件：嵌入模型、向量数据库、检索器以及相似度搜索功能，所有这些都通过统一的接口提供。
六步实现从问题到有依据的答案
一旦文档可以被搜索，回答问题的过程就遵循一定的顺序：
- 用户提问。以自然语言形式提出问题。
- 对问题进行嵌入处理。将其转换为向量，以便通过语义而非精确文字来进行比较。
- 检索相关文本。系统会获取向量值最接近的文档片段或页面。
- 输入内容被整合。检索到的段落与原始问题会被合并为模型所需的提示语。
- 模型对其进行处理。包含上下文与问题的完整提示语会被发送给大语言模型。
- 得到有依据的答案。由于模型是基于所提供的文本进行推理而非仅依赖记忆，因此回复更为准确，也更容易追溯其来源。
该列表中的每个箭头都代表组件之间的数据传递，而这正是LangChain旨在管理的功能。它简化了信息检索流程，将提示词步骤串联起来，管理内存，向提示词中注入上下文，并协调对模型的调用。这六步流程是任何RAG系统的核心。如果您想更深入地了解信息检索本身，我们关于RAG如何按需获取最新知识的解释文章会提供更详细的说明。
完整的RAG架构
上述六步流程假设文档已经过索引处理。一个完整的系统包含两个流程：一个是提前准备文档的流程，另一个是按需回答查询的流程。
为搜索准备文档
在有人提出问题之前，每份文档都必须被处理成可检索的形式：
- 上传。 PDF 文件会被存储到某个位置，例如 AWS S3 存储桶中。
- 加载。 文档加载器会读取该文件，并将其文本提取到处理流程中。
- 分割。 文本分割器会将文本拆分成更小的片段或页面。这样做很重要，因为如果将整本书作为一个向量来处理，其所有主题信息会混在一起，而且模型的上下文窗口容量有限。
- 嵌入。 每个片段都会经过嵌入模型处理，从而转化为向量。
- 存储。 这些向量以及它们所代表的文本会被保存在向量数据库中。
经过这一阶段后，文档即可被查询。通常每次上传文件时只会执行一次此操作，而非针对每个问题都重复执行。
回答查询
当有问题出现时，会启动第二套处理流程：
- 嵌入查询。使用相同的嵌入模型将问题转换为向量，使其与已存储的文本片段处于同一空间。
- 搜索。通过相似度搜索找到与问题最接近的文本片段。
- 获取上下文。从向量数据库中调取这些文本片段。
- 构建提示词。将获取的文本与用户的问题结合成系统提示词。
- 调用模型。将生成的提示词发送给大语言模型API。
- 回复。模型根据获取的资料返回答案。
初学者常犯的一个错误是：查询和文档必须使用相同的模型进行嵌入。来自两种不同嵌入模型的向量无法相互比较，若擅自混用会严重降低检索质量。
自行实现时的写法
在没有框架的情况下，开发团队需要手动处理提示词管理、检索逻辑、上下文注入、多步骤流程、内存管理、工具集成以及这些组件之间的协调工作。虽然每项功能本身并不复杂，但累积起来会导致代码与特定模型和数据库紧密绑定。LangChain为这些功能提供了可复用的抽象层，从而加快开发速度，并能在后续修改时减少代码重写量。
框架带来的优势
有四项优势反复被提及。
以链式结构作为组合模型
链式结构将各个步骤——如提示词模板、模型调用以及输出解析器——整合为一个可运行、测试和重复使用的单一工作流。在当前版本中，这是通过 Runnables 和 LCEL 来实现的，它们允许将各个组件串联起来。
与模型无关的代码
由于 LangChain 通过统一的接口支持各大 LLM 提供商，因此您的应用程序不会绑定在某一家供应商身上。更换模型只需调整配置即可，无需重新编写代码，这既有助于控制成本，也有利于尝试新的模型。
丰富的生态系统
该框架自带或可连接大量组件与集成功能：支持多种文件类型的加载器、多种向量存储库、嵌入服务提供商以及相关工具。您所需的大部分功能很可能已经以集成形式存在。
内存与状态管理
对话型应用需要记住之前说过的内容。LangChain提供了多种方法来管理不同交互中的对话上下文、记忆和状态。不同版本推荐的实现方式有所变化，较新的指南更倾向于使用LangGraph来实现有状态的工作流，因此请查阅对应版本的最新文档。
可使用它构建什么
常见的应用类型包括：
- 对话式聊天机器人，用户可以用自然语言与AI交流。
- 知识助手，帮助人们在自己的文档或知识库中查找并理解信息。
- AI智能体，能够处理多步骤任务并决定在过程中使用哪些工具。
- 工作流自动化，其中大语言模型只是更大规模自动化流程中的一个环节。
何时考虑替代方案
LangChain只是众多选项之一，每种替代方案都有其侧重点：
- LlamaIndex着重于将大语言模型与外部数据相连，并构建数据及RAG应用。
- Haystack专注于搜索、问答、RAG以及智能体应用。
- Semantic Kernel是微软推出的开源SDK，可将AI模型嵌入现有软件中，并协调多步骤的AI工作流程。
- DSPy将大语言模型系统视为需要优化的程序，而非要求用户手动编写每个提示词。
- AutoGen则是围绕多个智能体相互协作与交流的应用而设计的。
- CrewAI旨在协调多个智能体共同完成任务。
- PydanticAI是一个用于构建生产级应用及智能体的Python框架，能够生成结构化且类型安全的输出。
一个大致的判断标准是：如果您的应用主要涉及从自身数据中检索信息，那么值得考虑LlamaIndex或Haystack；如果您更看重类型化的输出，可选用PydanticAI；如果希望以多智能体协作为核心理念，AutoGen或CrewAI更为合适。LangChain的优势在于功能全面，因此在尚不确定应用最终形态时，它是一个合理的默认选择。如需直接对比这两种最常用的框架，请参阅我们关于LangChain与LlamaIndex的对比文章。
了解何时不需要使用框架也同样重要。对于仅需要单个提示的功能，或是只需调用一次模型并手动编写提示的简单脚本来说，没有抽象层往往更为清晰。只有当步骤数量和可替换组件增多时，框架的优势才会显现出来。
接下来需要学习的构建模块
在明确了整体架构后，接下来的自然步骤就是了解构成每个LangChain应用程序的各个组件：
- 模型，即用于与不同AI模型交互的接口。
- 提示词，用于决定模型对输入内容的响应方式。
- 链，用于将各个组件连接成工作流程。
- 索引，用于将应用程序与外部知识源相连。较新的文档通常会用加载器、向量存储和检索器来描述这一部分内容。
了解每部分的职责有助于更轻松地阅读 LangChain 代码，并判断自己的应用实际上需要哪些组件。
核心要点
- 大语言模型只是应用的一个组成部分；数据加载、检索、提示词构建、内存管理以及界面都是其他重要部分，而 LangChain 正是帮助你构建这些部分的工具。
- 语义搜索通过嵌入技术根据文本含义对其进行排序，因此当询问法国的首都时它能找到关于巴黎的段落。
- RAG系统由两个流程组成：一个是离线流程，负责加载、分割、嵌入并存储文档；另一个是在线流程，用于嵌入查询、检索上下文、构建提示词并调用模型。
- 必须始终使用相同的模型来嵌入查询和文档，否则检索质量会大幅下降。
- LangChain的主要优势在于基于链式的组合方式、对提供者的独立性、完善的集成生态系统，以及用于管理状态和内存的工具。
- 像LlamaIndex、Haystack、Semantic Kernel、DSPy、AutoGen、CrewAI和PydanticAI这样的替代方案各有侧重点，而一些非常简单的功能可能根本不需要任何框架。
相关阅读
- RAG架构解析：流程阶段、核心组件及不同变体 — 了解检索增强生成技术的端到端工作原理，RAG系统需要哪些组件，以及各类不同的RAG变体如何整合在同一框架中。
- RAG详解：AI系统如何按需获取最新知识 — 学习检索增强生成技术的运作机制，从数据分块与嵌入向量到向量搜索，了解为何AI模型无需重新训练即可回答问题。