做RAG项目最尴尬的时刻不是模型答错而是别人问你“你的RAG效果到底怎么样”你只能回一句“还行吧”。我早期做知识库问答也是这个状态线上看着回答挺流畅但一到业务方验收就露馅——他们拿出几十个刁钻问题一测答非所问的比例远超预期。后来我认真调研了一圈评估方案最终落在RAGAS上。这篇文章就完整记录我怎么用RAGAS从零搭起一套RAG系统评估流程包括指标怎么选、测试集怎么造、结果怎么解读以及在实战中踩过的坑。RAGAS是专门针对RAG检索增强生成系统的评估框架名字源自Retrieval Augmented Generation Assessment。它的核心思路是用LLM来评估LLM从答案忠实度、答案相关性、上下文精度、上下文召回率等维度给RAG系统打分。适合三种人看一是正在做RAG但不知道怎么量化效果的技术人二是想给RAG系统建立持续回归测试的团队三是做AI应用验收需要客观指标的项目负责人。1. 为什么需要RAGASRAG系统评估的痛点1.1 没有评估RAG就只是“感觉好用”RAG系统的效果取决于很多环节文档切分、向量检索、排序策略、提示词设计、模型能力任何一环出问题最终答案都会跑偏。更麻烦的是这些环节的问题很难靠肉眼发现。比如你调整了chunk size看几条样例觉得回答还不错但放到全量知识库上可能检索质量已经悄悄下降了只是样例没踩中而已。我经历过一次非常典型的翻车。当时把某个产品的操作手册接进RAG系统人工抽测了十条问题回答质量明显提升于是直接把新版本推到线上。结果第二天业务方反馈大量“如何导出数据”“权限怎么配”这类高频问题反而答得不如以前。排查后发现是切块参数改大了导致部分细粒度知识点在检索时因为向量被稀释而排到后面。这个教训让我明白没有一套标准化的评估集和量化指标你根本不知道改动到底是在优化还是在破坏系统。1.2 RAGAS能解决什么问题RAGAS解决的正是这个“说不清、比不了、难回归”的问题。它把RAG评估拆成几个可量化的维度再用LLM自动打分省去人工标注的成本。相比传统的“基于标注答案算rouge/bleu”的做法RAGAS更适合生成式任务的场景因为它不要求预测答案和参考答案逐字匹配而是从语义层面判断“答案有没有忠实于检索到的内容”、“检索到的内容有没有覆盖用户问题所需的信息”、“最终答案对用户来说有没有用”。对比一下传统评估和RAGAS评估对比维度传统评估ROUGE/BLEU等RAGAS评估核心思想字面重叠度匹配语义与逻辑关系判断是否需要参考标准需要标准答案可以不依赖标准答案评估维度单一文本相似度多维度忠实度/相关性/上下文质量对RAG适配度弱无法定位问题环节强可定位检索/生成环节实施成本需要人工准备大量标准答案可用LLM自动生成测试集所以RAGAS更适合当前主流的生成式RAG架构而且它提供的多个指标可以帮你定位问题到底出在哪个环节。比如上下文精度低说明检索到的内容里噪声太多上下文召回率低说明该检索的内容没检索全忠实度低说明模型在“自己编”而没有严格按照上下文回答。这一点在实际调优时价值巨大。2. RAGAS核心指标与原理2.1 四个核心评估维度拆解RAGAS最常用的一组指标是Faithfulness忠实度、Answer Relevancy答案相关性、Context Precision上下文精度和Context Recall上下文召回率。每个指标评估的环节不同合在一起就覆盖了“检索-增强-生成”全链路。Faithfulness忠实度忠实度衡量的是最终答案是否完全基于检索到的上下文来生成不能有编造内容。它的计算逻辑是先把答案拆成若干条陈述statements再逐条判断这些陈述能否从上下文中推导出来能推导出的比例就是忠实度分数。举个例子如果答案里写“该系统支持OAuth2.0登录”但检索到的上下文里根本没提OAuth2.0这条陈述就会被判为不忠实。分数范围0到1越接近1越好。我一般把阈值定在0.8以上低于这个数就说明模型有“自由发挥”的倾向需要调整提示词或者降低生成温度。Answer Relevancy答案相关性答案相关性与忠实度不同它不看“答案是否凭空捏造”而是看“答案是否完整回答了用户的问题”。计算方法是根据答案反向生成若干条问题再把这些生成的问题与原问题做相似度比较取平均值就是相关性得分。如果回答内容跑偏比如用户问“怎么配置告警”模型却回答了一堆告警功能介绍生成的问题就会和原问题偏离得分自然低。这里要特别注意一个坑答案相关性只衡量“回答是否切题”不衡量“回答是否正确”。哪怕答案内容全错只要它紧紧围绕问题展开相关性得分也会很高。所以这个指标适合配合其他指标一起看。Context Precision上下文精度上下文精度衡量的是“检索到的上下文中有多少对回答用户问题真正有用”。计算方式是把上下文按顺序分成若干片段从第一段开始逐渐增加判断用前n段是否足以回答用户问题这个判断也是交给LLM的最终以“有用片段在全量片段中的位置加权得分”来打分。我对这个指标的理解是它直接反映向量检索排序的质量。如果真正有用的知识点排在很后面前面全是无关段落上下文精度就会很低。这时候需要考虑优化embedding模型、调整重排序策略或者改进切块逻辑。Context Recall上下文召回率上下文召回率衡量的是“能够回答用户问题的信息是否都被检索到了”。它的判断方式是把标准答案拆成陈述句逐条判断每一条是否能从检索到的上下文中推导出来能推导出的比例就是召回率。这个指标最能反映“知识库有没有覆盖用户的问题”。如果召回率低原因一般是两种要么知识库里根本没有相关内容数据问题要么检索链路没有把相关内容捞出来检索问题。前者需要补数据后者需要调检索策略。2.2 “用LLM评估LLM”的机制RAGAS所有指标底层都依赖一个评判LLMcritic LLM来对输入输出做判断。说得直白一点就是用GPT这类大模型来当“阅卷老师”让它判断“答案陈述是否由上下文支持”、“生成的问题和原问题是否相关”这类细粒度问题。这种模式出道时争议不小毕竟用LLM当裁判看起来有点“自己给自己打分”的意思。但实际体验下来只要评判LLM够强我通常用GPT-4级别或同等能力的模型它的判断一致性比人工标注要高很多而且速度快、成本低。更重要的是它不需要针对每个领域定制规则开箱即用。当然如果项目涉及的数据非常敏感你也可以用私有化部署的Qwen、DeepSeek等模型来做评判RAGAS支持自定义评判模型的接入这一点后面实战部分会演示。用LLM评估LLM有一个前提条件评判模型的能力要显著高于被测模型。如果你用小模型做RAG生成又用同样的小模型去评估很可能会出现“坏答案也看不出来”的情况。所以评估环节我建议优先用当前可用范围内最强的模型宁可多花一点API费用也别在评判能力上将就。2.3 其他评估指标与扩展场景除了上面四个核心指标RAGAS还提供一些针对特定场景的指标。比如Answer Correctness答案正确性需要同时提供标准答案从语义相似度和事实正确性两个角度综合打分。适合已有标准答案库的测评场景。Noise Sensitivity噪声敏感度衡量当上下文中混杂无关信息时答案多大程度被带偏。Response Relevancy与Answer Relevancy类似但更侧重对话场景。Multi-turn Agentic RAG针对多轮对话和Agent场景还提供了SignalMetrics等模块比如判断对话过程中的“工具选择是否合理”、“计划执行是否成功”这块适合进阶做Agentic RAG的人研究。实际项目里我不建议一上来全指标上先跑通最核心的四个指标建立基线再根据业务场景扩展其他维度。初期指标太多反而让人抓不住重点。3. 环境准备与快速上手3.1 安装RAGAS与依赖RAGAS的安装比较简单直接用pip装就行。我自己是在Python 3.9版本的虚拟环境里跑通的建议使用Python 3.10以上版本后面有些依赖包对3.9的支持越来越不友好。pip install ragas默认安装会带上langchain-core、openai这些基础依赖。如果项目中还要做完整的RAG链路可能需要补充安装langchain、langchain-openai、langchain-community以及向量数据库客户端。我当前项目用的是PGVector所以还装了pgvector。pip install langchain langchain-openai langchain-community pgvector3.2 配置评判模型RAGAS底层需要调用LLM来做评判我习惯用OpenAI接口做演示。首先设置环境变量export OPENAI_API_KEY你的API Key如果你希望评判程序走自定义的Base URL比如国内的模型中转服务可以在Python代码里设置OpenAI相关配置。RAGAS 0.2版本之后推荐直接用langchain的ChatOpenAI实例来配置模型。from ragas.llms import LangchainLLMWrapper from langchain_openai import ChatOpenAI # 创建评判模型实例 eval_llm LangchainLLMWrapper( ChatOpenAI( modelgpt-4o, temperature0 ) )temperature设置为0很关键。评判任务应该保持稳定一致温度太高会让打分随机波动不利于系统回归对比。3.3 第一次跑通RAGAS评估用最快的方式跑通一次评估不需要接真实RAG系统直接手工构造几份数据就能看到指标输出。RAGAS接受的数据需要包含这样几个字段question用户问题answerRAG系统生成的答案contexts检索到的上下文列表ground_truth标准答案仅计算部分指标时需要我需要真实数据先自造一个典型案例。假设知识库是关于某企业内部系统“资产管理系统”的使用说明检索到的上下文、生成的答案等都可以手工构造。from datasets import Dataset from ragas import evaluate from ragas.metrics import ( faithfulness, answer_relevancy, context_precision, context_recall, ) # 手工构造评估数据 sample_data { question: [如何创建一条新的资产入库记录], answer: [ 创建资产入库记录需要进入资产管理系统的入库管理模块点击新增按钮填写资产编号、资产名称、分类、存放位置和使用人字段保存后即可生成入库记录。 ], contexts: [[ 入库管理模块用于处理所有资产入库操作。在入库管理页面点击新增按钮可以打开入库表单。, 入库表单需要填写资产编号、资产名称、资产分类、存放位置、使用人等信息其中资产编号是必填项。, 保存入库表单后系统会自动生成一条资产入库记录并同步更新库存台账。, ]], ground_truth: [ 进入资产管理系统入库管理模块点击新增按钮填写资产编号、资产名称、分类、存放位置和使用人保存后生成入库记录。 ], } # 转换为HuggingFace Dataset格式 dataset Dataset.from_dict(sample_data) # 执行评估 result evaluate( dataset, metrics[ faithfulness, answer_relevancy, context_precision, context_recall, ], llmeval_llm, ) # 输出结果 print(result.to_pandas())正常情况下你会在终端看到一行评估结果类似这样faithfulness answer_relevancy context_precision context_recall 0 1.0000 0.9872 0.5000 1.0000第一次跑通后你就能感受到RAGAS的几个特点不需要大量标注数据、每条样本只需要问题答案上下文就能出多个指标、整个流程可以脚本化批量执行。4. 完整实战评估一个知识库问答RAG4.1 从零构造完整的RAG问答流程为了演示效果我构造一个相对完整的个人知识库RAG链路用langchain做编排向量库用Chroma本地起不依赖外部服务方便复现然后接一个OpenAI模型生成答案。这个流程和RAGAS评估是解耦的评估时只需要把RAG链路产出的question、answer、contexts喂给RAGAS。先安装Chroma相关依赖pip install chromadb langchain-chroma然后写一个最小可用的RAG检索函数。假设知识库里已经存放了几篇关于“企业会议室预约系统”的操作文档。我抓取几条知识条目存入向量库再通过相似度检索拿回contexts最后用LLM基于上下文生成答案。from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_chroma import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_core.runnables import RunnablePassthrough # 初始化embedding模型和向量库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma( collection_namemeeting_room_manual, embedding_functionembeddings, persist_directory./chroma_db ) # 准备知识条目标实际项目可能来自大量文档切块 knowledge_docs [ 会议室预约系统支持按日期、时间段、容纳人数检索空闲会议室。, 预约会议需要先选择楼层再选择会议室系统会自动展示该会议室在所选时间段的占用情况。, 会议预约支持添加参会人参会人会收到邮件通知。, 如果会议室门禁与预约系统联动参会人可以使用企业微信扫码开门。, 取消会议预约需要在会议开始前至少30分钟操作否则会被记为违约。, 会议室管理员可以批量导入会议室信息包括会议室名称、位置、设备配置等。, 投影仪、视频会议终端等设备可以在预约会议室时一并预订。, 部门管理员可以查看本部门所有会议室的预约统计报表。, ] # 写入向量库 # 注意实际项目一般先切块再入库这里为了演示直接使用整条文档 vectorstore.add_texts(knowledge_docs) # 定义检索器 retriever vectorstore.as_retriever( search_typesimilarity, search_kwargs{k: 3} ) # 定义提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是企业内部系统的智能助手请基于以下知识内容回答问题不要编造知识库中没有的信息。\n\n知识内容\n{context}), (human, {question}) ]) # 构建RAG链 def rag_answer(question: str): contexts [doc.page_content for doc in retriever.invoke(question)] filled_prompt prompt.format(context\n.join(contexts), questionquestion) answer ChatOpenAI(modelgpt-4o-mini, temperature0).invoke(filled_prompt) return { question: question, answer: answer.content, contexts: contexts, }这里有一点值得说明为什么要单独做一个rag_answer函数而不是直接连成LangChain的LCEL链。原因是评估阶段不仅需要最终答案还需要拿到“检索到了哪些上下文”。如果把检索和生成耦合在一条链里后面提取contexts会比较别扭。做评估前我建议把RAG链路拆成“检索”和“生成”两个独立可调用的部分方便分别观察。4.2 用RAGAS自动生成合成测试集真实项目里通常没有现成的“问题-标准答案”对。RAGAS提供了TestsetGenerator可以从知识库文档中自动生成问答题。它以文档chunk作为输入让LLM扮演“提问者”结合文档内容生成可能被用户问到的问题同时附带标准答案。合成测试集特别适合还没有线上日志、冷启动的RAG项目。我自己的经验是先用合成测试集跑一版基线后续再把线上真实用户的badcase逐渐补充进去形成“合成数据真实数据”混合的测试集。先准备需要生成测试集的文档chunk列表from ragas.testset.generator import TestsetGenerator from ragas.testset.evolutions import simple, reasoning, multi_context # 初始化生成器 generator TestsetGenerator.from_langchain( generator_llmChatOpenAI(modelgpt-4o), critic_llmChatOpenAI(modelgpt-4o), embeddingsOpenAIEmbeddings(modeltext-embedding-3-small) ) # 准备文档chunk实际项目可以是切块后的所有文档片段 split_docs [ 会议室预约系统支持按日期、时间段、容纳人数检索空闲会议室。, 预约会议需要先选择楼层再选择会议室系统会自动展示该会议室在所选时间段的占用情况。, 会议预约支持添加参会人参会人会收到邮件通知。, 如果会议室门禁与预约系统联动参会人可以使用企业微信扫码开门。, 取消会议预约需要在会议开始前至少30分钟操作否则会被记为违约。, 会议室管理员可以批量导入会议室信息包括会议室名称、位置、设备配置等。, 投影仪、视频会议终端等设备可以在预约会议室时一并预订。, 部门管理员可以查看本部门所有会议室的预约统计报表。, ] # 生成测试集 testset generator.generate_with_langchain_docs( split_docs, test_size10, # 生成多少个测试样本 distributions{ simple: 0.5, # 简单问题占比 reasoning: 0.3, # 推理问题占比 multi_context: 0.2 # 需要综合多个上下文的问题占比 } ) # 转为pandas查看 testset.to_pandas()生成的测试集非常接近真实用户提问的风格比如“会议室预约支持哪些检索条件”“如果我迟到了30分钟以上预约会被取消吗”“设备预订在哪个环节完成”这里有一个经验性的建议不要一味生成“简单”类型的问题要提高“推理”和“多上下文”类型问题的比例因为这类问题更容易暴露出RAG系统在信息整合和推理方面的缺陷。实测下来如果测试集全是简单直问RAG系统的分数普遍虚高。4.3 跑通一次完整的RAGAS评估流程有了测试集接下来就把问题逐条喂给RAG链路拿到answer和contexts然后交给RAGAS打分。from datasets import Dataset # 收集RAG系统的实际表现 questions testset.to_pandas()[question].tolist() eval_samples [] for question in questions: result rag_answer(question) eval_samples.append(result) # 构造评估数据集 eval_dataset Dataset.from_list(eval_samples) # 执行评估 from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall result evaluate( eval_dataset, metrics[ faithfulness, answer_relevancy, context_precision, context_recall, ], llmeval_llm, ) df result.to_pandas() print(df.mean(numeric_onlyTrue))综合得分输出大概长这样faithfulness 0.86 answer_relevancy 0.91 context_precision 0.62 context_recall 0.74 dtype: float64看到这组数据典型的“检索环节拖后腿”特征就出来了。答案本身的忠实度和相关性都还不错但上下文精度只有0.62说明检索结果中混入了大量无关片段上下文召回率0.74说明有一部分该被检索出来的内容没有出现在top结果里。这时候调优的重点就很明确了不是去调生成模型而是去优化embedding模型、重排序策略和chunk切分策略。4.4 结合线上真实问题构建回归集合成的测试集毕竟不能完全代表线上场景尤其是业务方关注的那些刁钻问题合成数据经常覆盖不到。我在项目稳定运行后会定期从线上日志中捞取“用户实际提问但回答效果不好”的case加入测试集。具体做法是对线上问题做一轮简单聚类去重后选出高频且覆盖不同业务模块的问题人工确认正确答案或至少确认检索内容然后进入评估集。这个动作看起来简单但对系统长期演进非常有价值。没有回归集后面每次模型升级、向量库变更、提示词调整都是“盲改”。我个人维护的评估集大概有三层测试集层级来源用途更新频率核心回归集线上高频低质问题防止回归每周新增badcase合成集TestsetGenerator生成冷启动基线按需重建业务专项集业务方提供验收核心场景月度沟通确认4.5 多轮对话与Agentic RAG场景的评估标题里我用了“完整实战教程”所以顺带提一下更进阶的场景。如果RAG系统做成多轮对话模式评估起来比单轮问答复杂得多。因为多轮场景下模型不仅要回答当前问题还要考虑对话历史中的指代和上下文。RAGAS官方现在也有针对Agentic RAG的SignalMetrics比如判断Agent在回答过程中是否选对了工具、是否合理规划了步骤。我在一个IT服务台智能工单分派Agent项目中试用过一部分它的思路是结合Agent内部执行轨迹对每一步做“信号级”打点汇总成可信度、规划质量等指标。不过这部分的生态还在快速演进中稳定性和文档完善程度都不如单轮问答四个指标。建议先把单轮问答的评估体系搭扎实再考虑多轮和Agent场景。多轮场景也可以先用“把对话历史拍平后重新评估单轮”的简化方法来过渡。5. 常见问题与排查技巧实录5.1 评判指标异常低先别急着改模型我最初跑RAGAS时遇到过一个问题faithfulness得分只有0.3当时第一反应是生成模型太差马上换更大的模型。换完之后发现得分反而更低后来排查才发现是评判LLM在拆解答案陈述时“太严格”把一些常识性描述也当成需要上下文支持的陈述导致误判。遇到指标异常先别急着手动调参。我建议按这个顺序排查单独抽查几条样本看评判LLM给出的详细理由。RAGAS支持将评估过程拆解开你可以看到每个陈述被判定为“支持”还是“不支持”。确认评判LLM本身没问题换一个更强或不同厂商的模型对比一下打分差异。确认上下文内容真的够不够很多时候低分不是误判而是检索到的内容确实答不了问题。确认问题的设计是否合理如果问题本身超出了知识库范围任何指标都会很难看。5.2 context_recall低常见原因与对策context_recall这个指标最容易让人抓狂因为它的影响面很大。我总结了三个最常踩的坑知识库覆盖不足。知识库里压根没有能回答问题的内容再好的检索也白搭。判断方法简单直接拿问题去向量库检索看看top3返回的片段是不是和问题完全不搭边。如果是先补文档。切块粒度不合适。chunk太小关键信息被拆散chunk太大内容噪声多、向量表达不聚焦。我踩过的实际案例是说明书类的文档按固定500字切块把“系统要求”和“安装步骤”混在同一块里召回还行但精度很差。后来改成按标题结构切块指标立马改善。embedding模型和领域文本不匹配。通用embedding在垂直领域比如法律文书、医疗术语、代码文档上表现不稳定。可以用一个最简单的“金句检索”测试来验证手动构造几对“典型问题-期望命中文档”用向量相似度排序看看目标文档能不能进top10。进不了就得认真考虑换embedding模型或加BM25混合检索。5.3 API费用高优化测试集规模和质量RAGAS评估按样本数消耗LLM调用次数每个样本跑四个指标大概要调用十几次LLM。测试集太大时API费用确实肉疼。我踩过的坑是初期一股脑生成了200条测试集跑一次评估烧掉不少钱后来优化策略是单次评估样本数控制在50条以内足以反映整体趋势。优先跑核心指标比如faithfulness和context_recall相关性类指标按需再补。定期从线上badcase中精选问题而不是盲目堆积样本。5.4 评分浮动大怎么保证可复现RAGAS底层依赖LLM输出虽然我设置了temperature0但不同批次评估时分数仍然可能略有波动。建议每次优化前后用完全相同的测试集和相同的评判模型做对比并记录评估日期和模型版本。连续多次评估时取平均值而不是单次结果。我现在的做法是把评估纳入CI流程每次改动RAG链路后自动触发一次小规模评估20条核心回归集输出一份评估报告。任何指标下降超过5个百分点就告警这比靠人肉测试靠谱得多。5.5 要不要用API评估私有化场景的取舍关于“RAG必须用API吗”这个话题我的结论是正式评估环节完全可以用本地私有化模型不一定非要调外部API。RAGAS的评判模型本身可以替换成任意OpenAI兼容接口模型比如本地部署的Qwen2.5-72B、DeepSeek-V3蒸馏版等。只要模型能力足够强评估结果不会比GPT-4差太多。但这里有一个现实问题小参数模型的评判能力确实不稳定。我用7B级别的模型做过对比发现它在判断“陈述是否由上下文支持”这种细粒度逻辑时经常误判导致faithfulness分数失真。建议至少用70B级别或同等能力的模型来当评判LLM评估这个环节不是省钱的地方。6. RAGAS评估结果的调优实践6.1 根据指标定位问题环节上面的流程跑通后评估就变成了一件可重复的事。更大的价值在于不同指标的分数组合能帮你快速定位问题环节。指标表现高低Faithfulness生成忠实于上下文模型在编造查提示词/降低温度Answer Relevancy回答切题生成读不懂问题查问题改写/提示词Context Precision检索结果干净无关内容多查embedding/重排序/切块Context Recall检索覆盖全面漏检查切块/检索策略/知识库完整性举个例子如果context_precision低但context_recall正常说明检索结果里混入了太多不相关片段但相关的内容都捞到了。优先做的是加粗排rerank或者调小k值。如果context_recall低但context_precision正常说明该捞的没捞到优先做的是调大k值、改进切块或者加混合检索。这个定位逻辑是我认为RAGAS最大的价值所在。它让你从“盲人摸象”式的调优变成“按图索骥”式的修改每次改动都有明确目标。6.2 一个实际的调优案例我在一次企业内部知识库项目中用RAGAS跑出这样的基线faithfulness 0.82 answer_relevancy 0.88 context_precision 0.65 context_recall 0.70context相关指标明显偏低。当时知识库是各种格式混合的文档Word、PDF、Markdown都有。分析后定位到两个问题一是切块逻辑用了固定的300字符导致很多语义完整的段落被截断。比如一个“会议室预约流程”的描述被拆成好几块完整流程信息分散到不同chunk里。改为按标题和段落结构切块后context_recall一下从0.70涨到0.81。二是检索结果没有做rerank。原先是embedding相似度直接取top5改为在top20候选里用重排序模型精排后context_precision从0.65涨到0.78。这两个改动没有动任何生成环节的代码但整体评估分数提升幅度非常可观业务方的主观体验也确实更好了。这个案例说明评估模型给到的数据确实能倒逼你去做那些不容易想到但收益很大的基础优化。6.3 将评估纳入迭代流程最后分享一个我目前在用的固化作法RAG评估不是“上线的最后一步”而是每个迭代循环里的一步。我一般这样安排功能开发前先跑基线评估记录当前各指标得分改检索链路/换模型/调提示词后跑同一套回归集指标持平或提升继续往下走指标下降暂停合并先排查原因。这套流程跑顺之后RAG项目的迭代节奏会清晰很多。团队成员不再靠“我觉得这样回答好一些”来争论而是用同一套客观标准讨论方案。另外还有一个细节线上上线后我也会保留每次模型版本的评估快照方便回溯。有一次项目上线后业务方反馈“回答变差了”回查评估快照发现是某次embedding模型升级导致context_precision掉了4个点但当时没有纳入回归检查。后来把这个版本回退问题立刻解决了。这个经历给我的教训是RAG链路中每一个组件的版本变化都要经过评估验证哪怕只是“模型升级小版本”这种看似无关的改动。
