A Field Guide to Rapidly Improving AI Products – Hamel’s Blog

Большинство AI-команд фокусируются не на том. Вот типичная сцена из моей консалтинговой практики:

«Вот архитектура нашего агента — тут у нас RAG, тут маршрутизатор, и мы используем вот этот новый фреймворк для…»

[Поднимаю руку, чтобы остановить воодушевлённого техлида.] «Можете показать мне, как вы измеряете, работает ли всё это на самом деле?»

Эта сцена повторялась десятки раз за последние два года. Команды вкладывают недели в построение сложных AI-систем, но не могут сказать мне, помогают их изменения или вредят.

Это неудивительно. Когда каждую неделю появляются новые инструменты и фреймворки, естественно фокусироваться на осязаемых вещах, которые мы можем контролировать — какую векторную базу данных использовать, какого LLM-провайдера выбрать, какой агентный фреймворк взять. Но после работы с более чем 30 компаниями над AI-продуктами я обнаружил, что успешные команды почти не говорят об инструментах. Вместо этого они одержимы измерениями и итерациями.

В этом посте я покажу вам, как именно работают эти успешные команды. Вы узнаете:

Как анализ ошибок стабильно выявляет улучшения с наибольшей отдачей Почему простой просмотрщик данных — ваша самая важная AI-инвестиция Как дать доменным экспертам (а не только инженерам) возможность улучшать ваш AI Почему синтетические данные эффективнее, чем вы думаете Как поддерживать доверие к системе оценки Почему ваш AI-роадмап должен считать эксперименты, а не фичи

Я объясню каждую из этих тем на реальных примерах. Хотя каждая ситуация уникальна, вы увидите паттерны, которые применимы независимо от вашей предметной области или размера команды.

Начнём с разбора самой распространённой ошибки, которую я вижу у команд, — ошибки, которая сводит AI-проекты на нет ещё до их начала.

1. Самая распространённая ошибка: пропуск анализа ошибок

Мышление «сначала инструменты» — самая распространённая ошибка в AI-разработке. Команды увлекаются архитектурными диаграммами, фреймворками и дашбордами, пренебрегая процессом реального понимания того, что работает, а что нет.

Один клиент с гордостью показал мне вот такой дашборд оценки:

Это «ловушка инструментов» — убеждение, что внедрение правильных инструментов или фреймворков (в данном случае — обобщённых метрик) решит ваши AI-проблемы. Обобщённые метрики хуже, чем бесполезны — они активно тормозят прогресс двумя способами:

Во-первых, они создают ложное ощущение измерения и прогресса. Команды думают, что принимают решения на основе данных, потому что у них есть дашборды, но они отслеживают метрики тщеславия, которые не коррелируют с реальными проблемами пользователей. Я видел, как команды праздновали улучшение «оценки полезности» на 10%, в то время как их реальные пользователи по-прежнему не справлялись с базовыми задачами. Это как оптимизировать скорость загрузки сайта, когда у вас сломан процесс оформления заказа — вы становитесь лучше не в том.

Во-вторых, слишком много метрик дробят ваше внимание. Вместо того чтобы сосредоточиться на нескольких метриках, которые действительно важны для вашего конкретного кейса, вы пытаетесь оптимизировать множество параметров одновременно. Когда важно всё — не важно ничего.

Альтернатива? Анализ ошибок — самая ценная деятельность в AI-разработке и стабильно наиболее окупаемое занятие. Давайте посмотрим, как эффективный анализ ошибок выглядит на практике.

Процесс анализа ошибок

Когда Jacob, основатель Nurture Boss, решил улучшить AI-ассистента для индустрии аренды жилья, его команда создала простой просмотрщик для изучения диалогов между AI и пользователями. Рядом с каждым диалогом было место для свободных заметок о режимах отказа.

После аннотирования десятков диалогов проявились чёткие паттерны. Их AI не справлялся с обработкой дат — ошибался в 66% случаев, когда пользователи говорили что-то вроде «давайте назначим экскурсию через две недели».

Вместо того чтобы хвататься за новые инструменты, они: 1. Просмотрели реальные логи диалогов 2. Категоризировали типы ошибок обработки дат 3. Создали конкретные тесты для выявления этих проблем 4. Измерили улучшения по этим метрикам

Результат? Успешность обработки дат выросла с 33% до 95%.

Вот Jacob сам объясняет этот процесс:

Восходящий и нисходящий анализ

При определении типов ошибок можно использовать либо «нисходящий», либо «восходящий» подход.

Нисходящий подход начинается с общепринятых метрик вроде «галлюцинации» или «токсичности» плюс метрик, уникальных для вашей задачи. Хотя это удобно, такой подход часто упускает специфические для домена проблемы.

Более эффективный восходящий подход заставляет вас смотреть на реальные данные и позволяет метрикам возникать естественным образом. В NurtureBoss мы начали с таблицы, где каждая строка представляла один диалог. Мы писали свободные заметки о любом нежелательном поведении. Затем использовали LLM для построения таксономии типичных режимов отказа. Наконец, мы сопоставили каждую строку с конкретными метками режимов отказа и подсчитали частоту каждой проблемы.

