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

Most AI teams focus on the wrong things. Here’s a common scene from my consulting work:

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

Here’s our agent architecture – we’ve got RAG here, a router there, and we’re using this new framework for…

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

“Can you show me how you’re measuring if any of this actually works?”

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

This scene has played out dozens of times over the last two years. Teams invest weeks building complex AI systems, but can’t tell me if their changes are helping or hurting.

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

This isn’t surprising. With new tools and frameworks emerging weekly, it’s natural to focus on tangible things we can control – which vector database to use, which LLM provider to choose, which agent framework to adopt. But after helping 30+ companies build AI products, I’ve discovered the teams who succeed barely talk about tools at all. Instead, they obsess over measurement and iteration.

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

In this post, I’ll show you exactly how these successful teams operate. You’ll learn:

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

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

I’ll explain each of these topics with real examples. While every situation is unique, you’ll see patterns that apply regardless of your domain or team size.

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

Let’s start by examining the most common mistake I see teams make – one that derails AI projects before they even begin.

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

1. The Most Common Mistake: Skipping Error Analysis

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

The “tools first” mindset is the most common mistake in AI development. Teams get caught up in architecture diagrams, frameworks, and dashboards while neglecting the process of actually understanding what’s working and what isn’t.

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

One client proudly showed me this evaluation dashboard:

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

This is the “tools trap” – the belief that adopting the right tools or frameworks (in this case, generic metrics) will solve your AI problems. Generic metrics are worse than useless – they actively impede progress in two ways:

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

First, they create a false sense of measurement and progress. Teams think they’re data-driven because they have dashboards, but they’re tracking vanity metrics that don’t correlate with real user problems. I’ve seen teams celebrate improving their “helpfulness score” by 10% while their actual users were still struggling with basic tasks. It’s like optimizing your website’s load time while your checkout process is broken – you’re getting better at the wrong thing.

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

Second, too many metrics fragment your attention. Instead of focusing on the few metrics that matter for your specific use case, you’re trying to optimize multiple dimensions simultaneously. When everything is important, nothing is.

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

The alternative? Error analysis - the single most valuable activity in AI development and consistently the highest-ROI activity. Let me show you what effective error analysis looks like in practice.

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

The Error Analysis Process

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

When Jacob, the founder of Nurture Boss, needed to improve their apartment-industry AI assistant, his team built a simple viewer to examine conversations between their AI and users. Next to each conversation was a space for open-ended notes about failure modes.

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

After annotating dozens of conversations, clear patterns emerged. Their AI was struggling with date handling – failing 66% of the time when users said things like “let’s schedule a tour two weeks from now.”

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

Instead of reaching for new tools, they: 1. Looked at actual conversation logs 2. Categorized the types of date-handling failures 3. Built specific tests to catch these issues 4. Measured improvement on these metrics

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

The result? Their date handling success rate improved from 33% to 95%.

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

Here’s Jacob explaining this process himself:

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

Bottom-Up vs. Top-Down Analysis

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

When identifying error types, you can take either a “top-down” or “bottom-up” approach.

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

The top-down approach starts with common metrics like “hallucination” or “toxicity” plus metrics unique to your task. While convenient, it often misses domain-specific issues.

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

The more effective bottom-up approach forces you to look at actual data and let metrics naturally emerge. At NurtureBoss, we started with a spreadsheet where each row represented a conversation. We wrote open-ended notes on any undesired behavior. Then we used an LLM to build a taxonomy of common failure modes. Finally, we mapped each row to specific failure mode labels and counted the frequency of each issue.

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

The results were striking - just three issues accounted for over 60% of all problems:

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

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

The impact was immediate. Jacob’s team had uncovered so many actionable insights that they needed several weeks just to implement fixes for the problems we’d already found.

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

If you’d like to see error analysis in action, we recorded a live walkthrough here.

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

This brings us to a crucial question: How do you make it easy for teams to look at their data? The answer leads us to what I consider the most important investment any AI team can make…

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

2. The Most Important AI Investment: A Simple Data Viewer

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

The single most impactful investment I’ve seen AI teams make isn’t a fancy evaluation dashboard – it’s building a customized interface that lets anyone examine what their AI is actually doing. I emphasize customized because every domain has unique needs that off-the-shelf tools rarely address. When reviewing apartment leasing conversations, you need to see the full chat history and scheduling context. For real estate queries, you need the property details and source documents right there. Even small UX decisions – like where to place metadata or which filters to expose – can make the difference between a tool people actually use and one they avoid.

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

