1. 项目概述：为什么RAG系统必须配一套“体检报告”机制？

你有没有遇到过这样的情况：花两周时间搭好一个RAG问答系统，本地测试效果惊艳——用户问“公司Q3财报里提到的AI战略重点是什么”，它能精准定位PDF第17页表格、摘出三句话总结，还带引用标注。你信心满满上线，结果运营团队第二天就甩来截图：客户问“上个月客服投诉率最高的三个问题”，系统却返回了去年的员工培训PPT目录。更糟的是，没人知道问题出在哪——是向量库没更新？检索器召回了错误chunk？还是大模型在摘要时把“投诉率23%”错读成“2.3%”？这种黑盒式失效，在真实业务场景里不是bug，是信任崩塌的起点。

这就是我写这篇内容的直接动因。过去三年，我带团队落地过11个面向金融、医疗、政务领域的RAG应用，其中7个在上线后3个月内因评估缺失被迫回滚。不是技术不行，而是我们习惯性地把“能跑通”当成“能交付”。MLFlow不是新工具，但把它用作RAG系统的全链路健康监测平台，却是被严重低估的实践路径。它不替代LangChain或LlamaIndex，而是给整个RAG流水线装上可追溯的“行车记录仪”：从原始文档切片质量、嵌入向量分布、检索器Top-K命中率，到生成答案的事实一致性、冗余度、响应延迟，全部变成可量化、可对比、可归因的指标。关键在于，这些指标不是静态快照，而是随每次数据更新、模型迭代、提示词调整自动存档，形成一条清晰的性能演进时间轴。

你不需要是MLFlow专家才能上手——本文所有代码基于MLFlow 2.12.1（2024年最新稳定版），所有依赖库版本经过生产环境验证。我会从零开始构建一个可立即复用的评估框架，重点讲清三个核心逻辑：第一，为什么RAG评估不能只看最终答案准确率（Accuracy）？第二，如何用MLFlow的log_metric、log_table、log_model组合拳，把抽象的“检索质量”“生成鲁棒性”翻译成工程师能调试的数字？第三，当评估结果异常时，怎样通过MLFlow UI的对比视图，5分钟内定位是数据预处理环节的分块策略出了问题，还是重排序模型（Reranker）的阈值设置过于激进？接下来的内容，全部来自我们团队在某省级医保知识库项目中的真实踩坑记录和优化方案，连日志截图里的报错信息都是原样复现的。

2. RAG评估的核心逻辑重构：跳出“答案对错”的思维陷阱

2.1 传统评估方式的致命盲区

很多团队评估RAG的第一反应是：准备100个测试问题，人工核对答案是否正确，算个准确率。这就像给汽车只测“能不能点火”，却不管刹车距离、油耗、胎压是否均衡。RAG本质是检索+生成的两阶段流水线，任一环节失效都会导致最终答案失真，但传统单点准确率无法区分故障来源。我们曾在一个法律咨询系统中发现：整体准确率82%，但深入拆解发现——检索阶段召回相关文档的比率（Recall@5）只有61%，而生成阶段对已召回文档的答案提炼准确率（Answer Faithfulness）高达94%。这意味着82%的“正确答案”其实是运气好碰上的，系统实际处于高风险状态。当客户问一个冷门条款时，失败概率远高于预期。

提示：RAG评估必须解耦为三个正交维度——检索质量（Retrieval Quality）、生成质量（Generation Quality）、系统稳定性（System Stability）。任何只关注单一维度的评估，都是在给线上服务埋雷。

2.2 检索质量：不只是“找得准”，更是“找得稳”

检索质量的核心矛盾在于：业务方要的是“最相关文档”，而向量检索返回的是“语义相似度最高”的Top-K。这两者常有偏差。比如查询“苹果手机电池续航差”，理想文档应包含iPhone 15 Pro Max的实测续航数据，但向量检索可能因“苹果”“电池”等词频过高，召回一堆MacBook电池维修指南。因此，我们定义四个不可妥协的检索指标：

