1. 先搞懂RAG到底在解决什么问题先从一个特别常见的场景说起。你买了个智能客服机器人老板扔过来一份两百页的产品手册让你把手册里的内容全部“装进”大模型里这样客户问什么它都能答。你直接把手册丢给模型模型说“内容超出我的处理上限”切成几十段分批喂模型倒是读进去了但问它“保修期到底是几年”它睁眼说瞎话给你编一个。这时候你就知道光靠大模型本身搞不定私有知识这件事。RAG全称是Retrieval-Augmented Generation中文叫检索增强生成。拆开看就是“先检索再生成”用户提问之后系统先去一个外部知识库里把相关的资料片段捞出来再把“问题资料片段”一起交给大模型让模型基于这些证据来回答。可以把它理解成开卷考试大模型不是闭卷硬背全世界的知识而是拿着你准备的参考资料现场翻书作答。这个“翻书”的过程就是知识增强。它解决的痛点非常明确。第一个是幻觉模型不懂装懂、一本正经地编造答案有了检索到的真实资料兜底模型只能照着资料说信口开河的概率大幅下降。第二个是知识过时大模型训练数据有截止日期你问它今年新发布的政策它不知道但知识库里的最新文档可以随时更新模型就能答上来了。第三个是私有知识无法融入公司内部的技术方案、实验记录、项目文档这些保密内容不可能拿去训练大模型但通过RAG挂在外面成本极低效果还立竿见影。如果你是个刚接触大模型的小白程序员我的建议是别一上来就微调模型先学RAG。微调相当于你重新训练一个“专科生”要和预训练数据、显卡、调参搏斗很久RAG只是搭一套检索管线数据准备清楚了半天就能跑通一个可用版本。这也是为什么我说这是“小白程序员必备的秘籍”——门槛低、见效快而且几乎所有业务场景都能直接套用。2. RAG的整体架构到底长什么样2.1 一个完整RAG系统的五段式流程只要把RAG拆成五个环节你就会发现它一点都不神秘。第一步是文档加载。把PDF、Word、Markdown、网页、数据库里的数据全部读出来变成纯文本。第二步是文本切分。长文档不能整块处理要按照某种规则切成一个个chunk也就是文本块几百字一块比较常见。第三步是向量化。每一块文本通过嵌入模型Embedding Model转成一串浮点数向量语义相近的文本向量之间的距离也近。第四步是存入向量数据库。所有向量连同原始文本一起存进去建立索引等查询时能快速找到邻居。第五步是查询阶段把用户问题也转成向量在数据库里做相似度检索取回top-k个最相关的文本块然后把这些文本块塞进提示词里交给大模型生成最终答案。这五个环节每一步都有讲究。很多人跑出来的RAG效果烂不是大模型选得不好而是前面某一步偷懒了——最常见的就是切分随便切、检索不调参。后面我会逐个环节展开讲。2.2 为什么需要向量化相似度检索到底在算什么你可能会问直接拿关键词搜不行吗比如用户问“保修期多久”我在文档里搜“保修期”三个字不也能搜到吗日常关键词搜索当然有用但它有两个缺陷。一是同义词问题文档里写的是“质保期限”你搜“保修期”字面匹配不到但这俩明明是一个意思。二是语义理解问题用户问“屏幕碎了能免费换吗”文档里说的是“人为损坏不在三包范围内”关键词几乎没有重合但语义上是相关的。向量化方案就是为了解决这类语义匹配问题。嵌入模型会把文本映射到高维空间比如常见的768维、1024维。“保修期”和“质保期限”这两段文本向量在你没看到的高维空间里距离很近系统就能把它们关联起来。检索时用的距离算法最常见的是余弦相似度Cosine Similarity公式不复杂本质就是计算两个向量夹角的余弦值值越接近1说明方向越一致文本语义越相近。实际操作中向量数据库都会内置这个算法你不需要手写但理解这个原理能帮你判断为什么检索结果不对。2.3 离线索引与在线查询一套系统两个阶段RAG系统的工程结构上通常分成离线和在线两条链路。离线链路做“索引构建”把各种格式的文档清洗、切分、向量化、写入向量库。这个过程可以批量跑文档更新了就重跑一遍或者做增量更新。它不直接面对用户但对系统的上限起决定作用——索引质量差后面检索再快也白搭。在线链路做“查询生成”接收用户提问向量化问题检索相似文本拼装提示词调大模型生成回复。这个链路要求低延迟通常控制在几秒内。两条链路共用同一个向量库离线的写入质量和在线的检索策略共同决定最终回答质量。很多项目初期只关注在线链路的调用忽略了离线索引的质量管控。我的经验是把大概率的时间和精力花在离线数据上数据清洗、切分策略、向量模型选型这三件事做好了在线链路基本不会出大乱子。3. 动手搭建从零跑通一个最小可用的RAG系统3.1 技术选型与库安装我不打算直接贴某个商业产品的代码因为不同账号、不同环境差异太大。下面用一套当前社区主流的开源技术栈来模拟演示你换成自己熟悉的其他工具也没问题思路是通用的。我这里假设你选择了某开源向量检索库作为存储底座某嵌入模型作为文本向量化工具大模型部分使用某家云厂商的API接口或者本地方案均可。目录结构大概长这样rag_demo/ ├── data/ # 放原始文档 ├── indexer.py # 离线文档加载、切分、向量化、入库 ├── retriever.py # 在线检索 ├── generator.py # 在线构造提示词、调用LLM ├── config.py # 全局配置 └── requirements.txt安装依赖时核心的库包括文档解析库读PDF和Word用、向量库客户端、嵌入模型客户端、大模型API客户端。举个例子requirements大致是这样pypdf python-docx openai chromadb sentence-transformers不同版本之间偶尔有兼容性小坑建议直接用最新的稳定版本。装完以后先跑一句“import 某某库”确认没报错再继续。3.2 写一个最简单的索引构建脚本离线索引脚本的核心逻辑就是“读文档-切文本-算向量-存库”。先看文档加载的部分。PDF用pypdf逐页提取文本Word用python-docx遍历段落。这个环节最大的坑是“提取出来全是乱码或者空内容”——扫描版PDF本质是图片需要OCR我后面会专门讲。代码示意如下from pypdf import PdfReader def load_pdf(path): reader PdfReader(path) pages [] for page in reader.pages: text page.extract_text() if text and text.strip(): pages.append(text.strip()) return \n.join(pages)然后是文本切分。这里我建议先讲一种最简单、最稳妥的方式按固定长度切分带重叠。固定长度好理解比如每块500个字符带重叠是什么意思就是相邻两块之间保留一部分相同的字符比如重叠100个字符。为什么要重叠因为如果一刀切在句子中间会把一个完整的语义单元劈成两半比如“保修期”三个字被拆到两块里检索时哪块都匹配不全。重叠部分能缓解这种切断问题。def split_text(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks切完以后做向量化。用嵌入模型把每个chunk转成向量然后连同原文一起写入向量库。向量库会帮你自动建索引后面查询直接用。3.3 写一个最简单的查询脚本查询侧的逻辑更短就三步def answer(question): # 1. 问题向量化 query_vec embed(question) # 2. 在向量库里检索最相关的5个文本块 top_chunks vector_db.query(query_vec, top_k5) # 3. 拼提示词调大模型 prompt build_prompt(question, top_chunks) return llm_complete(prompt)这几乎是所有RAG小程序的最小骨架。你先别急着加花活把这个跑通让系统能针对你自己的一篇文档回答三五个问题再谈优化。我见过不少同学一上来就想要多轮对话、带历史记忆、带重排序结果基础链路都没走通排查问题的时候根本不知道是哪一环出的错。3.4 用提示词模板把检索结果交给模型检索到了文本块不能一股脑全丢给模型要像写工作简报一样把证据整理清楚。我常用的提示词模板是这样的请根据下面提供的资料内容回答问题。如果资料中没有相关信息请直接回答“资料中未找到相关信息”不要自行编造。 资料内容 资料1 ... /资料1 资料2 ... /资料2 用户问题{question} 请给出简洁、准确的回答。注意几个细节一是明确告诉模型“没有就直说没有”这是抑制幻觉的关键一句二是用XML风格的标签把资料区隔开模型能更清楚区分“哪些是引用资料哪些是问题”三是要求简洁回答避免模型发挥太多。提示提示词里最好还加上“优先参考资料中与问题最相关的内容”这类引导。多轮调试下来你会发现提示词的约束力比你想的大得多。4. 调优实践切分、向量库和检索参数的组合拳4.1 切分策略固定长度只是个起点固定长度切分简单但效果粗糙。因为它完全不考虑文本结构可能把一个段落、一个列表项拦腰截断。更进一步的做法是按照文档结构切分Markdown按标题分块代码文档按函数或类分块表格按行保留完整性。逻辑很简单文档作者本来就划分好了“语义单元”你只要顺着这个结构走切出来的块质量通常不错。我在实际项目里试过几种切分方式纯固定长度、按段落切、按标题层级切、语义切分用嵌入模型判断断点。结论是“按标题段落混合切分”性价比最高既能保持结构完整又不需要额外引入复杂的语义分割模型。语义切分效果更细腻但计算成本高适合文档类型特别杂、结构混乱的场景。还有个重要参数是chunk大小。块太小比如100字信息量不足检索回来拼在一起上下文零碎块太大比如2000字检索命中后内容太泛还会撑爆模型上下文窗口。我常用500到800字任务偏问答就取小一点任务偏摘要或分析就取大一点。这里面没有绝对真理建议你拿自己的文档跑一组对照测试。4.2 向量数据库选型对比市面上的向量数据库不少新手容易选花眼。我的建议是分阶段原型验证阶段用轻量级嵌入式向量库一个文件搞定不需要单独部署服务适合本地调试。小规模生产阶段换用独立的开源向量数据库支持多用户、数据持久化和简单的过滤规则。大规模并发阶段再考虑分布式向量数据库或者直接在云端托管。表格对比一下不同阶段的选择逻辑场景推荐方案优势注意点本地Demo、几十MB文档本地嵌入向量库零部署、快速迭代不适合高并发公司内部小工具、百GB级独立开源向量库支持过滤、持久化需要维护服务大规模线上业务分布式向量库/托管服务高可用、弹性扩容成本高、运维复杂选型的核心判断标准是你的数据量级、并发规模、团队运维能力。别一上来就追求最重的方案。4.3 检索参数top-k和相似度阈值怎么定检索这一步最需要调的参数就两个召回数量top-k以及相似度阈值。top-k决定每次取多少个文本块送给大模型。k太小比如2可能漏掉关键信息k太大比如20模型要读太多垃圾内容既浪费tokens又容易答偏。我一般的起点是4到6然后再根据效果微调。相似度阈值是过滤线低于这个分数说明文本块和问题语义上压根不搭宁可不要。这个阈值和你的嵌入模型强相关不同模型产出的分数分布差很多。我之前用某通用嵌入模型时相关内容的相似度普遍在0.35到0.75之间阈值设个0.3就能挡掉大量无关块但换了一个模型后0.3以下的全是噪声。所以别照搬网上的阈值一定要自己抽样一批查询结果看看相关和不相关内容的分数分布再定阈值。4.4 嵌入模型直接决定检索质量的上限嵌入模型是整个RAG系统里最容易被忽视、但影响最大的组件。切分和参数调得再好嵌入模型语义理解能力弱检索结果照样稀烂。选嵌入模型有几个原则中文场景优先看中文语料表现好的模型领域术语多例如法律、医疗、代码最好拿领域样本做个小测试向量维度选多少要兼顾检索效果和存储成本。同一个领域内不同嵌入模型的差异比大模型品牌的差异对RAG效果的影响大得多。实操技巧选嵌入模型时构造十个有代表性的业务问题每个问题人工标注“应该在文档的哪个位置找答案”然后分别用候选模型做检索统计命中率。这比看榜单上那些通用分数实在得多。5. 常见问题与排查技巧实录5.1 检索出来一堆不相关的内容怎么办这是最普遍的问题现象是向量库明明有相关内容但检索认为不相关的块更相似。排查顺序是这样的第一步查数据切分。看是不是chunk太大或太碎导致语义混杂。第二步查嵌入模型。拿几个典型问题手动跑一遍相似度分数看相关文档是不是分数显著更高。第三步查查询预处理。有些问题带着大量连接词、语气词会稀释核心语义可以先做个简单的清洗或者用“重写查询”的方式把冗长的提问压缩成关键词组合。我遇到过一种特别隐蔽的情况文档里有大量重复段落比如同一份说明在多个章节反复出现检索结果被重复内容霸屏真正细分的知识点反而排不上号。这时候可以在索引构建时做一次去重或者检索后做一个结果多样性过滤避免top-k里全是同一个来源。5.2 模型总是答非所问问题可能出在提示词检索没问题相关文本也找回来了但模型回答出来完全跑偏这种情况九成是提示词构造的问题。检查点一资料是不是拼接得太乱。多段资料之间没有分隔模型分不清边界容易串味。检查点二有没有给足指令约束。如果提示词里没写“严格基于资料回答”模型就会自由发挥。检查点三资料太长。模型在长上下文里“迷失在中间”很可能只注意了开头或结尾的内容。应对办法是把最相关的资料排在最前面并且把“请优先参考靠前的资料”写进提示词。5.3 上下文窗口溢出怎么处理大模型有上下文长度限制你检索了5个文本块每块1000字再加上历史对话和多轮信息一不小心就超了。处理办法有三层。第一层减小chunk size。第二层调低top-k。第三层做内容压缩把文本块里明显无关的段落删掉只保留和查询语义最接近的句子。我给一个项目做过“上下文预算”机制先算好模型上下文的合理占用再反推允许放进多少文本块优先级低的直接裁掉。这个思路比盲目调参数可靠得多。5.4 两个高频场景的额外提醒PDF加载乱码这基本是扫描件。解决方式是接入OCR模块先识别图像文字再进入文本切分。建议不要整页整页OCR先做版面分析把标题、正文、表格分开处理效果会好很多。重复词、错别字太多文档本身质量差会影响嵌入模型的向量表达。先做一轮清洗统一全角半角、去重空行、纠正明显错字、保留Markdown标题标记再走索引流程。5.5 效果评估别凭感觉说“还行”最后也是最重要的一点要给RAG系统准备一组评测集。评测集就是几十条“问题-标准答案-来源段落”的元组。每次改动切分参数、换嵌入模型、调提示词后都跑一遍评测集记录两个指标检索环节的召回率正确答案对应的段落有没有被检索回来以及生成环节的准确率大模型基于检索结果有没有答对。你说“感觉系统变聪明了”不如去看这两个数字的变化。RAG的优化是工程活不是玄学用评测数据说话才能避免反复改、反复拆东墙补西墙。6. 进阶扩展让RAG贴近真实业务场景6.1 多轮对话中的上下文处理基础版RAG是单轮问答用户问一句答一句。但实际业务里用户会连续追问“那维修流程呢”这种指代性问题单轮检索根本处理不了。解决思路是把对话历史变成“重写后的独立查询”把“那维修流程呢”结合前文“保修期多久”重写成“保修期内的维修流程是什么”再用重写后的问题去做检索。这一步既简单又有效是优先级最高的进阶功能。6.2 混合检索关键词加向量一起上向量检索擅长语义匹配但在精确匹配、编号查询上反而不如传统关键词。比如用户直接报了一个产品型号“A3000”向量检索可能匹配到一堆含义相近但型号不同的内容。混合检索就是把关键词检索和向量检索的结果做融合再统一排序。具体做法可以简单粗暴两种方案各取若干结果按分数加权汇总。这个融合逻辑不需要一开始做得多复杂先设置权重跑通再逐步优化排序算法。对很多业务系统来说加上混合检索后的准确率提升是肉眼可见的。6.3 引用溯源让用户看到依据RAG有一个天然优势是微调模型很难给的引用溯源。回答里带上“根据公司内部文档第3章第2节”用户一眼看出答案有据可查信任感完全不一样。实现起来也不难检索时把每个文本块的来源路径、页码、标题一并存进向量库生成回答时把引用的文本块编号记录下来最后把来源信息附在答案末尾。这部分代码量不大但业务价值极高特别是客服、法务、医疗这类对依据要求高的场景。6.4 知识库更新别让旧数据拖累新答案资料会变知识库就必须维护增量更新。最简单的办法是全量重建数据量小的时候完全够用但数据多了效率太低。建议做双阶段更新高频更新的小知识库用“增量删除重写”模式定期重建的大知识库用“定时全量刷新”模式。两套并行既不漏数据也不给系统带来多余负担。我在把RAG接到正式业务后感受最深的一点是RAG不是一次性搭完就结束的系统。它像一套需要持续调优的检索方案数据在变、用户提问方式在变你需要常回来看评测指标定期重跑评测集。这活儿听着琐碎但你看着那个“幻觉率”一点点降下来、“准确率”稳步往上走就知道前面所有麻烦都值了。如果你也是刚接触大模型这个方向别犹豫拿手边一份真实文档开始把这段最小流程跑通你就已经跑赢大多数只看了概念没动过手的人了。 
长河君 · 2026/10/18 6:21:06 · 阅读 1.2k 小白程序员必备的RAG实战秘籍：从零搭建检索增强生成系统
1. 先搞懂RAG到底在解决什么问题先从一个特别常见的场景说起。你买了个智能客服机器人老板扔过来一份两百页的产品手册让你把手册里的内容全部“装进”大模型里这样客户问什么它都能答。你直接把手册丢给模型模型说“内容超出我的处理上限”切成几十段分批喂模型倒是读进去了但问它“保修期到底是几年”它睁眼说瞎话给你编一个。这时候你就知道光靠大模型本身搞不定私有知识这件事。RAG全称是Retrieval-Augmented Generation中文叫检索增强生成。拆开看就是“先检索再生成”用户提问之后系统先去一个外部知识库里把相关的资料片段捞出来再把“问题资料片段”一起交给大模型让模型基于这些证据来回答。可以把它理解成开卷考试大模型不是闭卷硬背全世界的知识而是拿着你准备的参考资料现场翻书作答。这个“翻书”的过程就是知识增强。它解决的痛点非常明确。第一个是幻觉模型不懂装懂、一本正经地编造答案有了检索到的真实资料兜底模型只能照着资料说信口开河的概率大幅下降。第二个是知识过时大模型训练数据有截止日期你问它今年新发布的政策它不知道但知识库里的最新文档可以随时更新模型就能答上来了。第三个是私有知识无法融入公司内部的技术方案、实验记录、项目文档这些保密内容不可能拿去训练大模型但通过RAG挂在外面成本极低效果还立竿见影。如果你是个刚接触大模型的小白程序员我的建议是别一上来就微调模型先学RAG。微调相当于你重新训练一个“专科生”要和预训练数据、显卡、调参搏斗很久RAG只是搭一套检索管线数据准备清楚了半天就能跑通一个可用版本。这也是为什么我说这是“小白程序员必备的秘籍”——门槛低、见效快而且几乎所有业务场景都能直接套用。2. RAG的整体架构到底长什么样2.1 一个完整RAG系统的五段式流程只要把RAG拆成五个环节你就会发现它一点都不神秘。第一步是文档加载。把PDF、Word、Markdown、网页、数据库里的数据全部读出来变成纯文本。第二步是文本切分。长文档不能整块处理要按照某种规则切成一个个chunk也就是文本块几百字一块比较常见。第三步是向量化。每一块文本通过嵌入模型Embedding Model转成一串浮点数向量语义相近的文本向量之间的距离也近。第四步是存入向量数据库。所有向量连同原始文本一起存进去建立索引等查询时能快速找到邻居。第五步是查询阶段把用户问题也转成向量在数据库里做相似度检索取回top-k个最相关的文本块然后把这些文本块塞进提示词里交给大模型生成最终答案。这五个环节每一步都有讲究。很多人跑出来的RAG效果烂不是大模型选得不好而是前面某一步偷懒了——最常见的就是切分随便切、检索不调参。后面我会逐个环节展开讲。2.2 为什么需要向量化相似度检索到底在算什么你可能会问直接拿关键词搜不行吗比如用户问“保修期多久”我在文档里搜“保修期”三个字不也能搜到吗日常关键词搜索当然有用但它有两个缺陷。一是同义词问题文档里写的是“质保期限”你搜“保修期”字面匹配不到但这俩明明是一个意思。二是语义理解问题用户问“屏幕碎了能免费换吗”文档里说的是“人为损坏不在三包范围内”关键词几乎没有重合但语义上是相关的。向量化方案就是为了解决这类语义匹配问题。嵌入模型会把文本映射到高维空间比如常见的768维、1024维。“保修期”和“质保期限”这两段文本向量在你没看到的高维空间里距离很近系统就能把它们关联起来。检索时用的距离算法最常见的是余弦相似度Cosine Similarity公式不复杂本质就是计算两个向量夹角的余弦值值越接近1说明方向越一致文本语义越相近。实际操作中向量数据库都会内置这个算法你不需要手写但理解这个原理能帮你判断为什么检索结果不对。2.3 离线索引与在线查询一套系统两个阶段RAG系统的工程结构上通常分成离线和在线两条链路。离线链路做“索引构建”把各种格式的文档清洗、切分、向量化、写入向量库。这个过程可以批量跑文档更新了就重跑一遍或者做增量更新。它不直接面对用户但对系统的上限起决定作用——索引质量差后面检索再快也白搭。在线链路做“查询生成”接收用户提问向量化问题检索相似文本拼装提示词调大模型生成回复。这个链路要求低延迟通常控制在几秒内。两条链路共用同一个向量库离线的写入质量和在线的检索策略共同决定最终回答质量。很多项目初期只关注在线链路的调用忽略了离线索引的质量管控。我的经验是把大概率的时间和精力花在离线数据上数据清洗、切分策略、向量模型选型这三件事做好了在线链路基本不会出大乱子。3. 动手搭建从零跑通一个最小可用的RAG系统3.1 技术选型与库安装我不打算直接贴某个商业产品的代码因为不同账号、不同环境差异太大。下面用一套当前社区主流的开源技术栈来模拟演示你换成自己熟悉的其他工具也没问题思路是通用的。我这里假设你选择了某开源向量检索库作为存储底座某嵌入模型作为文本向量化工具大模型部分使用某家云厂商的API接口或者本地方案均可。目录结构大概长这样rag_demo/ ├── data/ # 放原始文档 ├── indexer.py # 离线文档加载、切分、向量化、入库 ├── retriever.py # 在线检索 ├── generator.py # 在线构造提示词、调用LLM ├── config.py # 全局配置 └── requirements.txt安装依赖时核心的库包括文档解析库读PDF和Word用、向量库客户端、嵌入模型客户端、大模型API客户端。举个例子requirements大致是这样pypdf python-docx openai chromadb sentence-transformers不同版本之间偶尔有兼容性小坑建议直接用最新的稳定版本。装完以后先跑一句“import 某某库”确认没报错再继续。3.2 写一个最简单的索引构建脚本离线索引脚本的核心逻辑就是“读文档-切文本-算向量-存库”。先看文档加载的部分。PDF用pypdf逐页提取文本Word用python-docx遍历段落。这个环节最大的坑是“提取出来全是乱码或者空内容”——扫描版PDF本质是图片需要OCR我后面会专门讲。代码示意如下from pypdf import PdfReader def load_pdf(path): reader PdfReader(path) pages [] for page in reader.pages: text page.extract_text() if text and text.strip(): pages.append(text.strip()) return \n.join(pages)然后是文本切分。这里我建议先讲一种最简单、最稳妥的方式按固定长度切分带重叠。固定长度好理解比如每块500个字符带重叠是什么意思就是相邻两块之间保留一部分相同的字符比如重叠100个字符。为什么要重叠因为如果一刀切在句子中间会把一个完整的语义单元劈成两半比如“保修期”三个字被拆到两块里检索时哪块都匹配不全。重叠部分能缓解这种切断问题。def split_text(text, chunk_size500, overlap100): chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks切完以后做向量化。用嵌入模型把每个chunk转成向量然后连同原文一起写入向量库。向量库会帮你自动建索引后面查询直接用。3.3 写一个最简单的查询脚本查询侧的逻辑更短就三步def answer(question): # 1. 问题向量化 query_vec embed(question) # 2. 在向量库里检索最相关的5个文本块 top_chunks vector_db.query(query_vec, top_k5) # 3. 拼提示词调大模型 prompt build_prompt(question, top_chunks) return llm_complete(prompt)这几乎是所有RAG小程序的最小骨架。你先别急着加花活把这个跑通让系统能针对你自己的一篇文档回答三五个问题再谈优化。我见过不少同学一上来就想要多轮对话、带历史记忆、带重排序结果基础链路都没走通排查问题的时候根本不知道是哪一环出的错。3.4 用提示词模板把检索结果交给模型检索到了文本块不能一股脑全丢给模型要像写工作简报一样把证据整理清楚。我常用的提示词模板是这样的请根据下面提供的资料内容回答问题。如果资料中没有相关信息请直接回答“资料中未找到相关信息”不要自行编造。 资料内容 资料1 ... /资料1 资料2 ... /资料2 用户问题{question} 请给出简洁、准确的回答。注意几个细节一是明确告诉模型“没有就直说没有”这是抑制幻觉的关键一句二是用XML风格的标签把资料区隔开模型能更清楚区分“哪些是引用资料哪些是问题”三是要求简洁回答避免模型发挥太多。提示提示词里最好还加上“优先参考资料中与问题最相关的内容”这类引导。多轮调试下来你会发现提示词的约束力比你想的大得多。4. 调优实践切分、向量库和检索参数的组合拳4.1 切分策略固定长度只是个起点固定长度切分简单但效果粗糙。因为它完全不考虑文本结构可能把一个段落、一个列表项拦腰截断。更进一步的做法是按照文档结构切分Markdown按标题分块代码文档按函数或类分块表格按行保留完整性。逻辑很简单文档作者本来就划分好了“语义单元”你只要顺着这个结构走切出来的块质量通常不错。我在实际项目里试过几种切分方式纯固定长度、按段落切、按标题层级切、语义切分用嵌入模型判断断点。结论是“按标题段落混合切分”性价比最高既能保持结构完整又不需要额外引入复杂的语义分割模型。语义切分效果更细腻但计算成本高适合文档类型特别杂、结构混乱的场景。还有个重要参数是chunk大小。块太小比如100字信息量不足检索回来拼在一起上下文零碎块太大比如2000字检索命中后内容太泛还会撑爆模型上下文窗口。我常用500到800字任务偏问答就取小一点任务偏摘要或分析就取大一点。这里面没有绝对真理建议你拿自己的文档跑一组对照测试。4.2 向量数据库选型对比市面上的向量数据库不少新手容易选花眼。我的建议是分阶段原型验证阶段用轻量级嵌入式向量库一个文件搞定不需要单独部署服务适合本地调试。小规模生产阶段换用独立的开源向量数据库支持多用户、数据持久化和简单的过滤规则。大规模并发阶段再考虑分布式向量数据库或者直接在云端托管。表格对比一下不同阶段的选择逻辑场景推荐方案优势注意点本地Demo、几十MB文档本地嵌入向量库零部署、快速迭代不适合高并发公司内部小工具、百GB级独立开源向量库支持过滤、持久化需要维护服务大规模线上业务分布式向量库/托管服务高可用、弹性扩容成本高、运维复杂选型的核心判断标准是你的数据量级、并发规模、团队运维能力。别一上来就追求最重的方案。4.3 检索参数top-k和相似度阈值怎么定检索这一步最需要调的参数就两个召回数量top-k以及相似度阈值。top-k决定每次取多少个文本块送给大模型。k太小比如2可能漏掉关键信息k太大比如20模型要读太多垃圾内容既浪费tokens又容易答偏。我一般的起点是4到6然后再根据效果微调。相似度阈值是过滤线低于这个分数说明文本块和问题语义上压根不搭宁可不要。这个阈值和你的嵌入模型强相关不同模型产出的分数分布差很多。我之前用某通用嵌入模型时相关内容的相似度普遍在0.35到0.75之间阈值设个0.3就能挡掉大量无关块但换了一个模型后0.3以下的全是噪声。所以别照搬网上的阈值一定要自己抽样一批查询结果看看相关和不相关内容的分数分布再定阈值。4.4 嵌入模型直接决定检索质量的上限嵌入模型是整个RAG系统里最容易被忽视、但影响最大的组件。切分和参数调得再好嵌入模型语义理解能力弱检索结果照样稀烂。选嵌入模型有几个原则中文场景优先看中文语料表现好的模型领域术语多例如法律、医疗、代码最好拿领域样本做个小测试向量维度选多少要兼顾检索效果和存储成本。同一个领域内不同嵌入模型的差异比大模型品牌的差异对RAG效果的影响大得多。实操技巧选嵌入模型时构造十个有代表性的业务问题每个问题人工标注“应该在文档的哪个位置找答案”然后分别用候选模型做检索统计命中率。这比看榜单上那些通用分数实在得多。5. 常见问题与排查技巧实录5.1 检索出来一堆不相关的内容怎么办这是最普遍的问题现象是向量库明明有相关内容但检索认为不相关的块更相似。排查顺序是这样的第一步查数据切分。看是不是chunk太大或太碎导致语义混杂。第二步查嵌入模型。拿几个典型问题手动跑一遍相似度分数看相关文档是不是分数显著更高。第三步查查询预处理。有些问题带着大量连接词、语气词会稀释核心语义可以先做个简单的清洗或者用“重写查询”的方式把冗长的提问压缩成关键词组合。我遇到过一种特别隐蔽的情况文档里有大量重复段落比如同一份说明在多个章节反复出现检索结果被重复内容霸屏真正细分的知识点反而排不上号。这时候可以在索引构建时做一次去重或者检索后做一个结果多样性过滤避免top-k里全是同一个来源。5.2 模型总是答非所问问题可能出在提示词检索没问题相关文本也找回来了但模型回答出来完全跑偏这种情况九成是提示词构造的问题。检查点一资料是不是拼接得太乱。多段资料之间没有分隔模型分不清边界容易串味。检查点二有没有给足指令约束。如果提示词里没写“严格基于资料回答”模型就会自由发挥。检查点三资料太长。模型在长上下文里“迷失在中间”很可能只注意了开头或结尾的内容。应对办法是把最相关的资料排在最前面并且把“请优先参考靠前的资料”写进提示词。5.3 上下文窗口溢出怎么处理大模型有上下文长度限制你检索了5个文本块每块1000字再加上历史对话和多轮信息一不小心就超了。处理办法有三层。第一层减小chunk size。第二层调低top-k。第三层做内容压缩把文本块里明显无关的段落删掉只保留和查询语义最接近的句子。我给一个项目做过“上下文预算”机制先算好模型上下文的合理占用再反推允许放进多少文本块优先级低的直接裁掉。这个思路比盲目调参数可靠得多。5.4 两个高频场景的额外提醒PDF加载乱码这基本是扫描件。解决方式是接入OCR模块先识别图像文字再进入文本切分。建议不要整页整页OCR先做版面分析把标题、正文、表格分开处理效果会好很多。重复词、错别字太多文档本身质量差会影响嵌入模型的向量表达。先做一轮清洗统一全角半角、去重空行、纠正明显错字、保留Markdown标题标记再走索引流程。5.5 效果评估别凭感觉说“还行”最后也是最重要的一点要给RAG系统准备一组评测集。评测集就是几十条“问题-标准答案-来源段落”的元组。每次改动切分参数、换嵌入模型、调提示词后都跑一遍评测集记录两个指标检索环节的召回率正确答案对应的段落有没有被检索回来以及生成环节的准确率大模型基于检索结果有没有答对。你说“感觉系统变聪明了”不如去看这两个数字的变化。RAG的优化是工程活不是玄学用评测数据说话才能避免反复改、反复拆东墙补西墙。6. 进阶扩展让RAG贴近真实业务场景6.1 多轮对话中的上下文处理基础版RAG是单轮问答用户问一句答一句。但实际业务里用户会连续追问“那维修流程呢”这种指代性问题单轮检索根本处理不了。解决思路是把对话历史变成“重写后的独立查询”把“那维修流程呢”结合前文“保修期多久”重写成“保修期内的维修流程是什么”再用重写后的问题去做检索。这一步既简单又有效是优先级最高的进阶功能。6.2 混合检索关键词加向量一起上向量检索擅长语义匹配但在精确匹配、编号查询上反而不如传统关键词。比如用户直接报了一个产品型号“A3000”向量检索可能匹配到一堆含义相近但型号不同的内容。混合检索就是把关键词检索和向量检索的结果做融合再统一排序。具体做法可以简单粗暴两种方案各取若干结果按分数加权汇总。这个融合逻辑不需要一开始做得多复杂先设置权重跑通再逐步优化排序算法。对很多业务系统来说加上混合检索后的准确率提升是肉眼可见的。6.3 引用溯源让用户看到依据RAG有一个天然优势是微调模型很难给的引用溯源。回答里带上“根据公司内部文档第3章第2节”用户一眼看出答案有据可查信任感完全不一样。实现起来也不难检索时把每个文本块的来源路径、页码、标题一并存进向量库生成回答时把引用的文本块编号记录下来最后把来源信息附在答案末尾。这部分代码量不大但业务价值极高特别是客服、法务、医疗这类对依据要求高的场景。6.4 知识库更新别让旧数据拖累新答案资料会变知识库就必须维护增量更新。最简单的办法是全量重建数据量小的时候完全够用但数据多了效率太低。建议做双阶段更新高频更新的小知识库用“增量删除重写”模式定期重建的大知识库用“定时全量刷新”模式。两套并行既不漏数据也不给系统带来多余负担。我在把RAG接到正式业务后感受最深的一点是RAG不是一次性搭完就结束的系统。它像一套需要持续调优的检索方案数据在变、用户提问方式在变你需要常回来看评测指标定期重跑评测集。这活儿听着琐碎但你看着那个“幻觉率”一点点降下来、“准确率”稳步往上走就知道前面所有麻烦都值了。如果你也是刚接触大模型这个方向别犹豫拿手边一份真实文档开始把这段最小流程跑通你就已经跑赢大多数只看了概念没动过手的人了。