去年公司要做一个智能客服系统，用大模型+RAG（检索增强生成）技术，让AI能够基于公司的产品文档和知识库回答用户的问题。

领导把这个任务交给了我，我当时信心满满，觉得RAG不就是"检索+生成"嘛，把文档切吧切吧存到向量数据库里，用户提问的时候搜一下相关文档，然后丢给大模型生成回答，这有什么难的。网上那么多RAG教程，照着做就行了。

结果真正做起来才发现，RAG这东西，入门很容易，但做好非常难。我前前后后折腾了三个多月，踩了无数的坑，中间好几次想放弃，最后终于调整了思路，找到了适合我们业务场景的方案，系统才勉强上线。

这篇文章就来聊聊我做RAG项目的完整经历，从入门到差点放弃，再到最后找到方向的全过程，以及踩过的坑和一些反思。希望能给正在做RAG或者准备做RAG的朋友一些参考。

入门阶段：照着教程做，感觉很简单

最开始做RAG的时候，我照着网上的教程，很快就搭了一个原型。

流程很简单：第一步，把公司的产品文档（PDF、Word、Markdown等）读取出来，提取文本。第二步，把文本切分成chunk（块），每个chunk大概500到1000个token。第三步，用Embedding模型（最开始用的是text-embedding-ada-002）把每个chunk转换成向量，存到向量数据库里（最开始用的是Chroma，后来换成了Milvus）。第四步，用户提问的时候，把问题也转换成向量，在向量数据库里搜索最相似的几个chunk。第五步，把搜索到的chunk和用户的问题一起拼到Prompt里，发给大模型（最开始用的是GPT-3.5-turbo），让大模型基于这些文档生成回答。

整个流程搭下来，花了不到一周的时间，用一些测试问题测试了一下，效果居然还不错。比如问"产品A的价格是多少"，AI能准确地回答出价格；问"产品B有哪些功能"，AI能列出主要功能。当时我觉得RAG也不过如此嘛，这么简单就搞定了，看来很快就能上线了。

领导看了演示也很满意，说效果不错，让我尽快完善，争取一个月内上线。

我当时也是这么想的，觉得原型都跑通了，剩下的就是优化一下细节，处理一下边界情况，很快就能上线。但我万万没想到，原型跑通只是开始，真正的挑战还在后面。

第一个坑：文档切分的学问

第一个遇到的大坑是文档切分。

最开始我用的是最简单的固定长度切分，每个chunk 500个token，重叠50个token。这种方法简单粗暴，对于结构简单的文档（比如纯文本的FAQ）效果还可以，但对于结构复杂的文档（比如有标题、列表、表格、代码块的技术文档），效果就很差了。

我遇到的第一个问题是，固定长度切分经常把一个完整的语义单元切成两半。比如一个产品的功能介绍，正好在中间被切开了，前半部分在一个chunk里，后半部分在另一个chunk里。检索的时候，可能只搜到了前半部分，没有搜到后半部分，大模型拿到的信息不完整，回答就会出错或者不完整。

第二个问题是，表格和代码块的处理很麻烦。我们的技术文档里有很多表格（比如参数对比表、价格表）和代码块（比如API示例、配置示例）。固定长度切分经常把表格切成碎片，表格的表头在一个chunk里，数据行在另一个chunk里，检索到的时候根本看不懂。代码块也是一样，经常被切成碎片，大模型拿到不完整的代码，生成的回答就会出错。

第三个问题是，不同类型的文档应该用不同的切分策略。比如FAQ文档，每个问答对就是一个完整的语义单元，应该按问答对来切分，而不是按固定长度。比如产品手册，有清晰的章节结构，应该按章节和小节来切分。比如API文档，每个API就是一个完整的单元，应该按API来切分。一刀切的固定长度切分，对所有类型的文档都用同样的策略，效果肯定不好。

为了解决这些问题，我花了将近两周时间优化文档切分。主要做了以下几件事：

