很多人第一次听到AI 知识库这四个字脑子里浮现的画面要么是某个大厂发布会上的炫酷 Demo要么是一堆看不懂的论文术语。但真实情况是一个能跑起来、能回答你自己文档问题的知识库从零开始搭一个周末足够了。我自己带过不少零基础的朋友入门发现大家卡住的地方从来不是模型不够强而是不知道整条链路上到底有哪几个环节、每个环节该用什么工具、以及为什么这么选。这篇就把从上传一份 PDF 到跑通一套 RAG 检索增强的完整路线拆开讲每一步都告诉你为什么这么做而不是甩一堆命令让你照抄。适合完全没有 AI 工程背景、但想亲手做一个能用的知识库的人。1. 先把 RAG 这件事的本质想明白1.1 大模型为什么记不住你的文档大语言模型LLM本质上是一个被训练来预测下一个词的函数。它的知识全部固化在训练时的参数里训练完成那一刻它的知识就冻结了。你公司内部的产品手册、你个人的读书笔记、一份上周刚出的行业报告这些东西它一概不知道。你直接问它它要么说不知道要么更糟——一本正经地编一个看起来很像那么回事的答案这就是所谓的幻觉。有人会想那我直接把整份 PDF 粘贴到对话框里不就行了短文档确实可以但一旦文档超过几万字就会撞上两个硬墙一是模型的上下文窗口有上限塞不下二是就算塞得下token 是要花钱的每次提问都把十万字重新喂一遍成本和延迟都受不了。更关键的是长上下文里模型对中间部分的注意力会衰减你真正想要的那句话可能被淹没在一堆无关内容里。RAGRetrieval-Augmented Generation检索增强生成解决的正是这个问题。它的思路特别朴素既然模型记不住那就在它回答问题之前先去你的文档库里把最相关的那几段找出来连同问题一起塞给它让它看着材料答题。模型负责语言理解和组织检索负责提供事实依据各干各的活。1.2 一条完整的 RAG 链路长什么样把 RAG 拆开其实就四个动作我习惯叫它切、嵌、存、查切Chunking把长文档切成一段段小文本块。因为检索的最小单位是块不是整篇文档。嵌Embedding把每个文本块转成一串数字向量让语义相近的文本在向量空间里距离也相近。存Storage把这些向量连同原文存进一个支持向量检索的数据库。查Retrieval Generation用户提问时把问题也转成向量去库里找最相似的几个块拼进提示词交给 LLM 生成答案。这四个字看着简单但每一个环节都有坑。切得太碎语义不完整切得太大检索精度下降。Embedding 模型选错中文检索效果可能惨不忍睹。存储方案选重了本地跑不动选轻了数据量一大就崩。这些细节后面会逐个展开。1.3 零基础该从哪一层切入市面上 RAG 的教程大致分三档最上层是直接用现成产品比如各种笔记软件的 AI 问答中间层是用框架LangChain、LlamaIndex 这类拼装最底层是从零手写每一个环节。我的建议是零基础先走中间层但一定要把底层原理搞懂。原因很实际——纯用现成产品你永远不知道它为什么答错也没法调优纯手写底层光是向量检索的数学就能劝退一大半人。用框架能让你快速跑通全流程建立信心同时框架暴露出来的每个参数chunk size、top k、相似度阈值都是理解原理的抓手。提示不要一上来就追求生产级。先用十几页 PDF 跑通一个能回答问题的 Demo比读十篇架构文章都有用。跑通之后再谈优化。2. 文档准备PDF 上传背后的脏活累活2.1 PDF 解析远没有你想的那么简单很多人以为上传 PDF就是读个文件实际上这是整条链路里最容易被低估的一步。PDF 这个格式的设计初衷是精确排版打印不是存储结构化文本。它里面可能是一堆绝对定位的文本框、可能是扫描出来的图片、可能是双栏排版、可能带页眉页脚和水印。我踩过最典型的坑一份双栏排版的学术 PDF用最朴素的解析库读出来左右两栏的文字被交错拼在了一起一句话读到一半跳到另一栏语义完全乱套。这种文本喂给 Embedding检索质量直接归零。常见的解析方案有这么几类选哪个取决于你的文档类型文档类型推荐方案说明纯文本型 PDFPyMuPDF、pdfplumber速度快对规整排版效果好扫描件/图片型OCR 方案如 PaddleOCR必须先做文字识别复杂排版双栏、表格版面分析类工具先识别版面结构再抽取Word/PPT/网页对应格式的解析库比 PDF 好处理得多2.2 解析之后必须做的清洗解析出来的原始文本不能直接用得先清洗。这一步没有标准答案但有几件事几乎每次都要做去掉页眉页脚每页重复出现的公司名、页码、文档标题这些内容会污染检索结果。想象一下你搜报销流程结果每个块里都带着XX公司内部资料 第3页相似度计算会被这些噪声干扰。合并断行PDF 里一句话经常被硬换行切成好几行需要根据标点和语义把它们重新拼成完整句子。处理特殊字符全角半角、连字符、乱码符号该转的转该删的删。保留结构信息标题、章节号这些信息很有价值最好在切块时带上方便后续做元数据过滤。我个人的经验是清洗这一步花的时间往往比调模型还多但它带来的收益是线性的——文本越干净后面每一步的效果都越好。别嫌烦这是地基。2.3 什么样的文档适合做知识库不是所有文档都适合。我总结了几条判断标准内容相对稳定天天变的实时数据不适合知识库更适合沉淀型内容。有明确问答价值操作手册、FAQ、政策文件、技术文档这类天生适合。篇幅适中几页到几百页都行但如果是几千页的巨型文档要考虑分库或分层检索。格式尽量规整排版越乱解析成本越高。反过来纯图片、纯表格、大量公式的文档做起来难度会陡增零基础阶段建议先避开。3. 切块Chunking决定检索质量的第一道分水岭3.1 为什么不能整篇文档直接嵌入有人会问我把整篇文档转成一个向量不行吗不行原因有两个。第一一篇一万字的文档转成一个向量这个向量是所有语义的平均值它什么都沾一点但什么都不精确检索时根本区分不出细节。第二就算检索到了你把整篇文档塞给 LLM又回到了上下文塞不下的老问题。所以必须切块。块是检索的最小单位块的质量直接决定了检索的上限。这里有个残酷的事实如果正确的答案没有被切进任何一个块里或者被切得支离破碎那么后面无论用什么高级模型都救不回来。切块是整条链路里最值得花时间打磨的环节。3.2 固定长度切块与语义切块的取舍最朴素的切法是固定长度每 500 个字符切一刀相邻块之间留 50 个字符的重叠。重叠是为了防止一句话正好被切断导致两个块都读不懂。但固定长度有个明显问题它会在句子中间、段落中间硬切破坏语义完整性。于是有了语义切块——按段落、按标题、按句子边界来切尽量保证每个块是一个完整的语义单元。我的实操建议是混合策略先按文档的自然结构切章节、段落。如果某个段落太长再按句子边界二次切分。如果某个段落太短比如就一句话和相邻段落合并。最后给每个块加上一定的重叠。这样切出来的块既不会太长导致检索不精确也不会太短导致语义不完整。3.3 chunk size 到底设多少合适这是被问得最多的问题但答案真的不是固定的。它取决于你的文档类型和提问方式FAQ、问答对块可以小200-300 字因为每个问答本身就是独立单元。技术文档、操作手册500-800 字比较合适一个完整操作步骤通常在这个范围。叙述性长文、报告800-1200 字保证上下文完整。判断标准很简单一个块应该能独立回答一个具体问题。如果你读这个块觉得信息不完整还得看下一块那说明切小了如果觉得里面讲了好几件事那说明切大了。注意chunk size 和 Embedding 模型的最大输入长度要匹配。有些模型只支持 512 个 token你切 2000 字进去会被截断等于白切。3.4 元数据被大多数人忽略的检索利器每个块除了文本内容还应该带上一组元数据来自哪个文件、第几页、属于哪个章节、文档的更新时间等等。这些信息平时看着没用但在检索时能派上大用场。举个例子你的知识库里同时有 2023 版和 2024 版的政策文件用户问最新的报销标准是多少。如果块上带了版本和日期元数据你就可以在检索时优先返回新版内容或者直接过滤掉旧版。没有元数据你只能靠语义相似度硬碰很容易返回过时信息。元数据还能用于结果展示——告诉用户这个答案来自《员工手册》第 12 页可信度立刻上来了。4. Embedding把文字变成可计算的向量4.1 Embedding 到底在做什么Embedding 模型的作用是把一段文本映射到一个高维空间里的点通常几百到几千维。这个映射有个关键性质语义相近的文本映射后的点距离也近。打个比方你可以把每个文本块想象成地图上的一个位置。如何申请年假和年假申请流程这两句话虽然用词不完全一样但它们在地图上的位置会非常接近而如何申请年假和食堂今天吃什么就会离得很远。检索的时候把用户的问题也放到这张地图上找离它最近的几个点就是最相关的文本块。这个距离通常用余弦相似度来衡量取值范围 -1 到 1越接近 1 表示越相似。实际系统里一般会设一个阈值比如 0.7低于这个值的块就不返回了避免答非所问。4.2 中文场景下怎么选 Embedding 模型这是中文用户最容易踩坑的地方。很多英文榜单上排名靠前的模型拿到中文场景下效果会打折扣。选模型时我一般看这几点中文支持优先选明确针对中文优化过的模型或者多语言模型里中文表现好的。维度维度越高表达能力越强但存储和计算成本也越高。常见的有 384、768、1024、1536 维。最大输入长度要和你的 chunk size 匹配。本地还是 API本地模型免费、数据不出门但需要算力API 模型省事但有调用成本和数据外传的顾虑。对于零基础、想本地跑的朋友我建议从参数量小、专门做中文的模型入手几百 MB 的模型在普通笔记本上就能跑效果对入门来说完全够用。等跑通了、发现效果不够再换更大的模型。4.3 一个容易被忽略的细节查询和文档要用同一个模型Embedding 模型有个硬性要求建库时用的模型和查询时用的模型必须是同一个。因为不同模型构建的向量空间是不兼容的用 A 模型建的库拿 B 模型去查得到的相似度完全是乱的。这个坑我见过太多次了。有人建库时用了一个模型后来觉得另一个模型更好直接换了查询端的模型结果检索结果一塌糊涂还以为是数据问题。换模型必须重建整个向量库没有捷径。4.4 向量归一化与相似度计算还有个技术细节值得提一句很多 Embedding 模型输出的向量需要做归一化把长度缩放到 1。归一化之后余弦相似度就等价于点积计算更快。大部分框架会自动处理这一步但如果你手写检索逻辑记得确认一下否则相似度排序可能会出错。5. 向量存储与检索把块存进去把答案捞出来5.1 向量数据库怎么选存向量这件事方案从轻到重差别很大方案适用场景特点内存/本地文件入门、小数据量零依赖重启即失适合练手轻量嵌入式库单机小项目无需独立服务够用专业向量数据库生产、大数据量支持分布式、高并发运维成本高传统数据库的向量扩展已有数据库体系复用现有运维功能相对基础零基础阶段我强烈建议先用最轻的方案。几百个块的规模内存里跑暴力检索把问题和每个块算一遍相似度完全够快几十毫秒的事。等你数据量上万、检索变慢了再考虑上专业数据库。过早引入复杂组件只会让你在配置上耗光耐心。5.2 检索策略不只是找最相似的最基础的检索是取相似度最高的 top k 个块。但实际用起来纯向量检索有几个短板对关键词不敏感用户搜一个具体的产品型号X200向量检索可能返回一堆语义相近但型号不对的内容。对精确匹配弱专有名词、代码、编号这类向量表达不如字面匹配准。所以进阶做法是混合检索向量检索负责语义关键词检索比如 BM25负责字面两路结果融合排序。这个思路在中文场景下尤其有用因为中文分词和专有名词的处理本来就复杂。另一个常用技巧是重排序Rerank先用向量检索粗筛出比如 20 个候选块再用一个专门的重排序模型对这 20 个精排取前 3-5 个给 LLM。粗筛快、精排准两级配合效果比单级好很多。5.3 top k 设多少阈值怎么定top k 是返回给 LLM 的块数量。设太小可能漏掉关键信息设太大无关内容会干扰 LLM还可能超出上下文。我的经验值先用 3-5 试。如果发现答案经常缺信息往上加如果发现 LLM 被无关内容带偏往下减。配合相似度阈值一起调低于阈值的块直接丢弃哪怕它排在 top k 里。这里有个反直觉的点不是返回越多越好。LLM 面对一堆材料时注意力会被分散有时候 3 个精准的块比 10 个混杂的块效果好得多。宁可少而精。5.4 检索效果怎么评估搭完之后怎么知道好不好最土但最有效的办法准备一批测试问题人工看检索结果对不对。具体看两个指标命中率Hit Rate正确答案所在的块有没有出现在检索结果里。这是检索的底线命中率不行后面全白搭。排序质量正确的块是不是排在了前面。排第一和排第五对 LLM 的影响不一样。准备 20-30 个覆盖各类问题事实型、操作型、对比型的测试问题每次调整参数后跑一遍对比命中率变化。这个习惯能帮你把调优从凭感觉变成看数据。6. 生成环节让 LLM 看着材料答题6.1 提示词怎么写才不容易幻觉检索到的块要拼进提示词交给 LLM。提示词的设计直接决定答案质量。一个靠谱的模板大概长这样你是一个基于给定资料回答问题的助手。 请严格根据下面提供的资料回答问题。 如果资料中没有相关信息请直接说资料中未提及不要编造。 资料 {检索到的文本块} 问题{用户的问题}关键就三句话限定依据、要求诚实、禁止编造。别小看这几句它能挡掉相当一部分幻觉。我见过太多人提示词写得含糊LLM 就开始自由发挥。6.2 引用来源让答案可追溯一个成熟的知识库答案里应该带上来源。比如根据《XX手册》第 3 章……。实现方式很简单检索时保留每个块的元数据生成时让 LLM 在答案里标注引用了哪几个块。这个功能的价值在于可验证。用户看到答案能顺着来源去核对原文信任度立刻不一样。而且当答案出错时你能快速定位是检索错了还是生成错了。6.3 上下文长度与成本控制检索到的块 提示词 用户问题加起来不能超过模型的上下文窗口。一般检索几个块不会超但如果你 top k 设得很大或者块切得很大就要留意了。成本方面输入 token 是大头。每次提问都要把检索到的块重新喂一遍块越多、越频繁提问成本越高。控制手段就是前面说的精准检索少而精别一股脑塞。6.4 多轮对话怎么处理用户不会只问一个问题往往是连续追问。多轮对话的难点在于第二个问题里的它这个指代的是什么。常见做法是查询改写把当前问题和历史对话一起交给 LLM让它把问题改写成不依赖上下文的完整问题再去检索。比如用户先问年假有几天再问那病假呢改写后变成病假有几天检索就准了。这一步不做多轮对话的检索质量会断崖式下跌。7. 从能跑到好用优化与排错实战7.1 检索不准的排查顺序效果不好时别乱改参数按这个顺序排查先看解析和切块把检索到的块原文打印出来看内容是不是完整的、干净的。如果块本身就是乱的后面怎么调都没用。再看 Embedding拿几个已知相关的问题和文本手动算一下相似度看模型能不能区分开。然后看检索策略top k、阈值、要不要加混合检索和重排序。最后看生成提示词、模型选择。这个顺序是从源头到末端因为上游的问题下游救不回来。7.2 常见问题对照表现象可能原因处理方向答非所问检索没命中查切块、换 Embedding、调 top k答案不完整块切太碎增大 chunk size 或加重叠答案过时元数据没过滤加版本/日期过滤幻觉严重提示词太松强化依据资料约束检索慢数据量大、暴力检索上向量索引或专业库中文效果差模型不适配中文换中文优化模型7.3 什么时候该上更复杂的方案入门跑通之后你可能会听到 GraphRAG、Agentic RAG 这些进阶概念。它们解决的是更复杂的问题比如需要跨多个文档做推理、需要多步检索、需要处理实体关系。我的建议是先用最简方案把业务跑起来遇到具体瓶颈再针对性升级。GraphRAG 适合知识之间有复杂关联的场景Agentic RAG 适合需要多轮自主检索的复杂任务。如果你的场景就是文档问答基础 RAG 完全够用别为了技术而技术。7.4 我踩过的几个真实坑最后分享几个我自己踩过的坑都是文档里不会写的中文标点导致的切块异常有些切块逻辑只认英文句号中文的。它不认结果一整段切不开。写切块规则时一定要考虑中文标点。表格内容被切散表格转成文本后行和列的对应关系很容易丢。如果文档里表格多要么单独处理表格要么接受这部分效果打折。重复内容干扰文档里如果有大段重复的模板文字会产生大量相似块检索时互相挤占位置。清洗阶段去重很重要。测试集太单一只用一种类型的问题测试会高估效果。测试问题要覆盖事实、操作、对比、否定等各种类型。搭 AI 知识库这件事技术门槛其实没有想象中高真正拉开差距的是对每个环节细节的把控。从一份 PDF 开始把切、嵌、存、查四步走通再逐步优化你会发现它没那么神秘。我个人的体会是先动手跑通一个最小可用版本比纠结选哪个框架、哪个模型重要得多——因为只有跑起来你才会遇到那些真正值得解决的问题。