字节一面：说说 RAG 的完整流程，越详细越好
面试官：你们项目用了 RAG，能说说完整的流程吗？越详细越好。
我：先把文档切块，然后向量化存进向量数据库，用户提问时检索出相关内容，把内容和问题一起送给大模型生成答案。
面试官：好，那文档进来之后有没有做预处理？直接切块的？
我：有，用 PDF 解析工具提取文本，然后按 512 个 token 切块。
面试官：PyPDF2 提取出来的表格是什么格式？里面的行列关系还在吗？
我：表格会变成一段文字，中间用空格分隔。
面试官：那这段文字向量化之后，检索效果怎么样？用户问”A产品价格是多少”，能准确找到表格里那一行吗？
我：……应该还好吧。
面试官：你觉得整个流程里，哪个环节最容易出问题，工程时间花得最多？
我：我觉得是生成环节，大模型有幻觉。
面试官：其实不是。你们真正花时间最多的那个环节，通常既不是生成，也不是向量化。
今天把这道题彻底讲清楚。
简要回答
RAG 的完整流程分两个阶段，共 5 个核心环节。
索引阶段（一次性，提前完成）：文档预处理、文本分块、向量化建库。
查询阶段（每次用户提问时实时执行）：查询处理和检索、生成。
竞品几乎所有的流程介绍都只画一条干净的箭头。现实里每个环节都有自己的失败模式。真正区分”用过 RAG”和”背过 RAG”的，是你能不能说出哪个环节最容易出问题，以及出问题的时候你是怎么发现和修的。
结论先放：影响效果最大的环节是检索，工程时间花得最多的环节是文档预处理。
环节一：文档预处理（最被低估的环节）
文档上传进来，不能直接就用。真实的业务文档通常是 PDF、Word 或 HTML，里面夹着表格、图片、页眉页脚、水印，甚至有些是扫描件。
把文档比作一份带格式的外卖菜单，你要先把菜单上的有效信息抄到一张白纸上，才能开始处理。预处理就是这个”抄写”的过程，不同的文档类型，抄写难度差很多。
纯文本和 Markdown 最简单，几乎不需要额外处理。问题出在 PDF 上。
PDF 分两种：可编辑 PDF 和扫描 PDF。
可编辑 PDF 里文字是可以选中的，可以用 PyMuPDF 或 pdfplumber 提取。但提取出来的文本不等于”正常文本”，格式信息会丢失。一个两列的表格，提取出来可能变成两行文字混在一起，列与列之间的关系完全消失了。用户问”A 产品的价格是多少”，表格里确实有这一行，但提取出来的文本里价格和产品名已经错位，向量化之后检索出来是乱的。
扫描 PDF 里没有可选中的文字，需要先做 OCR（光学字符识别）。OCR 在中文字体上的识别准确率通常在 95% 左右，但 5% 的错误率在一个 10000 字的文档里意味着约 500 个错别字，这会直接拉低 Embedding 的质量。
常见预处理失败模式：表格被展平成无结构文字（列关系丢失）、OCR 扫描件错别字、页眉页脚保留进来干扰语义、图片内容完全丢失。
这里有一个反直觉的结论：实际项目里，花时间最多的通常是预处理，而不是向量化或模型调优。我们做某个企业知识库项目时，处理文档预处理问题花了两周，向量化和检索调通只花了两天。面试里主动说出这一点，是区分”真做过”和”背过流程”的关键。
环节二：文本分块和向量化建库
文档清洗完之后，进入分块环节。这一步决定了知识库里每条”记录”包含多少信息。
把分块想象成把一本字典拆成一张张词条卡片放进抽屉。卡片太小，一张卡片只写了半句话，没有上下文；卡片太大，一张卡片里塞了五六个主题，检索时很难精准匹配。
分块之后是向量化（Embedding）。每一块文本通过 Embedding 模型转成一个向量，存进向量数据库。向量数据库会为这些向量建立 HNSW 索引（一种层级图结构），让后续的近似最近邻搜索能快速完成。
这个环节相对稳定，只要 Embedding 模型选得合理，中文场景优先选 BGE 系列，不容易出大问题。有一点需要记住：如果一个完整的知识点被分块切断成两块，单独召回其中一块就得不到完整答案。这是分块策略调优期间最频繁出现的召回问题来源，和 Embedding 模型本身无关。
环节三：查询处理和检索（效果天花板在这里）
用户提问来了，系统要做的第一件事不是直接去检索，而是处理用户的问题。
用户的原始问题往往口语化、不完整，甚至带着代词（”刚才那个功能怎么用”）。更深层的问题是：用户的问法是疑问句，知识库里的文档是陈述句，这两种文体在向量空间里的坐标并不完全重合，直接拿原始问题去检索，效果通常不够好。
查询的完整处理链路：用户问题 → （可选：Query 改写 / 关键词提取）→ 转成向量 → 向量库里找 Top-K 最相似的块 → 过滤和排序 → 返回结果。
这一步是整个 RAG 系统效果的天花板。不管大模型有多强，检索不到正确的内容，生成就没有原材料可用。实际项目中，75% 的回答质量问题都可以追溯到检索环节，而不是生成环节。
一个典型的检索失败场景：用户问”骨折住院能报销多少”，知识库里写的是”因意外伤害导致骨骼骨折，住院治疗费用可按 70% 比例报销”。语义相近，但具体词汇不同，如果用纯向量检索，相似度可能不够高，这一段排在 Top-10 之外，召回失败。
另一个场景：用户问”A 产品和 B 产品的价格和保障范围分别是什么”。这个问题对应至少 4 个不同的文档片段，单次检索只能找到其中一部分，答案天然不完整。
环节四：生成
检索回来的 Top-K 块被组装成 Prompt，送给大模型生成最终答案。Prompt 的基本结构通常是：系统指令 + 检索到的文档块 + 用户问题。
这一步有两个容易被忽略的细节。
第一，Prompt 里的约束指令要明确。如果只说”参考以下资料”，模型有时候会把资料和训练数据里的知识混合使用，产生”半幻觉”，答案里一部分来自文档，一部分是编造的。改成”只能基于以下资料，资料里没有的不要回答”，效果会明显好很多。
第二，文档的排列顺序影响生成质量。研究表明，LLM 对 Prompt 里中间位置的内容注意力最低，这个现象叫 Lost in the Middle。如果把相关度最高的块放在 Prompt 结尾而不是中间，生成质量会更高。这是很多项目没有做的细节优化。
生成环节的幻觉问题是真实存在的，但它不是 RAG 里最难解决的问题。80% 的生成幻觉来源于检索失败，而不是模型本身，所以优先优化检索，比反复调 Prompt 更有效率。
对比总结
面试总结
回答”说说 RAG 的完整流程”，常见的失分点是只画了一条干净的箭头，没有提任何失败模式。面试官想知道的不只是你知道这条链路，而是你是否真的做过、踩过坑。
回答可以按三个层次来讲：
第一步（20 秒）：先说两个阶段五个环节，不要上来就细说每一步。”RAG 分两个阶段，索引阶段三步：预处理、分块、向量化建库；查询阶段两步：检索和生成。”
第二步（60 秒）：展开每个环节，重点说失败模式，不要平铺直叙。”每个环节都有自己的坑，但影响效果最大的是检索，不是生成。75% 的回答质量问题来自检索召回不准，而不是大模型幻觉。”然后举一个具体的 badcase，比如”用户问骨折，文档写的是骨骼损伤，向量相似度不够高，召回失败”。
第三步（20 秒）：主动说工程时间分布，给出一个反直觉的结论。”实际项目里，花时间最多的不是向量化，也不是模型调优，而是文档预处理。原始文档格式复杂，表格和扫描件的处理往往花掉三分之一的工程时间。”
如果面试官追问”你们项目哪个环节遇到的问题最多”，回答要点是：检索环节。给出具体指标，比如初始版本召回命中率只有 68%，通过分块策略优化和 Query 改写提升到 85%，这样的答案比泛泛说”检索不准”有说服力得多。
如果面试官追问”生成环节的幻觉怎么解决”，回答要点是：幻觉大部分来自检索失败，优先提升检索质量；其次是 Prompt 里加明确约束，强制模型只参考检索内容，不要用训练数据里的知识补充；最后考虑的才是模型本身。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～