1. 先把链路讲透本地 RAG 到底在做什么我经常被问到一个问题大模型不是什么都懂吗为什么问它“我们公司报销上限是多少”这种内部制度它要么答不上来要么一本正经地编一个答案答案很简单模型在训练的时候根本没见过你们公司的制度文档。要让模型能回答私有知识行业里最常见的是两条路一条是拿这些资料做微调价格高、周期长而且知识一更新就得重新训练另一条就是RAGRetrieval-Augmented Generation检索增强生成。后者让模型在回答之前先从你的文档库里“查一遍资料”再基于查到的内容组织答案。本地 RAG 问答系统的核心价值就是把“文档检索”和“大模型生成”这两件事都放在你自己的机器上跑。这样一来文档不外传网络可达性要求低不用付按 token 计费的钱还能随心所欲地换模型、调参数。适合的场景很明确个人知识库、企业内部制度问答、产品手册答疑、课程资料检索哪怕是几十万字的技术文档也能在一个中端配置的电脑上跑起来。这篇内容我要讲的不只是“怎么装一个能用的系统”而是把选型思路、搭建步骤、踩坑记录和优化手段串起来。适合正在评估自建知识问答方案的技术人员也适合想从零动手做一个本地问答服务、但对底层原理还不太清楚的爱好者。先说核心链路。RAG 可以拆成三个环节嵌入Embedding、检索Retrieval、生成Generation。嵌入层把文档切成一段段文本每一段通过嵌入模型变成一串数字向量。这个向量的作用是把“语义”映射到多维空间里的一个坐标附近。语义相近的句子向量之间的距离也近。检索层你把一个问题也转成向量然后在向量库里找最接近的 K 个文档片段也就是语义上的“最相关段落”。生成层把这 K 个片段连同原始问题一起塞给大模型让模型基于这些片段组织答案。模型此时不需要靠记忆硬编它只要做好“阅读理解”就行。用一个生活里的类比来理解把 RAG 想象成一个图书馆。嵌入和索引阶段是给每本书做详细索引卡片并按主题归类摆放用户提问时图书管理员先根据你的问题快速找到最相关的几本书检索然后让一位熟悉资料的助手大模型翻开这几本书照着内容给你讲答案。整个过程不依赖这位助手之前是否背过这些书它只需要会读、会总结。这也是 RAG 和“直接问模型”的本质区别。后者拼的是模型记忆里的训练数据前者拼的是你的文档库是否完整、检索是否准确。文档库越贴合你的业务回答质量就越可控。所以这个系统里文档处理质量和检索质量往往比模型本身的大小更影响实际效果。2. 选型之前先问自己三个问题文档量、硬件、质量预期很多人一上来就问“该选哪个模型”“该用哪个向量库”我一般会先反问三个问题这三个答案基本决定了整套技术选型的方向。2.1 问题一文档总量到底有多大这里说的“大”不是文件数量而是有效文本总量。比如 50 个 PDF每个 20 页加起来也就几十万字。这种规模嵌入式向量库完全顶得住——就是那种直接以文件形式存在磁盘上的轻量方案比如 SQLite 的向量扩展或者常说的 Chroma 方案不需要额外起服务。但如果文档到了百万字级别以上比如几个 GB 的语料或者团队里多人同时查询、要求毫秒级响应那就要认真考虑服务化向量库了。这类方案把数据加载进内存或建立独立索引支持并发查询但相应的部署和维护成本也更高。我的建议是第一批先按“几十万到百万字”设计用文件型向量库把系统跑通。等真实跑起来发现检索变慢了再迁移到服务端向量库。很多方案都提供一键导出导入能力迁移成本并不高。2.2 问题二机器是什么配置本地 RAG 对 CPU 和内存的要求通常比显卡更关键。因为嵌入模型普遍不大在 CPU 上就能跑真正吃资源的是生成模型。如果你的机器没有独立显卡内存又只有 16GB那就老老实实选量化版的小参数模型别想着上大模型。如果机器有主流独立显卡显存 8GB 以上选择余地就大很多可以上 7B 甚至 14B 级别的量化模型回答质量会有明显提升。而如果只是 CPU 跑也不是不能做但每轮回答可能要等几十秒适合非实时场景。2.3 问题三回答质量要求有多高内部自用、查个资料参考一下和面向客户提供在线问答容忍度是完全不同的。前者哪怕答案偶尔不准确也能接受后者就得额外做引用标注、兜底拒答、人工审核这些机制。质量预期直接影响你后续要在提示词、检索排序、评估迭代上投入多少精力。这三个问题想清楚之后再来看具体选型方向就不会乱。我用下面这个表概括常见的配置档位档位适用场景嵌入模型规格生成模型规格向量库形态预期效果轻量档个人笔记、少量文档参数量 1 亿以内向量维度 512 左右参数 3B~7B 量化版文件型嵌入式向量库回答可用速度较慢均衡档团队内部知识库参数量 3 亿左右向量维度 768 左右参数 7B~14B 量化版嵌入式向量库或轻量服务回答质量稳定速度可接受重载档大规模语料、在线服务参数量 3 亿以上向量维度 1024 左右参数 14B 以上甚至部署多卡分布式向量库集群检索准、回答好运维成本高必须提醒的是元数据里那些“效果不错”的错觉往往来自只看单条样例。真要判断档位够不够得拿自己的文档建评测集来测这个我放到后面专门讲。3. 嵌入模型和向量库的两点关键参数维度与距离度量嵌入模型的选择核心看三个东西参数量、支持语言的语料覆盖度、输出向量的维度。同档次的模型里中文场景优先选在中文语料上有专门训练的版本效果差距很明显。我实际测过同一个问题通用英文模型召回的段落经常差一截——不是不能用而是中文文档的语义相近程度打分偏低。输出向量维度要特别留意。维度越高表达语义的空间越大但每条文档向量占的存储和检索计算量也越大。512 维和 1024 维听起来只是“两倍”在大规模文档下索引体积和查询耗时会成倍往上走。个人知识库的量级用 512 维就够了到百万字以上再考虑更高的维度。距离度量方面最常见的做法是余弦相似度。它只关心向量方向、不关心绝对长度天然适合文本语义比较。很多向量库默认支持的就是余弦实际用下来也是中文场景里最稳的选项。至于内积、欧氏距离这些除非你有特殊调优需求否则并没有必要一开始就折腾。向量库的选型逻辑更直接。文件型嵌入式方案的好处是零运维程序里几行代码就能建库和查询适合单机和个人项目。但它不适合高并发查询也没法做到多机分布式。服务端向量库则有完整的增删改查接口支持过滤条件和并发访问代价是要多管一个服务进程、处理持久化和备份。我个人的习惯是文档数不超过十万个片段就用文件型超过这个量或者检索延迟要求非常高再上服务端。4. 搭建最小可用系统从文档清洗到问答闭环下面这部分我按一个完整的最小系统来讲你可以照着搭。假设环境是 Linux 或 macOSPython 3.10 以上机器有 16GB 内存。4.1 文档加载与清洗这一步最容易被跳过却最影响最终效果。PDF、Word、HTML、Markdown 各有各的坑。PDF 尤其麻烦如果是文字版 PDF用解析库直接抽文本但如果是扫描件就需要 OCR 识别否则抽出来的是乱码。Word 文档要先转成纯文本或 Markdown注意去掉页眉页脚、目录、重复的表格。清洗环节我建议至少做三件事把全角字符统一转成半角、去掉多余空行和制表符、把“第 1 页 / 共 10 页”这类分页信息删除。这些脏数据看着不起眼等进入检索阶段它们会变成无效的候选片段白白占用检索名额。# 逻辑示例清洗文本 import re def clean_text(text: str) - str: text text.replace(\u3000, ).replace( , ) text re.sub(r[ \t], , text) text re.sub(r\n{3,}, \n\n, text) text re.sub(r第\s*\d\s*页[,、]?\s*共\s*\d\s*页, , text) return text.strip()4.2 分块策略固定长度是底线结构切分是加分项分块是整个系统里最需要反复实验的参数。块太小比如只有几十个字语义不完整检索回来的是碎片块太大比如几千个字命中一个块会把大量无关内容带进上下文既浪费 token 又干扰回答。我用得最多的是固定长度分块加重叠窗口。中文场景下单块 300 到 500 字是一个比较稳的区间重叠 50 到 100 字。重叠的作用是减少“一句话被拦腰切断”导致的语义断裂。更进阶的做法是按文档结构切分先识别 Markdown 标题、PDF 章节让每一段尽量对应一个完整的小节。# 逻辑示例固定长度分块带重叠 def split_text(text: str, chunk_size: int 400, overlap: int 80) - list[str]: chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) start end - overlap return chunks如果你维护的是几十篇结构清晰的 Markdown 文档我强烈建议先用标题层级切分再对过长的章节做二次固定长度分块。这样检索到的片段往往是语义完整的主题段落比纯按字数切高出不少命中率。4.3 建立向量索引并保存接下来把每个分块喂给嵌入模型得到向量存入向量库。这里要给每个分块保存好元数据来源文件名、章节路径、块序号。这些元数据在后面对照答案和查错时非常有用甚至比向量本身还重要。没有元数据的向量库等于一堆没有出处的引用你永远不知道模型答的内容来自哪里。入库时顺带做去重。同一条内容反复出现在多个文档里会在检索阶段霸占多个名额导致其他相关内容挤不进来。简单做法是计算文档片段间的哈希内容完全一样只保留一份。# 逻辑示例入库 def build_index(docs: list[dict]): for idx, item in enumerate(docs): vector embed_model.encode(item[chunk_text]) vector_store.insert( vectorvector, payload{ file: item[file_name], section: item[section], chunk_index: idx, }, )4.4 检索与问答闭环查询阶段分两步。先把用户问题用同一个嵌入模型转成向量做向量检索取回 TopK 片段再把片段和问题拼进提示词交给生成模型。检索参数里最重要的是 K 值和相似度阈值。K 值决定召回多少候选太小会漏太大会把噪音带进来。个人经验是 K 取 4 到 8 比较合适具体要看文档粒度。阈值的作用是兜底如果所有片段相似度都低于 0.4 之类就说明文档库里根本没有相关内容此时应该让模型回答说“仓库中没有找到相关答案”而不是硬编。提示词的设计也很讲究。我给生成模型下达的指令大概是这样只依据提供的片段回答问题片段不够时就明确说明缺少信息不要补充片段之外的细节。同时把所有片段按顺序放入上下文开头标注文档出处。提示本地系统最容易犯的错是把整个提示词堆得满满当当。8K 上下文的模型塞了 6000 字的检索片段之后模型处理长文本的能力会下降有时候反而忘掉最核心的指令。检索片段宁少勿多。5. 实测必然撞上的五个坑每个我都踩过单看流程RAG 好像很简单。但真正跑起来问题一个接一个。我把最常遇见的五个问题列出来每个都给出我当时排查的过程和最终方案。5.1 分块大小调了很多次答案依然不准症状明明文档里有答案系统就是检索不到或者检索出来的片段半对半错。排查过程我先看检索返回的片段是不是定位到了正确章节。发现定位到的大章节没错但片段太长答案埋在后半段生成模型没注意到。后来把单块字数从 800 降到 400重叠从 0 加到 80定位精度明显改善。结论分块大小直接决定“检索的最小语义单位”是否完整。小一点粒度细命中后上下文更聚焦但太小会导致单个片段缺上下文。最终值是拿自己的文档反复试出来的别人的参数只能当起点不能直接照搬。5.2 检索 TopK 和上下文长度互相挤兑症状TopK 设成 10每个片段 400 字加上提示词和问题单次请求快 5000 token。模型要么啰嗦重复要么把不相关的片段也编进去。排查过程我把 K 从 10 降回 5每个片段控制在 300 字以内回答精炼了很多。关键不是“能塞多少片段”而是“模型能真正利用多少片段”。结论上下文预算要提前分好。比如模型总上下文 8K留 1K 给系统提示和历史对话剩下 7K 给检索内容和生成空间。按这个预算倒推 K 值和单块长度比凭感觉调要高效得多。5.3 相似度阈值设太低把无关片段当答案症状用户问 A 主题系统答出 B 主题的内容而且语气很笃定看起来像有据可依其实是检索错了。排查过程我把每个检索片段的相似度分数打印出来发现低于 0.35 的片段全是噪音。生成模型不管三七二十一把这些噪音当成“参考材料”写进了答案。结论阈值不能省。我这边把阈值定在 0.45 到 0.5 之间低于阈值的检索结果直接丢弃。宁可让模型说“没找到”也绝不能让它用无关内容编答案。这个阈值要按你的嵌入模型和文档类型调整原则是“宁缺毋滥”。5.4 中文 PDF 抽出来是乱码症状理想中的 PDF 解析是整整齐齐的段落实际抽出来是各种断行、乱码、表格错位。排查过程一开始我用基础解析库硬抽抽完也没看结果就直接入库。测试问答时发现几乎所有答案都驴唇不对马嘴回过头看文档片段里面全是“\u3000”和断裂的半句话这才意识到第一步就出了事。结论PDF 清洗这一关绕不开。文字版 PDF 要看解析质量扫描版直接上 OCR。清洗完必须抽看几段片段确认没有乱码和异常空白再入库。最好加一步断行合并把上一行末尾没有句号的文本和下一行拼接避免一句话被拆成两半。5.5 答案看着完整但出处张冠李戴症状回答内容是对的但你追问“这是哪份文档说的”它给出的出处在文档里根本找不到原话。排查过程我最初只把片段文本塞给模型没有强制要求它引用。模型有时把多个来源的内容杂糅在一起还自己补充了顺理成章的过渡句。结论生成模型的提示词里必须规定两件事一是“只能使用片段中的信息”二是“在每个要点后用元数据标注出处”。如果片段本身互相矛盾要如实指出不要自行调合。加上这两条之后张冠李戴的情况少了很多。这些坑有一个共性都不是模型不够聪明而是前面环节有问题。要么是文档清洗没做干净要么是检索召回了非相关内容要么是上下文组织方式不对。排错的时候把链路拆成“清洗—分块—检索—生成”四段分段定位比盲目调参数快得多。6. 检索质量升级混合检索、重排序与查询改写基础系统跑通之后如果你的文档库比较杂或者问题风格口语化直接向量检索就会暴露出一些软肋。向量检索擅长语义相似但遇到专有名词、编号、精确型号这种场景往往不如传统关键词检索来得稳。我建议分三步做升级每一步的收益都很直观。6.1 混合检索向量召回 关键词召回思路很简单同一问题走两条路一条是向量相似度另一条是关键词匹配就是把问题拆成词在文档里找包含这些词的片段。两条路的召回结果合并去重后统一送给后续排序。这样既保留了语义召回对“换个说法”的宽容度又补上了精确匹配对“型号、编号”的敏锐度。合并时注意分数归一化。向量相似度通常在 0 到 1 之间关键词分数可能差异很大不能直接相加。我一般把两类分数各自缩放到 0 到 1然后按 0.6 和 0.4 的权重加权。权重不是死的以你自己评测集上的表现来调。6.2 重排序用交叉编码器重新打分向量检索的分数反映的是“片段和问题的向量距离”这个粗粒度排序有时候不够准。重排序是拿出来再精排把问题和候选片段配对用一个专门的排序模型逐对计算相关性得到更可靠的分数然后重新排序只取前几名进上下文。这一步的代价是开销更高一次要跑 N 对内容。我通常先召回 30 到 50 个候选重排后只取前 4 到 6 个。实测这种“广召回、精重排”的组合比直接拿 TopK 检索进上下文的效果好很多尤其适合文档之间语义差异不大的场景。6.3 查询改写把口语问题变成检索友好的表达用户提问往往很口语化比如“我上次报销那笔钱到底啥时候能下来”。直接拿这句话做向量检索效果一般。查询改写就是在检索之前先用大模型把问题转成几句更直白、信息更完整的关键词表达比如“报销款到账时间”“费用报销进度查询”。然后拿改写后的文本去检索效果比直接用原话好很多。不过要注意改写环节增加了一次模型调用会拉长单次响应时间。处理高频服务时可以考虑只对首次提问做改写后续追问沿用原问题。升级项主要解决什么问题额外开销适配场景混合检索专有名词和精确编号漏召回低本地词表匹配所有场景优先做重排序粗召回排序不准中需要跑候选片段文档语义接近、答案易混查询改写口语问题检索命中率低中多一次模型调用用户提问随意、长短差异大三步不是必须全上。我建议的顺序是先做混合检索性价比最高效果还不够再加重排查询改写可以放到最后因为它对用户体验影响最直接也最容易引入额外的失败点。7. 落地评估与持续优化拿指标说话别凭感觉本地 RAG 系统最大的隐患就是你问几个问题觉得“还挺好”就以为可以上线了。等真实用户问出五花八门的问题才发现检索命中率其实不稳定。所以从第一天起就要把评测机制建起来。我用的方法很简单准备 20 到 50 个真实问题每个问题标好正确答案对应的文档片段做成固定的评测集。每次改完参数把整个评测集跑一遍记录这几项指标命中率回答内容是否覆盖了标准答案里的关键点完全答非所问算 0 分部分覆盖按要点计分。引用准确率答案中标注的出处是否真的包含对应内容防止“答对了但出处是错的”。拒答准确率对文档库中不存在的答案系统是否如实拒绝而不是硬编。单次耗时从提问到完整回答的平局耗时衡量系统的可交互性。测试时把 TopK、阈值、分块大小这几个参数各做几个档位跑一轮对比。比如分块大小分别设 200、400、600TopK 分别设 3、5、8看哪组参数在评测集上得分最高。不要一次改两个变量否则你永远说不清是哪一步起作用。日志埋点也不要省。线上每一条问答把检索出的片段文件名、相似度分数、最终回答用到的 token 数记录下来。当用户反馈答案不对时第一件事就是看检索日志确认是召回没命中还是生成阶段跑偏。这个排查习惯能帮你省掉大量盲目调参的时间。等系统稳定跑起来之后可以按周回顾日志把新增的、没命中的问题补充进评测集。随着评测集越来越接近真实问题分布系统效果的可控性会一步步提升。最后再多说一句我的真实体会本地 RAG 这事的核心从来不是“选了个多强的模型”而是把文档处理、分块策略、检索排序这些看似琐碎的环节一个一个打磨到位。一开始我是冲着“搭建”去的做到后面才发现真正花时间的全是“调优”。如果你也想上手建议先用最小配置跑通全流程再加混合检索和重排每一步都能看到明确的改进这个过程本身就比最后那个“能用”的系统有价值得多。