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

多语言RAG五大工程方案选型与实操指南

news 2026/6/13 5:12:28

1. 项目概述：这不是简单的“加个翻译”，而是多语言RAG的系统性工程

“Showcasing Different Approaches for Implementing Multilingual RAG”——这个标题乍看像一篇学术综述，但在我过去三年亲手落地17个跨语言知识检索项目的经验里，它背后藏着的是一个极其现实、极其烧脑、也极其容易踩坑的工程命题。Multilingual RAG（多语言检索增强生成），核心不是让模型“会说多种语言”，而是让整个系统在面对中文用户问“特斯拉上海工厂最新产能是多少”，能精准从英文财报PDF、日文供应链新闻、德文技术白皮书里捞出关键数据，并用中文干净利落地回答。关键词里的“Different Approaches”四个字，是整件事的灵魂：没有银弹，只有权衡。我见过太多团队一上来就豪气干云地选“端到端大模型翻译+单语RAG”，结果上线后响应延迟翻三倍、专业术语全错乱；也见过另一拨人死磕“多语言嵌入模型”，最后发现小语种召回率惨不忍睹，法语文档的向量和西班牙语文档的向量在向量空间里离得比北京到布宜诺斯艾利斯还远。这个项目要展示的，是五种经过真实业务压力验证的路径：从最轻量的“查询翻译+单语索引”到最重的“多语言混合索引+路由分发”，每一种都对应着明确的资源水位、语种覆盖目标、延迟容忍度和维护成本。它适合三类人：正在为海外客户部署知识库的产品经理、需要快速支持东南亚市场的AI工程师、以及被老板一句“我们要支持10种语言”拍在桌子上的技术负责人。你不需要从零造轮子，但必须清楚每条路的坡度、弯道和加油站在哪里。

2. 整体设计思路与方案选型逻辑：为什么这五种路径不可替代？

2.1 方案选型不是技术炫技，而是对业务约束的诚实回应

做多语言RAG，第一课就是扔掉“技术最优解”的幻想。我在给一家跨境医疗器械公司做方案时，他们提出的需求表面是“支持中英日韩”，但深挖下去，发现95%的客服咨询来自中文用户，80%的原始技术文档是英文PDF，而日韩资料全是扫描件OCR质量极差。这时候硬上“多语言嵌入模型”就是自找麻烦——模型再强，喂给它一堆模糊的韩文OCR文本，产出的向量也是噪声。所以我们的整体设计框架，始终锚定三个刚性约束：语种分布不均衡性、原始内容形态差异性、线上服务SLA确定性。这直接决定了五种方案的定位：

