想知道你的 RAG 智能体是否准备好上线只需使用 Elasticsearch Workflows 和两个 Claude 模型就能在正确性、忠实度和检索质量三个维度上给它打分。1. 引言自动化评估在构建检索增强生成RAG系统时我们总会面临一个核心问题怎么知道智能体给出的答案到底好不好手动抽查几个问题——可行。但如果要调整检索策略、修改提示词、更换模型每次改动都需要重新验证全部答案手动评估就变得既不现实又不可靠。人的评分标准也常常摇摆不定难以复现。“LLM 即评判者”LLM-as-a-Judge应运而生用一个较强的语言模型来自动评判较弱模型输出的质量从而取代人工审核。这个思路并不复杂——如果语言模型能够稳定地判断一个答案是否正确那我们就能在几分钟内自动化完成数百个测试用例的质量检查。而本文更进一步将整套评估流程完全内置于 Elasticsearch Workflows 中。无需外部评估框架无需额外基础设施。一个小模型Claude Haiku 4.5负责回答问题一个大模型Claude Sonnet 4.6负责从三个维度打分。知识库、评判列表、工作流执行、评分结果——全部数据都存储在同一个 Elasticsearch 系统中。在 35 个 HotpotQA 测试案例上Haiku 4.5 的正确性得分为 0.74忠实度得分为 0.90。这些数字足以帮我们精准定位问题出在检索环节还是推理环节2. 前置条件开始之前请确保你已具备一个Elastic Cloud 集群或自管理的Elasticsearch/Kibana 9.4环境若没有可申请免费试用。Python 3.13用于运行配套的示例 Notebook。你的ELASTICSEARCH_URL和ELASTICSEARCH_API_KEY参照连接指南获取以及KIBANA_URL从 Kibana 访问页面获取。3. 理解 LLM-as-a-Judge 评估模式3.1 核心理念传统方式人工逐条检查答案 → 费时、费力、标准不一。LLM-as-a-Judge用强模型当“评委”给弱模型的答案自动打分 → 快速、一致、可重复。3.2 本文的两阶段流程知识库HotpotQA 段落阶段1回答模型Claude Haiku 4.5评判列表问题 标准答案候选答案阶段2评判模型Claude Sonnet 4.6三个评分正确性 / 忠实度 / 上下文相关性4. 三大 RAG 评估指标指标衡量什么低分意味着什么正确性correctness候选答案是否与标准答案一致智能体答非所问或给出错误结论。忠实度faithfulness答案是否基于检索到的段落智能体产生了幻觉编造事实。上下文相关性context_relevance检索到的段落与问题相关吗检索环节带回了无关文档。三者结合的价值假设正确性高但上下文相关性低那说明模型在检索质量不佳的情况下仍然答对了——很可能依赖了自身训练记忆。这在公开知识如维基百科上可能奏效但在私有数据上就会失效。5. 加载并索引 HotpotQA 数据集我们使用HotpotQA 的 distractor 配置每个问题附带 10 个段落其中 2 个包含答案支撑段落8 个为干扰项。问题多为多跳multi-hop类型需要结合两个段落才能答对。数据最终存入两个 Elasticsearch 索引5.1 知识库索引hotpot-knowledge-base存储所有上下文段落每个文档包含标题和段落内容。段落字段被复制到semantic_content映射为semantic_text以便用自然语言进行语义检索无需手动管理嵌入向量。INDEX_NAMEhotpot-knowledge-baseifes_client.indices.exists(indexINDEX_NAME):es_client.indices.delete(indexINDEX_NAME)es_client.indices.create(indexINDEX_NAME,mappings{properties:{title:{type:keyword},passage:{type:text,copy_to:semantic_content,},semantic_content:{type:semantic_text,inference_id:.jina-embeddings-v5-text-small,},}},)5.2 评判列表索引hotpot-judgement-list存储评测用例每个文档包含问题和标准答案ground truth。{question:Were Scott Derrickson and Ed Wood of the same nationality?,answer:yes}6. Elasticsearch Workflow 如何运行评估6.1 整体流程图手动触发工作流步骤1: load_cases从评判列表加载全部35个问题步骤2: eval_loopforeach 遍历每个案例子步骤: retrieve对知识库做语义检索取前4个段落子步骤: agent_answerHaiku 根据段落生成答案子步骤: judgeSonnet 对答案打分子步骤: save将评分结果写入 eval-results 索引全部完成结果可查询6.2 工作流定义YAML工作流采用 YAML 定义通过 Workflows APIElastic 9.4上传。下面逐段解析关键部分。常量与触发器consts:kbIndex:hotpot-knowledge-basejudgeIndex:hotpot-judgement-listresultsIndex:eval-resultstriggers:-type:manual# 手动触发便于调试和重放步骤 1加载所有评测案例-name:load_casestype:elasticsearch.searchwith:index:{{ consts.judgeIndex }}query:match_all:{}size:35步骤 2循环处理每个案例foreach-name:eval_looptype:foreachforeach:{{ steps.load_cases.output.hits.hits }}steps:# 子步骤 2.1语义检索-name:retrievetype:elasticsearch.searchwith:index:{{ consts.kbIndex }}query:semantic:field:semantic_contentquery:{{ foreach.item._source.question }}size:4步骤 3回答模型Haiku使用ai.prompt类型引用 Kibana 中配置的 AI 连接器Anthropic-Claude-Haiku-4-5。提示词强制模型仅依据提供的段落作答若找不到答案则回复“unknown”。-name:agent_answertype:ai.promptwith:connector-id:Anthropic-Claude-Haiku-4-5prompt:You are a Wikipedia QA assistant. Answer the question using ONLY the passages provided. Keep the answer short (one line). If the passages do not contain the answer, reply unknown.Question:{{foreach.item._source.question}}Passages:1.{{steps.retrieve.output.hits.hits[0]._source.passage}}2.{{steps.retrieve.output.hits.hits[1]._source.passage}}3.{{steps.retrieve.output.hits.hits[2]._source.passage}}4.{{steps.retrieve.output.hits.hits[3]._source.passage}}步骤 4评判模型Sonnet评判模型接收问题、标准答案、候选答案、检索段落并输出结构化的 JSON 评分。关键在于schema块——它强制模型返回符合规范的 JSON 对象无需再解析文本或处理 Markdown 代码块。-name:judgetype:ai.promptwith:connector-id:Anthropic-Claude-Sonnet-4-6prompt:You are a STRICT evaluator. Score the candidate answer against the ground truth on three axes. Each score MUST be exactly one of these three values: 0.0, 0.5, or 1.0. Do not return any other number.correctness:1.0 candidate contains the ground truth answer exactly or an unambiguous synonym,and nothing factually wrong. 0.5 partially correct (one side of a multi-hop right,or mostly right with minor noise). 0.0 wrong,missing,or contradicts the ground truth.faithfulness:1.0 every factual claim is supported by the passages. 0.5 mostly supported,one minor unsupported claim. 0.0 contains at least one unsupported claim.context_relevance:1.0 the passages contain enough to answer the question. 0.5 partial coverage (one hop covered,the other missing). 0.0 passages do not cover the answer. Be harsh. If in doubt between two scores,pick the lower one.Question:{{foreach.item._source.question}}Ground truth:{{foreach.item._source.answer}}Candidate:{{steps.agent_answer.output.content}}Passages:1.{{steps.retrieve.output.hits.hits[0]._source.passage}}2.{{steps.retrieve.output.hits.hits[1]._source.passage}}3.{{steps.retrieve.output.hits.hits[2]._source.passage}}4.{{steps.retrieve.output.hits.hits[3]._source.passage}}schema:type:objectproperties:correctness:type:numberminimum:0maximum:1faithfulness:type:numberminimum:0maximum:1context_relevance:type:numberminimum:0maximum:1required:-correctness-faithfulness-context_relevance步骤 5保存结果将每个案例的评分写入eval-results索引。由于schema保证了输出是结构化 JSON我们可以直接用{{ steps.judge.output.content.correctness }}等引用具体字段。-name:savetype:elasticsearch.indexwith:index:{{ consts.resultsIndex }}document:qid:{{ foreach.item._source.qid }}question:{{ foreach.item._source.question }}ground_truth:{{ foreach.item._source.answer }}candidate:{{ steps.agent_answer.output.content }}correctness:{{ steps.judge.output.content.correctness }}faithfulness:{{ steps.judge.output.content.faithfulness }}context_relevance:{{ steps.judge.output.content.context_relevance }}6.3 上传并运行工作流使用 Elastic 9.4 提供的 REST APIPOST /api/workflows— 创建/更新工作流POST /api/workflows/{id}/run— 启动执行GET /api/workflows/executions/{id}— 轮询执行状态35 个测试案例整个流程大约几分钟完成包含 35 次语义检索 35 次 Haiku 调用 35 次 Sonnet 调用 35 次索引写入。7. 解读评估结果7.1 聚合统计直接从eval-results索引查询并计算各指标均值无需额外解析。指标平均分解读正确性0.74约 7/10 的问题答对。对于多跳维基百科问题算是不错的成绩但仍有提升空间。忠实度0.90当 Haiku 给出答案时绝大多数内容都基于检索段落。幻觉问题不严重。上下文相关性0.86语义检索大多数时候能带回相关段落但部分多跳问题需要的信息不在前 4 个段落中。7.2 分数分布图示各指标平均分Haiku 4.5 作为回答模型正确性忠实度上下文相关性10.90.80.70.60.50.40.30.20.10平均分 (0-1)7.3 洞察问题出在哪儿忠实度0.90远高于正确性0.74——这说明模型没有编造事实而是在较难的问题上直接答错了。因此问题核心在于检索覆盖不足或推理能力不够而非幻觉。后续优化方向可以是增加检索段落数量如从 4 个增至 8 个对最难的案例切换到更强的模型。8. 对生产环境的启示我们构建了一套完全运行在 Elasticsearch 内部的评估流水线。知识库、评判列表、工作流执行、评分结果——所有组件都统一在同一系统内无需额外基础设施。版本可控工作流 YAML 可以纳入 Git方便追踪变更。可重放当知识库或回答模型更新时一键重新运行同一管道对比新旧分数。API 可触发可集成到 CI/CD实现自动化回归测试。对于本次测试Haiku 在忠实度上表现可靠但在多跳问题上的正确性还有不足。是否满足生产要求取决于你的具体场景。而评估管道的意义正是给你数据支撑让你能自信决策而非凭感觉猜测。9. 总结LLM-as-a-Judge是一种高效、可扩展的自动化评估方法用强模型评判弱模型。在 Elasticsearch Workflows 中我们用Claude Haiku 4.5回答用Claude Sonnet 4.6从正确性、忠实度、上下文相关性三个维度打分。整个流程通过YAML 工作流定义所有数据与索引共存于 Elasticsearch。实测结果揭示了 Haiku 的强项忠实度高和弱项多跳正确率一般为后续优化指明了方向。立即行动开始 Elastic Cloud 试用用你自己的数据和模型跑一遍评估管道看清你的 RAG 智能体到底表现如何。