企业官网建设流程全解析

1. 项目概述：当向量检索不再是RAG系统的“单点故障”

你有没有遇到过这样的情况：一个精心设计的RAG系统，在测试集上准确率高达92%，上线一周后，客服工单里突然冒出大量“回答完全不相关”“答非所问”“胡编乱造”的反馈？查日志发现，问题不是大模型崩了，也不是知识库更新出错，而是——向量检索模块返回的top-3 chunk里，压根没包含任何能支撑答案的关键句子。我去年帮一家金融合规团队落地RAG时，就卡在这个坎上整整三周。他们用的是行业公认的高质量嵌入模型text-embedding-ada-002，知识库是经过律师逐条审核的监管问答对，但只要用户提问里带一个生僻缩写（比如把“QDII”写成“QDII基金”），或者用口语化表达（“那个管私募牌照的部门叫啥？”），向量相似度就直接掉到0.3以下，检索结果全军覆没。这不是模型能力问题，而是整个RAG架构把“找对材料”这件事，100%押注在向量空间的几何近似上——这就像让一个只靠人脸识别门禁的人，去管理整栋银行金库：人脸匹配失败，门就永远打不开，哪怕钥匙就在他口袋里。

这个标题里的“Break The Vector Search Dependency”，说的正是要拆掉这道单点依赖的门禁系统。它不是要否定向量检索的价值——恰恰相反，我们要更聪明地用它。核心思路是：把“检索”从一个黑盒式、不可解释、强语义耦合的步骤，重构为可插拔、可验证、多路协同的决策层。具体来说，就是构建三层检索防线：第一层用向量搜索快速圈定候选池（快但粗）；第二层用关键词+规则引擎做硬性过滤（准但慢）；第三层用轻量级交叉编码器对前两层交集做重排序（精但省）。这三层不是简单叠加，而是通过“置信度熔断机制”动态调度——比如当向量检索top-5的余弦相似度全部低于0.45时，系统自动降级启用纯关键词匹配，并触发人工审核告警。我们实测下来，在金融、医疗、法律这三个对准确性零容忍的领域，这种架构让RAG的“有效检索率”（即最终答案所依据的chunk真实存在于检索结果中）从平均68%提升到99.2%，而端到端延迟仅增加120ms。这篇文章不讲空泛理论，我会带你从零开始，复现这套可落地的鲁棒RAG架构，包括每个模块的选型逻辑、参数调优的血泪经验、以及那些文档里绝不会写的“踩坑现场”。

2. 架构设计与技术选型：为什么必须放弃“向量检索即全部”的思维惯性

2.1 向量检索的三大结构性缺陷，决定了它无法单独扛起RAG的可靠性

很多团队把RAG效果不佳归咎于“嵌入模型不够好”或“分块策略不对”，这其实是本末倒置。向量检索本身存在三个与生俱来的、无法通过调参消除的结构性缺陷，它们共同构成了RAG系统脆弱性的根源：

第一，语义鸿沟的不可解释性。向量空间的相似度计算，本质是高维空间中两个点的距离度量。但人类语言的语义关联，从来不是欧氏距离能完全刻画的。举个真实案例：某医疗RAG系统中，用户问“二甲双胍会升高还是降低血糖？”，向量检索返回的top-1 chunk是“二甲双胍常见副作用包括腹泻、恶心”，因为“二甲双胍”和“腹泻”在训练语料中高频共现，导致向量空间里这两个词被拉得很近。而真正回答问题的核心chunk——“二甲双胍通过抑制肝糖原输出降低空腹血糖”——却排在第17位。这不是模型错了，而是向量空间把“药物-副作用”的共现关系，错误映射成了“药物-药理作用”的语义关系。这种错误无法通过调整temperature或top-k来修复，因为它源于嵌入模型训练目标（预测上下文）与RAG任务目标（精准定位事实）的根本错配。

第二，对抗扰动的零防御能力。向量检索对输入文本的微小变化极度敏感。我们在测试中做了个简单实验：对标准问题“公司章程修改需要多少股东同意？”，分别测试以下变体：

• 原句：相似度0.72
• 加个错别字“公司章成”：相似度0.31
• 换个同义词“公司规约”：相似度0.28
• 口语化“改章程要几个股东点头？”：相似度0.19

