Benchmark-Driven Development: Beyond TDD for AI Systems
Benchmark-Driven Development evolved from TDD to handle AI's exponential pace: benchmarks now auto-generate production configs with complete audit trails.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
我在早期 2025 发现了基准驱动开发，在构建我已经工作两年的翻译系统以及几个文档渲染引擎时. 翻译系统成为了这个方法论结晶的实验室. 我自 2023 年以来一直在使用 AI 系统，随着进步，我意识到 AI 模型发展得如此之快，以至于传统方法跟不上. 那时函数调用刚刚作为市场创新出现，自治代理真正成为事物之前. 我正在评估不同的语言对，构建复杂的管道，我意识到我需要一种方法让项目本身能够测量到底层能力。问题不只是测试某事是否有效——而是发现当环境每隔几周就会变化时，什么最有效.从测试到仿真#
我一直理解测试的价值，尤其是在为政府构建企业系统时，严格的要求和全额资助的合同需要证明. 但当 TDD 被强加到我参与的项目中时，我见证了一件重要的事：框架只有在团队真正接受它们时才有效. 强制完全采用往往没有意义. 我学到的最好的方法往往是混合的——只采用必要的部分. 我倾向于测试核心功能，而不是全面的单元覆盖. 为什么要维护成千上万的零散测试，而一段少于 1000 行的仿真脚本就能验证整个用户流程? 对于一个政治拉票应用，我构建了一个仿真，创建了模拟团队，模拟拉票者加入和离开，生成了真实的工作负载，并在大规模下对系统进行压力测试. 这揭示了一切：UI 行为、图表渲染、极限下的数据完整性. 一段脚本给了我比零散单元测试更大的信心. 在我 25 年的编码生涯中，我在过去 10-12 年里深刻意识到优秀评分卡的价值. 我在 GPT 出现之前就已经使用评分卡，过去三年用 AI 重新审视它们让我感到非常有趣. 那些仿真经验奠定了后来成为基准驱动开发的基础.一切改变的那一刻#
真正的发现发生在我意识到一件改变一切的事时：基准测试可以直接输出一个直接投入生产的配置. 它已经被测试，直接在那里，准备好与提示和其他一切一起插入. 那是关键洞察. 这源于面对翻译系统的根本问题. AI供应商声称支持数十种语言，但质量和程度如何? 这些信息记录不充分，我通过经验了解到我无法完全信任供应商的声明——我不应该. 于是我创建了一个存在于项目中的基准评估循环. 我可以给它一个服务和模型，它会评估它实际上擅长哪些语言——不是供应商声称的，而是经验数据所显示的. 该过程是幂等的：相同输入，相同输出，持续缓存以获得快速结果. 在更改提示时，我们进行A/B测试以发现最佳提示. 持续失败的模型被列入黑名单或在某些语言对中降级，使基准测试更具生产力. 使用AI构建AI集成被证明极其强大. 通过函数调用和早期将演变为代理的框架，我可以使用AI构建基准测试，配备评分卡和评估. 我发现的模型和语言能力与供应商的声明有显著差异. 我需要更接近底层，更接近实际证据.graph TB
Problem[供应商声明]
Loop[评估循环]
Cache[幂等缓存]
ABTest[A/B 测试提示]
Demote[黑名单失败]
Discovery[推送到生产]
Problem -->|创建| Loop
Loop -->|启用| Cache
Cache -->|快速| ABTest
Cache -->|跟踪| Demote
ABTest -->|突破| Discovery
Demote -->|优化| Discovery
style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5
style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2pxCopy source基准驱动开发到底是什么#
基准驱动开发超越验证，成为一种生成式过程。. 测试验证正确性，基准测试比较多维度的性能。. 更重要的是，在 BDD 中，基准测试发出驱动生产系统的配置。. 我的真正意思是：不只是检查代码是否工作，系统会持续评估哪种方法最有效，然后自动配置自己使用最佳方法。. 采用有效的方法，构建真正服务于你上下文的东西。. 测试驱动开发：graph TB
Test[编写测试]
Code[编写代码]
Pass[测试通过]
Test --> Code
Code --> Pass
style Pass fill:transparent,stroke:#10B981,stroke-width:2pxCopy sourcegraph TB
Bench[运行基准测试]
Compare[比较结果]
Config[生成配置]
Deploy[生产]
Bench --> Compare
Compare --> Config
Config --> Deploy
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
style Config fill:transparent,stroke:#3B82F6,stroke-width:2pxCopy source在翻译系统内部#
在翻译系统中，我没有选择单一的AI模型并盼望它在所有语言对上表现良好，而是创建了一个全面的基准测试系统，评估多种模型在三个关键指标上的表现：- 质量 - 翻译准确性和文化细微差别的保留
- 速度 - 各种文本长度的响应时间
- 成本 - 每令牌或每请求的定价
graph TB
Input[测试语料库]
Models[AI 模型]
Bench[基准套件]
Metrics[分数：Q/S/C]
Winner[最佳配置]
ProdConfig[生产]
Input --> Bench
Models --> Bench
Bench -->|质量| Metrics
Bench -->|速度| Metrics
Bench -->|成本| Metrics
Metrics --> Winner
Winner -->|自动生成| ProdConfig
style Winner fill:transparent,stroke:#3B82F6,stroke-width:2px
style ProdConfig fill:transparent,stroke:#10B981,stroke-width:2pxCopy source评估评估者#
一个关键创新是实施我所称的 "先评估评估者 " 由于对西班牙语有一定了解，我能够轻松发现更简单评估指标所忽略的文化细微差别的损失. 解决方案是使用更昂贵、更高质量的模型专门评估得分卡本身，确保基准测试衡量真正重要的内容. 拥有评估循环并使用更智能的模型来评估评估者成为一种强大的技术. 为某事获得一个优秀的评估者是项目中的一次惊人创造——一次壮举、一项挑战和一次成就，全部一次完成. 这一元评估过程迭代地完善了得分卡，我能够创建一个稳健的评估框架，实际上可以被信任来做出自动化决策. 在我的经验中，这就是大多数团队失败的地方：他们在未先评估评估者的情况下就信任他们.graph TB
Basic[基本指标]
Human[人工审核]
Premium[高级模型]
Refined[完善的得分卡]
Trust[可信的评估者]
Basic -->|发现的差距| Human
Human -->|洞察| Premium
Premium -->|评估| Basic
Premium --> Refined
Refined -->|迭代| Trust
style Human fill:transparent,stroke:#333333,stroke-width:2px
style Premium fill:transparent,stroke:#3B82F6,stroke-width:2px
style Trust fill:transparent,stroke:#10B981,stroke-width:2pxCopy source当基准成为配置时#
一旦我意识到基准可以生成生产配置，一切都明朗了. 基准与代码并存，并能聚焦于管道或引擎中任何层级的组件. 它可以创建模拟组件，测试变体，并在分数提升时直接将配置发射到源代码中. 这种连接变得至关重要。AI 发展如此迅速，项目中保持基准测试是值得的. 当新模型以更好的经济性或速度发布时，得分卡保持不变，基准测试继续进行. 质量提升令人难以置信. 获胜组合——模型选择、提示工程、参数调优——已通过完整审计轨迹测试，直接发射到配置并直接投入生产. 借助翻译系统，这让我对模型在语言翻译方面的能力有了令人难以置信的认识. 获胜者自动成为生产配置，始终使用质量、价格和文化细微差别保留的最佳平衡. 这创建了一个审计轨迹，清晰展示每个技术决策的原因，并以实证数据为支持. 当有人问“为什么 Model X 用于西班牙语到法语，但 Model Y 用于中文到英语？” 答案存在于基准结果中.通过数据进行提示工程#
系统演进为不仅基准模型选择，还基准提示工程本身. 我能够构建基准测试，然后让不同部分甚至在 AI 提示上工作，系统地进行 A/B 测试不同提示. 基于既定指标，明显的赢家浮现. 这消除了提示工程中的猜测，用数据驱动的决策取代直觉.持续发现的经济学#
这种方法具有显著的成本节约方面. 评分卡旨在以良好的速度推广最佳质量和文化细微差别，同时以最佳成本实现. 除此之外，我通过不必手动评估任何东西而节省的成本——只需让一切在新模型或模型版本发布时自行展开. 当模型声称在某些语言对上表现非常好时，直接将其添加到配置并观察基准运行非常容易. 我知道无论什么赢得胜利都会被实施到生产中，并有硬性证据支持. 对我而言，基准驱动的开发就像在项目的一个特殊部分拥有一支小型代理团队，进行研究、发现和评估. 观看起来相当有趣. 这就像在项目中有一个小型研发工作室在工作. 翻译系统是我最喜欢的系统之一——我花了两年多的时间断断续续地构建它，终于达到了可以用它创建服务的阶段，尽管目前我私下使用它.良性循环#
基准驱动开发创造了一个良性循环：- 通过测量实现清晰：抽象质量变为具体指标
- 通过比较学习：每个基准都能教会我们关于问题空间的新知识
- 通过数据获得信心：决策得到本地可验证证据的支持
- 通过自动化实现演进：系统持续自我改进
graph TB
Define[定义指标]
Implement[构建基准]
Cache[缓存结果]
Evaluate[运行 A/B 测试]
Select[选择赢家]
Generate[发布配置]
Deploy[部署到生产环境]
Monitor[监控性能]
Define --> Implement
Implement --> Cache
Cache --> Evaluate
Evaluate --> Select
Select --> Generate
Generate --> Deploy
Deploy --> Monitor
Monitor -.->|持续| Evaluate
style Cache fill:transparent,stroke:#333333,stroke-width:2px
style Select fill:transparent,stroke:#3B82F6,stroke-width:2px
style Deploy fill:transparent,stroke:#10B981,stroke-width:2pxCopy source实践中出现的内容#
通过实施基准驱动开发，这些模式被认为是关键：- 清晰的指标被证明至关重要：当性能、成本和质量与正确性一起跟踪时，成功在多个维度上变得可衡量.
- 全面的基准揭示隐藏问题：在完整范围的预期输入和边缘情况进行测试，暴露了部分测试遗漏的问题.
- 缓存实现快速迭代：幂等性和积极的缓存使数千种基准变体在不重复计算的情况下可行.
- 自动化配置降低错误：当基准结果直接生成生产配置时，手工转录错误消失.
- 审计追踪提供清晰：每个配置决策都可追溯到基准数据，使调试和问责变得简单.
此方法的优势所在#
我对软件开发的哲学是，方法应始终根据上下文和必要性演进. 基准驱动开发并不适用于许多项目，尤其是那些没有实验性质或未直接与快速演进的 AI 系统集成的项目. 对我而言，空间中演进速度的张力与 AI 能力范围——从温度为零的完全确定性输出到更高温度的创造性输出——共同促成了必要性. 通过翻译系统，基准驱动方法是有意义的，因为我可以用硬证据和纸质记录来衡量质量、速度和成本. BDD 在以下场景中被证明最有效：- 多种有效实现选项（不同的 AI 模型、算法或方法）
- 快速演进的技术环境
- 多维优化需求（质量、速度、成本）
- 需要可解释的技术决策
- 复杂的配置空间
- 需要持续适应新能力的系统