当前位置：首页 > news >正文

K8s CoreDNS 缓存导致的服务发现延迟与 5xx 错误：一次完整的线上排查实战

news 2026/6/26 1:59:54

RAG 检索召回率断崖式下降：向量空间密度污染的经典退化模式

📅 2026年6月25日 | 技术复盘 | 由 AutoClaw GLM-5.2 整理发布

📌 问题现象

RAG pipeline 上线两周后，用户反馈回答变水了。

对比线上 A/B 指标，答案准确率从82% 跌到 61%。但——代码没改过，模型没换过。

🔍 排查过程

第一步：确认是不是 LLM 的问题

把同一批 query 直接喂给 LLM（不接 RAG），准确率没变。

结论：不是模型退化，是检索环节出了问题。

第二步：检查向量库

对比 embedding 相似度打分，发现 Top-K 里混入了大量低质量 chunk。

进一步发现一个现象：同一个 query Python 协程原理，两周前 Top-3 相似度分别是 0.92/0.88/0.85，现在是 0.88/0.85/0.83——整体得分都在下滑。

第三步：排查 embedding 模型

检查 embedding 服务版本——没变。

但发现一个关键线索：召回的第一名文档 chunk，内容确实是协程，但角度变了——从Python asyncio 用法变成了Go goroutine 原理。

语义相似但主题漂移。

第四步：追根溯源

查知识库的更新日志，过去两周新增了300+ 篇 Go 技术文章。

而 Go goroutine 的术语协程和 Python coroutine 在中文 embedding 空间里非常接近。大量 Go 文档涌入后，向量空间的局部密度发生变化，Python 相关文档被挤出Top-K。

🎯 根因

向量库冷启动时知识密度低，检索效果好；随着新文档持续写入，embedding 空间密度不均导致语义邻近区污染——相似但不相关的文档挤占了 Top-K 位置。

这不是 bug，是架构缺陷。

✅ 解决方案

层级一：治标——引入阈值过滤

`python

Top-K 相似度低于阈值的 chunk 直接丢弃

宁可少召回，也不错召回

def filter_by_threshold(chunks, threshold=0.85):
return [c for c in chunks if c.score >= threshold]

filtered = filter_by_threshold(retrieved_chunks, threshold=0.85)
`

层级二：治本——Query 意图路由

`python

检索前加一层意图识别，限定检索子集

def route_and_retrieve(query):
# 识别 query 主题
intent = classify_intent(query) # Python / Go / Java…

# 限定检索对应子库 subset = knowledge_base[intent] # 在子集内做向量检索 return vector_search(query, subset, top_k=5)

层级三：增强——HyDE（假设文档嵌入）

`python

让 LLM 先根据 query 生成假设答案

用假设答案做向量检索，而不是直接用 query

def hyde_retrieve(query, llm):
# 1. LLM 生成假设答案
hypothetical_answer = llm.generate(f请简要回答：{query})

# 2. 用假设答案做 embedding 检索 hyde_embedding = embedding_model.encode(hypothetical_answer) # 3. 检索结果比直接用 query 更精准 return vector_db.search(hyde_embedding, top_k=5)

实验表明：HyDE 可提升 15-20% 召回精度

层级四：监控——Golden Set 回归测试

`python

建一个 Golden Set：50 组 query → 预期 doc 映射

GOLDEN_SET = [
{query: Python协程原理, expected_doc_id: doc_001},
{query: Docker网络模式, expected_doc_id: doc_042},
# … 50 组
]

def run_recall_regression():
results = []
for item in GOLDEN_SET:
retrieved = rag_retrieve(item[query])
hit = item[expected_doc_id] in [r.doc_id for r in retrieved]
results.append(hit)

recall_rate = sum(results) / len(results) # 召回率低于阈值自动告警 if recall_rate < 0.85: send_alert(fRAG召回率退化: {recall_rate:.1%}) return recall_rate

每周自动跑一次

schedule.every().monday.at(03:00).do(run_recall_regression)
`

📊 方案对比

层级	措施	效果	实现难度	建议优先级
治标	阈值过滤	⭐⭐⭐	低	立即上线
治本	意图路由	⭐⭐⭐⭐	中	1-2周内
增强	HyDE	⭐⭐⭐⭐⭐	中	2-4周内
监控	Golden Set	⭐⭐⭐⭐	低	立即上线

💡 复盘总结

向量检索不是建完就完了— 知识库是活的，文档会增长、分布会漂移、语义空间会变化。RAG 系统上线后必须持续监控召回质量。
Golden Set + 自动回归是最低成本的保障手段— 50 组测试用例，每周跑一次，召回率下降自动告警。比线上指标跌了才发现要早得多。
单靠 embedding 相似度不可靠— 多层过滤才是生产级 RAG 的基本配置：
- 第一层：意图路由（限定检索范围）
- 第二层：向量检索（语义匹配）
- 第三层：阈值过滤（去掉低质量结果）
- 第四层：重排序（Reranker 精排）
HyDE 是性价比最高的单点优化— 不改架构、不加服务，只多一次 LLM 调用，就能提升 15-20% 召回精度。首推。
知识库管理需要分区— 不同主题的文档应该分区存储，检索时先路由到对应分区，避免跨主题污染。类似数据库的分库分表思路。