Поскольку мы все еще только осваиваем создание приложений с использованием базовых моделей, ошибки вполне нормальны. Это краткая заметка с примерами некоторых из наиболее распространенных ошибок, которые я видел как в публичных кейсах, так и в своем личном опыте.
Эти ошибки являются распространенными, поэтому, если вы работали над каким-либо продуктом, связанным с ИИ, вы, вероятно, уже сталкивались с ними.
1. Использовать генеративный ИИ там, где он не нужен
Каждый раз, когда появляется новая технология, я слышу, как хором вздыхают старшие инженеры: «Если тебе дали молоток, то нельзя повсюду видеть гвозди». Генеративный ИИ не является исключением из этого правила — его, казалось бы, безграничные возможности только усугубляют тенденцию использовать генеративный ИИ для всего.
Одна команда предложила мне идею использования генеративного ИИ для оптимизации энергопотребления. Они ввели в LLM список энергоемких действий в домохозяйстве и почасовые цены на электроэнергию, а затем попросили его составить график, чтобы минимизировать затраты на энергию. Их эксперименты показали, что это может помочь сократить счета за электроэнергию в домохозяйстве на 30 %. Бесплатные деньги. Почему кто-то не захочет использовать их приложение?
Я спросила: «Как это соотносится с простым планированием наиболее энергозатратных действий на время, когда электроэнергия дешевле всего? Например, стирка белья и зарядка автомобиля после 22:00?»
Они сказали, что попробуют позже и дадут мне знать. Они так и не связались со мной, но вскоре после этого отказались от этого приложения. Я подозреваю, что такой «жадный» подход к планированию может быть довольно эффективным. Даже если это не так, есть другие, гораздо более дешевые и надежные решения для оптимизации, чем генеративный ИИ, например, линейное программирование.
Я встречала этот сценарий снова и снова. Одна крупная компания хочет использовать генеративный ИИ для обнаружения аномалий в сетевом трафике. Другая хочет предсказать предстоящий объем звонков от клиентов. Больница хочет определять, страдает ли пациент от недоедания (крайне не рекомендуется).
Часто бывает полезно изучить новый подход, чтобы понять, что возможно, при условии, что вы осознаете, что ваша цель не решить проблему, а протестировать решение. «Мы решаем проблему» и «Мы используем генеративный ИИ» — это два очень разных заголовка, и, к сожалению, многие люди предпочитают второй.
2. Путать «плохой продукт» и «плохой ИИ»
С другой стороны, многие команды отвергают генеративный ИИ, не считая, что он будет эффективен при решении их проблем, потому что они попробовали его, и их пользователи этим остались очень недовольными. Однако другие команды успешно использовали генеративный ИИ для аналогичных задач. Я смогла изучить только две такие команды. В обоих случаях проблема была не в ИИ, а в продукте.
Многие люди говорили мне, что технические аспекты их ИИ-приложений просты. Сложность заключается в пользовательском опыте (UX). Как должен выглядеть интерфейс продукта? Как плавно интегрировать продукт в рабочий процесс пользователя? Как включить человека в цикл?
UX всегда было сложно реализовать, но с генеративным ИИ она стала еще сложнее. Хотя мы знаем, что генеративный ИИ меняет то, как мы читаем, пишем, учимся, преподаем, работаем, развлекаемся и т. д., мы еще не совсем понимаем, как именно. Каким будет будущее чтения/обучения/работы?
Вот несколько простых примеров, которые показывают, как желания пользователей могут быть противоречивыми и требуют тщательного изучения.
Моя подруга работает над приложением, которое подготавливает краткие протоколы встреч. Изначально ее команда сосредоточилась на том, чтобы найти оптимальную длину отчета. Что предпочтут пользователи: протоколы из 3 предложений или из 5?
Однако оказалось, что пользователям было все равно, какова фактическая длина протокола. Им нужны были только конкретные для них действия, которые необходимо было предпринять по итогам каждой встречи.Когда LinkedIn разработал чат-бота для оценки соответствия компетенциям, они обнаружили, что пользователи не хотят правильных ответов. Пользователи хотят полезных ответов.
Например, если пользователь спрашивает бота, «подхожу ли я на эту вакансию», и бот отвечает: «Вы совершенно не подходите», этот ответ может быть правильным, но не очень полезным для пользователя. Пользователи хотят получить советы о том, в чем заключаются пробелы и что они могут сделать, чтобы их устранить.
Компания Intuit создала чат-бота, чтобы помочь пользователям отвечать на вопросы по налогам. Сначала отзывы были прохладными — пользователи не находили бота полезным. После исследования выяснилось, что пользователи на самом деле не любили печатать. Столкнувшись с пустым чат-ботом, пользователи не знали, что он может делать и что печатать.
Поэтому для каждого взаимодействия Intuit добавила несколько предлагаемых вопросов, на которые пользователи могли нажимать. Это уменьшило трудности при использовании бота и постепенно укрепило доверие пользователей. Отзывы пользователей стали гораздо более положительными.
(Поделилась Нхунг Хо, вице-президент по искусственному интеллекту в Intuit, во время нашей панельной дискуссии на Grace Hopper.)
Поскольку в настоящее время все используют одни и те же модели, компоненты искусственного интеллекта в продуктах с ИИ схожи, а различия заключаются в продукте.
3. Начинать слишком сложно
Пример этой ошибки:
Использовать агентные фреймворки там, где можно обойтись прямыми вызовами API.
Терзаться выбором векторной базы данных, когда простое поисковое решение на основе терминов (не требующее vectordb) работает не хуже.
Настойчивое стремление к тонкой настройке, когда работает промпт.
Использование семантического кэширования.
Учитывая такое количество новых заманчивых технологий, очень хочется сразу же приступить к их использованию. Однако слишком раннее внедрение внешних инструментов может вызвать две проблемы:
Абстрагирование от важных деталей, что затрудняет понимание и отладку вашей системы.
Появление ненужных ошибок.
Разработчики инструментов могут допускать ошибки. Например, при проверке кодовой базы фреймворка я часто нахожу опечатки в стандартных подсказках. Если используемый вами фреймворк обновляет подсказки без уведомления, поведение вашего приложения может измениться, и вы не будете понимать, поч��му.
В конечном итоге абстракции — это хорошо. Но абстракции должны включать в себя лучшие практики и проходить длительное тестирование. Поскольку мы все еще находимся на ранней стадии развития искусственного интеллекта, лучшие практики продолжают формироваться, и мы должны быть более бдительными при внедрении любых абстракций.
4. Переоценивать ранний успех
LinkedIn потребовался 1 месяц, чтобы достичь 80% желаемого результата, и еще 4 месяца, чтобы превысить 95%. Первоначальный успех заставил их сильно недооценить, насколько сложно дальше улучшать продукт, особенно в части галлюцинаций. Им было разочаровывающе сложно достичь каждого последующего 1% прироста.
Один стартап, разрабатывающий ИИ‑ассистентов по продажам для e‑commerce, рассказал мне, что путь от 0 до 80% занял столько же времени, сколько и путь от 80% до 90%. Основные сложности, с которыми они столкнулись:
Компромисс между точностью и задержкой (latency): больше планирования и самокоррекции → больше узлов → выше задержка
Вызов инструментов (tool calling): агенту сложно различать похожие инструменты
Системные инструкции с требованиями к стилю (например, «говори как консьерж люксового бренда») трудно выполнять идеально.
Агенту сложно полностью понять запрос пользователя
Трудно создать чёткий набор юнит‑тестов, поскольку комбинаций запросов практически бесконечное количество
Спасибо Джейсону Тьяхжоно за то, что поделился этим опытом.
В статье UltraChat Дин и соавторы (2023) отмечают: «Путь от 0 до 60 даётся легко, тогда как продвижение от 60 до 100 становится чрезвычайно сло»жным».
Пожалуй, это один из первых болезненных уроков, которые быстро усваивает каждый, кто создаёт ИИ-продукт. Сделать демо легко, а вот выстроить продукт сложно. Помимо уже упомянутых проблем с галлюцинациями, задержками, компромиссом между задержкой и точностью, использованием инструментов, промптингом, тестированием и т. д., команды сталкиваются и с другими трудностями, например::
Надёжность API‑провайдеров. Одна команда рассказала мне, что около 10% их API‑запросов завершались тайм‑аутом. Кроме того, поведение продукта может меняться из‑за обновлений базовой модели.
Соответствие требованиям, например, в отношении авторских прав на результаты работы ИИ, доступа к данным/обмена данными, конфиденциальности пользователей, рисков безопасности, связанных с системами поиска/кэширования, а также неоднозначности в отношении происхождения обучающих данных.
Безопасность. Например, злоумышленники могут злоупотреблять вашим продуктом, или продукт может генерировать нечувствительные либо оскорбительные ответы.
При планировании этапов разработки продукта и распределении ресурсов важно учитывать все эти потенциальные препятствия. Один мой друг называет такой подход «осторожным оптимизмом». При этом стоит помнить, что многие впечатляющие демо так и не превращаются в по-настоящему отличные продукты.
5. Отказываться от человеческой оценки
Для автоматической оценки приложений ИИ многие команды выбирают подход «ИИ в роли арбитра» (также называемый «LLM в роли арбитра») — использование моделей ИИ для оценки результатов ИИ. Распространенной ошибкой является отказ от оценки человеком и полное доверие к ИИ-судьям.
Хоть ИИ-арбитры могут быть очень полезны, они не являются детерминированными. Качество судьи зависит от базовой модели арбитра, промпта и кейса использования. Если ИИ-судья не разработан должным образом, он может дать вводящие в заблуждение оценки производительности вашего приложения. ИИ-судьи должны оцениваться и совершенствоваться со временем, так же как и любые другие ИИ-приложения.
Команды с лучшими продуктами, которые я видел, дополняют автоматическую оценку оценкой, проводимой людьми. Каждый день эксперты-люди оценивают часть результатов работы приложения, количество которых может варьироваться от 30 до 1000 примеров.
Ежедневная ручная оценка выполняет три задачи:
Сопоставление человеческих оценок с оценками ИИ. Если балл, выставляемый людьми, снижается, а балл ИИ‑оценщика растёт, стоит проверить работу вашего ИИ‑судьи.
Получение лучшего понимания того, как пользователи используют ваше приложение, что может дать идеи для его улучшения.
Выявление закономерностей и изменений в поведении пользователей с учётом текущих событий, которые автоматический анализ данных может пропустить.
Надежность оценки человека также зависит от хорошо составленных рекомендаций по аннотированию. Эти рекомендации могут помочь улучшить инструкции модели (если человеку сложно следовать инструкциям, то и модели будет сложно). Их также можно повторно использовать для создания данных для тонкой настройки, если вы решите провести такую настройку.
В каждом проекте, над которым я работал, всего 15 минут просмотра данных обычно давали мне некоторое понимание, которое могло сэкономить мне часы головной боли. Грег Брокман написал в Твиттере: «Ручная проверка данных, вероятно, имеет самое высокое соотношение ценности и престижа среди всех видов деятельности в области машинного обучения».
6. Краудсорсить кейсы использования
Это ошибка, которую я наблюдала в первые дни, когда предприятия в порыве энтузиазма начали внедрять генеративный ИИ. Не сумев разработать стратегию, на каких сценариях использования следует сосредоточиться, многие руководители технологических компаний собрали идеи от всех сотрудников. «Мы нанимаем умных людей. Пусть они подскажут нам, что делать». Затем они пытаются реализовать эти идеи одну за другой.
Так мы получили миллион моделей преобразования текста в SQL, миллион Slack-ботов и миллиард плагинов кода.
Хотя действительно стоит прислушиваться к умным людям, которых вы нанимаете, отдельные сотрудники могут быть предвзятыми по отношению к проблемам, которые непосредственно влияют на их повседневную работу, а не к проблемам, которые могут принести наибольшую отдачу от инвестиций. Без общей стратегии, учитывающей общую картину, легко отвлечься на ряд небольших приложений с низкой эффективностью и прийти к ошибочному выводу, что генеративный ИИ не приносит ROI.
Итог
Вкратце, вот распространенные ошибки при разработке ИИ:
Использовать генеративный ИИ там, где он не нужен
Генеративный ИИ — это не универсальное решение всех проблем. Многие проблемы даже не требуют использования ИИ.Путать «плохой продукт» и «плохой ИИ»
Для многих ИИ‑продуктов ИИ является легкой частью, а продукт — сложной.Начинать слишком сложно
Хотя красивые новые фреймворки и тонкая настройка могут быть полезны для многих проектов, не с них следует начинать.Переоценивать ранний успех
Путь от готового демо до готового к запуску продукта может занять гораздо больше времени, чем подготовка первого демо.Отказываться от человеческой оценки
Оценки ИИ должны быть проверены и сопоставлены с систематической оценкой людьми.Краудсорсить кейсы использования
Имейте общую стратегию, чтобы максимизировать окупаемость инвестиций.
