最近被问得最多的一个问题基本可以排到前三“零基础怎么搭一个属于自己团队的 AI 知识库”问的人里有做运营的、有搞行政的、有刚开始学编程的也有想给公司弄一套内部文档助手的研发。大家的需求其实非常一致手头有一堆 PDF、Word、Markdown 文档想让大模型基于这些资料来回答问题而不是让它凭空瞎编。这个需求本质上就是 RAG检索增强生成而市面上各种名词——知识库、向量库、Embedding、Rerank——又把新手绕得头晕。这篇文章我想用一整篇的篇幅把从“拿到一批 PDF”到“跑通一个能用的 RAG 知识库”之间的完整路线拆开揉碎讲清楚。适合完全零基础、被各种概念劝退的人也适合已经装过 Dify 之类工具但发现回答质量一塌糊涂、不知道怎么继续优化的人。我会尽量把每一步为什么要这么做讲明白而不是只丢给你一套点鼠标的操作。1. 先想明白你要做的是知识库不是把文档塞给大模型1.1 知识库到底解决什么问题先做一个类比。你让一个刚入职的实习生回答客户问题他如果只靠自己的脑子最多能回答行业常识要想让他回答你们公司特有的产品细节、报价规则、售后政策你必须先给他一份公司手册而且他看完还要能快速找到对应条目。大模型也是一样它训练时见过海量公开资料但没见过你公司内部那些 PDF 里写的特殊规则。知识库在这里扮演的角色就是“给实习生一本可以随手翻查的手册”。具体到技术上我们把文档切成片段、做成索引、存到向量库里用户提问时系统先根据问题去手册里检索相关内容再把“问题 相关片段”一起扔给大模型让它照着片段内容作答。这就是 RAG 的核心逻辑先检索再生成。很多人一开始会误以为知识库就是把 PDF 直接传上去然后大模型就“记住”了。如果你真这么想后面一定会踩坑。因为大模型在对话时能携带的上下文是有限的几万字的长文档不可能一次全塞进去所以才需要“检索”这一步来决定到底该把哪些片段送给大模型看。1.2 三类知识库的边界结构化、半结构化与非结构化热搜词里有一条很有意思“kg知识库、rag知识库和结构知识库区分以及应用场景”。这说明很多人在概念层面就开始迷茫了。我试着用一句人话解释结构化知识库本质是关系型数据库或者图谱数据是规整的表格、明确的字段比如客户表、订单表。它适合精确查询比如“昨天成交了几单”。非结构化知识库通常是文档型内容比如 PDF、Word、网页它们没有固定的字段结构。RAG 处理的主要就是这类。知识图谱KG它把“实体”和“实体之间的关系”显式地连起来适合“A 和 B 有什么关系”这种问题但构建成本明显更高。对零基础入门来说你 99% 的场景会落在“非结构化文档 RAG”上。先别碰图谱别碰复杂的本体建模那是进阶话题。先把 PDF 里的文字用起来你就已经跑赢大多数只停留在“想”这一步的人了。1.3 零基础最容易犯的第一个错误我见过非常多人一上来就下载了某个开源知识库系统界面很漂亮也成功上传了 PDF但问几个问题发现答非所问于是得出一个结论“RAG 不行”“这个开源项目不行”。其实问题几乎都出在这几处PDF 根本没被正确解析出来、文档切分策略不对、嵌入模型选得太弱、检索结果根本没把真正有用的片段捞出来。所以这篇文章的顺序是刻意安排的先用前三章把“文档处理”和“原理链路”打牢再去讲框架和工具。没有这个地基你搭得越快后面返工越狠。2. 拆开看从上传 PDF 到 AI 回答中间到底发生了什么2.1 一次完整问答背后的四个环节你以为你在对话框里问了一句“咱们公司的年假规则是什么”系统立刻就能给出答案。但实际上后台经历了四步文档解析把 PDF 里的文字、表格、图片内容提取成纯文本。文本切分把长文档按一定策略切成一个个片段Chunk。向量化嵌入用嵌入模型把每个片段变成一串数字向量并把向量存入数据库。检索与生成用户提问时把问题也变成向量在向量库里找最相似的片段最后把片段和问题一起交给大模型生成回答。这四个环节里任何一个偷懒最终回答质量都会打折。而新手往往把注意力全放在“怎么选大模型”上忽略了解析和切分这是最典型的误区。2.2 文档解析为什么是整条链路的“地基”你可以把 RAG 想象成盖房子解析就是地基。如果 PDF 里的文字提取出来是乱码、是丢字、是排版错乱后面做得再好也是白搭。这里有个常见误解PDF 不就是能选中文字、能复制嘛解析有什么难的真正上手你才会发现PDF 的“内里”分好几种有的是文本型PDF文字本身是编码的可以直接提取有的是扫描件本质上是一张张图片必须走 OCR 识别还有一种是“带复杂排版的 PDF”比如双栏、有页眉页脚、文字压着图片直接提取出来的顺序经常是乱的。我在第三章会展开讲具体怎么处理这里先建立一个认知解析结果决定了 RAG 的上限。很多知识库项目最后效果不好你追根溯源往往发现是解析环节就有问题。2.3 向量化把文字变成坐标到底是什么概念嵌入模型Embedding做的事情本质上是用一串数字表示一段文字的“语义坐标”。比如“年假”和“带薪休假”在字面上完全不同但语义相近它们在向量空间里的距离就会比较近。这就是为什么知识库能理解“换个说法提问”的底层原因。向量化的质量取决于你选的嵌入模型。你可以把嵌入模型类比成翻译官翻译官水平差会把“苹果手机”和“苹果这种水果”混为一谈翻译官水平高就能区分语境。后面第五章会专门讲模型选型。3. 第一步实操PDF 解析和内容清洗的正确姿势3.1 先分清你的 PDF 是哪一种类型我处理过几千份格式各异的 PDF几乎可以总结出一条规律解析工具本身没有绝对好坏只有合不合适。拿到一份 PDF先做两个判断是文本型还是扫描件最简单的方法用阅读器打开试着选中一段文字。能选中就是文本型只能选中整页变成高亮块基本就是扫描件需要 OCR。是单栏还是多栏排版学术论文常见双栏说明书常见多栏。如果你不处理栏顺序提取出来的文本会变成“左栏第一行、右栏第一行、左栏第二行...”的交叉错乱。3.2 文本型 PDF 的处理工具对比如果你手里是文本型 PDF那选择就多。我常用的几款各有偏重工具优势劣势适合场景PyMuPDFfitz提取速度快能保留部分格式和元数据对复杂排版的顺序处理一般批量处理大量常规 PDFpdfplumber表格和文本的位置信息非常准速度慢处理超长文档耗时需要精确表格数据、版面分析PyPDF2 / pypdf轻量API 简单文本抽取能力偏弱复杂版式易乱简单脚本、临时处理商业云解析服务版面分析强表格还原度高收费数据出外网有合规风险对解析质量要求高的生产环境我自己的经验是如果只是个人零基础实验优先用 PyMuPDF 快速跑通流程如果你发现某些文档提取顺序混乱再针对这些“问题文档”用 pdfplumber 精细处理。不要一开始就在工具选型上纠结太久先把流水线跑通最重要。3.3 扫描件OCR 方案怎么选扫描件 PDF 本质是图片这一步只能靠 OCR光学字符识别把图片上的字变成文本。中文场景下的选择基本是这几个方向Tesseract免费开源但中文识别质量一般需要额外下载中文语言包对排版复杂的扫描件效果有限。PaddleOCR百度开源的 OCR 工具中文识别效果明显好于 Tesseract支持版面分析是目前开源方案里的主流选择。云服务 OCR各家大厂都有识别准确率最稳定但同样涉及数据外发问题。如果你要处理的扫描件不多我建议直接用 PaddleOCR 本地跑既能保证质量又不存在数据出境的问题。安装稍微有点门槛但照着官方文档操作半小时内能跑通。3.4 清理环节PDF 提取后必须做的三件事费了好大劲把文字提出来不代表就能直接拿去切分建库了。我每次都会做一个“提取后检查清单”去页眉页脚。页码、公司 logo 下的重复文字、章节页眉这些内容会被切进片段里检索时造成严重噪声。合并断行。PDF 提取出来的文本经常是“每行一个段落”尤其是英文文本。需要根据换行符情况做合并不然一个完整句子被拆成七八段切分时会被拦腰截断。处理表格。表格在 RAG 里是个老大难。直接转成纯文本行列关系会丢失但很多开源知识库目前对表格的还原能力都一般。这三点里页眉页脚的清理是最容易忽视的。我曾经处理一份 200 页的产品手册页眉每页都是“XX产品用户手册 第 X 章”结果检索时大量片段因为共同包含页眉文字而被误判为相似整个检索排序全乱了。后来我写了个脚本按规则批量剔除页眉区域文字效果立竿见影。4. 切分策略Chunk 大小和重叠才是检索质量的关键变量4.1 为什么切分方式能决定成败嵌入模型一次能处理的文本长度有限所以长文档必须切片。但切片绝不是“每 500 字一刀切”切得好不好直接决定检索能否命中。举个例子你有一份合同里面有一条“违约责任若甲方逾期付款超过 30 日乙方有权解除合同并收取违约金”。如果切分时把这句话从中截断了那检索“合同解除条件”时模型可能只找到“若甲方逾期付款超过 30 日”不知道后半句的后果或者只找到“乙方有权解除合同”丢失了“逾期 30 日”这个前提条件。这种信息残缺会让大模型给出“看似合理但细节错漏”的回答。4.2 切分参数的通用经验值切分有三个核心参数Chunk Size每个片段的字数。Chunk Overlap相邻片段之间重叠的字数。切分单位按字符数、按句子、还是按 Markdown 标题结构。以中文文档为例我常用的经验值是Chunk Size 在 300 到 800 字之间Overlap 在 50 到 150 字之间。具体取值取决于你的文档类型如果文档是问答式比如 FAQ可以切小一点200 到 400 字因为每个问答本身是独立完整的单元。如果文档是长段落式的技术规范或制度文件切大一点500 到 800 字避免把一个完整的逻辑链条切碎。如果文档里有大量列表、步骤说明可以考虑按 Markdown 标题层级来切也就是所谓的“结构化切分”保证每个片段自带上下文。4.3 结构化切分比固定长度切分更优的方案固定长度切分虽然简单但会经常斩断语义。更推荐的做法是“按结构切分”先用标题层级定位章节再在章节内部按段落或语义切块。现在很多知识库框架已经内置了 Markdown 解析器能自动识别标题、表格、列表并按层级组织片段。如果你用的是 Dify 或者 RAGFlow它们在文档加载器里就提供了按 Markdown 标题切分的选项。我自己的经验是如果源文档本身就是结构化良好的 Markdown 或 HTML用结构切分的效果比固定长度切分高一个档次。反过来如果源文档是纯文本扫描识别出来的结构已经丢失只能用固定长度切分加适当重叠。4.4 一个值得尝试的进阶技巧父子分块“父子分块”是针对“检索却又怕上下文丢失”的一种思路把小片段作为检索单位提高准确性命中后把该小片段所属的更完整的大块内容一起喂给大模型保证上下文完整性。说得直白一点用“章节摘要”去匹配问题找到正确章节后把整个章节内容都给大模型看。这种方式特别适合长文档问答。比如你问“公司对加班有什么规定”可能文档里有大段内容分散在“考勤制度”和“薪酬福利”两个章节单纯小片段检索只能捞到其中一段。父子分块就能把相关章节整体带出来让大模型综合回答。5. 框架选型Dify、FastGPT、RAGFlow 等开源方案怎么选5.1 主流框架的定位差异跑通原理之后就到了选工具的环节。目前零基础最常接触的三个开源知识库框架各有各的脾性框架定位优势需要注意的点Dify一站式 LLMOps 平台上手快工作流可视化支持知识库、Agent、插件部分高级功能在企业版社区版有资源上限FastGPT知识库 工作流偏向业务集成知识库能力做得细致支持可视化编排部署和升级比 Dify 稍微繁琐RAGFlow深度优化 RAG 链路强调可解释性文档解析能力强引用溯源做得很好对服务器资源要求更高界面偏专业向除了这三家还有不少新玩家和新框架但底层逻辑大同小异。零基础没必要把每个框架都装一遍选一个先深入用透。5.2 我建议零基础从哪里开始Dify如果是完全零基础我首推 Dify。原因很简单文档解析、切分、嵌入、向量库、模型调用全部帮你串好了你能在一天内把一条完整的 RAG 流水线跑起来。先有一个能用的系统再去逐个环节深挖优化学习效率是最高的。Dify 社区版可以用 Docker 部署如果你不会 Docker也可以直接用它的云端版先体验。建知识库时直接上传 PDF它会走内置的文档解析和切分流程然后你只需要选择嵌入模型和对话模型就能开始测试了。5.3 用 RAGFlow 作为第二站的原因等你理解了基础的全流程我建议再去看 RAGFlow。它对文档解析这块做了很多强化比如“版面识别 深度文档理解”对于复杂 PDF 的解析质量明显比通用框架好。更重要的是它把检索结果和引用段落展示得很清晰你能直观看到“大模型是根据哪一段内容回答的”这对排查问题非常有帮助。可以说 Dify 是让你“快”RAGFlow 是让你“懂”。两者配合你既能快速上手又能理解优化的方向。6. 嵌入模型与向量库这两个选择决定你的知识库下限6.1 嵌入模型中文场景选什么嵌入模型是 RAG 里最容易被低估的环节。很多人随便选一个默认模型结果发现知识库怎么调都不聪明。中文场景下我推荐几个方向BGE 系列BAAI/bge-large-zh-v1.5 等目前开源中文嵌入模型里成熟度最高的支持中文语义匹配效果好而且对长文本支持不错。text-embedding-3-small / text-embedding-3-largeOpenAI 的嵌入模型中文效果也不错但数据会发给 OpenAI 的 API得有网络和费用上的考虑。国产商业 API 的嵌入模型比如各云厂商提供的通用向量模型中文效果通常也稳定。我需要强调一个技术细节开源嵌入模型对中文的支持参差不齐很多英文场景表现不错的模型在中文上会明显“笨”一些。你在模型库选择时看模型卡上有没有标注中文训练数据占比优先选在中文评测比如 C-MTEB上分数高的。6.2 向量库需要单独部署吗其实很多知识库框架已经内置了向量库比如 Dify 默认使用 WeaviateFastGPT 用 MongoDB 的向量索引。作为零基础你不需要一开始就单独部署 Milvus、Qdrant 这类专业向量数据库。但你需要知道向量库索引的几个关键概念相似度度量常用的是余弦相似度Cosine衡量方向的相似程度。Top K返回最相似的多少个片段。通常设 4 到 10 之间。K 值太小可能漏掉关键信息K 值太大会把不相关内容也带进来浪费上下文窗口。相似度阈值低于某个相似度的结果宁可不返回也别硬塞给大模型。经验上0.3 或 0.4 以下的片段基本可以认为是无关内容。6.3 一个不太好听但很真实的事实很多知识库效果差不是大模型不够聪明而是嵌入模型召回的片段根本不对。你换了更强的对话模型它也不过是“更聪明地基于错误内容作答”。所以你在做优化时先怀疑嵌入模型和检索策略而不是一开始就迷信“大模型要上最强的那款”。7. 检索策略从“能回答”到“答得准”的分水岭7.1 先理解召回率和准确率RAG 的检索环节可以拆成两个指标来看召回率真正相关的片段有多少被找出来了。召回率低意味着答案依据不足大模型只能瞎编。准确率精确率找出来的片段里有多少是真正相关的。准确率低意味着噪声多大模型容易被错误信息带偏。零基础用户最容易遇到的问题就是片段确实召回了但召回的是一堆页眉、目录、无关章节大模型被这些垃圾信息干扰回答自然不对。这种时候你去调 prompt 是没用的问题出在检索环节。7.2 最常见的三种检索问题及应对只做向量检索词面和语义对不上。对策向量检索 关键词检索的混合检索。向量检索擅长找“同义不同词”关键词检索擅长精确匹配人名、编号、产品型号。两者结果合并投票能显著提升召回质量。片段太碎上下文信息不够。对策用前面说的父子分块检索小片段返回大段落。一次检索策略吃遍所有问题类型。对策针对不同问题类型设计不同的检索策略。比如“这个价格是多少”适合精确匹配报价表“这个功能怎么实现”适合按上下文检索长段落。7.3 重排序Rerank提升精度的关键一步检索阶段先用低成本的模型拉回一批候选片段比如 20 条然后用一个重排序模型对这 20 条重新打分排序只把最高分的 5 条送给大模型。这个“粗召回 精排序”的两阶段策略是目前 RAG 质量提升性价比最高的手段之一。重排序模型需要单独部署或调用 API主流框架基本都支持配置。你如果发现知识库的回答总是“沾边但不精准”优先检查是否加了 Rerank。加了之后效果往往会有肉眼可见的提升。7.4 多路召回和查询改写什么时候需要这些都是进阶玩法不需要一开始就上。多路召回是同时从多个索引或多种检索方式做召回再合并查询改写是先把用户的模糊问题改写成几条更清晰的问题再做检索。当你发现“用户问得越口语化检索越不准”时再考虑加查询改写。零基础阶段先把 7.2 和 7.3 的两点做好效果就能超过大多数业余项目了。8. 效果评估与常见瓶颈别靠感觉调优先学会量化8.1 给知识库打分RAGAS 和人工测试集很多人在调 RAG 时全凭感觉“这个回答好像更好了”“这个好像还是不对”。这种状态很难持续优化。我建议一开始就建立一套最小的评估集准备 20 到 50 个问题覆盖你们业务里最常见的高频问题然后每次改动后用同一批问题跑一遍记录回答质量评分。如果要更系统化可以用 RAGAS 框架做自动化评估它把 RAG 效果拆成三个核心维度忠实度Faithfulness回答是否忠于检索到的片段有没有编造。答案相关性Answer Relevance回答是否切题。上下文相关性Context Relevance检索到的上下文是否包含了回答所需的必要信息。我个人的习惯是先把 8.1 的“忠实度”放在第一位。一个知识库如果经常编造文档里没有的内容那是绝对不能上线的。8.2 我见过的知识库“效果差”的五大瓶颈根据过往经验知识库做出来不好用原因几乎集中在下面五个方向按出现概率排序文档解析质量问题。扫描件 OCR 错字太多或者页眉页脚噪声严重检索结果被污染。切分策略不适合文档类型。把低频长文档切得太碎或者把 FAQ 切得太大。嵌入模型选型偏弱。中文效果差语义相似度判断不准。缺少重排序环节。检索结果粗而不精。没有设计好的 user prompt。知识库在回答时如果 prompt 里没有明说“只能基于给定内容回答不能自行发挥”大模型就会自由发挥。最后一条特别容易被忽略。你给大模型的指令需要明确约束它严格基于检索内容作答如果检索内容不足以回答就明确说“文档里没有相关信息”不要强行编。这一步能明显减少“幻觉”。8.3 瓶颈排查的完整链路一个真实案例用一个小例子把排查过程串起来。假设你搭了一个 Dify 知识库上传了公司的制度 PDF然后问“办公用品领用流程是什么”它回答得跟文档完全对不上。正确排查顺序是第一步先在知识库里做纯检索测试看看系统到底检索出了哪些片段。如果 Dify 提供了“引用文件”的展示点开看它引用了哪几段。如果引用内容根本不包含领用流程问题出在检索侧如果引用了正确段落但回答错了问题出在生成侧。第二步检查解析结果。在知识库的文档列表里打开这份 PDF 的“分段预览”看看有没有乱码、断行、页眉噪声。这一步能过滤掉 40% 的问题。第三步检查切分。看“领用流程”是不是被切到了两个片段中间导致哪一段都不完整。第四步检查嵌入模型和检索方式。临时把 Top K 调大比如调到 10看正确内容是否会出现在候选结果里。如果调大后仍然找不到说明嵌入模型召唤不出来换个嵌入模型试试。第五步检查生成 prompt。确认系统提示词里是否明确要求“基于给定的内容回答”。按照这个链路走下来99% 的问题都能定位到具体环节。很多人在第一步就放弃了跑去调 prompt其实完全错位。9. 面向更上层的思考从朴素 RAG 到更聪明的知识库9.1 Ontology RAG、GraphRAG 这些新概念要不要追最近总能刷到 GraphRAG、Ontology RAG 这些概念很多新手因此焦虑是不是不用图谱就落伍了我的建议是零基础阶段先把朴素 RAG 的每一步做到位再考虑升级。GraphRAG 的适用场景是“回答需要跨多篇文档串联推理的问题”比如“我们所有研发项目里哪些是 2024 年启动并且使用了 Vue 的”。这类问题如果只用片段检索很难把分散在多个文档里的信息合起来。但 GraphRAG 的构建成本也高需要先抽取出实体和关系再存成图谱。对于大多数“问答靠单篇文档”的场景朴素 RAG 已经够用。9.2 知识库如何与 AI Agent 结合热搜词里出现了大量“AI Agent”相关的词。知识库和 Agent 的关系可以理解为知识库提供“长期记忆和事实依据”Agent 负责“理解和执行任务”。比如你问“帮我总结这份合同的风险条款并写一封提醒邮件”知识库负责找出合同片段Agent 负责把总结和写邮件的动作串起来。在 Dify 和 FastGPT 里你都可以把知识库作为工具挂给 Agent。这是 RAG 迈向实际生产力的方向。但我的建议仍然是先把知识库本身的问答质量调到令人满意再考虑接 Agent。否则你接的 Agent 只会更快地把错误信息放大。9.3 知识库的维护也是成本最后必须提醒一件事知识库不是一次搭好就一劳永逸的。文档更新了你需要重新上传或增量更新嵌入模型换了你需要重新做一遍向量化用户提问方向变了你需要回头调整文档结构和切分策略。我见过不少团队搭知识库花了两周维护知识库却完全没排期最后知识库因为内容过时被弃用。所以你在规划的时候至少留出 20% 的时间来做清洗、更新和效果回归。好的知识库本质上是一个需要持续运营的内容产品而不是一次性部署的软件项目。我个人在实际操作中的体会是很多人卡在中间某个环节不是因为不会用工具而是因为不理解“检索结果为什么是错的”。如果你能养成习惯每次回答不对时先去看系统“引用”了哪些片段再顺着引用往回推是解析、切分、嵌入还是生成环节的问题你的水平会提升得非常快。这也是我和很多朋友交流后得出的最一致的经验RAG 的调试拼的不是玄学而是你能不能把一条链路里每个环节的“输出”都检查一遍。把这篇文章里的几步都做到位你的知识库就已经超过绝大多数所谓的“AI 问答助手”了。