看到没？仅仅一个字的偏差，相似度就腰斩。这意味着，只要用户打字手滑、语音识别出错、或者用方言表达，向量检索就大概率失效。而现实场景中，这类“非标准输入”占比超过35%（我们抽样分析了12万条真实客服对话）。指望用户每次都输入教科书式标准问法，无异于要求司机必须用毫米级精度倒车入库——技术上可行，但工程上反人性。

第三，知识盲区的不可感知性。向量检索永远无法告诉你：“这个问题，我的知识库里根本没有答案”。它只会返回“最不差”的几个chunk，然后交给大模型强行编造。我们曾发现一个致命问题：当用户问“2024年Q3深圳新能源汽车补贴政策细则”，而知识库只更新到2024年Q2时，向量检索会返回Q2政策中关于“申请流程”的chunk，大模型据此生成一个看似合理的Q3版本，其中关键数字全是幻觉。更可怕的是，整个过程没有任何异常信号——相似度0.65，看起来很健康。这种“自信的错误”，比直接报错更危险。

提示：这三个缺陷不是bug，而是向量检索作为“无监督语义匹配工具”的固有属性。试图用更好的嵌入模型（如bge-large）或更细的分块（50token）来“修补”，就像给漏雨的屋顶刷更多油漆——治标不治本。

2.2 三层防御架构的设计哲学：用工程冗余换取业务确定性

既然单点依赖注定失败，我们的解法就是引入“工程冗余”——不是堆算力，而是用不同原理的检索技术形成互补。这就像核电站的安全设计：不是指望一个阀门永不泄漏，而是设置主阀、副阀、应急截止阀三层物理隔离。我们的三层架构如下：

第一层：向量检索（Fast Lane）
角色：速度先锋，负责在毫秒级内从百万级知识库中圈出100-200个候选chunk。
选型逻辑：必须牺牲部分精度换极致速度。我们弃用faiss-cpu（单线程瓶颈），改用Qdrant（Rust编写，支持HNSW索引+量化压缩）。实测在100万chunk、768维向量的场景下，Qdrant的P99延迟为8ms，而faiss-cpu为42ms。关键参数：ef_construction=100（建索引时平衡精度与速度），m=16（HNSW图每节点连接数），quantization=True（INT8量化，内存占用降65%）。这里不追求召回率100%，只要保证“正确答案一定在top-200里”即可——这是后续两层工作的前提。

第二层：关键词+规则引擎（Safe Lane）
角色：精度守门员，对Fast Lane的候选池做硬性过滤。
选型逻辑：必须100%可靠，宁可漏检也不误召。我们不用Elasticsearch的全文检索（其BM25算法仍有语义模糊性），而是自研轻量级正则+术语词典双引擎。例如针对金融场景，预置术语词典：{"QDII": ["合格境内机构投资者", "QDII基金"], "LOF": ["上市型开放式基金", "场内LOF"]}，当用户输入含“QDII”时，强制将词典中所有变体加入关键词列表。同时，对每个chunk做结构化校验：若问题含时间状语（如“2024年”），则只保留chunk中明确标注“2024”或“当前有效”的条目。这个引擎的召回率可能只有30%，但它返回的每一条，都是100%可验证的。

第三层：交叉编码器重排序（Precision Lane）
角色：终极裁判，对Safe Lane筛选后的20-50个chunk，用语义理解模型做精细化打分。
选型逻辑：精度优先，但必须控制成本。我们弃用庞大的cross-encoder/ms-marco-MiniLM-L-12-v2（推理需300ms），选用jinaai/jina-embeddings-v2-base-en的交叉编码模式。其巧妙之处在于：该模型原生支持“query-chunk”联合编码，且通过知识蒸馏将参数量压缩到12M，单次推理仅需18ms（A10 GPU）。更重要的是，它输出的不是相似度分数，而是logits值+置信度区间。当logits低于阈值（我们设为-1.2）时，系统判定“query与chunk无实质语义关联”，直接剔除——这解决了向量检索无法感知知识盲区的问题。

这三层不是线性流水线，而是通过动态熔断机制智能调度。核心逻辑用伪代码表示：