第一，按文档结构切分。先解析文档的结构（标题、章节、列表、表格、代码块等），然后按语义单元来切分，比如每个小节作为一个chunk，每个问答对作为一个chunk，每个API作为一个chunk。尽量保持语义单元的完整性，不要把一个完整的意思切开。

第二，智能处理表格和代码块。表格尽量保持完整，如果表格太大就按行切分，但一定要把表头带到每一个切分后的chunk里。代码块尽量保持完整，如果代码太长就按逻辑块切分，保持上下文的连贯性。把表格和代码块转换成更容易理解的格式（比如把表格转换成Markdown表格，把代码块加上语言标识），提高大模型的理解效果。

第三，根据文档类型选择不同的切分策略。FAQ文档按问答对切分，产品手册按章节切分，API文档按API切分，新闻和文章按段落和语义切分。为每种类型的文档设计专门的切分器，而不是一刀切。

第四，合理设置chunk大小和重叠。chunk不是越大越好，也不是越小越好。太大了会包含很多无关信息，影响检索精度；太小了上下文不完整，大模型理解不了。我最后把chunk大小控制在300到800个token之间，根据文档类型调整。重叠设置为chunk大小的10%到20%，确保边界处的语义不会丢失。

优化完文档切分之后，检索的准确率提升了不少，大模型回答的完整性和准确性也提高了。但这只是开始，后面还有更多的坑等着我。

第二个坑：Embedding模型的选择

第二个大坑是Embedding模型的选择。

最开始我用的是OpenAI的text-embedding-ada-002，这个模型效果不错，使用也方便，直接调API就行。但用了一段时间之后发现了几个问题。

第一个问题是成本。我们的文档量很大，有几十万篇文档，每篇切分成几个chunk，总共有几百万个chunk。用ada-002来Embedding，成本不低，而且每次新增文档都要重新Embedding，成本持续增加。更重要的是，用户提问的时候也要Embedding，虽然单次成本低，但量大了之后也是一笔不小的开销。

第二个问题是数据安全。我们的文档是公司的内部资料，包含产品信息、技术细节、客户数据等，把这些数据发给OpenAI的API，公司的安全合规部门有顾虑。虽然OpenAI说不会用API的数据训练模型，但安全合规部门还是觉得把内部数据发到外部服务不安全，要求尽量用本地部署的模型。

第三个问题是领域适应性。ada-002是通用的Embedding模型，在通用文本上效果不错，但在我们的专业领域（比如我们公司的产品术语、技术名词、行业黑话）上，效果就打折扣了。比如我们公司有一些自定义的产品名称和技术术语，通用模型可能理解不了，Embedding的效果就不好，检索的时候经常搜不到相关的文档。

为了解决这些问题，我开始调研和测试其他Embedding模型。当时测试了很多模型，包括开源的BGE系列、M3E、GTE、E5、 Instructor等，也测试了一些国内厂商的Embedding API。

测试的过程中又发现了很多问题。比如不同的Embedding模型效果差异很大，有的模型在通用文本上效果好，在专业领域效果差；有的模型在中文上效果好，在英文上效果差；有的模型检索速度快但精度低，有的精度高但速度慢。而且不同的模型对chunk大小的适应性也不一样，有的模型适合短文本，有的适合长文本。

最后我选择了BGE-large-zh作为主要的Embedding模型，本地部署，原因是：第一，它在中文上的效果很好，在很多中文检索基准上都名列前茅；第二，它是开源的，可以本地部署，数据安全有保障；第三，它支持长文本（最大512个token），适合我们的文档切分大小；第四，它的推理速度还可以，用GPU部署的话能满足我们的并发需求。

但用了BGE之后又发现了新问题：通用的BGE模型在我们的专业领域上效果还是不够好，很多专业术语和产品名称检索不准。于是我又做了领域微调，用我们公司的内部数据（问答对、文档对）对BGE模型做了微调。微调之后，检索准确率又提升了一大截。