方案一（查询翻译+单语索引）：适用于语种少（≤3）、查询语言高度集中（如90%以上是中文）、原始内容以高质量结构化文本为主（如API文档、产品手册）。它的核心优势是“快、稳、省”：复用现有单语RAG pipeline，只需在query入口加一层轻量翻译，延迟增加<200ms，向量索引完全不用动。我实测过，用DeepL API翻译中文query到英文，再查英文维基百科向量库，准确率比直接用中文query查混排库高12%，因为中文query常带口语化表达（“那个车厂最近产量咋样？”），而英文query更接近文档术语（“Tesla Gigafactory Shanghai production capacity Q2 2024”）。
方案二（多语言嵌入模型+统一索引）：这是当前开源社区最热的方案，代表模型是intfloat/multilingual-e5-large。但它绝非万能钥匙。它的价值在于“语义对齐”——让“苹果”（中文）、“apple”（英文）、“pomme”（法文）在向量空间里彼此靠近。但代价是：训练数据覆盖不均。e5-large在德语、法语上表现强劲，但在越南语、泰语上召回率断崖下跌。我们曾用它处理泰国电商客服知识库，发现用户问“怎么退货”（คืนสินค้า），模型把答案指向了“换货”（เปลี่ยนสินค้า）文档，只因两者在训练语料中常共现。所以这个方案只推荐用于欧洲语言为主、且能接受小语种效果打折的场景。
方案三（语种路由+分索引）：当语种超过5种、且各语种内容质量/体量差异巨大时，这是最务实的选择。比如某国际律所的知识库：英语合同模板占60%，中文法律解释占25%，阿拉伯语案例摘要占10%，其余小语种合计5%。我们给每种主流语种建独立向量索引（英语用bge-en-v1.5，中文用bge-zh-v1.5），query进来先用fastText做语种检测（准确率99.2%，比LangDetect快3倍），再路由到对应索引。好处是每个索引都能用该语种最优的embedding模型，坏处是运维复杂度翻倍——你要同时监控6个索引的更新状态、向量维度一致性、相似度阈值。
方案四（混合索引+重排序）：这是为“既要又要”场景准备的折中方案。主索引用多语言模型（如e5）做粗筛，召回Top 100文档；再用语种专用模型（如bge-zh）对中文query和中文候选文档做二次精排。我们给一家游戏公司做全球玩家FAQ支持时用了这招：首层用e5召回中英日韩文档，第二层用bge-zh对中文query和所有候选文档重新打分。实测下来，中文答案相关性提升27%，而总延迟只比单层索引多350ms。关键技巧在于：第二层只重排前100个候选，而不是全量，否则重排序本身就成了瓶颈。
方案五（LLM原生多语言+提示工程）：这是最激进的方案，直接放弃传统向量检索，让大模型自己完成“跨语言理解-检索-生成”。典型做法是用Qwen2-72B-Instruct，给它喂入指令：“你是一个精通中英日韩的法律助手，请根据以下多语言文档片段回答问题”。我们测试过，它能在不微调的情况下，从混排的中英文判决书里准确提取赔偿金额。但致命伤是成本和可控性：72B模型单次推理需2张A100，延迟>8秒，且无法解释“为什么选这段文档”，审计风险极高。所以它只适合低频、高价值、允许长等待的场景，比如跨国并购尽调报告生成。

提示：方案选型的第一步，永远不是打开HuggingFace找模型，而是画一张表格，填满你的语种列表、每种语种的内容来源（PDF/网页/数据库）、内容质量（OCR精度/人工校对率）、日均查询量、P95延迟要求。这张表会自动告诉你哪条路不能走。

2.2 架构决策背后的隐性成本：你以为省下的钱，最后都变成了运维噩梦

很多团队在方案评审会上只算显性成本：GPU卡数、API调用量、存储费用。但真正拖垮项目的，是那些藏在角落的隐性成本。我用一张对比表拆解五种方案的真实开销：

方案	向量索引维护成本	查询延迟（P95）	小语种支持难度	审计与可解释性	突发流量应对能力
查询翻译+单语索引	★☆☆☆☆（极低，复用现有索引）	★★★★★（<300ms）	★★☆☆☆（依赖翻译API质量）	★★★★★（全程可追溯）	★★★★☆（弹性好）
多语言嵌入+统一索引	★★★☆☆（需定期重训模型）	★★★☆☆（400-600ms）	★★★★☆（覆盖广但质量不均）	★★☆☆☆（黑盒对齐）	★★☆☆☆（重训慢）
语种路由+分索引	★★★★☆（6套索引独立运维）	★★★★☆（350-500ms）	★★★★★（按需定制）	★★★★☆（分索引可审计）	★★★☆☆（需协调多索引扩容）
混合索引+重排序	★★★★☆（双索引+重排服务）	★★★☆☆（600-800ms）	★★★★☆（首层粗筛保覆盖）	★★★☆☆（两层逻辑可拆解）	★★☆☆☆（重排服务易成瓶颈）
LLM原生多语言	★★☆☆☆（无索引，但需大模型运维）	★☆☆☆☆（>8s）	★★★★★（理论上支持所有语言）	★☆☆☆☆（完全不可解释）	★☆☆☆☆（GPU资源刚性）