def hybrid_retrieve(query): # Step1: Fast Lane - 向量检索 vector_results = qdrant.search(query, limit=200) if max([r.score for r in vector_results]) < 0.45: # 熔断阈值 # 向量信心不足，降级启用Safe Lane全量扫描 safe_results = keyword_engine.full_scan(query) return rerank(safe_results[:50]) # Step2: Safe Lane - 关键词过滤 safe_results = keyword_engine.filter(vector_results) if len(safe_results) == 0: # 关键词无匹配，说明可能是新概念，回退到向量top-10 safe_results = vector_results[:10] # Step3: Precision Lane - 重排序 final_results = reranker.rank(query, safe_results) return final_results[:5]

这个设计的精髓在于：把“不确定性”显性化、可操作化。系统不再假装自己永远正确，而是清楚知道“哪里不确定”，并启动对应的应急预案。

2.3 为什么拒绝混合嵌入（Hybrid Embedding）这类“缝合怪”方案？

市面上常看到“dense+sparse hybrid embedding”的方案，号称能兼顾语义和关键词。我必须坦白：我们在三个客户项目中实测过，效果反而更差。原因很实在：

• 计算开销爆炸：一个hybrid embedding需要同时运行dense模型（768维）和sparse模型（10万+维TF-IDF），向量维度飙升至10万级，索引构建时间增加8倍，QPS直接腰斩；
• 调权如同玄学：dense_score * α + sparse_score * (1-α)，这个α怎么定？在金融问答场景α=0.7效果好，在医疗诊断场景α=0.3才稳定——没有通用解；
• 调试黑洞：当结果出错时，你根本分不清是dense部分漂移了，还是sparse部分词典漏了，还是α权重错了。

我们选择三层分离架构，就是为了每个模块职责单一、效果可验证、问题可定位。就像汽车的刹车系统：ABS防抱死、EBD电子制动力分配、BA刹车辅助，各自独立工作，故障时能精准报“ABS传感器失效”，而不是笼统报“刹车异常”。

3. 核心模块实现：从零搭建可验证的鲁棒RAG检索层

3.1 向量检索层：Qdrant集群部署与性能调优实战

Qdrant的部署看似简单，但生产环境的坑远超文档描述。我们采用双节点集群+异步复制架构，避免单点故障。以下是关键配置和血泪经验：

硬件与网络配置：

• 节点配置：2台A10 GPU服务器（24G显存），CPU 32核，内存128G，NVMe SSD 2TB
• 网络：千兆内网直连，禁用TCP延迟确认（net.ipv4.tcp_delack_min=0），实测集群同步延迟从120ms降至18ms
• 关键避坑：绝对不要用Docker Desktop在Mac上跑Qdrant做性能测试！其文件系统层虚拟化会导致HNSW索引构建速度慢5倍，测试数据毫无参考价值。必须在Linux物理机或K8s集群中验证。

索引构建参数详解（这才是影响效果的核心）：

# qdrant_config.yaml storage: # 必须开启mmap，否则大索引加载时内存爆满 mmap: true # WAL日志大小设为1GB，避免频繁刷盘影响吞吐 wal_capacity_mb: 1024 # HNSW索引是性能关键，参数必须手工调优 hnsw_config: # ef_construction决定建索引时的“探索深度” # 太小（<50）：索引稀疏，召回率暴跌；太大（>200）：建索引时间翻倍 # 我们在100万chunk数据上实测，ef_construction=100是最佳平衡点 ef_construction: 100 # m值控制图的连接密度，m=16是Qdrant官方推荐值 # 但注意：m越大，查询越准但越慢；m越小，越快但易漏检 # 我们在金融场景中发现，m=12时QPS提升22%，但top-5召回率从92%→85% # 最终选择m=16，因业务无法接受5%的漏检率 m: 16 # 最关键的参数：ef_search，它决定查询时的探索广度 # 文档说默认值是512，但这是为精度牺牲速度的设定 # 实测：ef_search=128时，P99延迟11ms，top-5召回率91.3% # ef_search=256时，延迟19ms，召回率92.1%（仅+0.8%） # 我们设为128，因11ms延迟已满足SLA，不值得为0.8%多等8ms ef_search: 128

向量化Pipeline的稳定性保障：
向量质量取决于嵌入模型和预处理。我们强制统一以下三点：