• Recall@K：在Top-K返回结果中，至少包含1个标准答案文档的比例。K取值需匹配业务场景——客服系统通常K=3（用户耐心有限），而法律研究系统K=10（允许深度挖掘）。
• MRR（Mean Reciprocal Rank）：衡量相关文档在排序中的位置权重。若相关文档排第1位，MRR贡献1；排第3位，贡献1/3。MRR越接近1，说明检索器越能把关键文档“顶到前面”。
• Chunk Precision@K：不仅看文档是否相关，更看具体是文档的哪个段落被召回。这对长PDF尤其关键——召回整篇《用户手册》不如精准定位到“第4章第2节：电池校准步骤”。
• Semantic Distance Distribution：统计所有查询的向量与召回文档向量的余弦距离分布。如果90%的距离集中在0.75-0.85区间，说明检索器缺乏区分度（所有结果都“差不多相关”）；健康状态应呈双峰分布——强相关（距离>0.9）和弱相关（距离<0.6）明确分离。

2.3 生成质量：警惕“流畅的谎言”

大模型生成答案的流畅性极具迷惑性。我们曾收到用户表扬：“这个系统回答太专业了！”——结果审计发现，它对“医保报销比例”问题的回答中，将“在职职工报销70%”虚构为“75%”，且引用了一个根本不存在的政策文号。这种事实性幻觉（Factual Hallucination）是RAG最大风险点。因此，生成质量评估必须包含：

• Answer Faithfulness（忠实度）：答案中每个声明是否能在召回文档中找到支持证据。我们采用基于BERT的细粒度匹配模型，而非简单关键词匹配。例如，答案说“报销比例70%”，模型会检查召回文档中是否存在“70%”数值及上下文是否确指“在职职工门诊报销”。
• Answer Relevance（相关性）：答案是否直接回应查询意图。用Sentence-BERT计算答案与查询的语义相似度，阈值设为0.65（经2000组样本标定）。
• Answer Conciseness（简洁性）：答案长度与信息密度比。超过300字符未提供新信息，即判定为冗余。这能有效抑制模型“车轱辘话”倾向。
• Citation Accuracy（引用准确性）：答案中标注的文档ID、页码、段落号是否真实存在。这是建立用户信任的物理锚点。

2.4 系统稳定性：让性能波动“看得见、管得住”

生产环境最怕“昨天还好，今天就崩”。RAG系统稳定性取决于三个动态变量：文档库更新频率、嵌入模型版本、重排序策略。MLFlow的核心价值，就是把这些变量与性能指标绑定。例如，当文档库新增1000份政策文件后，我们监控：

• Latency Drift：平均响应延迟是否超过基线20%？若超限，立即触发告警并冻结新文档入库。
• Embedding Drift：新文档的向量分布（均值、方差）是否偏离历史分布3个标准差？这预示着检索器可能无法理解新领域术语。
• Metric Correlation Breakdown：Recall@5与Answer Faithfulness的相关系数是否从0.82骤降至0.31？这往往意味着检索与生成模块出现协同失效。

注意：所有指标必须设定动态基线（Baseline），而非固定阈值。基线值取最近7天同时间段（如工作日上午9-11点）的移动平均。静态阈值在业务流量波动时会产生大量误报。

3. 实操搭建：从零构建MLFlow驱动的RAG评估流水线

3.1 环境准备与依赖锁定

先明确我们的技术栈选择逻辑：不追求最新版，只选经过大规模验证的稳定组合。以下是我们在医保项目中持续运行14个月的配置清单（所有版本号均精确到小数点后两位）：

安装命令必须使用requirements.txt锁定，禁止pip install mlflow这类模糊安装：

# requirements.txt 内容（精简版） mlflow==2.12.1 langchain==0.1.16 llama-index==0.10.32 sentence-transformers==2.2.2 pandas==2.2.2 datasets==2.21.0 torch==2.1.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118