但微调也不是一件容易的事情，需要准备高质量的训练数据，需要GPU资源，需要调参，需要评估效果。我又花了将近两周时间做数据准备和模型微调，才得到了一个效果不错的领域Embedding模型。

这个坑给我的教训是：Embedding是RAG的基础，Embedding的质量直接决定了检索的上限，进而决定了整个RAG系统的效果。不要小看Embedding模型的选择，一定要根据自己的业务场景、数据特点、安全要求，充分测试和对比，选择最适合的模型。如果通用模型效果不够好，一定要考虑领域微调，这往往能带来很大的提升。

第三个坑：检索准确率的瓶颈

第三个大坑是检索准确率的瓶颈。

文档切分和Embedding都优化完之后，我以为检索准确率应该差不多了，但实际测试的时候发现，还是有很多问题搜不到相关文档，或者搜到的文档不相关。

我分析了一下，主要有几个问题：

第一个问题是词汇不匹配。用户的提问方式和文档里的表述方式不一样。比如用户问"这个东西多少钱"，但文档里写的是"产品定价"或"价格体系"；用户问"怎么用"，文档里写的是"使用指南"或"操作手册"。虽然意思一样，但用词不一样，向量相似度就不够高，检索的时候就搜不到。

第二个问题是多义词和歧义。有些词在不同的语境下有不同的意思，比如"苹果"可以是水果，也可以是苹果公司的产品；"接口"可以是API接口，也可以是硬件接口。用户提问的时候，Embedding模型可能理解错了语境，检索到了不相关的文档。

第三个问题是长文档的检索。有些文档很长，虽然切分成了chunk，但检索的时候只能搜到几个相关的chunk，而这些chunk可能只是文档的一部分，缺少上下文。大模型拿到这些片段，可能理解不了完整的意思，回答就会出错。

第四个问题是多跳推理。有些问题需要综合多个文档的信息才能回答，比如"产品A和产品B在功能上有什么区别"，需要同时检索产品A和产品B的文档，然后对比才能回答。但向量检索是基于相似度的，可能只搜到了产品A的文档，没搜到产品B的，或者搜到的文档不相关，大模型就没法准确回答。

为了解决这些问题，我尝试了很多方法：

第一，混合检索。不再单纯用向量检索，而是把向量检索和关键词检索（BM25）结合起来。向量检索擅长语义匹配，关键词检索擅长精确匹配，两者结合可以取长补短。比如用户问"价格"，关键词检索能精确匹配到文档里的"价格"这个词，向量检索能匹配到"定价""费用"等相关的词。混合检索之后，召回率提升了不少。

第二，查询改写。用户提问之后，先用大模型对查询进行改写，扩展成多个相关的查询，然后用这些查询分别检索，最后合并结果。比如用户问"这个东西多少钱"，改写成"产品价格""定价方案""费用标准""多少钱"等多个查询，分别检索，这样能大大提高召回率。查询改写还可以消除歧义，比如把多义词改写成更明确的表述。

第三，重排序（Rerank）。向量检索召回top 20或top 50的候选文档，然后用一个更强大的重排序模型（比如BGE-Reranker、Cohere Rerank）对这些候选文档重新排序，选出最相关的top 5或top 10。重排序模型比Embedding模型更强大，因为它可以同时看查询和文档的完整内容，做更精细的相关性判断。加了重排序之后，检索的精确率提升了很多。

第四，父文档检索。切分的时候，把文档分成小的chunk用于检索，但返回给大模型的时候，返回这个chunk所属的更大的父文档（比如整个小节或整个章节），这样大模型能拿到更完整的上下文，理解更准确。这种方法叫"小chunk检索，大chunk返回"，很好地平衡了检索精度和上下文完整性。

第五，多查询和多跳检索。对于需要多跳推理的问题，用大模型把复杂问题分解成多个子问题，然后分别检索每个子问题的相关文档，最后综合所有文档生成回答。比如"产品A和产品B有什么区别"，分解成"产品A的功能是什么"和"产品B的功能是什么"两个子问题，分别检索，然后对比回答。