看到没？方案二看似“省事”，但它的“定期重训模型”意味着你得有专人盯HuggingFace数据集更新、准备多卡环境、验证重训后各语种召回率——这活儿一年至少干4次。而方案三的“6套索引”，听起来吓人，但一旦写好自动化脚本（我们用Airflow编排，每天凌晨自动拉取各语种新文档、调用对应embedding服务、更新对应索引），实际人力投入反而比方案二稳定。真正的成本，永远在人的注意力上。

3. 核心细节解析与实操要点：五个致命细节，90%的人第一次就栽在这里

3.1 细节一：查询翻译不是“Google翻译”，而是“面向检索的语义净化”

很多人以为多语言RAG的翻译环节，就是调个百度翻译API完事。大错特错。普通翻译API的目标是“通顺”，而RAG需要的是“利于检索”。举个真实例子：中文用户问“微信支付限额是多少？”，直译成英文是“What is the WeChat Pay limit?”。但如果你去查英文版微信支付文档，你会发现官方术语是“WeChat Pay transaction limits”或“daily payment cap”。用直译query去搜，召回率暴跌。解决方案是引入检索导向的翻译增强（Retrieval-Oriented Translation Enhancement, ROTE）：

术语标准化：建立核心术语映射表。例如，“微信支付”→“WeChat Pay”，“日累计”→“daily cumulative”，“单笔”→“per transaction”。这个表不是静态的，而是从你的知识库原文中自动挖掘：用spaCy提取英文文档中的名词短语，再用TF-IDF匹配中文query中的关键词，人工校验后入库。
句式重构：强制将口语化query转为文档风格。规则很简单：删除所有语气词（“啊”、“呢”、“咋样”），将“多少”替换为“what is the value of”，将“怎么”替换为“how to configure”。我们用正则+少量prompt工程实现，耗时<50ms。
实体保留与扩展：对专有名词（如“iPhone 15 Pro Max”）不做翻译，但补充常见别名（“iPhone15PM”、“15ProMax”）。这步靠知识图谱补全，我们用Wikidata API实时获取。

实测数据：在金融知识库场景，加入ROTE后，中文query的英文检索召回率从68%提升到89%。关键不是翻译得有多美，而是让query和文档“说同一种检索语言”。

3.2 细节二：多语言嵌入模型的“幻觉对齐”陷阱，如何用向量空间诊断

multilingual-e5-large这类模型宣传“语义对齐”，但实际使用中，你会遇到诡异的“幻觉对齐”：模型把完全无关的两种语言概念强行拉近。比如，我们发现它把中文“苹果”（水果）和英文“Apple”（公司）的向量距离，比“苹果”和“香蕉”的距离还近——因为训练语料里“Apple Inc.”出现频率太高，淹没了水果义项。这种偏差肉眼不可见，必须用向量空间分析工具诊断。我的标准流程是：

构建诊断语料集：精选100组“应相近”和100组“应远离”的词对。例如：
- 应相近：“car/汽车/voiture”、“machine learning/机器学习/apprentissage automatique”
- 应远离：“apple/苹果/公司” vs “apple/苹果/水果”、“bank/银行/金融机构” vs “bank/河岸/berge”
计算余弦相似度矩阵：用目标模型对所有词向量化，计算每组词对的相似度，生成200×200矩阵。
可视化热力图：用UMAP降维后画散点图。健康模型下，“应相近”组应聚成紧密簇，“应远离”组应分散在不同区域。我们曾用此法发现某小众多语言模型在阿拉伯语-波斯语对上存在系统性偏差——所有波斯语词都被拉向阿拉伯语高频词附近，导致波斯语用户查询准确率仅52%。
针对性微调：对诊断出的偏差，用LoRA在小样本上微调。例如，针对“苹果”歧义，构造100个“水果苹果”和“公司Apple”的对比样本，用对比学习损失函数优化。微调后，该义项分离度提升3.2倍。

