Андрес Тапиа, соучредитель и генеральный директор Restack, говорит, что компании неправильно относятся к ИИ.
Тапиа и его коллега-соучредитель и технический директор Филипп Брюле впервые работали вместе более 10 лет назад в Mister Spex, омниканальной оптике. Разошлись, пара снова объединилась, чтобы помочь компаниям разобраться в своих данных: как их переместить; как его редактировать.
Так появилась первая версия Restak: облачного сервиса, позволяющего инженерам данных развертывать приложения одним щелчком мыши. Это была миссия около двух лет — пока ChatGPT не вышел на сцену в 2022 году и полностью не перевернул технологии, работу и то, как мы обо всем думаем.
Внезапно клиенты Restack начали обращаться к Tapia с новыми запросами: «Я использую Restack для перемещения данных отсюда сюда, — перефразирует Тапиа. — Сейчас мы начинаем создавать некоторые продукты AI. Можем ли мы использовать вашу платформу также для этих продуктов AI?»
Технически, по его словам, мало что нужно изменить, чтобы соответствовать новым требованиям, но это стало важным поворотным моментом. Вскоре почти 90% их пользователей обратились за помощью к ИИ: «Поэтому мы сказали: «Мы собираемся остановить то, что мы делаем».[‘re] делаем, и мы собираемся на 100% сосредоточиться на сценарии использования ИИ», — вспоминает Тапиа.
Но они были не единственными, кто двигался в этом направлении.
Так много новых инструментов ИИ — так много новых ошибок
Так же быстро, как ChatGPT и почти повсеместные агенты искусственного интеллекта, казалось бы, возникли в мгновение ока, появились и инструменты для создания продуктов искусственного интеллекта: Langchain, Bercel и т. д. И, несмотря на относительную новизну, процесс создания агента быстро стал относительно стандартным: определите, что должен делать ваш агент (для многих это поддержка клиентов); подключить нужные инструменты и источники данных (например, часто задаваемые вопросы); иди вживую.
«Но проблема в том, что на этом все не заканчивается», — говорит Тапиа. Как только вы выйдете в эфир… ваш агент будет отвечать реальным людям — и [IT] начинать[s] галлюцинировать».
Один поставщик медицинских услуг усвоил это на собственном горьком опыте, прежде чем прийти в Restack.
Они создали агента службы поддержки клиентов, который будет отвечать на такие вопросы, как «Сколько будет стоить X?» и «Покрывает ли моя страховка этого стоматолога или нет?» Удобно в теории, но не тогда, когда большинство ответов на эти вопросы неверны.
«Они ха[d] много случаев, когда… клиент жаловался: «Я ходил к дантисту, а на самом деле на этого стоматолога не распространяется мой полис», — объясняет Тапиа.
К сожалению, любой, кто общался с ботом, знает, что такие сбои не редкость.
Тапиа думает, что он определил причину неудачи. С его точки зрения, большинство компаний упускают из виду вторую — и очень важную — часть создания агентов ИИ: тестирование поведения.
Часть, которую все упускают: тестирование поведения агента тестирования (не только результатов)
«Сначала вы создаете техническую часть, но потом… вам нужно убедиться, что агент работает правильно — вот и все. [where] мы не видели, чтобы на рынке что-то было», — говорит Тапиа, — и где, по его словам, Restack предлагает что-то другое.
Компании начинают с создания агента. Затем они могут определить то, что Тапиа называет «поведенческими метриками», квалификаторами, которые выходят за рамки типичных функциональных показателей или показателей производительности, на которые опирается большинство инструментов.
Например, для вышеупомянутого поставщика медицинских услуг поведенческие показатели включают такие вопросы, как «Упоминает ли мой агент моего конкурента?» «Проверяет ли мой агент полис, прежде чем рекомендовать стоматолога?»
В отличие от объективных сигналов (таких как время ответа агента или скорость решения), ответы на эти поведенческие вопросы субъективны и, следовательно, их нелегко проверить с помощью простой функции или теста на основе правил — но они делают больше, чтобы не допустить, чтобы ответы чат-бота пошли в сторону.
Есть и еще один уровень оценки. «Мы [have] этот LLM в качестве судьи, — объясняет Тапиа. — По сути, другой LLM собирается проверить, действительно ли этот LLM поступает правильно или нет».
А если агент не оправдает ожиданий судьи LLM? Затем наступает время итерации, то есть «измените подсказки, измените инструменты, которые вы предоставляете, измените контекст», — говорит он.
Когда ИИ запускается, ошибки проявляются сами собой
По словам Тапиа, большинство компаний упускают из виду поведенческие метрики и процесс тестирования и итерации, когда начинают проекты ИИ.
«Каждая компания хочет внедрить ИИ», — говорит он. «Они знают, что каким-то образом могут сэкономить деньги и работать более эффективно. [but they do] не совсем [know] вариант использования».
Понятно, что многие компании бросаются в ИИ с закрытыми глазами и головой вперед, потому что боятся часто рекламируемого принципа: «Присоединяйся или оставайся позади». И продуктовым командам часто приходится разбираться в этом и быстро доставлять результаты.
В поисках жизнеспособных вариантов использования поддержка клиентов обычно кажется естественной. Следующим шагом является оценка доступных фреймворков, а затем передача их командам разработчиков для работы в течение нескольких месяцев перед запуском в эксплуатацию.
Именно тогда Тапиа говорит, что ошибки проявляются сами собой.
Во время первого живого теста (скажем, отправки агенту 10% разговоров со службой поддержки): «Люди [i.e., customers] начинают жаловаться, — говорит Тапиа, — а потом начальство жалуется… Тогда команда продукта говорит[ys]«Это продукт, который я отправляю; Я несу ответственность за то, что он делает».
Но когда продуктовые команды возвращаются к инженерам, чтобы спросить, что пошло не так и как это исправить, ответы не однозначны.
Нет быстрого решения
С инженерной стороны все было правильно — правильные инструменты, правильная интеграция. Но недетерминированный характер LLM означает, что результаты по-прежнему будут различаться.
Это не воодушевляет. Возможно, именно поэтому Gartner прогнозирует, что 40% проектов агентного искусственного интеллекта будут отменены к 2027 году. Тапиа говорит, что дискуссии часто повторяют одни и те же опасения:
«[For companies that…build the[ir] первый агент…, там [is] большая часть людей говорит: «ИИ, пока. Это не работает. Давайте остановим это».
По его словам, только благодаря этим неудачам команды понимают, что не могут оценивать поведение с помощью классических вопросов и ответов. А именно, говорит Тапиа, они понимают: «Нам нужно проводить тестирование по-другому. Нам нужно самим позвонить агенту, попытаться смоделировать случаи и посмотреть… работу агента и поведение по этим вопросам».
Но об этом тестировании легче сказать, чем сделать.
«Когда команда разработчиков хочет это протестировать, они обнаруживают, что не могут — потому что все было построено с точки зрения разработки программного обеспечения», — объясняет Тапиа. «Инструмент встроен в него. Если они хотят что-то изменить, им нужно обратиться к команде разработчиков программного обеспечения и сказать им: «Измените приглашение. Измените этот инструмент. Удалите этот контекст из хранилища контекстов».
Очевидно, что многоэтапный итерационный процесс увеличивает объем и время. Но создание агентов ИИ — это новая сфера, поэтому имеет смысл, чтобы компании вернулись к известным процессам разработки программного обеспечения.
Вот в чем загвоздка, отмечает Тапиа. Он утверждает, что создание агентов ИИ не является проблемой разработки программного обеспечения; это проблема продукта. И пока компании не изменят свой подход, он прогнозирует, что впереди нас ждут дальнейшие неудачи:
«Больше компаний [are going to] перейти к ИИ и остаться недовольными результатами… потому что, по сути, они не понимали, что ИИ — это не то же самое, что создание программного решения».
Перестаньте относиться к ИИ как к программному обеспечению; Относитесь к нему как к сотруднику
Итак, как компаниям следует относиться к внедрению ИИ?
«Надо подумать об ИИ [the same] как вы думаете о новых сотрудниках в компании», — советует Тапиа.
Это означает адаптацию, обучение и регулярное развитие, чтобы со временем обе стороны могли лучше понять, что нужно делать. По его словам, такое усовершенствование поведения является ключом к успеху, а другие инструменты его упускают из виду.
При использовании метода Restack команды по разработке продуктов получают возможность самостоятельно контролировать поведение ИИ-агента, тестировать и поставлять его, как обычные функции продукта.
«Вы создаете свой агент так, как вы его создаете, но у команды разработчиков будет ряд функций… чтобы они могли — самостоятельно в нашем пользовательском интерфейсе — повторять и изменять эти подсказки, инструменты и все остальное — без необходимости обращаться к технической команде».
Это отход от стандартных процессов развертывания ИИ, который дает командам разработчиков больше контроля над поведением агентов и, возможно, наконец приводит его в соответствие с ожиданиями пользователей.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Мередит Шубель — технический писатель, освещающий облачную инфраструктуру и корпоративное программное обеспечение. С 2022 года она сотрудничает с The New Stack, рассказывая о стартапах и изучая, как организации внедряют новые технологии. Помимо The New Stack, она пишет официальные документы, подписи руководителей и т. д. Подробнее от Мередит Шубель
