★ FEATURED ARTICLE 你有没有遇到过这种场景同一个生成式AI应用在demo演示时惊艳全场一上线跑真实流量就频频翻车——答非所问、格式跑偏、一本正经地编数据。调试prompt修好一类case另一类case又坏了陷入按下葫芦浮起瓢的循环。我在多个生成式AI项目里反复踩过这个坑之后越来越确定一件事生成式AI的应用开发真正的分水岭不在于模型选得多强、prompt写得多花哨而在于你有没有一套质量评估与优化的闭环机制。这套机制就是我这篇系列第八篇想展开的评估-优化模式Evaluator-Optimizer Pattern。这个模式解决的核心问题是生成式AI的输出天然带随机性和不确定性你不能像传统软件一样靠单元测试和分支覆盖来保证质量只能靠持续评估、定向优化来逼近稳定。这篇文章会从架构拆解、Judge设计、优化回路、工程化组合四个层面讲透并附上我实际项目里的代码骨架和踩坑记录。适合已经在用大模型做应用、但卡在效果不稳定阶段的团队阅读也适合准备把生成式AI能力接入生产系统的同学做设计参考。1. 为什么我把它放在系列第八篇生成式AI项目的黑盒焦虑聊设计模式总得先弄清楚它解决什么问题。评估-优化模式的位置很特殊它不负责让模型生成得更好而是负责让系统知道生成得好不好、并持续变好。在我接触过的生成式AI落地项目里这个能力恰恰是最晚被团队补上的。1.1 生成式AI的黑盒焦虑到底在焦虑什么传统软件开发里一个函数输入确定、输出就确定测试用例覆盖到位质量就能兜住。生成式AI完全不同——同一个prompt同一套参数温度调到0也可能因为采样细节产生差异调到0.7更是每次输出都不一样。更麻烦的是你很难写一个断言来判定输出对不对摘要类任务两句prompt打天下是很多团队初期的常态。但一旦业务方开始提指标要求——准确率要达到多少、错误率要低于多少你就不得不面对一个现实没有评估机制就没有优化依据。prompt的每次改动只是感觉变好了还是在碰运气式调优完全无法回答。1.2 评估-优化模式在整套设计模式中的定位如果把这个系列前面聊过的RAG模式、Agent模式、路由模式比作汽车的发动机、变速箱和转向系统那评估-优化模式就是仪表盘和方向盘。前面那些模式解决的是怎么让车跑起来评估-优化解决的是怎么知道跑偏了、怎么修正方向。两者缺一不可甚至后者的天花板决定了整个应用能走多远。这也是为什么我把评估-优化模式放到系列第八篇——没有前面那些生成、检索、编排模式打底评估-优化容易变成空中楼阁但有了前面那些模式之后再来补评估优化很多当初解释不了的质量问题就都有了明确答案。2. Evaluator-Optimizer架构拆解双引擎闭环怎么转起来评估-优化模式的核心是把生成和改进生成拆成两个独立的处理单元生成器Generator负责产出初始结果评估器Evaluator负责给结果打分并给出反馈优化器Optimizer根据反馈产出修正版本。三者形成一个闭环直到评估通过或达到迭代上限。2.1 生成器与优化器的职责分离逻辑很多团队的做法是一个prompt干到底生成、检查、修改全写在一段指令里。这样做的优点是省一次模型调用缺点是职责混在一起后每一层指令都在抢占模型有限的注意力——生成的时候想着还要自检自检的时候又想着还要修改哪一步都做不深。把生成器和优化器分开之后各管一段逻辑就清晰了生成器只需要专注于从上下文中提取重点、组织语言结构不需要操心质量问题优化器则拿到评估器给出的具体修改意见逐条修订戴着镣铐跳舞反而跳得更稳。代价是多一两次模型调用后面会聊怎么控成本但这个架构上的取舍我认为值得。2.2 评估器的核心Judge的设计原则评估器是整个闭环里技术含量最高的部分它本质上是另一个裁判模型——接收生成结果和评估标准输出质量分数和改进建议。Judge设计有三条核心原则我在项目里反复验证过评估标准必须显式化不能写请判断这段话好不好必须拆成事实准确性、逻辑连贯性、格式合规性、语气一致性等可判别的维度。输出必须是结构化的要么是JSON格式的维度分数说明修改建议要么是固定模板的文本方便后续代码解析。评估器与生成器的上下文需要隔离如果评估器看到的是生成器看到过的完整历史很容易被生成器的自信语气带偏客观性会大打折扣。2.3 一个最小可跑的Evaluator-Optimizer骨架下面这套骨架是我在内部工具链里一直在用的简化版用Python写大模型调用统一封装成llm()函数。核心思路是先生成再评估如果不达标就走优化循环。import json from typing import Dict, List def generate(transcript: str, style_guide: str) - str: 生成器只负责根据原文和风格指南产出初稿 prompt f 你是一名内容编辑。根据以下会议记录和风格指南生成一篇会议纪要。 会议记录 {transcript} 风格指南 {style_guide} 要求 - 只输出纪要正文不要任何解释。 - 使用中文结构按结论-依据-行动项组织。 return llm(prompt, temperature0.3) def evaluate(candidate: str, eval_standard: str) - Dict: 评估器Judge返回结构化评分与修改建议 prompt f 你是一名严格的质量评审。根据以下评估标准对候选文本进行打分。 评估标准 {eval_standard} 候选文本 {candidate} 请以严格JSON格式返回不要输出其他内容 {{ scores: {{factual_accuracy: 0-5, completeness: 0-5, format_compliance: 0-5}}, overall_pass: true/false, issues: [问题1, 问题2], revision_suggestions: [具体修改建议1, 具体修改建议2] }} raw llm(prompt, temperature0.0, response_formatjson) return json.loads(raw) def optimize(candidate: str, evaluation: Dict, original_source: str) - str: 优化器根据评估反馈返回修订稿 issues \n.join(evaluation[issues]) suggestions \n.join(evaluation[revision_suggestions]) prompt f 你是一名资深编辑。初稿未能通过质量评审请根据问题和修改建议进行修订。 初稿 {candidate} 评审问题 {issues} 修改建议 {suggestions} 原始材料供修订时核对 {original_source} 要求 - 只输出修订后的完整文本不要解释修改过程。 - 不要引入原始材料中不存在的信息。 return llm(prompt, temperature0.3) def run_pipeline(transcript: str, style_guide: str, eval_standard: str, max_iters: int 3) - Dict: 主循环生成 - 评估 - 优化直到通过或达到迭代上限 candidate generate(transcript, style_guide) history [] for i in range(max_iters): evaluation evaluate(candidate, eval_standard) history.append({iter: i 1, evaluation: evaluation}) if evaluation[overall_pass]: return {passed: True, text: candidate, history: history} candidate optimize(candidate, evaluation, transcript) return {passed: False, text: candidate, history: history}这个骨架有几点值得注意temperature在不同环节设置不同——评估器的temperature设成0让打分尽量稳定客观生成器用0.3保留一定表达多样性但不至于太飘。max_iters必须设一个上限否则遇到评估器持续不通过的情况你会被不可控的模型调用成本拖垮后面聊成本控制时再细说。3. LLM-as-Judge的实现门道评估维度、打分方式与三大偏差Judge是本模式的核心动力它的质量直接决定整个闭环的质量。很多人以为Judge就是用另一个大模型帮忙打个分实际落地时会发现一堆隐蔽的工程问题。3.1 评估维度怎么定从通用指标到任务专属指标评估维度是最容易走极端的地方。维度太少Judge看不出差异维度太多每个维度都浅尝辄止反而拉低整体判断质量。我的经验是分成两层第一层是通用维度任何生成任务都适用事实准确性有没有编造、指令遵循度有没有按prompt要求做、格式合规性结构是否清晰、信息完整性有没有漏关键信息。第二层是任务专属维度例如摘要任务看要点覆盖率和忠实度客服回复看语气适配度和解决方案可执行性代码生成看可运行性和安全风险。任务专属维度才真正决定了一个Judge能否在具体场景里派上用场。维度描述必须具体。比如忠实度如果只写是否忠实于原文Judge很难把握我会改成是否出现原文中不存在的事实、数字、人名、结论。让Judge像对着checklist工作一样打分稳定性会高很多。3.2 打分方式点分数、排序、成对比较的取舍Judge的打分方式主要有三种直接给分如0-5分、排序比较同一需求多样本排优劣、成对比较两个候选二选一。我在不同场景里都用过体会是直接给分实现最简单但分数分布可能整体偏高或偏低不同Judge之间的尺度也不一致。排序比较适合从多个候选里挑最好的场景比如一次生成5个摘要选1个模型比选优通常比绝对打分更稳。成对比较精度最高但调用成本也最高——每比一次就是一次模型调用N个候选要比较N-1次以上。我通常在A/B回归测试里用成对比较日常线上打分用直接给分。如果选择直接给分建议把分数档位写得越具体越好比如4分存在小瑕疵但不影响核心信息理解而不是4分较好。模糊的档位描述会让Judge的评分标准漂移。3.3 三大Judge偏差与规避手段用大模型当裁判天然继承了大模型自己的偏好这三个坑我都在项目里实测踩过位置偏差评估器倾向于对排在前面的内容给更高权重。规避方法是在评估prompt里明确要求阅读完整候选文本后再打分而不是基于第一印象。自我偏好偏差同一个大模型家族既当生成器又当评估器时它往往对自己家族的输出给更高分。规避方法是在评估prompt中去除模型身份信息不透露是谁生成的。冗长偏差模型普遍觉得写得多写得好长文本得分虚高。规避方法是把简洁性单独列为评估维度并在示例中同时给出优秀短答案和冗长低质答案做对比。另外Judge的评估prompt里最好带1-2个Few-shot示例一个高质量正例、一个低质量负例比在文字里反复强调要严格有效得多。这是我实测下来性价比最高的Judge优化手段。4. 优化回路的落地方式别再只会重写prompt评估器输出分数和建议之后怎么把反馈变成更好的结果很多人的第一反应是把建议拼回prompt再生成一遍这在简单场景有效但深入之后你会发现优化回路有更细腻的落地方式。4.1 触发式重写、反馈注入与自适应示例选择我把优化回路按反馈利用深度分成三档触发式重写最轻量的一档。只在评估未通过时把评估器输出的具体问题原样喂给优化器照着改。适用于格式错误、遗漏要点这类明确问题。反馈注入中档。不直接贴评估原文而是把评估结果转译成约束条件例如评估器发现候选文本使用被动语态过多注入的指令就是改为主动语态主语尽量明确。这一步的差异在于翻译反馈效果好坏取决于你是否定义了合理的转译规则。自适应示例选择最高档。系统预先准备多套Few-shot示例池评估器判断问题类型后动态选择对应类型的示例拼进优化器prompt。比如发现回答过于冗长就注入一个简洁回答的示例发现事实性错误就注入一个严格忠于原文的示例。我一开始只用了第一档后来发现触发式重写在某些复杂任务上会原地打转——评估器说不够简洁优化器删几句评估器又说信息缺失优化器又加回去反复横跳。换成反馈注入示例选择的组合之后收敛速度快了一倍不止。4.2 离线优化资产评测集、Bad Case库与版本回归闭环要真正跑起来不能像打地鼠一样今天改这个明天改那个必须沉淀三类资产。第一是评测集。从业务场景里收集一批有代表性的输入每条输入配上人工标注的理想输出或关键考核点。规模不一定大我见过效果很好的团队只用200条评测样本但每一条都经过严格人工审核覆盖了主要业务类型和困难case。评测集的价值是让系统变好变成可量化指标——每次改动prompt、换模型、调参数都拿同一套评测集跑一遍对比得分。第二是Bad Case库。线上用户反馈、人工抽检发现的失败case全部归档标注失败原因是检索问题、生成问题、还是评估标准问题。Bad Case库越厚评测集的迭代方向就越清晰。第三是版本回归流程。所有prompt修改、模型切换、链路调整都必须先在线下评测集上回归再灰度上线。这个习惯看起来只是流程严谨问题实际能救你很多次——我就经历过某个prompt优化让线上摘要分涨了但评测集上忠实度悄悄跌了5个百分点的案例如果没有回归这个隐患就会带着真实流量一起上路。4.3 线上护栏何时让人介入、何时让机器自纠评估-优化闭环可以放在离线阶段也可以放在线上推理链路里。放在线上就变成了一个护栏系统。我建议线上部署遵循分级干预原则第一级轻量规则预检长度异常、空输出、关键格式缺失这些用正则和简单判断就能捕获不需要调大模型评估成本近乎为零。第二级大模型评估对通过预检的输出做质量评分低于阈值就触发优化器重写。第三级人工介入连续优化多轮仍未通过或涉及高风险场景金融建议、医疗信息等降级到人工处理不能在自动优化里无限打转。这个设计背后是对系统可靠性和用户体验的平衡。完全交给机器自纠用户会等到焦虑动不动丢给人工成本又不可控。分级干预是我目前找到的比较务实的折中方案。5. 把评估-优化和RAG、Agent、Guardrails拼起来用设计模式单独讲都清清楚楚一放进真实系统就全是组合问题。评估-优化模式和其他几个模式的关系我在落地时摸索出了几条边界和衔接方式。5.1 Agent场景下的评估层级Agent类应用比单轮生成复杂得多因为中间有工具调用、多轮规划错误可能出在任何一个环节。我给Agent系统设计了四层评估结果层最终返回给用户的内容质量复用前述的通用专属维度打分。过程层Agent的决策是否合理比如是否调用了正确的工具、参数是否合法、有没有在关键步骤上自相矛盾。效率层Agent是否绕了远路比如明明一次工具调用能完成却来回调了三遍。安全层输出是否包含计划外的敏感内容、是否执行了非法操作。四层评估的优先级是安全层最高、结果层次之、过程层再次、效率层最后。线上环境通常只开安全层和结果层过程层和效率层放到离线评测里评估否则延迟和成本都会爆炸。5.2 与RAG模式的衔接评估检索还是评估生成RAG链路里最让人头疼的问题——检索到的内容里根本没答案但模型还是硬编了一个根源往往不在生成而在检索。如果只对最终输出做评估你永远分不清是检索质量差还是生成质量差。我的做法是在RAG链路上分两段评估检索段评估评估检索片段和用户问题的相关性、覆盖度。可以直接用LLM给问题-片段对打相关性分低于阈值就触发补充检索或改写查询。生成段评估评估最终回答的事实忠实度——是否严格基于检索片段有没有引入外部知识。两段评估的结果要分开记录。当线上答案质量波动时先看检索段得分是不是也掉了能迅速定位问题出在召回还是生成而不是整条链路一起排查。5.3 与Guardrails模式的边界划分Guardrails护栏模式和评估-优化模式功能上有重叠很多团队分不清该用谁。我给出的边界判断是评估-优化模式用于质量不够好的场景——输出符合规范但不够准确、不够完整、不够简洁需要优化提升。Guardrails模式用于不能越线的场景——涉及敏感内容、非法指令、Prompt注入、数据泄露风险一旦触发直接拦截根本没有优化后放行的说法。一个管好不好一个管能不能给用户两者串成流水线先过Guardrails拦截硬性违规再过评估-优化打磨质量。这个顺序不能反如果先把质量优化到很好但内容本身违规那整个闭环等于在给违规内容做美化。6. 团队落地建议评测集怎么建、指标怎么选、成本怎么控模式再好落不了地都是纸上谈兵。最后这部分结合我的实际经验给准备引入评估-优化模式的团队一些可执行的建议。6.1 评测集以小步快跑方式起步很多团队一上来就想建完整的评测集结果收集了两周还在收集未落地先内耗。我的建议是先50条跑通流程再200条稳住指标最后按场景持续扩充。第一批50条覆盖主要业务类型每条都有人工标注的理想输出要点它的作用不是评估而是让团队成员对什么叫好达成共识。第二批200条加入线上真实流量中出现的困难case、Bad Case库里的典型问题让评测集开始对真实场景有统计意义。长期维护每次版本回归后把产生分歧的样本拉出来review持续补充边缘case。评测集的质量把控有个小技巧每次评测集更新后先让两个以上的人对同一批输出独立打分算一下打分一致性。如果一致性只有60%说明标注标准本身还没对齐这时候拿评测集去衡量模型优劣是自欺欺人。6.2 指标选择矩阵质量、成本、延迟三线并行评估-优化模式除了关注内容质量指标还必须把成本指标和延迟指标放进同一套评估框架里。我习惯给每个候选方案跑一张矩阵表维度推荐指标作用内容质量评估器综合分、人工抽检合格率、Bad Case率判断输出好不好成本单次请求平均成本、优化迭代平均次数判断闭环跑不跑得起延迟P50/P95响应时间判断上线体感是否可接受具体到评估-优化模式最需要盯的是优化迭代平均次数。如果这个数字持续大于2说明初始生成质量太差或者评估器的反馈质量不行光靠优化回路在硬撑。真正的健康状态应该是绝大多数case一次生成就通过少数case优化1轮后通过极少case需要2轮以上连续优化多轮仍不通过的case应该成为Bad Case库里的重点分析对象。控制优化迭代次数的实用手段有三个一是提高生成器质量从源头减少返工二是收紧评估标准让通过的含义更明确三是设置合理的max_iters强制终止那些低效的反复重写。6.3 Bad Case闭环流程从发现到收敛最后聊一个团队流程问题Bad Case发现之后怎么让它真正推动系统进步。我整理了一个四步闭环团队按这个节奏每周迭代一轮收集线上监控、用户反馈、人工抽检、评测集运行结果四路汇总。归类每个Bad Case打标签——是评估维度定义不清、生成器能力不足、优化器反馈不准还是链路上游问题。修复分头处理。维度问题改评估prompt生成不足换模型或调参反馈不准改Judge上游问题调检索或工具逻辑。回归修复后跑全量评测集对比修复前后的整体得分防止顾此失彼。这个流程跑起来之后团队的日用节奏会从谁想起来谁调一版prompt变成每周有数据驱动一次系统更新。效果可能不像换个大模型那样立竿见影但累积下来的稳定性提升才是生产系统真正需要的东西。我自己的体会是评估-优化模式不是那种看懂就觉得惊艳的炫技型设计它更像项目管理里的复盘机制——不起眼但决定了团队能不能在一个方向上持续变好。生成式AI应用开发还远没到开箱即用的阶段谁能早一点把评估-优化闭环搭起来谁就能早一点把不可控的模型输出变成可管理的系统行为。
阅读完成 · 觉得有帮助？
