完整题目
在RAG系统中，当新文档与历史文档存在语义或分布差异时，可能引发检索偏差，影响系统鲁棒性。请结合实际应用场景，提出可行的技术策略，并解释其如何缓解此类问题。
本文目录
问题本质
新文档与历史文档的分布差异会导致：① embedding空间不对齐（语义相近但向量距离远）；② 检索结果被历史文档主导（索引偏置）；③ 相关性打分失效。
技术策略
1. 动态索引与增量更新
- 新文档单独建索引，检索时多路召回（历史索引+增量索引），结果融合排序
- 美团外卖场景：新商家/新菜品实时入增量索引，避免全量重建延迟
2. 查询重写与扩展
- 用LLM将用户query改写为多个视角（时间敏感型、通用型），分别检索后聚合
- 例："附近好吃的" → 扩展为"2024新店推荐"+"高评分老店"
3. 自适应向量微调
- 收集新文档的点击/转化反馈，用对比学习微调embedding模型（LoRA轻量更新）
- 关键：混合采样新旧数据，防止灾难性遗忘
4. 分布感知的重排序
- 训练阶段引入领域标签，推理时检测query分布，动态调整检索策略
- 监控新文档的检索占比，低于阈值时触发告警
落地关键
- 监控看板：新文档命中率、头部结果多样性指标
- A/B实验：灰度验证策略效果，避免全量风险
学习建议
建议掌握RAG基础架构，理解检索偏差成因，学习持续学习、向量重排序、数据分布监控等技术，结合实际案例思考系统优化。
换一种问法，检查是否真正理解
场景切入
假设你做一个电商客服RAG系统，上个月的知识库全是夏季商品，现在上新了一批秋冬装，结果用户问“推荐厚外套”，检索出来的全是T恤。你觉得问题出在哪儿？怎么从技术层面避免这种新老文档的偏差？
层层追问
RAG系统里，如果新加入的文档和原来分布不一样，检索效果可能会变差，你遇到过吗？……那具体是什么原因导致的偏差呢？……有什么策略可以缓解，让系统对新旧文档都公平？
直球架构
RAG系统中新文档与历史文档存在分布差异，导致检索偏差。请你设计策略来提升系统鲁棒性，会从索引、检索、模型、排序哪些方面入手？具体怎么缓解embedding不对齐或索引偏置？
练习口述回答 · 约4分钟
- 一句话点本质：新老文档分布差异导致 embedding 空间不对齐和索引偏置
- 核心策略：增量索引加多路召回，解决实时性和偏置问题
- 分布感知的重排序：训练时引入领域标签，推理时动态调整
- 落地风险：监控新文档命中率，A/B实验灰度验证
- 收尾与可延伸点：更倾向轻量增量更新，追问新文档量级影响
这道题其实是在问，当新文档和老文档在语义或分布上有明显差异时，怎么保证检索系统不偏科、不失效。本质上是 [[embedding]] 空间不对齐 和 索引偏置 两个问题，新文档在向量空间里可能离老文档很远，导致检索结果被老文档主导。
我会从几个层面来应对。先说一个最直接又实用的策略：增量索引加多路召回。具体来说，新文档不急着塞进历史索引，而是单独建一个增量索引，检索时同时走历史索引和增量索引，最后把两路结果融合排序。这么做的好处是，新文档不会因为图索引的局部性被埋没，而且能实时生效。举个例子，在电商场景里，新上架的商品或者新商家活动，比如满减政策，需要立刻能被搜到，如果走全量重建索引，延迟太高，等建完用户都流失了。所以增量索引很适合这种场景。
但这里有个坑：如果新文档量级很大，增量索引本身也会膨胀，检索延迟会上升。所以我会给增量索引设一个阈值，比如超过历史索引的10%，就触发一次异步全量合并，合并期间用双缓冲影子索引保证服务不中断。
再一个策略是 分布感知的[[重排序]]。说白了，就是训练一个 Rerank 模型，在训练时引入领域标签，比如‘新店’、‘老店’，推理时检测 query 的分布，动态调整新文档的权重。比如用户搜‘附近好吃的’，如果是晚上八点，可能更倾向新店推荐，我会把新店评分加权；如果是中午，可能更看重老店的口碑和配送时间。这个策略的关键前提是，你得有足够多的新文档反馈数据，比如点击率、转化率，不然重排模型学不到有效的分布信息。常见失败场景是，新文档数据稀疏，模型退化成随机排序，甚至拉低整体效果。
说到落地，我会特别关注两个指标：一个是新文档的命中率，看它是不是被系统‘看见’了；另一个是头部结果的多样性，别让前十个结果全是老店。如果新文档命中率低于某个阈值，比如20%，我会触发告警，检查是索引问题还是重排权重太低。上线前一定要做 A/B 实验，灰度验证，避免全量风险。
其实还有一个延伸点：当新文档量级特别大时，增量索引的策略需要调整，比如按时间窗口做分层索引，或者用 [[LoRA]] 微调 embedding 模型来对齐空间。这个可以根据实际场景来选。
所以整体上，我更倾向用增量索引加多路召回作为基础，再配合分布感知的重排来做精细化调整。前提是监控和实验体系得跟上，不然很容易踩坑。