注意：不要迷信模型卡上的benchmark分数。那些分数是在标准数据集（如MSE）上测的，而你的业务语料分布完全不同。上线前，必须用你自己的语料做空间诊断。

3.3 细节三：语种路由的“灰色地带”处理——当fastText说不准时，交给规则兜底

语种路由方案（方案三）的核心是fastText语种检测，但它在真实场景中会频繁失灵。典型“灰色地带”包括：

混合语言query：“请用中文解释一下Python的asyncio原理”（中英混杂）
代码片段：用户粘贴了一段含中文注释的Java代码
缩写与符号：“vs”、“i.e.”、“etc.”等拉丁缩写大量出现在非拉丁语系query中

fastText对这些场景的准确率会跌到70%以下。我们的应对策略是三级路由机制：

一级：fastText快速判定（耗时<10ms）。若置信度>0.95，直接路由。
二级：规则引擎兜底。预设20条高置信度规则，例如：
- 若query含“の”、“は”、“が”等日文助词 → 日语
- 若query含“的”、“了”、“在”且无英文字母 → 中文
- 若query含“&”、“@”、“#”且长度<50字符 → 英文（大概率是代码或标签）
三级：LLM辅助判定。当一级置信度<0.8且二级无匹配时，调用轻量级LLM（如Phi-3-mini）做判断。Prompt设计很关键：“你是一个语种识别专家，请严格按以下格式输出：[语种代码]。只输出代码，不要解释。Query: {query}”。实测Phi-3-mini在混合query上准确率达92%，耗时<150ms。

这套组合拳让整体路由准确率从82%提升到99.4%，且99%的请求走一级，成本可控。

3.4 细节四：混合索引的“重排序阈值”不是调参，而是业务SLA的翻译

混合索引方案（方案四）的重排序层，常被当成一个技术参数来调优。错。它的阈值（比如“只重排Top 100”）本质是业务需求的数学表达。我们给某跨境电商设定的SLA是：95%的查询在1秒内返回，且答案相关性得分≥4.2（5分制，由人工标注评估）。那么重排序阈值的计算过程是：

测量基础延迟：单层e5索引召回Top 100耗时320ms，Top 1000耗时410ms。
测量重排序延迟：用bge-zh对100个文档重排序耗时210ms，对1000个耗时1800ms。
计算P95延迟预算：SLA要求1秒，基础索引已占320ms，留给重排序的预算=1000-320=680ms。
反推最大可重排数：实测重排序延迟≈文档数×2.1ms（线性拟合），所以680ms最多支持重排323个文档。
结合相关性曲线：我们画出“重排数”vs“平均相关性得分”曲线，发现重排前200个时，得分从3.8升到4.3；重排200-323个时，得分只从4.3升到4.32。所以最终阈值定为200——用最小的延迟代价，精准命中SLA要求的4.2分。

这个数字不是拍脑袋，而是把业务语言（“一秒内，答案要靠谱”）翻译成了工程语言（“重排200个”）。

3.5 细节五：LLM原生方案的“可控性护栏”，没有护栏等于没有上线

选择方案五（LLM原生多语言）的团队，90%倒在“不可控”上。模型可能一本正经胡说八道，比如把“2023年营收增长15%”错记成“2023年营收下降15%”，且你无法追溯错误源头。我们的“可控性护栏”是三层防御：

输入净化层：在query进入LLM前，强制执行：
- 语种标准化：用前述三级路由确定语种，若为中文，则强制将query转为简体中文（过滤繁体、异体字）。
- 实体锚定：用NER模型（如Flair）识别query中的关键实体（公司名、日期、数值），生成锚点列表。例如，“特斯拉2024年Q1交付量”→锚点[“特斯拉”, “2024年Q1”, “交付量”]。

上下文约束层：在prompt中硬编码约束：

