CTO Airbnb Ахмад Аль-Дахле назвал ИИ в поддержке одной из самых неудобных задач для внедрения генеративных моделей: здесь недостаточно вежливо ответить в чате, нужно согласовать действия нескольких сторон и не ошибиться в ситуации, которая затрагивает деньги, поездку или жильё. Для российских продуктовых и инженерных команд это знакомый сигнал: автоматизация саппорта упирается не в красивую демо-версию, а в качество решений на реальных, непредсказуемых кейсах.
Об этом Аль-Дахле говорил в беседе с Райаном Донованом, сообщает Stack Overflow Blog. Главная тема разговора — использование многосторонних ИИ-агентов в клиентской поддержке Airbnb, подход к оценке их работы и изменения, которые генеративный ИИ приносит в инженерную организацию компании.
Поддержка в сервисе бронирования — это не один пользователь с одним вопросом. В одном обращении могут участвовать гость, хозяин жилья и сама платформа; у каждого свои данные, ожидания и допустимые действия. Агенту нужно не просто сформулировать ответ, а понять контекст, определить, кого и о чём можно уведомить, и не выдать решение, которое выглядит убедительно, но нарушает правила процесса. Именно на стыке нескольких участников обычный сценарий «вопрос — ответ» перестаёт работать.
Из разговора следует важная инженерная деталь: оценка таких систем не может быть разовым экзаменом перед запуском. Аль-Дахле описывает её как постоянно меняющуюся цель. Команда должна регулярно проверять, насколько модель точна, где она ошибается и какую цену имеет каждая ошибка. Это особенно актуально для ИИ в поддержке: неверный ответ на вопрос о статусе заказа неприятен, а неверное действие в споре между клиентом и исполнителем может создать уже операционную проблему.
Вторая сторона этой задачи — задержка. Пользователь не готов ждать, пока несколько моделей и сервисов неспешно обсудят его обращение, но ускорение не должно превращать систему в генератор поспешных решений. Поэтому компромисс между латентностью и точностью здесь не сводится к выбору более быстрого API или меньшей модели. Его приходится измерять на сценариях, которые действительно доходят до поддержки, и пересматривать по мере изменения продукта, правил и поведения пользователей.
Для разработчиков это аргумент против популярной схемы «подключим модель к базе знаний и посмотрим». База знаний полезна, но в сложном сервисе она решает только часть задачи. Нужны границы полномочий агента, журналы действий, понятная передача диалога человеку и набор проверок для ситуаций, где у системы нет достаточной уверенности. Чем ближе агент к операциям — отмене, компенсации, изменению бронирования или доступу к данным, — тем дороже обходится самоуверенность модели.
Отдельно Аль-Дахле затронул инструменты для программирования на базе ИИ. Их распространение, по его словам, повышает, а не снижает требования к инженерному суждению. Код можно получить быстрее, но команде всё равно необходимо определить корректность решения, его риски, последствия для архитектуры и поддержку в будущем. Это относится и к агентным системам: скорость генерации кода не заменяет ответственность за то, что этот код делает с пользовательским запросом.
Для руководителей разработки и продуктовых команд вывод довольно приземлённый. Внедрение ИИ в поддержке стоит оценивать не по числу автоматически закрытых тикетов и не по эффектному диалогу на презентации, а по качеству решения конкретных классов обращений. Полезнее начать с ограниченной зоны, заранее описать случаи обязательной эскалации и собирать ошибки в отдельный набор для переоценки. Иначе автоматизация быстро оптимизирует метрику, но не опыт клиента.
Следующий вопрос для рынка — смогут ли компании построить оценку агентных систем быстрее, чем растёт сложность самих агентов. В клиентской поддержке победит не тот, кто первым добавит чат с моделью, а тот, кто сможет доказать: система достаточно быстро принимает решения, знает пределы своих полномочий и вовремя зовёт человека.