1. 从对话式 AI 到知识增强为什么第四篇要聊 RAG做对话式 AI 和聊天机器人做到第四篇如果前三篇还在聊怎么调 API、怎么写提示词、怎么管理多轮对话上下文那这一篇必须往深水区走了。原因很简单任何一个真正在生产环境跑过聊天机器人的人都会遇到同一个天花板——模型本身的知识是静态的它不知道你公司的内部文档不知道你昨天刚更新的产品手册更不知道你私有的那套业务规则。你问它一个稍微偏门一点的专业问题它要么一本正经地胡说八道要么直接告诉你“我的知识截止到某年某月”。这个问题的本质不是模型不够聪明而是大语言模型的知识边界是训练时冻结的。你可以通过微调去注入新知识但微调成本高、周期长、更新一次要重训一次对于知识频繁变动的场景根本不现实。于是 RAGRetrieval-Augmented Generation检索增强生成就成了过去两年里最务实的一条路不改模型而是在模型回答问题之前先从外部知识库里把相关内容检索出来塞进提示词的上下文里让模型“看着资料回答”。这一篇的核心就是把这套 RAG 的完整链路拆开讲透。从 LangChain 的框架选型到 ChromaDB 的向量存储再到文档切分、嵌入、检索、重排、生成这一整条流水线我会把每个环节的关键参数、踩过的坑、以及实际项目中的取舍逻辑都摊开来说。适合已经跑通过基础对话机器人、想往知识增强方向进阶的开发者也适合正在评估 RAG 方案到底能不能落地的技术负责人。读完你应该能自己动手搭一套可用的 RAG 知识库并且知道哪些地方容易翻车。2. RAG 到底是什么把“开卷考试”讲清楚2.1 用一个类比理解 RAG 的核心逻辑我一直觉得理解 RAG 最好的方式就是把它想象成一场开卷考试。闭卷考试的时候学生只能靠脑子里记住的东西答题记不住的就只能瞎蒙。大语言模型在没有 RAG 的时候就是这个状态——它的“脑子”就是训练时记住的那些参数训练之后发生的事它一概不知。开卷考试就不一样了学生可以带一堆参考资料进考场遇到不会的题先翻书找到相关章节然后结合书上的内容组织答案。RAG 干的就是这件事检索Retrieval就是翻书找相关章节增强Augmented就是把找到的内容和问题一起交给模型生成Generation就是模型结合资料写出答案。这个类比能解释很多实际现象。比如为什么 RAG 的效果高度依赖检索质量——如果书翻错了页找到的是不相关的章节那模型再聪明也答不对。再比如为什么文档切分策略这么重要——如果书被撕成了一页一页的碎片每页只有半句话那翻到了也没用。理解了这一点后面所有的工程细节就都有了落脚点。2.2 RAG 和微调、知识库的本质区别很多人一开始会纠结我到底该用 RAG 还是微调这里必须把几个概念掰清楚。微调Fine-tuning是把新知识通过训练的方式写进模型参数里。它的优势是推理时不需要额外检索速度快而且模型能学到知识的“风格”和“语气”。但劣势也很明显每次知识更新都要重新训练成本高训练数据准备麻烦而且微调容易导致模型遗忘原有能力也就是所谓的灾难性遗忘。RAG 则完全不碰模型参数知识存在外部数据库里更新知识就是更新数据库实时性极强。缺点是每次问答都要多一次检索开销而且检索质量直接决定回答质量。至于知识库这里要区分三种形态。结构化知识库指的是关系型数据库、知识图谱这类有明确 schema 的数据查询靠 SQL 或图查询语言精确但覆盖面窄。非结构化知识库就是一堆文档、PDF、网页信息量大但没法直接查询。RAG 知识库本质上是把非结构化知识库做了向量化处理让它变得可以被“语义检索”。三者不是替代关系而是互补关系——实际项目里经常是结构化数据走 SQL 查询非结构化数据走 RAG 检索最后合并成上下文喂给模型。维度微调RAG结构化知识库知识更新成本高需重训低改数据库即可低改表即可实时性差好好推理开销低中多一次检索低适合场景风格迁移、固定领域知识频繁变动精确查询、统计可解释性差好能看到检索来源好2.3 什么时候该上 RAG什么时候别硬上不是所有场景都适合 RAG。我见过不少项目明明就是几十条 FAQ非要搭一套向量数据库加检索链路结果维护成本比直接写 if-else 还高。判断标准其实很简单如果你的知识总量小到可以全部塞进提示词那就别搞 RAG。比如一个产品的常见问题就三五十条直接拼进 system prompt 里模型照样答得又快又准。真正需要 RAG 的场景通常满足几个条件知识量大几百上千篇文档、知识更新频繁、需要引用来源、对回答准确性要求高。典型的就是企业内部的客服机器人、技术文档问答、法律条文检索、医疗知识辅助这些。这些场景的共同点是模型本身不可能记住这么多细节但用户又要求回答必须基于真实资料。3. 技术选型LangChain、ChromaDB 和嵌入模型怎么挑3.1 LangChain 在 RAG 链路里到底扮演什么角色LangChain 刚出来的时候被吹得很神后来又被不少人吐槽“过度封装”。我的实际体会是LangChain 的价值在于它把 RAG 的各个组件标准化了。文档加载器、文本切分器、嵌入模型、向量存储、检索器、提示词模板、输出解析器这些环节它都有对应的抽象你可以像搭积木一样把它们串起来。但它的坑也很明显。版本迭代太快API 经常变网上搜到的教程可能半年前就失效了。而且它的抽象层有时候会掩盖底层细节出了问题不好排查。我的建议是入门阶段用 LangChain 快速跑通链路理解每个环节在干什么生产环境如果对性能和可控性要求高可以考虑把关键环节用原生库重写。LangChain 里 RAG 的核心链路大概是这样先用DocumentLoader把各种格式的文档读进来然后用TextSplitter切分成小块接着用Embeddings模型把每块转成向量存进VectorStore检索时用Retriever根据 query 找出最相关的块最后用PromptTemplate把问题和检索结果拼起来交给 LLM。from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma loader PyPDFLoader(manual.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_documents(docs) embeddings OpenAIEmbeddings() vectorstore Chroma.from_documents(chunks, embeddings, persist_directory./db)这段代码就是最基础的入库流程。看着简单但每个参数背后都有讲究后面会细说。3.2 ChromaDB 为什么适合中小型 RAG 项目向量数据库的选择其实挺多的Pinecone、Weaviate、Milvus、Qdrant、FAISS还有 ChromaDB。我为什么在中小型项目里优先推荐 ChromaDB主要是三个原因。第一是部署简单。ChromaDB 可以完全跑在本地不需要额外起服务pip install chromadb之后直接就能用数据持久化到本地目录。对于个人项目或者内部工具来说这个便利性太重要了。Pinecone 是云服务要注册要付费Milvus 功能强但部署重适合大规模场景。第二是和 LangChain 集成好。Chroma 是 LangChain 官方支持的向量存储之一接口统一切换成本低。如果哪天项目长大了要换 Milvus代码改动量也不大。第三是够用。ChromaDB 支持 HNSW 索引检索性能在百万级向量以内完全没问题。大多数企业知识库的文档量根本到不了这个级别用 Chroma 绰绰有余。当然它也有局限。分布式支持弱多节点部署麻烦元数据过滤能力相比专业向量库要弱一些。但这些都是规模上来之后才需要考虑的问题早期项目没必要过度设计。3.3 嵌入模型的选择别只盯着 OpenAI嵌入模型决定了文本被转成什么样的向量直接影响检索质量。OpenAI 的text-embedding-ada-002和text-embedding-3-small是很多人的默认选择效果好、稳定、API 调用方便。但它有两个问题一是要花钱二是数据要发到外部涉及隐私的场景用不了。开源方案里BGE系列BAAI 出品和m3e系列在中文场景下表现都不错可以本地部署。sentence-transformers库用起来也简单。我的建议是如果做中文知识库优先试试 BGE-large-zh效果不比 OpenAI 差而且完全本地化。选嵌入模型的时候要注意一个关键点入库用的模型和检索用的模型必须是同一个。因为不同模型生成的向量空间不一样混用会导致检索结果完全错乱。这个坑我见过不止一个项目踩过切换模型的时候忘了重新入库结果检索出来全是无关内容。4. 文档处理RAG 效果的地基4.1 文档加载格式五花八门怎么统一实际项目里的文档格式能有多杂PDF、Word、Excel、Markdown、HTML、TXT甚至还有扫描件和图片。LangChain 提供了各种 Loader但每个 Loader 的坑都不一样。PDF 是最麻烦的。PyPDFLoader对文本型 PDF 还行但遇到扫描件就抓瞎得先上 OCR。而且 PDF 的排版信息在提取时会丢失表格会变成一堆乱序的文字。如果文档里表格多建议用pdfplumber或者unstructured库它们对表格和版面的保留更好。Word 文档用Docx2txtLoader或者UnstructuredWordDocumentLoader后者对格式保留更好但依赖较重。HTML 用UnstructuredHTMLLoader或者BeautifulSoup自己解析注意去掉导航栏、页脚这些噪音。我的经验是加载环节一定要做清洗。去掉多余的空行、页眉页脚、重复的版权声明这些噪音会污染检索结果。宁可加载慢一点也要保证进去的内容是干净的。4.2 文本切分chunk_size 到底设多少文本切分是 RAG 里最容易被低估的环节。切得太大检索出来的块包含太多无关信息会稀释关键内容切得太小语义不完整模型拿到半句话也没法用。RecursiveCharacterTextSplitter是 LangChain 里最常用的切分器它的逻辑是按分隔符优先级递归切分先按段落切段落还太大就按句子切句子还太大就按字符切。这样能尽量保证语义完整性。chunk_size的设置没有标准答案但有个经验范围中文场景下 300 到 800 字符比较合适。太小了语义不全太大了检索精度下降。chunk_overlap一般设成 chunk_size 的 10% 到 20%目的是让相邻块之间有重叠避免关键信息正好被切断。splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , , , ] )注意separators参数中文场景一定要把中文标点加进去默认的分隔符是给英文设计的。这个细节不注意切出来的块会很奇怪。4.3 元数据别让检索结果丢了上下文很多人入库的时候只存文本内容忽略了元数据。这是个隐患。因为检索出来一个块之后你往往需要知道它来自哪个文档、哪一页、什么章节这样才能给用户提供引用来源或者在提示词里补充上下文。ChromaDB 支持给每个向量附带 metadata入库的时候把source、page、title这些信息一起存进去。检索的时候可以按元数据过滤比如只在某个文档范围内检索或者只检索某个时间之后的内容。for i, chunk in enumerate(chunks): chunk.metadata[source] manual.pdf chunk.metadata[chunk_id] i这个chunk_id在排查问题时特别有用能快速定位到具体是哪个块出了问题。5. 检索与生成RAG 链路的最后一公里5.1 相似度检索的几种策略最基础的检索就是向量相似度搜索把 query 也转成向量然后找余弦相似度最高的 top-k 个块。但单纯靠向量相似度有几个问题一是对关键词匹配不敏感比如用户搜一个专有名词向量检索可能找不准二是 top-k 的 k 值不好定太小了漏信息太大了引入噪音。改进方案有几种。混合检索Hybrid Search是把向量检索和关键词检索BM25结合起来各取所长。MMR最大边际相关性是在保证相关性的同时增加结果多样性避免检索出来的块内容都差不多。多查询检索Multi-Query是用 LLM 把用户问题改写成几个不同角度的查询分别检索后合并结果。实际项目里我一般先用基础的相似度检索跑通然后根据 bad case 逐步加策略。不要一上来就堆一堆高级技巧那样出了问题都不知道是哪个环节的锅。5.2 重排给检索结果做二次筛选检索出来的 top-k 个块相关性其实参差不齐。重排Rerank就是用一个小模型对这 k 个块重新打分排序把最相关的排到前面。常用的重排模型有bge-reranker系列效果提升明显。重排的价值在于向量检索是“粗筛”重排是“精排”。粗筛追求召回率宁可多找一些精排追求准确率把真正相关的挑出来。两步走的效果通常比一步到位好很多。代价是增加了一次模型推理延迟会上升。如果对响应速度要求高可以只在 top-k 比较大的时候才启用重排。5.3 提示词模板怎么把检索结果喂给模型检索到内容之后怎么组织提示词也很关键。一个常见的模板是这样的prompt_template 基于以下参考资料回答问题。如果资料中没有相关信息请明确说明不知道不要编造。 参考资料 {context} 问题{question} 回答这里有几个要点。第一明确告诉模型基于资料回答否则它可能忽略资料自己发挥。第二要求模型在资料不足时承认不知道这能有效降低幻觉。第三context 的拼接顺序也有讲究最相关的放前面还是放后面不同模型表现不一样可以实测调整。如果检索结果多还要注意别超过模型的上下文窗口。一般 RAG 场景下检索内容控制在 2000 到 4000 token 比较合适留足空间给问题和回答。6. 常见问题与排查实录6.1 检索不准的排查思路检索不准是最常见的问题排查要按链路一步步来。先看入库环节文档加载有没有丢内容切分有没有把关键信息切断嵌入模型有没有用错再看检索环节top-k 设得合不合理相似度阈值有没有设query 需不需要改写我遇到过一个典型案例用户问“怎么重置密码”检索出来的全是“密码强度要求”相关的内容。排查发现是切分的时候把“重置密码”的操作步骤和“密码强度”的说明切到了相邻的块里而向量检索对“重置”这个动作词不敏感。解决办法是在切分时按标题层级切保证操作步骤的完整性同时引入关键词检索做补充。6.2 模型答非所问怎么办模型答非所问通常是两个原因要么检索结果不相关要么提示词没约束好。先确认检索出来的内容是不是真的相关如果检索就不对那问题在检索环节。如果检索对了但模型还是乱答那就是提示词的问题。一个有效的技巧是在提示词里加 few-shot 示例给模型展示一两个“基于资料回答”的正确姿势。另一个技巧是要求模型先复述资料再回答这样能强制它关注检索内容。6.3 性能优化的几个方向RAG 链路的延迟主要来自三块嵌入计算、向量检索、LLM 生成。嵌入可以批量处理入库时一次性算好检索用 HNSW 索引百万级向量毫秒级返回LLM 生成是主要瓶颈可以通过流式输出改善体验或者用小模型做初筛。缓存也是个好办法。相同或相似的 query 直接返回缓存结果能省掉大量重复计算。ChromaDB 本身不提供缓存可以在应用层用 Redis 做一层。问题现象可能原因排查方向检索结果不相关切分不当/嵌入模型不匹配检查 chunk 内容和模型一致性模型编造答案提示词约束不足加强“基于资料回答”的指令响应慢LLM 生成瓶颈流式输出/缓存/小模型初筛漏掉关键信息top-k 太小/切分切断增大 k 值/调整 overlap重复内容多文档本身重复入库前去重7. 从 Demo 到生产几个必须想清楚的问题7.1 知识库更新策略知识库不是建好就完事了它需要持续更新。更新策略有两种全量重建和增量更新。全量重建简单粗暴每次把新文档全部重新入库适合文档量不大或者更新不频繁的场景。增量更新只处理新增和修改的文档效率高但实现复杂需要维护文档的版本和状态。我的建议是早期用全量重建简单可靠文档量上来之后再考虑增量。全量重建的时候注意保留一份原始文档方便回溯。7.2 评估 RAG 效果的方法RAG 效果怎么评估不能只靠感觉。至少要准备一批测试问题人工标注标准答案然后看系统回答的准确率、召回率。更细一点可以分开评估检索环节和生成环节检索环节看 top-k 里有没有包含正确答案所在的块生成环节看模型有没有正确利用检索内容。LangChain 提供了一些评估工具但我觉得最实用的还是自己攒一个测试集每次改动后跑一遍看指标有没有退化。这个测试集不用很大几十条高质量的问题就够用了。7.3 安全与权限别让知识库变成泄密通道企业知识库往往涉及权限问题。不是所有人都能看所有文档检索的时候必须做权限过滤。ChromaDB 的 metadata 过滤可以支持这个需求给每个块打上权限标签检索时按用户权限过滤。另一个安全点是提示词注入。用户可能在问题里塞入恶意指令试图让模型忽略系统提示。防御方法是在提示词里明确分隔用户输入和系统指令并且对用户输入做一定的清洗。8. 我踩过的几个坑和一点心得第一个坑是嵌入模型切换没重新入库。前面提过这里再强调一次切换嵌入模型后必须把所有文档重新向量化否则检索结果完全不可用。这个错误很隐蔽因为系统不会报错只是检索质量突然变差。第二个坑是chunk_overlap 设成 0。当时觉得重叠是浪费存储结果发现很多关键信息正好被切在边界上检索时两边都差一点。后来把 overlap 设成 chunk_size 的 15% 左右效果明显改善。第三个坑是忽略元数据过滤。早期所有文档混在一起检索用户问 A 产品的问题检索出来 B 产品的资料。后来给每个块加上产品标签检索时按标签过滤准确率提升了一大截。最后一个心得是RAG 不是银弹它解决的是知识时效性和私有化的问题但解决不了推理能力的问题。如果问题本身需要复杂推理检索再多资料也没用那得靠模型本身的能力或者 agent 框架来补。把 RAG 用在合适的地方它才能发挥最大价值。