这些方法加在一起，检索准确率又提升了一大截，但也让整个系统变得复杂了很多。原来的简单流程变成了"查询改写→混合检索→重排序→父文档返回→多跳推理"的复杂流水线，每个环节都有很多参数要调，很多细节要处理。

这时候我才真正理解了为什么说RAG入门容易做好难。入门的时候你只需要一个简单的流程，但要做好，你需要处理无数的细节，优化无数的环节，系统会变得越来越复杂。

第四个坑：大模型的幻觉和Prompt工程

第四个大坑是大模型的幻觉和Prompt工程。

检索的问题解决得差不多之后，我以为剩下的就是大模型生成了，这应该最简单，把检索到的文档和问题丢给大模型就行了。但实际上，大模型生成这一环也有很多坑。

第一个问题是幻觉。虽然我们给大模型提供了检索到的文档，但大模型有时候还是会" hallucination"（幻觉），编造一些文档里没有的信息。比如文档里只写了产品A有三个功能，大模型可能会编造出第四个、第五个功能，说得有鼻子有眼的。或者文档里写的是价格1000元，大模型可能会说成1200元。这种幻觉在客服场景下是非常致命的，用户可能会因为AI的错误回答而做出错误的决策，然后找公司投诉。

为了减少幻觉，我尝试了很多方法：

第一，优化Prompt。在Prompt里明确告诉大模型，只能基于提供的文档回答，不能编造信息，如果文档里没有相关信息，就回答"根据现有资料无法回答"。还可以要求大模型在回答中标注信息来源（比如"根据文档X"），这样既可以减少幻觉，又可以让用户验证回答的准确性。

第二，控制生成参数。降低temperature（温度），让大模型的回答更确定、更保守，减少随机性。比如把temperature从0.7降到0.2或0.3，幻觉会明显减少。还可以设置frequencypenalty和presencepenalty，减少重复和无关内容。

第三，引用和溯源。让大模型在回答中引用检索到的文档片段，每个观点都要有文档支撑。生成回答之后，再做一次校验，检查回答中的每个事实是否都能在检索到的文档中找到，如果有找不到的，就标记为可能的幻觉，要求大模型修改或者删除。

第四，Self-RAG（自我检索增强）。让大模型在生成回答的过程中，自己判断是否需要检索更多的信息，如果觉得信息不够，就主动发起检索，然后基于新检索到的信息继续生成。这种方法能让大模型在生成过程中动态地补充信息，减少因为信息不足而产生的幻觉。

虽然用了这些方法，幻觉还是不能完全消除，只能尽量减少。在客服这种对准确性要求很高的场景下，幻觉是一个永远需要警惕的问题。

第二个问题是Prompt工程。Prompt的写法对大模型生成的质量影响非常大。同样的文档和问题，不同的Prompt，生成的回答质量可能天差地别。

我最开始的Prompt很简单，就是"请基于以下文档回答用户的问题：[文档] [问题]"。生成的回答质量一般，有时候答非所问，有时候格式混乱。后来我不断优化Prompt，加了很多内容：角色设定（你是一个专业的客服）、回答规则（只能基于文档、不能编造、要标注来源）、回答格式（分点回答、先给结论再给细节）、示例（few-shot，给几个好的回答示例）、异常处理（不知道就说不知道）等。

Prompt越来越长，越来越复杂，从最开始的几句话变成了几百字甚至上千字。而且Prompt不是一次就能写好的，需要不断地测试、调整、优化。有时候改一个词、加一句话，生成的质量就会有明显的变化。Prompt工程真的是一门艺术，需要耐心和经验。

而且大模型版本更新之后，原来的Prompt可能就不好用了，需要重新调整。比如从GPT-3.5升级到GPT-4，或者从一个模型换到另一个模型，Prompt都需要重新优化。这也是一个持续的工作。