1. 模型锁定：使用BAAI/bge-small-zh-v1.5（中文场景），而非OpenAI API。理由：API响应不稳定（偶尔429），且无法控制batch size。本地部署后，通过--batch-size=64参数将吞吐提升3.2倍；
2. 文本清洗标准化：所有chunk在向量化前，必须经过：
   • 移除HTML标签（用lxml而非正则，避免误删内容）
   • 合并连续空白符（\s+→ ）
   • 强制转小写（关键！BGE模型对大小写敏感，"Apple"和"apple"向量距离达0.8）
3. 分块策略的反直觉优化：
   不再用固定token数分块（如512），而是采用语义边界分块：用nltk识别句子边界，确保每个chunk以完整句子结尾；再用spacy识别段落主题句，将同一主题的连续句子合并。实测在法律条文场景，这种分块使向量检索top-1准确率从63%→79%——因为模型更容易学习“条款-适用情形”的语义关联，而非割裂的片段。

注意：Qdrant的score字段不是余弦相似度，而是负欧氏距离。需转换：cosine_sim = (2 - score) / 2。我们在线上监控中，专门埋点统计score分布，当P95值持续低于0.45时，自动触发熔断机制。

3.2 关键词+规则引擎：如何让“老派技术”在RAG时代焕发新生

很多人觉得关键词检索“过时了”，但恰恰是它的确定性，成为鲁棒性的基石。我们的引擎不是简单grep，而是融合了术语词典、正则模板、结构化校验的三层过滤器。

术语词典构建：从人工整理到半自动演进

• 初始阶段：由领域专家提供核心术语表（如金融场景的“QDII”、“LOF”、“T+0”）
• 运行阶段：系统自动收集向量检索的“高分误召”case。例如，当“QDII”问题返回“QFII”相关内容时，记录这对词为“易混淆术语对”，加入词典并标注confusion_weight=0.8
• 扩展阶段：用jieba对知识库做新词发现，结合TF-IDF筛选出领域特有词汇（如“雪球产品”、“侧袋机制”），人工审核后入库

词典数据结构示例（JSONL格式）：

{ "term": "QDII", "variants": ["合格境内机构投资者", "QDII基金", "QDII理财产品"], "confusion_pairs": [{"term": "QFII", "weight": 0.85}], "required_context": ["境外投资", "额度管理"] }

正则模板引擎：解决“同义不同形”问题
针对用户口语化表达，我们预置了200+条正则规则。关键设计原则：不追求全覆盖，只覆盖高频歧义场景。例如：

• 时间表达：r"(本|当)季度|Q\d{1,2}"→ 统一映射为current_quarter
• 主体指代：r"(该公司|本企业|该组织)"→ 替换为知识库中实际主体名称（需提前抽取）
• 否定表达：r"不.*?允许|禁止.*?进行"→ 标记为negation_intent，触发特殊校验

结构化校验：让知识库“开口说话”
这是最容易被忽视，却最有效的环节。我们在知识库ETL阶段，为每个chunk注入结构化元数据：

• valid_from: 生效日期（ISO格式）
• jurisdiction: 适用地区（"CN-Shenzhen", "US-NY"）
• document_type: 条文类型（"regulation", "faq", "case_study"）
• confidence_level: 人工标注的可信度（1-5星）

检索时，这些字段变成硬性过滤条件。例如用户问“深圳2024年新能源补贴”，引擎自动添加：

filter = { "must": [ {"key": "jurisdiction", "match": {"value": "CN-Shenzhen"}}, {"key": "valid_from", "range": {"gte": "2024-01-01"}} ] }

实测表明，仅靠结构化校验，就能过滤掉62%的无效chunk，且零误伤。

性能优化秘籍：

• 词典匹配不用re.findall遍历，而是用Aho-Corasick算法（pyahocorasick库），10万术语词典匹配耗时稳定在0.3ms；
• 正则编译一次复用，避免每次re.compile()；
• 结构化校验用内存索引：将jurisdiction和valid_from字段预建哈希表，O(1)查询。

3.3 交叉编码器重排序：轻量级模型的精度与效率平衡术

重排序是精度的最后防线，但也是性能瓶颈。我们选择jinaai/jina-embeddings-v2-base-en，不仅因其速度快，更因它原生支持query-chunk联合编码——这是区别于普通双塔模型的关键。

模型微调：用领域数据榨干最后1%精度
通用模型在专业领域表现平平。我们用客户提供的1000条“问题-正确chunk”pair做LoRA微调：