实操心得：在Docker环境中，务必在Dockerfile中添加RUN pip install --no-cache-dir -r requirements.txt，并用pip list --outdated定期扫描过期包。我们曾因datasets库未锁定版本，导致CI/CD环境自动升级到2.22.0，引发load_dataset函数签名变更，整条评估流水线中断6小时。

3.2 数据准备：构建可复现的黄金测试集

评估的根基是高质量测试集。我们拒绝使用公开数据集（如NQ、HotpotQA），因为它们与业务场景脱节。正确做法是：从真实用户会话中采样+专家标注。具体流程：

1. 采样：导出近30天客服系统中“未解决”和“用户标记为不满意”的会话，按问题类型（报销规则、药品目录、异地就医）分层抽样，确保覆盖长尾问题。
2. 清洗：用正则过滤掉“你好”“谢谢”等无意义query，保留纯问题文本。对含多问句的query（如“报销比例是多少？需要什么材料？多久到账？”）拆分为独立子问题。
3. 标注：由2名医保政策专家独立标注，要求：
   • 标准答案：必须来自指定政策文档库（如《XX省医保实施细则2024版》），精确到章节条款；
   • 相关文档ID：标注答案所依据的原始PDF文件名及页码；
   • 难度分级：S级（需跨文档推理）、A级（单文档内查找）、B级（常识性问题）。

最终得到327个测试样本，其中S级42个、A级198个、B级87个。我们将此测试集保存为gold_dataset.jsonl，每行JSON结构如下：

{ "query": "异地就医备案后，住院费用报销比例比本地高还是低？", "answer": "异地就医备案后，住院费用报销比例比本地低5个百分点。", "source_doc": "XX省医保实施细则2024版.pdf", "source_page": 42, "difficulty": "S" }

3.3 RAG工作流封装：让评估可插拔

关键设计原则：评估代码与业务RAG代码完全解耦。我们创建rag_evaluator.py，其核心是evaluate_rag_system()函数，接收一个符合统一接口的RAG对象：

from typing import List, Dict, Any from langchain.chains import RetrievalQA class RAGEvaluator: def __init__(self, test_dataset_path: str): self.test_data = self._load_test_data(test_dataset_path) def evaluate_rag_system(self, rag_system: RetrievalQA, run_name: str = "default_run") -> Dict[str, Any]: """ 评估RAG系统，返回结构化指标字典 :param rag_system: 符合LangChain RetrievalQA接口的对象 :param run_name: MLFlow实验名称，用于追踪不同版本 :return: 包含所有指标的字典 """ # 初始化MLFlow实验 mlflow.set_experiment("RAG_Evaluation") with mlflow.start_run(run_name=run_name): # 记录系统元数据 mlflow.log_param("rag_system_version", getattr(rag_system, "version", "unknown")) mlflow.log_param("test_dataset_size", len(self.test_data)) # 执行评估主循环 results = self._run_evaluation_loop(rag_system) # 计算并记录核心指标 metrics = self._calculate_metrics(results) for metric_name, value in metrics.items(): mlflow.log_metric(metric_name, value) # 记录详细结果表（支持MLFlow UI表格视图） mlflow.log_table("detailed_results", results) return metrics def _run_evaluation_loop(self, rag_system: RetrievalQA) -> List[Dict]: """执行单次评估循环，返回每条测试样本的详细结果""" detailed_results = [] for i, sample in enumerate(tqdm(self.test_data, desc="Evaluating")): try: # 调用RAG系统获取答案 result = rag_system.invoke({"query": sample["query"]}) answer_text = result.get("result", "") # 计算各维度指标 retrieval_metrics = self._evaluate_retrieval(sample, rag_system) generation_metrics = self._evaluate_generation(sample, answer_text) # 合并结果 detailed_results.append({ "query_id": i, "query": sample["query"], "ground_truth_answer": sample["answer"], "generated_answer": answer_text, "retrieval_recall_at_5": retrieval_metrics["recall_at_5"], "retrieval_mrr": retrieval_metrics["mrr"], "generation_faithfulness": generation_metrics["faithfulness"], "generation_relevance": generation_metrics["relevance"], "latency_ms": result.get("latency", 0), "is_correct": self._is_answer_correct(answer_text, sample["answer"]) }) except Exception as e: # 记录失败样本，不中断整个流程 detailed_results.append({ "query_id": i, "query": sample["query"], "error": str(e), "generated_answer": "", "retrieval_recall_at_5": 0.0, "retrieval_mrr": 0.0, "generation_faithfulness": 0.0, "generation_relevance": 0.0, "latency_ms": 0, "is_correct": False }) return detailed_results