第三个问题是长上下文的处理。有时候检索到的文档很多，拼到Prompt里之后，整个Prompt很长，可能会超过大模型的上下文窗口限制。这时候就需要做上下文压缩，把不那么相关的文档去掉，或者对文档做摘要，只保留最关键的信息。

上下文压缩也有很多方法，比如用重排序模型选出最相关的几个文档，用大模型对每个文档做摘要，提取关键信息，或者用更高级的上下文压缩算法。但压缩的时候要注意不要丢失关键信息，否则大模型回答的准确性会下降。

这些问题加在一起，让大模型生成这一环也变得非常复杂。原来以为最简单的环节，实际上也有很多细节要处理，很多参数要调。

第五个坑：评估体系的缺失

第五个大坑是评估体系的缺失。

做到一定程度之后，我发现一个很严重的问题：我不知道系统到底好不好，不知道每次优化有没有效果，不知道效果提升了多少。因为没有一个系统的评估体系，每次优化都是凭感觉，用几个测试问题测一测，觉得好像好了一点，但到底好多少，不知道。

比如我优化了文档切分，用10个测试问题测了测，觉得回答好像准确了一些，但这10个问题够不够？有没有代表性？是不是只是碰巧这几个问题变好了，其他问题反而变差了？不知道。

比如我换了Embedding模型，检索准确率提升了多少？是提升了召回率还是精确率？对不同类型的问题提升一样吗？不知道。

比如我优化了Prompt，幻觉减少了多少？回答的准确性提升了多少？用户满意度提升了多少？不知道。

没有评估体系，优化就是盲目的，可能花了很多时间做了一个"优化"，实际上效果反而变差了，只是你没有发现而已。

意识到这个问题之后，我开始搭建评估体系。主要做了以下几件事：

第一，构建测试数据集。收集了几百个真实的用户问题，每个问题都标注了标准答案和相关的文档（ground truth）。这些测试问题覆盖了不同的类型（事实型、推理型、比较型、开放型等）、不同的难度（简单、中等、困难）、不同的产品和业务场景。有了这个测试数据集，就可以定量地评估系统的效果。

第二，评估检索效果。用检索评估指标来衡量检索的质量，比如Recall@k（前k个结果中包含相关文档的比例）、Precision@k（前k个结果中相关文档的比例）、MRR（平均倒数排名）、NDCG（归一化折损累计增益）等。每次优化之后，在测试数据集上跑一遍，看看这些指标有没有提升，提升了多少。

第三，评估生成效果。用生成评估指标来衡量大模型生成回答的质量，比如准确率（回答是否正确）、完整性（回答是否完整）、相关性（回答是否和问题相关）、幻觉率（回答中编造信息的比例）、引用准确率（引用的文档是否真的支持回答中的观点）等。这些指标可以用人工评估，也可以用大模型作为裁判来自动评估（LLM-as-a-judge）。

第四，端到端评估。除了分环节评估，还要做端到端的评估，模拟真实用户的使用场景，看整个系统的回答质量和用户满意度。可以做A/B测试，让用户对比两个版本的回答，看哪个更好。也可以收集用户的反馈（点赞、点踩、评论），持续优化。

搭建评估体系花了我不少时间，但非常值得。有了评估体系之后，每次优化都能量化效果，知道哪些优化有效，哪些无效，哪些反而有副作用。优化的效率大大提高，也避免了盲目优化。

这个坑给我的教训是：做RAG项目，一定要尽早搭建评估体系，不要等系统做差不多了才想起来评估。评估是优化的基础，没有评估，优化就是盲目的。而且评估体系本身也需要持续优化，测试数据集要不断更新和扩充，评估指标要不断完善，才能真实反映系统的效果。

差点放弃：复杂度和成本的失控

做到这个时候，整个RAG系统已经变得非常复杂了。

