RAG Pipeline 监控与重试检索失败不是静默跳过而是触发备选路径一、RAG 系统最常被忽略的环节是检索失败处理RAG 架构的讨论通常聚焦在向量数据库选择、分块策略和 Embedding 模型对比上。但在生产环境里更频繁的问题是检索失败。向量库超时、相似度阈值过高导致空结果、索引写入延迟导致新数据无法即时检索——这些情况远比检索到了但不准更常见。多数 RAG 实现遇到检索失败时会静默跳过检索结果直接让模型用自身知识回答。这等于退回到了纯生成模式用户完全不知道回答没有经过事实支撑。正确做法是触发备选路径并在回答中标注信息来源状态。二、RAG 调用链路要有显式降级和来源标注完整的 RAG 链路应该包含检索、降级判断、模型调用和来源标注四个环节。每个环节的失败都要被记录和传递不能被吞掉。flowchart TD A[用户查询] -- B[查询预处理与意图分类] B -- C[向量检索] C -- D{检索结果数量} D --|≥3条| E[正常RAG生成] D --|1-2条| F[弱支撑RAG标注低置信度] D --|0条| G[触发备选路径] G -- H[关键词检索备选] H -- I{备选是否成功} I --|是| J[备选RAG生成标注检索降级] I --|否| K[纯生成模式标注无事实支撑] E -- L[回答与来源标注] F -- L J -- L K -- L来源标注是关键。用户看到此回答基于3条检索结果和此回答未经事实检索时对回答的信任度判断完全不同。标注不是削弱产品而是增加透明度。三、检索失败的重试与降级逻辑type RetrievalResult { chunks: string[]; scores: number[]; source: vector | keyword | none; latencyMs: number; }; const SIMILARITY_THRESHOLD 0.72; const MAX_RETRIES 2; export async function retrieveWithFallback(query: string): PromiseRetrievalResult { // 第一次向量检索含超时保护 for (let attempt 0; attempt MAX_RETRIES; attempt) { try { const result await vectorSearch(query, { timeoutMs: 3000 }); const filtered result.filter((r) r.score SIMILARITY_THRESHOLD); if (filtered.length 3) { return { chunks: filtered.map((r) r.text), scores: filtered.map((r) r.score), source: vector, latencyMs: result[0]?.latencyMs ?? 0, }; } // 结果不足3条但不为空标记为弱支撑 if (filtered.length 0) { return { chunks: filtered.map((r) r.text), scores: filtered.map((r) r.score), source: vector, latencyMs: result[0]?.latencyMs ?? 0, }; } } catch (error) { console.error(向量检索第${attempt 1}次失败:, error); } } // 降级到关键词检索 try { const keywordResult await keywordSearch(query); if (keywordResult.length 0) { return { chunks: keywordResult, scores: keywordResult.map(() 0.5), source: keyword, latencyMs: 0, }; } } catch (error) { console.error(关键词检索也失败:, error); } // 全部失败标记无检索支撑 return { chunks: [], scores: [], source: none, latencyMs: 0 }; }这段代码实现了向量检索重试、关键词检索降级和最终无支撑标记的完整链路。每次检索的来源和耗时都被记录方便后续分析检索质量。四、重试和降级不能无限制延长响应时间RAG 系统的响应时间直接影响用户体验。两次向量检索重试加一次关键词降级总耗时可能超过10秒。生活工具的场景下用户对等待的容忍度更低。合理的做法是设置总超时上限。比如整个检索环节不超过5秒超过后直接降级到纯生成模式。宁可标注未经事实检索也不要让用户等太久。响应速度和信息质量需要权衡生活应用里速度的权重往往更高。重试次数也要克制。向量库如果是持续故障两次重试不会有不同结果。更好的做法是把检索失败记录到监控系统触发告警后由运维层面修复而不是让每次请求都重复失败的检索。五、总结RAG Pipeline 应对检索失败做显式降级处理不能静默跳过。链路包含向量检索重试、关键词检索备选和纯生成降级每一步都标注来源状态。总超时不超过5秒超过后直接标注无检索支撑。检索失败要记录到监控系统由运维层面解决持续故障。用户看到来源标注后才能准确判断回答可信度。