I’ve watched teams struggle with generic labeling interfaces, hunting through multiple systems just to understand a single interaction. The friction adds up: clicking through to different systems to see context, copying error descriptions into separate tracking sheets, switching between tools to verify information. This friction doesn’t just slow teams down – it actively discourages the kind of systematic analysis that catches subtle issues.

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

Teams with thoughtfully designed data viewers iterate 10x faster than those without them. And here’s the thing: these tools can be built in hours using AI-assisted development (like Cursor or Loveable). The investment is minimal compared to the returns.

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

Let me show you what I mean. Here’s the data viewer built for NurtureBoss (which we discussed earlier):

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

Here’s what makes a good data annotation tool:

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

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

It doesn’t matter what web frameworks you use - use whatever you are familiar with. Because I’m a python developer, my current favorite web framework is FastHTML coupled with MonsterUI, because it allows me to define the back-end and front-end code in one small python file.

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

The key is starting somewhere, even if it’s simple. I’ve found custom web apps provide the best experience, but if you’re just beginning, a spreadsheet is better than nothing. As your needs grow, you can evolve your tools accordingly.

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

This brings us to another counter-intuitive lesson: the people best positioned to improve your AI system are often the ones who know the least about AI.

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

3. Empower Domain Experts To Write Prompts

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

I recently worked with an education startup building an interactive learning platform with LLMs. Their product manager, a learning design expert, would create detailed PowerPoint decks explaining pedagogical principles and example dialogues. She’d present these to the engineering team, who would then translate her expertise into prompts.

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

But here’s the thing: prompts are just English. Having a learning expert communicate teaching principles through PowerPoint, only for engineers to translate that back into English prompts, created unnecessary friction. The most successful teams flip this model by giving domain experts tools to write and iterate on prompts directly.

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

Build Bridges, Not Gatekeepers

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

Prompt playgrounds are a great starting point for this. Tools like Arize, Langsmith and Braintrust let teams quickly test different prompts, feed in example datasets, and compare results. Here are some screenshots of these tools:

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

But there’s a crucial next step that many teams miss: integrating prompt development into their application context. Most AI applications aren’t just prompts – They commonly involve RAG systems pulling from your knowledge base, agent orchestration coordinating multiple steps, and application-specific business logic. The most effective teams I’ve worked with go beyond standalone playgrounds. They build what I call integrated prompt environments – essentially admin versions of their actual user interface that expose prompt editing.

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

Here’s an illustration of what an integrated prompt environment might look like for a real estate AI assistant:

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

Tips For Communicating With Domain Experts

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

There’s another barrier that often prevents domain experts from contributing effectively: unnecessary jargon. I was working with an education startup where engineers, product managers, and learning specialists were talking past each other in meetings. The engineers kept saying, “We’re going to build an agent that does XYZ,” when really the job to be done was writing a prompt. This created an artificial barrier – the learning specialists, who were the actual domain experts, felt like they couldn’t contribute because they didn’t understand “agents.”

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

This happens everywhere. I’ve seen it with lawyers at legal tech companies, psychologists at mental health startups, and doctors at healthcare firms. The magic of LLMs is that they make AI accessible through natural language, but we often destroy that advantage by wrapping everything in technical terminology.

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

Here’s a simple example of how to translate common AI jargon:

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

This doesn’t mean dumbing things down – it means being precise about what you’re actually doing. When you say “we’re building an agent,” what specific capability are you adding? Is it function calling? Tool use? Or just a better prompt? Being specific helps everyone understand what’s actually happening.

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

There’s nuance here. Technical terminology exists for a reason – it provides precision when talking with other technical stakeholders. The key is adapting your language to your audience.

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

The challenge many teams raise at this point is: “This all sounds great, but what if we don’t have any data yet? How can we look at examples or iterate on prompts when we’re just starting out?” That’s what we’ll talk about next.

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

4. Bootstrapping Your AI With Synthetic Data Is Effective (Even With Zero Users)

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

One of the most common roadblocks I hear from teams is: “We can’t do proper evaluation because we don’t have enough real user data yet.” This creates a chicken-and-egg problem – you need data to improve your AI, but you need a decent AI to get users who generate that data.

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

Fortunately, there’s a solution that works surprisingly well: synthetic data. LLMs can generate realistic test cases that cover the range of scenarios your AI will encounter.

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