原来的简单流程变成了一个复杂的流水线：文档解析→文档清洗→文档切分→Embedding→向量存储→查询改写→混合检索→重排序→父文档返回→上下文压缩→Prompt组装→大模型生成→回答校验→引用溯源。每个环节都有很多参数要调，很多细节要处理，很多异常情况要考虑。

系统的成本也很高。Embedding模型本地部署需要GPU，大模型调用需要API费用（如果用本地大模型也需要GPU），向量数据库需要服务器存储和计算，整个系统的运维成本也不低。而且随着文档量和用户量的增加，成本还在持续增长。

更让人沮丧的是，效果的提升越来越慢。最开始优化的时候，每次优化都能带来明显的提升，比如检索准确率从60%提升到70%。但到了后期，优化的边际效应递减，花了很多时间做了一个复杂的优化，可能只提升了1%或2%，甚至没有提升。

这时候我真的有点想放弃了，觉得RAG这东西太复杂了，投入产出比太低了。花了这么多时间和精力，效果还是不够好，用户还是经常投诉回答不准确。

但后来我冷静下来想了想，问题可能不是RAG本身不行，而是我的思路有问题。我一直在追求"完美的RAG"，想把所有环节都做到最好，想让AI能回答所有问题，但这实际上是不现实的。RAG不是银弹，它有它的适用场景和局限性，不能期望它解决所有问题。

想明白这一点之后，我开始调整思路，不再追求完美，而是根据我们的业务场景，做适合我们的RAG。

调整思路：找到适合的方案

调整思路之后，我做了以下几件事：

第一，明确RAG的定位和边界。RAG不是万能的，它适合回答那些有明确文档支撑的事实型问题，不适合回答需要复杂推理、主观判断、或者文档里没有信息的问题。我把客服问题分成了几类：事实型问题（价格、功能、参数等）用RAG回答；流程型问题（怎么操作、怎么办理等）用RAG+工作流回答；复杂问题和投诉转人工客服。不再强求RAG回答所有问题，而是让它做它擅长的事情，不擅长的交给其他方式。

第二，简化系统架构。不再追求每个环节都用最复杂、最先进的方案，而是根据实际效果选择性价比最高的方案。比如混合检索效果提升不大，就改回单纯的向量检索；查询改写增加了延迟但效果提升有限，就只对复杂问题做查询改写；多跳推理太复杂，就只对明确的比较型问题做多跳。系统简化之后，维护成本降低了，稳定性也提高了，效果并没有下降多少。

第三，聚焦核心问题优化。不再面面俱到地优化所有环节，而是聚焦对效果影响最大的核心问题。分析发现，我们的场景下，对效果影响最大的是文档质量和Embedding质量，而不是检索算法和Prompt技巧。于是我把主要精力放在了文档治理（清洗文档、统一格式、补充缺失信息）和Embedding领域微调上，这两块做好了，效果提升最明显。其他环节保持够用就行，不过度优化。

第四，人机协同。不再追求完全自动化，而是引入人机协同的机制。AI回答之后，如果置信度不高，就标记为"待人工审核"，由人工客服审核之后再发给用户。用户也可以对AI的回答点赞或点踩，点踩的回答会进入人工复核队列，持续优化。这样既利用了AI的效率，又保证了回答的准确性，用户满意度大大提高。

第五，持续迭代。RAG不是一次性做完就完事了，而是需要持续迭代和优化。文档在更新，用户的问题在变化，大模型在升级，RAG系统也需要持续优化。我建立了一个持续优化的机制：定期收集用户反馈，分析bad case，针对性地优化文档、检索、Prompt等，每个版本都有明确的评估指标，持续提升效果。

调整思路之后，系统的效果反而比之前追求"完美RAG"的时候更好了，成本和复杂度也降下来了。用户满意度提升了，投诉减少了，系统也稳定了。这时候我才真正理解了，RAG不是一个技术问题，而是一个系统工程，需要根据业务场景找到适合的方案，而不是盲目追求技术的先进性和完美性。

