1. 为什么零基础的人现在反而更适合做 AI 知识库这两年我身边问 AI 知识库的人明显变多了问法也很有意思。前年大家问的是“大模型能不能帮我读文档”去年变成“RAG 到底怎么搭”今年直接变成“我有一堆 PDF怎么搞成一个能问答的知识库”。这个变化说明一件事RAG 已经从研究概念变成了普通人的工具需求。我自己第一次接触 RAG 的时候踩的坑比走的路还多。当时以为把 PDF 丢给模型就完事了结果模型回答得驴唇不对马嘴要么胡编要么答非所问。后来才明白RAG 不是“把文档喂给模型”这么简单它是一整条链路文档解析、文本切分、向量化、检索、重排、生成每一环都有讲究。这篇文章我想写给两类人一类是完全没碰过 AI 知识库、但手头有一堆资料想用起来的普通用户另一类是写过一点代码、想系统搞明白 RAG 全流程的开发者。我会从最基础的“上传一个 PDF”讲起一路讲到能跑起来的 RAG 系统中间该注意什么、该选什么工具、哪里容易翻车我都会说清楚。先给一个最朴素的认知RAG 的本质是“先查资料再回答问题”。就像你考试时允许翻书翻到相关的那一页再根据那一页的内容作答。模型本身不知道你的 PDF 里写了什么是检索环节把相关内容找出来塞给它它才能答对。所以整条链路里检索的质量决定了回答的质量这一点后面会反复提到。2. 先把概念理清楚RAG、LLM Wiki、Embedding、Chunk 到底是什么关系很多人一上来就被一堆术语砸晕我先把这几个词用大白话串一遍后面再展开。2.1 RAG 是什么给大模型配一个“随身资料库”RAG 全称是 Retrieval-Augmented Generation检索增强生成。拆开看就三件事Retrieval检索从你的资料库里找出和问题相关的内容Augmented增强把这些内容作为上下文补充给模型Generation生成模型基于这些上下文生成回答我常跟朋友打的比方是大模型是一个知识渊博但记性有限的专家RAG 就是给他配了一个可以随时翻的资料柜。你问问题他先去资料柜里翻出几页再结合自己的理解回答你。资料柜里放什么、怎么放、怎么找就是 RAG 工程要解决的事。RAG 解决的核心问题是三个知识时效性模型训练数据有截止日期、私有知识模型不知道你公司的内部文档、幻觉模型不知道就会编。这三个问题里私有知识是普通人最关心的因为你手头的 PDF、笔记、报告模型是真不知道。2.2 LLM Wiki 是什么一种更结构化的知识组织方式LLM Wiki 这个词最近热度很高它和 RAG 不是对立关系更像是 RAG 的一种进阶形态。普通的 RAG 是把文档切碎了存进向量库检索时按相似度找片段。而 LLM Wiki 的思路是先把知识整理成结构化的条目再让模型基于这些条目回答。打个比方普通 RAG 像把一本书撕成纸条塞进抽屉找的时候按关键词捞LLM Wiki 像先给这本书编好目录和索引每条知识都有明确的主题、来源、关联。后者在回答“某某概念是什么”“某某和某某有什么关系”这类问题时准确率会高很多。现在社区里讨论比较多的 ontology rag、graphrag本质上都是在往“结构化知识”这个方向走。ontology 是本体graphrag 是图结构它们都在试图解决普通 RAG 的一个痛点碎片化检索容易丢失上下文和关系。如果你的资料是零散的技术文档普通 RAG 够用如果是成体系的知识库LLM Wiki 的思路会更合适。2.3 Embedding 是什么把文字变成能算“距离”的数字Embedding 是整条链路里最容易被忽视、但最影响效果的一环。它的作用是把一段文字转换成一串数字向量这串数字代表了这段文字的“语义”。语义相近的文字向量距离就近。举个例子“猫喜欢吃鱼”和“猫咪爱吃鱼肉”这两句话字面上不一样但 embedding 之后向量距离很近检索时就能互相匹配到。这就是为什么 RAG 能理解语义而不是单纯的关键词匹配。选 embedding 模型是门学问。我自己的经验是场景推荐方向理由中文为主中文优化过的模型中文语义理解更准多语言混合多语言通用模型覆盖语种广本地部署轻量级开源模型不依赖外部服务隐私可控追求效果大参数模型语义区分度更高但慢embedding 模型排行这类榜单可以看但别迷信。同一个模型在不同语料上的表现差异很大最好的办法是拿你自己的数据测一遍。2.4 Chunk 是什么把长文档切成模型能消化的块Chunk 就是文本切分。为什么必须切因为模型有上下文长度限制而且太长的文本检索精度会下降。你不可能把一本 300 页的 PDF 整个塞给模型必须切成一段一段。切分策略直接决定检索质量。切太大一个 chunk 里混了好几个主题检索时容易捞到不相关的内容切太小一句话被拆散语义不完整。我一般建议按语义切分优先按段落、按标题层级切保持语义完整固定长度兜底语义切分不好做时按字符数切但要留重叠重叠很重要相邻 chunk 之间留 10%~20% 的重叠避免关键信息被切断这几个概念串起来就是PDF 经过解析变成文本文本经过 Chunk 切分切分后的片段经过 Embedding 变成向量存进向量库用户提问时同样经过 Embedding在向量库里检索出相关片段再交给 LLM 生成回答。这就是 RAG 的主干流程。3. 从零开始的第一步PDF 解析与文本提取别小看这一步我见过太多人卡在这里。PDF 解析的质量直接决定了后面所有环节的上限。垃圾进垃圾出这句话在 RAG 里体现得淋漓尽致。3.1 PDF 的三种类型处理方式完全不同不是所有 PDF 都一样我一般把它们分成三类第一类原生电子 PDF。这种 PDF 里的文字是可以直接选中的解析起来最简单用常规的 PDF 解析库就能提取出干净的文本。第二类扫描件 PDF。这种本质上是图片文字选不中必须走 OCR光学字符识别。OCR 的准确率受扫描质量影响很大歪斜、模糊、水印都会让识别结果一塌糊涂。第三类混合型 PDF。一部分是文字一部分是图片还有表格、公式、图表。这种最难搞需要针对不同元素用不同策略。我自己的处理顺序是先判断 PDF 类型再决定用什么工具。判断方法很简单用 PDF 阅读器试着选中一段文字能选中就是第一类选不中就是第二类。3.2 解析工具怎么选别一上来就上重型武器工具选型上我的建议是从简到繁。很多人一上来就想用最复杂的方案结果配置半天跑不起来热情直接耗光。纯文本 PDF常规解析库足够速度快结果干净扫描件需要 OCR 引擎中文识别要选中文优化过的复杂版式需要版面分析能力强的工具能识别标题、段落、表格表格多的文档要专门处理表格普通解析会把表格拍扁成乱码这里有个经验解析完一定要人工抽查。我一般会随机抽 5~10 页看看提取出来的文本有没有乱码、有没有段落错位、有没有表格被拆散。这一步花十分钟能省后面几小时的调试。3.3 解析后的清洗这一步最枯燥但最值钱解析出来的原始文本通常很脏需要清洗去掉页眉页脚每页重复的页码、文档标题检索时是噪音合并断行PDF 里一句话经常被硬换行拆开要合并成完整段落处理特殊字符乱码、多余空格、奇怪的符号统一标点中英文标点混用会影响检索我踩过的一个坑有份 PDF 的页脚是“第 X 页 共 Y 页”我没清理结果检索时经常把页脚捞出来当相关内容回答里就冒出莫名其妙的页码。清洗这一步没有捷径但它是检索质量的地基。提示清洗规则最好写成可复用的脚本而不是手动改。文档一多手动改根本改不过来。4. 文本切分ChunkRAG 效果的分水岭如果让我选一个最影响 RAG 效果的环节我会选 Chunk。检索不准八成是切分没做好。4.1 切分策略的三种思路固定长度切分按字符数或 token 数切比如每 500 字一块。优点是简单缺点是经常把一句话、一个段落从中间切断。语义切分按段落、按标题、按句子边界切。优点是语义完整缺点是需要文档本身结构清晰。递归切分先按大结构章节切再按小结构段落切最后按长度兜底。这是目前最常用的策略兼顾结构和长度。我一般用递归切分参数上给个参考块大小500~1000 字符中文太大检索不准太小语义不全重叠块大小的 10%~20%比如 800 字一块重叠 100~150 字分隔符优先级段落 换行 句号 逗号 空格4.2 重叠为什么重要一个真实的反例我做过一个测试一份技术文档里有一句话“该参数默认值为 30取值范围是 10 到 100。”如果不设重叠切分点正好落在这句话中间前半句在上一块后半句在下一块。用户问“这个参数默认值是多少”检索时可能只捞到后半块模型就答不出来。设了重叠之后这句话至少完整地出现在一个块里检索就能命中。重叠是用存储空间换检索召回率非常划算。4.3 特殊内容的切分表格、代码、公式普通文本好切但表格、代码、公式是老大难。表格最好整表保留或者转成“字段-值”的描述性文本。把表格拍扁成一行文字检索基本废掉代码按函数或代码块切别从中间切断公式如果公式重要最好转成文字描述或者保留公式的上下文有个热词叫“有没有本地的 rag 文本拆解工具”说明很多人被这一步卡住。我的建议是先用现成的切分库跑通流程再针对自己的文档类型做定制。别一开始就自己写切分逻辑容易陷入细节。4.4 切分质量的检验方法切完之后怎么知道好不好我一般做两件事随机抽查抽 20 个 chunk看语义是否完整、有没有被切断反向检索测试拿几个已知答案的问题看能不能检索到对应的 chunk如果检索不到先别怀疑 embedding八成是切分的问题。5. Embedding 与向量库把文本变成可检索的知识切分完的文本要经过 embedding 变成向量存进向量库。这一步是 RAG 的“记忆”环节。5.1 Embedding 模型选型的实战考量选 embedding 模型我一般看四个维度维度说明我的取舍语义区分度相近语义能否聚在一起最重要直接决定检索准不准中文能力中文语义理解是否到位中文资料必须重点看速度编码速度文档量大时很关键部署方式本地还是调用服务隐私敏感就本地embedding 模型排行可以当参考但一定要用自己的数据测。我试过两个榜单上排名接近的模型在我自己的技术文档上效果差了将近 20% 的召回率。测试方法很简单准备 20~30 个问题和对应的标准答案片段看模型能不能把正确片段排进前几名。5.2 向量库怎么选别被“高性能”忽悠向量库的选择我的原则是够用就好。常见的几类轻量本地库适合个人和小项目零配置直接跑专业向量数据库适合数据量大、并发高的场景传统数据库的向量扩展适合已经在用某个数据库、不想引入新组件的情况个人做知识库我强烈建议从轻量本地库开始。我见过太多人一上来就搭分布式向量库结果数据就几千条纯属杀鸡用牛刀还增加了运维负担。5.3 向量化的实操细节向量化的时候有几个细节要注意批量处理别一条一条编码批量编码快很多归一化很多模型输出需要归一化否则距离计算会偏维度一致检索和入库必须用同一个模型维度必须一致增量更新文档更新时只重新编码变化的部分我踩过的一个坑入库用了一个模型检索时手滑换了另一个模型结果检索结果全是乱的。模型版本一定要锁死最好在配置里写清楚。6. 检索与重排决定回答质量的关键一环检索是 RAG 的“查找”环节重排是“精选”环节。这两步做不好前面全白搭。6.1 向量检索的原理与局限向量检索的核心是计算相似度常见的有余弦相似度、点积、欧氏距离。它的优势是能理解语义劣势是对精确匹配不敏感。比如你问“RAG 的 hit rate 怎么算”向量检索可能给你捞出一堆讲 RAG 概念的段落但真正讲 hit rate 计算的那段可能排在后面。这时候就需要混合检索。6.2 混合检索向量 关键词混合检索是目前的主流做法把向量检索和关键词检索的结果融合。关键词检索比如 BM25擅长精确匹配向量检索擅长语义匹配两者互补。融合方式常见的有两种加权融合给两种检索结果各一个权重加权求和RRF倒数排名融合按排名融合不依赖分数绝对值更稳健我一般用 RRF因为它不需要调权重省心。实测下来混合检索比纯向量检索的召回率能提升 10%~20%尤其是问题里带专有名词的时候。6.3 重排把最相关的挑到最前面检索出来的结果可能有几十条但模型上下文有限只能塞进去几条。这时候就需要重排把最相关的排到最前面。重排模型rerank比 embedding 模型更精细它会把“问题”和“候选片段”一起输入直接输出相关性分数。代价是慢所以一般只对检索出来的前几十条做重排。我的经验是重排是性价比很高的一步。加一个重排模型回答准确率能明显提升尤其是检索结果多的时候。6.4 检索质量的评估指标评估检索质量几个常用指标Hit Rate正确片段是否出现在检索结果里MRR正确片段的平均排名倒数RecallK前 K 条里包含正确片段的比例我一般准备 30 个左右的问题人工标注正确答案片段然后跑一遍看指标。没有评估优化就是瞎猜。7. 生成环节让模型基于资料回答检索到相关内容后就要交给 LLM 生成回答。这一步看似简单其实提示词的设计很关键。7.1 提示词的核心原则我总结的提示词原则就三条明确角色告诉模型它是基于资料回答的助手限定范围只根据提供的资料回答资料里没有就说不知道要求引用让模型标注答案来自哪段资料第三条特别重要。要求引用能大幅降低幻觉因为模型知道要“交作业”不敢乱编。7.2 上下文怎么塞顺序和数量都有讲究检索出来的片段怎么塞给模型也有讲究顺序最相关的放最前面和最后面中间放次要的模型对首尾更敏感数量别贪多3~5 条通常够用太多反而稀释重点标注来源每条片段标上来源方便模型引用7.3 处理“资料里没有”的情况这是很多人忽略的一点。用户问的问题资料里可能根本没有答案。这时候模型应该老实说“资料里没有相关信息”而不是硬编一个。我在提示词里会明确写“如果提供的资料无法回答该问题请直接说明资料中没有相关内容不要编造。”这一句话能挡掉大量幻觉。8. 常见问题与排查技巧实录这部分是我踩坑最多的地方整理成速查表希望能帮你少走弯路。8.1 检索不准的排查顺序检索不准别急着换模型按这个顺序排查排查项检查方法常见问题切分质量抽查 chunk语义被切断、块太大解析质量看原始文本乱码、页眉页脚没清embedding 模型换模型对比中文能力不足检索方式加关键词检索纯向量漏掉精确匹配重排加重排模型相关片段排名靠后我一般从切分开始查因为切分问题最常见也最容易修。8.2 回答胡编的三种原因模型胡编通常是这三个原因检索没捞到相关内容模型只能靠自己的知识编提示词没限制没告诉模型“资料里没有就说没有”上下文太长塞了太多无关内容模型抓不住重点对应解法优化检索、加限制性提示词、精简上下文。8.3 性能瓶颈在哪里RAG 系统慢瓶颈通常在这几处embedding 编码文档多的时候很慢要批量处理向量检索数据量大时慢要建索引重排重排模型慢要控制候选数量LLM 生成生成本身就慢要控制上下文长度我的经验是先优化检索再优化生成。检索快了整体体验提升最明显。8.4 几个容易被忽视的坑文档更新文档改了向量库要同步更新否则检索到旧内容权限控制多人使用时不同人能看到不同文档检索要带权限过滤多轮对话用户追问时要把历史对话一起考虑否则检索会跑偏图片内容PDF 里的图片普通解析提取不到需要 OCR 或图像理解最后一条特别值得说。热词里有人问“rag 知识库能存储图片嘛”答案是能但要额外处理。图片要么 OCR 成文字要么用多模态模型生成描述再存进向量库。纯文本 RAG 是处理不了图片的。9. 进阶方向从普通 RAG 到 LLM Wiki 和 Agentic RAG跑通基础 RAG 之后如果想进一步提升有几个方向可以探索。9.1 从碎片检索到结构化知识普通 RAG 是碎片化检索回答“是什么”类问题还行回答“有什么关系”“整体脉络”类问题就吃力。LLM Wiki 的思路是先构建结构化的知识条目再基于条目回答。具体做法可以是先用 LLM 从文档里抽取实体和关系构建知识图谱检索时同时走向量检索和图检索。这就是 graphrag 和 ontology rag 的核心思路。代价是构建成本高适合知识体系稳定、查询需求复杂的场景。9.2 Agentic RAG让检索变成主动行为普通 RAG 是“一问一检索”Agentic RAG 是让模型自己决定要不要检索、检索几次、怎么改写查询。比如用户问一个复杂问题模型可以先拆成几个子问题分别检索再综合回答。这个方向目前还在演进工程复杂度高但效果上限也高。我的建议是基础 RAG 跑稳了再考虑别一上来就搞 Agent容易失控。9.3 RAG as a Service把能力封装成服务如果想让团队共用可以把 RAG 封装成服务提供统一的接口。这样不同应用都能调用不用各自重复搭建。agentscope 2.0 这类框架就在往这个方向走。不过我要提醒一句服务化之前先把单机版跑通。我见过太多团队服务化架构搭得很漂亮但检索质量一塌糊涂纯属本末倒置。10. 我自己的学习路线建议最后说说学习路线。如果你是完全零基础我建议按这个顺序走第一阶段跑通最小闭环。找一个现成的 RAG 框架用一份 PDF从解析到问答跑通一遍。这一步的目标是建立整体认知别纠结细节。第二阶段理解每个环节。把解析、切分、embedding、检索、生成逐个拆开理解每个环节的作用和常见问题。这一步可以配合调参实验比如改切分大小看检索效果变化。第三阶段优化检索质量。这是提升效果最关键的一步。加混合检索、加重排、做评估把检索准确率提上去。第四阶段探索进阶方向。基础跑稳后再考虑 LLM Wiki、Agentic RAG 这些方向。我自己走这条路花了大概两三个月中间踩的坑不计其数。现在回头看最大的体会是RAG 的难点不在模型在数据工程。解析、切分、清洗这些“脏活累活”才是决定效果的关键。模型选型反而没那么重要主流的几个模型差距没有想象中大。还有一点别追求一步到位。我见过太多人想搭一个完美的知识库结果卡在架构设计上几个月都没跑起来。先用最土的办法跑通再逐步优化这才是正道。如果你手头正好有一堆 PDF 想用起来我的建议是今天就动手找一份文档跑一遍最小闭环。跑通之后你会对 RAG 有完全不一样的理解。
零基础也能搭建AI知识库：RAG全流程实战指南
1. 为什么零基础的人现在反而更适合做 AI 知识库这两年我身边问 AI 知识库的人明显变多了问法也很有意思。前年大家问的是“大模型能不能帮我读文档”去年变成“RAG 到底怎么搭”今年直接变成“我有一堆 PDF怎么搞成一个能问答的知识库”。这个变化说明一件事RAG 已经从研究概念变成了普通人的工具需求。我自己第一次接触 RAG 的时候踩的坑比走的路还多。当时以为把 PDF 丢给模型就完事了结果模型回答得驴唇不对马嘴要么胡编要么答非所问。后来才明白RAG 不是“把文档喂给模型”这么简单它是一整条链路文档解析、文本切分、向量化、检索、重排、生成每一环都有讲究。这篇文章我想写给两类人一类是完全没碰过 AI 知识库、但手头有一堆资料想用起来的普通用户另一类是写过一点代码、想系统搞明白 RAG 全流程的开发者。我会从最基础的“上传一个 PDF”讲起一路讲到能跑起来的 RAG 系统中间该注意什么、该选什么工具、哪里容易翻车我都会说清楚。先给一个最朴素的认知RAG 的本质是“先查资料再回答问题”。就像你考试时允许翻书翻到相关的那一页再根据那一页的内容作答。模型本身不知道你的 PDF 里写了什么是检索环节把相关内容找出来塞给它它才能答对。所以整条链路里检索的质量决定了回答的质量这一点后面会反复提到。2. 先把概念理清楚RAG、LLM Wiki、Embedding、Chunk 到底是什么关系很多人一上来就被一堆术语砸晕我先把这几个词用大白话串一遍后面再展开。2.1 RAG 是什么给大模型配一个“随身资料库”RAG 全称是 Retrieval-Augmented Generation检索增强生成。拆开看就三件事Retrieval检索从你的资料库里找出和问题相关的内容Augmented增强把这些内容作为上下文补充给模型Generation生成模型基于这些上下文生成回答我常跟朋友打的比方是大模型是一个知识渊博但记性有限的专家RAG 就是给他配了一个可以随时翻的资料柜。你问问题他先去资料柜里翻出几页再结合自己的理解回答你。资料柜里放什么、怎么放、怎么找就是 RAG 工程要解决的事。RAG 解决的核心问题是三个知识时效性模型训练数据有截止日期、私有知识模型不知道你公司的内部文档、幻觉模型不知道就会编。这三个问题里私有知识是普通人最关心的因为你手头的 PDF、笔记、报告模型是真不知道。2.2 LLM Wiki 是什么一种更结构化的知识组织方式LLM Wiki 这个词最近热度很高它和 RAG 不是对立关系更像是 RAG 的一种进阶形态。普通的 RAG 是把文档切碎了存进向量库检索时按相似度找片段。而 LLM Wiki 的思路是先把知识整理成结构化的条目再让模型基于这些条目回答。打个比方普通 RAG 像把一本书撕成纸条塞进抽屉找的时候按关键词捞LLM Wiki 像先给这本书编好目录和索引每条知识都有明确的主题、来源、关联。后者在回答“某某概念是什么”“某某和某某有什么关系”这类问题时准确率会高很多。现在社区里讨论比较多的 ontology rag、graphrag本质上都是在往“结构化知识”这个方向走。ontology 是本体graphrag 是图结构它们都在试图解决普通 RAG 的一个痛点碎片化检索容易丢失上下文和关系。如果你的资料是零散的技术文档普通 RAG 够用如果是成体系的知识库LLM Wiki 的思路会更合适。2.3 Embedding 是什么把文字变成能算“距离”的数字Embedding 是整条链路里最容易被忽视、但最影响效果的一环。它的作用是把一段文字转换成一串数字向量这串数字代表了这段文字的“语义”。语义相近的文字向量距离就近。举个例子“猫喜欢吃鱼”和“猫咪爱吃鱼肉”这两句话字面上不一样但 embedding 之后向量距离很近检索时就能互相匹配到。这就是为什么 RAG 能理解语义而不是单纯的关键词匹配。选 embedding 模型是门学问。我自己的经验是场景推荐方向理由中文为主中文优化过的模型中文语义理解更准多语言混合多语言通用模型覆盖语种广本地部署轻量级开源模型不依赖外部服务隐私可控追求效果大参数模型语义区分度更高但慢embedding 模型排行这类榜单可以看但别迷信。同一个模型在不同语料上的表现差异很大最好的办法是拿你自己的数据测一遍。2.4 Chunk 是什么把长文档切成模型能消化的块Chunk 就是文本切分。为什么必须切因为模型有上下文长度限制而且太长的文本检索精度会下降。你不可能把一本 300 页的 PDF 整个塞给模型必须切成一段一段。切分策略直接决定检索质量。切太大一个 chunk 里混了好几个主题检索时容易捞到不相关的内容切太小一句话被拆散语义不完整。我一般建议按语义切分优先按段落、按标题层级切保持语义完整固定长度兜底语义切分不好做时按字符数切但要留重叠重叠很重要相邻 chunk 之间留 10%~20% 的重叠避免关键信息被切断这几个概念串起来就是PDF 经过解析变成文本文本经过 Chunk 切分切分后的片段经过 Embedding 变成向量存进向量库用户提问时同样经过 Embedding在向量库里检索出相关片段再交给 LLM 生成回答。这就是 RAG 的主干流程。3. 从零开始的第一步PDF 解析与文本提取别小看这一步我见过太多人卡在这里。PDF 解析的质量直接决定了后面所有环节的上限。垃圾进垃圾出这句话在 RAG 里体现得淋漓尽致。3.1 PDF 的三种类型处理方式完全不同不是所有 PDF 都一样我一般把它们分成三类第一类原生电子 PDF。这种 PDF 里的文字是可以直接选中的解析起来最简单用常规的 PDF 解析库就能提取出干净的文本。第二类扫描件 PDF。这种本质上是图片文字选不中必须走 OCR光学字符识别。OCR 的准确率受扫描质量影响很大歪斜、模糊、水印都会让识别结果一塌糊涂。第三类混合型 PDF。一部分是文字一部分是图片还有表格、公式、图表。这种最难搞需要针对不同元素用不同策略。我自己的处理顺序是先判断 PDF 类型再决定用什么工具。判断方法很简单用 PDF 阅读器试着选中一段文字能选中就是第一类选不中就是第二类。3.2 解析工具怎么选别一上来就上重型武器工具选型上我的建议是从简到繁。很多人一上来就想用最复杂的方案结果配置半天跑不起来热情直接耗光。纯文本 PDF常规解析库足够速度快结果干净扫描件需要 OCR 引擎中文识别要选中文优化过的复杂版式需要版面分析能力强的工具能识别标题、段落、表格表格多的文档要专门处理表格普通解析会把表格拍扁成乱码这里有个经验解析完一定要人工抽查。我一般会随机抽 5~10 页看看提取出来的文本有没有乱码、有没有段落错位、有没有表格被拆散。这一步花十分钟能省后面几小时的调试。3.3 解析后的清洗这一步最枯燥但最值钱解析出来的原始文本通常很脏需要清洗去掉页眉页脚每页重复的页码、文档标题检索时是噪音合并断行PDF 里一句话经常被硬换行拆开要合并成完整段落处理特殊字符乱码、多余空格、奇怪的符号统一标点中英文标点混用会影响检索我踩过的一个坑有份 PDF 的页脚是“第 X 页 共 Y 页”我没清理结果检索时经常把页脚捞出来当相关内容回答里就冒出莫名其妙的页码。清洗这一步没有捷径但它是检索质量的地基。提示清洗规则最好写成可复用的脚本而不是手动改。文档一多手动改根本改不过来。4. 文本切分ChunkRAG 效果的分水岭如果让我选一个最影响 RAG 效果的环节我会选 Chunk。检索不准八成是切分没做好。4.1 切分策略的三种思路固定长度切分按字符数或 token 数切比如每 500 字一块。优点是简单缺点是经常把一句话、一个段落从中间切断。语义切分按段落、按标题、按句子边界切。优点是语义完整缺点是需要文档本身结构清晰。递归切分先按大结构章节切再按小结构段落切最后按长度兜底。这是目前最常用的策略兼顾结构和长度。我一般用递归切分参数上给个参考块大小500~1000 字符中文太大检索不准太小语义不全重叠块大小的 10%~20%比如 800 字一块重叠 100~150 字分隔符优先级段落 换行 句号 逗号 空格4.2 重叠为什么重要一个真实的反例我做过一个测试一份技术文档里有一句话“该参数默认值为 30取值范围是 10 到 100。”如果不设重叠切分点正好落在这句话中间前半句在上一块后半句在下一块。用户问“这个参数默认值是多少”检索时可能只捞到后半块模型就答不出来。设了重叠之后这句话至少完整地出现在一个块里检索就能命中。重叠是用存储空间换检索召回率非常划算。4.3 特殊内容的切分表格、代码、公式普通文本好切但表格、代码、公式是老大难。表格最好整表保留或者转成“字段-值”的描述性文本。把表格拍扁成一行文字检索基本废掉代码按函数或代码块切别从中间切断公式如果公式重要最好转成文字描述或者保留公式的上下文有个热词叫“有没有本地的 rag 文本拆解工具”说明很多人被这一步卡住。我的建议是先用现成的切分库跑通流程再针对自己的文档类型做定制。别一开始就自己写切分逻辑容易陷入细节。4.4 切分质量的检验方法切完之后怎么知道好不好我一般做两件事随机抽查抽 20 个 chunk看语义是否完整、有没有被切断反向检索测试拿几个已知答案的问题看能不能检索到对应的 chunk如果检索不到先别怀疑 embedding八成是切分的问题。5. Embedding 与向量库把文本变成可检索的知识切分完的文本要经过 embedding 变成向量存进向量库。这一步是 RAG 的“记忆”环节。5.1 Embedding 模型选型的实战考量选 embedding 模型我一般看四个维度维度说明我的取舍语义区分度相近语义能否聚在一起最重要直接决定检索准不准中文能力中文语义理解是否到位中文资料必须重点看速度编码速度文档量大时很关键部署方式本地还是调用服务隐私敏感就本地embedding 模型排行可以当参考但一定要用自己的数据测。我试过两个榜单上排名接近的模型在我自己的技术文档上效果差了将近 20% 的召回率。测试方法很简单准备 20~30 个问题和对应的标准答案片段看模型能不能把正确片段排进前几名。5.2 向量库怎么选别被“高性能”忽悠向量库的选择我的原则是够用就好。常见的几类轻量本地库适合个人和小项目零配置直接跑专业向量数据库适合数据量大、并发高的场景传统数据库的向量扩展适合已经在用某个数据库、不想引入新组件的情况个人做知识库我强烈建议从轻量本地库开始。我见过太多人一上来就搭分布式向量库结果数据就几千条纯属杀鸡用牛刀还增加了运维负担。5.3 向量化的实操细节向量化的时候有几个细节要注意批量处理别一条一条编码批量编码快很多归一化很多模型输出需要归一化否则距离计算会偏维度一致检索和入库必须用同一个模型维度必须一致增量更新文档更新时只重新编码变化的部分我踩过的一个坑入库用了一个模型检索时手滑换了另一个模型结果检索结果全是乱的。模型版本一定要锁死最好在配置里写清楚。6. 检索与重排决定回答质量的关键一环检索是 RAG 的“查找”环节重排是“精选”环节。这两步做不好前面全白搭。6.1 向量检索的原理与局限向量检索的核心是计算相似度常见的有余弦相似度、点积、欧氏距离。它的优势是能理解语义劣势是对精确匹配不敏感。比如你问“RAG 的 hit rate 怎么算”向量检索可能给你捞出一堆讲 RAG 概念的段落但真正讲 hit rate 计算的那段可能排在后面。这时候就需要混合检索。6.2 混合检索向量 关键词混合检索是目前的主流做法把向量检索和关键词检索的结果融合。关键词检索比如 BM25擅长精确匹配向量检索擅长语义匹配两者互补。融合方式常见的有两种加权融合给两种检索结果各一个权重加权求和RRF倒数排名融合按排名融合不依赖分数绝对值更稳健我一般用 RRF因为它不需要调权重省心。实测下来混合检索比纯向量检索的召回率能提升 10%~20%尤其是问题里带专有名词的时候。6.3 重排把最相关的挑到最前面检索出来的结果可能有几十条但模型上下文有限只能塞进去几条。这时候就需要重排把最相关的排到最前面。重排模型rerank比 embedding 模型更精细它会把“问题”和“候选片段”一起输入直接输出相关性分数。代价是慢所以一般只对检索出来的前几十条做重排。我的经验是重排是性价比很高的一步。加一个重排模型回答准确率能明显提升尤其是检索结果多的时候。6.4 检索质量的评估指标评估检索质量几个常用指标Hit Rate正确片段是否出现在检索结果里MRR正确片段的平均排名倒数RecallK前 K 条里包含正确片段的比例我一般准备 30 个左右的问题人工标注正确答案片段然后跑一遍看指标。没有评估优化就是瞎猜。7. 生成环节让模型基于资料回答检索到相关内容后就要交给 LLM 生成回答。这一步看似简单其实提示词的设计很关键。7.1 提示词的核心原则我总结的提示词原则就三条明确角色告诉模型它是基于资料回答的助手限定范围只根据提供的资料回答资料里没有就说不知道要求引用让模型标注答案来自哪段资料第三条特别重要。要求引用能大幅降低幻觉因为模型知道要“交作业”不敢乱编。7.2 上下文怎么塞顺序和数量都有讲究检索出来的片段怎么塞给模型也有讲究顺序最相关的放最前面和最后面中间放次要的模型对首尾更敏感数量别贪多3~5 条通常够用太多反而稀释重点标注来源每条片段标上来源方便模型引用7.3 处理“资料里没有”的情况这是很多人忽略的一点。用户问的问题资料里可能根本没有答案。这时候模型应该老实说“资料里没有相关信息”而不是硬编一个。我在提示词里会明确写“如果提供的资料无法回答该问题请直接说明资料中没有相关内容不要编造。”这一句话能挡掉大量幻觉。8. 常见问题与排查技巧实录这部分是我踩坑最多的地方整理成速查表希望能帮你少走弯路。8.1 检索不准的排查顺序检索不准别急着换模型按这个顺序排查排查项检查方法常见问题切分质量抽查 chunk语义被切断、块太大解析质量看原始文本乱码、页眉页脚没清embedding 模型换模型对比中文能力不足检索方式加关键词检索纯向量漏掉精确匹配重排加重排模型相关片段排名靠后我一般从切分开始查因为切分问题最常见也最容易修。8.2 回答胡编的三种原因模型胡编通常是这三个原因检索没捞到相关内容模型只能靠自己的知识编提示词没限制没告诉模型“资料里没有就说没有”上下文太长塞了太多无关内容模型抓不住重点对应解法优化检索、加限制性提示词、精简上下文。8.3 性能瓶颈在哪里RAG 系统慢瓶颈通常在这几处embedding 编码文档多的时候很慢要批量处理向量检索数据量大时慢要建索引重排重排模型慢要控制候选数量LLM 生成生成本身就慢要控制上下文长度我的经验是先优化检索再优化生成。检索快了整体体验提升最明显。8.4 几个容易被忽视的坑文档更新文档改了向量库要同步更新否则检索到旧内容权限控制多人使用时不同人能看到不同文档检索要带权限过滤多轮对话用户追问时要把历史对话一起考虑否则检索会跑偏图片内容PDF 里的图片普通解析提取不到需要 OCR 或图像理解最后一条特别值得说。热词里有人问“rag 知识库能存储图片嘛”答案是能但要额外处理。图片要么 OCR 成文字要么用多模态模型生成描述再存进向量库。纯文本 RAG 是处理不了图片的。9. 进阶方向从普通 RAG 到 LLM Wiki 和 Agentic RAG跑通基础 RAG 之后如果想进一步提升有几个方向可以探索。9.1 从碎片检索到结构化知识普通 RAG 是碎片化检索回答“是什么”类问题还行回答“有什么关系”“整体脉络”类问题就吃力。LLM Wiki 的思路是先构建结构化的知识条目再基于条目回答。具体做法可以是先用 LLM 从文档里抽取实体和关系构建知识图谱检索时同时走向量检索和图检索。这就是 graphrag 和 ontology rag 的核心思路。代价是构建成本高适合知识体系稳定、查询需求复杂的场景。9.2 Agentic RAG让检索变成主动行为普通 RAG 是“一问一检索”Agentic RAG 是让模型自己决定要不要检索、检索几次、怎么改写查询。比如用户问一个复杂问题模型可以先拆成几个子问题分别检索再综合回答。这个方向目前还在演进工程复杂度高但效果上限也高。我的建议是基础 RAG 跑稳了再考虑别一上来就搞 Agent容易失控。9.3 RAG as a Service把能力封装成服务如果想让团队共用可以把 RAG 封装成服务提供统一的接口。这样不同应用都能调用不用各自重复搭建。agentscope 2.0 这类框架就在往这个方向走。不过我要提醒一句服务化之前先把单机版跑通。我见过太多团队服务化架构搭得很漂亮但检索质量一塌糊涂纯属本末倒置。10. 我自己的学习路线建议最后说说学习路线。如果你是完全零基础我建议按这个顺序走第一阶段跑通最小闭环。找一个现成的 RAG 框架用一份 PDF从解析到问答跑通一遍。这一步的目标是建立整体认知别纠结细节。第二阶段理解每个环节。把解析、切分、embedding、检索、生成逐个拆开理解每个环节的作用和常见问题。这一步可以配合调参实验比如改切分大小看检索效果变化。第三阶段优化检索质量。这是提升效果最关键的一步。加混合检索、加重排、做评估把检索准确率提上去。第四阶段探索进阶方向。基础跑稳后再考虑 LLM Wiki、Agentic RAG 这些方向。我自己走这条路花了大概两三个月中间踩的坑不计其数。现在回头看最大的体会是RAG 的难点不在模型在数据工程。解析、切分、清洗这些“脏活累活”才是决定效果的关键。模型选型反而没那么重要主流的几个模型差距没有想象中大。还有一点别追求一步到位。我见过太多人想搭一个完美的知识库结果卡在架构设计上几个月都没跑起来。先用最土的办法跑通再逐步优化这才是正道。如果你手头正好有一堆 PDF 想用起来我的建议是今天就动手找一份文档跑一遍最小闭环。跑通之后你会对 RAG 有完全不一样的理解。