As I wrote in my LLM-as-a-Judge blog post, synthetic data can be remarkably effective for evaluation. Bryan Bischof, the former Head of AI at Hex, put it perfectly:

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

“LLMs are surprisingly good at generating excellent - and diverse - examples of user prompts. This can be relevant for powering application features, and sneakily, for building Evals. If this sounds a bit like the Large Language Snake is eating its tail, I was just as surprised as you! All I can say is: it works, ship it.”

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

A Framework for Generating Realistic Test Data

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

The key to effective synthetic data is choosing the right dimensions to test. While these dimensions will vary based on your specific needs, I find it helpful to think about three broad categories:

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

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

These aren’t the only dimensions you might care about – you might also want to test different tones of voice, levels of technical sophistication, or even different locales and languages. The important thing is identifying dimensions that matter for your specific use case.

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

For a real estate CRM AI assistant I worked on with Rechat, we defined these dimensions like this:

Для 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 ]

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" # Имеет специфические требования к району/школам ]

But having these dimensions defined is only half the battle. The real challenge is ensuring your synthetic data actually triggers the scenarios you want to test. This requires two things:

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

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

For Rechat, we maintained a test database of listings that we knew would trigger different edge cases. Some teams prefer to use an anonymized copy of production data, but either way, you need to ensure your test data has enough variety to exercise the scenarios you care about.

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

Here’s an example of how we might use these dimensions with real data to generate test cases for the property search feature (this is just pseudo-code, and very illustrative):

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

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)

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)

This produced realistic queries like:

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

The key to useful synthetic data is grounding it in real system constraints. For the real-estate AI assistant, this means:

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

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

We then feed these test cases through Lucy and log the interactions. This gives us a rich dataset to analyze, showing exactly how the AI handles different situations with real system constraints. This approach helped us fix issues before they affected real users.

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

Sometimes you don’t have access to a production database, especially for new products. In these cases, use LLMs to generate both test queries and the underlying test data. For a real estate AI assistant, this might mean creating synthetic property listings with realistic attributes – prices that match market ranges, valid addresses with real street names, and amenities appropriate for each property type. The key is grounding synthetic data in real-world constraints to make it useful for testing. The specifics of generating robust synthetic databases are beyond the scope of this post.

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

Guidelines for Using Synthetic Data

Рекомендации по использованию синтетических данных

When generating synthetic data, follow these key principles to ensure it’s effective:

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

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

This approach isn’t just theoretical – it’s been proven in production across dozens of companies. What often starts as a stopgap measure becomes a permanent part of the evaluation infrastructure, even after real user data becomes available.

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

Let’s look at how to maintain trust in your evaluation system as you scale…

Давайте посмотрим, как поддерживать доверие к системе оценки по мере масштабирования…

5. Maintaining Trust In Evals Is Critical

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

This is a pattern I’ve seen repeatedly: teams build evaluation systems, then gradually lose faith in them. Sometimes it’s because the metrics don’t align with what they observe in production. Other times, it’s because the evaluations become too complex to interpret. Either way, the result is the same – the team reverts to making decisions based on gut feeling and anecdotal feedback, undermining the entire purpose of having evaluations.

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

Maintaining trust in your evaluation system is just as important as building it in the first place. Here’s how the most successful teams approach this challenge:

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

Understanding Criteria Drift

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

One of the most insidious problems in AI evaluation is “criteria drift” – a phenomenon where evaluation criteria evolve as you observe more model outputs. In their paper “Who Validates the Validators?”, Shankar et al. describe this phenomenon:

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

“To grade outputs, people need to externalize and define their evaluation criteria; however, the process of grading outputs helps them to define that very criteria.”

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

This creates a paradox: you can’t fully define your evaluation criteria until you’ve seen a wide range of outputs, but you need criteria to evaluate those outputs in the first place. In other words, it is impossible to completely determine evaluation criteria prior to human judging of LLM outputs.

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

I’ve observed this firsthand when working with Phillip Carter at Honeycomb on their Query Assistant feature. As we evaluated the AI’s ability to generate database queries, Phillip noticed something interesting:

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

“Seeing how the LLM breaks down its reasoning made me realize I wasn’t being consistent about how I judged certain edge cases.”

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

The process of reviewing AI outputs helped him articulate his own evaluation standards more clearly. This isn’t a sign of poor planning – it’s an inherent characteristic of working with AI systems that produce diverse and sometimes unexpected outputs.

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