• 数据构造：对每个正样本，随机采样3个负样本（来自同一文档的其他段落），构成四元组；
• LoRA配置：r=8, alpha=16, dropout=0.1，仅训练0.3%参数；
• 关键技巧：负样本必须hard——不能随机选，而要用向量检索中与query相似度排名2-5的chunk。这样模型才能学会区分“看起来像但实际无关”的干扰项。

微调后，在金融测试集上，top-1准确率从76.2%→89.7%，且未增加推理延迟（因LoRA适配器在GPU显存中常驻）。

置信度熔断机制的实现细节：
交叉编码器输出的logits值，需要转化为可操作的置信度。我们采用温度缩放+分位数校准：

1. 在验证集上，收集所有正样本的logits分布，计算P10（10%分位数）为-1.2；
2. 推理时，对每个chunk的logits应用温度缩放：calibrated_score = logits / temperature（temperature=0.8）；
3. 若calibrated_score < -1.2，则标记为low_confidence，进入人工审核队列。

这个-1.2阈值不是拍脑袋，而是通过精确率-召回率曲线确定的：当阈值设为-1.2时，精确率保持在99.1%，而召回率仍达87.3%，是业务可接受的平衡点。

GPU显存优化实战：
A10显存24G，但默认加载模型会占满。我们通过三步释放：

• 使用torch.compile(model, mode="reduce-overhead")，编译后显存占用降35%；
• 启用flash_attn（需CUDA11.8+），注意力计算显存降40%；
• 对batch内chunk做动态padding：不pad到max_len，而是按batch内最长chunk长度pad，显存再降22%。
  最终，单卡A10可并发处理16个query-chunk对，P99延迟稳定在18ms。

4. 端到端集成与问题排查：让鲁棒性在真实流量中经受考验

4.1 完整Pipeline代码实现：可直接复制的生产级脚本

以下是整合三层架构的核心代码（已脱敏，可直接用于生产）：

# rag_pipeline.py import qdrant_client from qdrant_client.http import models from jina import DocumentArray, Document from typing import List, Dict, Optional import numpy as np class RobustRAGPipeline: def __init__(self): # 初始化Qdrant客户端（集群模式） self.qdrant = qdrant_client.QdrantClient( url="https://qdrant-cluster.internal:6333", api_key="your_api_key", timeout=5.0 ) # 初始化关键词引擎（伪代码，实际为自研服务） self.keyword_engine = KeywordEngine( term_dict_path="/data/finance_terms.jsonl", struct_index_path="/data/kb_struct_index.pkl" ) # 初始化交叉编码器（ONNX Runtime加速） self.reranker = ONNXCrossEncoder( model_path="/models/jina-reranker.onnx", providers=['CUDAExecutionProvider'] # 强制GPU ) # 熔断阈值（线上可热更新） self.vector_score_threshold = 0.45 self.rerank_logit_threshold = -1.2 def retrieve(self, query: str, top_k: int = 5) -> List[Dict]: """主检索入口""" # Step 1: 向量检索 vector_results = self._vector_search(query, limit=200) # Step 2: 动态熔断判断 if not vector_results or max(r.score for r in vector_results) < self.vector_score_threshold: # 降级：全量关键词扫描 safe_results = self.keyword_engine.full_scan(query) candidates = safe_results[:50] if len(safe_results) > 50 else safe_results else: # 正常流程：关键词过滤向量结果 safe_results = self.keyword_engine.filter(vector_results) if len(safe_results) == 0: # 关键词无匹配，回退向量top-10 candidates = [r.payload for r in vector_results[:10]] else: candidates = [r.payload for r in safe_results] # Step 3: 交叉编码器重排序 if len(candidates) > 0: reranked = self._rerank(query, candidates) # 置信度过滤 final_results = [ r for r in reranked if r['logit_score'] >= self.rerank_logit_threshold ] return final_results[:top_k] else: return [] def _vector_search(self, query: str, limit: int) -> List: """向量检索封装，含异常重试""" try: # 文本预处理（小写+清洗） clean_query = self._preprocess_text(query) # 获取嵌入向量（本地BGE模型） query_vector = self.bge_model.encode([clean_query])[0].tolist() results = self.qdrant.search( collection_name="finance_kb", query_vector=query_vector, limit=limit, with_payload=True, # 关键：启用score解释 search_params=models.SearchParams(hnsw_ef=self.hnsw_ef_search) ) return results except Exception as e: # Qdrant故障时，优雅降级为关键词扫描 logger.warning(f"Qdrant search failed: {e}") return [] def _rerank(self, query: str, candidates: List[Dict]) -> List[Dict]: """交叉编码器重排序""" # 构造query-chunk对 pairs = [[query, c['content']] for c in candidates] # 批量推理（ONNX Runtime） logits = self.reranker.predict(pairs) # 合并结果 reranked = [] for i, candidate in enumerate(candidates): reranked.append({ 'content': candidate['content'], 'source': candidate['source'], 'logit_score': float(logits[i]), 'confidence': self._calibrate_confidence(logits[i]) }) # 按logit_score降序 return sorted(reranked, key=lambda x: x['logit_score'], reverse=True) def _calibrate_confidence(self, logit: float) -> float: """置信度校准""" # 温度缩放 scaled = logit / 0.8 # Sigmoid映射到[0,1] return 1 / (1 + np.exp(-scaled)) def _preprocess_text(self, text: str) -> str: """标准化预处理""" import re # 移除HTML text = re.sub(r'<[^>]+>', ' ', text) # 合并空白 text = re.sub(r'\s+', ' ', text).strip() # 强制小写 return text.lower() # 使用示例 pipeline = RobustRAGPipeline() results = pipeline.retrieve("QDII基金可以投资哪些海外市场？") for r in results: print(f"Score: {r['logit_score']:.3f}, Content: {r['content'][:50]}...")

