LangChain实战入门：从消息模板到RAG管道

手写RAG之后，为什么还要用LangChain？

一位开发者曾手动构建过Synapse——一个基于个人笔记的问答应用。从加载文件、生成向量、检索相似片段到调用LLM，每一步都由自己编写。当开始接触LangChain这个号称能自动化全流程的框架时，他的第一反应是怀疑：它到底做了什么我没做过的事？

答案逐渐清晰：LangChain带来的不是新概念，而是为已有的想法提供了一套标准化的结构。本文将沿着这位开发者的学习路径，拆解LangChain的核心组件与RAG实现方式。

从消息与模板开始

聊天模型接收的不是单一字符串，而是一个消息列表：设定角色的系统消息、用户输入的人类消息，以及模型回复的AI消息。LangChain为每种消息提供了独立的类，本质上与原始API的要求一致。

提示模板是下一个实用步骤。无需每次手动拼接字符串，而是预先写好带占位符的提示。例如：

from langchain_core.prompts import ChatPromptTemplate

template = ChatPromptTemplate.from_template(
    "I've recently adopted a {pet}. Suggest three {pet} names."
)

输出解析器负责将模型返回的文本转换为可用的数据结构，比如Python列表。一个关键心得是：解析器的效果完全取决于指令的精确度——模糊的格式要求得到混乱的结果，严格的约束才能获得干净的输出。

嵌入模型与向量维度是理解后续检索环节的关键背景。嵌入模型（如OpenAI的text-embedding-ada-002）将一段文本映射为一个固定长度的浮点数向量，语义相近的文本在向量空间中距离更近。文中提到的1536维，指的是该模型为每个文本块输出的向量包含1536个数值。由于这些向量通常经过了归一化处理（长度约为1），两个向量之间的点积就等于余弦相似度，取值范围在-1到1之间，越接近1表示语义越相似。这就是为什么文中用0.88、0.80、0.79这样的分数来判断相关文本是否彼此靠近，也是RAG检索环节能够工作的数学基础。

管道：LangChain的核心抽象

真正让开发者豁然开朗的是管道操作符 |，它像Unix管道一样连接各个组件：

chain = chat_template | chat | list_output_parser
chain.invoke({"pet": "dog"})
# ['Max', 'Bella', 'Luna']

提示从一端进入，模型居中处理，干净的列表从另一端输出。每一步的输出就是下一步的输入——这就是全部理念。

普通Python函数也能通过 RunnableLambda 接入管道：

from langchain_core.runnables import RunnableLambda

add_up = RunnableLambda(lambda x: sum(x))
square = RunnableLambda(lambda x: x**2)

(add_up | square).invoke([1, 2, 5])   # 8, then 64

链条还可以可视化：chain.get_graph().print_ascii() 会打印出方框和箭头，在链条变长时尤其有用。

两个值得注意的功能：RunnableParallel 可以并行运行两条链并将结果传给下一步；batch 比循环更快——在作者的测试中，两次请求通过 batch 耗时2.67秒，而分开调用约需7.5秒。

用相同组件实现RAG

回顾手动构建RAG的五个步骤，LangChain为每一步都提供了对应组件。

加载与分割：针对不同文件类型有对应的加载器（如PDF和Word）。分割是手动实现时未曾涉及的新环节。作者对一份六页文档进行了两次分割：先按标题切分，确保每个块记住来源讲座；再按大小切分，约500字符并保留少量重叠，最终得到20个带来源标签的块。

嵌入：每个块通过OpenAI嵌入模型转换为1,536维向量。为验证效果，作者比较了三对块，相似度得分分别为0.88、0.80和0.79，说明相关文本确实在向量空间中彼此靠近。所有向量长度约为1，因此普通点积即可作为相似度分数。

存储与检索：向量存入Chroma，持久化到磁盘文件夹，避免每次打开笔记本都重新嵌入。检索有两种方式——普通相似度搜索返回最接近的块；MMR则返回既接近又彼此不同的块，防止重复段落。

串联成链：最后一步让管道回归：

chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt_template
    | chat
    | StrOutputParser()
)

chain.invoke("What software do data scientists use?")

检索器填充上下文，问题直接传递，提示要求模型仅基于上下文回答并注明使用的讲座，解析器返回纯文本。答案末尾附上了来源：

Resources: Programming Languages & Software Employed in Data Science - All the Tools You Need

这正是手动实现的“仅使用这些笔记”的防护栏，外加之前一直推迟添加的来源标注功能。

MMR（最大边际相关性） 是一种在检索时兼顾相关性与多样性的策略。普通相似度搜索会返回与查询最接近的若干文本块，但如果这些块内容高度重复，模型拿到的上下文就会浪费。MMR的做法是：先选最相关的块，再在后续选择中同时惩罚与已选块过于相似的候选，从而让返回结果既贴近问题又彼此不同。它通过一个λ参数平衡“相关性”与“多样性”，λ越大多样性权重越高。在问答场景中，当同一主题在多个笔记片段中反复出现时，MMR能有效避免模型只看到重复信息。

文本分割与重叠是手动实现RAG时容易被忽略、却直接影响检索质量的环节。分割过粗，一个块可能混杂多个主题，检索时匹配不准；分割过细，块会丢失上下文，模型难以理解。按标题切分属于结构性分割，能保留文档的语义边界；按大小切分（如约500字符）则控制单块长度，适配嵌入模型和上下文窗口的限制。保留少量重叠是为了防止关键句子恰好被切在边界处而被割裂。文中最终得到20个带来源标签的块，正是这两种策略叠加的结果，也是实现来源标注功能的前提。

对开发者意味着什么

LangChain没有传授新理念。管道中的每一步——加载、嵌入、找最近邻、提问——都是手动做过的。它提供的是每一步的标准形态，以及连接它们的管道。先走长路亲手构建，才能理解短路为何成立。

对于已经熟悉RAG原理的开发者，LangChain的价值在于减少样板代码、统一组件接口，并让批处理、并行化和可视化调试变得更容易。它不是魔法，而是对既有模式的提炼与封装。

下一步是LangGraph。