说实话这两年“AI 知识库”这个词几乎被聊烂了好像不提 RAG 就不是搞 AI 的。但真上手你会发现多数教程要么贴一段 LangChain 代码让你自己跑要么扔给你一个 Dify 让你点按钮卡在“知道概念但做不出来”和“做出来了但效果稀烂”之间的朋友占绝大多数。我最初入坑时也是从“手头一堆 PDF 文档不知道怎么喂给 AI”开始的。当时市面上还没有现在这么多可视化工具踩了大半个月的坑才把从 PDF 解析、文本切片、向量化、检索到最终问答的整条链路跑通。这篇就把这条路线从头捋一遍尽量按零基础能复现的标准来写适合刚接触 RAG、被各种名词绕晕、准备给团队做内部知识库的读者。1. 入门之前先把 RAG 的思路搞明白很多人一上来就问“RAG 用什么框架”我建议先别急。框架只是最后一步的搬运工你连“为什么要用 RAG”和“RAG 到底分几步”都没谱的话后面每一步做出来都是歪的。1.1 RAG 到底解决什么问题RAG 全称是 Retrieval-Augmented Generation检索增强生成。拆开看就是“先把知识找出来再让大模型看着答案说”。普通聊天模型的知识停留在训练截止日期那一刻今天你刚拿到的产品手册、公司制度、技术文档它一概不知道。过去很多团队为了让它“知道”会去微调模型贵且慢改一次文档就要重新训练一次性价比极低。RAG 的思路则是把知识外置。你处理好的文档切片被存进向量数据库用户提问时系统先去库里检索最相关的几段文本把它们拼进提示词再交给大模型做总结回答。模型不需要“背”你的文档它只负责“顺着你给的资料说话”。这样既能回答新知识又不用重训模型换文档只需要更新知识库。这个“先检索、后生成”的模式就是整套 AI 知识库的地基。后面所有工作——PDF 解析、切片、Embedding、向量库选型、检索策略——都是在为“检索更准、生成更稳”服务。1.2 RAG 与微调的分工别一开始就想歪零基础最常见的一个误区是想用微调解决知识缺失。我见过有人把上百页 PDF 丢给模型微调结果既没学会内容还出现了幻觉。为什么微调适合纠正模型的说话方式、输出格式、特定风格不适合喂新事实。模型参数大小有限塞不下你几千页的规章制度即使硬塞进去也会遗忘这就是所谓“灾难性遗忘”。RAG 的定位是“外部记忆”微调的定位是“行为调教”两者是互补关系。入门阶段除非你要让模型变成特定角色去对话否则一律先做 RAG等 RAG 效果稳定后再考虑是否用微调做辅助。2. 第一关处理 PDF 是最容易被低估的环节标题里专门点出“从上传 PDF 开始”是因为 PDF 解析是整套 RAG 链路里最脏最累、也最影响最终效果的环节。很多人把 PDF 拖进知识库就完事结果回答时模型东拼西凑、找错页码根本原因就是源头解析坏了。2.1 PDF 远没有你想象的那么好解析PDF 本质上是一个“版面描述格式”它记录的是每个字符、每条线、每张图放在页面什么位置而不是像 Word 或 Markdown 那样有清晰的段落结构。这意味着“把 PDF 里的文字提取出来”这件事本身就不是一行代码能搞定的。实际工作中 PDF 大致分两类。第一类是文本型 PDF文字可以直接选中复制通常是 Word 打印或 LaTeX 生成的第二类是扫描件 PDF本质就是一张张图片文字是像素不是字符必须靠 OCR 识别。这两种的处理路径完全不同。我见过最坑的情况是一份 PDF 看起来是文本型但某些页是扫描合成的提取出来的内容一半正常一半乱码。所以第一步永远是“抽几页试试水”别拿整份文件直接灌进流水线。2.2 文本型 PDF 的解析工具与取舍如果是文本型 PDFPython 生态里常见的工具是 PyMuPDFfitz、pdfplumber、pypdf 三件套。直接说结论通用场景首选 PyMuPDF速度快对中文支持也算稳定需要保留表格信息的场景用 pdfplumber它能识别单元格和行列结构。import fitz # PyMuPDF def extract_text_from_pdf(pdf_path): doc fitz.open(pdf_path) full_text [] for page in doc: full_text.append(page.get_text()) return \n.join(full_text) text extract_text_from_pdf(员工手册.pdf) print(text[:500])这段代码跑通之后要留意 PyMuPDF 提取到的文本是按页面输出的版式复杂的 PDF 可能会出现段落顺序错乱。比如两栏排版的文档提取后左侧一栏和右侧一栏会交错在一起先左后右还好遇到多栏错位就只能换 pdfplumber 或下一步按块级元素处理。实操的时候我一般还会做一步“清洗”把所有全角/半角空格统一、把连续换行压缩成段落分隔符、剔除页眉页脚。页眉页脚是检索时的大毒瘤如果知识库里 200 个文档都带着“第 x 页 共 y 页”和公司名检索结果相关性会被这些噪声带偏。2.3 扫描件和表格图怎么办扫描件必须进 OCR。现在开源方案里 PaddleOCR 算是效果最好的之一CPU 也能跑只是慢。如果文件量大我建议优先用 PaddleOCR 的 PP-Structure 系列它能输出版面分析结果识别标题、表格、正文区域比单纯抽文字强很多。表格是个特殊存在。纯文本提取的表格会变成一行行无结构文字模型看着费劲检索质量也差。有两个处理思路一是用 pdfplumber 提取表格结构后保留为 Markdown 表格格式喂给模型时让它直接读二是把表格区域截图保存为图片依赖多模态大模型去读。前一种方案兼容性好后一种方案在表格复杂时效果更好。这里提醒一句解析环节千万别只做一次。我在做公司知识库时不同部门交上来的 PDF 模板五花八门有 PPT 导出的有 CAD 图纸打印的有高拍仪扫描的没有一个统一解析策略能通吃。稳妥的做法是先抽样 20 份不同类型的文档人工检查解析结果再决定按哪条处理路径走。3. 知识库的核心三件套切片、向量化与检索PDF 处理完你得到了一批干净文本。接下来要把这批文本变成可供大模型使用的“知识单元”。这个阶段的核心操作可以拆成三步切片、Embedding 向量化、写入向量库并检索。3.1 切片策略决定召回质量的第一块多米诺骨牌切片就是把长文本裁成小块。很多人觉得这步无所谓随便按 500 字切一刀就行。但切片大小和策略直接决定检索的召回准确率。先说一个反直觉的结论切片不是越小越好。零基础的朋友常以为块越小、语义越精确实际上如果切得太碎一个问题对应的信息被拆成好几块检索只召回其中一块模型看到的上下文就缺了一半回答自然残缺。切片太大则带来另一个问题比如一整章内容塞进一个块里面三分之一是废话Embedding 向量会被噪声稀释相关性得分被拉低而模型处理超长文本的 token 成本也高。我常用的切片策略分两种。一种是把按标题层级分割的章节直接作为切片单元因为自然段落天然语义完整另一种是固定大小加重叠窗口比如每块 500 个字符、重叠 100 个字符保证跨块语义不割裂。Dify 这类可视化工具里有一个 “分段标识符”设置默认是 \n\n你可以额外指定 ## 或 第X章 这类标题前缀让系统优先按标题切。一个具体建议技术文档、规章制度这类结构清晰的文档优先按标题切对话记录、新闻资讯这类分段明确的按段落切没有明显边界的杂文再退回到固定大小切片。3.2 Embedding 模型怎么选切片完成之后每块文本要被转化为一串浮点数也就是向量。这个转化动作依赖 Embedding 模型它决定了“语义上的相似”能不能被计算出来。面向中文场景选择 Embedding 模型要考虑三个问题中文效果、部署成本、和你的主模型兼容性。如果用国外闭源 APIOpenAI 的 text-embedding-3-small 对中文支持尚可但部分垂直行业术语识别一般如果追求中文效果BGE 系列BAAI/bge-large-zh-v1.5、M3Emoka-ai/m3e-large都是开源选择效果不输商业 API还可以本地部署。我这段时间做本地知识库用的是 Ollama 拉取 bge-m3 模型操作很简单一行命令就能把模型跑起来通过 HTTP 接口调用即可。这个方案特别适合零基础读者不用去申请各种 API key不用处理支付装个 Ollama 就能全链路跑通。需要强调主 LLM 和 Embedding 模型是两个不同的模型别混为一谈。我在项目里常看到新手用一个模型既做对话又做向量化虽然能跑但检索效果往往打折扣因为对话模型和向量模型的训练目标完全不同。3.3 向量库与检索语义检索不是万能的向量化完成后这些向量会写入向量数据库。常见的开源选择有 Chroma轻量级适合入门、Qdrant功能全面、Milvus适合大规模生产、以及关系型数据库里的 pgvector适合已有 PostgreSQL 的场景。零基础入门阶段我建议直接用 Chroma它的 API 简单到可以当 Python 库用安装即可启动不需要单独部署服务。import chromadb client chromadb.PersistentClient(path./kb_store) collection client.get_or_create_collection(my_manual) collection.add( ids[chunk_001, chunk_002], embeddings[[0.1, 0.2, ...], [0.3, 0.4, ...]], # 你算出的向量 documents[切片1的内容, 切片2的内容], metadatas[{source: 员工手册.pdf}, {source: 员工手册.pdf}] )检索阶段最常见的问题是“语义检索不是万能的”。Embedding 模型理解语义相似但它是把整句话压缩成一个向量关键词精确匹配能力很弱。比如用户问“2024 年报销流程”如果知识库里写的是“费用报销的审批步骤”语义上能检索到但如果用户问的是特定编号“XG-2024-01”语义向量就很难精确命中因为向量模型更擅长理解“意思”而非“字符”。所以真正靠谱的知识库通常会在语义检索之外加一层关键词检索把精确匹配和语义匹配结果做一个加权融合。Dify 里的 “混合检索” 选项就是这个原理。这也是为什么我特别强调别一上来就迷信“大模型什么都能理解”混合检索是实现可用知识库的关键细节。4. 两条实操路线Dify 图形化 vs 本地代码理解了原理之后就看你要走哪条落地路线了。我给零基础读者的建议非常直接如果你只想快速做出一个能用的知识库先用 Dify如果你是想真正理解内部原理再亲手写一套本地 RAG。两条路我都走过各自优缺点下面说透。4.1 路线一用 Dify 在网页上搭一条完整流水线Dify 是一个开源的大模型应用开发平台它把知识库、Prompt 编排、模型管理、应用发布全部做成了可视化界面。你不需要写一行代码只要按顺序点击配置就能完成从上传 PDF 到问答应用的全流程。操作步骤如下部署 Dify可以用 Docker Compose 一键拉起进入工作台。创建“知识库”新建数据集把 PDF 拖进去。设置分段标识符和最大分段长度Dify 会自动完成切片。配置 Embedding 模型这一步选择你上一步定的模型。索引完成后创建一个“聊天助手”类型的应用关联刚才的知识库。在应用设置里选好生成模型开启“引用和归属”功能提问测试。这个路线最大的价值是让你在十分钟内看到完整 RAG 效果。而且 Dify 的默认参数已经比较合理适合零基础跑通第一版。我用它给一个团队做过内部制度问答从上传文档到上线只花了一个下午速度非常可观。提示Dify 知识库建立后底层会自动创建索引任务如果文档较多排队等待是正常现象不用反复刷新或重复上传。4.2 路线二Python Ollama 本地搭建最小可运行 RAG如果你是开发背景或者想彻底摸清每个环节我强烈建议走一遍本地代码路线。不用 LangChain 全家桶用几段核心代码把原理串起来效果最直观。整个流程可以拆成四段代码PDF 解析上一章讲过、切片、向量化、检索问答。切片后用 Ollama 的 Embedding 接口把每个切片转成向量ollama pull bge-m3import requests import json def embed_text(text): resp requests.post( http://localhost:11434/api/embeddings, json{model: bge-m3, prompt: text} ) return resp.json()[embedding] chunk_vectors [embed_text(chunk) for chunk in chunks]然后存进 Chroma查的时候同样把问题转成向量再取最相似的几个切片拼接到提示词里from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) def ask_question(question): q_vec embed_text(question) results collection.query(query_embeddings[q_vec], n_results3) context \n\n.join(results[documents][0]) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你只能依据提供的资料回答资料中没有的内容要明确说不知道。}, {role: user, content: f资料如下\n{context}\n\n问题{question}} ] ) return response.choices[0].message.content我在本地用 qwen2.5:7b 加 bge-m3 跑过几百条真实问答回答质量足以应对一般内部文档查询。这套方案的全部依赖就是 Ollama 和两份 Python 脚本非常适合零基础当作“毕业项目”来练手。4.3 图片能不能进 RAG 知识库很多人会问“RAG 知识库能存储图片吗”。直接说结论常规 RAG 流程本身处理不了图片但可以通过两种方式绕过去。第一种是图片文字化。如果图片里主要是文字信息比如截图、扫描件先让 OCR 识别成文本再进知识库第二种是多模态化。把图片按路径保存进知识库的元数据里问答时先检索到对应文本再把图片路径丢给支持视觉的大模型去理解。我见过一个做“产品宣传图知识库”的方案就是先把图片说明文字做索引检索结果附带图片 URL前端把它显示出来。这种方式用户感知上就是“知识库能查图片”实际后端仍是文本检索为主。总之纯图库不适合用 RAG 做RAG 的核心始终是文本语义。5. 踩坑排查与实测经验这条路线看起来清晰但实际执行中会冒出一堆零散问题。我把这几个月里反复踩过、也帮朋友排查过的坑集中列出来按频率排序。5.1 PDF 解析乱码和丢内容的排查症状是知识库里有文档但问答时引用内容驴唇不对马嘴或者干脆搜不到。这类问题 80% 出在 PDF 解析阶段。排查顺序很重要。第一先手动打开 PDF确认是否扫描件——扫描件没 OCR 直接进知识库等于让知识库“读书却不识字”。第二用代码提取一段文本肉眼检查是否有大量空格、换行错乱、乱码。第三查看页眉页脚是否混入了正文切片如果有在预处理里加排除规则。我之前遇到过一个特殊案例某文档用特殊字体嵌入PyMuPDF 提取正常但单独提取某些字符时顺序错乱。后来发现需要按“字符在页面上的坐标”排序而不是按 PDF 内部顺序输出。这个场景用 pdfplumber 的 extract_words 然后按坐标排序就能解决。5.2 检索召回差、答非所问的排查如果解析没问题但模型总答非所问问题多数出在检索环节。我排查的思路如下先看召回结果。把用户问题喂进去看看被检索到的 top3 切片内容是否相关。如果不相关就是 Embedding 或切片出问题了如果相关但回答不对就是提示词拼写或模型理解的问题。再调整切片长度。切片太长会让向量特征被稀释太短会让信息碎片化试着把长度从 1000 字符降到 500 字符对比效果。最后考虑混合检索。如果专有名词、编号、型号出现频率高一定要开关键词权重Dify 里勾选混合检索本地代码就加一层 BM25 检索做融合。5.3 关于 Dify 知识库排队中的亲历记录在线编辑场景下Dify 上传文档后偶尔会卡在“排队中”状态。遇到这个情况先别慌看两处一是是否开启了索引模式但 Embedding 模型 API 限流如果限流就稍等或换模型二是文档格式是否正常某些加密 PDF 会导致解析进程挂起。我实测下来批量上传大文件时常遇到排队卡住最终解决办法是一次别传太多分批上传建立索引。Dify 的索引服务对并发支持一般大文件建议控制在单份 20MB 以内太大就先用工具拆分 PDF 再传。5.4 其他容易被忽略的小坑提示词里忘了约束“只能根据资料回答”。没这句话模型会放飞自我编造知识库中不存在的内容。知识库规模很小时语义检索的得分差异不明显导致每次召回结果随机性大。解决方法是把 top_k 调大比如 5~8 个切片让模型自己筛选有用信息。切片里的重复内容会在召回时被重复引用白白消耗 token。清洗阶段可以跑一遍简单去重相同的段落只保留一份。RAG 的效果和主模型能力强相关。知识库检索再准如果主模型是那种只会复述原文的小模型回答仍然很生硬。预算允许的话至少选 7B 以上参数量的模型。6. 给零基础的完整学习路线速查看完前五章你脑子里应该已经有一条完整链路了。我用这套方法带过几个零基础入门的朋友按下面的顺序安排学习基本两周内都能做出自己的知识库应用。6.1 按周拆解的学习进度安排第一周重点在概念和工具手感。先用 Dify 或类似可视化平台跑通“上传 PDF → 提问 → 出答案”的最小闭环。这个阶段不求理解代码只求建立“知识库原来是这样工作”的整体感知。同时看几篇 RAG 原理文章把检索、Embedding、向量库这几个名词的基本含义搞清楚。第二周开始动手写代码。按第五章的方案装 Ollama把两套模型跑起来写一个最小的 Python 脚本完成“解析-切片-向量化-检索”的调用。这里不要求写得多规范能跑就行。跑通后试着换不同切片长度和不同文档对比问答效果。第三周可以深入某个环节做优化。比如把 PDF 解析工具从 PyMuPDF 换成 pdfplumber感受表格提取差异或者给检索加一个 BM25 混合层看精确命中是否变好。到这个阶段你已经不是零基础了你已经能判断别人的教程写得好不好、自己的知识库问题出在哪。6.2 一些个人体会最后说点偏主观的经验。我发现很多零基础的人包括当初的我卡住不是因为智商不够或资料太少而是因为教程给得太完美。网上那些“三步搭建企业级知识库”的帖子往往省略了 PDF 解析、切片调参、检索评估这些脏活。实际上RAG 这个技术本身就是 20% 模型代码加 80% 数据处理你把 PDF 处理好、切片切对、召回调好应用效果已经超过大多数半吊子项目。关于学习材料我的建议是少看博客多读官方文档。Dify 的文档和 Ollama 的文档都写得不错跟着做比搬运二手代码强。遇到问题不要急着发帖问先把报错信息拆开看大概率是依赖版本冲突或者路径不对。自己排查一次收获比看十篇文章大得多。这个方向后续还能扩展的地方很多比如给知识库加权限管理、做文档版本更新提醒、接入企业微信机器人、用 Agent 串联多个工具。但不管扩展多少地基始终是那三件事干净的数据、合理的切片、可靠的检索。把这三件事做扎实你就已经站在多数人前面了。