AI开发/产品通用面经大盘点：RAG篇
春招马上就要开始了，不知道各位牛友有没有赶时髦包装一些AI项目呢
第一部分：RAG核心概念与价值
1. RAG是什么？可以说说RAG的流程吗？
RAG的全称是Retrieval Augmented Generation（/rɪˈtriːv(ə)l ɔːɡˈmentɪd ˌdʒenəˈreɪʃ(ə)n/ 瑞吹喔 嗷个曼提特 战弄瑞声）检索 增强 生成，它是一种将检索系统与生成式大模型结合的技术架构。
简单来说，就是当用户提问时，系统不是直接让大模型凭“记忆”回答，而是先去外部知识库里找相关的资料，把这些资料作为上下文喂给大模型，让它依据这些参考信息生成答案。RAG通过在生成前引入外部知识，来弥补大模型在事实性、时效性和私有数据上的不足。
RAG的完整流程主要分为三个阶段：
首先是数据准备阶段，我们需要将原始文档进行清洗、切分，并利用Embedding模型将文本转化为向量存储到向量数据库中；
其次是检索阶段，当用户输入问题后，系统会将问题也转化为向量，在数据库中进行相似度匹配，召回最相关的文档片段；最后是生成阶段，我们将召回的文档片段与用户的原始问题通过Prompt模板组装在一起，输入给大语言模型，模型最终生成融合了外部知识的回答。
2. 为什么要用RAG，RAG与一般的微调方案相比有什么优势？
选择RAG主要是为了解决大模型存在的“幻觉”问题以及知识时效性滞后的短板。
相比于微调，RAG在很多场景下更具优势。
首先是成本更低，微调模型需要大量的算力和高质量的数据集，而RAG只需要维护一个外挂的知识库；
其次是时效性更强，如果企业的业务数据更新了，RAG只需要更新向量数据库即可，可以做到分钟级生效，而微调通常需要重新训练模型，周期很长；
最后是可解释性更好，RAG生成的答案通常可以给出引用的来源文档，方便用户核查事实，而微调后的模型像一个黑盒，很难追溯它为什么这么回答。
当然，微调也有它的价值，它更擅长让模型学习特定的语言风格或指令遵循能力，所以现在很多落地方案是“RAG+微调”的组合拳。
3. 简单说一说RAG的流程，从用户输入文本开始到拿到结果，中间经历了什么？
当用户在界面输入一个文本问题后，这个请求首先会被发送到后端服务。
第一步是“查询预处理”，我们可能会对用户的原始Query进行改写或扩充，比如去除停用词或者补全省略的主语，然后调用Embedding模型将文本转换成高维向量。
第二步是“检索”，这个向量会被拿到向量数据库中进行相似度搜索（通常是余弦相似度），找出前N个最相似的文档块，如果做了混合检索，可能还会并行跑一遍关键词搜索。
第三步是“重排序”，因为向量检索召回的片段可能包含一些相关度虽高但并不精准的噪声，如果对检索准确度有更高的需求，我们会用更精准的Rerank模型对这几十个片段重新打分，选出最靠前的几个。
第四步是“Prompt组装”，我们将筛选出的高质量片段填入预设的System Prompt中，告诉大模型“请根据以下信息回答问题”。
第五步是“生成”，大模型接收到这个包含上下文的长Prompt，开始进行推理，最后将生成的答案以流式或非流式的方式返回给用户。
4. 如何将微调与RAG结合？什么场景需要这样的技术？
这是一种取长补短的策略，通常被称为“RAG-FT”混合模式。
微调主要解决的是“形式”和“能力”的问题，而RAG解决的是“知识”和“事实”的问题。
具体的结合方式是，我们先用高质量的特定领域数据（比如法律文书或医疗报告）对基座模型进行SFT（有监督微调），让模型学会该领域的专业术语、行文风格以及特定的指令遵循格式；
然后在推理阶段，我们依然使用RAG去挂载最新的案例或实时数据。
这种技术通常用于专业壁垒很高的垂直领域，比如医疗问诊，我们需要模型具备医生的口吻和诊断逻辑（靠微调），但同时需要引用最新的药品说明书或医保政策（靠RAG），如果只用RAG，通用模型可能会说外行话；如果只用微调，模型可能会编造不存在的药名。
第二部分：数据处理与检索策略
5. 在RAG项目中，你有留意过chunk的切分方式吗？有哪些切分方式，结合场景展开说说你为什么使用这种方案？
Chunk切分是RAG效果好坏的基石，我非常关注这一块。
切分太细会导致语义碎片化，切分太粗又会引入过多噪声，这些现象都会导致召回成功率下降，并影响最终输出文本的质量。
常见的切分方式有固定字符数切分、按自然段落切分、递归字符切分以及基于语义的切分。
在我最近的项目中，我主要使用的是递归字符切分（RecursiveCharacterTextSplitter）。
因为我们的文档多为技术手册，结构嵌套较深，递归切分可以优先按段落、再按句子切分，能够很好地保留文本的层级结构和完整语义。
对于一些特殊的法律法规文档，我还尝试过“父子索引”(又叫Small-to-big)的切分方案，即检索时匹配小的子块，但给大模型喂数据时召回该子块所属的父块，这样既保证了检索的精准度，又保证了生成时上下文的连贯性。
6. 常见的chunk切分方案有哪些？
目前业界主流的方案大概有四种。
最基础的是“固定大小切分”，简单粗暴地按Token数量或字符数截断，设定一定的重叠窗口（Overlap）来维持连贯性；
进阶一点的是“基于分隔符的切分”，利用换行符、句号等自然语言标记来分割；
比较常用且效果均衡的是“递归切分”，它会尝试用不同的分隔符层级递归地分割文本，直到块的大小合适为止；
最高级的是“语义切分”，通过计算前后句子的Embedding相似度，在语义发生突变的地方进行断句，保证每个Chunk内部的话题是统一的。
此外，针对代码或Markdown文件，还有专门的结构化切分器。
7. 有留意过召回率吗，如何提高召回率？
召回率是检索系统的生命线，我肯定是有留意的。如果在第一步就漏掉了关键信息，后面的大模型再聪明也答不对。
提高召回率的手段主要有几个方面：
首先是采用“混合检索”（Hybrid Search），结合向量检索（语义匹配）和BM25（关键词匹配），既抓住了语义相关性，又防止了专有名词被漏掉；
其次是引入“Query改写”模块，因为用户的提问往往是不完整的，我们可以利用大模型把用户的问题改写成更标准的查询语句，甚至生成多个维度的子问题去并行检索；
再者是使用“假设性文档嵌入”（HyDE），让大模型先生成一个假设性的答案，用这个答案的向量去库里搜，往往比直接搜问题效果更好；
最后，结合评测效果来人工的调整Chunk的大小和重叠率（Overlap）也是一个无需增加成本就能优化召回率的细节。
8. embedding模型和rerank模型的作用是什么？
这两个模型构成了RAG检索链路的“漏斗”结构。
Embedding模型的作用是“海选”，它负责将高维的文本数据压缩成低维的稠密向量，通过计算向量空间距离，快速从海量数据中圈定一个宽泛的候选集（比如Top 100）。它的特点是速度快，但精度相对有限，容易忽略细微的语义差异。
而Rerank模型的作用是“精选”，它通常是一个Cross-Encoder架构的模型，能够同时输入Query和Document进行深度交互计算，精准地评估两者的相关性得分，它的特点是精度极高，但计算开销大。
综合来看，我们在实际业务开发中，选择只对Embedding粗排回来的那几十条数据进行重排序，最终选出Top 5喂给大模型。可以说，Embedding决定了下限，Rerank决定了上限。
第三部分：架构选型与进阶技术
9. 你用的是什么框架实现的，为什么选择这个框架？(以AI-SDK、Langchain为例)
在之前项目中，针对不同的业务需求，我分别使用过LangChain和Vercel AI SDK。
如果是构建后端逻辑复杂、需要深度定制检索链路或者涉及多步推理链（Chain）的系统，我会选择LangChain。它的生态非常丰富，集成了几乎所有主流的向量库和模型接口，内置了大量的Document Loaders和Splitters，非常适合快速搭建功能完备的RAG后台。
但如果是开发面向用户的全栈Web应用，特别是基于Next.js架构时，我会倾向于使用Vercel AI SDK。它的优势在于极致的工程化体验，对流式传输（Streaming）的支持非常丝滑，能够轻松实现打字机效果，且包体积更小，更适合前端开发者直接调用，能极大地提升产品的首屏响应速度和交互体验。
10. 听说过Agentic RAG/Graph RAG吗，它的优势是什么？
这两个都是RAG目前的前沿演进方向。
Agentic RAG（代理式RAG）是把RAG从“一个静态流程”变成了“一个智能体”。在这个模式下，模型不仅是回答者，还是决策者，它会自己判断“现有的资料够不够？如果不沟，我要不要去搜Google？或者去查数据库？”，它支持多步推理和工具调用，优势在于处理复杂、多维度的查询时更加灵活，能自我纠错。
而Graph RAG（图谱RAG）则是引入了知识图谱，将文档转化为实体和关系的网状结构。它的优势在于能处理“跨文档的全局性问题”或者“隐式关系推断”，比如问“文档库里提到的所有CEO之间有什么共同点？”，传统RAG很难通过向量相似度把这些散落在不同文档的碎片关联起来，而Graph RAG可以通过图遍历找到答案，显著提升了回答的深度和全面性。
11. 多模态RAG是什么，有了解吗？如何实现，说说你的思路？
多模态RAG是指系统不仅能检索文本，还能检索图片、表格甚至音频来辅助生成。
对于实现思路，核心难点在于“对齐”。我会采用像CLIP这样的多模态Embedding模型，将图片和文本映射到同一个向量空间。当用户输入文本时，我们可以同时检索相关的文本片段和图片。
对于检索到的图片，有两种处理方式：一种是直接把图片喂给支持多模态输入的大模型（如Gemini，GLM4.6V，Qwen3.5Next）；另一种是利用VLM（视觉语言模型）预先给图片生成详细的文本摘要，建立索引时存的是摘要文本，检索时也是搜摘要文本，这是一种更低成本的兼容方案。
在最近的调研中，我也在关注ColPali这类新型模型，它能直接对PDF的页面截图进行向量化检索，保留了排版信息，这对于处理包含复杂图表的文档非常有效。
第四部分：评测与优化
12. 有没有搭建过RAG评测集，如何测试RAG的质量？
搭建评测集是RAG项目上线前的非常重要的一环。
在项目开发中，我通常采用“黄金数据集”的策略，即人工或利用大模型辅助生成一系列“问题-参考文档-标准答案”的三元组。
测试RAG质量时，我主要关注两个维度的指标：检索层和生成层。
检索层我看重Recall@K和MRR（平均倒数排名），确保正确的文档被排在前面；
生成层我会使用RAGAS框架，它提供了Context Precision（上下文精确度）、Faithfulness（忠实度）和Answer Relevance（答案相关性）等指标。具体的做法是，让大模型作为“裁判”（LLM-as-a-Judge），去打分判断生成的答案是否忠实于检索到的上下文，以及是否回答了用户的问题。通过这套自动化评测管线，我们可以在每次代码迭代后快速量化效果。
13. 如果RAG生成时间太长，你会怎么排查，从哪些方面下手优化？
RAG的延迟通常来源于三个环节：检索耗时、网络传输和LLM生成耗时。我会先打点日志看各个阶段的耗时分布。
如果是检索慢，我会检查向量库的索引类型（是否用了HNSW等近似索引）或者考虑减少Rerank的候选文档数量；
如果是Embedding慢，可以尝试更换更轻量级的Embedding模型；
但绝大多数时候瓶颈在大模型生成上。针对这一点，优化手段包括：开启流式输出（Streaming），让用户先看到首字，降低心理等待时间；
缩减Prompt长度，精简检索回来的Chunk，只保留最核心的片段；
或者切换推理速度更快的模型（如使用Lite、Flash的低参数模型）。
另外，引入语义缓存（Semantic Cache）也是一个方法，对于重复的高频提问，可以直接返回缓存的答案，可以将延迟降到毫秒级。
#聊聊我眼中的AI##AI求职实录#
查看8道真题和解析