给做RAG的朋友的建议

最后给正在做RAG或者准备做RAG的朋友一些建议，这些都是我用三个多月的时间和无数的坑换来的经验。

第一，不要高估RAG，也不要低估RAG。RAG不是银弹，不能解决所有问题，不要期望它能完美回答所有问题。但RAG也不是一无是处，在合适的场景下，它能大大提升效率和用户体验。要客观认识RAG的能力和局限性，根据业务场景合理使用。

第二，先做简单的原型，再逐步优化。不要一开始就搞很复杂的架构，先做一个简单的原型，跑通流程，验证可行性，然后再根据实际效果逐步优化。很多时候简单的方案就能满足80%的需求，剩下的20%再花时间优化。不要过度设计，不要为了技术而技术。

第三，文档质量是基础。RAG的效果很大程度上取决于文档的质量。如果文档本身质量很差（信息缺失、格式混乱、过时错误），那再怎么优化检索和生成也没用。一定要重视文档治理，清洗文档、统一格式、补充信息、及时更新，这是RAG效果的基础。

第四，评估要尽早做。一定要尽早搭建评估体系，不要等系统做差不多了才想起来评估。有了评估体系，优化才有方向，才能知道每次优化有没有效果。评估体系本身也需要持续完善，测试数据集要不断更新和扩充。

第五，不要陷入技术细节的泥潭。RAG涉及的技术很多，Embedding、向量检索、重排序、Prompt工程、大模型微调等，每个方向都有很多细节。不要陷入某个技术细节的泥潭，要从系统整体出发，找到对效果影响最大的环节，重点优化。很多时候，一个简单的方案配合好的文档和评估，比一个复杂但调不好的方案效果更好。

第六，考虑成本和可维护性。RAG系统的成本不只是大模型API费用，还包括Embedding、向量数据库、服务器、运维等。在设计方案的时候就要考虑成本，选择性价比最高的方案。还要考虑可维护性，系统越复杂，维护成本越高，出问题的概率越大。在满足需求的前提下，尽量保持系统简单。

第七，人机协同是现实的选择。在目前的技术水平下，完全自动化的RAG很难做到100%准确，特别是在对准确性要求高的场景下。引入人机协同的机制，AI负责初筛和常规问题，人工负责审核和复杂问题，既能保证效率，又能保证准确性，是目前比较现实的选择。

第八，持续迭代。RAG不是一次性项目，而是需要持续迭代和优化的。文档在更新，用户在变化，技术在发展，RAG系统也需要持续优化。建立持续优化的机制，定期收集反馈，分析bad case，针对性优化，才能让系统越来越好。

这些建议希望能帮到大家，少走弯路，少踩坑。

写在最后

RAG检索增强从入门到放弃，我经历了很多。

从最开始的信心满满，觉得RAG很简单，到中间遇到无数的坑，文档切分、Embedding选择、检索准确率、大模型幻觉、评估体系缺失，每一个都是大坑，好几次想放弃。到最后调整思路，找到适合的方案，系统终于稳定上线，用户满意度也提升了。

这段经历让我对RAG有了更深刻的理解。RAG不是一个简单的技术，而是一个系统工程，涉及文档、检索、生成、评估、运维等多个环节，每个环节都有很多细节要处理。RAG也不是银弹，它有它的适用场景和局限性，需要根据业务场景找到适合的方案，而不是盲目追求技术的完美。

但RAG确实是一项很有价值的技术，在知识管理、智能客服、企业搜索等场景下，它能大大提升效率和用户体验。随着大模型技术的不断发展，RAG的效果也会越来越好，应用场景也会越来越广。

如果你正在做RAG或者准备做RAG，希望我的经历能给你一些参考。不要怕踩坑，每个坑都是成长的机会。也不要追求完美，找到适合自己业务场景的方案，持续迭代，就一定能做出有价值的RAG系统。

RAG的路还很长，我们都在路上。