RAG系统长文档检索失败怎么排查？向量库选型与混合检索调优实战

RAG（检索增强生成）系统上线一段时间后，经常出现”答案答非所问”或”检索结果与问题无关”的情况。这类问题大多不在模型本身，而在检索链路。本文围绕RAG系统中常见的检索失败场景，从文档切分、向量库选型、混合检索与重排四个环节给出可直接落地的排查方法和调优思路，供大模型应用开发者参考。

先确认问题出在召回还是生成：检索质量的三段式验证

排查RAG检索失败，第一步是把链路拆开，确认失败发生在哪个环节。常见做法是单独打印检索结果：

# 伪代码：只验证召回，不走LLM
hits = vector_store.search(query, top_k=10)
for h in hits:
    print(h.score, h.content[:80])

# 召回结果与问题语义明显不相关 -> 问题在向量检索
# 召回结果相关但回答仍混乱 -> 问题在Prompt或上下文拼接

如果召回结果本身就不相关，优先检查三处：文档切分粒度是否过大、Embedding模型与查询语言是否匹配、向量库的相似度阈值是否过严。

文档切分策略调整：固定窗口切分与语义切分的取舍

固定字符切分（如每512字符一刀）实现简单，但会把一个完整段落拦腰截断，导致向量表示被稀释。排查时先看切分块是否保留了完整语义单元：

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64,
    separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""]
)

实战经验：技术文档按Markdown标题层级切分、合同按条款切分，效果普遍优于纯字符窗口。切分块太大（超过512 token）会让向量平均化，太小（低于128 token）则上下文不足，两者都会直接拉低检索命中率。

向量库选型对比：pgvector、Qdrant与Milvus怎么选

向量库的选型直接影响检索性能和运维成本。三款主流方案对比：

选型建议：中小规模先用pgvector或Qdrant，检索瓶颈出现再迁移Milvus。注意HNSW索引的M参数（连接数）和ef_construction参数会影响召回率，M=16、ef_construction=200是常见起步值。

混合检索与RRF融合：向量检索查不到时的补救手段

纯向量检索对数字、专有名词、缩写不敏感。比如查”K8s存储卷挂载失败”这类强关键词查询，BM25关键词检索往往比向量检索更准。混合检索就是把两者结果做融合：

def rrf_fusion(vec_hits, kw_hits, k=60):
    scores = {}
    for rank, hit in enumerate(vec_hits + kw_hits):
        scores[hit.id] = scores.get(hit.id, 0) + 1.0 / (k + rank + 1)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

RRF（倒数排名融合）不依赖分数归一化，实现简单、效果稳定。如果加了混合检索后效果提升仍不明显，再加一层重排（rerank）：用cross-encoder对召回的前20条做精排，取前3-5条送入生成。重排模型选择bge-reranker-base这类中小尺寸即可，在线延迟可控。

把检索失败固化成回归用例：RAG评估集是最值得投入的部分

RAG系统改一处、坏一处的现象很常见。建议把每次发现的检索失败样本沉淀为评估集：记录问题、正确文档、错误回复，用命中率（Recall@k）和正确率（Precision@k）做回归指标。每次调整切分策略或向量库参数后跑一遍，才能判断改动是变好还是变坏。评估集覆盖三类难样本：同义改写、多跳查询、否定表述，这三类最容易暴露检索短板。