A Field Guide to Rapidly Improving AI Products

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процесс error analysis

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

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

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

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

Вот Jacob лично объясняет этот процесс:

Снизу вверх vs. сверху вниз

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

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

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

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

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

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

Если хотите увидеть error analysis в действии, мы записали прямой разбор здесь.

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

2. Важнейшая AI-инвестиция: простой data viewer

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

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

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

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

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

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

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

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

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

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

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

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

Стройте мосты, а не привратников

Хорошая отправная точка — prompt playground'ы. Инструменты вроде Arize, Langsmith и Braintrust позволяют командам быстро тестировать разные промпты, подавать примерные датасеты и сравнивать результаты. Вот несколько скриншотов этих инструментов:

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

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

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

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

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

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

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

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

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

4. Bootstrap AI на синтетических данных работает (даже при нуле пользователей)

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

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

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

«LLM на удивление хороши в генерации отличных — и разнообразных — примеров пользовательских промптов. Это может быть полезно для фич приложения, а ещё, что немного хитро, для построения Evals. Если это похоже на змею из Large Language Snake, которая ест свой хвост, — я был удивлён не меньше вашего! Всё, что я могу сказать: это работает, отправляйте в прод».

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

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

Features: какие возможности должен поддерживать ваш AI? Scenarios: какие ситуации он будет встречать? User Personas: кто будет им пользоваться и как?

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

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

features = [ "property search", # Finding listings matching criteria "market analysis", # Analyzing trends and pricing "scheduling", # Setting up property viewings "follow-up" # Post-viewing communication ] scenarios = [ "exact match", # One perfect listing match "multiple matches", # Need to help user narrow down "no matches", # Need to suggest alternatives "invalid criteria" # Help user correct search terms ] personas = [ "first_time_buyer", # Needs more guidance and explanation "investor", # Focused on numbers and ROI "luxury_client", # Expects white-glove service "relocating_family" # Has specific neighborhood/school needs ]

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

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

Для 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 объявлений и адреса из их базы Учитывать настоящие расписания и окна доступности агентов Соблюдать бизнес-правила вроде ограничений на показ и сроков уведомления Включать особенности рынка вроде требований HOA или местного регулирования

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

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

Принципы использования синтетических данных

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

Разнообразьте датасет: создавайте примеры, покрывающие широкий спектр фич, сценариев и персон. Как я писал в статье про LLM-as-a-Judge, такое разнообразие помогает находить краевые случаи и режимы сбоев, которых иначе вы могли бы не предусмотреть. Генерируйте пользовательские входы, а не выходы: используйте LLM для генерации реалистичных пользовательских запросов или входов, а не ожидаемых AI-ответов. Это не даёт вашим синтетическим данным унаследовать смещения или ограничения генерирующей модели. Учитывайте реальные ограничения системы: заземляйте синтетические данные в реальных ограничениях системы и реальных данных. Например, при тестировании функции планирования используйте настоящие окна доступности и правила бронирования. Проверяйте покрытие сценариев: убедитесь, что сгенерированные данные действительно запускают сценарии, которые вы хотите проверить. Запрос, придуманный для теста «совпадений не найдено», должен реально возвращать ноль результатов в вашей системе. Начинайте с простого, потом усложняйте: сначала простые тестовые кейсы, потом нюансы. Это помогает изолировать проблемы и установить базовый уровень до работы с краевыми случаями.

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

Посмотрим, как поддерживать доверие к evaluation-системе при масштабировании…

5. Поддерживать доверие к eval'ам критически важно

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

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

Понимание criteria drift

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

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

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

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

«Глядя, как LLM раскладывает своё рассуждение, я понял, что сам непоследовательно судил некоторые краевые случаи».

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

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

Создание систем оценки, которым можно доверять

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструменты вроде AlignEval от Eugene Yan прекрасно демонстрируют этот процесс согласования. Он даёт простой интерфейс, где вы загружаете данные, размечаете примеры бинарно «good»/«bad», а затем оцениваете LLM-судей против этих человеческих суждений. Эффективным его делает то, как он стримлайнит рабочий процесс — вы быстро видите, где автоматические оценки расходятся с вашими предпочтениями, уточняете критерии на основе этих инсайтов и измеряете улучшение со временем. Этот подход подкрепляет идею, что согласование — не разовая настройка, а постоянный диалог между человеческим суждением и автоматической оценкой.

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

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

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

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

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

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

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

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

Этот подход с треском проваливается в AI.

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

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

Эксперименты vs. фичи

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

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

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

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

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

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

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

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

Фундамент: evaluation-инфраструктура

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

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

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

Как доносить это до стейкхолдеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Смотрите на свои данные. Ничто не заменит инсайтов от изучения реальных примеров. Error analysis раз за разом выявляет улучшения с самым высоким ROI. Стройте простые инструменты, убирающие трение. Кастомные data viewer'ы, упрощающие изучение AI-выходов, дают больше инсайтов, чем сложные дашборды с универсальными метриками. Давайте полномочия доменным экспертам. Люди, лучше всех понимающие вашу область, часто способны эффективнее всех улучшать ваш AI, независимо от их технического бэкграунда. Используйте синтетические данные стратегически. Чтобы начать тестировать и улучшать AI, не нужны реальные пользователи. Продуманно сгенерированные синтетические данные могут забутстрапить процесс оценки. Поддерживайте доверие к вашим оценкам. Бинарные суждения с подробными критиками создают ясность, сохраняя нюанс. Регулярные проверки согласованности гарантируют, что автоматические оценки остаются заслуживающими доверия. Стройте дорожные карты вокруг экспериментов, а не фич. Берите на себя обязательство по каденсу экспериментирования и обучения, а не по конкретным результатам к конкретным датам.

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

Ресурсы для углубления

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

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

Сноски

Я пишу шире про machine learning, 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.↩︎