2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
从百行代码到生产级流水线
在上一篇文章中，我们用纯 Python 的 100 行代码构建了一个最小化的检索增强生成（RAG）系统。它确实能运行，也展示了核心思想。但如果你试图将那段代码投入生产环境，很快就会碰壁。
加载 PDF 文件？你需要使用 PyPDF2 或 pdfplumber，然后会发现表格、页眉和页脚的解析简直是一场噩梦，难以干净利落地完成。
分割文本？你那种天真的 text.split("\n\n") 做法会把句子截断，破坏代码块，或者生成过大的文本块，导致超出令牌（token）限制。
更换向量数据库？那就跟你的下午时光说再见吧——每个数据库都有不同的应用程序接口（API）、不同的距离度量标准以及不同的元数据处理方式。
切换大语言模型（LLM）提供商？开放人工智能公司（OpenAI）的客户端、安索帕克公司（Anthropic）的客户端、通过 llama.cpp 运行的本地模型——每种方案都有自己的消息格式、令牌计数方式和错误处理机制。
这正是 LangChain 存在的原因。它并不做什么魔法般的事情，也不会替换底层的模型或数据库。它所做的是简单而有价值的：它为你提供了一个统一的接口来连接各个组件，这样你就可以专注于 RAG 系统的逻辑，而不是底层的基础设施拼接。
在本文中，我们将使用 LangChain 的现代应用程序接口（API）重建我们的 RAG 流水线。到最后，你将拥有一个完整且可运行的项目，它能够加载 PDF 文件、智能地分割它们、将其存储在 ChromaDB 中，并使用支持多提供商的大语言模型（LLM）回答问题——而实际的流水线代码大约只有 30 行。
LangChain 版本说明：本文中的代码基于
langchain 1.x（当前稳定版）。LangChain 1.x 对0.3.x进行了破坏性重组——诸如create_retrieval_chain之类的高级应用程序接口（API）已被移除。我们改用 LCEL 原生语法（|管道运算符），这在功能上是等效的，且与版本无关。完整源代码：https://github.com/chendongqi/llm-in-action/tree/main/02-langchain-basic
RAG 流水线的六个组成部分
LangChain 将 RAG 分解为六个组件。理解每个组件的作用——以及质量风险隐藏在哪里——是日后调试 RAG 系统的关键。
| 组件 | 作用 | 质量风险 |
|---|---|---|
| 文档加载器 | 读取原始文件（PDF、Word、Markdown、HTML）并提取文本 | 表格、图片和奇怪的格式会被弄乱 |
| 文本分割器 | 将长文档切割成语义连贯的片段 | 片段过大 = 精度低；片段过小 = 上下文丢失 |
| 嵌入模型 | 将文本片段转换为高维向量 | 模型选择不当 = 语义不相关的文本聚集在一起 |
| 向量存储 | 持久化存储向量并支持快速相似性搜索 | 错误的距离度量或缺乏元数据过滤 = 检索效果差 |
| 检索器 | 接收查询，搜索向量存储，返回相关片段 | Top-K 值太低 = 信息缺失；太高 = 上下文噪声大 |
| 链 | 协调完整流程：查询 → 检索 → 提示词 → 大语言模型 → 回答 | 提示词设计和上下文组装决定回答质量 |
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