关键技巧：_run_evaluation_loop中对每个样本的try...except包裹，确保单个query失败不影响全局评估。失败样本的error字段会被完整记录到detailed_results表中，方便后续在MLFlow UI中筛选分析。

3.4 检索质量评估实现：超越简单的Top-K匹配

_evaluate_retrieval()函数是技术难点所在。我们不满足于“是否召回标准文档”，而是深入到向量空间分析。以Recall@5为例，其实现包含三个层次：

第一层：文档级召回判断

def _evaluate_retrieval(self, sample: Dict, rag_system: RetrievalQA) -> Dict: # 获取RAG系统返回的检索结果（LangChain格式） retriever = rag_system.retriever docs = retriever.get_relevant_documents(sample["query"]) # 标准答案所在文档ID（来自测试集标注） gold_doc_id = sample["source_doc"] # 判断前5个召回文档中是否包含gold_doc_id recall_at_5 = 0.0 for doc in docs[:5]: if gold_doc_id in doc.metadata.get("source", ""): recall_at_5 = 1.0 break

第二层：语义距离精细化分析

# 加载预训练的句子编码器（用于计算查询与文档的语义距离） encoder = SentenceTransformer('all-MiniLM-L6-v2') query_embedding = encoder.encode([sample["query"]])[0] # 计算查询与每个召回文档的余弦距离 distances = [] for doc in docs[:5]: doc_embedding = encoder.encode([doc.page_content[:512]])[0] # 截断防OOM distance = 1 - cosine_similarity([query_embedding], [doc_embedding])[0][0] distances.append(distance) # 记录距离分布统计 mrr = 0.0 for rank, doc in enumerate(docs[:5], 1): if gold_doc_id in doc.metadata.get("source", ""): mrr = 1.0 / rank break return { "recall_at_5": recall_at_5, "mrr": mrr, "avg_distance_top5": np.mean(distances), "distance_std_top5": np.std(distances) }

第三层：Chunk级精准定位

# 进一步分析：标准答案是否在召回文档的特定chunk中？ gold_page = sample["source_page"] chunk_precision_at_5 = 0.0 for doc in docs[:5]: if (gold_doc_id in doc.metadata.get("source", "") and doc.metadata.get("page", -1) == gold_page): chunk_precision_at_5 = 1.0 break

实操心得：cosine_similarity计算必须用sklearn.metrics.pairwise.cosine_similarity，而非手动实现。我们曾因自定义余弦计算未归一化，导致距离值溢出，MRR指标全为NaN。另外，doc.page_content[:512]截断是必要措施——长PDF的chunk可能达2000字符，编码耗时剧增，且前512字符已足够捕捉核心语义。

3.5 生成质量评估：用模型检测模型的幻觉

_evaluate_generation()是另一技术攻坚点。我们放弃基于规则的关键词匹配（易被绕过），采用轻量级微调模型：

Answer Faithfulness检测：使用cross-encoder/ms-marco-MiniLM-L-6-v2模型，输入格式为[query, generated_answer, retrieved_document_chunk]，输出0-1分数。该模型在MS-MARCO数据集上微调，专为事实一致性设计。

