引言想象一下这个场景你问 ChatGPT 一个关于你们公司内部制度的问题它信誓旦旦地给出一段看似合理、实则完全编造的答案——这就是大模型的幻觉Hallucination。大模型就像一个知识渊博但与世隔绝的学者它的知识截止于训练数据的日期。之后发生的事情、你企业内部没有公开的文档它全都不知道。但关键问题在于——它不会承认自己不知道而是会一本正经地胡说八道。那怎么解决呢答案就是我们今天的主角——RAGRetrieval-Augmented Generation检索增强生成。一、大模型的幻觉从何而来1.1 大模型的知识边界LLM大语言模型的知识完全取决于训练时喂给它的数据集。训练数据里没有的东西它就不可能知道。这带来了几个结构性的问题问题描述知识有截止日期训练数据只覆盖到某一时间点之后的新信息它无从得知无法访问私有数据企业内部文档、机密资料不会出现在公开训练数据中不懂装懂面对不知道的问题模型倾向于编造而非承认无知1.2 幻觉的本质所谓幻觉就是模型生成的内容与事实不符。这并非模型故意撒谎而是因为模型的输出本质上是概率性的——它只是在预测下一个最可能的 token当模型缺乏相关知识时它依然会根据语言模式推测出一个答案这个推测在语言上可能通顺但在事实上可能完全错误核心矛盾用户要查询的内容模型不知道模型却能生成一段看似合理的回答。二、解决幻觉的两条路Fine-tuning vs RAG想一下怎么让大模型知道它不知道的东西2.1 微调Fine-tuning把新知识直接训练进模型参数里。✅优点知识融入模型本身推理时无需额外检索❌缺点成本高昂需要大量标注数据和 GPU 算力而且知识更新就要重新训练2.2 RAG检索增强生成不给模型植入记忆而是在提问前先去知识库里查资料把查到的内容塞进 Prompt 里再让模型回答。✅优点成本低知识库随时更新可解释性强❌缺点依赖检索质量检索不到就回答不了类比理解Fine-tuning 让一个人去上全日制大学时间长、成本高、知识固化RAG 给一个人配了搜索引擎和百科全书随时查、成本低、知识实时更新对于大多数企业场景来说RAG 是现阶段性价比最高的方案。三、什么是 RAG3.1 名词拆解单词含义Retrieval检索去知识库里检索与用户问题相关的文档片段Augmented增强把检索到的内容作为背景知识增强到 Prompt 里Generation生成让大模型基于增强后的 Prompt 生成回答3.2 RAG 的工作流程用户提问 → 检索知识库找到相关文档片段→ 拼接到 Prompt 中 → 大模型生成回答具体来说用户提出一个问题去知识库中检索—— 找到与问题语义最相关的文档片段分片按章节/按页/按段落切分的自然语义段落拼接到 Prompt 中—— 把检索到的文档片段作为背景知识加入原始 Prompt大模型回答—— 基于这些背景知识生成准确、可靠的回答这就是 RAG 的整个流程先检索再增强最后生成。四、核心技术从关键词到向量语义搜索4.1 关键词搜索为什么不太行传统搜索依赖文本匹配你搜苹果好吃吗 → 匹配到包含苹果的文档但如果你搜那种红色的、咬起来嘎嘣脆的水果怎么样 → 关键词匹配可能完全找不到苹果相关内容问题所在语言表达千变万化同一个意思可以有无数种说法。关键词搜索无法理解语义。4.2 向量语义搜索这就是 RAG 的第一个技术突破向量Vector语义搜索。核心思想把文字转换成一个多维空间中的坐标向量语义相近的文字在空间中离得近。用一个直观的例子理解假设我们定义两个维度来描述食物维度一食用性0 不可食用1 高度可食用维度二硬度0 液体状1 非常坚硬那么食物向量坐标 [食用性, 硬度] 苹果[0.9, 0.3] 香蕉[0.9, 0.1] 水果抽象概念[0.9, 0.3] 石头[0.1, 0.9]向量空间中苹果与水果的距离很近[0.9, 0.3] ≈ [0.9, 0.3]→ 语义高度相关 ✅苹果与香蕉的距离也较近[0.9, 0.3] vs [0.9, 0.1]→ 水果之间语义相关 ✅苹果与石头的距离很远[0.9, 0.3] vs [0.1, 0.9]→ 语义无关 ❌这只是一个 2 维的简化示例。在实际应用中向量通常有几百到上千个维度可以表达极其丰富的语义信息。4.3 相似度计算两个向量的相似度通常用**余弦相似度Cosine Similarity**来衡量夹角越小 → 余弦值越接近 1 → 语义越相似夹角越大 → 余弦值越接近 -1 → 语义越不相似通过这种方式即使用户的提问用词完全不同只要能映射到相近的向量空间位置就能找到语义相关的文档。五、嵌入模型Embedding Model要把文字变成向量就需要一个专门的模型——嵌入模型Embedding Model。5.1 Embedding Model vs Generative Model类型用途成本Embedding Model将文本转换为向量表示 相对便宜Generative Model如 GPT、Claude生成文本、对话、推理 昂贵RAG 中两种模型配合使用Embedding Model负责把知识库文档和用户问题都向量化Generative Model负责根据检索结果生成最终回答5.2 能处理多种数据格式Embedding 技术不仅限于文字还可以处理 文本txt、markdown、pdf️ 图片通过多模态 embedding 模型 语音先转文字再 embedding 各种格式的文档所有内容向量化后就都能进行语义搜索了。六、RAG 的两个关键突破6.1 文档怎么切分Chunking知识库里的文档往往很长不可能一次性全部放入 Prompt有上下文长度限制。需要把文档切分成一个个有独立语义的片段Chunk。切分策略可以按策略适用场景示例 按章节结构化文档、书籍第一章、第二章... 按页PDF 等固定版式文档第1页、第2页... 按段落一般文章、文档每个自然段落一个 chunk✂️ 按固定大小通用策略每 512 tokens 一个 chunk可重叠好的切分策略是 RAG 效果的关键之一。切得太大 → 检索不精准切得太小 → 丢失上下文语义。6.2 文档怎么查向量检索第二个突破向量数据库Vector Database。传统数据库MySQL、PostgreSQL 等无法高效处理向量的相似度搜索。向量数据库专为此而生存储向量将切割后的文档片段通过 embedding 模型转换成向量存储起来相似度搜索查询时把用户问题也向量化在数据库中找最相似的向量⚡高性能支持海量向量的快速检索通过 ANN / 近似最近邻算法持久化存储数据不丢失可反复使用常见向量数据库Milvus、Pinecone、Weaviate、Qdrant、Chroma 等。七、RAG 完整架构图把整个流程串起来RAG 的完整架构如下┌─────────────────────────────────────────────────────────────────┐ │ RAG 系统架构 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ 知识库文档 │ ──► │ 文档切分 │ ──► │ Embedding Model │ │ │ │ (txt/pdf/ │ │ (Chunking) │ │ (文本 → 向量) │ │ │ │ md/...) │ │ │ │ │ │ │ └──────────┘ └──────────────┘ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 向量数据库 │ │ │ │ (存储索引) │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌──────────┐ ┌──────────────┐ │ │ │ │ 用户问题 │ ──► │ Embedding │ ────────────┘ │ │ │ │ │ (问题→向量) │ 相似度搜索 │ │ └──────────┘ └──────────────┘ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 相关文档片段 │ │ │ │ (检索结果Top-K) │ │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 增强后的 Prompt 原始问题 检索到的背景文档片段 │ │ │ └──────────────────────────┬───────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Generative Model │ │ │ │ (生成最终回答) │ │ │ └──────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘一句话总结在原始 Prompt 给到大模型之前先查询知识库把相关的文档片段作为背景知识加入到 Prompt 里再让大模型回答。这就是 RAG。八、代码实战用 LangChain 构建 RAG 系统光说不练假把式我们来看一个基于 LangChain 的 RAG 实现示例。8.1 环境准备{ name: rag-test, dependencies: { langchain/core: ^1.2.2, langchain/openai: ^1.5.5, dotenv: ^17.4.2 } }三个核心依赖langchain/openai统一封装 OpenAI 兼容的 LLM 和 Embedding 接口langchain/coreLangChain 核心库提供 Document、Tool 等抽象dotenv环境变量管理8.2 初始化模型import dotenv/config import { ChatOpenAI, OpenAIEmbeddings } from langchain/openai import { Document } from langchain/core/documents // 初始化 Chat 模型用于最终生成回答 const model new ChatOpenAI({ temperature: 0, // 温度设为 0确保回答稳定 model: process.env.MODEL_NAME, // 例如gpt-4o / deepseek-chat apiKey: process.env.OPENAI_API_KEY, configuration: { baseURL: process.env.OPENAI_BASE_URL, } }) // 初始化 Embedding 模型用于文本向量化 const embeddings new OpenAIEmbeddings({ apiKey: process.env.OPENAI_API_KEY, model: process.env.EMBEDDINGS_MODEL_NAME, // 例如text-embedding-3-small configuration: { baseURL: process.env.OPENAI_BASE_URL, } })关键点temperature: 0→ 确保回答的确定性和一致性RAG 场景不需要创造性Embedding 模型和 Chat 模型是两个独立的模型各司其职8.3 构建知识库文档我们用一个关于光光和东东的儿童故事作为知识库const documents [ new Document({ pageContent: 光光是一个活泼开朗的小男孩他有一双明亮的大眼睛 总是带着灿烂的笑容。光光最喜欢的事情就是和朋友们一起玩耍他特别 擅长踢足球每次在球场上奔跑时就像一道阳光一样充满活力。, metadata: { chapter: 1, character: 光光, type: 角色介绍, mood: 活泼 }, }), new Document({ pageContent: 东东是光光最好的朋友他是一个安静而聪明的男孩。 东东喜欢读书和画画他的画总是充满了想象力。虽然性格不同但东东 和光光从幼儿园就认识了他们一起度过了无数个快乐的时光。, metadata: { chapter: 2, character: 东东, type: 角色介绍, mood: 温馨 }, }), new Document({ pageContent: 有一天学校要举办一场足球比赛光光非常兴奋 他邀请东东一起参加。但是东东从来没有踢过足球他担心自己会拖累 光光。光光看出了东东的担忧他拍着东东的肩膀说没关系我们 一起练习我相信你一定能行的, metadata: { chapter: 3, character: 光光和东东, type: 友情情节, mood: 鼓励, }, }), // ... 更多文档片段 ]Document 的两个核心字段字段作用是否参与向量化pageContent文档正文内容是检索匹配的核心✅ 是metadata元信息章节、角色、类型、情感等用于后续过滤和溯源❌ 否metadata不参与向量化计算但它非常重要——可以帮助你在检索后做元数据过滤、来源标注、分类展示等。提问const question 光光和东东怎么成为朋友的8.4 RAG 检索流程核心逻辑扩展虽然原始代码在此处结束了但完整的 RAG 流程应该是这样的// Step 1: 将知识库文档向量化并存入向量数据库 const vectorStore await MemoryVectorStore.fromDocuments( documents, embeddings ) // Step 2: 将用户问题向量化并在向量数据库中检索 const relevantDocs await vectorStore.similaritySearch(question, 3) // 返回与问题语义最相似的前 3 个文档片段 // Step 3: 构建增强后的 Prompt const context relevantDocs.map(doc doc.pageContent).join(\n\n) const augmentedPrompt 请基于以下背景知识回答问题。如果背景知识中没有相关信息请明确说明。 【背景知识】 ${context} 【用户问题】 ${question} 【回答】 // Step 4: 调用大模型生成回答 const response await model.invoke(augmentedPrompt) console.log(response.content)预期的大模型回答基于检索到的文档光光和东东从幼儿园就认识了。虽然性格不同——光光活泼开朗、擅长踢足球东东安静聪明、喜欢读书画画——但他们从幼儿园开始就是最好的朋友。光光邀请东东一起参加足球比赛并耐心地教东东踢球东东也为光光画画作为回报。在足球比赛中东东传出一个漂亮的球光光射门得分他们的友谊变得更加深厚了。这样的回答完全基于知识库中检索到的真实内容不会产生幻觉。九、RAG 在 Agent 生态系统中的定位RAG 不是一个孤立的技术它是构建AI Agent的核心模块之一。9.1 Agent 的公式Agent LLM Memory Tool RAG MCP Skills模块解决的问题说明LLM基础推理能力大模型的大脑Memory无状态问题记住上下文、用户偏好、项目规范Tool无法操作外部世界调用 API、操作文件、执行命令RAG知识盲区检索内部知识库获取私有信息MCP跨进程/跨语言工具调用标准化 Tool 通信协议Skills复杂任务编排可复用的技能包9.2 RAG vs MCP两种上下文扩展方式RAG先检索再增强 —— 解决知识不在训练数据中的问题MCP跨进程提供 Tool Resource —— 解决工具跨语言/跨项目复用的问题两者并不互斥可以结合使用。例如通过 MCP 连接一个远程的知识库服务然后在 Agent 内部用 RAG 的方式检索其中的文档。十、RAG 的进阶挑战与优化方向掌握 RAG 的基本概念只是第一步在实际落地中你还会遇到这些挑战挑战描述优化方向文档切分策略chunk 太大检索不精准太小丢失语义语义切分、滑动窗口、层级索引检索精度召回率 vs 准确率的平衡混合检索向量关键词、ReRank 重排序知识更新文档变更后如何同步增量索引、版本管理多轮对话后续问题可能指代之前的上下文Query 改写、对话历史向量化️多模态 RAG图片、表格、代码等非文本内容多模态 Embedding 结构化解析十一、总结RAG检索增强生成的精髓可以用三句话概括大模型不知道的东西它不会承认不知道而是会胡说幻觉RAG 的核心思路问之前先去知识库查一下查到的东西塞进 Prompt 再让模型回答向量 语义搜索是 RAG 实现的技术基石嵌入模型把文字变成向量向量数据库做相似度检索从更大的视角看RAG 是Harness Engineering挽具工程的典型代表之一。LLM 就像一个强大的引擎但引擎再牛没有好的变速箱、刹车和仪表盘这辆车就没法上路。RAG 就是给模型装上了一个知识检索系统让它的能力可以被稳定、可靠地驾驭。引擎是模型Harness 就是装着引擎的车。RAG 是这辆车上最关键的零件之一。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
一文搞懂 RAG（检索增强生成）：从 LLM 幻觉到智能检索，手把手带你理解核心原理与代码实现
引言想象一下这个场景你问 ChatGPT 一个关于你们公司内部制度的问题它信誓旦旦地给出一段看似合理、实则完全编造的答案——这就是大模型的幻觉Hallucination。大模型就像一个知识渊博但与世隔绝的学者它的知识截止于训练数据的日期。之后发生的事情、你企业内部没有公开的文档它全都不知道。但关键问题在于——它不会承认自己不知道而是会一本正经地胡说八道。那怎么解决呢答案就是我们今天的主角——RAGRetrieval-Augmented Generation检索增强生成。一、大模型的幻觉从何而来1.1 大模型的知识边界LLM大语言模型的知识完全取决于训练时喂给它的数据集。训练数据里没有的东西它就不可能知道。这带来了几个结构性的问题问题描述知识有截止日期训练数据只覆盖到某一时间点之后的新信息它无从得知无法访问私有数据企业内部文档、机密资料不会出现在公开训练数据中不懂装懂面对不知道的问题模型倾向于编造而非承认无知1.2 幻觉的本质所谓幻觉就是模型生成的内容与事实不符。这并非模型故意撒谎而是因为模型的输出本质上是概率性的——它只是在预测下一个最可能的 token当模型缺乏相关知识时它依然会根据语言模式推测出一个答案这个推测在语言上可能通顺但在事实上可能完全错误核心矛盾用户要查询的内容模型不知道模型却能生成一段看似合理的回答。二、解决幻觉的两条路Fine-tuning vs RAG想一下怎么让大模型知道它不知道的东西2.1 微调Fine-tuning把新知识直接训练进模型参数里。✅优点知识融入模型本身推理时无需额外检索❌缺点成本高昂需要大量标注数据和 GPU 算力而且知识更新就要重新训练2.2 RAG检索增强生成不给模型植入记忆而是在提问前先去知识库里查资料把查到的内容塞进 Prompt 里再让模型回答。✅优点成本低知识库随时更新可解释性强❌缺点依赖检索质量检索不到就回答不了类比理解Fine-tuning 让一个人去上全日制大学时间长、成本高、知识固化RAG 给一个人配了搜索引擎和百科全书随时查、成本低、知识实时更新对于大多数企业场景来说RAG 是现阶段性价比最高的方案。三、什么是 RAG3.1 名词拆解单词含义Retrieval检索去知识库里检索与用户问题相关的文档片段Augmented增强把检索到的内容作为背景知识增强到 Prompt 里Generation生成让大模型基于增强后的 Prompt 生成回答3.2 RAG 的工作流程用户提问 → 检索知识库找到相关文档片段→ 拼接到 Prompt 中 → 大模型生成回答具体来说用户提出一个问题去知识库中检索—— 找到与问题语义最相关的文档片段分片按章节/按页/按段落切分的自然语义段落拼接到 Prompt 中—— 把检索到的文档片段作为背景知识加入原始 Prompt大模型回答—— 基于这些背景知识生成准确、可靠的回答这就是 RAG 的整个流程先检索再增强最后生成。四、核心技术从关键词到向量语义搜索4.1 关键词搜索为什么不太行传统搜索依赖文本匹配你搜苹果好吃吗 → 匹配到包含苹果的文档但如果你搜那种红色的、咬起来嘎嘣脆的水果怎么样 → 关键词匹配可能完全找不到苹果相关内容问题所在语言表达千变万化同一个意思可以有无数种说法。关键词搜索无法理解语义。4.2 向量语义搜索这就是 RAG 的第一个技术突破向量Vector语义搜索。核心思想把文字转换成一个多维空间中的坐标向量语义相近的文字在空间中离得近。用一个直观的例子理解假设我们定义两个维度来描述食物维度一食用性0 不可食用1 高度可食用维度二硬度0 液体状1 非常坚硬那么食物向量坐标 [食用性, 硬度] 苹果[0.9, 0.3] 香蕉[0.9, 0.1] 水果抽象概念[0.9, 0.3] 石头[0.1, 0.9]向量空间中苹果与水果的距离很近[0.9, 0.3] ≈ [0.9, 0.3]→ 语义高度相关 ✅苹果与香蕉的距离也较近[0.9, 0.3] vs [0.9, 0.1]→ 水果之间语义相关 ✅苹果与石头的距离很远[0.9, 0.3] vs [0.1, 0.9]→ 语义无关 ❌这只是一个 2 维的简化示例。在实际应用中向量通常有几百到上千个维度可以表达极其丰富的语义信息。4.3 相似度计算两个向量的相似度通常用**余弦相似度Cosine Similarity**来衡量夹角越小 → 余弦值越接近 1 → 语义越相似夹角越大 → 余弦值越接近 -1 → 语义越不相似通过这种方式即使用户的提问用词完全不同只要能映射到相近的向量空间位置就能找到语义相关的文档。五、嵌入模型Embedding Model要把文字变成向量就需要一个专门的模型——嵌入模型Embedding Model。5.1 Embedding Model vs Generative Model类型用途成本Embedding Model将文本转换为向量表示 相对便宜Generative Model如 GPT、Claude生成文本、对话、推理 昂贵RAG 中两种模型配合使用Embedding Model负责把知识库文档和用户问题都向量化Generative Model负责根据检索结果生成最终回答5.2 能处理多种数据格式Embedding 技术不仅限于文字还可以处理 文本txt、markdown、pdf️ 图片通过多模态 embedding 模型 语音先转文字再 embedding 各种格式的文档所有内容向量化后就都能进行语义搜索了。六、RAG 的两个关键突破6.1 文档怎么切分Chunking知识库里的文档往往很长不可能一次性全部放入 Prompt有上下文长度限制。需要把文档切分成一个个有独立语义的片段Chunk。切分策略可以按策略适用场景示例 按章节结构化文档、书籍第一章、第二章... 按页PDF 等固定版式文档第1页、第2页... 按段落一般文章、文档每个自然段落一个 chunk✂️ 按固定大小通用策略每 512 tokens 一个 chunk可重叠好的切分策略是 RAG 效果的关键之一。切得太大 → 检索不精准切得太小 → 丢失上下文语义。6.2 文档怎么查向量检索第二个突破向量数据库Vector Database。传统数据库MySQL、PostgreSQL 等无法高效处理向量的相似度搜索。向量数据库专为此而生存储向量将切割后的文档片段通过 embedding 模型转换成向量存储起来相似度搜索查询时把用户问题也向量化在数据库中找最相似的向量⚡高性能支持海量向量的快速检索通过 ANN / 近似最近邻算法持久化存储数据不丢失可反复使用常见向量数据库Milvus、Pinecone、Weaviate、Qdrant、Chroma 等。七、RAG 完整架构图把整个流程串起来RAG 的完整架构如下┌─────────────────────────────────────────────────────────────────┐ │ RAG 系统架构 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ 知识库文档 │ ──► │ 文档切分 │ ──► │ Embedding Model │ │ │ │ (txt/pdf/ │ │ (Chunking) │ │ (文本 → 向量) │ │ │ │ md/...) │ │ │ │ │ │ │ └──────────┘ └──────────────┘ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 向量数据库 │ │ │ │ (存储索引) │ │ │ └────────┬─────────┘ │ │ │ │ │ ┌──────────┐ ┌──────────────┐ │ │ │ │ 用户问题 │ ──► │ Embedding │ ────────────┘ │ │ │ │ │ (问题→向量) │ 相似度搜索 │ │ └──────────┘ └──────────────┘ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ 相关文档片段 │ │ │ │ (检索结果Top-K) │ │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 增强后的 Prompt 原始问题 检索到的背景文档片段 │ │ │ └──────────────────────────┬───────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Generative Model │ │ │ │ (生成最终回答) │ │ │ └──────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘一句话总结在原始 Prompt 给到大模型之前先查询知识库把相关的文档片段作为背景知识加入到 Prompt 里再让大模型回答。这就是 RAG。八、代码实战用 LangChain 构建 RAG 系统光说不练假把式我们来看一个基于 LangChain 的 RAG 实现示例。8.1 环境准备{ name: rag-test, dependencies: { langchain/core: ^1.2.2, langchain/openai: ^1.5.5, dotenv: ^17.4.2 } }三个核心依赖langchain/openai统一封装 OpenAI 兼容的 LLM 和 Embedding 接口langchain/coreLangChain 核心库提供 Document、Tool 等抽象dotenv环境变量管理8.2 初始化模型import dotenv/config import { ChatOpenAI, OpenAIEmbeddings } from langchain/openai import { Document } from langchain/core/documents // 初始化 Chat 模型用于最终生成回答 const model new ChatOpenAI({ temperature: 0, // 温度设为 0确保回答稳定 model: process.env.MODEL_NAME, // 例如gpt-4o / deepseek-chat apiKey: process.env.OPENAI_API_KEY, configuration: { baseURL: process.env.OPENAI_BASE_URL, } }) // 初始化 Embedding 模型用于文本向量化 const embeddings new OpenAIEmbeddings({ apiKey: process.env.OPENAI_API_KEY, model: process.env.EMBEDDINGS_MODEL_NAME, // 例如text-embedding-3-small configuration: { baseURL: process.env.OPENAI_BASE_URL, } })关键点temperature: 0→ 确保回答的确定性和一致性RAG 场景不需要创造性Embedding 模型和 Chat 模型是两个独立的模型各司其职8.3 构建知识库文档我们用一个关于光光和东东的儿童故事作为知识库const documents [ new Document({ pageContent: 光光是一个活泼开朗的小男孩他有一双明亮的大眼睛 总是带着灿烂的笑容。光光最喜欢的事情就是和朋友们一起玩耍他特别 擅长踢足球每次在球场上奔跑时就像一道阳光一样充满活力。, metadata: { chapter: 1, character: 光光, type: 角色介绍, mood: 活泼 }, }), new Document({ pageContent: 东东是光光最好的朋友他是一个安静而聪明的男孩。 东东喜欢读书和画画他的画总是充满了想象力。虽然性格不同但东东 和光光从幼儿园就认识了他们一起度过了无数个快乐的时光。, metadata: { chapter: 2, character: 东东, type: 角色介绍, mood: 温馨 }, }), new Document({ pageContent: 有一天学校要举办一场足球比赛光光非常兴奋 他邀请东东一起参加。但是东东从来没有踢过足球他担心自己会拖累 光光。光光看出了东东的担忧他拍着东东的肩膀说没关系我们 一起练习我相信你一定能行的, metadata: { chapter: 3, character: 光光和东东, type: 友情情节, mood: 鼓励, }, }), // ... 更多文档片段 ]Document 的两个核心字段字段作用是否参与向量化pageContent文档正文内容是检索匹配的核心✅ 是metadata元信息章节、角色、类型、情感等用于后续过滤和溯源❌ 否metadata不参与向量化计算但它非常重要——可以帮助你在检索后做元数据过滤、来源标注、分类展示等。提问const question 光光和东东怎么成为朋友的8.4 RAG 检索流程核心逻辑扩展虽然原始代码在此处结束了但完整的 RAG 流程应该是这样的// Step 1: 将知识库文档向量化并存入向量数据库 const vectorStore await MemoryVectorStore.fromDocuments( documents, embeddings ) // Step 2: 将用户问题向量化并在向量数据库中检索 const relevantDocs await vectorStore.similaritySearch(question, 3) // 返回与问题语义最相似的前 3 个文档片段 // Step 3: 构建增强后的 Prompt const context relevantDocs.map(doc doc.pageContent).join(\n\n) const augmentedPrompt 请基于以下背景知识回答问题。如果背景知识中没有相关信息请明确说明。 【背景知识】 ${context} 【用户问题】 ${question} 【回答】 // Step 4: 调用大模型生成回答 const response await model.invoke(augmentedPrompt) console.log(response.content)预期的大模型回答基于检索到的文档光光和东东从幼儿园就认识了。虽然性格不同——光光活泼开朗、擅长踢足球东东安静聪明、喜欢读书画画——但他们从幼儿园开始就是最好的朋友。光光邀请东东一起参加足球比赛并耐心地教东东踢球东东也为光光画画作为回报。在足球比赛中东东传出一个漂亮的球光光射门得分他们的友谊变得更加深厚了。这样的回答完全基于知识库中检索到的真实内容不会产生幻觉。九、RAG 在 Agent 生态系统中的定位RAG 不是一个孤立的技术它是构建AI Agent的核心模块之一。9.1 Agent 的公式Agent LLM Memory Tool RAG MCP Skills模块解决的问题说明LLM基础推理能力大模型的大脑Memory无状态问题记住上下文、用户偏好、项目规范Tool无法操作外部世界调用 API、操作文件、执行命令RAG知识盲区检索内部知识库获取私有信息MCP跨进程/跨语言工具调用标准化 Tool 通信协议Skills复杂任务编排可复用的技能包9.2 RAG vs MCP两种上下文扩展方式RAG先检索再增强 —— 解决知识不在训练数据中的问题MCP跨进程提供 Tool Resource —— 解决工具跨语言/跨项目复用的问题两者并不互斥可以结合使用。例如通过 MCP 连接一个远程的知识库服务然后在 Agent 内部用 RAG 的方式检索其中的文档。十、RAG 的进阶挑战与优化方向掌握 RAG 的基本概念只是第一步在实际落地中你还会遇到这些挑战挑战描述优化方向文档切分策略chunk 太大检索不精准太小丢失语义语义切分、滑动窗口、层级索引检索精度召回率 vs 准确率的平衡混合检索向量关键词、ReRank 重排序知识更新文档变更后如何同步增量索引、版本管理多轮对话后续问题可能指代之前的上下文Query 改写、对话历史向量化️多模态 RAG图片、表格、代码等非文本内容多模态 Embedding 结构化解析十一、总结RAG检索增强生成的精髓可以用三句话概括大模型不知道的东西它不会承认不知道而是会胡说幻觉RAG 的核心思路问之前先去知识库查一下查到的东西塞进 Prompt 再让模型回答向量 语义搜索是 RAG 实现的技术基石嵌入模型把文字变成向量向量数据库做相似度检索从更大的视角看RAG 是Harness Engineering挽具工程的典型代表之一。LLM 就像一个强大的引擎但引擎再牛没有好的变速箱、刹车和仪表盘这辆车就没法上路。RAG 就是给模型装上了一个知识检索系统让它的能力可以被稳定、可靠地驾驭。引擎是模型Harness 就是装着引擎的车。RAG 是这辆车上最关键的零件之一。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
