1. RAG为什么突然火先把问题说清楚1.1 大模型的窘境能聊天却答不了你家的文档检索增强生成RAG这个词最近几乎每个做大模型应用的人都在聊。但我发现很多人把它当成一个高级概念一上来就谈向量库、谈重排序反而忽略了它到底在解决什么。我先讲一个非常常见的场景。你训练或者调用一个大语言模型问它公司的加班调休流程是什么它能给你写出一段通顺的答案。但你拿公司真实制度文档去核对会发现它编造了一个不存在的线上申请-审批-备案流程。原因很简单大模型的知识来自它训练时见过的公开语料它根本没见过你们公司的内部文档。这不是模型笨而是它的知识边界摆在那里——训练数据有截止日期公开语料没有你的私有信息而且模型在不确定的时候倾向于自圆其说这就是所谓的幻觉。RAG的核心思路就是把这个记忆问题从模型内部挪到模型外部。它不再试图让大模型记住所有知识而是先问一个问题答案可能出现在哪份文档里找到对应的段落再把它喂给大模型让它基于这些材料作答。相当于给大模型开卷考试而不是逼它闭卷死记硬背。1.2 RAG的核心思想很简单先检索再生成我见过一些新手把RAG理解成给大模型接一个数据库这个理解方向对但不全对。RAG不只是把文档塞进系统它是一套完整的检索-增强-生成流水线。拆开看就是三个动作第一把你的私有文档切分成小块每一块转成向量存入向量数据库第二用户提问时把问题也转成向量去数据库里找语义上最接近的若干段落第三把找到的段落和用户问题拼在一起交给大模型让它根据这些段落生成答案。这套流程的价值有几个层面。首先是知识实时更新你不需要重新训练模型换文档内容就换知识其次是可追溯大模型引用了哪一段你可以明确展示给用户看最后是可控制你可以通过调整检索范围让模型只聊你允许它聊的内容。实际落地时我强烈建议你把RAG理解为带检索功能的工程系统而不是某个单一工具。1.3 RAG与微调不是二选一一张对照表说清楚很多人在选RAG还是微调时纠结很久。其实这两条路线解决的是不同层面的问题。微调是改变模型的行为方式和表达能力RAG是改变模型的信息来源。我列一个对比表你一眼就能看出差别维度检索增强生成RAG微调知识来源外部文档按需检索模型内部的权重参数更新成本换文档、重新索引即可分钟级重新训练要数据、要算力小时到天级幻觉控制相对好因为限制了材料范围仍然可能出现模型会对没见过的问题编造可解释性高可展示检索到的证据片段低黑盒回答无法定位出处适合场景私有知识问答、资料库检索、实时信息改变语气风格、精通特定领域的表达习惯、提高特定任务能力实践中最靠谱的做法是先用RAG跑通业务如果发现某个细分场景的表达能力确实不够——比如模型不懂你所在领域的专业术语写法——再考虑对模型做轻量级微调两者可以叠加使用不是互斥关系。2. 从文档到答案RAG的完整工作链路拆解2.1 索引阶段预处理、切块、向量化与入库RAG的第一步是建索引也就是把原始文档变成可以被检索的形式。这一步做得不好后面检索结果必然崩塌。我通常会拆成四个环节。首先是文档加载与解析。PDF、Word、Markdown、网页都需要分别处理。这里有一个非常隐蔽的坑很多PDF是扫描件里面根本没有文字层你需要先做OCR识别。否则你辛苦建立了索引检索的时候却什么都查不到因为段落内容是空白的。其次是文本切块。大模型有上下文长度限制而且塞入过多无关内容会稀释注意力所以文档必须切成合适大小的块。切块策略直接影响检索命中率我后面会专门展开讲这里先记住一个原则语义完整优先于长度整齐。第三是向量化。把每一块文本通过嵌入模型转换成向量比如得到几百上千维的数值数组。嵌入模型的质量决定了语义相近判断的准确度。大体上好的嵌入模型能理解奖金申请和绩效奖金发放流程是相关的内容差的模型可能只匹配到字面重复的句子。第四是写入向量数据库。向量数据库负责存储这些向量并在检索时按相似度快速返回结果。选型时重点关注检索速度、过滤能力、混合检索支持程度不要只盯着排行榜上的性能数字。2.2 检索阶段从用户问题到候选文档检索是整个RAG系统的命门。用户输入一个问题后系统要做的第一件事不是让大模型回答而是先做一次找材料的动作。具体流程是把用户问题用同一个嵌入模型向量化然后在向量数据库里计算它与所有文档向量的相似度通常是余弦相似度取出最相似的Top-K个段落。这个过程中有几个关键变量返回几个段落、相似度阈值是多少、需不需要对段落做元数据过滤。只做向量检索有一个常见盲区当用户问题里含有人名、编号、产品型号这类精确词汇时向量检索不一定比得上传统的关键词检索。所以现在主流做法是混合检索——把向量检索和关键词检索结合起来两路召回再做融合排序。你可以把向量检索理解为找意思相近的朋友关键词检索理解为找名字相同的熟人两者互补才最稳。2.3 重排序与生成把相关上下文组装给大模型召回出的段落里往往第一名和第五名的质量差距很大。直接用Top-5拼进提示词经常会把大模型的注意力带到沟里去。我建议在检索和生成之间加一道重排序环节。重排序的原理是用一个小型但高精度的打分模型对召回段落逐条重新评分把真正有用的内容排在前面过滤掉实际上无关的段落。它比嵌入模型的匹配精度更高代价是多一次推理调用。在预算允许的情况下这一步对回答质量的提升非常明显尤其是知识库内容庞杂的时候。生成阶段的提示词组装也有讲究。我常用的模板逻辑是先给模型设定角色——你是一个客服助手只能依据以下资料回答问题然后列出检索到的资料每条带上来源编号最后是用户问题并强调如果资料中没有答案就回答不知道不要编造。不要小看这几句话它直接决定模型会不会老老实实做资料搬运工。3. 实操三十分钟搭建一个私有文档问答RAG3.1 需求定义与技术选型说一千道一万动手跑一遍比看十篇文章都管用。我当时接到的任务是做一个内部产品手册问答助手不需要大模型开源部署重点是快速验证流程。我选了最朴素的技术组合开源的文本嵌入模型做向量化本地向量数据库做存储和检索再调用通用的对话大模型接口做生成整个流程用Python串起来。有人会问为什么不自建大模型对于企业内部问答来说短时间内把模型质量和吞吐量调到可用水平成本和精力都不划算。先调用成熟接口把RAG的逻辑跑通将来要换本地模型只需要替换生成接口那一层就行。这也是RAG架构的优点模块之间耦合度很低。3.2 核心代码索引建库部分索引阶段的核心代码大致长这样from doc_loader import load_files # 读取各类文档 from text_splitter import split_chunks # 文本切块 from embed_model import EmbeddingModel # 嵌入模型封装 import vector_store # 向量数据库客户端 # 1. 加载文档 docs load_files(./product_manual/) # 2. 切块每块400字符重叠80字符 chunks [] for doc in docs: chunks.extend(split_chunks(doc.content, chunk_size400, overlap80)) # 3. 批量向量化 embedder EmbeddingModel(model_namechinese-embedding-model) vectors embedder.embed_documents(chunks) # 4. 写入向量数据库同时保存原始文本和元数据 for i, chunk in enumerate(chunks): vector_store.insert( vectorvectors[i], textchunk.text, metadata{source: chunk.source, page: chunk.page} )这里有几个细节新手容易忽略。切块时加重叠窗口是为了避免一个完整语义被一刀切在两块中间写入元数据是为了将来可以按文档来源过滤检索范围。向量化时批量处理比逐条循环快得多接口调用次数也能省一大截。3.3 核心代码检索与生成部分检索和生成放在同一个请求处理函数里流程如下def ask(question: str, top_k: int 5): # 1. 问题向量化 q_vector embedder.embed_documents([question])[0] # 2. 向量检索 hits vector_store.search(q_vector, top_ktop_k) # 3. 重排序可选用交叉编码器重新打分 reranked reranker.rerank(question, hits) # 4. 拼接提示词 context \n\n.join( f[{i1}] 来源{h.metadata[source]}\n{h.text} for i, h in enumerate(reranked) ) prompt f你是一个产品助手只能根据下面提供的资料回答用户问题。 资料 {context} 用户问题{question} 如果资料中没有相关信息请明确回答我没有找到相关资料不要编造。 # 5. 调用大模型生成 answer llm.chat(prompt) return answer, reranked我跑通这个流程的第一感受是RAG的系统结构确实不复杂真正复杂的在于里面的内容组织和参数调优。比如Top_K到底取3还是取5重排序模型该不该上上下文拼多长才不会淹没重点这些都是一步一步实验调出来的。3.4 第一轮实验结果与暴露的问题第一轮实验我测了20个问题总体能用但暴露了几个问题。第一当文档里有大量相似术语时向量检索召回的段落会重复雷同比如五条结果里三条讲的是同一个功能的不同截图描述第二对于用户口语化的提问比如这功能咋开启直接做向量检索的效果不如把它改写成功能开启步骤这种祈使句第三模型偶尔会忽略资料里明确的答案反而用自己的知识回答。这些问题让我意识到RAG就像一个毛坯房能住人但要住得舒服必须花大量时间打磨细节。接下来这部分我想把最有价值的细节经验一次性说清楚。4. 决定检索质量的六个细节比选模型更重要4.1 分块大小与重叠窗口的科学设置分块策略是RAG里争议最多、影响最直接的一环。块太小语义不完整模型看不到前因后果块太大噪音太多嵌入向量的语义被稀释检索精度反而下降同时生成的上下文也会被撑爆。我测试过几组参数256字符、512字符、1024字符重叠窗口分别是0、50、100。结果在技术问答场景下512字符加80字符重叠的效果最稳。这个数字不是通用的如果你的文档是合同条款一段可能只有几十个字那就适合按条切分如果是操作手册步骤之间强关联就适合稍大的块并带重叠。核心原则是让每个块尽量是一个独立可理解的语义单元。可以在切分时做一些结构化处理比如按Markdown标题分节按表格的行边界分割避免一个表格被拦腰切断。这个功夫花在索引阶段受益的是整个后续流程。4.2 嵌入模型怎么选型嵌入模型决定了语义匹配的上限。目前选择大体分三类闭源API模型、开源通用模型、面向中文或垂直领域微调过的模型。我的建议是不要只看评测榜单要拿你自己的真实文档和问题来测。选型优点代价适用情况闭源API嵌入质量稳定、维护省心按量付费、数据出域对数据安全要求不高的场景开源通用嵌入免费、可控中文语义理解可能不够细腻数据必须本地化部署垂直领域微调嵌入对专业术语匹配更好需要准备训练语料你的文档术语非常特殊换嵌入模型不是改一行配置那么简单因为不同模型的向量维度不同你需要重新对全部文档做索引。所以我一直建议项目初期就多测两个模型用同一批测试问题对比召回结果选好后再大规模建库不然后面返工的成本很高。4.3 top-k与相似度阈值召回多少合适Top-K熟练的设置是新手最容易忽略的。取太少可能漏掉正确答案取太多无关片段混进来大模型容易被带偏。我做过一次实验同一个问题在Top-3、Top-5、Top-10下的回答质量Top-5明显好于Top-3和Top-10。原因不难理解3条太容易漏相关内容10条则引入了大量干扰文本。除了数量相似度阈值也要设置。向量检索本质上会返回相对相似的结果哪怕所有文档都不相关它也会给你个第一名。如果设定一个最低分比如余弦相似度低于0.35的段落直接丢弃就能有效避免模型在毫无依据的情况下硬答。阈值需要根据你的嵌入模型和文档特点实测得出没有标准值。另外当召回结果为空或者全部低于阈值时最优策略不是硬着头皮生成而是让模型直接回答知识库中没有相关信息。很多时候诚实说不知道比一本正经地编答案更让用户信任。4.4 查询改写和HyDE让用户问题变得更可检索用户的提问方式和文档的表述方式经常不在一个频道上。比如用户问这玩意儿咋退款而文档里写的是退款申请流程及退费标准。直接用原问题去向量检索匹配效果一般。这时候就要做查询改写。最简单的改写方式是用大模型把口语化问题转成正式的、带动作对象的问题如何申请退款流程是什么进阶一点的做法是生成HyDE假设性文档嵌入也就是让大模型先根据问题写一个假设的理想答案再用这个答案的向量去检索。因为理想答案的用词风格更接近目标文档召回效果往往会好不少。我实测中查询改写对短查询、口语化查询的帮助最大。但注意不要过度改写每次改写都会增加一次模型调用延迟如果系统对响应时间要求很高可以只对特定类型的问题触发改写。4.5 提示词模板如何有效利用上下文很多人的RAG效果不好问题出在提示词上。他们把所有检索段落一股脑倒给模型然后说根据资料回答结果模型也不知道该优先信谁。经验是提示词里要明确三件事角色、规则、证据优先级。我习惯先说你是某文档问答助手只能依据提供的资料作答再说明当资料内部有冲突时优先采用来源更权威或时间更新的段落最后规定资料不包含答案时必须承认不知道。还有一个小技巧把每段资料加上编号并要求模型在回答中用编号标注信息出处。比如根据资料[2]退款周期为3-5个工作日。这样既方便用户核对又能显著降低模型的自由发挥程度因为它知道每个信息点都可以被追溯。4.6 评估闭环没有指标就没有优化RAG系统最怕感觉还不错因为感觉会骗人。我强烈建议从第一天就建立评估集准备30到100个真实问题标注期望答案和答案对应的资料段落每次修改系统后都跑一遍看召回准确率和回答完整性是变好还是变差。评估指标可以分两层。检索层看召回率正确答案是否出现在返回结果中和排序质量生成层看回答是否忠于资料、是否包含关键信息点。人工评估成本高可以用大模型间互评的方式做初筛但是最终结论一定要抽样人工复核。有了评估闭环你才能回答这次该分块策略到底好不好换嵌入模型值不值这类问题。否则你可能只是在靠运气调参。5. 从Demo走向生产那些踩过才懂的坑5.1 藏在扫描件里的文字PDF解析与OCR上线第一个版本时我遇到一个非常尴尬的故障用户上传了一份盖章扫描的PDF合同检索结果为空。检查索引库才发现这个PDF的每一页都是图片根本没有文本层。解析器返回的正文是空字符串索引阶段直接跳过了这些文件。这个问题在真实的企业文档里非常普遍。解决方案是引入OCR环节先识别图片中的文字再做切块和向量化。OCR模型选型上要关注中文识别准确率和表格结构还原能力。处理完OCR文本之后还有一个隐性收益很多图片版文档里包含历史文件字样OCR出来后你就能用元数据标注防止模型引用过期内容。5.2 表格和长文被切碎后检索结果惨不忍睹RAG系统对表格数据的处理是个经典大坑。一个包含多列的表格被通用切分器切成几块之后每块可能就剩下孤零零的一列数据模型根本看不懂上下文。我现在的处理方式是解析文档时检测表格结构把整张表格作为独立块保存同时在块内保留表头字段说明。如果表格太大就按逻辑行组切分并在每个子块中重复带上表头信息。这样模型既能看懂列的含义检索时也能返回完整的表格片段。长文档也是类似问题。一个60页的技术白皮书如果按固定长度切分成几十个块它们之间没有任何章节层级关系检索到的内容就是碎片里的碎片。更合理的做法是保留文档的标题层级把父级标题拼进每个块的文本里就像给每个碎片贴上归属标签检索和生成的质量会有明显提升。5.3 检索知识与大模型先验知识打架时怎么办生产中还有一个非常常见的现象文档里写的结论与大模型在训练中学到的通用常识不一致。比如你们公司的报销上限是5000元但大模型在公开语料里常见到的是很多企业报销上限为2000元。这时候模型可能无视文档直接给出2000元的答案。我的处理办法有三层。第一层在提示词中提高资料优先级写清楚当资料与常识冲突时一律以资料为准第二层对高风险问题强制要求模型在回答末尾附上引用段落编号没有引用就不能作答第三层在生成后加一道校验逻辑检测答案中的关键数字、日期是否在检索资料中出现过如果完全没出现过则标记为疑似幻觉。这套组合不能说100%消除幻觉但确实把一本正经说错话的概率压到了很低的水平。5.4 性能、成本与安全上线之前要做的功课最后说生产环境的现实问题。RAG上线之后每一项能力都有代价。嵌入模型调用要钱和时间重排序增加延迟大模型生成按token计费用户的每个问题都是多条链路叠加消耗。我建议做三层优化。第一层是缓存完全相同的问题直接复用历史答案相似问题可以用向量匹配命中缓存第二层是分级模型简单问题用小模型生成复杂问题才调用大模型第三层是对检索上下文做精简重排序后只取真正相关的前两三条而不是无脑塞入五条。安全方面同样不能马虎。至少要做两件事一是对上传文档做权限管理不同用户只能检索到他有权限看的资料二是给输出内容加敏感信息过滤防止模型把某些不该外传的内部信息泄露出去。这两条在金融、医疗、法律等场景里是硬要求前期不做后期整改起来非常痛苦。我自己从最初跑通Demo到现在最大的体会是RAG不是一个搭完就完事的功能而是一个需要持续调优的工程系统。文档会变提问方式会变模型会换评估集也在扩充。但核心方法论始终稳定——把知识放进可检索的文档里用可靠的流程控制模型的输出范围剩下的就是一个个细节较真。如果你现在正准备做一个知识问答类应用我的建议很直接先把一个最小RAG流程跑通再用真实文档去做几十个评估问题然后对着暴露出来的问题逐一优化。这个过程走完你再看任何RAG文章都能一眼分辨出哪些是干货哪些是空谈。