from sentence_transformers import CrossEncoder class FaithfulnessEvaluator: def __init__(self): self.model = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2') def score(self, query: str, answer: str, context: str) -> float: # 构造输入对：(query + answer, context) input_pair = (f"{query} {answer}", context[:1024]) # 上下文截断 score = self.model.predict([input_pair])[0] return float(score) # 在评估循环中调用 faithfulness_evaluator = FaithfulnessEvaluator() faithfulness_score = faithfulness_evaluator.score( sample["query"], answer_text, docs[0].page_content if docs else "" )

Answer Relevance检测：直接复用SentenceTransformer计算查询与答案的语义相似度：

relevance_score = util.cos_sim( encoder.encode([sample["query"]]), encoder.encode([answer_text]) )[0][0].item()

Citation Accuracy验证：解析答案中的引用标记（如[1]、(详见XX文件P42)），正则匹配测试集标注的source_doc和source_page：

import re citation_pattern = r'\[?(\d+)\]?|\(详见([^)]+)P(\d+)\)' citations = re.findall(citation_pattern, answer_text) # 检查是否匹配gold_doc_id和gold_page

注意：所有评估模型必须在__init__中预加载，避免在循环中重复初始化。我们曾因在_evaluate_generation中每次新建CrossEncoder实例，导致单次评估耗时从8秒飙升至47秒。

4. MLFlow深度集成：让评估结果真正驱动决策

4.1 实验管理：用MLFlow组织RAG的“版本考古学”

RAG系统迭代频繁：周一更新文档库，周三更换嵌入模型，周五优化提示词。若无统一追踪，很快陷入“哪个版本在哪个数据上表现最好”的混沌。MLFlow的Experiment机制正是为此设计。我们建立三级实验结构：

• Root Experiment:RAG_Evaluation（所有评估的根实验）
• Child Experiments: 按评估目标划分，如RAG_Retrieval_Tuning、RAG_Generation_Prompt_Optimization
• Runs: 每次具体评估执行，命名规范为{system_name}_{date}_{commit_hash}，例如medical_rag_v2.1_20241015_abc123

在代码中强制约束：

# 在evaluate_rag_system开头 mlflow.set_experiment("RAG_Evaluation") mlflow.set_experiment_tag("domain", "healthcare") # 标记业务领域 mlflow.set_experiment_tag("eval_type", "production") # 标记评估类型 # 创建Run时注入Git信息 import git repo = git.Repo(search_parent_directories=True) sha = repo.head.object.hexsha mlflow.start_run( run_name=f"medical_rag_v2.1_{datetime.now().strftime('%Y%m%d')}_{sha[:7]}", tags={"git_commit": sha} )

实操心得：set_experiment_tag是团队协作的关键。当多个小组并行优化时，通过domain标签可快速筛选出医保组的全部实验，避免互相干扰。我们曾因未打标签，导致财务组误删了医疗组的127次实验。

4.2 指标可视化：从数字到洞察的三步转化

MLFlow UI默认的折线图对RAG评估价值有限。我们通过log_table和log_figure构建专属看板：

Step 1：详细结果表（detailed_results）

# log_table自动创建交互式表格，支持列筛选、排序 mlflow.log_table("detailed_results", [ { "query": "报销比例是多少？", "recall_at_5": 1.0, "faithfulness": 0.92, "latency_ms": 1240, "status": "PASS" }, { "query": "异地备案流程？", "recall_at_5": 0.0, "faithfulness": 0.0, "latency_ms": 890, "status": "FAIL_RETRIEVAL" } ])

在UI中，可点击status列筛选所有FAIL_RETRIEVAL样本，导出为CSV进行根因分析。

Step 2：多维对比图（comparison_plot）