你必须严格遵循以下规则： - 所有数值、日期、公司名必须与提供的文档片段完全一致，不得推断、不得改写。 - 若文档片段未提及某个锚点（如“2024年Q1”），则回答“未提供相关信息”。 - 回答必须用与query相同的语言。

输出验证层：LLM生成答案后，启动验证服务：
- 事实核查：用轻量级BERT模型，将答案与文档片段做细粒度匹配，检查数值、日期是否原文出现。
- 语言一致性检查：用langdetect验证答案语种是否与query一致。
- 置信度打分：若答案中所有关键信息都能在文档中找到原文支撑，打分1.0；若部分信息需推断，打分0.3；若完全无支撑，打分0.0。

只有打分≥0.8的答案才返回给用户。这套护栏让幻觉率从31%压到4.7%，代价是平均延迟增加1.2秒——但比起发布错误信息带来的法律风险，这1.2秒值得。

4. 实操过程与核心环节实现：从零搭建方案四（混合索引+重排序）的完整流水线

4.1 环境准备与工具链选型：为什么我们弃用LangChain，拥抱LlamaIndex+自研调度器

搭建多语言RAG，第一步不是写代码，而是选工具链。我们曾用LangChain试跑方案四，两周后果断弃用，原因很实在：它的抽象层太厚，当你需要精细控制“e5粗筛”和“bge-zh重排”的向量维度、归一化方式、相似度计算逻辑时，LangChain的chain封装反而成了枷锁。最终我们选定的技术栈是：

索引构建：LlamaIndex（v0.10.32）。它对多索引管理的支持最成熟，VectorStoreIndex可无缝切换不同embedding模型，且StorageContext支持为每个索引配置独立的持久化路径。
向量存储：Qdrant（v1.9.2）。选它不是因为名气，而是三个硬指标：① 原生支持多向量字段（一个文档可存e5向量和bge-zh向量）；②scrollAPI性能极佳，适合批量重排；③ Rust写的，内存占用比FAISS低40%。
调度中枢：自研Python调度器（基于FastAPI+Redis Queue）。LangChain的AgentExecutor在混合路由场景下状态管理混乱，而我们的调度器用Redis List做任务队列，每个任务包含{query, query_lang, candidate_ids, rerank_model}，清晰可控。
Embedding服务：自建API集群。e5模型用ONNX Runtime加速，batch size=16，吞吐达1200 docs/sec；bge-zh用vLLM托管，支持动态batch，重排100文档耗时稳定在210±15ms。

安装命令（生产环境）：

# 创建隔离环境 conda create -n multirag python=3.10 conda activate multirag # 安装核心依赖（注意版本锁定） pip install llama-index==0.10.32 qdrant-client==1.9.2 fastapi==0.111.0 redis==4.6.0 onnxruntime-gpu==1.18.0 vllm==0.4.2 # 部署Qdrant（Docker Compose） cat > docker-compose.yml << 'EOF' version: '3.8' services: qdrant: image: qdrant/qdrant:v1.9.2 ports: - "6333:6333" environment: - QDRANT__SERVICE__HTTP_PORT=6333 - QDRANT__STORAGE__PATH=/qdrant/storage volumes: - ./qdrant_storage:/qdrant/storage EOF docker-compose up -d

实操心得：不要在开发机上用pip install llama-index[all]。它会装一堆你用不到的LLM连接器（如OpenAI、Anthropic），不仅慢，还可能因依赖冲突报错。按需安装，比如只用Qdrant，就pip install llama-index-vector-stores-qdrant。

4.2 数据预处理：多语言文档的“清洗-切片-标注”三部曲

多语言RAG的成败，70%在数据预处理。我们处理过PDF、HTML、Word、Markdown四种格式，总结出一套通用流程：

第一步：格式清洗（Format Sanitization）

