面试题 · 模型微调
请分析RAG系统在实际应用中的深度和局限性，并讨论可能的优化方向和改进方案。
优势层面
技术深度体现
学习内容与项目面试，在同一条路上。
| 局限类型 | 具体表现 | 典型场景 |
|---|---|---|
| 检索质量瓶颈 | 语义匹配≠相关性，Top-K可能漏关键信息 | 专业术语、多义词 |
| 上下文碎片化 | 长文档切块导致逻辑断裂 | 技术文档、法律条款 |
| 推理能力边界 | 弱于多跳推理、数值计算、跨文档归纳 | 财报分析、科研综述 |
| 系统耦合复杂 | 检索失败时缺乏优雅降级机制 | 边缘Query、新领域 |
1. 检索层：混合检索+重排序
2. 查询层：意图理解与改写
3. 生成层：上下文工程
4. 系统层：反馈闭环
RAG不是万能解，需与SFT、Agent协同：
美团场景示例：外卖菜品知识用RAG实时更新，但下单对话策略用SFT固化，复杂售后链路用Agent调度。
场景切入
假设你做电商客服，用户问“我的订单为什么还没到”，RAG系统去检索物流知识库。如果用户又问“那退货运费呢”，这时候检索容易跑偏，你遇到过这种场景吗？实际落地中RAG深度和局限在哪儿？
层层追问
你觉得RAG相比纯大模型生成，优势主要在哪？……那它有什么明显的短板？……比如多跳推理或者长文档处理？针对这些，你会怎么优化？
直球架构
请你分析一下RAG系统在实际应用中的深度和局限，然后给出至少三个具体的优化方向，包括方案细节和可行性。不用讲基础概念，直接说痛点和解法。
这道题问的是[[RAG]]在实际落地中到底能挖多深、又卡在哪里，我觉得本质是在考你对系统取舍的判断力。RAG不是银弹，它的核心价值在于让模型能动态接入外部知识，不用重新训练就能更新信息，同时每句话都能溯源到原文，这对合规审计类场景特别关键。成本上也很友好，相比全量微调，RAG的边际成本低得多，适合那些频繁变动的业务知识。
但局限也很明显。首个大问题是检索质量不够稳，语义匹配不等于真的相关，比如搜「苹果」可能召回水果和手机混在一起，Top-K里关键信息反而漏了。接着说上下文碎片化，长文档一[[切块]]逻辑就断了，技术文档里前后依赖的条款很容易被割裂。再补充推理能力弱，多跳推理、数值比较这些，RAG天生不擅长。
所以优化方向其实很明确。先说检索层，我倾向用[[Hybrid Search]]，把向量检索的语义能力和[[BM25]]的关键词精准度结合起来，再加一层[[重排]]，用[[Cross-Encoder]]精排，而不是只靠余弦相似度粗排。这样专业术语和同义词的匹配能好很多。查询层也很重要，做查询改写，把复杂问题拆成子查询，比如「去年Q3和Q4的营收对比」拆成两个独立查询再聚合。生成层可以做上下文压缩，用一个小模型先提取关键句，减少噪声。
这里有个坑：很多团队一上来就堆技术，但忽略了一个前提，数据质量。如果文档本身就有矛盾或者格式混乱，检索质量根本救不回来。所以上线前我一定会花时间做数据清洗和标注，不然检索框架再强也是白搭。
另外，RAG不是孤立的。高频稳定的知识适合用[[SFT]]内化到模型参数里，而动态海量的知识才外挂成RAG。真正落地常常是RAG加微调一起上。比如外卖场景，菜品知识更新快用RAG，但下单对话策略这类高频稳定的逻辑就用微调固化。复杂售后链路再交给[[Agent]]来调度。
说到Agent，我觉得下一步有意思的方向是把RAG当成Agent的一个工具，让模型自己决定什么时候去查、查什么、怎么综合多个来源。这样能突破RAG当前多跳推理和跨文档归纳的瓶颈。
所以整体上，我更倾向把RAG看作一个系统工程，从数据清洗到检索到生成再到反馈闭环，每个环节都要有兜底机制。比如检索置信度低于阈值时，主动澄清或者转人工，而不是硬生成一个可能错误的结果。这才是工程上靠谱的做法。