import matplotlib.pyplot as plt import seaborn as sns def create_comparison_plot(metrics_history: List[Dict]): # metrics_history: 历史多次评估的指标字典列表 df = pd.DataFrame(metrics_history) fig, axes = plt.subplots(2, 2, figsize=(12, 10)) sns.lineplot(data=df, x='timestamp', y='recall_at_5', ax=axes[0,0]) axes[0,0].set_title('Recall@5 Trend') sns.scatterplot(data=df, x='avg_distance_top5', y='faithfulness', ax=axes[0,1]) axes[0,1].set_title('Retrieval-Generation Correlation') # ... 其他子图 plt.tight_layout() return fig # 记录图表 fig = create_comparison_plot(history_data) mlflow.log_figure(fig, "comparison_plot.png")

Step 3：异常检测热力图（drift_heatmap）

# 计算各指标相对于基线的偏移百分比 baseline = get_baseline_metrics() # 从历史数据计算 drift_df = pd.DataFrame({ "metric": ["recall_at_5", "mrr", "faithfulness", "latency_ms"], "drift_pct": [ (current["recall_at_5"] - baseline["recall_at_5"]) / baseline["recall_at_5"] * 100, # ... 其他指标 ] }) # 生成热力图 plt.figure(figsize=(8, 3)) sns.heatmap(drift_df.set_index("metric").T, annot=True, cmap="RdBu_r", center=0) plt.title("Metric Drift vs Baseline (%)") mlflow.log_figure(plt.gcf(), "drift_heatmap.png")

提示：log_figure生成的图片会永久存档，即使删除Run也不会丢失。我们每周自动生成drift_heatmap.png，当任一指标偏移>15%时，自动邮件通知负责人。

4.3 模型注册与部署：让最优RAG版本一键上线

MLFlow Model Registry是连接评估与生产的桥梁。当某次评估Run的faithfulness首次突破0.90，且latency_ms<1500时，我们执行：

# 将当前Run的RAG系统注册为模型 model_uri = f"runs:/{mlflow.active_run().info.run_id}/model" mlflow.register_model( model_uri=model_uri, name="MedicalRAG-Production", tags={"eval_score": metrics["faithfulness"], "latency_ms": metrics["latency_ms"]} ) # 创建Staging版本 client = mlflow.tracking.MlflowClient() client.transition_model_version_stage( name="MedicalRAG-Production", version=1, stage="Staging" )

在生产服务中，我们不再硬编码RAG对象，而是动态加载：

# production_service.py def load_rag_model(): client = mlflow.tracking.MlflowClient() # 获取Staging阶段的最新版本 latest_version = client.get_latest_versions("MedicalRAG-Production", stages=["Staging"])[0] model_uri = f"models:/{latest_version.name}/{latest_version.version}" return mlflow.langchain.load_model(model_uri)

关键经验：注册模型时必须log_model完整的RAG pipeline，包括retriever、llm、prompt_template。我们曾只注册了LLM，导致生产环境缺少检索器，服务直接500错误。正确做法是在评估Run中显式记录：

mlflow.langchain.log_model( rag_system, "model", input_example={"query": "测试问题"}, signature=infer_signature({"query": "string"}, {"result": "string"}) )

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 问题：MLFlow UI中detailed_results表格为空，但日志显示log_table成功

现象描述：执行评估脚本后，MLFlow UI的Artifacts标签页下能看到detailed_results.json文件，但点击Table视图时显示“Empty table”。

根因分析：log_table要求传入的数据必须是纯字典列表，且字典的键（key）必须全部为字符串，值（value）必须为基本类型（str, int, float, bool, None）。若字典中包含datetime对象、numpy.float32、或嵌套字典，MLFlow会静默失败。

排查步骤：

1. 在log_table前添加校验：

   def validate_table_data(data: List[Dict]) -> None: for i, row in enumerate(data): for k, v in row.items(): if not isinstance(k, str): raise TypeError(f"Row {i}: key '{k}' is not string") if not isinstance(v, (str, int, float, bool, type(None))): raise TypeError(f"Row {i}: value '{v}' of key '{k}' is not basic type") validate_table_data(detailed_results) mlflow.log_table("detailed_results", detailed_results)