The teams that maintain trust in their evaluation systems embrace this reality rather than fighting it. They treat evaluation criteria as living documents that evolve alongside their understanding of the problem space. They also recognize that different stakeholders might have different (sometimes contradictory) criteria, and they work to reconcile these perspectives rather than imposing a single standard.

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

Creating Trustworthy Evaluation Systems

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

So how do you build evaluation systems that remain trustworthy despite criteria drift? Here are the approaches I’ve found most effective:

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

1. Favor Binary Decisions Over Arbitrary Scales

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

As I wrote in my LLM-as-a-Judge post, binary decisions provide clarity that more complex scales often obscure. When faced with a 1-5 scale, evaluators frequently struggle with the difference between a 3 and a 4, introducing inconsistency and subjectivity. What exactly distinguishes “somewhat helpful” from “helpful”? These boundary cases consume disproportionate mental energy and create noise in your evaluation data. And even when businesses use a 1-5 scale, they inevitably ask where to draw the line for “good enough” or to trigger intervention, forcing a binary decision anyway.

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

In contrast, a binary pass/fail forces evaluators to make a clear judgment: did this output achieve its purpose or not? This clarity extends to measuring progress – a 10% increase in passing outputs is immediately meaningful, while a 0.5-point improvement on a 5-point scale requires interpretation.

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

I’ve found that teams who resist binary evaluation often do so because they want to capture nuance. But nuance isn’t lost – it’s just moved to the qualitative critique that accompanies the judgment. The critique provides rich context about why something passed or failed, and what specific aspects could be improved, while the binary decision creates actionable clarity about whether improvement is needed at all.

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

2. Enhance Binary Judgments With Detailed Critiques

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

While binary decisions provide clarity, they work best when paired with detailed critiques that capture the nuance of why something passed or failed. This combination gives you the best of both worlds: clear, actionable metrics and rich contextual understanding.

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

For example, when evaluating a response that correctly answers a user’s question but contains unnecessary information, a good critique might read:

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

“The AI successfully provided the market analysis requested (PASS), but included excessive detail about neighborhood demographics that wasn’t relevant to the investment question. This makes the response longer than necessary and potentially distracting.”

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

These critiques serve multiple functions beyond just explanation. They force domain experts to externalize implicit knowledge – I’ve seen legal experts move from vague feelings that something “doesn’t sound right” to articulating specific issues with citation formats or reasoning patterns that can be systematically addressed.

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

When included as few-shot examples in judge prompts, these critiques improve the LLM’s ability to reason about complex edge cases. I’ve found this approach often yields 15-20% higher agreement rates between human and LLM evaluations compared to prompts without example critiques. The critiques also provide excellent raw material for generating high-quality synthetic data, creating a flywheel for improvement.

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

3. Measure Alignment Between Automated Evals and Human Judgment

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

If you’re using LLMs to evaluate outputs (which is often necessary at scale), it’s crucial to regularly check how well these automated evaluations align with human judgment.

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

This is particularly important given our natural tendency to over-trust AI systems. As Shankar et al. note in “Who Validates the Validators?”, the lack of tools to validate evaluator quality is concerning

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

Research shows people tend to over-rely and over-trust AI systems. For instance, in one high profile incident, researchers from MIT posted a pre-print on arXiv claiming that GPT-4 could ace the MIT EECS exam. Within hours, [the] work [was] debunked … citing problems arising from over-reliance on GPT-4 to grade itself.”

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

This over-trust problem extends beyond self-evaluation. Research has shown that LLMs can be biased by simple factors like the ordering of options in a set, or even seemingly innocuous formatting changes in prompts. Without rigorous human validation, these biases can silently undermine your evaluation system.

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

When working with Honeycomb, we tracked agreement rates between our LLM-as-a-judge and Phillip’s evaluations:

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

It took three iterations to achieve >90% agreement, but this investment paid off in a system the team could trust. Without this validation step, automated evaluations often drift from human expectations over time, especially as the distribution of inputs changes. You can read more about this here.

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

Tools like Eugene Yan’s AlignEval demonstrate this alignment process beautifully. It provides a simple interface where you upload data, label examples with a binary “good” or “bad,” and then evaluate LLM-based judges against those human judgments. What makes it effective is how it streamlines the workflow – you can quickly see where automated evaluations diverge from your preferences, refine your criteria based on these insights, and measure improvement over time. This approach reinforces that alignment isn’t a one-time setup but an ongoing conversation between human judgment and automated evaluation.

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

Scaling Without Losing Trust

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

