零基础搭建RAG知识库：从PDF解析到智能问答全流程

先抛一个场景你桌面上堆着几十份 PDF产品手册、行业报告、公司制度、技术文档平时找信息全靠 CtrlF翻半天还不一定找得到。后来我搭了一个基于 RAG 的个人知识库把 PDF 全部丢进去用一句话提问就能直接把原文捞出来再让大模型组织成答案附带出处。这个听起来很高级的东西其实零基础也能上手我在这个学习路线上踩过不少坑今天把它完整分享给你从上传第一份 PDF 开始一直到搭出一个能回答问题的 RAG 系统。这篇内容会覆盖文档解析、文本分块、向量化、检索、生成这整条链路中间穿插我的实操过程和排错经验适合完全没接触过 RAG 的小白也适合后端或数据岗位想快速上手 AI 知识库的同学。我会尽量说人话每个环节都给可复现的代码和选择理由让你不但能跑通还能知道每一步为什么这么做。1. 先搞懂 AI 知识库和 RAG 到底是啥1.1 用一个例子讲透 RAG 的完整工作过程先不说术语想一个场景。你是一家公司的 HR手头有一份 200 页的员工手册 PDF。有人问你年假制度怎么规定的你肯定不会傻背整本书而是先在手册里找到年假附近的段落读一遍再用自己的话复述出来。RAG 干的就是这件事只不过找和复述都被自动化了。RAG 全称是 Retrieval-Augmented Generation中文叫检索增强生成。它由两个阶段组成第一阶段是检索根据用户提问在现有文档库里找出最相关的几段原文第二阶段是生成把这些原文片段作为参考资料交给大语言模型也就是 ChatGPT 这类模型组织成流畅答案。第一阶段解决知识从哪来第二阶段解决话怎么说好合起来就是一条完整的 AI 知识库问答链路。这套思路解决了一个很实际的问题大模型训练完之后知识就定格了你问它 2025 年发布的新规、你公司内部特有的制度、某款产品的独有参数它要么答不上来要么一本正经地胡编。而 RAG 让模型在面对问题时多了一步现查资料这相当于给它配了一本可以随时翻的字典知识不再是固定的而是可以持续更新和扩展的。1.2 为什么说 RAG 是当前做知识库的最佳路线之一很多人会问想做大模型知识库除了 RAG 不是还有微调、还有直接一次性把 PDF 全塞进上下文吗这几个方案我都试过可以给你对比一下。直接全文塞进上下文是最原始的办法操作简单把 PDF 内容拼到问题后面发给大模型就行。但大模型的上下文窗口是有限度的几千页文档塞不进去勉强塞进去指令跟随质量也会急剧下降这相当于让一个人看完 500 页书之后马上精确回忆某个角落的细节还不允许他翻书结果可想而知。微调呢则是用大量数据去更新模型本身的参数说人话就是让模型记住知识。但微调需要高质量数据标注、显存和大量训练时间而且知识更新一次就得重训练一次在文档经常变更的知识库场景里性价比非常低。RAG 的优势在于它把这个事拆开了知识存外置数据库模型只管理解语言和生成答案。知识更新的时候只需要处理增量文档不用动模型本身。而且 RAG 回答的时候能吐出来源引用这个对我们后续排查问题、建立信任非常重要——你可以实际看到模型是依据哪段原文回答的而不是凭空想象。所以现阶段做文档问答、企业知识库、客服机器人这类需求RAG 是投入产出比最高、上手速度最快的一条路。1.3 从 PDF 到知识库的完整数据链路既然要学习脑子里得先有一幅全景图。我把整个 RAG 知识库拆成两条链路来看理解起来非常轻松。第一条是离线数据准备链路简单说就是把 PDF 变成能被检索的索引。PDF 文件先被解析成纯文本做完清洗去掉页眉页脚、乱码、多余空格然后按一定长度切成一个个小文本块每个文本块通过嵌入模型转换成一个高维向量最后把向量和原文一起写入向量数据库。这个过程是离线的文档不变化的时候跑一次就行。第二条是在线问答链路就是用户提问到返回答案。用户输入问题后同样用同一个嵌入模型把问题转换成向量在向量数据库里做相似度搜索找出最接近问题语义的几个文本块把这些文本块作为上下文连同用户问题一起组装成一个 Prompt 发送给大语言模型大模型基于这些证据生成最终答案并附带引用来源。这两条链路就是 RAG 的全部骨架后面的所有学习本质上都是在给这两条链路上每个环节做精细化调优。2. 零基础学习路线先备好这些武器2.1 环境准备这一套配置够你用半年作为零基础起步我不建议一上来就折腾本地大模型、买显卡。真正适合的学习环境是一台普通笔记本电脑8G 内存以上、Python 3.9、一个代码编辑器VS Code 或者 Jupyter 都行再加上能访问的大模型 API 服务。这套配置成本极低但如果希望全本地化可用 Ollama 等工具跑小模型后续我会专门解释怎么替换。依赖安装这一步你只需要在终端里运行pip install langchain langchain-openai chromadb pypdf openai这几个库的分工很明确pypdf 负责把 PDF 解析成文本chromadb 是轻量级向量数据库langchain 用来把分块、向量化、检索、生成串成一条流水线openai 负责调用嵌入模型和大语言模型。第一次跑通的情况下建议用云 API 起步先不要纠结成本按量付费的 API 跑小体量知识库花不了几块钱却能让你跳过最痛苦的模型部署阶段把注意力全放在理解 RAG 流程上。2.2 四阶段学习法每一步都在为下一步铺路我给零基础的朋友规划了一条四阶段学习路线每个阶段目标非常具体完成后你会有非常强的掌控感。阶段一是会调用大模型 API。这个阶段不碰任何知识库概念就是学会把一段文本发给大模型拿到返回结果。目的是熟悉输入输出的基本交互模式以及 Prompt 的基本写法。我见过太多人直接跳到阶段四结果报错都不知道该查哪一环就是因为缺了这种基础体感。阶段二是会做文档解析。目标是把一份 PDF 变成干净的纯文本打开终端能看到文本被打印出来。这个阶段你会遇到文本错乱、乱码、页眉页脚干扰等问题解决完这些问题你对数据质量决定结果质量会有切身体会。阶段三是会做向量化与检索。目标是写一个小程序输入一个问题它能在你的文档里找出最相关的片段并打印出来。这是 RAG 的核心魔法也是大部分人最容易卡壳的地方我已经准备了详细讲解。当你亲眼看到语义相近的句子能被向量找出来时之前所有抽象概念都会落地。阶段四是会串 RAG 问答。把阶段二、三的结果和大模型拼接起来用一条流水线完成整个问答再花时间优化。这四个阶段环环相扣每步都是下一步的前置依赖缺了哪一块后面出问题你都不知道从哪排查。2.3 工具选型对比先跑通再升级工具选型的核心原则是能跑通就行不用一步到位选最复杂的。我在多个方案里反复横跳之后给不同环节选了入门组合先看表格感受一下环节入门推荐进阶可选选型理由PDF 解析pypdf / PyMuPDFunstructured / marker / PaddleOCR入门先用简单方案复杂文档再上版面分析嵌入模型OpenAI text-embedding-3-smallBGE / bge-m3 / 本地 embedding云 API 效果稳定本地模型省成本但初期调参费劲向量数据库Chroma本地文件型Milvus / qdrant / pgvector入门不折腾部署一个 pip install 就能用大模型OpenAI GPT 系列或同类云 API本地 Ollama 开源模型云 API 响应快、效果好先把链路跑起来再说编排框架LangChainLlamaIndex / 手写流程LangChain 生态成熟教程多索引和问答都有现成组件我的建议是第一版知识库全部选表格里入门推荐那一列花一个下午把它跑通。跑通之后再根据自己的业务场景逐个环节换成进阶可选方案。我见过太多朋友一开始就纠结向量数据库选哪家、嵌入模型用哪个结果一周下来连 PDF 还没读进程序里。正确的顺序永远是把系统立起来再谈优化。3. 文档解析从 PDF 到干净文本的第一场硬仗3.1 为什么 PDF 解析是个麻烦事很多新手第一次做知识库最轻视的就是 PDF 解析这可以说是第一个大坑。PDF 这个格式很特殊它的设计目标是保证打印和显示效果一致文件里记录的是一堆字符画在哪、字体多大、位置在哪而不是句子和段落的逻辑结构。这就像别人给你一张扫描版的报纸图片你能看到字但想把这些字复制成文本文档就需要做 OCR 识别。基于这个特性PDF 解析有至少三条技术路线我分别说一下适用场景。路线一是文本抽取代表工具是 pypdf 和 PyMuPDF。它们直接把 PDF 内部已经编码好的文本抠出来速度快、使用简单但只适用于本身带文字层的 PDF也就是那种鼠标能选中文字的电子版。大部分用 Word/WPS 导出的 PDF或者网页打印生成的 PDF都属于这一类。路线二是版面分析代表工具是 unstructured、marker 这类。它们不仅能抽取文字还能识别标题、段落、表格、页眉页脚等结构。这对于产品说明书、学术论文这类布局复杂的文档非常有必要。代价是要么调用云服务要么本地模型较重首次上手有一定门槛。路线三是 OCR 识别代表工具是 PaddleOCR。PDF 实际上全是扫描图片根本没有文字层鼠标选中不了任何文字就必须走 OCR。中文扫描件还需要额外注意语言模型配置我在热词记录里就看到不少朋友在问pdf 图片中文设置其实就是 OCR 的中文模型参数这个我们后面讲。实操建议新拿到一份 PDF第一步在阅读器里尝试用鼠标选文字能选中直接走路线一选不中走路线三。如果你文档复杂且表格很多再升级到路线二。不要一上来就上最重的工具我用 pypdf 处理过 90% 的常规文档完全够用。3.2 实操用 Python 读取 PDF 并清洗文本直接上代码这段代码非常简单但已经是知识库数据准备的第一环from pypdf import PdfReader reader PdfReader(员工手册.pdf) print(fPDF 共 {len(reader.pages)} 页) all_text [] for i, page in enumerate(reader.pages): text page.extract_text() or all_text.append(f--- 第 {i1} 页 ---\n{text}) full_text \n.join(all_text) print(full_text[:2000])打印出来之后你会发现原始文本往往有大量空白、换行错乱、分页符、页眉页脚甚至还有莫名其妙的乱码。这些脏数据如果直接进入知识库会产生大量垃圾向量后续检索时它们会被当噪声捞出来干扰最终答案。所以解析后的清洗不可跳过你需要至少做这几件事import re def clean_text(text: str) - str: # 去掉首尾空白 text text.strip() # 把多个空白字符/换行压缩成一个空格 text re.sub(r\s, , text) # 去掉常见的页眉页脚垃圾词按需调整 text text.replace(第 1 页 共 20 页, ).replace(公司内部资料, ) return text cleaned_pages [clean_text(p.extract_text() or ) for p in reader.pages]这里要特别提醒一点页眉页脚如果不清理会在每个 chunk 里重复出现等于给向量数据库灌了大量一模一样的高频噪声。我做第一个版本时懒得清洗结果用户问公司愿景根本答不准因为知识库前 50 个最相似的片段全是重复的页眉文字。清洗这一步虽然枯燥但对检索质量的影响非常直接。3.3 PDF 里的图片和表格怎么处理顺着前面提到的rag 知识库能存储图片嘛这个问题往下说。很多 PDF 的精华内容在图片和表格里比如架构图、流程图、数据表。如果只做文本抽取这些内容就会全部丢失导致后续问答明明 PDF 里有这个信息系统却答不上来。我分三类情况给出处理建议。先说扫描件里的文本图片比如印章、截图里的文字处理方式是 OCR 识别把图片文字转成可检索的文本再进行入库。再说真正的信息型图片比如流程图、产品照片处理方式是先用多模态模型或人工写一段对图片的中文描述这段描述就是图片的知识如果知识库是纯文本向量库就得用这种图片转描述的方案。最后说表格处理方式是转成 Markdown 格式或键值结构实验下来检索效果最好的是把表格转成表头值的文本形式因为表格本身以二维布局存储直接抽取容易变成混乱的流水文本反而损坏语义。我自己处理过一份带大量图表的产品白皮书最初走 pypdf 抽取发现图片全丢、表格变成一堆数字大杂烩。后来花了一个小时把关键图表用 PaddleOCR 抽取文字形成图注文本描述把表格转成参数数值的文本塞回知识库后问答准确率有明显提升。所以结论是知识库当然可以间接存储图片关键是变成文字进入向量体系真正让多模态向量直接支撑检索目前成本太高对零基础做入门项目没有性价比优势。4. 文本分块为什么不能把整篇 PDF 直接塞进向量库4.1 检索粒度决定命中率走过解析这关你已经有了整份 PDF 的纯文本。下一个问题是能不能把这整份文本一股脑变成一个向量存进数据库我吃过这个亏直接告诉你答案不行至少效果非常差。原因在于检索单元的粗细。一份 200 页的员工手册如果整篇变成一个向量那么用户问年假制度系统拿这个问题的向量去和手册向量做相似度计算结果是整本手册和年假问题之间的相似度根本分不清具体是第几章的内容等于大海捞针。如果我们把手册切成若干个小段落比如 500 字一块每一块都是一个独立的向量那么年假制度对应的那个块就会被精准捞出来。这个过程就是信息检索里常说的检索粒度粒度越小越精准但太小又会丢失上下文。4.2 分块策略对比与关键参数分块不是单纯切文本需要考虑语义完整性。常用的策略有三种我给它们排个序。最简单的是固定长度切块按 token 数或字符数硬切比如每 500 个 token 切一段。优点是实现简单缺点是可能把一个完整的制度条款从中间劈开导致每半个都不完整检索到了也答不对。中间路线是递归字符切分代表实现是 LangChain 的 RecursiveCharacterTextSplitter。它先按段落分隔符如换行切如果某段太长再按标点、空格逐级细化。相比硬切它能尽量保住段落结构是文本型文档的默认选择。更复杂的方案是按语义边界切例如利用文档标题、表格结构、主题模型来智能切分代表工具是 unstrctured 的章节感知分块。对于有清晰章节的 PDF 效果好但零基础阶段不用强求。无论哪个策略你都会碰到两个参数chunk_size 和 chunk_overlap。chunk_size 决定每一块多大chunk_overlap 决定相邻两块之间有多少字符是重叠的。overlap 的存在是为了兜底当一句完整的话正好跨在两个块的边界上时没有 overlap 就会把这句完整语义从中间截断有重叠区域就能保证关键句子至少在某个块里是完整的。我实际使用下来中文场景用一个相对合理的组合是chunk_size 取 500 到 800按 token 计算overlap 取 50 到 100。4.3 实操用 LangChain 文本分隔器实现代码如下非常直观from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, length_functionlen, separators[\n\n, \n, 。, , , , ], ) chunks text_splitter.split_text(full_text) print(f切分后共 {len(chunks)} 个文本块) print(chunks[0][:300])这里需要注意的是分隔符顺序。我给的顺序是先按段落之间的空行切不行再按单换行再按句号、感叹号、问号最后实在不行才按空格硬切。这样设计是为了尽量让每个 chunk 结束在一个语义完整的位置。不设置好分隔符很容易出现一句话被拦腰切断的惨案这是所有做 RAG 的人都会遇到的chunk 太碎导致回答语义混乱的问题。有一个检验分块效果的小技巧强烈建议你实操完立刻自查打印出 chunks 里第 20 块的开头和结尾看看是不是完整句子。如果不是说明 chunk_size 偏小或者分隔符顺序有问题。调参这一步不要靠感觉要有针对性地看数据。5. 向量化与检索让计算机会搜索PDF5.1 嵌入模型到底在做什么从文本到向量的过程是 RAG 里最容易被当成黑盒的环节。学到这里请你放下神经网络很神秘的想法用一个几何视角来理解嵌入模型会把每个文本块映射到一个高维空间让语义相近的文本在这个空间里距离更近。举个例子。今天天气很好和今天阳光明媚两句话字面不同但语义相近它们映射到高维空间后就会挨得很近。而今天天气很好和这道菜很咸则离得很远。这个距离通常用余弦相似度来衡量数值越接近 1 表示方向越一致也就是语义越相关。推荐一套稳定的入门组合OpenAI text-embedding-3-small 嵌入模型。如果项目对数据隐私有要求可以换飞桨 BGE 等开源模型部署在本地效果也很稳定只是需要额外花时间在模型和环境上零基础建议先走云 API。引入依赖并生成向量的代码from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vector embeddings.embed_query(年假制度怎么规定的) print(f向量维度{len(vector)})你能看到一句话变成了一个几百维的浮点数列表这就是计算机用来理解语言和交流的空间坐标。这一步是数据准备链路的核心检索阶段还会用同一个嵌入模型把用户提问也转成向量再和库里所有向量比距离。不同阶段用的嵌入模型必须一致否则两个向量不在同一语义空间距离计算毫无意义。5.2 实操把文本块写入向量数据库向量数据库的任务是存储这些高维向量并支持快速相似度检索。零基础阶段我用 Chroma它是嵌入式数据库一个 pip install 就能用不需要单独部署服务适合小规模知识库和教学。写入代码from langchain_community.vectorstores import Chroma # 将切分好的文本块连同向量写入数据库 vectorstore Chroma.from_texts( textschunks, embeddingembeddings, persist_directory./pdf_knowledge_db, # 本地持久化目录 ) print(向量数据库写入完成) # 直接在检索阶段测试 results vectorstore.similarity_search(年假制度怎么规定的, k3) for i, doc in enumerate(results): print(fTop{i1}: {doc.page_content[:200]})执行完这段代码你就完成了知识库建设最关键的一步PDF 内容从纯文本变成了可按语义检索的向量数据。这里面有两点实操经验。一点是persist_directory指定一个固定目录这样下次重新运行时可以从磁盘加载已有向量库不用每次都重新解析 PDF。另一点是k参数代表每次检索召回几个相似块一般设 3 到 5 个太少可能漏答案太多会往上下文里塞噪声。我一开始迷信召回越多越好结果每次把 20 个不相关块全塞给大模型它反而被噪声带偏回答质量直线下降后面加了一个重排序步骤才解决。5.3 理解 hit rate你的知识库到底能不能找到答案很多教程只讲 RAG 全链路跑通不告诉你如何衡量检索这一步到底好不好但我觉得这是零基础最该建立的一个指标意识。RAG 里有一个基础指标叫 hit rate直译是命中率含义是在全部测试问题中有多少比例的问题正确答案对应的文本块被成功召回在了 Top-k 结果里面。比如你有 100 个测试问题人工标注了每个问题对应的正确答案片段然后运行检索看这些问题里有多少个在返回的 Top-3 里包含了那个片段。如果命中率是 70%说明 30% 的问题大模型根本找不到证据只能瞎编。这个指标直接指向你自己搭的知识库检索质量而不受大模型发挥影响核心诊断价值就在这里。我强烈建议入门项目养成为每个阶段小规模验证的习惯解析完后抽查文本分块后抽查语义完整性检索后计算 hit rate最后再看大模型回答质量。分层验证能让你快速定位是哪一个环节出了问题而不是永远在最后一环回答不对这个黑盒里打转。6. 搭建 RAG 核心流程把整条链路串起来6.1 最小可用的 RAG 问答系统前面所有准备工作都做好了这一步是把它们串起来。RAG 流水线其实就是一个检索器 提示词模板 大模型的组合。直接上完整代码这个代码就是你的最小可运行底座from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain_core.prompts import ChatPromptTemplate # 1. 从磁盘加载已建好的向量库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma( persist_directory./pdf_knowledge_db, embedding_functionembeddings, ) retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 2. 组装 Prompt强制模型基于检索内容回答 prompt_template 你是一个基于知识库回答问题的助手。 请严格依据以下资料片段回答问题。如果资料里没有相关信息请直接回复未找到相关资料不要编造。 资料片段 {context} 用户问题 {question} 回答要求 - 用简洁的中文回答 - 在末尾列出引用的资料编号 prompt ChatPromptTemplate.from_template(prompt_template) # 3. 实例化大模型 llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) # 4. 定义一个函数把检索 组装 生成串起来 def answer_question(question: str): docs retriever.invoke(question) context \n\n.join( f[{i1}] {doc.page_content} for i, doc in enumerate(docs) ) final_prompt prompt.format(contextcontext, questionquestion) response llm.invoke(final_prompt) return response.content, docs # 测试问答 answer, source_docs answer_question(员工年假制度是怎么规定的) print( 答案 ) print(answer) print(\n 引用的来源片段 ) for i, doc in enumerate(source_docs): print(f[{i1}] {doc.page_content[:150]})我看到很多第一次搭 RAG 的人代码跑通后非常兴奋但我要提醒你这个版本只是能用距离好用还有距离。首先temperature0.2是刻意设置的偏低值因为知识库问答希望模型尽量忠实于资料而不是自由发挥温度高了容易让模型过度发挥。其次Prompt 里显式写没有资料就直说是为了减少事实幻觉。最后as_retriever(search_kwargs{k: 4})控制召回数量这里取 4是从召回充分性和上下文噪声两个角度博弈后比较合适的中档值。6.2 回答质量的关键让 Prompt 约束模型而不是放任它基本问答跑通后你要学会调 Prompt。同一套检索结果Prompt 写法不同回答质量可能天差地别。最基础的优化是告诉模型只用资料。然后是进阶优化让模型把回答划分为结论 依据 原文引用三部分大规模知识库项目里引用信息对用户建信任极其重要也能让你在回答错的时候迅速追溯是哪一步出的问题。实际效果对比我亲测过。我在 prompt 里加了如果资料相互矛盾请分别列出并对比之后员工制度这类经常存在新旧版本冲突的文档回答准确率提升非常明显。除此之外我还习惯在每个 chunk 里带上来源元信息比如员工手册_第12页这样检索回来的片段自带出处大模型就能在回答里给出精确引用。这个做法很简单但是价值巨大排查问题的效率直接翻倍。6.3 RAG 常见瓶颈与调优方向很多项目做到能回答就停了但真实场景下你会发现 RAG 的瓶颈往往不在大模型本身而在检索质量。最常见的瓶颈现象是资料明明在库里却检索不到或者检索到了相关片段但还有几个干扰片段答案被带偏。前者是 hit rate 问题后者是检索精确率问题。针对这两类瓶颈我按性价比排了调优优先级。第一优先是优化文档解析和清洗很多所谓检索不到其实是数据源本身脏。第二优先是调整分块策略尤其是中文文本用 500 token 附近加 overlap 的组合通常能解决一大部分语义截断问题。第三优先是换个更强的嵌入模型因为它能提升向量本身的语义表达能力但注意这会导致全库向量需要重新生成。第四优先是加重排序步骤先把 k 设为 20 召回更多候选块再用一个重排序模型如 bge-reranker 或 Cohere Rerank精排成 Top 4这能显著打掉噪声。最后如果你追求更强的推理能力可以考虑 Agentic RAG——把检索变成可规划的多步动作让知识库像人一样反复查询、交叉验证这属于进阶内容先把自己的基础 RAG 做到稳定数十 QPS 再说。我整理了一张常见瓶颈排查表方便对照。症状可能瓶颈优先排查方向回答答非所问检索召回内容不相关打印 retriever 结果检查解析和分块答案缺少细节召回块太少或 chunk 过小调大 k增大 chunk_size答案充满噪声召回过多不相关块减少 k增加重排序事实幻觉严重Prompt 缺少约束强化仅基于资料指令新文档不生效向量库缓存未更新重建持久化目录并重新写入7. 常见报错与问题排查实录7.1 问题速查表把这些坑提前踩一遍零基础用户踩的坑90% 都能从下面这张表里找到答案。我按问题现象、原因、排查思路三列整理问题现象根本原因排查思路与处理中文 PDF 解析出乱码PDF 字体编码不规范pypdf 抽取出错换 PyMuPDF 或试 OCR观察文字层存在与否答案明明在 PDF 里却答不出来检索未召回正确 chunk 或 chunk 被切碎打印 retriever 召回内容调整 chunk_size/overlap图片里的信息答不出来图片根本没有被解析成文字补充 OCR 或图片转描述流程相似度检索结果全是页眉页脚解析后没做清洗垃圾文本污染向量回到解析清洗环节过滤恒定重复字符串回答内容完全与资料无关检索返回为空或被阈值截断检查向量库是否为空放宽相似度阈值每次提问都很慢向量库没有索引或模型响应慢小库先忍受大库加 HNSW 类索引换轻量模型换了一个嵌入模型后检索失效新旧模型向量空间不一致统一嵌入模型重新生成全库向量结果会编造资料来源Prompt 允许模型自由发挥增加依据引用编号回答约束并附证据片段这个表单是我把这些年在群里看到的提问浓缩出来的碰到问题别急着重装环境先对着症状定位到对应阶段。7.2 一个现场排查实录PDF 有答案但 RAG 答不上来最后分享一个我真实踩过的坑整个过程非常有代表性你可以拿它当排查范本。当时有一个产品说明类 PDF用户问设备支持的供电方式有哪些答案明明在文档第 15 页的表格里RAG 却回答未找到相关资料。我第一步直接打印 retriever 检索到的前 5 个片段发现返回的全是设备简介和环境要求压根没有供电方式那个表格。这说明问题在检索不在生成。第二步我去检查那一段在原文里长什么样发现它是个三列表格pypdf 解析成了混乱的数字和文字拼接分块之后那块语义已经完全支离破碎。第三步我把解析脚本换成 PyMuPDF并把表格部分手动转成供电方式直流 48V、交流 220V这样的键值文本重新入库后检索结果里稳稳命中。第四步我计算了这个小库的 hit rate从原来不到 50% 提到 90% 左右才敢把知识库存起来给业务用。这次排错给我最大的启发是RAG 系统里大模型答错了往往不是在生成环节而是检索环节没有给足证据。所以不管你用什么工具搭知识库遇到问题一定要先切开链路分段验证而不是盲目换模型或调 Prompt。每个阶段有自己的可观测结果解析看文本分块看完整句检索看召回片段最后才轮到看生成答案。最后分享一点实操以来的真实体会我搭过几个不同体量的 RAG 知识库之后最大的感受是真正决定知识库上限的不是大模型而是前面解析、分块、嵌入、检索这几步的精细程度。一个简单的 pypdf 解析、固定长度分块、默认向量库配置搭出来的系统和一套针对业务文档做过清洗、语义分块、重排序的系统回答质量差距非常明显而后者并不需要多深的理论就是一步步把每个环节做实。对于零基础的同学我的建议是别追求一步到位务必先把最小闭环跑通。哪怕你的知识库只有一份 PDF哪怕你的检索结果不够完美只要提问→召回→生成→引用这条链路能完整走一遍你已经赢过绝大多数还停留在看教程的人。跑通之后再去优化每个环节优化到什么程度一个小经验是每次只改一个变量比如只调整 chunk_size对比 hit rate 变化只换嵌入模型对比问答质量。这样你的每一步提升都是可量化的、可复现的。这套路线往后还能扩把知识源从 PDF 延伸到 Word、网页、音视频转录或者升级成 Agentic RAG 让系统自主决定检索策略但那是后话。先把从 PDF 到 RAG 的这条路走扎实你会发现后面所有扩展都是水到渠成的事。