2. 检查detailed_results中是否有np.float32值（常见于cosine_similarity输出），强制转换：

   # 替换所有numpy类型 for row in detailed_results: for k, v in row.items(): if isinstance(v, np.floating): row[k] = float(v) elif isinstance(v, np.integer): row[k] = int(v)

解决方案：在log_table前添加json.dumps(json.loads(...))双重序列化，强制类型标准化：

import json json_str = json.dumps(detailed_results) detailed_results_clean = json.loads(json_str) mlflow.log_table("detailed_results", detailed_results_clean)

5.2 问题：Recall@5指标始终为0，但肉眼可见检索器返回了正确文档

现象描述：在测试集中，source_doc标注为"医保实施细则.pdf"，但retriever.get_relevant_documents()返回的doc.metadata["source"]却是"/data/docs/医保实施细则.pdf"。

根因分析：文件路径不一致。测试集标注的是逻辑文件名，而检索器存储的是绝对路径。这是数据准备阶段的典型疏漏。

排查技巧：在评估循环中添加路径标准化日志：

for doc in docs[:5]: # 打印原始metadata供调试 print(f"Retrieved source: {doc.metadata.get('source', 'MISSING')}") print(f"Gold source: {gold_doc_id}") # 添加路径标准化 retrieved_filename = os.path.basename(doc.metadata.get("source", "")) if retrieved_filename == gold_doc_id: recall_at_5 = 1.0 break

终极方案：在数据入库阶段，强制统一source字段为文件名（不含路径）：

# 文档加载时 loader = PDFPlumberLoader(file_path) docs = loader.load() for doc in docs: doc.metadata["source"] = os.path.basename(file_path) # 只存文件名

5.3 问题：Answer Faithfulness分数普遍偏低（<0.3），但人工审核答案质量尚可

现象描述：使用cross-encoder/ms-marco-MiniLM-L-6-v2模型评估，大部分样本得分低于0.3，与人工判断严重不符。

根因分析：该模型在英文MS-MARCO数据集上训练，对中文长句支持不佳。且输入格式[query+answer, context]中，query+answer拼接导致语义混乱。

实测对比：我们用同一组100个样本，对比三种方案：

推荐方案：切换至BAAI/bge-reranker-base，并优化输入：

# 不再拼接query+answer，只用answer和context input_pair = (answer_text, context[:1024]) score = reranker_model.predict([input_pair])[0]

注意：bge-reranker-base需单独pip install FlagEmbedding，且模型加载方式不同：

from FlagEmbedding import FlagReranker reranker_model = FlagReranker('BAAI/bge-reranker-base', use_fp16=True)

5.4 问题：MLFlow Server启动后，UI无法访问，报错OSError: [Errno 98] Address already in use

现象描述：执行mlflow server --host 0.0.0.0 --port 5000，终端报错端口被占用。

根因分析：端口5000被其他进程（如Jupyter Lab、旧MLFlow实例）占用。Linux/macOS可用lsof -i :5000，Windows用netstat -ano | findstr :5000查找PID。

快速解决：改用随机空闲端口，并生成访问链接：

# 查找空闲端口（Linux/macOS） PORT=$(python -c "import socket; s=socket.socket(); s.bind(('', 0)); print(s.getsockname()[1]); s.close()") echo "Using port $PORT" mlflow server --host 0.0.0.0 --port $PORT

生产建议：永远不要在生产环境用mlflow server。应部署为Docker容器，通过Nginx反向代理，并启用MLFlow的--backend-store-uri指向PostgreSQL：

# docker-compose.yml services: mlflow: image: mlflow:2.12.1 environment: - MLFLOW_BACKEND_STORE_URI=postgresql://user:pass@db:5432/mlflow - MLFLOW_ARTIFACT_ROOT=s3://my-bucket/mlflow-artifacts ports: - "5000:500