Разработка на основе бенчмарков: за пределами TDD для систем ИИ
Как Разработка на основе бенчмарков эволюционировала из TDD, чтобы справляться с экспоненциальным темпом ИИ через генерацию конфигураций на основе данных и эмпирическую оптимизацию.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
Я обнаружил Разработку на основе бенчмарков в раннем 2025, пока строил систему перевода, над которой работал уже два года, и несколько движков рендеринга документов. Система перевода стала лабораторией, где эта методология застывала. Я работал с системами ИИ с примерно 2023, и по мере прогресса я понял, что модели ИИ развивались так быстро, что традиционные подходы не успевали.В это время вызов функции только что появился как инновация на рынке, до того как автономные агенты стали реальностью. Я оценивал разные пары языков, строил сложные пайплайны, и понял, что проекту нужен способ измерять возможности до самой сути. Проблема заключалась не в том, чтобы проверить, работает ли что-то – а в том, чтобы выяснить, что работает лучше, когда ландшафт меняется каждые несколько недель.От тестов к симуляциям#
Я всегда понимал ценность тестирования, особенно при разработке корпоративных систем для правительства, где строгие требования и полностью финансируемые контракты требовали доказательств. Но когда TDD был навязан проектам, над которыми я работал, я увидел важную вещь: фреймворки работают только тогда, когда команды действительно их принимают. Принуждение к полному принятию редко имеет смысл.То, что я понял, — это то, что лучший подход часто является гибридным: принимать только столько, сколько нужно. Я склонялся к тестированию основных возможностей, а не к всеобъемлющему покрытию юнит‑тестами. Зачем поддерживать тысячи разбросанных тестов, если один скрипт симуляции длиной менее 1000 строк может проверить весь пользовательский поток?Для приложения для политической canvassing я создал симуляцию, которая создавала фиктивные команды, симулировала присоединение и уход приверженцев, генерировала реалистичные рабочие нагрузки и испытывала систему в масштабах. Это показало всё: поведение UI, отрисовку графиков, целостность данных на предельных нагрузках. Один скрипт дал мне больше уверенности, чем когда-либо могли дать разбросанные юнит‑тесты.В течение 25 лет программирования я в последние 10-12 был глубоко осведомлен о том, насколько ценен хороший scorecard. Я использовал scorecards задолго до появления GPT, и пересмотр их с помощью ИИ за последние три года был увлекателен. Те симуляционные эксперименты заложили основу того, что стало Benchmark-Driven Development.Момент, когда всё изменилось#
Настоящее открытие произошло, когда я понял, что изменило всё: bencharking просто мог бы выдавать конфигурацию, которая сразу попадает в продакшн. Это уже протестировано, прямо там, готово подключиться к подсказкам и всему остальному. Это был большой инсайт.Это возникло из столкновения с фундаментальной проблемой в системе перевода. Поставщики ИИ заявляли о поддержке десятков языков, но насколько и в какой степени? Эта информация была плохо задокументирована, и я понял через опыт, что я не могу полностью доверять заявлениям поставщика—и не должен.Итак, я создал цикл оценки benchmark, который живет в проекте. Я мог предоставить ему сервис и модель, и он оценивал, на каких языках он действительно хорош — а не то, что заявил поставщик, а то, что показали эмпирические данные.Процесс идемпотентен: одинаковый ввод, одинаковый вывод, постоянно кэшируется для быстрых результатов. При смене подсказок мы проводим A/B тестирование, чтобы найти лучшие. Модели, которые постоянно не справлялись, были отложены в черный список или понижены по рейтингу для определенных пар языков, что делало benchmarking более продуктивным.Использование ИИ для построения AI интеграций оказалось невероятно мощным. С помощью вызовов функций и ранних фреймворков, которые эволюционировали в агенты, я мог строить benchmarks с AI, включая scorecards и оценки. То, что я обнаружил о моделях и языковых возможностях, значительно отличалось от заявлений поставщика. Мне нужно было быть ближе к металлу, ближе к реальному доказательству.graph TB
Problem[Утверждения поставщика]
Loop[Цикл оценки]
Cache[Идемпотентный кэш]
ABTest[А/В тестовые подсказки]
Demote[Провалы черного списка]
Discovery[Вывести в продакшн]
BDD[Фреймворк BDD]
Problem -->|Создать| Loop
Loop -->|Включить| Cache
Cache -->|Быстрый| ABTest
Cache -->|Отслеживать| Demote
ABTest -->|Прорыв| Discovery
Demote -->|Оптимизировать| Discovery
Discovery --> BDD
style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5
style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2px
style BDD fill:transparent,stroke:#10B981,stroke-width:2pxCopy sourceЧто на самом деле представляет собой Benchmark-Driven Development#
Benchmark-Driven Development выходит за рамки валидации, становясь генеративным процессом. Где тесты проверяют правильность, бенчмарки сравнивают производительность по многим измерениям. Более важно, в BDD бенчмарки выдают конфигурацию, которая управляет производственной системой.То, о чём я действительно говорю: вместо того чтобы просто проверять, работает ли код, система постоянно оценивает, какой подход лучше всего, а затем автоматически конфигурирует себя под этот оптимальный подход. Возьми то, что работает, и создай что-то, что действительно служит твоему контексту.graph LR
subgraph "Разработка, управляемая тестами"
Test[Напиши тест]
Code[Напиши код]
Pass[Тест пройден]
Test --> Code
Code --> Pass
end
subgraph "Разработка, управляемая бенчмарками"
Bench[Запустить проверки]
Compare[Сравнить результаты]
Config[Создать конфигурацию]
Deploy[Производство]
Bench --> Compare
Compare --> Config
Config --> Deploy
end
style Pass fill:transparent,stroke:#10B981,stroke-width:2px
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
style Config fill:transparent,stroke:#3B82F6,stroke-width:2pxCopy sourceВнутри системы перевода#
В системе перевода, вместо выбора одной модели ИИ и надежды, что она будет работать хорошо для всех языковых пар, я создал всестороннюю систему тестирования, которая оценивала несколько моделей по трем ключевым метрикам:- Качество - точность перевода и сохранение культурных нюансов
- Скорость - время отклика для разных длин текста
- Стоимость - стоимость за токен или за запрос
graph TB
Input[Тестовый корпус]
Models[Модели ИИ]
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Когда бенчмарки становятся конфигурацией#
Когда я понял, что бенчмарки могут генерировать производственные конфигурации, всё соединилось. Бенчмарк живёт рядом с кодом и может сосредоточиться на любом слое конвейера или компоненте в движке. Он может создавать имитационные компоненты, тестировать варианты, и когда показатели улучшаются, выводить конфигурацию напрямую в исходный код.Эта связь стала необходимой. ИИ развивается так быстро, что выгодно иметь бенчмаркинг в проекте. Когда новая модель выходит с лучшей экономикой или скоростью, карточки оценок остаются прежними, а бенчмаркинг продолжается. Улучшения качества невероятны.Победные комбинации—выбор модели, инженерия запросов, настройка параметров—уже протестированы с полными аудитовыми цепочками, выводятся в конфигурацию и сразу попадают в производство. С помощью системы перевода мне стало невероятно ясно о возможностях модели для перевода языков. Победители автоматически становились производственной конфигурацией, всегда используя наилучший баланс качества, цены и сохранения культурных нюансов.Это создало аудит‑трейл, показывающий точную причину каждого технического решения, подкреплённую эмпирическими данными. Когда кто‑то спрашивает «Почему модель X для испанского- французского, но модель 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 доказала свою эффективность в сценариях с:- Множество допустимых вариантов реализации (различные модели ИИ, алгоритмы или подходы)
- Быстро развивающиеся технологические ландшафты
- Многомерные требования к оптимизации (качество, скорость, стоимость)
- Необходимость объяснимых технических решений
- Сложные конфигурационные пространства
- Системы, требующие непрерывной адаптации к новым возможностям