企业官网建设流程全解析

1. 从“能用”到“好用”：为什么RAG质量评估是工程化的分水岭

最近和几个团队聊他们的RAG项目，发现一个挺普遍的现象：大家花大力气把向量数据库搭起来，把LangChain或者LangChain4j的链路跑通，看着问答能出结果，就觉得“大功告成”了。但一上线，或者让真实用户用起来，问题就来了——回答有时会“一本正经地胡说八道”，或者对同一个问题，今天和昨天的答案质量波动很大。这时候才意识到，构建一个能跑的RAG原型，和打造一个稳定、可靠、可信任的生产级RAG服务，中间隔着一道巨大的鸿沟。这道鸿沟，就是系统化的质量评估与监控。

RAG（检索增强生成）不是个“一锤子买卖”。它不像传统的规则引擎，代码写完，逻辑就固定了。RAG系统的表现，受到上游文档质量、切片策略、嵌入模型、检索器、重排序模块、大语言模型（LLM）本身以及提示词工程等多重变量的共同影响。任何一个环节的微小变化，都可能像蝴蝶效应一样，导致最终答案质量的显著波动。因此，仅仅在开发阶段做几次人工测试是远远不够的。我们需要一套客观、量化、可自动化的评估体系，来持续地回答几个核心问题：我的RAG系统今天表现如何？比昨天变好了还是变差了？如果变差了，是哪个环节出了问题？我们做的优化（比如换了新的嵌入模型、调整了重排序权重）真的有效吗？

这就是RAG质量评估的价值所在。它把我们对系统“感觉还行”的主观印象，变成了“忠实度得分85，答案相关性得分92”的客观数据。而RAGAS框架，正是当前社区在解决这个问题上，走得最远、最成体系的开源工具之一。它试图用一套相对完备的指标，来量化RAG流水线的核心能力。今天，我就结合自己最近在一个Spring Boot微服务中落地RAGAS评估与Micrometer监控的实战经历，来聊聊如何跨越这道从“能用”到“好用”的鸿沟。这不仅仅是跑几个评估脚本，更是一套关于如何以数据驱动的方式，来迭代和运营一个AI服务的工程方法论。

2. 拆解RAGAS：超越简单准确率的四维评估体系

当我们谈论RAG的质量时，第一个蹦出来的词往往是“准确率”。但“准确”对于RAG来说，是一个过于模糊和单一的概念。一个答案可能事实正确但冗长啰嗦（相关性差），也可能流畅自然但篡改了原文信息（忠实度低）。RAGAS框架的聪明之处在于，它没有试图用一个“总分”来概括一切，而是将其分解为四个核心维度，分别评估生成链条中不同阶段的质量。

2.1 忠实度：答案是否“篡改”了你的知识？

这是我认为最重要的一个指标，直接关系到RAG系统的可信赖性。忠实度衡量的是生成的答案在多大程度上严格遵循了检索到的上下文（Context），而没有引入外部知识或进行臆测。它的计算逻辑是，评估答案中的每一个声明性语句，检查其是否都能从提供的上下文中推导或直接找到支持。

举个例子，假设你的知识库文档里写着：“公司产品A的最大并发连接数是1000。” 如果RAG系统回答：“产品A支持高达1000个并发连接，性能优异。” 这忠实度就很高。但如果它回答：“产品A的最大并发是1000，并且该产品采用了最新的异步IO架构。” 而后半句“异步IO架构”在上下文中根本没有提及，这就是典型的“幻觉”或“捏造”，会显著拉低忠实度得分。

在工程上，高忠实度是RAG的底线。一个忠实度低的系统是危险的，因为它会以非常自信的口吻传播错误信息。提升忠实度的关键，通常在于优化检索质量（确保召回的上下文真的相关）和优化提示词（明确指令LLM“严格基于给定上下文回答，不要自行发挥”）。

2.2 答案相关性：答案是否“答非所问”？

这个指标评估的是生成的答案与用户提出的问题之间的匹配程度。一个事实正确但文不对题的答案，同样没有价值。例如，用户问：“如何重启产品A的服务？” 系统检索到了关于产品A端口配置的文档，并生成答案：“产品A的默认服务端口是8080。” 这个答案本身可能忠实于上下文，但与问题毫不相关。

答案相关性的评估，通常由LLM来判断答案是否直接、充分地解决了原始问题。它关注的是答案的“效用”。在实践中，答案相关性低往往意味着检索环节出了问题——没有召回能真正回答问题的文档片段，或者重排序模块未能将最相关的片段排到前面。

