用 MySQL 构建 Prompt 发布门禁异步评测、租约与原子生效Prompt 改一个词就直接影响下一次生产调用是许多 LLM 应用的薄弱环节。一个针对特殊案例的修复也可能悄悄降低常规问题的表现。原文的解决方案是发布门禁候选 Prompt 先暂存在所有绑定数据集上完成评测只有全部达标才替换线上配置。编排依靠 MySQL 状态表与后台 Worker 完成。1. 门禁检查什么原文为了简化只考虑输出 yes/no 的二分类任务。每个数据集有独立准确率门槛例如常规集和困难集分别设门槛数字是业务配置不是通用标准。提交变更后返回跟踪 ID。评测异步运行最终只有两类结果所有门槛通过则生效否则保持线上版本不变。真实任务还可能需要检查精确率、召回率、延迟、成本和失败比例。2. 数据表表达状态和关系表负责保存prompt当前线上配置与版本dataset数据集登记及来源prompt_datasetPrompt 与数据集映射及门槛prompt_update一次候选变更与状态prompt_run候选在某个数据集上的一次评测prompt_run_item单条样本的期望、实际输出与判定给(run_id, item_id)加唯一约束可以防止重复物化样本。新增建议是给本次评测固定数据快照、门槛、模型和生产调用链路版本避免评测过程中配置变化造成结果不可解释。3. 四类 Worker 如何协作Materialize 分页读取并固化评测样本Execute 调用与生产一致的执行路径保存匹配、不匹配或错误Finalize 等待样本全部终结计算指标Reconcile 比较全部数据集门槛决定候选是否生效。Worker 不必彼此发消息可以查询相应状态。状态迁移使用条件更新例如只允许PENDING更新为REJECTED并检查影响行数避免已经终结的候选再次被处理。4. SKIP LOCKED 配合短事务认领两个 Worker 先查询再处理可能拿到同一条任务。FOR UPDATE让认领事务持有行锁SKIP LOCKED跳过其他事务已锁定的行适合多个消费者处理队列式表。MySQL 8.4 锁定读文档下面是参数化 SQL 设计片段:参数需要通过数据库驱动绑定。IN列表应由驱动生成占位符不能把用户输入直接拼进 SQL。STARTTRANSACTION;SELECTidFROMprompt_run_itemWHERErun_id:run_idANDverdictIN(PENDING,ERROR)ANDattempt:max_attemptsAND(lease_untilISNULLORlease_untilNOW(6))ORDERBYidLIMIT:batch_sizeFORUPDATESKIP LOCKED;-- 仅更新本事务刚选中的 IDtoken 为本次认领的新随机值UPDATEprompt_run_itemSETlease_token:token,lease_untilDATE_ADD(NOW(6),INTERVAL3MINUTE),attemptattempt1WHEREidIN(:claimed_ids);COMMIT;事务提交后再调用 LLM。长网络调用期间不持有行锁可以减少连接池和事务负担。原文把ORDER BY id描述成 FIFO需要收紧跳过锁定行和并发执行会改变完成顺序因此它不是严格 FIFO。还要为查询建立合适索引控制批量大小并检查扫描和锁竞争。5. 租约解决恢复令牌防止旧结果覆盖Worker 崩溃后其他 Worker 可以在租约过期后重新认领。每次认领使用新lease_token比只比较固定 Worker 名称更能区分前后两次执行。UPDATEprompt_run_itemSETverdict:verdict,actual_decision:decision,lease_tokenNULL,lease_untilNULLWHEREid:item_idANDlease_token:tokenANDlease_untilNOW(6);回写影响行数为零说明所有权已失效应丢弃结果。耗时任务需要续租或足够的租期并为重试安排退避。这里提供的是至少一次处理思路不能保证 LLM 只调用一次。租约过期前后可能出现重复请求和重复费用外部服务支持幂等键时可以利用它否则要记录重复执行并限制重试。6. 最终生效还要处理并发提交候选通过全部门槛后线上配置更新与候选状态更新应在同一事务完成。还要检查候选是否仍为当前有效提交以及线上基础版本是否符合预期防止较早的慢评测覆盖较新的配置。若采用“最新提交优先”被替代候选应进入取消状态其已在途任务的结果不能触发生效。Finalize 还要确认物化结束避免样本尚未读全就提前计算指标。错误耗尽重试、数据集为空、分母为零和取消中的运行都需要明确终态。阈值比较应使用未过早四舍五入的原始值。MySQL 能支撑一定规模的异步门禁但轮询、索引、历史表增长和清理都有成本。当工作流涉及大量跨系统补偿、复杂定时和高吞吐事件时应重新评估专门队列或工作流平台。选择依据是负载与运维能力而不是组件数量越少越好。