2026年，几乎每一家企业级LLM应用都在谈RAG（Retrieval-Augmented Generation，检索增强生成）。原因很简单：大模型的知识截止到训练那一天，且会一本正经地胡说八道（幻觉）；而企业真正要AI干活的场景——制度问答、产品手册、合同审查、故障排查——答案全在自家文档里。
RAG就是给大模型配一个「随查随用的资料库」：每次回答前，先从库里检索相关内容，再把内容连同问题一起交给模型生成答案。本文不聊学术概念，直接讲清楚从零搭建一套能用的知识库问答系统的完整链路、参数怎么调、坑在哪里。
一套RAG系统分两个阶段、六个环节：
离线阶段（建库，做一次）：文档加载 → 内容清洗 → 文本切分 → 向量化入库。
在线阶段（问答，每次请求）：问题检索 → 重排过滤 → 拼接提示词 → 生成回答。
大多数翻车项目，问题都出在离线阶段的「切分」和「向量化」两个环节——库没建好，检索再快也是垃圾进垃圾出。所以本文把重心放在离线阶段。
企业文档90%是PDF、Word、扫描件、PPT，每种格式都有坑：
| 格式 | 常见坑 | 对策 |
|---|---|---|
| PDF文字版 | 多栏排版、页眉页脚污染正文 | 按阅读顺序抽取（如PyMuPDF按块排序），去掉页眉页脚 |
| PDF扫描版 | 根本没有文字层 | 先OCR（RapidOCR/PaddleOCR），再走文字管道 |
| Word(.docx) | 表格、批注、修订痕迹 | 优先提取正文段落+表格结构 |
| 老式.doc | 二进制格式 | 转docx或走Word COM转换 |
| PPT | 一页全是碎片文字 | 按「标题+正文」合并为一条记录 |
清洗的黄金标准：库里每一条内容，读起来应该像一篇通顺的短文，而不是带「第3页 共12页」「修订人：张三」的原始文件残渣。清洗不干净，检索到的片段会浪费大量上下文窗口。
切分（chunking）是把长文档切成检索单元。切太大，检索到的片段混入无关信息；切太小，语义不完整。三条实操原则：
原则1：优先「结构切分」，不要无脑按字数切。 按Markdown标题、段落、表格边界切，比固定500字一刀切强得多。结构切分能保住「一段话讲一件事」，语义完整。
原则2：保留上下文锚点。 每个chunk带上「文档标题/章节路径」作为前缀元数据。检索时命中第37个chunk，至少要能回答「这段话出自哪份文件的哪一节」——这是后面做引用溯源的基础。
原则3：合理设置overlap。 相邻chunk之间重叠50-100字，防止一句话被从中间切断。固定长度切分时overlap尤其重要。
经验值：通用问答场景，300-500字一个chunk是好起点；代码文档、合同条款这种「语义颗粒度小」的内容，可以切到200字左右。不要迷信某个神奇数字，切分方案要跟着评测结果调。
Embedding（向量化） 把文本变成数字向量，让语义相近的内容在向量空间里距离更近。选型看三点：
向量数据库的选择（2026年现状）：
| 方案 | 适合场景 | 说明 |
|---|---|---|
| Chroma / FAISS | 个人项目、原型验证 | 轻量，Python直接嵌入，万级文档够用 |
| Milvus | 生产级、千万级向量 | 分布式，功能全，运维成本高 |
| Qdrant | 生产级、中等规模 | Rust实现，性能好，支持过滤 |
| Elasticsearch(8+) | 已有ES的企业 | 原生支持向量+BM25混合检索，一套搞定 |
| 云厂商向量库 | 不想运维 | 阿里/腾讯/华为云均有，配套服务完善 |
给中小团队的建议：别一上来就上分布式向量库。先确认文档量级——100万字符以内的知识库，PostgreSQL的pgvector或单机Qdrant就绰绰有余，省下的运维精力都该花在检索质量上。
库建好了，检索质量决定了问答质量。以下四个技巧按投入产出比排序：
技巧1：混合检索（BM25 + 向量）——最划算的一步。 纯向量检索对专有名词、型号、编号（如「GB/T 19001」「XH-2000型」）经常失手——这些词在语义空间里没有近邻，但关键词匹配一打一个准。做法：BM25关键词检索和向量检索各取Top N，合并去重后一起进重排。实测很多场景下混合检索比纯向量检索的命中率提升10个百分点以上。
技巧2：重排（Rerank）——效果立竿见影。 第一轮检索取回Top 20-50个候选，用重排模型（cross-encoder类）精排后只留Top 3-5个进上下文。重排模型比双塔Embedding精度高一个档次，是当前性价比最高的质量杠杆。别把第一轮的几十个chunk全塞给大模型——上下文越长，模型越容易被无关信息带偏，还烧token。
技巧3：查询改写（Query Rewrite）——治「问法太口语」的病。 用户问「那个认证怎么弄」，库里文档写的是「体系认证申请流程」。做法：先用小模型把用户问题改写成适合检索的表述（补全指代、提取关键词、转成名词性查询），再拿去检索。对多轮对话场景，还要把「它」「那个」等指代词结合历史消解成完整问题。
技巧4：过滤与路由——大库必备。 元数据过滤：先按部门/文档类型/时间范围缩小搜索空间再检索，既准又快。查询路由：判断问题类型，是查制度还是查手册还是闲聊，路由到不同的库或不同的处理流程。
「2025年的RAG只能答单跳问题，2026年的RAG会自己查资料」——这是Agentic RAG（智能体RAG）的核心：把「一次检索+一次生成」升级为「模型自主决定：先查什么→结果不够再查什么→多个来源交叉验证→最后组织答案」。
典型的多跳问题示例：「我们公司对供应商的账期要求，和去年相比有什么变化？」——这需要先定位到供应商管理制度，再定位到财务政策，可能还要对比历史版本。普通RAG一次性检索很难拼出完整答案，Agentic RAG通过多轮工具调用逐步逼近。
落地建议：别一上来就做全自主Agentic RAG——多轮检索意味着多次模型调用，延迟和成本都上去了，还可能检索跑偏。先用「单轮检索+重排」跑通，遇到两类问题再升级：①必须多文档/多来源才能回答的复合问题；②需要对比、汇总、溯源的高要求场景。
没有评测，你就不知道改动是变好还是变坏。至少建立三层评测：
第一层：检索质量（离线可测）。 准备50-100个「问题→标准答案出处」的测试对，计算召回率（recall@k：标准答案在不在检索结果里）。这一层不花钱不调模型，纯检索引擎的事，先把它调到90%以上再说生成。
第二层：生成质量（RAGAS四件套）。 用开源评测框架（如RAGAS）自动打分：忠实度（答案有没有编造库里没有的内容）、答案相关性（答没答到点上）、上下文相关性（检索回来的内容跟问题相不相关）、上下文精度（有没有混入噪音）。忠实度是底线指标，低于阈值就是幻觉，必须回查检索和提示词。
第三层：线上bad case复盘。 用户真实提问里翻车的案例，定期归类：是检索没召回（库的问题）？是召回了但重排没排上来（排序问题）？是内容进了上下文但模型没用对（提示词/生成问题）？三层问题三种解法，别一锅乱炖。
坑1：文档更新频繁却用「预Embedding」缓存。 如果知识库每周都有文档增删改（日变更率超过10%），就不要迷信「全部预计算好向量存起来」——每次更新全量重算成本极高。对策：增量更新、按文档版本号失效旧向量、检索时校验「内容指纹」（最新修改时间/哈希）防止拿到过期版本。知识库的时效性和数据库一样，是脏数据问题，不是检索问题。
坑2：把小文档库的chunk切得过大。 一个500页手册全库才几百个chunk，为了「省得检索不到」把chunk设成2000字——结果每个片段都包含两三个主题，检索命中率直线下降，模型还容易引用到无关段落。
坑3：扫描版PDF不OCR直接入库。 全库检索「零命中」的第一大元凶。建库前先抽样检查：随机挑几页PDF，看能不能复制出文字。不能？先过OCR再谈其他。
坑4：只测「答对了」的case，不测「不该答」的case。 RAG系统上线后最常见的投诉不是答错，而是「越权回答」——员工问工资制度，系统从某个内部文件夹里检索出敏感内容回答了。对策：元数据权限过滤必须在检索层做（按提问人身份过滤可见文档），不能指望大模型自己判断「这个能不能说」。
坑5：提示词里堆了几十条规则，却忘了告诉模型「资料库里没有就直说」。 这是幻觉的头号来源。提示词至少必须包含三件事：①只依据给定资料回答；②资料不足时明确说「资料库中未找到」，禁止编造；③回答附上引用来源（哪个文档哪一节），方便人核验。
如果你从零开始，按这个顺序走，每一步都有可验证的产出：
RAG不是什么高深算法，而是一套工程系统——文档清洗、切分、检索、重排、评估，每个环节都有实打实的坑。把基础链路做扎实、用评测数据说话，一套能稳定服务业务的知识库问答系统，其实没有想象中那么遥远。如果你正在做AI Agent、自动化或知识库方向的内容创作，欢迎关注本站持续更新的实战指南，也欢迎在爱发电商店获取更多可直接套用的模板与工具。
📚 更多创作资源: https://afdian.com/a/felix007