4.2 真实线上问题排查手册：那些监控告警里看不到的坑

再完美的设计，也会在真实流量中暴露问题。以下是我们在三个项目中总结的高频问题速查表，附带根因分析和解决方案：

独家避坑技巧：

• 熔断阈值必须动态化：我们用Prometheus监控vector_score_p95，当其连续1小时低于0.45时，自动将阈值下调0.02（最小0.35）。这避免了因知识库更新导致的批量熔断；
• 关键词引擎的“兜底开关”：当full_scan耗时超过500ms（说明词典过大），自动切换为partial_scan——只扫描required_context匹配的文档子集，牺牲覆盖率保延迟；
• 重排序的“安全气囊”：即使reranker返回空结果，Pipeline也强制返回向量检索top-1，并在response中添加"warning": "low_confidence_rerank"字段，让前端可提示用户“答案可能不完整”。

4.3 效果验证与AB测试：用数据证明鲁棒性提升

效果不能靠感觉，必须量化。我们设计了三维度验证体系：

维度一：基础检索指标（离线测试）
在标注的1000条测试集上对比：

维度二：业务效果指标（线上AB测试）
在客服系统中，将50%流量切到新架构，观察7天：

维度三：鲁棒性专项测试（压力测试）
模拟真实噪声场景：

• 错别字攻击：在1000个问题中随机替换1个字，传统RAG召回率跌至41.2%，新架构保持89.3%；
• 术语混淆攻击：将“QDII”替换为“QFII”，传统RAG返回错误答案率73%，新架构因结构化校验+关键词过滤，错误率降至2.1%；
• 知识盲区检测：提问知识库外问题（如“2025年政策”），传统RAG 100%幻觉，新架构98.7%触发low_confidence警告。

实测心得：鲁棒性提升最显著的不是“平均效果”，而是长尾场景的兜底能力。当传统RAG在10%最难问题上完全失效时，新架构仍能保持75%以上的有效检索率——这才是业务敢把RAG接入核心客服通道的底气。

5. 运维监控与持续进化：让鲁棒性成为可运营的资产

5.1 四层监控体系：从基础设施到业务语义的全链路可观测

鲁棒RAG不能只靠上线前的测试，必须建立实时监控闭环。我们构建了覆盖四个层面的监控体系：

L1 基础设施层：

• Qdrant集群健康：qdrant_cluster_status（1=健康，0=脑裂）
• GPU显存水位：nvidia_gpu_memory_used_percent{device="0"}> 90%时告警
• 关键：向量索引碎片率：通过qdrant.collection_info().segments计算segment_count / expected_segment_count，>1.5时触发重建

L2 模块性能层：

• 各层耗时：rag_pipeline_step_latency_seconds{step="vector_search"}、{step="keyword_filter"}等
• 熔断触发率：`rag_fallback_count_total{fallback_type="vector