上传PDF不等于RAG：大模型知识库检索增强生成流程解析

最近有同学拿着一份 PDF 产品手册上传到大模型对话窗口回车后没几秒大模型照着文档里的退货政策回了一段话。于是他觉得自己已经把 RAG 做完了。这个理解需要纠正一下。把 PDF 上传给大模型不等于 RAG。它只是把 PDF 里自动解析出来的文本当作临时上下文塞给了模型而真正的 RAG 核心是大模型回答之前先“检索”和问题相关的资料再把检索到的内容拼进提示词。这篇文章会把链路拆开讲清楚为什么上传 PDF 不等于 RAG以及一个能够称为 RAG 知识库的最小流程该包含哪几步。你会看到文件解析、文本分块、向量化、检索、重排、引用这些环节各自起什么作用也会看到一套相对靠谱的评估方法。准备开始做 PDF 问答、企业内部制度问答、产品手册问答的建议把这条链路先踩实。1. 先想清楚PDF 丢给大模型大模型看到的不是“整个知识库”1.1 上传 PDF 在实际处理里只相当于一次上下文拼接不管你去用的是网页版 AI 助手、开源大模型的 Web UI还是某个企业工具里的“上传文件并提问”当一份 PDF 被上传后后台做的事情通常是文件解析成文本截取前面一部分文本然后和你的问题一起拼进提示词。这个流程里没有“检索”。模型模型能不能答对完全取决于文件有没有被完整解析、截取的文本是否覆盖答案来源。好处是省事不需要建索引也不需要向量库。代价是文件一长前面和中间内容很容易被截断文件一多问答系统根本不知道该以哪份文件为准回答再正确也没有办法准确告诉你“这句话来自 PDF 的第几页、第几段”。我见过不少项目在第一版就是这么做的测试时只挑了一篇几十页的介绍文档效果尚可。等换成几份产品手册、合同模板、客服常见问题后发现模型会自己把不同文件里的信息混在一起甚至出现离谱的编造。这个阶段出现的“幻觉”其实不是模型能力问题而是上下文结构根本没有建立起来。1.2 为什么单文件时够用文件一多就“看起来傻”单独一份 PDF 上传通常只考验“文本提取”和“上下文长度”。如果 PDF 本身能复制文字问题聚焦在文档前中段体验可能不错。但这套方式有不少边界上下文长度限制文本超过窗口大小后要么被截断要么被压缩答案自然不稳定。跨文档能力弱多个 PDF 同时上传模型能看到的文本量更有限也无法区分知识的版本和适用范围。无法做精确来源回溯回答虽然引用了某句话但系统里没有保留段落索引用户想“跳到 PDF 原文看上下文”很难实现。更新成本高文档更新后如果直接在会话里替换文件模型只能基于新的一轮对话理解没有统一的知识版本管理。扫描版 PDF 很容易彻底失效文本层缺失时上传后的模型根本读不到内容只会在界面上给你一个“看起来读完了”的假象。这些边界叠加起来就是很多人觉得“上传 PDF 问答不靠谱”的原因。真正进入 RAG 体系后情况会改变系统不依赖“一次性看到全文”而是先把 PDF 做成可以被检索的片段等用户提问后只把最相关的几段找出来交给模型。这才是检索增强生成的本意。判断标准很简单如果系统没有任何“根据问题把文档片段找回来”的环节无论前端页面做了多少上传和对话功能它都不算完整意义的 RAG。2. 真正做 RAG链路里至少要拆出这几件事2.1 召回阶段先检索后生成RAG 的工作顺序和人类查资料很像。人类拿到一个问题不会重新背诵整本手册而是先翻目录、翻索引找到可能相关的章节再阅读其中一小段最后组织回答。RAG 就是把“翻找”这一步交给程序。一个标准流程至少包含文档解析、文本切分、向量化、索引构建、查询向量化、检索召回、重排、生成回答。前四步通常在文档入库时执行后四步在用户提问时执行。很多人第一次做 RAG最容易忽略的是“检索”之后还要“重排”。只用向量相似度召回 Top K 片段时可能召回了语义相近但顺序混乱的段落。重排模型会重新计算候选片段与问题的相关度把最匹配的几段调到前面生成质量往往能提升不少。2.2 只做“把 PDF 塞进提示词”和 RAG 的差别在哪里这里列一个表方便对照对比维度把 PDF 上传给大模型一个最基本的 RAG 流程文档处理靠平台自带解析用户不可控自己能控制解析、切分和清洗上下文组织把所有可见文本塞进窗口只检索最相关的若干片段长文件超过窗口就会被截断拆成片段按需召回多文件混合后容易串内容通过元数据限制范围和来源答案引用多数不支持精确到段落页码每段片段可保留文档名、页码、行号知识更新变更一份文件要重新传一次重新更新索引对应的文档即可可控性用户很难知道模型使用了哪些内容每轮检索结果可记录、可审计从这个表能理解为什么 RAG 适合知识库场景它的价值核心是“把有限的长文本知识变成可按问题定位的小片段”而不是让模型死记硬背。2.3 如果你做的是 Agentic RAG 或 Ontology RAG也是在“先检索后生成”这个底座上扩展现在网上常看到 Agentic RAG、Ontology RAG 这类概念。它们和基础 RAG 的区别是在上面提到的核心流程上加了新的控制逻辑。Agentic RAG 会让模型决定先检索哪个库、拆成几个子问题、检索不充分时是否换一种检索词重试。Ontology RAG 或者 Graph RAG 则更多依赖实体关系、知识图谱结构适合“人和岗位、项目和预算、零件和型号”这类关系密集的数据。新手不要一上来就追求这些高级形态。先能把一个 PDF 按段落切好、检索出来、带引用回答再考虑加 Agent 决策或图谱关系否则会叠加太多不确定性。3. 从最小可用项目开始跑通一份 PDF 的 RAG 闭环3.1 一套不过分依赖框架的实验流程我推荐的做法是先不用特意挑选一个复杂的 RAG 平台直接用一段脚本把流程串起来。下面这段代码是通用流程示意不是某个发行版本的官方 API实际使用时要根据你选用的工具替换具体函数。# 通用 RAG 最小流程演示 from doc_loader import load_pdf # 负责解析 PDF from chunker import split_text # 负责文本切分 from embedder import embed_texts # 负责文本向量化 from vector_store import VectorStore # 负责存储和相似度检索 from llm import chat # 负责最终回答 file_path 产品手册.pdf # 1. 解析 PDF保留页码 doc_pages load_pdf(file_path, include_page_numberTrue) # 2. 按段落或固定窗口切分模拟常用参数 chunks split_text( doc_pages, chunk_size500, overlap100 ) # 3. 向量化并写入库 vectors embed_texts([chunk.text for chunk in chunks]) store VectorStore() store.add(chunks, vectors) # 4. 用户提问 question 退货政策要求保留哪些凭证 # 5. 查询向量化、检索候选 query_vector embed_texts([question])[0] candidates store.search(query_vector, top_k20) # 6. 重排选出最相关的 3 段 final_chunks rerank(question, candidates, top_k3) # 7. 组装提示词并调用大模型 answer chat(build_instruct(question, final_chunks)) print(answer)这段流程有几个值得注意的点第 1 步解析 PDF 时要尽量把页码保下来。后面回答时能不能给出来源靠的就是这个页码或段落 ID。第 2 步切分是决定检索质量最关键的位置。chunk_size500 和 overlap100 只是示例中文一个词平均不到 2 个字500 字大概对应一段比较完整的说明。不能盲信固定数字。第 5 步先召回 20 条候选第 6 步再精排到 3 条目的是先保证“没有被遗漏”再用重排提升“顺序准确性”。如果环境里没有重排模块可以先只做 Top K 召回但不能忽略它对效果的贡献。3.2 先在单文档上验证再进入批量第一次跑通时不要直接开批量。先用一份结构清楚、能复制文字的 PDF问 5 到 10 个问题覆盖开头、中间、结尾三个位置。每次跑完都检查三个结果模型回答是否准确、检索出的片段是否真的包含答案来源、引用页码是否指向正确的原文。如果这些问题都能稳定通过再写批量脚本处理整个目录下的 PDF。批量场景下还要额外处理三件事文件命名是否唯一、解析失败的 PDF 是否有日志、每个文档的元数据是否挂得正确。否则某个文件嵌错了公司名后面所有答案都会跟着错。3.3 给答案加上来源是检验 RAG 是否成立的方法做 RAG 时我最看重的一项能力是“可回溯”。程序把文档切成了片段每个片段要带着来源信息一起进入向量库。回答生成后最好能把命中的片段放在答案下方显示成“来源产品手册.pdf第 12 页”。光是这个简单的设计就能区分真的 RAG 和伪 RAG。如果模型输出了结论来源里却找不到对应内容问题很可能出在提示词没有限制模型只能基于给定片段回答。这句话大家可以在系统提示里加一句“如果问题无法由提供的内容回答请明确说明”。这句话能大幅降低检索增强后的编造。第一版不要追求复杂提示词。先把“检索片段 - 引用来源 - 回答”闭环跑稳后续再优化提示词。4. PDF 文件类型决定 RAG 成败先做解析预检再谈向量化4.1 普通文本 PDF、扫描版 PDF、表格型 PDF 完全是三类输入我见过不少团队花大把时间调参数最后发现效果差是因为 PDF 根本没解析对。文本型 PDF 可以直接提取文字扫描型 PDF 没有文本层必须走 OCR 或视觉模型才能拿到内容表格型 PDF 则要处理行列拆分和多页跨页问题。网上经常有 PDF 转 Word、PDF 编辑器之类的工具它们能帮助我们快速确认某个 PDF 是否有文本层、表格是否会被拆乱。但这些工具解决的是“文件内容可读”问题不等于 RAG 里的“文本切分正确”。如果你把一张扫描图片转成了 Word里面很可能没有任何可直接检索的文字只是图片放在文档里。推荐做 PDF 预检拿一段成品 PDF 在阅读器里复制文字。如果复制不出任何内容基本可以判断是扫描版。用 PDF 转文本工具抽一次全文检查中文有没有乱码、表格是否变成一列乱序字符串。检查是否存在页眉页脚混入正文的情况。记录哪些页面是复杂图表页后续这些页面可能需要单独处理不适合参与普通切分。预检这一步暴露的问题通常比调检索参数更严重。4.2 切分不只按字数还要考虑章节、列表和表格语义固定按 500 字切分的问题在于它可能切断一段原本完整的规则。比如退货政策和售后电话放在同一个段落里因为被切分成了两个片段问题“退货找谁”可能只召回一半内容。较好的做法是在切分前先做结构感知尽量按标题层级、列表项、段落空行来切割再对超长段落做二次切分。这里有个实际经验切分后的片段不宜太短也不要太长。太短如“本政策自 2024 年 1 月 1 日生效”缺少上下文太长如整页文字 3000 字检索出来后喂给模型的噪声会变大。常用区间介于 300 到 800 字之间具体还要看你的知识库内容密度。4.3 检索方式不要太早锁死成“只用 Dense Vector Search”现在向量检索很流行但只依赖 Dense Vector Search稠密向量检索不一定最适合所有医疗、法律或政策文本。有的查询涉及精确型号、订单编号、法条条款数字稠密向量很容易忽略精确匹配。可以考虑在索引里混合一些关键词型检索再做结果合并和重排。这个组合在 RAG 实践中很常见也常被称为混合检索。新建 RAG 项目时如果发现“明明这段文字里有标准答案向量检索却召不回来”先去检查是不是文本解析错误然后再考虑加入关键词检索。不要一上来就怀疑模型。5. 想证明这不是“自嗨型 PDF 问答”拿指标和样例集说话5.1 一条不需要花太多时间的验收路径很多朋友会问 RAG 评测怎么做知识库指标到底该看哪些。答案是先准备一个高标准的测试问题集。每条问题里要包含标准问题、正确来源、期待出现的核心要点、所属文档范围。数量不用庞大30 到 50 条就够第一轮验证。测试问题要覆盖这几类能从文档某一段直接找到答案的问题如“退货周期是几天”。需要跨两段拼接的问题如“说明书某一章节引用了另一个章节的定义”。文档里没有答案测试模型会不会抵抗的问题如“这份手册没有提到的政策是什么”。来源容易混淆的问题比如两版产品手册中同一政策的说法不同。扫描版 PDF 转成 OCR 后文本有误的问题可测试系统能否给出较稳定的回应。跑完后逐条记录检索出来的前 3 个片段里有没有包含答案来源。模型回答时有没有只用检索到的内容。最终答案和标准答案是否接近。来源引用是否正确。5.2 几个基础指标的通俗解释在做 RAG 相关文章时常涉及的指标如下。理解它们比记住英文缩写更重要。指标通俗含义主要排查方向上下文命中率 / 召回率正确答案是否出现在被召回文本里解析、切分、检索上下文精确率 / 噪声敏感度召回文本里是否夹杂太多无关内容重排、Top K 规模、切分粒度回答忠实度最终回答是否严格基于检索文本提示词、模型选择答案相关性回答是否解决了提问意图提示词、检索结果质量引用准确率每条结论是否能定位到正确来源元数据、页码保留、切分逻辑如果“上下文命中率”很低就算把提示词写出一朵花也救不回来。这时候系统性问题通常不在生成侧而在前面的解析与检索链路。反过来如果检索命中率没问题但回答依然乱编问题多半出在提示词太“放养”没有约束模型使用给定的内容。第一轮评测跑完先别急着追问答案准不准先回答一个问题正确答案有没有出现在检索结果里没有就回头改分块和索引不要动模型设置。6. 不同规模场景下什么时候该直接用 PDF 对话什么时候该升级到 RAG6.1 几个常见场景和推荐选择不是所有业务都必须上 RAG。如果你的目标只是快速问一份短 PDF 里靠前的要点直接上传 PDF 可能是成本最低的方案。反过来当文件多、版本多、回答必须给出“来源依据”时RAG 是不可替代的底座。这里给一张场景对照表业务情况更合适的方式理由单份少于 20 页、能复制文字、只做信息提取直接用大模型文件上传成本低流程简单单份 PDF 超过 50 页答案可能分布在任意位置基础 RAG避免上下文截断能定位答案区间多份产品手册/政策文件版本会持续更新基础 RAG 文档元数据能按库筛选来源改一版只更新对应索引企业制度库中经常涉及权限范围隔离RAG 元数据权限过滤可以在检索层限制用户只能命中允许访问的文档问题需要跨多个文档分步推理Agentic RAG需要规划子问题、多轮检索和结果合并问题强依赖实体关系和层级关系Ontology RAG / Knowledge Graph RAG图结构更适合表达“部门和岗位、人员和项目”的关系注意表里的“权限过滤”“元数据过滤”指的都是检索层的正常工程设置通过索引过滤实现属于企业知识库常见做法。不要把它理解成绕过任何平台限制的方案。6.2 实际落地时我更建议的推进顺序如果你正在从 0 搭一个 PDF 问答系统建议按下面的顺序推进先拿 3 份不同类型 PDF 做解析预检确认文本质量。搭出“切分、向量化、检索、提示词、回答”的最小闭环。每条结果显示来源方便人工检查。建 30 条评测问题集跑第一轮指标。根据“检索没命中、命中但不会用、引用错误”三类问题分别修复。等单文件稳定后再扩展到批量文件、重排模型、混合检索。最后才考虑是否引入 Agentic RAG 或图谱类增强。这个过程听起来不华丽却很稳。前期花半天做好 PDF 解析后面会省出大量调提示词的精力和时间。RAG 的价值从来不是“模型再聪明一点”而是让模型在回答前有方法地翻到正确答案。先纠正“上传 PDF 就等于 RAG”这个误解再去设计文件、索引、评测和提示词你的知识库问答会少踩很多看不见的坑。