Большинство команд, работающих над искусственным интеллектом, сосредотачиваются не на тех вещах. Вот распространённая сцена из моей консультационной практики:
**Команда ИИ:**
«Вот наша архитектура агента — у нас есть RAG здесь, маршрутизатор там, и мы используем этот новый фреймворк для…»
**Я:**
(Поднимая руку, чтобы остановить увлечённого технического руководителя)
«Можете показать, как вы измеряете, работает ли это вообще?»
…В комнате воцаряется тишина.
Эта сцена повторялась десятки раз за последние два года. Команды тратят недели на создание сложных систем ИИ, но не могут сказать, помогают ли их изменения или вредят.
Это неудивительно. С появлением новых инструментов и фреймворков каждую неделю естественно сосредотачиваться на осязаемых вещах, которые мы можем контролировать — какой векторной базе данных использовать, какого поставщика LLM выбрать, какой фреймворк для агента принять. Но после того как я помог более чем 30 компаниям создать продукты с ИИ, я обнаружил, что команды, которые добиваются успеха, почти не говорят об инструментах. Вместо этого они одержимы измерениями и итерациями.
В этой статье я покажу вам, как именно действуют успешные команды. Хотя каждая ситуация уникальна, вы увидите закономерности, которые применимы независимо от вашей области или размера команды. Начнём с наиболее распространённой ошибки, которую я вижу у команд, — той, которая срывает проекты с ИИ ещё до их начала.
### Наиболее распространённая ошибка: пропуск анализа ошибок
Склонность к «инструментам прежде всего» — самая распространённая ошибка в разработке ИИ. Команды увлекаются архитектурными диаграммами, фреймворками и панелями мониторинга, пренебрегая процессом реального понимания того, что работает, а что нет.
Один клиент с гордостью показал мне эту оценочную панель:
«Вид панели, предвещающий неудачу».
Это «ловушка инструментов» — убеждение, что использование правильных инструментов или фреймворков (в данном случае общих метрик) решит ваши проблемы с ИИ. Общие метрики не только бесполезны, но и активно препятствуют прогрессу двумя способами:
1. Они создают ложное ощущение измерения и прогресса. Команды думают, что они ориентированы на данные, потому что у них есть панели мониторинга, но они отслеживают показатели тщеславия, которые не коррелируют с реальными проблемами пользователей. Я видел, как команды праздновали повышение «показателя полезности» на 10%, в то время как их реальные пользователи всё ещё испытывали трудности с базовыми задачами. Это всё равно что оптимизировать время загрузки вашего сайта, пока процесс оформления заказа сломан — вы совершенствуетесь в неправильном деле.
2. Слишком много метрик фрагментируют ваше внимание. Вместо того чтобы сосредоточиться на нескольких показателях, которые важны для вашего конкретного случая использования, вы пытаетесь оптимизировать несколько параметров одновременно. Когда всё важно, ничего не важно.
Альтернатива? Анализ ошибок: самое ценное занятие в разработке ИИ и неизменно деятельность с наивысшей рентабельностью инвестиций. Позвольте мне показать вам, как выглядит эффективный анализ ошибок на практике.
### Процесс анализа ошибок
Когда Джейкобу, основателю Nurture Boss, нужно было улучшить ИИ-ассистента для индустрии аренды квартир, его команда создала простой просмотрщик для изучения разговоров между их ИИ и пользователями. Рядом с каждым разговором было место для открытых заметок о возможных сбоях.
После аннотирования десятков разговоров стали очевидны чёткие закономерности. Их ИИ испытывал трудности с обработкой дат — терпел неудачу в 66% случаев, когда пользователи говорили что-то вроде «Давайте запланируем экскурсию через две недели».
Вместо того чтобы искать новые инструменты, они:
* посмотрели на реальные журналы разговоров;
* классифицировали типы сбоев при обработке дат;
* создали специальные тесты для выявления этих проблем;
* измерили улучшение по этим показателям.
Результат? Успешность обработки дат улучшилась с 33% до 95%.
### Анализ ошибок снизу вверх и сверху вниз
При выявлении типов ошибок вы можете использовать либо подход «сверху вниз», либо «снизу вверх».
Подход «сверху вниз» начинается с общих метрик, таких как «галлюцинация» или «токсичность», а также метрик, уникальных для вашей задачи. Хотя это удобно, часто упускаются проблемы, специфичные для домена.
Более эффективный подход «снизу вверх» заставляет вас смотреть на реальные данные и позволяет метрикам естественным образом формироваться. В Nurture Boss мы начали с таблицы, где каждая строка представляла разговор. Мы писали открытые заметки о любом нежелательном поведении. Затем мы использовали LLM для построения таксономии распространённых режимов сбоя. Наконец, мы сопоставили каждую строку с конкретными метками режима сбоя и подсчитали частоту каждого сбоя.
Результаты были поразительными — всего три проблемы составляли более 60% всех неполадок:
* Проблемы с потоком разговора (отсутствие контекста, неуклюжие ответы).
* Ошибки при передаче (неспособность распознать, когда нужно передать человеку).
* Проблемы с изменением расписания (трудности с обработкой дат).
Воздействие было немедленным. Команда Джейкоба выявила столько действенных идей для улучшения, что им понадобилось несколько недель только для того, чтобы реализовать исправления для проблем, которые мы уже обнаружили.
Если вы хотите увидеть анализ ошибок в действии, мы записали пошаговое руководство.
Это подводит нас к важнейшему вопросу: как сделать так, чтобы командам было легко просматривать свои данные? Ответ приводит нас к тому, что я считаю наиболее важным вложением для любой команды, занимающейся ИИ…
### Самое важное вложение в ИИ: простой просмотрщик данных
Самое значимое вложение, которое я видел у команд, занимающихся ИИ, — это не модная оценочная панель. Это создание настраиваемого интерфейса, который позволяет любому изучить, что на самом деле делает их ИИ. Я подчёркиваю «настраиваемый», потому что у каждой области есть уникальные потребности, которые стандартные инструменты редко удовлетворяют. При просмотре разговоров об аренде квартир вам нужно видеть полную историю чата и контекст планирования. Для запросов о недвижимости вам нужны данные об объекте и исходные документы прямо там. Даже небольшие решения UX, такие как расположение метаданных или выставленные фильтры, могут иметь значение — между инструментом, который люди на самом деле используют, и тем, который они избегают.
Я наблюдал, как команды борются с общими интерфейсами для маркировки, пробираясь через несколько систем, чтобы понять один-единственный контакт. Трение нарастает: переход по разным системам для просмотра контекста, копирование описаний ошибок в отдельные таблицы отслеживания, переключение между инструментами для проверки информации. Это трение не просто замедляет команды — оно активно препятствует систематическому анализу, который выявляет тонкие проблемы.
Команды с продуманными средствами просмотра данных итерации в 10 раз быстрее, чем те, у кого их нет. И вот в чём дело: эти инструменты можно создать за считанные часы с помощью разработки с использованием ИИ (например, Cursor или Loveable). Вложения минимальны по сравнению с отдачей.
Позвольте мне показать вам, что я имею в виду. Вот средство просмотра данных, созданное для Nurture Boss (о котором я говорил ранее):
* поиск и фильтрация сессий;
* аннотация и добавление заметок;
* агрегация и подсчёт ошибок.
Вот что делает инструмент аннотации данных хорошим:
* Показывает весь контекст в одном месте. Не заставляйте пользователей искать информацию в разных системах, чтобы понять, что произошло.
* Упрощает сбор обратной связи. Кнопки «верно/неверно» одним кликом лучше, чем длинные формы.
* Собирает открытую обратную связь. Это позволяет вам фиксировать нюансы проблем, которые не вписываются в предопределённую таксономию.
* Обеспечивает быструю фильтрацию и сортировку. Командам нужно легко погружаться в конкретные типы ошибок. В примере выше Nurture Boss может быстро фильтровать по каналу (голосовой, текстовый, чат) или по конкретному объекту, который они хотят быстро просмотреть.
* Имеет горячие клавиши, которые позволяют пользователям перемещаться между примерами данных и аннотировать без кликанья.
Не имеет значения, какие веб-фреймворки вы используете — используйте те, с которыми вы знакомы. Поскольку я разработчик на Python, моим текущим любимым веб-фреймворком является FastHTML в сочетании с MonsterUI, потому что он позволяет мне определять код бэкенда и фронтенда в одном небольшом файле Python.
Ключ в том, чтобы начать с чего-то простого. Я обнаружил, что собственные веб-приложения обеспечивают лучший опыт, но если вы только начинаете, электронная таблица лучше, чем ничего. По мере роста ваших потребностей вы можете развивать свои инструменты соответственно.
Это подводит нас к ещё одному неочевидному уроку: люди, которые лучше всего подходят для улучшения вашей системы ИИ, часто знают об ИИ меньше всего.