A Field Guide to Rapidly Improving AI Products

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:

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

Как error analysis раз за разом выявляет улучшения с самым высоким ROI Почему простой data viewer — это ваша важнейшая 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. Самая распространённая ошибка: пропуск error analysis

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:

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

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.

Во-первых, они создают ложное ощущение измерения и прогресса. Команды думают, что они data-driven, потому что у них есть дашборды, но они трекают тщеславные метрики, не коррелирующие с реальными проблемами пользователей. Я видел, как команды праздновали улучшение «helpfulness score» на 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.

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

The Error Analysis Process

Процесс error analysis

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

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

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.

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

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-инвестиция: простой data viewer

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-команд, — это не навороченный evaluation-дашборд, а кастомный интерфейс, который позволяет любому изучить, что на самом деле делает 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.

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

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

Покажу, что я имею в виду. Вот data viewer, построенный для 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:

Хорошая отправная точка — prompt playground'ы. Инструменты вроде 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-системы, тянущие данные из вашей базы знаний, оркестровка агентов, координирующая несколько шагов, и специфичная для приложения бизнес-логика. Самые эффективные команды, с которыми я работал, идут дальше отдельных playground'ов. Они строят то, что я называю интегрированными средами для промптов — по сути, админ-версии их реального пользовательского интерфейса, в которых открыто редактирование промптов.

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.

Это происходит везде. Я видел это у юристов в legal tech, у психологов в стартапах в области ментального здоровья, у врачей в медицинских компаниях. Магия 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.

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

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. Bootstrap 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-as-a-Judge, синтетические данные могут быть на удивление эффективны для оценки. Bryan Bischof, бывший Head of 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 на удивление хороши в генерации отличных — и разнообразных — примеров пользовательских промптов. Это может быть полезно для фич приложения, а ещё, что немного хитро, для построения Evals. Если это похоже на змею из Large Language Snake, которая ест свой хвост, — я был удивлён не меньше вашего! Всё, что я могу сказать: это работает, отправляйте в прод».

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:

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

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

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", # 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 ]

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

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-as-a-Judge, такое разнообразие помогает находить краевые случаи и режимы сбоев, которых иначе вы могли бы не предусмотреть. Генерируйте пользовательские входы, а не выходы: используйте 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.

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

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

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

5. Maintaining Trust In Evals Is Critical

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

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

Понимание 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-оценке — «criteria drift», явление, при котором критерии оценки эволюционируют по мере того, как вы наблюдаете всё больше выходов модели. В своей статье «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:

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

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-as-a-Judge, бинарные решения дают ту ясность, которую более сложные шкалы часто скрывают. Перед шкалой от 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.

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

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

3. Measure Alignment Between Automated Evals and Human Judgment

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

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-as-a-judge и оценками 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 от Eugene Yan прекрасно демонстрируют этот процесс согласования. Он даёт простой интерфейс, где вы загружаете данные, размечаете примеры бинарно «good»/«bad», а затем оцениваете 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.

Я наблюдал, как команды берут на себя обязательства вроде «Запустить sentiment analysis к 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

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

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, бывший Head of AI в Hex, познакомил меня с тем, что он называет подходом «capability funnel» к 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.

Вместо того чтобы определять успех как выпуск фичи, capability funnel разбивает производительность 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)

Например, для query-ассистента capability funnel может выглядеть так: 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, applied scientist в Amazon, рассказал, как он подходит к планированию ML-проектов с руководством — процесс, изначально разработанный для классического 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.”

«Вот типичный таймлайн. Сначала я беру две недели на data feasibility analysis, то есть «есть ли у меня нужные данные?» […] Затем я беру дополнительный месяц на technical feasibility analysis, то есть «может ли 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 могут не требовать такой же feature engineering или обучения моделей, как классический ML, базовый принцип тот же: задайте временные рамки для исследования, определите чёткие точки принятия решений и сфокусируйтесь на доказательстве выполнимости, прежде чем браться за полную реализацию. Такой подход даёт руководству уверенность, что ресурсы не будут потрачены на бесконечное исследование, а команде — свободу учиться и адаптироваться по ходу.

The Foundation: Evaluation Infrastructure

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

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.

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

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, используя уже существующие в качественных кодовых базах unit-тесты как автоматический способ верификации корректности дополнения. Это был колоссальный инженерный проект — им пришлось построить системы, способные клонировать репозитории в больших масштабах, поднимать их окружения, прогонять их тестовые наборы и анализировать результаты, и всё это с учётом огромного разнообразия языков программирования, фреймворков и подходов к тестированию.

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.

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

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.

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

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.

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

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

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.

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

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.

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

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

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:

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

Смотрите на свои данные. Ничто не заменит инсайтов от изучения реальных примеров. Error analysis раз за разом выявляет улучшения с самым высоким ROI. Стройте простые инструменты, убирающие трение. Кастомные data viewer'ы, упрощающие изучение 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. Курс даёт практический опыт по таким техникам, как error analysis, генерация синтетических данных и построение заслуживающих доверия систем оценки. В нём есть практические упражнения и персональные консультации через office hours. Если ищете персональное руководство под нужды вашей организации, узнать о работе со мной можно в Parlance Labs.

Footnotes

Сноски

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