PDF：用pymupdf（fitz）而非pdfplumber，前者对中日韩文字的坐标提取准确率高23%。关键技巧：启用textpage = page.get_textpage()后再textpage.extractText()，避免OCR干扰。
HTML：用BeautifulSoup移除所有<script>、<style>、广告div，但保留<h1>-<h6>标签——这些是天然的语义分段信号。
Word：用python-docx读取，重点处理“样式继承”：正文样式可能继承标题样式，导致切片错乱。我们强制重置所有段落样式为Normal。

第二步：语义切片（Semantic Chunking）传统固定长度切片（如512字符）在多语言场景灾难性失败。中文512字符≈256个词，英文512字符≈100个词，信息密度差一倍。我们用语义感知切片器：

对于英文/德文等空格分隔语言：用nltk的PunktSentenceTokenizer按句子切，再合并句子直到字符数达300-500。
对于中文/日文：用jieba/fugashi分词，按“段落+标题”切。规则：若段落含<h2>标签，则以此为切片起点；否则，当连续句子的总词数达120（中文）或80（日文）时切片。
对于代码：按函数/类定义切片，用tree-sitter解析AST，确保def calculate_tax():和其内部代码不被割裂。

第三步：多语言元数据标注（Metadata Tagging）每个切片必须标注三项元数据：

lang_code：用fastText检测，若置信度<0.8，则用规则引擎（见3.3节）。
source_type：pdf/html/word/md，影响后续重排序权重。
reliability_score：基于来源可信度打分（官网PDF=1.0，论坛帖子=0.3，用户上传文档=0.1），这个分数会在重排序时作为bias加入。

预处理后的JSONL示例：

{ "id": "doc_abc_001", "text": "特斯拉上海超级工厂2024年第一季度交付量为30.9万辆，同比增长36%。", "metadata": { "lang_code": "zh", "source_type": "pdf", "reliability_score": 0.95, "original_source": "tesla-q1-2024-report.pdf" } }

4.3 混合索引构建：e5粗筛索引与bge-zh重排索引的协同设计

混合索引的核心是“两个索引，一套ID”。Qdrant支持在同一collection中存多个向量字段，但我们发现这会导致查询逻辑耦合。最终采用双collection策略：

Collectione5_coarse：只存e5向量，字段名vector_e5，维度1024。
Collectionbge_zh_rerank：只存bge-zh向量，字段名vector_bge，维度1024。

关键设计点：

ID强一致：所有文档在两个collection中使用完全相同的document_id（如tesla_q1_2024_zh_001）。这样粗筛得到[id1, id2, id3]后，可直接用这些ID去bge_zh_rerank中批量查向量。
向量归一化同步：e5和bge-zh都输出L2归一化向量，确保余弦相似度计算逻辑一致。我们在embedding服务中硬编码torch.nn.functional.normalize(vector, p=2, dim=1)。
相似度阈值分离：e5_coarse的score_threshold设为0.45（宽松，保证召回），bge_zh_rerank的score_threshold设为0.65（严格，保证精度）。

构建脚本核心逻辑（Python）：

from llama_index.core import VectorStoreIndex, StorageContext from llama_index.vector_stores.qdrant import QdrantVectorStore from qdrant_client import QdrantClient # 初始化两个Qdrant客户端 client_coarse = QdrantClient(url="http://localhost:6333", port=6333) client_rerank = QdrantClient(url="http://localhost:6333", port=6333) # 创建e5粗筛索引 vector_store_coarse = QdrantVectorStore( client=client_coarse, collection_name="e5_coarse", vector_size=1024, distance_func="Cosine" ) storage_context_coarse = StorageContext.from_defaults(vector_store=vector_store_coarse) index_coarse = VectorStoreIndex.from_documents( documents=docs, # 预处理后的文档列表 storage_context=storage_context_coarse, embed_model=e5_embed_model # e5 embedding服务实例 ) # 创建bge-zh重排索引（注意：用同一份documents，但指定不同embed_model） vector_store_rerank = QdrantVectorStore( client=client_rerank, collection_name="bge_zh_rerank", vector_size=1024, distance_func="Cosine" ) storage_context_rerank = StorageContext.from_defaults(vector_store=vector_store_rerank) index_rerank = VectorStoreIndex.from_documents( documents=docs, storage_context=storage_context_rerank, embed_model=bge_zh_embed_model # bge-zh embedding服务实例 )

