Разработка на основе бенчмарков: за пределами TDD для систем ИИ

Я обнаружил Разработку на основе бенчмарков в раннем 2025, пока строил систему перевода, над которой работал уже два года, и несколько движков рендеринга документов. Система перевода стала лабораторией, где эта методология застывала. Я работал с системами ИИ с примерно 2023, и по мере прогресса я понял, что модели ИИ развивались так быстро, что традиционные подходы не успевали. В это время вызов функции только что появился как инновация на рынке, до того как автономные агенты стали реальностью. Я оценивал разные пары языков, строил сложные пайплайны, и понял, что проекту нужен способ измерять возможности до самой сути. Проблема заключалась не в том, чтобы проверить, работает ли что-то – а в том, чтобы выяснить, что работает лучше, когда ландшафт меняется каждые несколько недель. ## От тестов к симуляциям Я всегда понимал ценность тестирования, особенно при разработке корпоративных систем для правительства, где строгие требования и полностью финансируемые контракты требовали доказательств. Но когда TDD был навязан проектам, над которыми я работал, я увидел важную вещь: фреймворки работают только тогда, когда команды действительно их принимают. Принуждение к полному принятию редко имеет смысл. То, что я понял, — это то, что лучший подход часто является гибридным: принимать только столько, сколько нужно. Я склонялся к тестированию основных возможностей, а не к всеобъемлющему покрытию юнит‑тестами. Зачем поддерживать тысячи разбросанных тестов, если один скрипт симуляции длиной менее 1000 строк может проверить весь пользовательский поток? Для приложения для политической canvassing я создал симуляцию, которая создавала фиктивные команды, симулировала присоединение и уход приверженцев, генерировала реалистичные рабочие нагрузки и испытывала систему в масштабах. Это показало всё: поведение UI, отрисовку графиков, целостность данных на предельных нагрузках. Один скрипт дал мне больше уверенности, чем когда-либо могли дать разбросанные юнит‑тесты. В течение 25 лет программирования я в последние 10-12 был глубоко осведомлен о том, насколько ценен хороший scorecard. Я использовал scorecards задолго до появления GPT, и пересмотр их с помощью ИИ за последние три года был увлекателен. Те симуляционные эксперименты заложили основу того, что стало Benchmark-Driven Development. ## Момент, когда всё изменилось Настоящее открытие произошло, когда я понял, что изменило всё: **bencharking просто мог бы выдавать конфигурацию, которая сразу попадает в продакшн**. Это уже протестировано, прямо там, готово подключиться к подсказкам и всему остальному. Это был большой инсайт. Это возникло из столкновения с фундаментальной проблемой в системе перевода. Поставщики ИИ заявляли о поддержке десятков языков, но насколько и в какой степени? Эта информация была плохо задокументирована, и я понял через опыт, что я не могу полностью доверять заявлениям поставщика—и не должен. Итак, я создал цикл оценки benchmark, который живет в проекте. Я мог предоставить ему сервис и модель, и он оценивал, на каких языках он действительно хорош — а не то, что заявил поставщик, а то, что показали эмпирические данные. Процесс идемпотентен: одинаковый ввод, одинаковый вывод, постоянно кэшируется для быстрых результатов. При смене подсказок мы проводим A/B тестирование, чтобы найти лучшие. Модели, которые постоянно не справлялись, были отложены в черный список или понижены по рейтингу для определенных пар языков, что делало benchmarking более продуктивным. Использование ИИ для построения AI интеграций оказалось невероятно мощным. С помощью вызовов функций и ранних фреймворков, которые эволюционировали в агенты, я мог строить benchmarks с AI, включая scorecards и оценки. То, что я обнаружил о моделях и языковых возможностях, значительно отличалось от заявлений поставщика. Мне нужно было быть ближе к металлу, ближе к реальному доказательству. ```mermaid 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:2px ``` Это не было теоретическим. Оно возникло из практической боли невозможности доверять утверждениям поставщика и постоянного обновления производственных систем при появлении новых моделей. Бенчмарки эволюционировали от инструментов измерения до генераторов конфигураций. ## Что на самом деле представляет собой Benchmark-Driven Development Benchmark-Driven Development выходит за рамки валидации, становясь генеративным процессом. Где тесты проверяют правильность, бенчмарки сравнивают производительность по многим измерениям. Более важно, в BDD бенчмарки выдают конфигурацию, которая управляет производственной системой. То, о чём я действительно говорю: вместо того чтобы просто проверять, работает ли код, система постоянно оценивает, какой подход лучше всего, а затем автоматически конфигурирует себя под этот оптимальный подход. Возьми то, что работает, и создай что-то, что действительно служит твоему контексту. ```mermaid 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:2px ``` ## Внутри системы перевода В системе перевода, вместо выбора одной модели ИИ и надежды, что она будет работать хорошо для всех языковых пар, я создал всестороннюю систему тестирования, которая оценивала несколько моделей по трем ключевым метрикам: 1. **Качество** - точность перевода и сохранение культурных нюансов 2. **Скорость** - время отклика для разных длин текста 3. **Стоимость** - стоимость за токен или за запрос Бенчмарки говорили сами за себя и выявили удивительные выводы, которые кардинально изменили моё представление о возможностях ИИ в области языков. Момент ясности пришёл от проекта перевода китайского рукописного текста для клиента. Её жена написала китайский рукопись более 175 страниц, и я помогал её оцифровывать и переводить. Я захватил страницы, используя функцию наложения Google Translate, затем разбил контент на блоки по 10‑15 страниц для систематической оценки. Используя Claude Opus — самую продвинутую модель, доступную в то время, я провёл всесторонние оценки каждого блока. ИИ не просто переводил; он анализировал качество машинного перевода Google Translate. Результаты были поразительными: потеря 30% в культурных нюансах, с конкретными примерами, точно указывающими, где смысл разъехался. ИИ объяснял: «Эта фраза означает X на английском согласно машинному переводу, но китайский на самом деле передаёт Y — культурный контекст Z, и это недоразумение фундаментально меняет смысл.» Это не были тонкие различия. Это были значительные потери в задуманном автором сообщении. То, что сделало это открытие более тревожным, — это тестирование моделей, утверждающих поддержку 50-80+ языков. Имея некоторое знание испанского, я смог заметить аналогичные потери культурных нюансов, которые простые метрики полностью пропустили бы. Это поставило под вопрос, что значит «поддерживаемый язык», когда есть 30% потеря культурных нюансов по сравнению с более дорогими альтернативами. Пара была глубоко тронута подробным отчётом — они не ожидали такой точности в определении, где перевод не прошёл и почему. Для меня это был кристаллизующий момент: мне нужны были бенчмарки, измеряющие то, что действительно важно, а не только то, что заявляют поставщики. Этот опыт напрямую вдохновил подход, основанный на бенчмарках, который стал центральным в том, как я строю системы. ```mermaid 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:2px ``` ## Оценка оценщика Один важный нововведение заключалось в том, что я внедрил то, что называю "сначала оценивать оценщика". Будучи достаточно знаком с испанским, я смог легко заметить потери культурных нюансов, которые упускали простые метрики оценки.. Решением было использовать более дорогие, более качественные модели специально для оценки самой таблицы оценок, чтобы бенчмарки измеряли то, что действительно важно.. Наличие циклов оценки и использование более интеллектуальных моделей для оценки оценщиков стало мощной техникой.. Получить хороший оценщик для чего-то — это удивительное достижение в проекте — подвиг, вызов и успех одновременно.. Этот процесс мета-оценки итеративно уточнял таблицу оценок, и я смог создать надёжную систему оценки, которой действительно можно доверять для автоматизированного принятия решений.. По моему опыту, именно здесь большинство команд терпят неудачу: они доверяют своим оценщикам, не оценивая их сначала.. ```mermaid 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:2px ``` ## Когда бенчмарки становятся конфигурацией Когда я понял, что бенчмарки могут генерировать производственные конфигурации, всё соединилось. Бенчмарк живёт рядом с кодом и может сосредоточиться на любом слое конвейера или компоненте в движке. Он может создавать имитационные компоненты, тестировать варианты, и когда показатели улучшаются, выводить конфигурацию напрямую в исходный код. Эта связь стала необходимой. ИИ развивается так быстро, что выгодно иметь бенчмаркинг в проекте. Когда новая модель выходит с лучшей экономикой или скоростью, карточки оценок остаются прежними, а бенчмаркинг продолжается. Улучшения качества невероятны. Победные комбинации—выбор модели, инженерия запросов, настройка параметров—уже протестированы с полными аудитовыми цепочками, выводятся в конфигурацию и сразу попадают в производство. С помощью системы перевода мне стало невероятно ясно о возможностях модели для перевода языков. Победители автоматически становились производственной конфигурацией, всегда используя наилучший баланс качества, цены и сохранения культурных нюансов. Это создало аудит‑трейл, показывающий точную причину каждого технического решения, подкреплённую эмпирическими данными. Когда кто‑то спрашивает «Почему модель X для испанского- французского, но модель Y для китайского-английского?», ответ находится в результатах бенчмарка. ## Инженерия запросов через данные Система эволюционировала так, чтобы бенчмарки оценивать не только выбор модели, но и саму инженерию запросов. Я смог построить бенчмарки и затем позволить разным частям даже работать над AI‑запросами, систематически проводя A/B‑тесты разных запросов. Чёткие победители возникли на основе установленных метрик. Это устранило догадки в инженерии запросов, заменяя интуицию решениями, основанными на данных. ## Экономика непрерывного открытия В этом подходе есть значительный аспект экономии затрат. Карточка оценок создана для продвижения лучшего качества и культурных нюансов с хорошей скоростью, но и по лучшей стоимости. Вдобавок, я экономлю на том, что не нужно вручную оценивать ничего—просто всё происходит, когда новая модель или версия модели выходит. Когда модель заявляет, что она действительно хороша для определённых языковых пар, очень просто добавить её в конфигурацию и наблюдать, как бенчмарки работают. Я знаю, что всё, что побеждает, будет внедрено в производство, подкреплённое чёткими данными. Для меня разработка, управляемая бенчмарками, как наличие маленькой команды агентов, работающих в проекте, в специальном разделе, исследующих, открывающих и оценивающих. Насколько весело наблюдать. Это как иметь небольшую лабораторию исследований и разработок в проекте, работающую над задачами. Система перевода была одной из моих любимых систем — я потратил более двух лет на её разработку, иногда, и теперь она достигла точки, где я могу создать сервис, хотя в настоящее время использую её только лично. ## Добродетельный цикл Разработка, основанная на бенчмарках, создает добродетельный цикл: 1. **Ясность через измерения**: Абстрактное качество становится конкретными метриками 2. **Обучение через сравнение**: Каждый бенчмарк учит чему-то новому о проблемном пространстве 3. **Уверенность через данные**: Решения подкреплены локальными, проверяемыми доказательствами 4. **Эволюция через автоматизацию**: Система непрерывно улучшает себя Этот метод доказал свою высокую эффективность в направлении инноваций. Он стал моим предпочтительным подходом к созданию систем, особенно в сфере ИИ, где грунт постоянно меняется под нашими ногами. Я тоже не являюсь пуристом в этом отношении. Контекст каждого проекта раскрывает, какой подход работает лучше. ```mermaid 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:2px ``` ## Что появилось из практики При внедрении разработки, основанной на бенчмарках, эти шаблоны проявились как критические: - **Чёткие метрики оказались необходимыми**: Успех стал измеримым по нескольким измерениям, когда производительность, стоимость и качество отслеживались вместе с корректностью. - **Всеобъемлющие бенчмарки выявили скрытые проблемы**: Тестирование по всему спектру ожидаемых входов и крайних случаев выявило проблемы, которые пропустили частичные тесты. - **Кэширование ускорило итерацию**: Идемпотентность и агрессивное кэширование сделали возможными тысячи вариантов бенчмарков без избыточных вычислений. - **Автоматизированная конфигурация сократила ошибки**: Когда результаты бенчмарков напрямую генерировали конфигурацию для производства, ошибки ручного переноса исчезли. - **Отслеживание аудита обеспечило ясность**: Каждое решение конфигурации отслеживалось до данных бенчмарков, упрощая отладку и ответственность. ## Где данный подход процветает Моя философия в отношении разработки программного обеспечения заключается в том, что подход всегда должен развиваться в соответствии с контекстом и необходимостью. Разработка, управляемая бенчмарками, не имеет смысла для многих проектов, особенно тех, которые не обладают экспериментальной природой или не интегрированы напрямую с AI-системами, сталкивающимися с быстрым развитием. Для меня напряженность темпов эволюции в пространстве, комбинированная с диапазоном возможностей AI — от полностью детерминированных выходов при температуре ноль до креативных выходов при более высоких температурах — создала необходимость. С помощью системы перевода подход, управляемый бенчмарками, имел смысл, потому что я мог измерять качество, скорость и стоимость на основе достоверных доказательств и письменной истории. BDD доказала свою эффективность в сценариях с: - Множество допустимых вариантов реализации (различные модели ИИ, алгоритмы или подходы) - Быстро развивающиеся технологические ландшафты - Многомерные требования к оптимизации (качество, скорость, стоимость) - Необходимость объяснимых технических решений - Сложные конфигурационные пространства - Системы, требующие непрерывной адаптации к новым возможностям Он особенно мощен для AI-систем, движков рендеринга, задач оптимизации и любой области, где «лучшее» зависит от контекста и компромиссов. Контекст каждого проекта раскрывает, какой подход работает лучше. ## Путь вперед По мере того как AI всё глубже интегрируется в наши системы, статическое тестирование становится недостаточным. Доказательства показывают, что методологии, которые адаптируются так же быстро, как развиваются базовые технологии, дают лучшие результаты. Разработка, управляемая бенчмарками, предлагает путь вперёд, где наши системы постоянно оптимизируют себя на основе эмпирических доказательств. Сдвиг от TDD к BDD был эволюцией к чему-то более мощному, сохраняя тесты, но расширяя их за пределы. В мире, где лучшее решение меняется ежедневно, наши методологии разработки должны быть столь же динамичными. ## Заключение Benchmark-Driven Development представляет эволюцию в том, как мы строим и оптимизируем системы. Создавая генеративные, а не просто оценочные, бенчмарки, мы создаём самоподдерживающиеся системы с встроенными аудиторскими трассами. Ключевая идея: вместо того чтобы просто проверять, работает ли что-то, постоянно измерять, что работает лучше всего, а затем автоматически конфигурировать систему для использования этого оптимального решения. В эпоху экспоненциальных технологических изменений такая адаптивность и прозрачность становятся необходимыми для создания инновационных систем. Это чрезвычайно вознаграждающе, потому что я учусь от него сам. У меня больше ясности, а принятие решений поддерживается реальными локальными данными. Наблюдать за работой бенчмарков довольно весело — как иметь небольшую лабораторию НИР в проекте, открывающую, что работает, пока я сосредотачиваюсь на строительстве. Для любого, кто строит системы в быстро развивающихся областях, это предлагает прагматичный подход к достижению совершенства через эмпирическую оптимизацию. Применяйте только то, что служит реальным целям. Критически оценивайте всё, чтобы выявить, что действительно имеет значение. Когда команды понимают *почему* они делают то, что делают, результаты говорят сами за себя. Для систематического разборки фреймворка и шаблонов реализации я задокументировал основные компоненты в [Benchmark-Driven Development: A Framework](/articles/benchmark-driven-development-framework). Это первая статья, которую я делюсь на своём сайте, и я надеюсь, что вы нашли ценность в путешествии по открытию этой методологии. Берегите себя и удачи.