2.3 上下文相关性：你检索的“证据”有用吗？

这个指标评估的是检索器返回的那一堆上下文（比如top-5的文档片段），其中有多少是真正与问题相关的。它跳过了生成环节，直接检验检索系统的“纯度”。

计算方式通常是：上下文相关性 = (相关片段数量) / (总检索片段数量)。比如，你设置了检索top-5的片段，其中3个片段确实包含了回答问题所需的信息，那么上下文相关性就是0.6。这个指标直接反映了你的向量嵌入模型、切片策略和检索算法的有效性。如果这个值持续偏低，你就需要回头去检查文档预处理和向量化环节了。

2.4 上下文召回率：你漏掉了关键“证据”吗？

与上下文相关性关注“纯度”相反，上下文召回率关注的是“查全率”。它评估的是，所有应该被检索到的相关文档片段中，你的检索系统实际找回了多少。这是一个更难评估的指标，因为它需要一个“标准答案”或“所有相关片段”的集合作为基准。

在实际操作中，我们通常需要构建一个评估数据集，其中每个问题都标注了知识库中所有与之相关的文档片段ID。然后运行检索，看能命中多少。这个指标对于衡量检索系统的覆盖能力至关重要，尤其是在知识库庞大、问题多样的情况下。低召回率意味着很多相关知识“沉没”在向量海洋里没被找到，可能需要调整检索时的相似度阈值、尝试混合检索（关键词+向量），或者优化文档切片的大小与重叠策略。

把这四个指标放在一起看，就构成了一个相对完整的评估视角：上下文相关性和召回率诊断检索系统，忠实度和答案相关性诊断生成系统。它们相互关联，比如低上下文相关性几乎必然导致低忠实度和低答案相关性。通过持续监控这四个维度的得分及其变化趋势，我们就能像给汽车装上一套仪表盘一样，实时了解RAG引擎的“运行状况”。

3. 构建自动化评估流水线：从脚本到服务

理解了指标，下一步就是让评估自动化、常态化。你不能每次优化后都手动跑一遍评估脚本。我们需要把评估流水线集成到开发流程和运维体系中。下面我以基于Spring Boot和LangChain4j的RAG服务为例，分享如何搭建这套系统。

3.1 评估数据集的设计与构建

一切数据驱动的评估始于数据。你需要一个高质量的评估数据集，通常包含三个核心字段：

• question: 测试问题。
• ground_truth_answer: 可选的“标准答案”，用于某些需要对比的评估（但RAGAS的核心指标大多不需要）。
• contexts: 更重要的，是标注出知识库中与每个问题所有相关的文档片段ID或内容。这是计算上下文召回率所必需的。

构建数据集有几种方式：

1. 人工标注：最可靠，但成本高。适合核心场景和基线测试。
2. LLM生成：用GPT-4等高级模型，基于你的知识库内容，自动生成一批问题及相关上下文。这是一个快速启动的好方法，但需要人工抽样校验。
3. 用户日志挖掘：从线上真实的用户问答日志中提取问题，并组织专家标注相关上下文。这是最贴近实际业务的数据。

在我的项目里，我们混合使用了方法2和3。先用GPT-4基于核心文档生成了200个种子问题，再每周从线上日志中抽取几十个高频或典型问题加入评估集。数据集以JSONL格式存储，便于流式读取。

// 评估数据集示例 (eval_dataset.jsonl) {"question": "产品A的保修期是多久？", "relevant_context_ids": ["doc_a_section_1", "doc_a_section_2"]} {"question": "如何重置产品B的管理员密码？", "relevant_context_ids": ["doc_b_section_5"]}

3.2 集成RAGAS与LangChain4j进行评估

LangChain4j对RAGAS有很好的集成支持。评估的核心步骤是：用你的RAG服务处理评估集中的每个问题，收集生成的答案和检索到的上下文，然后喂给RAGAS的评估器打分。

首先，在pom.xml中引入依赖（注意版本兼容性）：

<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-evaluation-ragas</artifactId> <version>0.31.0</version> <!-- 请使用与LangChain4j核心库匹配的版本 --> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-open-ai</artifactId> <version>0.31.0</version> </dependency>

然后，可以编写一个评估服务类。关键点在于，你需要能同时获取到RAG生成的答案和触发这次生成的检索上下文。在LangChain4j中，这通常意味着你需要自定义一个AiServices的监听器或使用ToolExecutionListener来捕获检索结果。

