面试题 · 模型微调
搜索「分块」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请阐述检索增强生成（RAG）的典型实现方式、技术架构以及主要应用场景
离线阶段：知识库构建
在线阶段：检索生成
按学习路线查看教程、项目和面试题。
用户Query → Query处理 → 向量检索 → 重排序 → 上下文组装 → LLM生成 → 输出
↓
[向量数据库] ← Embedding模型 ← 文档知识库关键组件：Embedding模型、向量数据库、重排序模型、大模型
相比微调，RAG无需训练即可更新知识、可追溯来源、成本更低，是知识密集型场景的首选方案。
场景切入
假设我们要给电商客服做一个知识库问答系统，用户问“退货流程”，系统得从文档里找到答案。你打算怎么把文档里的信息变成可检索的东西？整个流程怎么搭建？
层层追问
你做过知识问答类的模型应用吗？……当用户提问时，你是怎么让模型基于私有知识回答的？……那如果知识库里的内容经常要更新呢，你用微调还是检索增强？具体怎么实现？
直球架构
请阐述RAG的典型实现方式和技术架构，包括离线知识库构建、在线检索生成流程，以及它主要用在哪些场景，和微调比有什么优缺点？
这道题其实在问，当大模型遇到它不知道或者记不准的知识时，怎么低成本、可靠地给它补上。我的理解，[[RAG]]本质上就是给模型配一个外挂知识库，让它能查了再答，而不是凭记忆瞎编。
实现方式分两段，离线建库和在线检索。离线阶段，先把PDF、网页这些原始文档解析成文本，然后切成一块一块的，这叫[[分块]]。分块是个很讲究的活，块太大，检索容易漏细节；块太小，上下文又不够。我一般按256到512个token切，保留段落边界，这样语义相对完整。分完块，用[[Embedding]]模型把每块转成向量，存进[[Vector Database]]，比如Milvus或[[Faiss]]。这里有个前提：Embedding模型得跟你的领域匹配，比如法律文档用法律微调过的模型，否则语义距离算不准。
在线阶段，用户来了一个Query，我先做Query理解，有时需要改写或扩展，比如用户说“退钱”，实际意图可能是“退款流程”。然后做[[ANN]]检索，从库里召回Top-K个相关块。但光靠向量检索不够，因为语义相似不等于内容相关，所以我会加一道[[重排]]，用[[Cross-Encoder]]模型精排，把低质量的过滤掉。最后把排好的块拼成Prompt，喂给大模型生成答案。
这里有个坑：很多人以为只靠向量检索就行，但实际场景里，关键词匹配往往能补足向量检索的盲区。比如搜一个产品型号“A100-Plus”，向量可能把它跟“A100”混淆，但[[BM25]]能精确命中。所以落地时，我倾向于用[[Hybrid Search]]，把向量和关键词两种结果合并，再重排，这样召回率和精度都高。
技术架构其实不复杂，就是一条链：Query进来，经过检索、重排、融合，最后生成。关键组件是Embedding模型、向量数据库、重排模型和LLM。但我想强调的是，重排这一步不是可选项，而是必选项。因为原始检索结果里噪声很多，不重排直接给大模型，它会被无关信息带偏，产生[[幻觉]]。
应用场景上，RAG最适合知识密集型任务，比如企业知识问答，内部SOP和规章制度，员工问“年假怎么休”，它能从文档里找到确切条款。还有客服系统，结合历史工单和FAQ，能精准回复退款政策、订单异常这类问题，减少人工介入。再比如研报分析，长文档里抽关键信息，RAG比人翻几百页快得多。
不过，RAG和微调不是二选一，而是互补。比如对高频、固定的知识，微调可以让模型直接记住，省去每次检索的延迟；而对动态更新的知识，比如促销政策，RAG更灵活。所以真正落地的系统，往往是RAG加微调混合用，比如用微调让模型学会理解领域术语，用RAG提供实时知识。
最后说下风险。RAG依赖知识库的质量，如果文档本身有错误或过时，检索出来反而误导模型。所以上线前我会特别关注知识库的更新机制和一致性校验。另外，分块策略直接决定检索精度，块太大会漏细节，块太小会丢上下文，需要根据文档类型调参。
所以我的判断是，RAG不是银弹，但在知识更新频繁、需要可追溯的场景里，它比微调更务实。我更倾向把RAG当成一个可插拔的知识模块，配合微调一起用，而不是二选一。