完整题目
请阐述检索增强生成（RAG）的典型实现方式、技术架构以及主要应用场景
本文目录
答案要点
- 离线知识库构建流程（文档解析、分块、向量化、索引存储）
- 在线检索生成流程（Query改写、向量检索、重排序、上下文融合）
- RAG vs 微调的选择权衡
- 典型应用场景举例
典型实现方式
离线阶段：知识库构建
- 文档解析：处理PDF/Word/网页等多格式，提取结构化文本
- 文本分块：按语义或固定长度切分，通常256-512 tokens，保留段落边界
- 向量化：用Embedding模型（如BGE、M3E）将chunk转为向量
- 索引存储：存入向量数据库（Milvus、Faiss、Elasticsearch）
在线阶段：检索生成
- Query理解：必要时进行Query改写、扩展、意图识别
- 向量检索：用ANN算法快速召回Top-K相关chunk
- 精排优化：Cross-Encoder重排序，过滤低质量内容
- 上下文融合：将检索结果拼接为Prompt上下文，约束模型生成
技术架构
用户Query → Query处理 → 向量检索 → 重排序 → 上下文组装 → LLM生成 → 输出
↓
[向量数据库] ← Embedding模型 ← 文档知识库关键组件：Embedding模型、向量数据库、重排序模型、大模型
主要应用场景
- 企业知识问答：内部文档、规章制度、产品手册的智能问答
- 客服系统：基于历史工单和FAQ的精准回复，减少幻觉
- 研报/法律分析：长文档信息抽取与综合分析
- 代码助手：结合私有代码库和开源文档的编程辅助
核心优势
相比微调，RAG无需训练即可更新知识、可追溯来源、成本更低，是知识密集型场景的首选方案。
换一种问法，检查是否真正理解
场景切入
假设我们要给电商客服做一个知识库问答系统，用户问“退货流程”，系统得从文档里找到答案。你打算怎么把文档里的信息变成可检索的东西？整个流程怎么搭建？
层层追问
你做过知识问答类的模型应用吗？……当用户提问时，你是怎么让模型基于私有知识回答的？……那如果知识库里的内容经常要更新呢，你用微调还是检索增强？具体怎么实现？
直球架构
请阐述RAG的典型实现方式和技术架构，包括离线知识库构建、在线检索生成流程，以及它主要用在哪些场景，和微调比有什么优缺点？
练习口述回答 · 约4分钟
- 本质是知识外挂，解决大模型知识滞后和幻觉
- 离线建库：分块、向量化、索引，关键在分块粒度
- 在线检索：Query改写、ANN检索、重排、融合，Hybrid Search是常态
- 落地风险：重排不能缺、知识更新实时性、Chunk大小影响精度
- 应用场景：企业问答、客服、长文档分析，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依赖知识库的质量，如果文档本身有错误或过时，检索出来反而误导模型。所以上线前我会特别关注知识库的更新机制和一致性校验。另外，分块策略直接决定检索精度，块太大会漏细节，块太小会丢上下文，需要根据文档类型调参。