面试题 · 模型微调
搜索「知识库」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请描述检索增强生成（RAG）的基本工作流程。
用外部知识库"喂"给大模型，解决知识截止和幻觉两大痛点，无需重新训练模型。
按学习路线查看教程、项目和面试题。
| 维度 | 说明 |
|---|---|
| 成本 | 无需训练，API 调用即可 |
| 时效性 | 知识库实时更新 |
| 可解释 | 答案可溯源到具体文档 |
"先搜后答"——让大模型在"开卷考试"环境下作答。
场景切入
假设我们在做一个智能客服，用户问“我的订单什么时候发货”，你直接让大模型回答容易胡扯。如果先查一下知识库里的物流规则再生成答案，这个流程你怎么设计？
层层追问
你一般怎么解决大模型知识过时的问题？……用外部知识库是吧，那具体怎么把外部知识和模型结合起来？……从用户提问到最终答案，中间经历了哪些步骤？
直球架构
请描述RAG的完整工作流程，包括离线和在线阶段，以及每个阶段的关键组件。比如文档怎么处理、检索怎么实现、生成时怎么拼接Prompt。
这道题其实问的是，大模型知识有截止日期还爱胡说，怎么让它基于真实文档来回答。说白了就是给模型一个开卷考试的环境，先搜后答。
具体流程分三段：先离线建个知识库，再在线检索，最后生成答案。
先说建库。原始文档不能直接往里扔，得先[[切块]]，按语义或者固定长度。我一般用语义切分，比如按段落或者用 LangChain 的 RecursiveCharacterTextSplitter，这样一块就是一个完整意思。切完用 [[Embedding]] 模型转成向量，然后存到 [[Vector Database]] 里，比如 [[FAISS]] 或者 Milvus。这里有个前提：Embedding 模型要跟你的业务数据匹配。如果拿通用模型去转金融术语，相似度会跑偏。
再说检索。用户问一个问题，同样转成向量，去库里搜最相似的 Top-K 块。相似度计算用余弦或者内积。但这里有个坑：纯向量检索对关键词不敏感，比如搜订单号或者错误码，向量相似度往往不如 [[BM25]]。所以实际落地我会用 [[Hybrid Search]]，向量和关键词两条路同时走，结果再融合。举个例子，电商客服场景，用户问“我上次买的手机怎么还没到”，向量检索能理解“手机”和“物流”的语义，但如果用户说“订单号 12345 怎么退款”，关键词匹配更准。所以混合检索是标配。
检索完，生成前还有一步：把搜到的文本和原始查询拼成一个 Prompt，扔给大模型。这里有个关键：不是所有搜到的块都有用。如果相似度低于某个阈值，我会直接过滤掉，宁可不答也别乱答。另外，Prompt 里要明确说“请基于以下文档回答，如果文档里没有相关信息，就说不知道”。这样能大幅降低 [[Hallucination]]。
跟微调比，[[RAG]] 的优势很明显：成本低，不用训练模型；数据更新灵活，换一批文档就行；而且答案可溯源，用户问“你凭什么这么说”，你能指回原始文档。但微调也有它的场景，比如想让模型学会特定语气或者输出格式，RAG 做不到。所以真正落地往往是 RAG 加微调配合，RAG 负责事实性，微调负责风格和指令遵循。
另外，RAG 上线后要持续监控召回质量，比如用 [[RAGAS]] 框架评估 [[Faithfulness]] 和 [[Context Recall]]。如果发现召回不准，可能要调切块大小、换 Embedding 模型，或者加 [[Rerank]] 层。
最后说我的判断：我会把 RAG 看成大模型落地的标配能力，而不是锦上添花。因为只要业务需要事实性，RAG 就是最稳的路径。但前提是你得把知识库当工程做，分块策略、检索策略、过滤策略，每一环都可能翻车。