Доставку продуктов для гостей Airbnb строили восемь-девять месяцев. Следующий сервис того же устройства — трансфер из аэропорта, та же интеграция с внешним партнёром по API — заняли шесть недель. Между проектами компания не ждала новой модели. Она сложила опыт первой команды в систему, из которой вторая смогла его достать.
История — из разговора Latent Space с Ахмадом Аль-Дахле: с января он CTO Airbnb, до этого руководил генеративным ИИ в Meta и выпускал Llama. Задача у него сформулирована как «сделать Airbnb AI-native компанией», и цифры он называет внушительные: 60% кода пишет ИИ, фич и улучшений за год вышло почти на 80% больше, средний инженер выпускает в 1,6 раза больше пул-реквестов. Цифры самой компании, снаружи не проверить. Я читал это с одним вопросом: что отсюда переедет в компанию на сто человек, а что останется игрушкой корпорации с капитализацией 93 миллиарда долларов.
Главную экономию дало не то, что добавили, а то, что убрали
По словам Аль-Дахле, самый большой выигрыш в скорости разработки дала не генерация кода. Раньше продукт в Airbnb шёл по конвейеру: требования, затем дизайн в Figma, затем инженеры, затем тесты, и на каждом стыке работа передавалась из рук в руки. Теперь продукт, дизайн и разработка садятся сразу за прототип. Документ требований как промежуточный артефакт исчез; CTO формулирует это так: компания ушла от избыточного производства артефактов к тому, что код и прототип — и есть артефакт, над которым рассуждают.
Технологии здесь ноль. Это отказ от одного типа документа и от передачи работы между отделами. Компания на сто человек может сделать то же самое в понедельник: следующая доработка в 1С или в CRM начинается не с ТЗ на четыре страницы, а с кликабельного прототипа, который свой разработчик или подрядчик собирает за день — с ИИ это сейчас именно день. У нас в проектах сильнее всего тормозит не разработка, а согласование ТЗ, которое к моменту сдачи уже не совпадает с тем, что хотел заказчик. Аль-Дахле говорит об этом же шире: компании, устроенные вокруг выпуска фич, в эпоху ИИ будут буксовать, устроенные вокруг целей и результатов — справятся.
Шесть недель вместо восьми месяцев — это память компании, а не модель
Everest — внутренний граф организационного контекста Airbnb, построенный на LLM и векторном поиске по всей кодовой базе. Команда доставки продуктов отработала интеграцию с партнёром, её опыт лёг в Everest, и команда трансферов шла по готовой колее. Второй эффект, который Аль-Дахле ценит не меньше: универсалы начали работать в узкоспециальных частях кода, куда раньше пускали только профильных инженеров.
Строить граф знаний на сто человек никто не станет, и правильно. Но узкое место то же самое: второй проект занимает столько же, сколько первый, потому что всё, что узнала первая команда, живёт в головах и в переписке с подрядчиком. Мысленный пример, не кейс: дистрибутор делал интеграцию с одним маркетплейсом полгода, со вторым — снова полгода, хотя грабли на девять десятых те же. Доступная версия Everest — одна папка, куда после каждого проекта кладут не отчёт для руководства, а то, что пригодится следующей команде: схему данных, обходные решения, переписку с техподдержкой партнёра и то, что в итоге так и не заработало. Если это лежит текстом, ИИ-ассистент это прочитает. Если в памяти Пети — нет, и Петя, кстати, может уволиться.
Половину тикетов закрывает ИИ, и важнее — какую половину не отдают
Поддержка стала первым местом, где Airbnb выпустила ИИ наружу, к клиентам, и Аль-Дахле называет её самой трудной задачей для внедрения: цена ошибки высокая. Сейчас около половины обращений закрывается без человека, в отчёте за второй квартал — почти 45%. Условий два. До продакшена агента прогоняют на батарее синтетических данных: сначала строят модель и агента, потом генерируют тесты, и только потом выпускают. И второе — цитата, которую я бы повесил над столом руководителя поддержки:
Пока мы решаем 50% тикетов, мы очень осознанно выбираем те тикеты, которые пока не отдаём агентам.
Вопросы безопасности и всё, где последствия ошибки необратимы, туда не пускают намеренно. Половина — это граница, которую провели люди, а не потолок модели.
Здесь масштабируется всё целиком. В компании на сто человек поддержка — три-пять человек в чате и на телефоне, и у них те же два вопроса: на чём проверять бота до запуска и что ему запрещено. Обычно делают наоборот: запускают на всё и потом по жалобам отрезают. У Airbnb список запретов появляется до запуска, и подозреваю, что именно поэтому их цифра растёт, а не откатывается после первого скандала.
Десять дообученных моделей — не для вас. Правило «объясни, что построил» — для всех
Теперь про то, что вниз не переедет. Airbnb называет себя мультимодельной компанией: открытые и флагманские модели, собственное дообучение на открытых, минимум десять кастомных моделей в проде, для каждой задачи свой набор тестов из реальных запросов, и для каждой — своя точка на кривой «цена, качество, задержка». Для поиска берут маленькие дообученные модели, которые, по словам Аль-Дахле, на узких задачах иногда обгоняют флагманские. Для кода — наоборот, самую сильную из флагманских: код терпит задержку, а каждый дефект обходится дороже токенов.
Дообучать модели в компании на сто человек не нужно, и команда для этого не появится. Но принцип выбора переезжает как есть: где ошибка дорогая и спешки нет — код или договор — берём лучшую модель и не экономим; где поток большой и ответ нужен за секунду — чат на сайте, разбор входящих заявок — берём дешёвую и проверяем на своих же вчерашних запросах. Набор тестов на задачу в вашем масштабе — таблица на сто строк, которую ведёт один человек.
А первым я бы скопировал вещь, которая вообще не про технологии. Аль-Дахле беспокоится, что джуниоры с ИИ не нарабатывают ремесло и суждение, которое у сеньоров пришло через годы эксплуатации систем и собственных ошибок. Поэтому правило: каждый инженер обязан объяснить, что он построил, даже если пул-реквест сгенерировала модель. В малой компании это правило нужнее, чем в Airbnb. Там ошибку поймают ревью и слой тестов, у вас её поймает бухгалтер через месяц. Не можешь рассказать, почему скрипт делает то, что делает, — скрипт в прод не идёт.
Асинхронных агентов, которые у Airbnb сами разбирают сработавшие алерты мониторинга, предлагают исправление в пул-реквесте или закрывают ложную тревогу, я у себя не гонял и пока смотрю со стороны; Аль-Дахле видит в них будущую систему надзора за всем маркетплейсом — фрод, нарушения доверия, качество площадки, дефекты в коде.
Шаг на неделю: попросите руководителя поддержки выгрузить обращения за сентябрь и разложить на три стопки — что ИИ закроет уже сейчас по готовым ответам; что закроет, если дать ему доступ к базе знаний и заказам; что ему нельзя отдавать ни при каких условиях. Доля первой стопки — ваш честный аналог «45% Airbnb». Третья стопка — документ, который должен появиться раньше бота.
Илья Потоцкий — внедряю ИИ и автоматизацию в российских компаниях. Что делаю — об авторе и Floxio.
Чем занимаюсь: ИИ для отдела продаж · автоматизация рутины · видеоаналитика · разработка софта.
Первоисточник: Inside-Out AI: Rebuilding Airbnb Behind the Scenes and Across the Guest Experience. Перевод и адаптация для российского рынка — с собственными комментариями.
Есть похожая задача в вашей компании? Напишите — разберу, стоит ли её вообще автоматизировать.
Написать в Telegram