As your AI system grows, you’ll inevitably face pressure to reduce the human effort involved in evaluation. This is where many teams go wrong – they automate too much, too quickly, and lose the human connection that keeps their evaluations grounded.

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

The most successful teams take a more measured approach:

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

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

Scaling evaluation isn’t just about reducing human effort – it’s about directing that effort where it adds the most value. By focusing human attention on the most challenging or informative cases, you can maintain quality even as your system grows.

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

Now that we’ve covered how to maintain trust in your evaluations, let’s talk about a fundamental shift in how you should approach AI development roadmaps…

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

6. Your AI Roadmap Should Count Experiments, Not Features

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

If you’ve worked in software development, you’re familiar with traditional roadmaps: a list of features with target delivery dates. Teams commit to shipping specific functionality by specific deadlines, and success is measured by how closely they hit those targets.

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

This approach fails spectacularly with AI.

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

I’ve watched teams commit to roadmaps like “Launch sentiment analysis by Q2” or “Deploy agent-based customer support by end of year,” only to discover that the technology simply isn’t ready to meet their quality bar. They either ship something subpar to hit the deadline or miss the deadline entirely. Either way, trust erodes.

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

The fundamental problem is that traditional roadmaps assume we know what’s possible. With conventional software, that’s often true – given enough time and resources, you can build most features reliably. With AI, especially at the cutting edge, you’re constantly testing the boundaries of what’s feasible.

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

Experiments vs. Features

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

Bryan Bischof, Former Head of AI at Hex, introduced me to what he calls a “capability funnel” approach to AI roadmaps. This strategy reframes how we think about AI development progress.

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

Instead of defining success as shipping a feature, the capability funnel breaks down AI performance into progressive levels of utility. At the top of the funnel is the most basic functionality – can the system respond at all? At the bottom is fully solving the user’s job to be done. Between these points are various stages of increasing usefulness.

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

For example, in a query assistant, the capability funnel might look like: 1. Can generate syntactically valid queries (basic functionality) 2. Can generate queries that execute without errors 3. Can generate queries that return relevant results 4. Can generate queries that match user intent 5. Can generate optimal queries that solve the user’s problem (complete solution)

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

This approach acknowledges that AI progress isn’t binary – it’s about gradually improving capabilities across multiple dimensions. It also provides a framework for measuring progress even when you haven’t reached the final goal.

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

The most successful teams I’ve worked with structure their roadmaps around experiments rather than features. Instead of committing to specific outcomes, they commit to a cadence of experimentation, learning, and iteration.

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

Eugene Yan, an applied scientist at Amazon, shared how he approaches ML project planning with leadership - a process that, while originally developed for traditional machine learning, applies equally well to modern LLM development:

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

“Here’s a common timeline. First, I take two weeks to do a data feasibility analysis, i.e”do I have the right data?” […] Then I take an additional month to do a technical feasibility analysis, i.e “can AI solve this?” After that, if it still works I’ll spend six weeks building a prototype we can A/B test.”

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

While LLMs might not require the same kind of feature engineering or model training as traditional ML, the underlying principle remains the same: time-box your exploration, establish clear decision points, and focus on proving feasibility before committing to full implementation. This approach gives leadership confidence that resources won’t be wasted on open-ended exploration, while giving the team the freedom to learn and adapt as they go.

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

The Foundation: Evaluation Infrastructure

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

The key to making an experiment-based roadmap work is having robust evaluation infrastructure. Without it, you’re just guessing whether your experiments are working. With it, you can rapidly iterate, test hypotheses, and build on successes.

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

I saw this firsthand during the early development of GitHub Copilot. What most people don’t realize is that the team invested heavily in building sophisticated offline evaluation infrastructure. They created systems that could test code completions against a very large corpus of repositories on GitHub, leveraging unit tests that already existed in high-quality codebases as an automated way to verify completion correctness. This was a massive engineering undertaking – they had to build systems that could clone repositories at scale, set up their environments, run their test suites, and analyze the results, all while handling the incredible diversity of programming languages, frameworks, and testing approaches.

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

This wasn’t wasted time—it was the foundation that accelerated everything. With solid evaluation in place, the team ran thousands of experiments, quickly identified what worked, and could say with confidence “this change improved quality by X%” instead of relying on gut feelings. While the upfront investment in evaluation feels slow, it prevents endless debates about whether changes help or hurt, and dramatically speeds up innovation later.

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

Communicating This to Stakeholders

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

