先聊个真实现象很多朋友拿到一个 PDF下意识就把它拖进 AI 对话框然后对着大模型说“帮我总结一下”结果模型要么说“我没法读取附件”要么答得模棱两可。于是大家开始搜“怎么搭建 AI 知识库”“PDF 怎么进知识库”搜出来的教程又全是 Dify、RAG、向量化、嵌入模型这些半懂不懂的词。这篇文章就是把“零基础入门 AI 知识库”这件事从头到尾拆开讲清楚为什么 PDF 不能直接喂给大模型RAG 到底做了什么Dify 和 Ollama 本地方案分别怎么跑通以及搭完之后检索质量上不去的坑在哪。如果你现在连“RAG 是什么”都说不上来没关系这篇文章就是给你写的。不需要会写代码不需要懂深度学习跟着路线一步步走目标是让你在一天内跑通一个“能回答 PDF 内容问题”的知识库问答应用并且知道下一步该往哪个方向深入。1. 先把概念扒开RAG 解决的不是“记住”而是“查得到、拼得对”1.1 为什么 PDF 不能直接塞给大模型要理解 RAG先得搞清楚大模型的局限。现在的语言模型本质上是一个“根据前文猜下一个词”的系统它的全部知识都凝固在训练时见过的那批数据里。你训练时没看过某份 2025 年的行业报告它就一点都不知道就算看过它也是把内容“压缩”成了参数而不是把原文逐字记住。所以当你试图让模型“记住”一整本几百页的 PDF 时你其实是在逼它做一件它根本做不到的事把超过上下文窗口的信息塞进一个小小的输入框。上下文窗口是什么你可以把它理解成模型一次能“摊在桌面上看”的字数上限。老一点的模型可能只有几千字新模型虽然有几十万字甚至百万字的窗口但窗口越大每个位置能得到的注意力越稀疏模型对长文本深处的细节就越容易“看是看了等于没看”。而且就算上下文窗口够大你把 500 页 PDF 全部拼进提示词里回答一个具体问题时模型也分不清那句关键结论藏在第几页第几章。它学习到的规律是“输出流畅、自洽的文本”不是“去某个段落里精确检索一句事实”。所以零基础入门 AI 知识库第一课就要把观念扭过来知识库不是把 PDF 装进模型脑袋里而是让模型在用的时候临时去翻资料。这套“临时翻资料再作答”的机制就是 RAG。1.2 RAG 的全流程到底发生了什么RAG 的全称是 Retrieval-Augmented Generation检索增强生成。名字听着硬核拆开就三件事先检索再拼接最后生成。打个比方你是一个不善记忆的实习生领导问你“公司 Q3 的客户流失率是多少”你不会直接编答案而是先查一下报表检索把关键段落抄到便签上拼接再照着便签组织语言回答生成。大模型做了同样的事情。整个流程具体是这样先把你上传的 PDF 做清洗和切分长文档切成一段一段的小文本块每个块通常几百字这是为了后续检索定位时更精确总不能一搜就出来一整本书。把这些文本块全部转换成“向量”。这个概念后面我会再用白话解释一遍你现在只需要知道向量就是把一段文字变成一个数组语义相似的两段话它们的向量在数学空间里离得近。用户提问时问题也被转成向量然后在向量库里做相似度搜索找出最相关的几个文本块。把找出来的文本块和用户问题一起拼成一个新的提示词交给大模型模型基于这些片段作答。这里面最关键的转变是答案的素材来源从“模型的记忆”切换成了“你提供的知识库片段”。模型不再凭印象胡编而是依据你喂给它的原文片段作答同时在提示词里明确写一句“如果片段里没有答案就如实说不知道”。这就是一个能拿自己 PDF 提问的知识库问答系统的全部秘密。看到这里你可能已经明白一件事RAG 的成败很大程度上不取决于你用了多强的模型而取决于中间那两步——文档切分得好不好检索结果准不准。这也是为什么同样一个 Dify 项目有的人搭出来很好用有的人搭出来满嘴跑火车。后面的内容基本都是围绕这两个环节展开的。2. PDF 进知识库之前解析和分块才是真正的分水岭2.1 不同的 PDF 解析工具该怎么选很多人觉得“上传 PDF”是一步到位的操作实际远没这么简单。PDF 是我见过最不适合做文本提取的格式它的排版信息是“画”出来的不是“写”出来的。一份 PDF 里可能有可复制的文字层也可能是扫描图片还可能是由表格、页眉页脚、分栏混排组成的复杂版式。解析不对后面所有环节都会继承这份脏数据。分享一个我在实际项目里的选型经验按内容类型分场景纯文本型 PDF、报告、书籍类首选pypdf或PyMuPDF速度快能直接抽文字。其中 PyMuPDF 对复杂排版的还原度更好还能顺带提取图片位置适合稍微花哨一点的文档。带表格的 PDF用pdfplumber它对表格线的识别比通用库好不少能按单元格抽出来。但也别指望 100% 无误复杂跨页表格照样翻车。扫描版 PDF不管用什么库没 OCR 之前都是白搭。这时候最稳的是先把 PDF 按页转成图片再交给 OCR 引擎。中文场景下我常用 PaddleOCR识别效果好但它需要额外装模型和依赖零基础玩家可以先跳过等你确实遇到扫描件再回头处理。奉劝一句如果原始文件有 Word 或 Markdown 版本优先用它们不要死磕 PDF。PDF 解析做得再好也只是在还原原本就存在的信息还原过程还会引入误差。源头是干净的电子文档后面能少操百分之八十的心。2.2 分块策略没做好分块后续所有检索都在救火解析完 PDF拿到一大段连续文本之后直接整篇丢进知识库是新手最容易犯的错误。因为检索的最小单位是“块”不是“页”更不是“整篇”。想象一下如果你把一本小说一整章作为一个块用户问“女主角第一次出场的台词是什么”这个块里虽然有答案但同时也混入了大量无关情节语义早被稀释了。向量检索算相似度时是拿整个块的平均语义去和问题比无关内容越多评分越差相关片段越容易被埋没。分块没有标准答案但有实用的经验值。我常用的起点是块大小 300 到 500 个中文字符相邻块之间重叠 50 到 100 个字符。重叠的意义在于一个关键句刚好被切成两半时有重叠的块能让句子完整出现在至少一个切片里。别小看这个细节它直接解决了很多“答案明明在文档里但检索就是找不到”的诡异问题。更聪明的办法是按结构切分而不是按固定字数硬切。比如 Markdown 标题、PDF 章节标题、段落标记都是天然的边界。先按标题切到章节如果某个章节还是太长再往下一级标题切。这样做的好处是语义完整性更好同一块的文字往往在讨论同一件事。Dify 的“自动分段与清洗”以及 LangChain 的 RecursiveCharacterTextSplitter 都是在往这个方向走前者开箱即用后者需要自己传 separators 参数。零基础阶段直接开 Dify 的自动分段就行后面手动搭的时候再来微调。2.3 一个我反复翻车的例子表格和扫描件说一个我踩过好几次的坑。我帮一个朋友把他公司几十页的设备维护手册做进知识库手册里有大量参数表格。我一开始偷懒直接用通用解析库把文字抽出来存进去结果问“某个型号的额定功率是多少”这类问题时答案经常是错的。排查发现那几个关键表在解析后变成了一长串没有表头的数字流字段和数值的对应关系全丢了。后来我的处理方式是凡是带表格的页面先在代码里检测到表格区域把表格按“行”提取再把每一行拼接成一句完整的话比如“型号 HT-300额定功率 1500W重量 12kg保修期 36 个月”。这样一来每个字段和它的值绑在了一起既能被检索到模型拿到片段后也能直接读懂含义。扫描件的问题更彻底没有文字层解析出来是空文本。这时必须 OCR。我的通用做法是先把 PDF 转成 300dpi 的图片再逐页走 PaddleOCR识别出来的文本按页面顺序存回 UTF-8 文本文件最后这个文本文件才真正进入知识库工作流。记住OCR 出来的文本可能有不少错别字后续还要有人工复核或者至少让嵌入模型去容忍这些错字别指望识别结果能干净得像原始文档一样。3. 零基础路线 ADify 把 RAG 做成可视化流水线3.1 部署 Dify 到底要做什么如果你是零基础第一条推荐路线当然是可视化平台。Dify 是目前社区里最火的开源 LLM 应用开发平台关键词里的“dify 知识库流水线”说的就是它。它把文档导入、分块、向量化、知识库检索、模型调用、提示词编排全都封装成了界面上的模块你不用写一行业务代码。部署方式其实不难官方推荐用 Docker Compose。装好 Docker Desktop 之后打开终端依次执行git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d第一次启动会拉取不少镜像耐心等完。浏览器访问http://localhost/install按向导创建管理员账号就能进入工作台。这里有一个新手很爱忽略的点.env 里可以预先配置你要用的模型供应商 API Key。如果你有 OpenAI Key直接填上如果没有后面在平台里配置 Ollama 或者其他开源模型也行这一步不影响你先把框架跑起来。3.2 创建知识库并上传 PDF进入 Dify 后左侧菜单找到“知识库”点击创建。名字随意索引方式我建议直接选“高质量”虽然会消耗更多向量化调用但检索准确度明显好于经济模式。Embedding 模型选择上如果你接了 OpenAI 就用text-embedding-3-small如果走本地 Ollama 就用bge-m3后面第四章会讲怎么配置本地模型。创建好空知识库后把 PDF 拖进去Dify 会弹出一个文档处理配置界面。分段模式里我推荐选“自动分段与清洗”它会在识别到标题、段落、列表结构的时候做智能切分比固定长度硬切合理很多。索引方式选“高质量”后点击保存并处理后台就开始向量化。上传几十页的 PDF一般也就几十秒到几分钟。这里特别提醒如果上传的是扫描版 PDFDify 自带的解析效果比较弱它不会自动帮你 OCR。你最好先把扫描件转成可复制文字的 PDF或者直接上传经过 OCR 处理的文本文件。这也是我前一个章节反复强调 PDF 解析是前置工作的原因。3.3 把知识库接到聊天应用上知识库建好之后返回“工作室”创建“聊天助手”应用。在编排页面左侧把“知识库”节点拖进画布选好刚建好的知识库。这里有几个参数是需要动手调一下的TopK默认 3 左右代表每次检索返回几个文本片段。太少可能漏答案太多会把无关内容塞进提示词后期按你的问题分布来调。Score 阈值低于这个相似度分数的片段会被丢弃默认 0.5 之类。如果你发现模型经常瞎编把这个阈值往上调一点。重排序Rerank如果平台里配置了 Rerank 模型就在知识库节点里打开它能对检索结果二次打分效果立竿见影。没有相关模型 Key 的话先跳过也行。最后在“提示词编排”里写清楚系统提示词我常用的版本是你是一名知识库助手必须只基于用户提供的资料片段回答问题。如果片段中没有相关信息就明确告知“未查询到相关内容”不要编造。设置完后点右上角“发布”你就有了一个带 PDF 知识的聊天机器人。3.4 Dify 实操中常见的“排队中”问题关键词里有一条“dify 知识库排队中”我在实际使用里也遇到过很多次。这个现象出现在点击“保存并处理”之后文档状态一直卡在“排队中”或者任务队列半天不动。多数情况下不是你的文件坏了而是后台 Worker 处理不过来。Dify 的向量化任务是由 worker 容器异步执行的如果你本机资源比较紧张多份大文档同时进来时就会排队。我试过的几个有效处理办法一是把大 PDF 拆成多个小文件分批上传减小单任务负载二是把 .env 里 worker 并发数、celery 相关配置调高后重启容器三是很多人忽略的——确保 Embedding 模型接口正常。如果你用的是 Ollama 或者自建模型接口慢一点或者连接不稳定任务就会卡在排队里不动。去后端容器日志里看一眼 embedding 服务的报错基本能定位问题。4. 零基础路线 BOllama Chroma 手搓一套本地最小 RAG4.1 环境准备和模型选择Dify 很适合快速跑应用但它像个黑盒子出了质量问题你不好查到底坏在哪一步。想真正理解 RAG我强烈建议你留出第二个下午跟着我下面的方案手搓一遍最小实现。它不复杂零基础也能复制但跑通之后你脑子里那根“文档到向量到检索到生成”的链路就彻底通了。先装两样东西Ollama 和 Python。Ollama 负责模型推理Python 负责写调度代码。Ollama 安装完成后在终端里拉两个模型一个是对话模型一个是嵌入模型ollama pull qwen2.5:7b ollama pull bge-m3qwen2.5:7b 是通义千问的开源 7B 版本中文能力不错普通电脑 CPU 也能跑只是慢一点bge-m3 是智源的文本嵌入模型中文语义匹配效果好适合做知识库向量化。如果你英文场景多也可以换成 llama3.1 和 nomic-embed-text 的组合原理完全相同。4.2 极简代码入库、检索、问答安装好 Python 依赖核心只需要这几个库ollama负责调本地模型chromadb负责本地向量库PyMuPDF负责读 PDF。pip install ollama chromadb pymupdf先做 PDF 读取和简单分块我这里用按字符数硬切的方式方便你理解原理import fitz doc fitz.open(你的文档.pdf) text \n.join(page.get_text() for page in doc) chunk_size 400 overlap 60 chunks [] for i in range(0, len(text), chunk_size - overlap): chunks.append(text[i:i chunk_size])接下来创建 Chroma 集合用 bge-m3 逐块向量化并入库import chromadb import ollama client chromadb.PersistentClient(path./kb_store) collection client.get_or_create_collection( namedemo_kb, metadata{hnsw:space: cosine} ) for idx, chunk in enumerate(chunks): emb ollama.embeddings(modelbge-m3, promptchunk)[embedding] collection.add(ids[str(idx)], embeddings[emb], documents[chunk])检索和问答部分把问题向量化后查库再拼进提示词提交给 qwenquestion 这段文档里提到了哪些关键参数 q_emb ollama.embeddings(modelbge-m3, promptquestion)[embedding] results collection.query(query_embeddings[q_emb], n_results3) context \n\n.join(results[documents][0]) prompt f仅根据以下资料回答问题资料中没有就回答不知道。\n\n资料\n{context}\n\n问题{question} stream ollama.chat( modelqwen2.5:7b, messages[{role: user, content: prompt}], streamTrue, ) for chunk in stream: print(chunk[message][content], end, flushTrue)这一套跑通就是完整的 RAG 闭环。你要做的只是把 PDF 路径换掉、把问题改掉就可以感受整个链路。代码里没有一行是多余的每个模块对应一个概念PyMuPDF 对应文档解析chunk 对应分块ollama.embeddings 对应向量化Chroma 对应向量库ollama.chat 对应最终生成。4.3 这套方案和 Dify 的区别在哪Dify 和这套手搓方案不是替代关系而是理解深度上的递进关系。Dify 是成品车间你按按钮就能流水线生产手搓方案是拧螺丝每个零件你都能摸到。用 Dify 时你看到的是“分段模式”“索引方式”“检索设置”这些按钮但你不明白这些选项背后会发生什么。手搓一次之后再回 Dify 设置 TopK、Score 阈值、Rerank你会瞬间理解每个按钮的用途因为刚才你是在代码层面亲手实现了它们的逻辑。这就是我推荐两条路线都走一遍的原因先可视化跑通再手搓理解原理学习效率最高。成本上也有明显区别。Dify 默认要走 OpenAI 或者你得自己配模型供应商如果你本地跑全套除了电费几乎零成本文档也完全不出机器适合对数据隐私有要求的场景。缺点是本地 7B 模型的能力上限就在那里复杂推理和长篇生成的流畅度不如商业大模型。但作为学习 RAG 原理的工具完全够用了。5. 向量检索到底在搜什么嵌入与余弦相似度的白话版5.1 词汇重叠的陷阱你要问的“向量检索到底在搜什么”我冒昧说一句大多数新手一开始把它想得太玄了。嵌入模型做的事是把一段文字映射成一个几百维到上千维的向量数组。这个数组不是随便生成的它要表达的是这段文字的“语义坐标”。训练时模型见过了海量句子对学会让意思相近的句子在坐标空间里靠得近意思相反的离得远。检索时我们把用户问题也转成向量然后计算它和所有文档块向量的余弦相似度。余弦相似度的直观含义是两个向量的夹角夹角越小越接近数值越接近 1 表示越相关。按分数排序取 TopK就是我们喂给大模型的上下文。但这里有一个非常值得警惕的陷阱嵌入模型捕捉的是“语义相似”不是“词面相似”。很多新手工程师上线后反馈“检索效果差”排查后发现问题出在用户用词和文档用词不一致。比如文档里写“赔偿条款”用户问“理赔规则”两个短语表面没有任何重叠的词但在语义向量空间里它们其实不算太远只是没那么近。这就是为什么纯向量检索召回率会受限简单粗暴用关键词搜索虽然词面匹配精准却又理解不了同义改写。5.2 为什么需要重新排序Rerank既然单靠向量检索不够业界主流的解法是两层漏斗第一层用向量检索或混合检索召回尽量多的候选片段别管精度先保证答案没被漏掉第二层用一个专门的 Rerank 模型逐个对“问题-候选片段”对打分重排之后只保留最高分的两三个。这个思路就像先广撒网捞人再精挑细选找目标比第一轮就直接精确匹配要稳得多。Dify 里如果配置了 Rerank 模型我建议一律打开。本地方案里Hugging Face 上的bge-reranker-base是常用选择它对中文问题效果不错。你可以在检索出 TopK10 的候选块后再用 Rerank 模型重排只取前三。这一步通常会带来肉眼可见的回答质量提升尤其是在文档库大、噪声多的场景。召回率和精确率的平衡是 RAG 调优永恒的主题。召回率低了答案可能根本不在上下文里精确率低了上下文里全是无关信息模型会努力从噪声里找答案结果就是思辨能力差的模型被带偏。理解了这层平衡你再看知识库设置里的各种滑杆就知道每个键在拧什么了。6. 上线之后最常卡住的三个瓶颈6.1 检索不到或检索跑偏这是知识库上线后最普遍的抱怨。我建议按这样的顺序排查别一上来就怪模型。先看分块尺寸。之前有项目文档每块切了 2000 字符里面塞了四五个主题查询内容只占其中一小句向量相似度被大量无关内容拉低排到了 TopK 之外用户自然得到错误回答。把块调到 300 到 500 字符并加重叠后问题立刻缓解。如果你的文档结构很清晰按章节切分比固定窗口更优。再看 TopK。块太小、知识库太大时可能相关片段跨了三四个块TopK2 就漏了。适当调到 5 或 6。但 TopK 不是越大越好TopK 过大塞进提示词的噪声也多模型容易被无关片段干扰。最后检查 Score 阈值和重排如果检索结果里明显有低分垃圾片断混进来提高阈值或加 Rerank 过滤。6.2 多轮对话中的提问歧义第二个坑来自对话场景。用户第一轮问“Q3 收入是多少”第二轮接着问“那毛利率呢”如果直接把第二轮问题拿去向量检索“毛利率”这个词太宽泛检索到的片段五花八门答案质量可想而知。正确的做法是在进行向量检索之前先把“当前轮问题 最近几轮对话历史”交给大模型做一次查询改写Query Rewrite变成“在 Q3 财报背景下毛利率是多少”再拿改写后的完整问题去检索。Dify 的聊天助手在“对话轮次”或模型 Prompt 里可以融入历史消息但你需要显式告诉模型把检索词补全。本地方案的话可以在对话模型前加一步改写。这个小改动能把“连续对话越说越糊涂”的问题解决掉大半。6.3 图片、扫描件、表格到底怎么进知识库关键词里有一条“rag 知识库能存储图片嘛”被问到的频率非常高。我明确回答能但要分清形式。常规 RAG 的向量库里存的是文本块的嵌入向量你不能直接把一张 JPG 塞进去指望模型“看一眼”再回答。图片要进知识库有两条路。第一条路是把图片当成“文本的补充”先用视觉语言模型做图像理解把图里的内容转成描述文字然后把描述文字入库。这样的信息对检索任务是友好的代价是可能丢失图片里精细的细节。第二条路是做多模态 RAG用 CLIP 这类图文对齐模型分别编码图片和文字统一存进支持多模态向量的向量库查询时同时匹配图文特征。这条路技术门槛稍高属于进阶玩法。对零基础入门者我的建议是全统一走第一条路先文本化再入库简单且有效。扫描版 PDF 本质上也是这个思路OCR 识别成文字再入库。表格则可以走前面说的“把每行组装成句子”的结构化方案。记住一句话知识库是你给模型准备的参考资料库它需要的是能被检索、被拼接的文本片段任何非文本内容都要先转成“可读的句子”。7. 完整学习路线四阶段从复现到改造再到深入7.1 阶段怎么排第一周目标只有一个复现。用 Dify 跑通一个能回答 PDF 内容的聊天机器人上传三五份不同风格的 PDF观察自动分段和检索效果。不要碰代码不要纠结原理先建立“输入文档到对话提问”的完整体验。第二周动手改。沿着第四章的代码把最小实现跑通然后改三件事换不同分块大小看检索变化换不同嵌入模型对比效果在 Prompt 里加“只基于资料回答”前后看结果差异。这些实验会把你从“会用 Dify”推向“懂 RAG”。第三周研究检索质量。可以开始给自己的知识库准备 20 个“问题-期望答案”对每次调整参数后都跑一遍全量测试记录回答正确率。这一步很重要它能让你意识到调优不是玄学是数据驱动的迭代。如果追求专业可以引入 RAGAS 这类框架做检索质量评估但手工测试对起步阶段完全够用。第四周之后就想清楚下一步的技术方向。如果文档之间有很强的关联关系比如企业制度体系、产品说明书嵌套引用可以看看 Graph RAG 和 ontology RAG也就是把知识库里实体之间的关系也建出来检索时按关系链路去扩展。如果你的应用需要自主完成任务比如查完知识库后还能去调用工具那就进入 AI Agent 的领域。这些方向都可以从社区里的开源项目入手学习和改造。7.2 关于模型选型的一些话整个学习过程中你一定会反复面临“该用哪个模型”的选择。我的建议是对话模型选你顺手的就行质量差距往往在检索环节被放大了模型反而是相对次要的因素。嵌入模型偏重要选适合中文的bge-m3 系列是不错的起点。如果预算有限或在意隐私Qwen 全家桶加 Ollama 本地部署能覆盖绝大多数场景。刚开始练手别急着接 GPT-4 或者最强的商业模型也别盲目追求最庞大的本地模型。选一个跑得动、中文效果尚可的对话模型跑通流程把精力优先放在文档解析和检索质量上。等到你的知识库在“百问百答”测试里的正确率超过八成再考虑升级模型能力你会发现自己那时已经能清晰地判断模型好坏而不是靠别人的测评文章做决定。7.3 我的习惯最后分享一个我自己的习惯每次做好一套知识库我会专门用一个文档记录调试过程。上传了什么文件、用的什么分块参数、TopK 设了多少、Score 阈值调成什么、哪些问题曾经回答错误、怎么改的。看上去像流水账但过一个月回来当别人反馈“这里又答错了”的时候这份记录能让你三分钟内定位到当时的思路而不是从头推演一遍。AI 知识库这个方向最值钱的从来不是第一次跑通而是你针对自己的资料做的那一轮轮可复现的调优这些记录就是你个人的经验资产。从“把 PDF 拖进对话框”到“搭建一个真正能办事的知识库应用”中间差的不是模型而是这条完整的工程链路。今天这篇文章把链路和踩坑的点都摆在明面上了接下来就轮到你动手跑第一遍。跑通之后你会觉得它没那么神秘但一定比想象中有趣得多。