关注LLM应用开发的同行这两年应该都听过一句话模型不是代码。这句话听着很玄但做应用工程的人都懂它的分量。传统后端代码写错了单测能抓住编译能抓住最不济上线后有日志和监控兜底但提示词写错了很多时候只是在评测集上悄悄掉了几分用户那边反馈一句“感觉没有以前好用了”你连复现都不好复现。今天这篇我想把我们在流水线改造上做的一件事完整沉淀下来把模型评测和Prompt版本管理真正搬进CI/CD让每一次发布从“感觉上没问题”变成“数据上说得过去”。这篇文章适合正在做LLM应用交付、被提示词反复改坏过、被评测标准模糊拖累过的团队成员。不管你们是已经用上Dify这类低代码平台还是自己维护一套推理服务这套思路都可以直接借鉴。我不会只讲理念会把目录结构、评测集格式、流水线阶段设计、踩过的坑都写清楚方便你们直接拿去改。1. 为什么LLM应用需要一套独立的CI/CD而不是沿用后端那套1.1 传统流水线管不好两件东西提示词和评测先说说我们之前的处境。团队最早做LLM应用的时候流水线是从普通后端服务那边直接拷贝过来的代码推上去跑一遍单元测试构建镜像部署到测试环境人工点一遍然后上线。这套流程对纯代码逻辑没什么问题但一旦牵涉到模型能力和提示词就出现两个传统流水线完全覆盖不到的盲区。第一个盲区是提示词没有版本。当时提示词散落在各个地方有写在代码常量里的有存在数据库配置表里的还有团队同学直接在某低代码平台的界面上改的。结果就是同一个问答机器人今天和明天的行为可能不一样但没有人能说清楚到底是哪条提示词变了、什么时候变的、为什么变。最痛苦的一次线上出现明显回复质量下降我们查了整整半天最后发现是一个同事在平台的调试界面里微调了一版措辞他觉得自己只是“临时看看效果”结果不小心保存成了正式版本。第二个盲区是评测没有自动化。代码有没有BUG靠单测能判断模型回答得好不好以前完全靠人工看。每次要发版就拉几个核心同学进会议室把几十条测试用例一条条人工跑一遍然后凭感觉投票这条回答还不错那条有点偏整体感觉可以上。这种做法有几个致命问题第一人工评测的标准不稳定今天A觉得好、明天B觉得差第二覆盖量极低几十条用例根本反映不了线上真实流量第三没有历史对比你没法知道这版提示词相对上一版是变好了还是变坏了。1.2 想在流水线里解决的两个核心问题想清楚痛点之后我们给这套改造定了两个核心目标。第一个目标让提示词像代码一样可追溯、可回滚。也就是说任何一次提示词的变更都要有对应的提交记录、作者、时间、变更说明并且能随时切回任意历史版本。这不只是管理洁癖而是LLM应用出问题时候的第一排查手段——先搞清楚当前线上跑的是哪一版提示词。第二个目标让模型评测成为发布门禁。和代码单测一样评测必须自动化地跑在流水线里并且要有明确的通过/失败标准。分数不达标就不允许继续部署而不是靠人拍脑袋说“我觉得还行”。这里要强调一点LLM应用评测天然带有概率性所以评测门禁不能做得像代码测试那样一刀切我们要在接下来的章节里详细说清楚怎么设计。1.3 这条流水线适合什么样的团队这套方案对团队的成熟度还是有一点要求的。最基础的准入条件是你得先用Git管理好代码并且已经有Docker化部署的习惯。如果现在还靠手动登录服务器改代码重启那先把基础设施补上再来做这层。另外一个隐性的条件是团队里至少有一个人能看懂评测指标的含义。LLM应用评测不像代码覆盖率那么直观准确率下降一个点到底是提示词的问题、模型服务波动的问题、还是评测集本身该更新了需要有经验的人来做判断。如果团队完全没有这方面积累我建议先从“提示词版本管理”这一步开始不要一上来就自动化评测直接卡发布不然很容易因为评测门禁误杀太多最后大家干脆绕过流水线去部署那这套体系就废了。2. 整体流水线架构设计阶段拆解和边界划分2.1 六阶段流水线的整体设计我们的流水线最终沉淀成六个阶段每个阶段有明确的输入、输出和质量标准代码提交触发开发者将代码和提示词变更一起提交到Git仓库。静态检查与单元测试跑Python语法检查、代码Lint、普通单测。提示词格式校验检查Prompt文件是否符合规范、变量是否存在、是否需要的关键词都在。模型评测在评测集上自动执行新提示词计算各维度得分和基线对比。人工确认卡点评测通过的变更再交给产品负责人做一次小规模人工抽查。构建镜像与发布通过全部关卡后自动构建Docker镜像并部署到目标环境。这六个阶段里第2步和第3步可以并行第4步是整个流水线新增的核心逻辑也是花费计算资源最多的环节。人工确认卡点是我们特意保留的因为LLM应用再怎么自动化最终还是需要人对体验负责。关于这一点后面在讲阈值的部分还会展开。2.2 核心链路设计评测与发布的关系在设计这个流水线的过程中最关键的决策就是把评测环节放在“构建镜像”之前而不是之后。传统代码流水线里通常先构建产物再做集成测试最后发布。但对于LLM应用提示词不是代码编译出来的它是运行时直接传给模型的一组指令。如果先构建镜像再评测意味着每次提示词修改都要重打一次镜像浪费时间和存储更麻烦的是镜像打好了、评测却没通过这枚镜像就成了垃圾产物需要额外清理。所以我们把顺序调了过来提示词变更先在流水线里做评测评测通过之后再带着这一批通过验证的提示词去构建最终镜像。这样镜像一旦生成里面的提示词就是已经验证过的版本。发布动作本质上只做一件事告诉部署系统“用这枚镜像替换线上那一枚”。还有一个细节设计得很小心评测执行时用的代码分支是当前提交的代码但评测用的模型服务是固定的、独立的评测环境不能混用线上服务。原因很简单评测要保证结果可比性如果线上服务同时在更新评测时调用的模型版本不稳定分数波动就会干扰判断。我们单独部署了一个评测专用模型服务固定模型版本关闭随机采样参数尽可能保证评测过程的可控性。2.3 工具选型JenkinsDocker的优势和局限工具选型我们没搞什么花活最核心的就是Jenkins加Docker再加一套代码托管平台的Webhook。选Jenkins的原因比较现实团队对它的运维经验最足它对流水线的编排能力也够用而且各种插件生态成熟接到我们的企业微信通知、制品库都很方便。有人可能会问为什么不直接上GitLab CI或者GitHub Actions这个完全看团队现状。如果是新项目我一定会推荐GitHub Actions有现成的市场、YAML表达也清爽但我们是有大量存量流水线的团队迁移成本不小用Jenkins反而是更务实的选择。Docker在这里的作用有两层。第一层是作为流水线任务运行时的隔离容器评测脚本、Python依赖、命令行工具全部装在一个定制的Docker镜像里避免不同任务之间互相污染环境。第二层是交付物本身最终跑评测通过的应用被打成Docker镜像推送到私有镜像仓库等待部署。至于低代码平台像Dify这一类的知识库流水线能力我们也调研过它们的确能大幅降低提示词的管理成本有些平台自带了版本历史和调试对比对小型团队很有吸引力。但我们的场景里提示词需要和代码里的函数调用、业务逻辑深度耦合放在代码仓库里统一管理更合适。这一点没有绝对的好坏关键是团队自己形成统一机制。3. Prompt版本管理落地细节3.1 把提示词当成代码来管理目录结构与文件规范我们最终确定的方案是在代码仓库里单独划出一个prompt目录所有线上正在使用的提示词都以结构化文件的形式存放在这个目录下。目录结构大致是这样prompt/ ├── chat_qa/ │ ├── v1.0.0.yaml │ ├── v1.1.0.yaml │ └── current - v1.1.0.yaml ├── email_summary/ │ ├── v1.0.0.yaml │ └── current - v1.0.0.yaml └── system/ └── security_filter.yaml每一份提示词文件本身是一个YAML里面既保存了提示词正文也保存了元信息。下面是一份简化但真实可用的示例version: 1.1.0 name: chat_qa author: zhangsan created_at: 2024-11-18T10:20:3008:00 description: 通用问答场景主提示词增加了对生僻问题的兜底说明 variables: - user_question - knowledge_context model: provider: openai-compatible name: qwen-plus temperature: 0.3 max_tokens: 2048 prompt: | 你是产品支持专家请基于以下知识片段回答用户问题。 【知识片段】 {knowledge_context} 【用户问题】 {user_question} 回答要求 1. 如果知识片段中包含答案请直接给出结论并补充相关细节。 2. 如果知识片段中不包含答案请明确告知用户你无法确认并建议其联系人工客服。 3. 不要编造知识片段中不存在的信息。把提示词拆成这样的结构化文件带来的直接收益是版本号可以跟着Git标签走author和历史记录天然留在Git里variables字段可以供校验逻辑读取model字段能告诉评测环节该用哪个模型来跑这份提示词。细心的读者会发现我还在每个业务目录下放了一个current软链接或指针文件。这个设计的目的是让部署脚本和评测脚本永远只读current这一个固定入口。如果提示词升级到v1.2.0就新增一个文件然后把指针切换到新版本部署系统再打包时自然就拿到新版本了。这样做的好处是避免了到处硬编码版本号也让回滚变得极简——把指针指回v1.1.0那一行重新构建发布线上就在一秒内回到旧版本。3.2 版本管理流程从修改到上线要走的路一份提示词的正式修改在流程上和改代码完全对齐新建分支比如feature/chat_qa_prompt_optimization。新增一个YAML文件版本号按语义化规则递增写清楚description说明这次改了什么。更新current指针指向新版本。提交到远程仓库发起合并请求。流水线自动触发完成格式校验、单测、模型评测。产品负责人确认评测报告后合并到主分支。部署流程读取主分支的prompt目录把current指向的提示词打进镜像。这套流程跑顺之后我再也没有遇到过“这版提示词是谁改的”“这个效果是哪个版本产生的”这种问题。任何一次线上表现变化都可以直接通过Git日志定位到对应的提示词版本再配合评测报告查看当时的得分情况。3.3 提示词冲突与回滚的实操经验提示词文件也是文件也会遇到合并冲突。这一点很多刚开始做提示词版本管理的人会忽略觉得YAML文本嘛手动改一下就行。但提示词文件通常包含大段自然语言Git的三方合并算法在这种文本上经常给出语义错误的合并结果。两个人可能都在改同一段“回答要求”改动非常相近Git自动合并之后生成的文本很可能逻辑上是矛盾的。我们的经验是对prompt目录的合并请求必须走人工审查禁止直接自动合并。可以在流水线里加一个规则凡是涉及prompt/目录的合并请求必须至少有另一个团队成员点同意并且审查时重点看current指针指向的变化以及提示词正文的措辞是否有冲突。回滚的逻辑反而简单。线上万一出了问题不需要去改代码只需要在版本管理平台上把current指针回退到上一个版本号然后触发一条部署流水线。从发现问题到线上恢复大概只需要几分钟而且整个过程是确定性的回到哪个版本、恢复哪份提示词全都可查。4. 模型评测如何接入流水线4.1 评测集的建设先有数据再谈评测评测集是整个模型评测体系的基石。没有一份稳定、有代表性的评测集后面所有自动化评测都是空中楼阁。我们的评测集是一组JSON Lines格式的用例文件每一行是一条测试样本。下面是一份脱敏后的示例{id: case_0001, category: product_qa, input: 你们的会员可以同时在几个设备上登录, reference: 同一时间最多允许在三个设备上登录超过会被强制下线。, keywords: [三个, 设备, 下线], expected_json_schema: {type: object, properties: {answer: {type: string}, related_docs: {type: array}}}} {id: case_0002, category: after_sales, input: 我想退货但是订单已经过了七天还能退吗, reference: 超过七天退货时效非质量问题不支持无理由退货质量问题可联系客服特殊处理。, keywords: [七, 不支持, 质量], expected_json_schema: null}每条用例包含几个关键字段input用户问题这是评测时真正发给模型的内容。reference标准答案用于和模型回答做相似度比对或规则匹配。keywords关键词列表检查模型答案是否覆盖了关键信息。expected_json_schema如果该场景要求模型输出JSON则用这个字段做结构化校验。category用于分组统计方便我们看整个评测集总分之外每个业务场景的得分情况。评测集的来源我们主要靠三个渠道线上真实用户问题抽样、业务专家手工编写的高频场景、历史线上异常case的回放。尤其是线上用户问题抽样这个非常重要因为它直接决定了评测数据是否能代表真实流量分布。我们每两周会从日志里抽一批新的真实问题经过脱敏和标注后合入评测集保证评测集不会和线上真实场景脱节。4.2 自动评测的执行流程稳定、可控、不烧钱每一次流水线触发评测会走一套比较稳定的执行流程读取当前分支prompt目录下的所有current指向的提示词文件。根据提示词的model字段确定本次评测要调用哪个模型服务同时设置temperature为0、其他参数固定。将评测集按category分组多进程并发调用评测专用模型服务得到每一条用例的模型回答。对每个回答做多维度的自动评分关键词命中、序列化结构校验、相似度得分、幻觉规则碰触检查等。汇总得分输出一份JSON格式的评测报告。将报告上传到制品库并把关键指标推到企业微信群里通知相关同事。并发数需要控制我们不建议一次性把所有用例都打满并发到模型服务上。一方面评测服务本身有限流另一方面完全并发的请求如果遇到模型服务偶发故障容易把真实的质量问题误判成服务问题干扰排查。我们现在的策略是控制在10到20并发按catagory顺序执行整体时间在10到15分钟可接受。评测执行过程中有一个小细节非常关键temperature必须固定为0其他影响生成随机性的参数也都不要动。否则同一份提示词跑两次评测分数可能因为采样随机性有明显的波动门禁判断就没有意义了。另外评测专用模型服务要保证独立部署不能和线上共享服务否则线上流量高峰会影响评测响应延迟进而影响超时判断。4.3 分数与阈值的设置允许波动但拒绝断崖这是整套体系里最需要拿捏火候的部分。模型评测不像代码单测百分比通过率天然会存在波动如果阈值设置得太紧一次偶然的模型波动就会卡住所有发版设置得太松评测门禁又失去了意义。我们最终使用的策略是双指标门禁第一个指标是整体通过率。也就是评测集中有多少比例的用例被认为是“通过质量检查”的。我们给不同业务场景设了不同的基准线比如聊天问答场景的基线是95%邮箱总结场景是90%。凡是低于基准线的流水线直接判失败不允许合并和发布。第二个指标更关键是相对基线分数回归率。每次评测跑完都会得到一个分数我们会把这个分数和上一次通过评测的历史分数做对比如果下降超过1.5个百分点即使绝对分数还在线上也判失败。这个策略解决了“绝对值稳定但相对质量下滑”的问题。很多提示词的退化不是一两句话的割裂而是整体回答质量缓慢下滑绝对值不好察觉但相对回退很容易暴露出来。有读者可能会问如果这次新改动确实会让某些case变差但其他case变优总分持平怎么办这种情况我们会进一步看分类别的得分明细。所以评测报告一定要带category字段的分解不能在总分数上把问题完全掩盖。在模型评测门禁全部通过之后我们才会进入人工确认这一步。这一步不会跑完整的测试集只是由产品负责人在评测报告里挑几条新用例的实际输出过目一下确认语气、风格、边界情况没有过于奇怪的地方。之所以保留人工卡点是因为“模型回答质量”终究要落到产品体验上有些隐性问题评测集覆盖不到比如回答太过罗嗦、语气过于生硬、对用户情绪缺乏共情这些很难用关键词或结构化检查完全量化。5. 完整落地Jenkins流水线、Docker镜像与基础环境准备5.1 Jenkins流水线阶段配置解读理论部分说完了接下来是具体实现。我们的Jenkins流水线使用声明式语法描述在Jenkinsfile里。下面是一个去掉了敏感细节、但结构完整的示例pipeline { agent { docker { image registry.internal/llm-cicd-tool:1.4.2 args -v /var/run/docker.sock:/var/run/docker.sock } } environment { EVAL_SERVICE_URL http://llm-eval.internal:8001/v1/chat/completions ARTIFACTORY registry.internal IMAGE_REPO registry.internal/llm-app } stages { stage(Checkout) { steps { checkout scm } } stage(Lint and UT) { parallel { stage(Python Lint) { steps { sh make lint } } stage(Unit Tests) { steps { sh make test } } stage(Prompt Format Check) { steps { sh python scripts/validate_prompt.py --dir prompt/ } } } } stage(Model Eval) { steps { sh python scripts/run_eval.py \ --prompt-dir prompt/ \ --eval-set tests/evalset.jsonl \ --report-file report/eval_report.json \ --base-regression-threshold 1.5 } } stage(Manual Approval) { input { message 模型评测已通过请检查评测报告并确认是否继续发布。 ok 确认发布 } } stage(Build Image) { steps { sh VERSION$(git rev-parse --short HEAD) docker build -t ${IMAGE_REPO}:${VERSION} . docker push ${IMAGE_REPO}:${VERSION} } } } post { success { sh python scripts/notify.py --channel devops --msg 流水线通过镜像已推送 } failure { sh python scripts/notify.py --channel devops --msg 流水线失败请查看日志 } } }这个Jenkinsfile验证了整个设计的核心链路先跑静态检查和单测再跑Prompt格式校验接着跑模型评测人工确认最后构建和推送镜像。每一步失败都会直接终止流水线不会带着问题进入下一环。我这里特别说明一下agent stage里那个Docker镜像的配置。我们把整个评测过程中需要的Python依赖、命令行工具全部打包进了一个llm-cicd-tool镜像每次跑流水线都使用这个干净的环境。这个镜像要维护好Python包版本升级之后要单独重新构建不能允许流水线任务自己临场pip install否则不同任务之间环境不一致越后面越难排查问题。5.2 镜像构建与提示词注入一次验证、到处运行刚才流水线的最后一步用docker build构建应用镜像。这里有一个细节需要强调提示词文件怎么进入镜像。我们的Dockerfile里会有类似这样的指令FROM python:3.11-slim WORKDIR /app COPY . /app RUN python scripts/render_prompts.py --src prompt/ --dst app/generated_prompts.json CMD [python, app/main.py]render_prompts.py这个脚本会在构建镜像时读取prompt目录下所有current指针指向的YAML文件把它们渲染成一个generated_prompts.json随镜像一起固化。这样一来镜像里面包含的提示词内容在构建那一刻就已经确定运行时不会再从外部数据库或配置中心读取提示词保证了“这枚镜像跑到哪里行为都一样”。这个设计实际是我们从一次线上事故中总结出来的。早期我们把提示词放在一个配置中心里应用启动时动态拉取结果配置中心的一次误操作导致所有应用实例同时拉到了错误的提示词全站回复质量崩塌。把提示词固化进镜像之后配置中心这一层的故障面就彻底切掉了。5.3 上下游联动代码平台、制品库与部署系统流水线本身不是孤岛它需要和周围的系统打好配合。我们的实践里代码平台、制品库、部署系统三者之间的联动是这么处理的代码平台负责提供Webhook当main分支有新的合并事件时自动触发Jenkins任务。制品库用来存放评测报告和最终镜像。评测报告我们统一命名为eval_report_commit_sha.json方便后续回溯。部署系统监听制品库里的新镜像标签收到后按环境顺序执行滚动更新。这个联动过程中最容易出问题的是产品环境部署的镜像标签策略。我们使用commit_sha作为镜像标签好处是每个标签唯一且可以直接关联到代码提交排查问题时能做到“线上跑的镜像对应当前代码的哪个提交”一目了然。还有一个实用的小技巧在评测报告的报表里额外记录一条trace信息包含模型服务版本号、评测集文件哈希、评测脚本版本。这样如果后来发现某段评测集本身有问题需要修订就能快速通过文件哈希找到哪些历史报告可能受到影响。6. 运行了半年之后常见问题与排查技巧实录6.1 评测结果不稳定同一版本跑两次分数不同这是我们上线初期最头疼的问题没有之一。最初我们以为固定temperature为0就够了但后来发现还是存在波动。排查下来有两个原因。第一个原因是模型服务端的采样算法有自己的随机性虽然temperature为0理论上会走贪心解码但推理框架的浮点运算顺序、批处理行为都可能引入微小差异尤其是在并发请求比较高的场景下。这个问题的缓解办法是提升评测并发时对请求参数的稳定性要求同时把评测执行放在低峰期进行另外单个case的分数不重要整体统计量更重要只要池子够大微小的单点波动会被平均掉。第二个原因比较隐蔽是评测集被意外修改导致的分数偏移。有一次我们调整了评测集在原有JSON Lines中间插入了一批新用例但忘记更新评测集文件的哈希记录结果后续所有评测报告的“相对回归率”都是和历史版本错误的基线在比出现了大量误报。后来我们养成了一个习惯任何评测集变更必须单独提交并且评测报告必须记录评测集哈希。6.2 评测集漂移用着用着评测分数失真了评测集是静态的但线上用户问题一直在变化。运行一段时间后我们会发现评测集里很多case已经不能在真实流量里反映问题了用户早就不这么问了或者问法变了、业务规则变了导致标准答案都需要更新。评测集漂移的危险性在于它会让流水线出现“假绿”现象评测分数一直很高但线上用户满意度却在下降。我们的应对方案是建立评测集周期性修订机制每两周抽一批线上真实问题由运营和产品一起标注增量更新评测集同时用脚本统计评测集里各category的用例数量分布确保和线上流量分布大致一致。需要注意的是评测集修订不能频繁操作否则不同时期评测结果之间没有可比性也会给发布门禁的判断带来麻烦。我们是固定每两周修订一次每次修订之后更新版本号并在评测报告里记录新的评测集版本跟历史报告的对比专门标注“跨评测集版本仅供参考”。6.3 并发资源与评测成本控制模型评测是有真实计算成本的尤其在评测集规模上来之后每一次完整评测可能消耗可观的token费用。我们曾经统计过一次评测集大约800条用例跑一遍多机并发大概要消耗几十万token按照主流大模型API的价格单次完整评测的成本不算低。如果每个人每次合并代码都全量跑一次评测一个月下来也是一笔不小的开支。为了更好地控制成本我们做了两件事。第一分支内的个人调试不允许触发完整评测只有发起合并请求时才会触发全量评测第二全量评测的基础上增加了一个“冒烟评测”环节从评测集里按category各取5条最典型的用例跑一个极小的评估子集用来做快速验证。如果冒烟评测都不通过直接终止流水线不浪费后面的资源。这个策略下来整个流水线的平均运行时间没有明显上涨但模型调用成本下降了大约60%而且开发体验也好了很多因为大部分明显有问题的改动在冒烟评测阶段就被拦下来了不需要等十几分钟的全量评测结果。6.4 人工确认卡点失灵与团队流程的磨合最后一个坑来自流程本身。人工确认阶段一开始经常失灵原因不是工具不好用而是团队成员不习惯在流水线里点确认按钮总在IM工具里口头说一句“可以了”就结束了流水线就一直卡在等待状态。后来我们做了一个调整人工确认卡点只在“合并到主分支并触发发布”的那条流水线里保留开发分支的合成验证不设人工卡点。同时我们给流水线配置了超时提醒超过30分钟没有点确认会在IM群里提醒对应该版本的产品负责人。这样既保证了关键发布有人的判断又不会因为团队习惯问题卡住整个流程。7. 复盘之后的经验与进一步扩展7.1 这套体系真正解决的是什么回看这次改造我们在CI/CD里引入模型评测和Prompt版本管理表面上增加的是几个流水线阶段和一堆评测脚本但更深层的变化是整个团队对“发布”这件事的心态。以前发一个LLM功能总有种赌运气的成分在里面。现在每次发布前我们都有清晰的评测数据、可回滚的提示词版本、和一次人工确认的兜底。上线出了任何问题第一反应不是慌而是打开评测报告看数据、打开Git日志找提示词变更记录、打开镜像清单看当前版本。这种确定性对于一个面向生产环境的LLM应用来说价值怎么强调都不为过。7.2 如果你要复刻这套方案我给出几个优先级建议复刻不必一步到位。我的建议是按照下面这个顺序推进先把提示词版本管理做起来这是基础中的基础。哪怕没有自动评测只在Git里用目录加YAML的方式管理提示词再配合current指针就已经能解决很多混乱。然后把评测集建设起来。这一项最困难的是标注环节需要团队里最懂业务的人参与。评测集质量决定自动化评测的上限绝不能贪快。最后才接入自动门禁。在提示词和评测集都有了稳定基础之后再让评测分数去卡合并和发布。前期评测结果只告警、不阻断等大家信任评测指标了再调成硬性门禁。这个循序渐进的路子能最大程度避免团队对自动化评测产生抵触。7.3 关于后续演进这套体系跑顺之后新的扩展方向也有很多比如多轮对话自动评测、多模型横向对比评测、基于线上反馈的在线评测采样等。我们在这些方向上的探索还在进行中目前最感兴趣的是把线上用户反馈信号接入评测体系让评测集不仅能通过人工修订来更新还能自动从线上数据里发现劣质回答从而让流水线的质量判断越来越贴近真实体验。这个方向等有初步结论了我再单独开一篇来写。