如何用LangChain打造RAG系统？

大模型（LLM）具有两大的局限：一是它不知道它不知道，所以会发现它经常天马行空、一本正经地胡说八道，这就是所谓的“幻觉”；而是模型具有的知识在训练生成的那一刻就已经冻结，知识体系不会继续更替，RAG是目前针对这两个问题的主要解决方案。RAG（Retrieval-Augmented Generation，检索增强生成）是一种结合了信息检索和文本生成的AI技术架构。它通过为大型语言模型（LLM）外挂一个“知识库”，让模型在回答问题前先去查询相关资料，从而有效解决了模型回答“胡编乱造”和知识滞后的问题。 1. 从一个简单的例子开始 RAG是对“针对当前推理任务检索相关信息，并提供给LLM以解决幻觉和知识滞后问题的解决思路”的统称，它并没有被局限于某一种或者几种固定的工作模式。而且从RAG被提出到现在，先后经历了如下的范式演进，而且在未来还会不断迭代下去： Naive RAG：标准的“检索-生成”流程，容易在复杂问题上出错。 Advanced RAG：引入了查询重写、递归检索和重排序等优化策略。 Modular RAG：架构更加灵活，可以根据需求增加插件（如Web搜索、逻辑计算）。 GraphRAG：利用知识图谱来处理更复杂的全局性问题（如“总结这10份报告的主要观点”）。 为让读者对LangChain针对RAG的实现方式由一个大概的了解，同时作为引子引出接下来我们着重介绍的内容，我们提供了一个非常简单的关于Q/A的演示实例，对于上述的范式演进，它只能算是最朴素的Naive RAG。 在博客园上由这么一篇文章“200行代码，7个对象——让你了解ASP.NET Core框架的本质”，它通过简单的代码揭示了ASP.NET Core这个Web框架的设计思路和实现原理，现在我们在此基础上建立一个针对ASP.NET Core的技术问答系统，也就是说我们希望针对用户提出的任何问题，都以这篇文章作为上下文进行解答。 这个简单的例子指导让大家了解构建“Naive RAG”管道的几个组件或者对象： Document：它是LangChain中数据的基本单位。无论原始数据是PDF、网页还是数据库记录，最终都会被统一封装成一个Document对象； BaseLoader：文档加载器，它加载不同形式和来源的内容，并将其转换成Document。不同形式和来源（比如PDF、网页和文件）具有的实现，BaseLoader是它们的基类； TextSplitter：LLM每次能处理的字符长度有限（Context Window），且直接检索整本书效率极低。TextSplitter负责将长文档切分成更小的块（Chunks）； VectorStore: 文本块被Embedding模型转化为“数字向量”后，存储在VectorStore中。它支持相似度搜索，能根据语义找到最相关的片段，而不是简单的关键词匹配； 一句话总结：Document是信息载体，由作为搬运工的BaseLoader提供，被TextSplitter裁切之后，以稠密向量（嵌入向量）的形式存储在VectorStore以实现基于自然语言的相似度查询。RAG中的检索（R：Retrieval）指的就是针对提供给LLM的原始查询文本（提示词）针对VectorStore的检索。检索的内容结果处理（比如重排序和压缩等）提供给LLM作为上下文，以增强（A：Augment）后者生成内容（G: Generation）的质量。