Оценка ИИ: почему это новые PRD (требования к продукту) по версии Expedia
Источник: VentureBeat · Louis Columbus
«Новые технические требования к продукту (PRD) — это тесты», — заявил Хави Аматриайн, первый директор по искусственному интеллекту и работе с данными Expedia Group, на прошлой неделе на конференции VB Transform 2026 в Менло-Парке. — По сути, вы закладываете то, что должен делать продукт, через тесты, которые могут включать тесты на red teaming (проверку на уязвимости) и множество других вещей, для которых уже существует куча требований безопасности. Так что вы внедряете это в PRD и в проектную документацию продукта еще до того, как начнете писать код».
Он развил эту мысль дальше: «С помощью кода, создаваемого или поддерживаемого с помощью ИИ, за этим будущее. Все ваше мышление будет уходить в тесты».
До своего назначения в Expedia в декабре 2025 года Аматриайн занимал должность вице-президента по ИИ и обеспечению вычислений в Google, работая на платформах, поддерживающих Gemini и Google Search. Он был наставником специалистов, которые впоследствии основали Perplexity и Scale AI.
Исследование VentureBeat VB Pulse, посвященное разрыву в оценках, лишь подчеркнуло серьезность ситуации. Шестьдесят шесть процентов из 157 опрошенных предприятий уже разрешают определенный запуск в производство без проверки человеком или планируют внедрить это в течение следующих 12 месяцев, однако лишь 5% полностью доверяют автоматизированным оценкам, которые принимали бы такое решение. Половина компаний выпускала агента, который успешно прошел внутренние тесты, но затем давал сбой при работе с реальным клиентом.
Не позволяйте защитным механизмам мешать обратной связи
«Чем больше защитных механизмов, искусственных бизнес-правил и прочих ограничений вы внедряете в систему, тем хуже, — сказал Аматриайн. — Не только потому, что они хрупкие, но и потому, что они фактически портят петлю обратной связи. Вы фактически вносите предвзятость в действия пользователя и в получаемую от него обратную связь, а затем делаете из этого неправильные выводы». Он назвал защитные механизмы «необходимым злом» и заявил, что цель состоит в том, чтобы со временем свести их влияние к минимуму.
С этим на конференции согласились далеко не все. Другие выступающие утверждали в ходе мероприятия, что действия с наивысшим уровнем риска по-прежнему требуют очень жестких ограничений.
Вместо этого Expedia регулирует использование ИИ с помощью трех уровней. На первом месте стоят принципы, о которых широко заявляется. «Мне нравится кодировать на очень высоком уровне то, как, по моему мнению, должны приниматься решения, потому что в крупной организации у вас будет много распределенного принятия решений, — сказал Аматриайн. — И иногда, если вам повезет, эти принципы могут быть заложены в вашу культуру. Но по большей части, судя по моему опыту, это не так». За ними следуют процессы и инструменты, обеспечивающие их соблюдение. «Принципы очень красиво смотрятся на картинке на какой-нибудь стене, но тогда нужно сделать так, чтобы они имели реальную силу», — отметил он. Автоматизация располагается поверх обоих этих уровней.
На практике это реализуется через так называемые контрольные точки выпуска агентов в Expedia — шлюзы, откалиброванные в соответствии с рисками. «Управление должно соотноситься с риском, — сказал Аматриайн. — И если у вас что-то с низким уровнем риска, вам не нужно слишком много бюрократии, которая будет мешать. Но если рисков много, то требуется больше контроля. Это можно закодировать». Эти контрольные точки связывают раунды оценки, тесты на проникновение и проверку безопасности с уровнем риска каждого агента, причем по мере роста ставок проверки переходят из разряда рекомендуемых в разряд обязательных.
Специализированные агенты против монолитного интеллекта
«Даже когда я работал в Google, я говорил: я не верю в общий искусственный интеллект (AGI) как в нечто единое, вроде одиночной универсальной модели, — рассказал Аматриайн аудитории. — Я считаю, что гораздо лучше рассматривать его как композицию — иметь специализированных агентов, которые очень хорошо справляются с какой-то задачей, а затем собирать систему из этих специализированных агентов».
Архитектура Expedia начинается на уровне компонентов. Инструменты объединяются в навыки, навыки собираются в субагентов, а субагенты организуются в полноценную агентную систему. «Вам необходимы единые принципы, которые определяют такие вещи, как используемый нами тон, то, как мы обращаемся к пользователем, как мы передаем контекст и память, — сказал он. — Все это должно быть тщательно спроектировано». Он охарактеризовал это как системную проблему проектирования. «Дело не в модели, дело не в конкретном решении, а в том, как вы проектируете систему».
Аматриайн также отметил, что сужение сферы применения каждого агента делает систему более безопасной, поскольку команды могут оценивать и изолировать отдельных агентов перед их объединением.
Когда за пользователем остается финальный клик
Цены на путешествия меняются в режиме реального времени, доступность рейсов колеблется каждую минуту, а отзывы об отелях регулярно противоречат заявлениям поставщиков. Аматриайн описал систему, которая сочетает в себе генерацию с дополненной выборкой (RAG) и прямые вызовы инструментов через API, выбирая подход в зависимости от задержки. «Если пользователь задает вам вопрос вроде: „Сколько обычно стоит четырехзвездочный отель в Чикаго в июле?“, вы не ждете, что агент будет отвечать на этот вопрос две минуты», — сказал он. — Вы ждете немедленного ответа, потому что его можно закэшировать, и ему не нужна информация в реальном времени». А вот четырехзвездочный отель недалеко от озера Мичиган, где разрешено проживание с домашними животными и есть бассейн, может оправдать 30-секундное окно для логических рассуждений.
«Поставщик может заявлять: да, у нас отличный бассейн, но затем мы смотрим на отзывы путешественников и видим, что есть два отзыва о том, что бассейн был не очень хорошим или не работал после 18:00», — пояснил Аматриайн. Обычный чат-бот, добавил он, выведет только то, о чем заявляет сам поставщик, в то время как Expedia сопоставляет эти данные со своим собственным корпусом отзывов.
«Мы не хотим, чтобы агент бронировал отель или покупал вам авиабилет, — заявил Аматриайн. — Это то, где у пользователя должна быть свобода воли. Агент может рекомендовать, предлагать, обсуждать с вами, но нажать эту кнопку должны вы. И это не обсуждается». По его словам, это ограничение также является решением в области безопасности. «Как только вы устанавливаете эти принципы проектирования, вам также не нужны защитные механизмы, иначе вам придется внедрять всю эту защиту уже постфактум».
Следующими атакующими станут другие системы ИИ
«Безопасность должна быть принципом, который смещается как можно дальше влево [на ранние этапы разработки] и становится частью самого дизайна», — сказал Аматриайн, отвечая на вопрос из зала. — И обычно защитный механизм требуется тогда, когда вы не подумали об этом на ранней стадии».
Второй участник из зала попросил рассказать об уроках, извлеченных из практической работы. Аматриайн описал цикл обратной связи, в котором сигналы мониторинга поступают обратно в набор тестов. «Вы можете практически автоматизировать весь цикл, — сказал он. — Но наличие полной петли обратной связи от реальных сигналов вашей работающей системы ИИ до оперативного сообщения о проблемах и их устранения станет критически важным».
Контрольные точки Аматриайна — это расчет на то, что управление, откалиброванное с учетом рисков, сможет опережать эту петлю обратной связи. Отдельное июньское исследование Pulse компании VentureBeat, посвященное безопасности агентов и охватившее 107 предприятий, показывает, насколько тонкой является эта грань. Более половины (54 процента) уже сталкивались с инцидентами безопасности или ситуациями на грани инцидента, связанными с агентами. Пятьдесят девять процентов планируют внедрить, добавить или заменить инструменты безопасности агентов в течение 12 месяцев, а 29% планируют сделать это в текущем квартале. Частота инцидентов растет вместе с размером организации, достигая 63% среди предприятий с числом сотрудников более 1000 против 49% у компаний с числом сотрудников от 101 до 1000. А изоляция в песочнице (sandbox) — единственный контроль после взлома, который ограничивает ущерб — снижается с 35% внедрения в небольших компаниях всего до 20% в крупнейших.
Аматриайн предупредил, что угрозы все чаще будут исходить от других систем ИИ. «Вы столкнетесь с угрозами не только от людей, но и от других внешних агентных систем, которые очень мощны и будут выискивать уязвимости во всем, что вы делаете. И как только вы что-то обнаружите, решающее значение приобретает не только само обнаружение, но и время устранения».



