前言
字节面试官问的第一个问题是："你说RAG不就是给大模型挂个知识库吗？"这句话听着像陈述句，其实是个陷阱。如果你只回答"对，就是检索+生成"，这题基本就凉了。面试官真正想考察的是：你能不能把RAG拆开来，讲清楚每一步的工程细节。
面试中高频追问还有：文档怎么切分？向量数据库怎么选？什么是Re-rank？多路召回具体怎么做？怎么量化评估RAG效果？这些问题每一个都能展开聊很久。下面就把这次面试中被问到的RAG核心知识梳理一遍，从概念定义到工程落地，把容易答浅的点都补上。
一、大模型为什么需要外挂
面试官问"大模型为什么需要外挂"时，真正想听的不是一句话定义，而是你对大模型局限性有清晰认知。大模型有三个硬伤：
第一，知识有截止日期。 模型知识来自训练数据，而训练数据有时间窗口。某个版本的训练数据截止到2023年4月，那之后的任何事情它都不知道，要么老实说"不知道"，要么开始编。
第二，不知道私有数据。 公司的产品文档、内部规章、客户信息、项目资料------这些从来没有出现在训练集中，模型不可能凭空知道。你问它"公司年假政策是什么"，它只能告诉你"我无法获取你们公司的内部信息"，或者一本正经地编一套听起来头头是道但全是错的答案。
第三，会幻觉。 幻觉就是模型非常自信地说出一些听起来专业但完全是编造的内容。问它一个不存在的研究论文，它能给你编出标题、作者、摘要甚至DOI号，像模像样但全是假的。这在医疗、法律、金融等高准确性场景中不可接受。
理解了这三个困境，RAG要解决什么就清楚了：给大模型"开卷考试"，允许它翻参考书。模型不再靠脑子记所有知识，而是先从外部知识库检索出相关资料，再基于这些真实资料生成回答。
二、RAG到底在解决什么问题
RAG的全称是Retrieval-Augmented Generation，翻译过来就是"检索增强生成"。核心思想拆成三步：先从外部知识库中检索出和用户问题相关的资料，把检索到的资料作为增强上下文与用户问题一起给到大模型，大模型基于这些真实资料生成回答。
这样一来，大模型的回答就有了依据，不再凭空编造。知识可以随时更新（更新知识库就行），私有数据也能用了（把公司文档放进知识库），幻觉问题也大幅减少（有真实资料做参考）。
RAG这个概念最早由Facebook（现Meta）研究团队在2020年提出，思路就是在模型回答问题前先从外部文档检索相关内容再喂给模型。但2020年大模型还没火，RAG只是学术圈讨论。真正让它火起来的是2023年ChatGPT爆红后，大家发现大模型在实际应用中有那么多局限性，而RAG恰好能补上。到如今，RAG已经是企业落地AI应用的标配技术。
但RAG不是万能的。它解决的是"大模型缺乏特定知识"的问题，但不能改变模型的推理能力（模型本身推理不行给再多资料也没用），不能改变输出风格（需要特定风格回答得靠微调），也不能保证100%准确（检索可能召回错误文档，模型也可能曲解内容）。RAG更准确的定位是一种让大模型基于真实可更新知识来回答问题的技术方案，和微调、Prompt Engineering是互补关系。
三、RAG整体工作流程
一个完整的RAG系统分两大阶段：索引阶段（离线）和查询阶段（在线）。很多同学对RAG的理解停留在"就是检索+生成"，但真正搭建远比这复杂。
用开卷考试打比方：考试前你得先把参考书整理好------给每本书贴标签、做目录索引、标注重点内容。这就是索引阶段，是考前完成的准备工作，不需要实时响应。考试开始后拿到题目，先理解题目问什么，再在参考书中快速定位相关章节，阅读找到的内容，最后组织答案。这就是查询阶段，实时进行、需要快速响应。
索引阶段的目标是把各种非结构化文档变成可高效检索的形式，通常包括：文档加载（把PDF、Word、Excel、PPT、HTML、Markdown等格式统一转成纯文本）、文档切割（把长文档切成小的文本块）、向量化（把每个文本块转换成数学向量）、存入向量数据库（建立可做相似度搜索的索引）。
查询阶段则包括：用户提问向量化（用同样的Embedding模型把问题转成向量）、相似度检索（在向量库中找Top-K个最相近的文本块）、构造增强Prompt（把检索结果和原始问题拼在一起）、大模型生成回答（基于真实参考资料生成答案）。
这是最基础的RAG流程，也叫Naive RAG。生产环境中为了提升效果还会加入查询改写、多路召回、重排序（Re-rank）等高级技术，后面会展开讲。
四、索引阶段：把知识整理好
索引阶段的第一个环节是文档加载。企业里的文档格式五花八门，PDF、Word、Excel、PPT、HTML、Markdown，每种格式解析方式不同。PDF尤其麻烦，包含表格、图片、多栏排版时解析很费劲。这一步的目标是把各种格式统一转成纯文本。
第二个环节是文档切割（Chunking），也是索引阶段最关键的步骤之一。不能把一整本100页的文档直接扔给大模型------上下文窗口有限。需要切成长度几百到几千字符的文本块。但切割这事不像看起来简单：机械地按固定长度切，很可能一句话被切成两半，一个完整段落被拆开，检索时丢失上下文。
切割策略有多种选择：固定长度切割（按字符数，简单粗暴但容易断语义）、按段落/标题切割（保留语义完整性但块大小不均）、递归切割（先按大段落切，超长段落再递归细分）、语义切割（用模型判断语义边界，效果最好但成本高）。选哪种策略取决于文档结构和业务需求，没有万能方案。
第三个环节是向量化（Embedding）。把每个文本块转换成高维向量------可以理解成Embedding模型把一段文本"翻译"成高维空间中的坐标点，语义相近的文本在这个空间中距离也相近。"今天天气很好"和"今天阳光明媚"意思差不多，向量距离就近；"今天天气很好"和"Python是一种编程语言"意思差远，向量距离也远。
第四个环节是存入向量数据库。向量数据库专门用来存储和检索向量，能高效做相似度搜索------给一个查询向量，快速找到最相近的Top-K个向量。这一步做完，知识库就建好了。
五、查询阶段：让大模型翻书找答案
知识库建好后，用户提问就进入查询阶段。
第一步，用户提问向量化。用户问"公司年假政策是什么"，系统用和索引阶段相同的Embedding模型把问题也转成向量。这里有个关键点：查询用的Embedding模型必须和建库时一致，否则两个向量不在同一个空间里，相似度计算没有意义。
第二步，相似度检索。拿着问题向量去向量库做相似度搜索，找到语义最相近的Top-K个文本块。比如可能检索出："公司全职员工入职满一年后享有10天带薪年假""年假可以拆分使用，每次不少于半天""未使用的年假可以累积到下一年，但最多累积5天"。
第三步，构造增强Prompt。把检索出的文本块和用户原始问题拼在一起，构造类似："请根据以下参考资料回答用户的问题。参考资料：检索出的文本块。用户问题：公司年假政策是什么？"
第四步，大模型生成回答。把增强Prompt发给大模型，大模型基于这些真实参考资料生成回答。有了具体参考资料，就不会凭空编造了。
但基础流程有几个问题：检索只靠单路向量相似度，召回率有上限；Top-K的K值不好定，太小漏召回、太大引入噪声；检索结果排序不一定合理，最相关的块可能排在后面。生产环境需要加多路召回和Re-rank来补。多路召回是除了向量检索外再加一路关键词检索（BM25），两路结果合并去重。Re-rank则是用专门的排序模型对召回结果做精排，把最相关的推到前面。
六、微调与RAG的本质区别
想让大模型学会新知识，除了RAG还有微调（Fine-tuning）。面试官常问"这俩有什么区别，什么时候该用哪个"，这个问题必须答清楚。
微调是拿一个预训练好的大模型，用自己的数据对它进一步训练，让它在特定领域或特定任务上表现更好。打个比方，大模型预训练完就像高中毕业生，知识面广但都不深；想让它当专业医生，就送它去医学院继续学，这个过程类似微调。
微调有不同级别。全量微调更新模型所有参数，效果最好但成本极高，需要大量GPU资源。参数高效微调（如LoRA）只训练一个小的低秩适配器，不动模型主体，硬件需求大幅降低，一张消费级显卡就能跑。指令微调用"指令-回答"格式数据来微调，让模型学会听懂指令、按指令回答。
两者的核心区别可以用一个类比说清楚：微调相当于让模型去上了一门课，知识已经"内化"到脑子里，考试时是闭卷考试，靠记忆回答，但记忆可能出错且新知识需要重新上课（重新训练）。RAG相当于给模型配了参考书架，考试时是开卷考试，可以翻书找答案，参考书随时更新，新增知识不需要重新训练模型。
选型原则：需要模型掌握某个领域的推理方式或输出风格→微调；需要模型能回答特定知识问题→RAG；两者可以叠加使用，先用微调让模型具备领域理解力，再用RAG补充实时知识。
七、文档切割策略的关键细节
文档切割是RAG系统中看似简单实则关键的环节，面试官经常在这里深挖。
固定长度切割。 按字符数（如500字、1000字）切，实现最简单。但问题明显：一句话可能被切成两半，一个完整段落被拆开，检索时上下文断裂。实际工程中通常配合重叠（Overlap）来缓解------相邻块之间保留50-200字的重叠区域，减少语义断裂。
按结构切割。 按段落、标题、章节等文档自身结构来切。好处是保留了语义完整性，坏处是块大小不均匀，有些段落太长超出模型处理能力，有些太短信息密度低。适合结构清晰的文档（如Markdown、HTML）。
递归切割。 先按大粒度（如章节）切，如果某块仍然超长，再按小粒度（如段落）递归切分，直到每块都在目标范围内。这是LangChain等框架的默认策略，兼顾了语义完整和长度控制。
语义切割。 用模型判断语义边界，在话题转换处切分。效果最好但成本最高，需要额外调用Embedding模型或LLM。适合对检索质量要求极高的场景。
切割粒度的选择也讲究。块太小（如100字），单个块信息量不足，需要召回更多块才能拼出完整答案，增加噪声。块太大（如2000字），单个块信息过多，大模型提取关键信息困难，且消耗更多Token。常见选择是300-800字，配合50-150字重叠。
八、向量数据库选型考量
向量数据库是RAG系统的核心存储层，面试中常问"做过向量数据库选型吗"。
主流选项对比。 Pinecone是托管型SaaS，开箱即用、免运维，但成本随数据量增长明显，且数据存在第三方。Milvus是开源向量数据库，支持大规模、分布式部署，社区活跃，但运维复杂度较高。Weaviate也是开源方案，内置多路召回和混合检索支持，开箱即用程度介于Pinecone和Milvus之间。Qdrant用Rust写的，性能好、资源占用低，适合对延迟敏感的场景。Chroma轻量级，适合原型验证和小规模场景。PgVector是PostgreSQL的向量扩展，如果已有PG技术栈，加个扩展就能用，运维成本最低。
选型考量维度。 数据规模：百万级向量以下，Chroma或PgVector够用；千万级以上，考虑Milvus或Pinecone。查询延迟：在线场景要求毫秒级响应，Qdrant和Pinecone表现好。运维能力：团队有DBA经验选Milvus/Weaviate，没有选托管型Pinecone。数据合规：不能把数据放第三方，排除Pinecone选开源方案。成本预算：数据量大且预算紧，选开源自建；数据量小或预算充足，选托管省心。
Embedding模型选型。 向量数据库只是存储层，检索质量更多取决于Embedding模型。OpenAI的text-embedding系列效果稳定但收费。开源模型如BGE、M3E在中文场景表现好且免费。选模型时关注维度（维度越高表达力越强但存储和计算成本也高）、语言支持（中英文混合场景选多语言模型）、最大输入长度（要和切割粒度匹配）。
九、RAG效果如何量化评估
RAG系统上线后怎么评估效果？面试官问"怎么量化你的RAG效果"时，只说"看看回答对不对"是不及格的。
检索环节评估。 检索质量决定上限，生成质量决定下限。检索评估常用指标：召回率（Recall，相关文档是否被召回）、精确率（Precision，召回的文档中有多少相关）、MRR（Mean Reciprocal Rank，第一个相关文档的排名倒数）。需要准备一批标注好正确答案和对应文档的测试集，跑检索后计算这些指标。
生成环节评估。 生成质量评估更主观，常用方法有人工评估（标注员对答案打分，准确但慢）、LLM-as-Judge（用另一个大模型当裁判打分，快但有偏见风险）、BLEU/ROUGE等文本相似度指标（和标准答案比文本重合度，简单但不够智能）。RAGAS框架把检索和生成统一评估，包含Faithfulness（答案是否忠于检索内容）、Answer Relevancy（答案是否切题）、Context Precision（检索上下文精确率）、Context Recall（检索上下文召回率）四个维度。
端到端评估。 最终看的是用户体感，常见做法是灰度上线后收集用户反馈（点赞/点踩）、跟踪问答日志中"无法回答"的比例、监控用户追问率（追问多说明首次回答不满足）。这些业务指标比技术指标更能反映真实效果。
降低幻觉的方法。 RAG虽然减少了幻觉但不能消除。进一步降低的手段包括：在Prompt中明确要求"如果参考资料中没有答案请直接说不知道"；对检索结果做相关性过滤，低相关性的块不要给模型；调整Top-K值，质量优先于数量；使用Re-rank确保最相关的块排在前面。
总结
这次面试把RAG从"挂个知识库"这五个字拆开来聊，核心知识点可以收拢成几条。
RAG的本质是给大模型开卷考试，解决的是知识截止、私有数据缺失、幻觉三个困境。它不是万能的------不能改变模型推理能力、不能改变输出风格、不能保证100%准确------和微调是互补关系而非替代。
RAG系统分离线索引和在线查询两大阶段。索引阶段做文档加载、切割、向量化、入库；查询阶段做提问向量化、相似度检索、构造增强Prompt、生成回答。生产环境还要加多路召回和Re-rank来提升检索质量。
文档切割策略（固定长度、按结构、递归、语义）和切割粒度直接影响检索效果。向量数据库选型要看数据规模、延迟要求、运维能力和合规需求，Embedding模型的选择比数据库选择更影响检索质量。效果评估要分检索环节（召回率、精确率、MRR）和生成环节（Faithfulness、Answer Relevancy），最终回归业务指标。
面试官那句"RAG不就是给大模型挂个知识库"是故意说浅的，真正能拉开差距的是你对每个环节工程细节的掌握深度。能讲清楚"为什么这么做"比"知道要这么做"更值钱。