The challenge, of course, is that executives often want certainty. They want to know when features will ship and what they’ll do. How do you bridge this gap?

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

The key is to shift the conversation from outputs to outcomes. Instead of promising specific features by specific dates, commit to a process that will maximize the chances of achieving the desired business outcomes.

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

Eugene shared how he handles these conversations:

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

“I try to reassure leadership with timeboxes. At the end of three months, if it works out, then we move it to production. At any step of the way, if it doesn’t work out, we pivot.”

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

This approach gives stakeholders clear decision points while acknowledging the inherent uncertainty in AI development. It also helps manage expectations about timelines – instead of promising a feature in six months, you’re promising a clear understanding of whether that feature is feasible in three months.

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

Bryan’s capability funnel approach provides another powerful communication tool. It allows teams to show concrete progress through the funnel stages, even when the final solution isn’t ready. It also helps executives understand where problems are occurring and make informed decisions about where to invest resources.

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

Build a Culture of Experimentation Through Failure Sharing

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

Perhaps the most counterintuitive aspect of this approach is the emphasis on learning from failures. In traditional software development, failures are often hidden or downplayed. In AI development, they’re the primary source of learning.

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

Eugene operationalizes this at his organization through what he calls a “fifteen-five” – a weekly update that takes fifteen minutes to write and five minutes to read:

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

“In my fifteen-fives, I document my failures and my successes. Within our team, we also have weekly”no-prep sharing sessions” where we discuss what we’ve been working on and what we’ve learned. When I do this, I go out of my way to share failures.”

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

This practice normalizes failure as part of the learning process. It shows that even experienced practitioners encounter dead ends, and it accelerates team learning by sharing those experiences openly. And by celebrating the process of experimentation rather than just the outcomes, teams create an environment where people feel safe taking risks and learning from failures.

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

A Better Way Forward

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

So what does an experiment-based roadmap look like in practice? Here’s a simplified example from a content moderation project Eugene worked on:

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

“I was asked to do content moderation. I said, ‘It’s uncertain whether we’ll meet that goal. It’s uncertain even if that goal is feasible with our data, or what machine learning techniques would work. But here’s my experimentation roadmap. Here are the techniques I’m gonna try, and I’m gonna update you at a two-week cadence.’”

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

The roadmap didn’t promise specific features or capabilities. Instead, it committed to a systematic exploration of possible approaches, with regular check-ins to assess progress and pivot if necessary.

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

The results were telling:

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

“For the first two to three months, nothing worked. […] And then [a breakthrough] came out. […] Within a month, that problem was solved. So you can see that in the first quarter or even four months, it was going nowhere. […] But then you can also see that all of a sudden, some new technology comes along, some new paradigm, some new reframing comes along that just [solves] 80% of [the problem].”

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

This pattern – long periods of apparent failure followed by breakthroughs – is common in AI development. Traditional feature-based roadmaps would have killed the project after months of “failure,” missing the eventual breakthrough.

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

By focusing on experiments rather than features, teams create space for these breakthroughs to emerge. They also build the infrastructure and processes that make breakthroughs more likely – data pipelines, evaluation frameworks, and rapid iteration cycles.

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

The most successful teams I’ve worked with start by building evaluation infrastructure before committing to specific features. They create tools that make iteration faster and focus on processes that support rapid experimentation. This approach might seem slower at first, but it dramatically accelerates development in the long run by enabling teams to learn and adapt quickly.

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

The key metric for AI roadmaps isn’t features shipped – it’s experiments run. The teams that win are those that can run more experiments, learn faster, and iterate more quickly than their competitors. And the foundation for this rapid experimentation is always the same: robust, trusted evaluation infrastructure that gives everyone confidence in the results.

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

By reframing your roadmap around experiments rather than features, you create the conditions for similar breakthroughs in your own organization.

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

Conclusion

Заключение

Throughout this post, I’ve shared patterns I’ve observed across dozens of AI implementations. The most successful teams aren’t the ones with the most sophisticated tools or the most advanced models – they’re the ones that master the fundamentals of measurement, iteration, and learning.

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

The core principles are surprisingly simple:

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

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

These principles apply regardless of your domain, team size, or technical stack. They’ve worked for companies ranging from early-stage startups to tech giants, across use cases from customer support to code generation.

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

Resources for Going Deeper

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

If you’d like to explore these topics further, here are some resources that might help:

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

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

Footnotes

Сноски

Я пишу шире о машинном обучении, 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.↩︎