Результаты были поразительными — всего три проблемы составляли более 60% всех ошибок:

Проблемы с потоком диалога (отсутствие контекста, неловкие ответы) Сбои при передаче (неспособность распознать, когда нужно перевести на человека) Проблемы с переносом встреч (трудности с обработкой дат)

Эффект был мгновенным. Команда Jacob обнаружила столько практически применимых инсайтов, что им потребовалось несколько недель только на внедрение исправлений для уже найденных проблем.

Если вы хотите увидеть анализ ошибок в действии, мы записали пошаговый разбор здесь.

Это подводит нас к ключевому вопросу: как сделать так, чтобы командам было легко смотреть на свои данные? Ответ ведёт нас к тому, что я считаю самой важной инвестицией для любой AI-команды…

2. Самая важная AI-инвестиция: простой просмотрщик данных

Самая результативная инвестиция, которую я видел у AI-команд, — это не навороченный дашборд оценки, а создание кастомного интерфейса, который позволяет любому изучить, что AI на самом деле делает. Я подчёркиваю кастомного, потому что у каждой предметной области свои уникальные потребности, которые готовые инструменты редко закрывают. При просмотре диалогов об аренде квартир нужно видеть полную историю чата и контекст планирования. Для запросов о недвижимости нужны детали объекта и исходные документы прямо перед глазами. Даже мелкие UX-решения — где разместить метаданные или какие фильтры показать — могут определить, будет ли инструмент реально использоваться или его будут избегать.

Я наблюдал, как команды мучаются с обобщёнными интерфейсами разметки, перебирая несколько систем, чтобы понять одно-единственное взаимодействие. Трение накапливается: переходы в разные системы для просмотра контекста, копирование описаний ошибок в отдельные таблицы, переключение между инструментами для проверки информации. Это трение не просто замедляет команды — оно активно отбивает желание проводить систематический анализ, который выявляет тонкие проблемы.

Команды с продуманными просмотрщиками данных итерируют в 10 раз быстрее тех, у кого их нет. И вот что важно: такие инструменты можно создать за часы с помощью AI-ассистентов для разработки (таких как Cursor или Loveable). Инвестиции минимальны по сравнению с отдачей.

Позвольте показать, что я имею в виду. Вот просмотрщик данных, созданный для NurtureBoss (о котором мы говорили ранее):

Вот что делает хороший инструмент аннотации данных:

Показывайте весь контекст в одном месте. Не заставляйте пользователей рыскать по разным системам, чтобы понять, что произошло. Сделайте обратную связь тривиальной. Кнопки «правильно/неправильно» в один клик лучше длинных форм. Собирайте свободную обратную связь. Это позволяет фиксировать нюансные проблемы, которые не укладываются в заранее определённую таксономию. Обеспечьте быструю фильтрацию и сортировку. Команды должны легко погружаться в конкретные типы ошибок. В примере выше NurtureBoss может быстро фильтровать по каналу (голос, текст, чат) или конкретному объекту недвижимости. Добавьте горячие клавиши, позволяющие навигировать между примерами данных и аннотировать без использования мыши.

Неважно, какие веб-фреймворки вы используете — берите то, что знаете. Поскольку я Python-разработчик, мой текущий любимый веб-фреймворк — FastHTML в связке с MonsterUI, потому что он позволяет определить бэкенд и фронтенд в одном небольшом Python-файле.

Главное — начать хоть с чего-то, пусть даже простого. По моему опыту, кастомные веб-приложения дают лучший результат, но если вы только начинаете, таблица лучше, чем ничего. По мере роста потребностей вы сможете развивать свои инструменты.

Это подводит нас к ещё одному контринтуитивному уроку: люди, лучше всего способные улучшить вашу AI-систему, часто меньше всего знают об AI.

3. Дайте доменным экспертам писать промпты

Недавно я работал с образовательным стартапом, создающим интерактивную обучающую платформу на LLM. Их продакт-менеджер, эксперт по проектированию обучения, создавала подробные презентации в PowerPoint с объяснением педагогических принципов и примерами диалогов. Она представляла их команде инженеров, которые затем переводили её экспертизу в промпты.

Но вот в чём дело: промпты — это просто английский язык. Когда эксперт по обучению передаёт принципы преподавания через PowerPoint, а инженеры переводят это обратно в текстовые промпты, создаётся ненужное трение. Самые успешные команды переворачивают эту модель, давая доменным экспертам инструменты для написания и итерации промптов напрямую.

Стройте мосты, а не заставы

Площадки для экспериментов с промптами — отличная отправная точка для этого. Такие инструменты, как Arize, Langsmith и Braintrust, позволяют командам быстро тестировать разные промпты, подавать примерные датасеты и сравнивать результаты. Вот несколько скриншотов этих инструментов:

Но есть важный следующий шаг, который многие команды упускают: интеграция разработки промптов в контекст приложения. Большинство AI-приложений — это не просто промпты. Обычно они включают RAG-системы, извлекающие данные из базы знаний, оркестрацию агентов, координирующую несколько шагов, и специфичную для приложения бизнес-логику. Самые эффективные команды, с которыми я работал, выходят за рамки изолированных площадок. Они создают то, что я называю интегрированными средами для промптов — по сути, администраторские версии реального пользовательского интерфейса с возможностью редактирования промптов.

Вот иллюстрация того, как может выглядеть интегрированная среда для промптов для AI-ассистента по недвижимости:

Советы по коммуникации с доменными экспертами

Есть ещё один барьер, который часто мешает доменным экспертам вносить эффективный вклад: лишний жаргон. Я работал с образовательным стартапом, где инженеры, продакт-менеджеры и специалисты по обучению разговаривали на разных языках на встречах. Инженеры постоянно говорили: «Мы собираемся построить агент, который делает XYZ», хотя на самом деле задача сводилась к написанию промпта. Это создавало искусственный барьер — специалисты по обучению, которые были настоящими доменными экспертами, чувствовали, что не могут внести вклад, потому что не понимают «агентов».

Это происходит повсюду. Я видел это с юристами в лигалтех-компаниях, психологами в стартапах по ментальному здоровью и врачами в медицинских фирмах. Магия LLM в том, что они делают AI доступным через естественный язык, но мы часто уничтожаем это преимущество, оборачивая всё в техническую терминологию.

Вот простой пример того, как перевести распространённый AI-жаргон:

Это не значит упрощать — это значит быть точным в том, что вы на самом деле делаете. Когда вы говорите «мы строим агент», какую конкретную способность вы добавляете? Это вызов функций? Использование инструментов? Или просто лучший промпт? Конкретика помогает всем понять, что происходит на самом деле.

Здесь есть нюанс. Техническая терминология существует не просто так — она обеспечивает точность при общении с другими техническими специалистами. Ключ в том, чтобы адаптировать язык к своей аудитории.

На этом этапе многие команды задают вопрос: «Всё это звучит отлично, но что если у нас ещё нет данных? Как мы можем смотреть примеры или итерировать промпты, если мы только начинаем?» Об этом и поговорим дальше.

4. Бутстрап AI с помощью синтетических данных эффективен (даже при нуле пользователей)

Одно из самых частых препятствий, о которых я слышу от команд: «Мы не можем проводить нормальную оценку, потому что у нас ещё недостаточно реальных пользовательских данных». Это создаёт проблему курицы и яйца — вам нужны данные, чтобы улучшить AI, но вам нужен приличный AI, чтобы привлечь пользователей, которые генерируют эти данные.

К счастью, есть решение, которое работает на удивление хорошо: синтетические данные. LLM могут генерировать реалистичные тестовые случаи, покрывающие спектр сценариев, с которыми столкнётся ваш AI.

Как я писал в своём блог-посте «LLM-как-судья», синтетические данные могут быть удивительно эффективны для оценки. Bryan Bischof, бывший руководитель AI в Hex, сформулировал это отлично:

«LLM удивительно хороши в генерации отличных — и разнообразных — примеров пользовательских запросов. Это может быть полезно для реализации функций приложения и, что неожиданно, для построения оценок. Если вам кажется, что Большая Языковая Змея кусает себя за хвост, я был удивлён не меньше вашего! Могу сказать только одно: это работает — отправляйте в продакшн.»

Фреймворк для генерации реалистичных тестовых данных

Ключ к эффективным синтетическим данным — выбор правильных измерений для тестирования. Хотя эти измерения будут различаться в зависимости от ваших конкретных потребностей, я считаю полезным думать о трёх широких категориях:

Функции: какие возможности должен поддерживать ваш AI? Сценарии: с какими ситуациями он столкнётся? Персоны пользователей: кто будет им пользоваться и как?

Это не единственные измерения, которые могут вас интересовать — возможно, вы также захотите тестировать разные тона голоса, уровни технической искушённости или даже разные локали и языки. Важно определить измерения, которые имеют значение для вашего конкретного кейса.

Для AI-ассистента CRM в сфере недвижимости, над которым я работал с Rechat, мы определили эти измерения так:

features = [ "property search", # Поиск объектов по критериям "market analysis", # Анализ трендов и цен "scheduling", # Назначение просмотров "follow-up" # Коммуникация после просмотра ] scenarios = [ "exact match", # Одно идеальное совпадение "multiple matches", # Нужно помочь пользователю сузить выбор "no matches", # Нужно предложить альтернативы "invalid criteria" # Помочь пользователю исправить параметры поиска ] personas = [ "first_time_buyer", # Нуждается в большем руководстве и объяснениях "investor", # Сфокусирован на цифрах и ROI "luxury_client", # Ожидает обслуживания высшего уровня "relocating_family" # Имеет специфические требования к району/школам ]

Но определение этих измерений — лишь половина дела. Настоящая задача — убедиться, что ваши синтетические данные действительно запускают сценарии, которые вы хотите протестировать. Для этого нужны две вещи:

Тестовая база данных с достаточным разнообразием для поддержки ваших сценариев Способ проверить, что сгенерированные запросы действительно запускают нужные сценарии

Для Rechat мы поддерживали тестовую базу данных объектов, которые, как мы знали, вызовут различные граничные случаи. Некоторые команды предпочитают использовать анонимизированную копию продакшн-данных, но в любом случае нужно убедиться, что ваши тестовые данные достаточно разнообразны, чтобы задействовать интересующие вас сценарии.

Вот пример того, как мы могли бы использовать эти измерения с реальными данными для генерации тестовых случаев для функции поиска объектов (это псевдокод, сугубо иллюстративный):

def generate_search_query(scenario, persona, listing_db): """Generate a realistic user query about listings""" # Pull real listing data to ground the generation sample_listings = listing_db.get_sample_listings( price_range=persona.price_range, location=persona.preferred_areas ) # Verify we have listings that will trigger our scenario if scenario == "multiple_matches" and len(sample_listings) < 2: raise ValueError("Need multiple listings for this scenario") if scenario == "no_matches" and len(sample_listings) > 0: raise ValueError("Found matches when testing no-match scenario") prompt = f""" You are an expert real estate agent who is searching for listings. You are given a customer type and a scenario. Your job is to generate a natural language query you would use to search these listings. Context: - Customer type: {persona.description} - Scenario: {scenario} Use these actual listings as reference: {format_listings(sample_listings)} The query should reflect the customer type and the scenario. Example query: Find homes in the 75019 zip code, 3 bedrooms, 2 bathrooms, price range $750k - $1M for an investor. """ return generate_with_llm(prompt)

Это давало реалистичные запросы вроде:

Ключ к полезным синтетическим данным — привязка к реальным ограничениям системы. Для AI-ассистента по недвижимости это означает:

Использование реальных ID объектов и адресов из их базы данных Включение актуальных расписаний и окон доступности агентов Соблюдение бизнес-правил: ограничений на показы, сроков уведомления Включение рыночной специфики: требования ТСЖ, местные регуляции

Затем мы пропускали эти тестовые случаи через Lucy и логировали взаимодействия. Это давало нам богатый датасет для анализа, показывающий, как именно AI обрабатывает разные ситуации с реальными системными ограничениями. Такой подход помог нам исправить проблемы до того, как они затронули реальных пользователей.

Иногда у вас нет доступа к продакшн-базе данных, особенно для новых продуктов. В таких случаях используйте LLM для генерации и тестовых запросов, и базовых тестовых данных. Для AI-ассистента по недвижимости это может означать создание синтетических объявлений с реалистичными атрибутами — ценами, соответствующими рыночным диапазонам, валидными адресами с настоящими названиями улиц и удобствами, подходящими для каждого типа объекта. Ключ — привязка синтетических данных к реальным ограничениям, чтобы они были полезны для тестирования. Детали генерации надёжных синтетических баз данных выходят за рамки этого поста.

5. Поддержание доверия к оценкам критически важно

Я неоднократно наблюдал такой паттерн: команды строят системы оценки, а затем постепенно теряют к ним доверие. Иногда — потому что метрики не совпадают с тем, что они наблюдают в продакшне. Иногда — потому что оценки становятся слишком сложными для интерпретации. В любом случае результат один — команда возвращается к принятию решений на основе интуиции и отдельных отзывов, подрывая весь смысл системы оценки.

Поддержание доверия к системе оценки не менее важно, чем её создание. Вот как наиболее успешные команды подходят к этой задаче:

Понимание дрейфа критериев

Одна из самых коварных проблем в оценке AI — «дрейф критериев»: явление, при котором критерии оценки эволюционируют по мере наблюдения за выходными данными модели. В своей статье «Who Validates the Validators?» Shankar et al. описывают это явление:

«Чтобы оценивать результаты, людям нужно формализовать и определить свои критерии оценки; однако сам процесс оценки результатов помогает им определить эти самые критерии.»

Это создаёт парадокс: вы не можете полностью определить критерии оценки, пока не увидите широкий спектр результатов, но вам нужны критерии для оценки этих результатов. Другими словами, невозможно полностью определить критерии оценки до того, как человек начнёт оценивать выходные данные LLM.

Я наблюдал это лично, работая с Phillip Carter в Honeycomb над их функцией Query Assistant. Когда мы оценивали способность AI генерировать запросы к базе данных, Phillip заметил кое-что интересное:

«Наблюдая за тем, как LLM разбирает свои рассуждения, я понял, что сам был непоследователен в оценке некоторых граничных случаев.»

Процесс изучения выходных данных AI помог ему чётче сформулировать собственные стандарты оценки. Это не признак плохого планирования — это неотъемлемая характеристика работы с AI-системами, которые производят разнообразные и порой неожиданные результаты.

Команды, которые сохраняют доверие к своим системам оценки, принимают эту реальность, а не борются с ней. Они относятся к критериям оценки как к живым документам, которые развиваются вместе с пониманием проблемного пространства. Они также признают, что у разных заинтересованных сторон могут быть разные (иногда противоречивые) критерии, и работают над согласованием этих точек зрения, а не навязывают единый стандарт.

Создание надёжных систем оценки

Так как же построить системы оценки, которые остаются надёжными, несмотря на дрейф критериев? Вот подходы, которые я нашёл наиболее эффективными:

1. Предпочитайте бинарные решения произвольным шкалам

Как я писал в посте «LLM-как-судья», бинарные решения обеспечивают ясность, которую более сложные шкалы часто скрывают. Столкнувшись со шкалой от 1 до 5, оценщики часто не могут определить разницу между 3 и 4, внося непоследовательность и субъективность. Чем именно «отчасти полезно» отличается от «полезно»? Эти пограничные случаи поглощают непропорционально много умственной энергии и создают шум в данных оценки. И даже когда компании используют шкалу от 1 до 5, они неизбежно спрашивают, где провести черту «достаточно хорошо» или когда запускать вмешательство, — в итоге всё равно принимая бинарное решение.

Напротив, бинарная оценка «прошёл/не прошёл» заставляет оценщиков принять чёткое суждение: достиг ли этот результат своей цели или нет? Эта ясность распространяется и на измерение прогресса — увеличение доли прошедших на 10% сразу имеет смысл, тогда как улучшение на 0,5 балла по пятибалльной шкале требует интерпретации.

Я заметил, что команды, которые сопротивляются бинарной оценке, часто делают это из желания сохранить нюансы. Но нюансы не теряются — они просто перемещаются в качественную критику, сопровождающую суждение. Критика даёт богатый контекст о том, почему что-то прошло или не прошло, и какие конкретные аспекты можно улучшить, в то время как бинарное решение создаёт практическую ясность о том, нужно ли вообще улучшение.

2. Дополняйте бинарные суждения детальными критиками

Хотя бинарные решения обеспечивают ясность, они работают лучше всего в сочетании с детальными критиками, которые фиксируют нюансы того, почему что-то прошло или не прошло. Такая комбинация даёт лучшее из обоих миров: чёткие, практически применимые метрики и богатое контекстное понимание.

Например, при оценке ответа, который правильно отвечает на вопрос пользователя, но содержит лишнюю информацию, хорошая критика может выглядеть так:

«AI успешно предоставил запрошенный анализ рынка (PASS), но включил чрезмерные подробности о демографии района, не относящиеся к инвестиционному вопросу. Это делает ответ длиннее необходимого и потенциально отвлекающим.»

Эти критики выполняют множество функций помимо объяснения. Они заставляют доменных экспертов формализовать неявные знания — я видел, как юристы переходили от смутного ощущения, что что-то «звучит не так», к формулировке конкретных проблем с форматами цитирования или паттернами рассуждений, которые можно системно исправить.

При включении в качестве примеров в промпты для LLM-судей эти критики улучшают способность LLM рассуждать о сложных граничных случаях. По моему опыту, такой подход часто даёт на 15–20% более высокий уровень согласия между человеческой и LLM-оценкой по сравнению с промптами без примеров критик. Критики также служат отличным сырьём для генерации качественных синтетических данных, создавая маховик улучшений.

3. Измеряйте согласованность автоматических оценок с человеческим суждением

Если вы используете LLM для оценки результатов (что часто необходимо при масштабировании), крайне важно регулярно проверять, насколько хорошо эти автоматические оценки совпадают с человеческим суждением.

Это особенно важно с учётом нашей естественной склонности чрезмерно доверять AI-системам. Как отмечают Shankar et al. в статье «Who Validates the Validators?», отсутствие инструментов для валидации качества оценщиков вызывает беспокойство:

«Исследования показывают, что люди склонны к чрезмерной зависимости от AI-систем и чрезмерному доверию к ним. Например, в одном громком инциденте исследователи из MIT опубликовали препринт на arXiv, утверждая, что GPT-4 может сдать экзамен MIT EECS на отлично. В течение нескольких часов работа [была] опровергнута… с указанием на проблемы, вызванные чрезмерной зависимостью от GPT-4 для оценки самой себя.»

Проблема чрезмерного доверия выходит за рамки самооценки. Исследования показали, что LLM могут быть подвержены влиянию таких простых факторов, как порядок вариантов в наборе, или даже на первый взгляд безобидных изменений форматирования в промптах. Без строгой человеческой валидации эти предвзятости могут незаметно подрывать вашу систему оценки.

Работая с Honeycomb, мы отслеживали уровень согласия между нашим LLM-судьёй и оценками Phillip:

Потребовалось три итерации, чтобы достичь более 90% согласия, но эта инвестиция окупилась системой, которой команда могла доверять. Без этого шага валидации автоматические оценки со временем часто расходятся с человеческими ожиданиями, особенно по мере изменения распределения входных данных. Подробнее об этом можно прочитать здесь.

Такие инструменты, как AlignEval Юджина Яна, прекрасно демонстрируют этот процесс выравнивания. Они предоставляют простой интерфейс, где вы загружаете данные, размечаете примеры бинарно — «хорошо» или «плохо» — а затем оцениваете LLM-судей по этим человеческим суждениям. Эффективность в том, как инструмент упрощает рабочий процесс — вы быстро видите, где автоматические оценки расходятся с вашими предпочтениями, уточняете критерии на основе этих наблюдений и измеряете улучшения со временем. Этот подход подтверждает, что выравнивание — не одноразовая настройка, а непрерывный диалог между человеческим суждением и автоматической оценкой.

Масштабирование без потери доверия

По мере роста вашей AI-системы вы неизбежно столкнётесь с давлением сократить человеческие усилия в оценке. Именно здесь многие команды ошибаются — они автоматизируют слишком много и слишком быстро, теряя человеческую связь, которая держит их оценки на земле.

Самые успешные команды выбирают более взвешенный подход:

Начинайте с высокой вовлечённости человека: на ранних стадиях привлекайте доменных экспертов для оценки значительной доли результатов. Изучайте паттерны согласованности: вместо автоматизации оценки сосредоточьтесь на понимании, где автоматические оценки совпадают с человеческим суждением, а где расходятся. Это помогает определить, какие типы случаев требуют более тщательного внимания человека. Используйте стратегическую выборку: вместо оценки каждого результата применяйте статистические методы для выборки наиболее информативных результатов, особенно фокусируясь на областях с наименьшей согласованностью. Поддерживайте регулярную калибровку: даже при масштабировании продолжайте регулярно сравнивать автоматические оценки с человеческим суждением, используя эти сравнения для уточнения понимания, когда можно доверять автоматическим оценкам.

Масштабирование оценки — это не просто сокращение человеческих усилий, а направление этих усилий туда, где они приносят наибольшую пользу. Фокусируя внимание человека на самых сложных или информативных случаях, вы можете поддерживать качество даже при росте системы.

Теперь, когда мы рассмотрели, как поддерживать доверие к оценкам, давайте поговорим о фундаментальном сдвиге в подходе к роадмапам AI-разработки…

6. Ваш AI-роадмап должен считать эксперименты, а не фичи

Если вы работали в разработке ПО, вы знакомы с традиционными роадмапами: список фич с целевыми датами поставки. Команды обязуются выпустить конкретную функциональность к конкретным дедлайнам, и успех измеряется тем, насколько точно они попали в эти цели.

Такой подход катастрофически проваливается в AI.

Я наблюдал, как команды брали на себя обязательства по роадмапам вроде «Запустить анализ тональности к Q2» или «Развернуть агентную систему клиентской поддержки к концу года», только чтобы обнаружить, что технология просто не готова соответствовать их планке качества. Они либо выпускали что-то посредственное, чтобы уложиться в дедлайн, либо полностью промахивались по срокам. В обоих случаях доверие подрывалось.

Фундаментальная проблема в том, что традиционные роадмапы предполагают, что мы знаем, что возможно. В традиционном ПО это часто так — при достаточном времени и ресурсах вы можете надёжно построить большинство фич. В AI, особенно на переднем крае, вы постоянно проверяете границы возможного.

Эксперименты против фич

Bryan Bischof, бывший руководитель AI в Hex, познакомил меня с тем, что он называет подходом «воронки возможностей» к AI-роадмапам. Эта стратегия переосмысливает то, как мы оцениваем прогресс в AI-разработке.

Вместо определения успеха как выпуска фичи, воронка возможностей разбивает производительность AI на прогрессивные уровни полезности. Наверху воронки — самая базовая функциональность: может ли система вообще ответить? Внизу — полное решение задачи пользователя. Между этими точками — различные стадии нарастающей полезности.

Например, в ассистенте для запросов воронка возможностей может выглядеть так: 1. Может генерировать синтаксически валидные запросы (базовая функциональность) 2. Может генерировать запросы, которые выполняются без ошибок 3. Может генерировать запросы, возвращающие релевантные результаты 4. Может генерировать запросы, соответствующие намерению пользователя 5. Может генерировать оптимальные запросы, решающие задачу пользователя (полное решение)

Такой подход признаёт, что прогресс в AI не бинарен — это постепенное улучшение возможностей по множеству измерений. Он также предоставляет фреймворк для измерения прогресса, даже когда конечная цель ещё не достигнута.

Самые успешные команды, с которыми я работал, строят свои роадмапы вокруг экспериментов, а не фич. Вместо обязательств по конкретным результатам они обязуются поддерживать ритм экспериментирования, обучения и итераций.

Eugene Yan, прикладной исследователь в Amazon, рассказал, как он подходит к планированию ML-проектов для руководства — процесс, который, хотя и был изначально разработан для традиционного машинного обучения, прекрасно применим к современной LLM-разработке:

«Вот типичный таймлайн. Сначала я беру две недели на анализ осуществимости данных, то есть «есть ли у меня правильные данные?» [...] Затем я беру ещё месяц на анализ технической осуществимости, то есть «может ли AI это решить?» После этого, если всё ещё работает, я трачу шесть недель на создание прототипа, который мы можем A/B-тестировать.»

Хотя LLM могут не требовать такой же разработки признаков или обучения модели, как традиционное ML, основополагающий принцип остаётся тем же: ограничивайте исследование по времени, устанавливайте чёткие точки принятия решений и сосредоточьтесь на доказательстве осуществимости до полной реализации. Такой подход даёт руководству уверенность, что ресурсы не будут потрачены на бесконечное исследование, при этом давая команде свободу учиться и адаптироваться по ходу дела.

Фундамент: инфраструктура оценки

Ключ к работе роадмапа, основанного на экспериментах, — наличие надёжной инфраструктуры оценки. Без неё вы просто гадаете, работают ли ваши эксперименты. С ней вы можете быстро итерировать, проверять гипотезы и развивать успехи.

Я видел это воочию на ранних этапах разработки GitHub Copilot. Большинство людей не осознают, что команда вложила значительные усилия в создание сложной инфраструктуры офлайн-оценки. Они создали системы, которые могли тестировать автодополнения кода на очень большом корпусе репозиториев GitHub, используя уже существующие юнит-тесты в качественных кодовых базах как автоматический способ верификации корректности дополнений. Это было масштабное инженерное начинание — нужно было создать системы для клонирования репозиториев в масштабе, настройки их окружений, запуска тестовых наборов и анализа результатов при невероятном разнообразии языков программирования, фреймворков и подходов к тестированию.

Это время не было потрачено зря — это был фундамент, ускоривший всё остальное. С надёжной оценкой на месте команда проводила тысячи экспериментов, быстро определяла, что работает, и могла с уверенностью сказать «это изменение улучшило качество на X%», а не полагаться на интуицию. Хотя начальные инвестиции в оценку кажутся медленными, они предотвращают бесконечные споры о том, помогают ли изменения или вредят, и кардинально ускоряют инновации в дальнейшем.

Коммуникация со стейкхолдерами

Сложность, конечно, в том, что руководители часто хотят определённости. Они хотят знать, когда фичи будут выпущены и что они будут делать. Как преодолеть этот разрыв?

Ключ — сместить разговор с выходов на результаты. Вместо обещания конкретных фич к конкретным датам, обязуйтесь поддерживать процесс, который максимизирует шансы достижения желаемых бизнес-результатов.

Eugene рассказал, как он ведёт такие разговоры:

«Я стараюсь успокоить руководство временными рамками. По итогам трёх месяцев, если всё получится, мы переводим в продакшн. На любом этапе, если не получается, мы разворачиваемся.»

Такой подход даёт стейкхолдерам чёткие точки принятия решений, при этом признавая неотъемлемую неопределённость AI-разработки. Он также помогает управлять ожиданиями по срокам — вместо обещания фичи через шесть месяцев вы обещаете чёткое понимание, осуществима ли эта фича, через три месяца.

Подход Bryan с воронкой возможностей предоставляет ещё один мощный инструмент коммуникации. Он позволяет командам показывать конкретный прогресс по стадиям воронки, даже когда финальное решение ещё не готово. Он также помогает руководителям понять, где возникают проблемы, и принять обоснованные решения о распределении ресурсов.

Формируйте культуру экспериментирования через открытое обсуждение неудач

Пожалуй, самый контринтуитивный аспект этого подхода — акцент на обучении на неудачах. В традиционной разработке ПО неудачи часто скрывают или преуменьшают. В AI-разработке они — главный источник обучения.

Eugene реализует это в своей организации через так называемый «fifteen-five» — еженедельный отчёт, который занимает пятнадцать минут на написание и пять минут на чтение:

«В своих fifteen-five я документирую свои неудачи и успехи. В нашей команде у нас также есть еженедельные "сессии обмена опытом без подготовки", где мы обсуждаем, над чем работали и что узнали. Когда я это делаю, я намеренно делюсь неудачами.»

Такая практика нормализует неудачу как часть процесса обучения. Она показывает, что даже опытные специалисты встречают тупики, и ускоряет обучение команды за счёт открытого обмена этим опытом. А празднуя процесс экспериментирования, а не только результаты, команды создают среду, в которой люди чувствуют себя в безопасности, рискуя и учась на неудачах.

Лучший путь вперёд

Так как выглядит роадмап на основе экспериментов на практике? Вот упрощённый пример из проекта по модерации контента, над которым работал Eugene:

«Меня попросили заняться модерацией контента. Я сказал: "Неясно, достигнем ли мы этой цели. Неясно даже, осуществима ли эта цель с нашими данными, или какие техники машинного обучения сработают. Но вот мой роадмап экспериментов. Вот техники, которые я попробую, и я буду отчитываться каждые две недели".»

Роадмап не обещал конкретных фич или возможностей. Вместо этого он обязывал к систематическому исследованию возможных подходов с регулярными точками оценки прогресса и разворота при необходимости.

Результаты были показательными:

«Первые два-три месяца ничего не работало. [...] А затем [случился прорыв]. [...] В течение месяца проблема была решена. Видите — в первом квартале или даже четыре месяца всё шло в никуда. [...] Но затем вдруг появляется какая-то новая технология, какая-то новая парадигма, какое-то новое переосмысление, которое просто [решает] 80% [проблемы].»

Такой паттерн — длительные периоды кажущихся неудач, сменяющиеся прорывами, — типичен для AI-разработки. Традиционные фичевые роадмапы закрыли бы проект после месяцев «неудач», пропустив итоговый прорыв.

Фокусируясь на экспериментах, а не на фичах, команды создают пространство для появления таких прорывов. Они также выстраивают инфраструктуру и процессы, которые делают прорывы более вероятными — конвейеры данных, фреймворки оценки и циклы быстрых итераций.

Самые успешные команды, с которыми я работал, начинают с создания инфраструктуры оценки до принятия обязательств по конкретным фичам. Они создают инструменты, ускоряющие итерации, и фокусируются на процессах, поддерживающих быстрое экспериментирование. Такой подход может казаться медленнее поначалу, но кардинально ускоряет разработку в долгосрочной перспективе, позволяя командам быстро учиться и адаптироваться.

Ключевая метрика для AI-роадмапов — не выпущенные фичи, а проведённые эксперименты. Побеждают те команды, которые могут проводить больше экспериментов, учиться быстрее и итерировать более оперативно, чем конкуренты. И фундамент для такого быстрого экспериментирования всегда один: надёжная, проверенная инфраструктура оценки, дающая всем уверенность в результатах.

Переосмыслив свой роадмап вокруг экспериментов, а не фич, вы создаёте условия для аналогичных прорывов в собственной организации.

Заключение

В этом посте я поделился паттернами, которые наблюдал в десятках AI-внедрений. Самые успешные команды — не те, у кого самые продвинутые инструменты или самые совершенные модели, а те, кто освоил основы измерения, итерации и обучения.

Ключевые принципы удивительно просты:

Смотрите на свои данные. Ничто не заменит инсайты, полученные из изучения реальных примеров. Анализ ошибок стабильно выявляет наиболее окупаемые улучшения. Создавайте простые инструменты, устраняющие трение. Кастомные просмотрщики данных, упрощающие изучение выходных данных AI, дают больше инсайтов, чем сложные дашборды с обобщёнными метриками. Расширяйте полномочия доменных экспертов. Люди, которые лучше всего разбираются в вашей предметной области, часто способны наиболее эффективно улучшить ваш AI, независимо от их технического бэкграунда. Используйте синтетические данные стратегически. Вам не нужны реальные пользователи, чтобы начать тестировать и улучшать AI. Продуманно сгенерированные синтетические данные могут запустить процесс оценки. Поддерживайте доверие к оценкам. Бинарные суждения с детальными критиками создают ясность, сохраняя нюансы. Регулярные проверки согласованности обеспечивают надёжность автоматических оценок. Стройте роадмапы вокруг экспериментов, а не фич. Обязуйтесь поддерживать ритм экспериментирования и обучения, а не конкретные результаты к конкретным датам.

Эти принципы применимы независимо от вашей предметной области, размера команды или технического стека. Они работали для компаний от ранних стартапов до технологических гигантов, в кейсах от клиентской поддержки до генерации кода.

Ресурсы для углублённого изучения

Если вы хотите глубже изучить эти темы, вот несколько ресурсов, которые могут помочь:

Мой блог с дополнительным контентом об оценке и улучшении AI. Другие мои посты подробнее раскрывают такие темы, как создание эффективных LLM-судей, внедрение систем оценки и другие аспекты AI-разработки1. Также обратите внимание на блоги Shreya Shankar и Eugene Yan, которые тоже являются отличными источниками информации по этим темам. Курс, который я веду: Rapidly Improve AI Products With Evals, совместно с Shreya Shankar. Курс даёт практический опыт работы с такими техниками, как анализ ошибок, генерация синтетических данных и создание надёжных систем оценки. Он включает практические упражнения и персонализированное обучение через офисные часы. Если вы ищете практическое руководство, адаптированное к потребностям вашей организации, вы можете узнать больше о сотрудничестве со мной на Parlance Labs.

Сноски

Я пишу шире о машинном обучении, AI и разработке ПО. Некоторые посты, развивающие эти темы, включают Your AI Product Needs Evals, Creating a LLM-as-a-Judge That Drives Business Results и What We've Learned From A Year of Building with LLMs. Все мои посты можно найти на hamel.dev.↩︎

A Field Guide to Rapidly Improving AI Products – Hamel’s Blog - Hamel Husain