import dev.langchain4j.evaluation.ragas.*; import dev.langchain4j.model.openai.OpenAiChatModel; import dev.langchain4j.data.message.UserMessage; import dev.langchain4j.store.embedding.EmbeddingSearchResult; import java.util.List; import java.util.ArrayList; @Service public class RagEvaluationService { @Value("${openai.api.key}") private String openAiApiKey; // 假设这是你的RAG服务组件，能返回答案和上下文 @Autowired private MyRagService myRagService; public EvaluationResult runEvaluationBatch(List<EvaluationRecord> records) { // 1. 初始化RAGAS评估器（需要一个大模型，通常用GPT-4） OpenAiChatModel evaluationModel = OpenAiChatModel.builder() .apiKey(openAiApiKey) .modelName("gpt-4-turbo-preview") // 评估建议使用更强的模型 .temperature(0.0) // 评估需要确定性 .build(); RagasEvaluator evaluator = new RagasEvaluator(evaluationModel); // 2. 准备评估输入 List<RagasEvaluationInput> inputs = new ArrayList<>(); List<String> contextIdList = new ArrayList<>(); // 用于召回率计算 for (EvaluationRecord record : records) { // 调用你的RAG服务，并确保能拿到上下文 RagResponse response = myRagService.generateAnswer(record.getQuestion()); // RagResponse 应包含：answer, retrievedContexts (List<TextSegment>) RagasEvaluationInput input = RagasEvaluationInput.builder() .question(record.getQuestion()) .answer(response.getAnswer()) .contexts(convertSegmentsToStrings(response.getRetrievedContexts())) .build(); inputs.add(input); // 记录实际检索到的ID（假设你的TextSegment有ID） contextIdList.addAll(extractContextIds(response.getRetrievedContexts())); } // 3. 执行批量评估 RagasEvaluationResult ragasResult = evaluator.evaluate(inputs); // 4. 计算上下文召回率 (需要标准答案相关ID) double contextRecall = calculateContextRecall(records, contextIdList); // 5. 汇总结果 return EvaluationResult.builder() .faithfulness(ragasResult.faithfulnessScore()) .answerRelevance(ragasResult.answerRelevanceScore()) .contextRelevance(ragasResult.contextRelevanceScore()) .contextRecall(contextRecall) // RAGAS未直接提供，需自己算 .build(); } private double calculateContextRecall(List<EvaluationRecord> records, List<String> retrievedIds) { // 简化逻辑：对比每个问题下，检索到的ID与标准相关ID的交集 int totalRelevant = 0; int totalRetrievedRelevant = 0; for (int i = 0; i < records.size(); i++) { EvaluationRecord record = records.get(i); List<String> relevantIds = record.getRelevantContextIds(); List<String> actualRetrievedIds = ... // 从retrievedIds中获取对应第i个问题的ID totalRelevant += relevantIds.size(); // 求交集 relevantIds.retainAll(actualRetrievedIds); totalRetrievedRelevant += relevantIds.size(); } return totalRelevant > 0 ? (double) totalRetrievedRelevant / totalRelevant : 0.0; } }

注意：上述代码是概念性示例。实际集成中，最大的挑战是如何从你的RAG调用链路中可靠地捕获每一次问答所对应的精确检索上下文。你可能需要改造你的RetrievalAugmentor或使用LangChain4j的监听器机制。

3.3 将评估任务CI/CD化

自动化评估应该成为你CI/CD流水线的一部分。我们是这样做的：

1. 每日定时任务：在测试环境，每天凌晨自动运行全量评估数据集（比如500个问题），生成评估报告。
2. 合并请求门禁：当开发人员提交涉及RAG核心组件（如嵌入模型、检索策略、提示词）的代码变更时，会触发一个轻量级的评估（比如50个核心问题）。只有评估结果的关键指标（如忠实度）下降不超过预设阈值（如5%），代码才能合并。这有效防止了“优化”变“劣化”。
3. 评估报告：每次评估生成一个HTML或Markdown报告，除了展示四个维度的平均分外，还会列出得分最低的若干问题示例，方便定位问题。

# 一个简化的GitLab CI配置示例 stages: - test - evaluate-rag rag-evaluation: stage: evaluate-rag image: openjdk:17 script: - mvn test -Dtest=RagEvaluationServiceIT # 运行集成测试，内部调用评估 - python generate_evaluation_report.py # 用脚本分析结果，生成报告 artifacts: paths: - target/rag-evaluation-report.html only: - merge_requests # 仅对合并请求运行 - schedules # 以及每日定时任务

4. 从评估到监控：用Micrometer实现生产级可观测性

评估流水线告诉我们“在测试集上表现如何”，而生产监控告诉我们“在真实用户流量下实时表现如何”。这是两个互补的视角。我们需要把RAGAS的评估思想，以轻量化的方式，融入到生产环境的每一次用户请求中，进行抽样评估和指标上报。

4.1 设计生产环境可用的轻量化评估

在生产环境全量运行RAGAS评估是不现实的，因为每次评估都需要调用一次GPT-4，成本高昂且延迟大。我们的策略是抽样评估和代理指标。

1. 抽样评估：对一小部分（如1%）的用户请求，在后台异步执行完整的RAGAS评估。这能为我们提供持续的真实用户场景下的质量指标。
2. 代理指标：对于所有请求，计算一些低成本、能间接反映质量的指标。例如：
   • 检索得分阈值：记录每次检索到的top-1片段的相似度得分。如果这个得分持续很低，可能意味着检索效果变差。
   • 答案长度：生成的答案长度异常（过短或过长）可能预示着问题。
   • LLM响应时间与Token用量：异常波动可能意味着提示词或模型行为发生了变化。

4.2 使用Micrometer集成指标与Prometheus

Spring Boot Actuator与Micrometer是微服务监控的事实标准。我们可以很方便地创建自定义指标。

首先，添加依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>

然后，创建一个RagMetricsComponent来管理指标：

import io.micrometer.core.instrument.*; import org.springframework.stereotype.Component; import java.util.concurrent.atomic.AtomicReference; import java.util.List; @Component public class RagMetricsComponent { private final MeterRegistry meterRegistry; // 用于记录抽样评估的四个核心指标（Gauge，最新值） private final AtomicReference<Double> latestFaithfulness = new AtomicReference<>(0.0); private final AtomicReference<Double> latestAnswerRelevance = new AtomicReference<>(0.0); private final AtomicReference<Double> latestContextRelevance = new AtomicReference<>(0.0); private final AtomicReference<Double> latestContextRecall = new AtomicReference<>(0.0); // 用于记录每次请求的代理指标（DistributionSummary，分布情况） private final DistributionSummary retrievalTop1Score; private final DistributionSummary answerLength; private final Timer llmResponseTimer; public RagMetricsComponent(MeterRegistry meterRegistry) { this.meterRegistry = meterRegistry; // 注册Gauge指标，绑定到AtomicReference Gauge.builder("rag.quality.faithfulness", latestFaithfulness, AtomicReference::get) .description("最新抽样评估的忠实度得分") .register(meterRegistry); // ... 为其他三个指标注册类似的Gauge // 创建DistributionSummary和Timer retrievalTop1Score = DistributionSummary.builder("rag.retrieval.top1.score") .description("检索结果Top-1片段的相似度得分") .publishPercentiles(0.5, 0.95, 0.99) // 发布中位数、95分位、99分位 .register(meterRegistry); answerLength = DistributionSummary.builder("rag.answer.length") .description("生成答案的长度（字符数）") .register(meterRegistry); llmResponseTimer = Timer.builder("rag.llm.response.time") .description("调用LLM生成答案的耗时") .publishPercentiles(0.5, 0.95, 0.99) .register(meterRegistry); } // 方法：更新抽样评估结果 public void updateSamplingEvaluationScores(double faithfulness, double answerRelevance, double contextRelevance, double contextRecall) { latestFaithfulness.set(faithfulness); latestAnswerRelevance.set(answerRelevance); latestContextRelevance.set(contextRelevance); latestContextRecall.set(contextRecall); } // 方法：记录一次请求的代理指标 public void recordRequestMetrics(double top1Score, int ansLength, long llmTimeMs) { retrievalTop1Score.record(top1Score); answerLength.record(ansLength); llmResponseTimer.record(llmTimeMs, TimeUnit.MILLISECONDS); } }

在你的RAG服务逻辑中，在每次处理请求时，记录代理指标。对于抽样的请求，则异步触发完整评估，并更新Gauge指标。

@Service public class ProductionRagService { @Autowired private RagMetricsComponent metrics; @Autowired private AsyncEvaluator asyncEvaluator; // 异步评估器 public AnswerResponse handleQuery(String question) { long start = System.currentTimeMillis(); // 1. 检索 List<TextSegment> contexts = retrieve(question); double top1Score = contexts.isEmpty() ? 0.0 : contexts.get(0).score(); // 2. 生成 String answer = generateAnswerWithLlm(question, contexts); long llmTime = System.currentTimeMillis() - start; // 3. 记录代理指标 metrics.recordRequestMetrics(top1Score, answer.length(), llmTime); // 4. 抽样评估 (例如，基于用户ID哈希或随机数) if (shouldSample(question)) { asyncEvaluator.evaluateAsync(question, contexts, answer); } return new AnswerResponse(answer); } private boolean shouldSample(String question) { // 简单的1%抽样逻辑 return Math.abs(question.hashCode()) % 100 == 0; } }

4.3 配置Grafana仪表盘进行可视化

当指标通过/actuator/prometheus端点暴露后，就可以用Prometheus采集，并在Grafana中创建直观的仪表盘了。

你的仪表盘应该至少包含以下几个面板：

1. RAG质量四维指标趋势图：用4个Graph面板，分别显示rag_quality_faithfulness、rag_quality_answer_relevance等Gauge指标随时间的变化。设置告警线（如忠实度低于0.8触发警告）。
2. 检索健康度面板：
   • rag_retrieval_top1_score的平均值和95分位数趋势。如果95分位数持续下跌，说明很多请求的检索质量在变差。
   • 该得分的直方图，看分布是否正常。
3. 生成健康度面板：
   • rag_answer_length的分布和趋势。突然变长可能提示提示词被污染或模型行为改变。
   • rag_llm_response_time的耗时趋势和分位数。响应时间变长可能意味着模型服务或网络问题。
4. 请求量与错误率面板：标准的QPS和错误计数，与其他服务监控一致。

通过这个仪表盘，你就能在一个屏幕上，实时掌握生产环境RAG服务的整体质量、检索性能和生成稳定性。当某个指标发生异常波动时，你能立即发现并开始排查。

5. 实战中的典型问题与排查思路

有了评估和监控，就像医生有了化验单和监护仪。当指标异常时，如何诊断？以下是一些常见问题的排查路径：

5.1 忠实度突然下降

现象：仪表盘上faithfulness指标在某个时间点后持续走低。可能原因与排查：

1. 检索上下文质量下降：首先检查context_relevance和retrieval_top1_score是否同步下降。如果是，问题出在检索之前。
   • 检查嵌入模型：是否无意中切换或更新了嵌入模型？不同模型生成的向量空间不同，会导致相似度计算失准。回滚或进行A/B测试验证。
   • 检查文档源：是否有大量新文档入库，且预处理（切片、清洗）方式与旧文档不一致？检查最近的数据管道变更。
   • 检查向量数据库：是否进行了重建索引（Re-index）操作？索引参数是否改变？
2. 生成环节的提示词被修改：如果检索指标正常，但忠实度下降，大概率是提示词（Prompt）出了问题。
   • 审查最近部署：是否更新了包含系统提示词的配置文件？是否在代码中硬编码的提示词被修改？重点检查那些强调“严格基于上下文”的指令部分是否被削弱或删除。
   • LLM供应商或模型版本变更：是否从GPT-4切换到了其他模型？即使是同一个供应商，不同模型版本对指令的遵循程度也可能不同。
3. 上下文长度或格式变化：如果检索返回的上下文片段数量或格式发生了变化，也可能影响LLM的理解。
   • 检查retrieved_contexts的拼接逻辑：是否在上下文之间添加了清晰的分隔符？上下文总长度是否超过了模型的上下文窗口限制，导致尾部信息被截断？

5.2 答案相关性波动大

现象：answer_relevance得分不稳定，时高时低。可能原因与排查：

1. 问题多样性增加：检查最近评估数据集或抽样到的用户问题，是否出现了之前未覆盖的新领域或更复杂的问题类型？这可能是系统能力边界的正常体现。
2. 检索结果排序问题：答案相关性低但上下文相关性高，说明检索到了相关内容，但LLM没有使用最关键的那部分来生成答案。这可能是因为重排序（Re-ranker）模块失效或权重设置不合理。
   • 检查重排序服务：如果使用了交叉编码器等重排序器，检查其服务是否健康，返回的分数是否合理。
   • 调整上下文注入顺序：确保最相关的片段被放在提示词中靠前的位置。LLM有时会对靠后的信息关注度下降。
3. 提示词中的任务指令模糊：确认你的提示词中是否清晰定义了“回答用户问题”这一任务。可以尝试强化指令，例如：“请直接、简洁地回答用户的问题，不要添加无关的背景介绍。”

5.3 上下文召回率始终偏低

现象：context_recall一直上不去，意味着很多相关知识检索不到。可能原因与排查：

1. 切片策略不当：这是最常见的原因。文档切片（Chunk）太大，可能包含多个主题，导致嵌入向量“失焦”；切片太小，则可能丢失关键信息的完整性。
   • 实验不同切片大小和重叠度：对于技术文档，256-512个token的切片配合50-100个token的重叠，通常是个不错的起点。需要通过A/B测试找到最优解。
   • 尝试语义切片：不要简单按固定长度切分，使用基于语义的切分工具（如LangChain的RecursiveCharacterTextSplitter结合语义判断），确保每个切片在语义上相对完整。
2. 检索策略单一：仅靠向量相似度检索（语义检索）可能不够。
   • 引入混合检索：结合关键词检索（如BM25）。对于包含特定术语、产品名、错误代码的问题，关键词检索往往更准。使用LangChain4j的EnsembleRetriever可以轻松融合两者。
   • 调整检索数量：尝试增加top-k的值（例如从5增加到10），让更多候选片段进入重排序环节。
3. 嵌入模型与领域不匹配：通用的嵌入模型（如text-embedding-ada-002）对通用文本效果好，但在特定专业领域（如法律、医疗）可能表现不佳。
   • 考虑领域微调或专用模型：如果资源允许，可以在领域数据上微调一个开源的嵌入模型（如BGE、E5），或者使用该领域宣称效果更好的商用模型。

5.4 生产监控指标异常但评估集分数正常

现象：Grafana上显示retrieval_top1_score的95分位数在下降，但每日定时任务在评估数据集上的context_relevance分数却保持稳定。可能原因与排查：

1. 数据分布偏移：这是最需要警惕的情况。意味着真实用户的问题分布已经偏离了你构建评估数据集时的假设。你的评估数据集“过时”了，无法代表当前的真实流量。
   • 立即分析用户日志：对最近一周的用户问题进行聚类和主题分析，看看是否出现了新的、未覆盖的问题类型。
   • 动态更新评估集：建立机制，定期将高频或典型的新用户问题，经过标注后加入评估数据集。确保评估集与线上流量同步进化。
2. 评估集本身设计偏差：你的评估集可能过于简单或集中在某个优势领域，无法暴露系统在边缘场景下的弱点。
   • 补充“压力测试”问题：故意在评估集中加入一些模糊的、多义的、需要多步推理的复杂问题。
   • 进行对抗性测试：设计一些容易诱发幻觉或检索失败的问题，看看系统如何应对。

排查这些问题时，一个核心习惯是：永远将指标异常与具体的请求样例关联起来。不要只看聚合后的数字，要下钻查看那些导致低分的具体问题和答案。在日志中，为每次抽样评估记录完整的输入（问题）、输出（答案、上下文）和评分，这是你进行根因分析最宝贵的材料。

6. 超越基础评估：面向Agentic RAG与复杂工作流的思考

随着RAG向更复杂的Agentic RAG（智能体驱动的RAG）和涉及多步推理、工具调用的流水线发展，基础的RAGAS四维指标可能就不够用了。例如，一个RAG系统可能先检索文档，然后调用一个计算器工具处理文档中的数字，再生成最终答案。如何评估这样的系统？

这需要我们扩展评估框架。除了“答案是否正确”，我们可能还需要评估：

• 工具调用的正确性：系统是否在正确的时机调用了正确的工具？传递给工具的参数是否正确？
• 推理过程的合理性：对于多步推理，中间步骤是否逻辑连贯？
• 溯源完整性：最终答案中的每一个关键事实，是否能清晰地追溯到源文档的某个具体片段？这对于高合规性场景至关重要。

社区也在朝这个方向探索，例如引入基于准则的评估（Criteria-based Evaluation），定义更细粒度的评估维度，或者使用LLM-as-a-Judge（大模型作为裁判）的方式，让更强大的模型（如GPT-4）根据一套复杂的准则对回答进行评分和点评。

在实际工程中，我的建议是：先从基础的RAGAS四维指标和监控体系做起，把它做扎实、做自动化。这套体系能解决80%的质量可见性问题。当你的系统演进到更复杂的形态时，再在现有基础上，针对新的工作流环节，设计并添加新的评估维度和监控指标。例如，为工具调用成功率添加一个tool_call_success_rate的计数器，为推理步骤添加一个可解释的日志链路。评估体系的建设本身，也应该是一个迭代演进的过程，始终与你RAG系统的复杂度和业务需求保持同步。