Представляем фреймворк Continuous Calibration/Continuous Development (CC/CD)
👋 Добро пожаловать в ✨ бесплатный выпуск ✨ моего еженедельного newsletter. Каждую неделю я разбираю вопросы читателей о создании продуктов, росте и развитии карьеры. Подробнее: Lenny's Podcast | How I AI | Lennybot | Lenny's Reads | Курсы
P.S. Годовые подписчики получают бесплатный год доступа к 15+ премиум-продуктам: Lovable, Replit, Bolt, n8n, Wispr Flow, Descript, Linear, Gamma, Superhuman, Warp, Granola, Perplexity, Raycast, Magic Patterns, Mobbin и ChatPRD (пока есть доступ). Подписаться.
В эпоху AI технологическим лидерам необходимо пересмотреть каждую лучшую практику индустрии по созданию продуктов. AI-продукты создаются принципиально иначе. Команды, которые осознают это и быстрее адаптируются, получат огромное конкурентное преимущество.
Основываясь на опыте реализации более 50 AI-внедрений в таких компаниях, как OpenAI, Google, Amazon, Databricks и Kumo, Айшварья Реганти и Кирити Бадам разработали фреймворк Continuous Calibration/Continuous Development (CC/CD) — специально для решения уникальных задач при создании AI-продуктов. В этой статье они делятся им впервые.
Узнать больше об Айш и Кирити можно на их популярном курсе Maven и их предстоящем бесплатном лайтнинг-токе, где они углублённо разбирают эту тему.
Этот пост можно также послушать в формате подкаста: Spotify / Apple / YouTube
Если ты — продакт-менеджер или разработчик, выпускающий AI-функции или продукты, ты, вероятно, уже сталкивался с этим:
Компания под давлением: нужно запустить что-то с AI. Появляется перспективная идея. Команда делает отличное демо, первые отзывы радуют, стейкхолдеры воодушевлены. Все усилия брошены на выход в продакшн.
Потом начинаются поломки. Ты погружаешься в дебри, пытаясь понять, что пошло не так. Но проблемы переплетены и трудно отследимы, ни одна из них не указывает на единственное решение. И вдруг весь твой продуктовый подход кажется шатким.
Мы видели это снова и снова. За последние несколько лет мы помогли более чем 50 компаниям спроектировать, запустить и масштабировать AI-автономные системы для тысяч клиентов. Во всех этих случаях мы наблюдали одну общую ловушку: люди упускают из виду, что AI-системы принципиально разрушают допущения традиционных программных продуктов.
AI-продукты нельзя создавать как обычные продукты — и вот почему:
Когда компании не признают эти различия, их AI-продукты сталкиваются с цепочкой последствий: неожиданными сбоями и плохими решениями. Мы видели, как множество команд болезненно переживают переход от впечатляющего демо к системе, которая не способна масштабироваться или работать стабильно. А вместе с этим тихо подрывается доверие пользователей к продукту.
После того как мы многократно наблюдали эту закономерность, мы разработали новый фреймворк жизненного цикла AI-продукта — основанный на том, что видели в успешных внедрениях. Он создан с учётом уникальности AI-систем и помогает создавать более осознанные, стабильные и надёжные продукты. К концу этой статьи ты сможешь соотнести свой продукт с этим фреймворком и лучше понять, как начать, на чём сосредоточиться и как безопасно масштабироваться.
Давай разберём, чем создание AI-продуктов отличается от традиционного программного обеспечения.
Традиционное программное обеспечение ведёт себя более или менее предсказуемо. Пользователи взаимодействуют известными способами: нажимают кнопки, отправляют формы, инициируют API-вызовы. Ты пишешь логику, которая сопоставляет эти входные данные с результатами. Если что-то ломается — это обычно проблема в коде, и её можно отследить.
AI-системы ведут себя иначе. Они вносят недетерминизм с обеих сторон: иными словами, непредсказуемость присутствует как в том, как пользователи взаимодействуют с системой, так и в том, как система реагирует.
Во-первых, поверхность взаимодействия с пользователем гораздо менее детерминирована. Вместо структурированных триггеров вроде нажатий кнопок пользователи взаимодействуют через открытые промпты, голосовые команды и другие естественные вводные данные. Их сложнее валидировать, легче неверно интерпретировать, и они значительно варьируются в зависимости от того, как пользователь выражает намерение.
Во-вторых, поведение системы inherently недетерминировано. AI-модели обучены генерировать правдоподобные ответы на основе паттернов, а не следовать фиксированным правилам. Один и тот же запрос может дать разные результаты в зависимости от формулировки, контекста или даже другой модели.
Это принципиально меняет то, как ты создаёшь и выпускаешь продукт. Ты больше не проектируешь предсказуемый пользовательский поток. Ты проектируешь вероятное поведение — и со стороны пользователя, и со стороны продукта, — а не гарантированное. Твой процесс разработки должен учитывать эту неопределённость с самого начала, постоянно калибруя разрыв между ожидаемым и тем, что проявляется в реальном мире.
Есть ещё один слой, который делает AI-системы особенными — тот, о котором раньше при работе с традиционными программными продуктами почти не приходилось думать: автономия.
Автономия в данном контексте — это способность AI-системы совершать действия, принимать решения или выполнять задачи от имени пользователя (отсюда и термин «AI-агент»). Например:
В отличие от традиционных инструментов, AI-системы созданы для того, чтобы действовать с разной степенью автономии. Но вот что люди часто упускают из виду:
Каждый раз, когда ты даёшь AI-системе больше автономии, ты уступаешь часть контроля.
Таким образом, всегда действует компромисс автономии и контроля. И этот компромисс очень важен! Если система предлагает ответ — ты всё ещё можешь его переопределить. Если она отправляет ответ автоматически — ты должен быть уверен, что он правильный.
Ошибка, которую совершает большинство команд, — это слишком ранний переход к полной автономии до того, как они протестировали, что происходит, когда система ошибается. Если ты не проверил, как система ведёт себя при высоком уровне контроля, ты ещё не готов давать ей высокую автономию. А если передать слишком много автономии до того, как система «заслужила» это, ты можешь утратить видимость системы и доверие пользователей.
Более того, ты оказываешься в ситуации отладки большой, сложной системы, которая совершала действия, которые ты не можешь отследить, по причинам, в которые ты потерял инсайт, — и даже не понимаешь, что нужно менять.
Что подводит нас к ключевому фреймворку, который мы разработали, чтобы помочь командам ориентироваться в этих особенностях.
Мы называем его CC/CD: Continuous Calibration/Continuous Development («Непрерывная калибровка / Непрерывная разработка»).
Название — отсылка к Continuous Integration/Continuous Deployment (CI/CD), но, в отличие от своего тёзки, он предназначен для систем с недетерминированным поведением, где автономия должна быть заработана.
Как и в традиционном программировании, AI-продукты проходят через фазы на пути к конечной цели. Но создание AI требует учёта двух вещей, упомянутых ранее: недетерминизма и компромисса автономии и контроля.
Фреймворк CC/CD разработан с учётом этих двух реалий:
В нашем фреймворке создатели продуктов работают в непрерывном цикле разработки (CD) и калибровки (CC). В фазе разработки ты формулируешь задачу, проектируешь архитектуру и настраиваешь оценки, чтобы держать недетерминизм под контролем. Начинаешь с функций с низкой автономией и высоким контролем, затем постепенно двигаешься вверх по мере того, как система доказывает, что справляется с большим.
Затем ты делаешь деплой — не как финишную черту, а как переход к следующей фазе. После деплоя ты переходишь в фазу калибровки, где наблюдаешь за реальным поведением, выясняешь, что сломалось, и вносишь точечные улучшения.
С каждым циклом система зарабатывает чуть больше автономии. Со временем этот цикл превращается в маховик, ускоряет обратную связь, укрепляет доверие и делает продукт сильнее с каждой версией.
Давай подробнее разберём каждый шаг цикла CC/CD: как он выглядит, почему важен и как делать его хорошо. Первые три шага составляют сторону Continuous Development цикла: формулировка возможности, настройка приложения и проектирование оценок.
Допустим, у тебя есть большая продуктовая идея и ты уже провёл исследование. Ясно, что AI — правильный подход. В традиционной разработке ты обычно планируешь v1, v2, v3 нового продукта на основе глубины функций или потребностей пользователей. В AI-системах версионность остаётся, но меняется линза.
Здесь каждая версия определяется тем, насколько автономна система и сколько контроля ты готов уступить. Поэтому вместо мышления в терминах наборов функций ты формулируешь возможности. Начни с определения набора функций с высоким контролем и низкой автономией (версия 1 на рисунке выше). Они должны быть небольшими, тестируемыми и легко наблюдаемыми. Отталкиваясь от этого, продумай, как эти возможности могут развиваться — постепенно наращивая автономию, версия за версией. Цель — разложить грандиозный конечный результат на ранние модели поведения, которые можно оценить, итерировать и развивать.
Например, если твоя конечная цель — автоматизировать клиентскую поддержку в компании, высококонтрольный способ начать — это сформулировать v1 как простую маршрутизацию тикетов в нужный отдел, затем перейти к v2, где система предлагает возможные решения, и только в v3 позволить ей авторазрешать тикеты с фолбэком на человека.
Помни, это лишь один подход. На практике всё зависит от твоего продукта, но процесс, как правило, одинаков: начинай с простых решений, которые легко верифицировать и легко переопределить людям. Затем, продвигаясь по циклу CC/CD, постепенно добавляй автономию с каждой версией.
То, сколько времени ты проводишь в каждой версии, целиком зависит от того, сколько поведенческих сигналов ты получаешь. Ты оптимизируешь для понимания того, как ведёт себя твой AI в условиях реального шума и вариативности.
Вот ещё пара примеров:
Маркетинговый ассистент
Ассистент для кода
Если ты следил за тем, как развивались инструменты вроде GitHub Copilot или Cursor, — это именно та стратегия, которую они использовали. Большинство пользователей видят только текущую версию, но в основе системы лежит постепенное продвижение по этой лестнице. Сначала дополнения, потом блоки, потом PR — каждый шаг заработан через использование, обратную связь и итерации.
Поскольку поведение пользователей недетерминировано, тебе нужно создать эталон того, как выглядит ожидаемое поведение и как должна реагировать твоя AI-система. Вот тут в игру вступают данные. Данные помогают преодолеть холодный старт и дают тебе что-то конкретное для оценки. Мы называем это эталонным датасетом.
В примере с автоматизацией клиентской поддержки для версии маршрутизации (v1) эталонный датасет может включать:
Ты можешь взять данные из прошлых логов (если они есть) или сгенерировать примеры на основе ожидаемой работы продукта. Этот датасет помогает оценивать производительность системы и также подсказывает, какой контекст нужен ассистенту для надёжной работы. Поскольку большинство продуктов стартует «с нуля», стремись собрать хотя бы от 20 до 100 примеров заранее.
Мы продолжим использовать пример с клиентской поддержкой для разбора следующих шагов цикла CC/CD. Представь, что ты строишь полностью автономную систему поддержки для компании. Ниже — версии, на которые мы будем ссылаться, с соответствующими уровнями автономии и контроля. Мы будем упоминать v1, v2 и v3 на протяжении всей статьи.
Большинство людей пропускают шаг 1 и слишком рано переходят к фазе настройки, теряясь в выборе реализации и раздумывая, какие компоненты нужны. Но если ты правильно сформулировал возможность на шаге 1, изучил достаточно примеров и собрал надёжный эталонный датасет, настройка приложения должна быть довольно прямолинейной. Ты уже знаешь, что должна делать система, имеешь представление о том, что пользователи будут бросать в неё, и понимаешь, как выглядит хороший ответ. Теперь нужно просто собрать простейшую версию, которая даст тебе полезный сигнал.
В программировании есть известное высказывание не без причины: «Преждевременная оптимизация — корень всех зол.» Здесь оно тоже применимо. Не переусложняй. Не переоптимизируй. Не на этом этапе. Просто не делай этого. Создавай только то, что нужно для твоей текущей версии. Сделай систему измеримой и итерируемой, настроив логи для захвата того, что система получает от пользователя, что возвращает и как с этим взаимодействуют люди. Это станет основой твоего датасета живых взаимодействий и поможет улучшать систему со временем. Мы не будем углубляться в детали реализации здесь, но если ты открываешь это для конечных пользователей — убедись, что базовые вещи, вроде защитных механизмов и соответствия требованиям, на месте.
Ещё один важный момент: при настройке приложения убедись, что управление может быть бесшовно передано людям в нужный момент. Мы будем называть это передачей контроля. Например, в клиентской поддержке v1, если тикет был неверно маршрутизирован, принимающий агент (контактное лицо для этого отдела) должен иметь возможность легко его перенаправить. Поскольку это исправление логируется, оно не только помогает улучшать систему со временем, но и сохраняет пользовательский опыт. Продуманная передача контроля с самого начала — ключ к укреплению доверия и возможности откатиться при необходимости.
Этот шаг, как правило, требует некоторого осмысления. Прежде чем что-либо выпускать, нужно определить, как ты будешь измерять, делает ли система то, что ты ожидаешь, и готова ли она к следующему шагу. Для этого используются метрики оценки (evals, сокращённо).
Так что же такое evals?
Evals — это механизмы оценки, которые помогают понять, работает ли твоя AI-система, где она даёт сбои и что нужно улучшить. Думай о них как об эквиваленте тестов в традиционном программировании. Но в отличие от обычных юнит- или интеграционных тестов, где входные и выходные данные фиксированы, а корректность бинарна, AI-evals имеют дело с неоднозначностью.
Они полностью специфичны для приложения и привязаны к задаче, сформулированной на шаге 1. Ты не просто проверяешь, запускается ли система — ты проверяешь, насколько хорошо она делает что-то inherently недетерминированное, например суммирует документ или отвечает на вопрос. Именно поэтому evals не универсальны. Они служат сигналами для управления твоим циклом итераций, помогая настраивать и уточнять поведение со временем.
Например, в маршрутизации v1 системы клиентской поддержки простой, но сильной оценкой будет точность маршрутизации — как часто система направляет тикет в правильный отдел. Одно это может показать, усваивает ли модель правильные различия и насколько надёжна твоя настройка.
В v2 системы клиентской поддержки, где ты извлекаешь внутренние стандартные операционные процедуры (СОП) или прошлые решения для помощи агенту, оценки смещаются к качеству извлечения. Действительно ли предложения релевантны тикету? Это то, на что посмотрел бы человек-агент?
Одна из лучших практик на этом этапе — запускать оценки на эталонном датасете из шага 1. Это помогает оценить производительность, убедиться, что evals хорошо спроектированы, и внести ранние правки в настройку продукта из шага 2. Некоторые команды ждут деплоя для уточнений, полагаясь на реальные взаимодействия пользователей. Такой подход тоже может работать — в зависимости от профиля риска системы и объёма эталонных данных, которые можно собрать заранее.
Не нужно чрезмерно оптимизировать evals на эталонном датасете. Цель — широкий охват ключевых сценариев, а не совершенство. Производственное поведение будет отличаться, но хорошая настройка оценок даёт надёжную отправную точку.
Чтобы глубже погрузиться в проектирование и уточнение evals, отличной отправной точкой будет материал Амана.
—
После того как ты реализовал систему и убедился, что она правильно сформулирована и инструментирована, пора деплоить. Деплой — это переходная фаза между циклами Continuous Development и Continuous Calibration.
Деплой — это приятная часть. Но ты не просто деплоишь «на ощущениях» (за неимением лучшего термина 🙂) и надеешься на лучшее. Ты выстроил пайплайн, который позволяет тебе учиться и улучшаться. Ты логируешь взаимодействия, выстроил механизм возврата контроля людям и настроил метрики оценки, чтобы сигнализировать о сбоях. Теперь пора посмотреть, как система работает в дикой природе.
Бум. Ты деплоишь на небольшую когорту, и система начинает работать.
Отсюда ты переходишь в фазу Continuous Calibration. Здесь начинает проявляться реальное поведение и ты начинаешь понимать, что работает, что ломается и что нужно исправить следующим.
Ты спроектировал метрики оценки в цикле CD. Теперь, когда ты сделал деплой и имеешь логи поведения пользователей, пора оценить, как система фактически справилась. Накопив достаточное количество данных живых взаимодействий, ты можешь запустить оценку. Её можно запустить на подмножестве данных или на полном датасете — в зависимости от ограничений по стоимости и вычислительным ресурсам.
Если нужно оценивать на подмножестве, используй уникальные свойства своей системы, чтобы решить, какие точки данных выбрать. Например, в v1 системы клиентской поддержки можно использовать логи, показывающие, перенаправил ли агент запрос в другой отдел, как прокси для точности маршрутизации. В более сложных системах можно смотреть на количество ходов в диалоге, отметки «палец вверх» или «палец вниз» от пользователей или другие сигналы внутри сессии.
Логи передачи контроля также могут давать ценные сигналы для оценки — особенно когда фиксируют, как человек вмешался или скорректировал результат.
Пример оценки для системы клиентской поддержки v1
В зависимости от твоего сценария использования выбери наиболее репрезентативную выборку живых взаимодействий пользователей для запуска метрик оценки. А если данных взаимодействий немного (2 000–3 000 логов), запускай оценку на полном датасете.
Когда смотришь на evals — может быть, они выглядят хорошо. Может, нет. Если ты хорошо выполнил шаги 1–3 фазы Continuous Development, метрики, вероятно, где-то посередине — а значит, есть что оптимизировать.
Теперь пора начать ручной просмотр данных. Это один из самых недооценённых, но необходимых аспектов создания AI-систем. Простая стратегия — начинать с того, где метрики оценки наиболее слабы. Именно там, как правило, сосредоточен самый ценный сигнал.
Например, в маршрутизации системы клиентской поддержки v1 ты можешь:
Смотри на то, что сказал пользователь, что сделала система и каков был результат. В зависимости от приложения это может быть единственное взаимодействие или многоходовая сессия. Метрики оценки должны помочь тебе определить, где что-то пошло не так, и направить к точке сбоя.
Просмотрев достаточно примеров вручную, ты начнёшь замечать повторяющиеся паттерны ошибок. Здесь начинается их документирование. На этом этапе хорошо работает простой табличный формат:
Эти паттерны показывают, что нужно изменить в логике системы, промптах или входных данных. Они также помогают более осознанно формулировать следующую версию.
Имея на руках actionable паттерны ошибок, ты можешь начать намечать способы их устранения. Это может быть что угодно: простая правка промпта, переход на более хорошую модель, улучшение качества извлечения или добавление новых компонентов для декомпозиции задачи. Что именно менять — полностью зависит от того, что сломалось.
Помнишь, как на шаге 2 фазы Continuous Development мы говорили не переусложнять? Потому что именно этот шаг — когда нужно инженерить больше. Развивай архитектуру, но делай это осознанно — опираясь на данные, а не на догадки.
Этот шаг сам по себе часто итеративен. Применяешь исправление, снова запускаешь метрики оценки и либо продолжаешь доводить текущую версию, либо проходишь через шаги 2–5 снова, пока система не будет работать достаточно хорошо. И поскольку данные у тебя уже есть, переделывать деплой каждый раз не нужно.
Кроме того, нередко сам дизайн оценок оказывается недостаточным. Это происходит потому, что evals часто проектируются на эталонном датасете, который основан на том, что ты ожидаешь от пользователей. Реальное поведение пользователей, однако, может сильно отличаться. Этот недетерминизм может сбить и твои оценки тоже. Проходя снова через шаги 4 и 5, ты можешь обнаружить места, где oценки пропускали проблемы или ставили высокие баллы некорректным выводам. Так что шаг 6 может включать пересмотр и перестройку оценок — и это совершенно нормально. Скорее всего, ты проведёшь несколько раундов оценки, продолжая формировать продукт. Ну что поделаешь... это часть процесса.
—
К концу шага 6 в первый раз ты, вероятно, уже войдёшь в ритм. Ты пройдёшь этот цикл несколько раз, постепенно снижая контроль, позволяя системе становиться более автономной и давая продуктовым функциям направлять твои дизайн-решения. Помни, что деплой — лишь часть большой картины. Большая часть работы — в том, чтобы всё хорошо спроектировать.
Что приводит нас к небольшому ворчанию: слишком многие сосредотачиваются почти исключительно на реализации, гоняясь за последними инструментами и фреймворками, и в итоге допускают дорогостоящие ошибки. Мы начали с большой цели, разбили её на части и использовали более сложные решения только тогда, когда они действительно решали реальную проблему.
Никогда не начинай с технологии. Пусть проблема, оценки и данные определяют, что добавляется следующим. Именно так держишь недетерминизм под контролем в AI-продуктах.
Вот возможная таблица, которая разбивает задачу на несколько версий, каждая из которых добавляет всё больше автономии. В ней также описан маховик, который можно выстроить на каждом этапе, — на примере клиентской поддержки, который мы обсуждали. Каждая итерация готовит почву для следующей. Это лишь один из подходов.
Используй это как вдохновение, чтобы подумать, как ты мог бы разложить свой продукт для осознанного создания и масштабирования.
Если бы ты сразу выпустил полностью автономную систему поддержки (v3), многое могло бы быстро пойти не так. Вот один простой пример: запрос на возврат неверно помечается как вопрос биллинга, система подтягивает не ту СОП и генерирует правдоподобное, но некорректное решение — пользователь оказывается в замешательстве и теряет доверие к продукту.
И хотя у тебя могут быть настроены evals для сигнализации о сбое, ты теперь застреваешь в распутывании цепочки отказов. Финальная ошибка оказалась ошибкой генерации, но началась на маршрутизации, усугубилась отсутствующим контекстом и привела к плохому результату. Это лишь один простой случай, но уже видно, как быстро всё может усложниться.
Подход CC/CD помогает избежать этой спирали. В клиентской поддержке v1 система занимается только маршрутизацией тикетов, давая тебе сигналы о том, как пользователи формулируют проблемы, какие отделы часто путают и какие метаданные действительно важны. Ты используешь это, чтобы улучшить логику маршрутизации и уточнить промпты перед переходом дальше. В v2 система составляет ответы на основе СОП, но человек всё ещё проверяет их. Это помогает понять, где ломается извлечение и каким документам нужны обновления. К v3 система готова взять на себя больше автономии — самостоятельно решать определённые тикеты. Но к этому моменту ты уже знаешь, какие запросы безопасно автоматизировать и где нужен фолбэк.
AI-системы обладают невероятным потенциалом для работы с определённой степенью автономии, но прийти к этому — редко означает нагромождать сложные инструменты или масштабироваться грубой силой. И дело не в написании идеального промпта. Создание AI-системы, которая экономит время, деньги и энергию за счёт эффективной автоматизации, — это решение реальной проблемы шаг за шагом, через понимание её нюансов.
Мы часто сравниваем работу с AI с онбордингом нового члена команды. Этот человек может быть блестящим, но он ещё не знает, как работает твоя команда. Ты не отдаёшь ему самые ответственные проекты с первого дня. Начинаешь с малого, наблюдаешь, выстраиваешь доверие — и по мере того, как он демонстрирует, с чем справляется, постепенно расширяешь его зону ответственности. AI-системам нужен тот же путь. Именно это и призван поддерживать фреймворк CC/CD.
В основе CC/CD лежит суждение: то, которое помогает тебе решать, что выпускать, как защищать пользователей при сбоях, когда передавать контроль обратно и как определять, что значит «достаточно хорошо».
Нет универсального ответа на вопрос о том, сколько возможностей давать каждой версии, как долго собирать данные перед движением вперёд или насколько узко формулировать задачу. Всё зависит от твоего продукта, пользователей и сроков. Одним продуктам нужны недели итераций. Другие могут двигаться быстрее. Вот где в игру вступает твоё суждение.
Большая часть этого ценного продуктового мышления уже живёт в успешных продуктовых лидерах. CC/CD просто придаёт ему структуру. Фреймворк предлагает цикл, ритм и общий язык для применения уже имеющегося отличного продуктового инстинкта к AI-системам.
Спасибо, Айш и Кирити! Ты можешь подписаться на них в LinkedIn, а также ознакомиться с их популярным курсом Maven и их предстоящим бесплатным лайтнинг-током, где они углублённо разбирают эту тему.
Продуктивной и насыщенной тебе недели 🙏
Если этот newsletter полезен для тебя — поделись им с другом и подпишись, если ещё не успел. Доступны групповые скидки, подарочные подписки и реферальные бонусы.
С уважением,
Ленни 👋