4.4 查询执行流水线：从用户输入到答案返回的17个关键步骤

一个查询的完整生命周期，我们拆解为17个原子步骤，每个步骤都有超时和熔断：

接收HTTP请求（FastAPI endpoint）
解析JSON body，校验query字段非空
三级语种路由（见3.3节），获取query_lang
若query_lang为中文，启动ROTE翻译增强（见3.1节），生成query_enhanced
调用e5服务，对query_enhanced生成向量
Qdrant查询e5_coarse，召回Top 200，score_threshold=0.45
提取召回文档的document_id列表
并发调用bge-zh服务，对query（非翻译版！重排序必须用原语言）生成向量
Qdrant批量查询bge_zh_rerank，用步骤7的ID列表获取对应向量
本地计算余弦相似度（避免Qdrant二次网络IO），对200个文档重排序
应用reliability_score bias：final_score = cosine_score * metadata.reliability_score
截取Top 5重排序结果
拼接Top 5文档的text字段，生成context
构造prompt，注入context和query
调用LLM服务（vLLM托管的Qwen2-7B），生成答案
LLM输出验证（见3.5节），打分
返回JSON response，含answer、sources（含document_id和reliability_score）

关键性能数据（A10G GPU）：

步骤5-6（e5查询）：平均180ms
步骤8-10（bge-zh重排序）：平均210ms
步骤14-15（LLM生成）：平均420ms
端到端P95延迟：890ms，完美满足1秒SLA。

实操心得：步骤9的“批量查询”是性能关键。Qdrant的scrollAPI比search快3倍，但scroll不支持相似度计算。我们的解法是：先用search查一次获取ID，再用scroll按ID批量拉向量。虽然多一次网络往返，但总耗时反而少110ms。

4.5 监控与告警：不只是看CPU，要看“语种漂移率”

多语言RAG的监控，必须超越传统指标。我们除了监控CPU、GPU显存、QPS外，新增三个核心业务指标：

语种漂移率（Language Drift Rate）：（当日检测为中文的query数 - 过去7日均值）/ 过去7日均值。若突增50%，说明可能有爬虫或恶意流量（比如某站群用中文query刷英文知识库）。
重排序增益（Rerank Gain）：（重排序后Top1相似度 - 粗筛Top1相似度）/ 粗筛Top1相似度。健康值应在0.15-0.35之间。若<0.1，说明bge-zh模型退化；若>0.4，说明e5粗筛太松，浪费计算资源。
源可靠性衰减（Source Reliability Decay）：统计Top 5答案中，reliability_score < 0.5的文档占比。若连续3天>30%，说明低质量内容（如用户上传的错误PDF）正在污染知识库，触发自动清理流程。

告警规则（Prometheus + Alertmanager）：

# 语种漂移告警 - alert: LanguageDriftHigh expr: abs((rate(lang_detect_total{lang="zh"}[1d]) - avg_over_time(rate(lang_detect_total{lang="zh"}[7d])[7d:1d])) / avg_over_time(rate(lang_detect_total{lang="zh"}[7d])[7d:1d])) > 0.5 for: 10m labels: severity: warning annotations: summary: "中文查询量突增50%，检查流量来源" # 重排序增益异常 - alert: RerankGainAnomaly expr: avg_over_time(rerank_gain_ratio[1h]) < 0.1 OR avg_over_time(rerank_gain_ratio[1h]) > 0.4 for: 30m labels: severity: critical annotations: summary: "重排序增益异常，检查e5或bge-zh模型"