Диалог с Amazon Web Services Май-Лан: Следующее поле боя S3, как справиться с бумом потребления данных в эпоху Агентов

null

В начале года взрывной рост OpenClaw на рынке Китая показал всем огромный потенциал агента. Но за этим последовал вопрос, на который должны были ответить все облачные провайдеры: когда агент начнет безумно размножаться и часто вызывать данные, как кибер-омары, готова ли облачная инфраструктура ИИ, особенно слой данных?

Например, при развертывании агента в производственной среде команда данных часто сталкивается с узкими местами на уровне данных. Построение агентов на различных платформах — векторных баз данных, реляционных баз данных, графовых баз данных и озерных хранилищ — требует синхронизации каналов данных для поддержания актуальности контекстной информации. Но в реальных условиях эта контекстная информация со временем устаревает.

Актуальность этой проблемы обусловлена принципиально отличающимися моделями потребления данных агентами и человеком-инженером.

«Агент потребляет данные очень активно и агрессивно, его частота вызовов к хранилищам данных или озерам данных удивительна.»

Недавно в беседе с автором заместитель технического директора Amazon Web Services Май-Лан Томсен Буковек отметил, что агент — это режим работы с «параллельным отбором лучших», то есть: не один запрос за раз, а десятки или сотни параллельных, сравниваемых для поиска оптимального пути. Это делает агента гораздо более агрессивным потребителем данных, чем человек — частота вызовов выше на несколько порядков, пропускная способность данных растет экспоненциально.

Май-Лан добавила: «Сейчас клиенты очень хотят построить инфраструктуру для агентов, стоимость или, точнее, соотношение цена/качество уже не является второстепенным фактором, а становится решающим. В ближайшие полгода — год, с ростом числа агентов, выбор базовых сервисов данных станет критически важным.»

Теперь же, когда буйство OpenClaw утихает, остается только предупреждение о необходимости стресс-тестирования возможностей базовых вычислительных и хранилищных ресурсов облачных провайдеров. Май-Лан считает, что Amazon Web Services обладает естественными преимуществами в этой области: масштаб Amazon S3 (Amazon Simple Storage Service), эффективность затрат Amazon Redshift и Amazon Athena при высокой нагрузке — все это подготовлено для сверхмасштабных и сверхчастых взаимодействий данных с агентами.

В честь 20-летия продукта Amazon S3, в контексте требований клиентов к обработке данных в эпоху ИИ, Amazon S3 недавно реализовал три крупные инновации: S3 Table (табличный формат), S3 Files (файлы) и S3 Vector (векторы).

Например, S3 Table поддерживает нативную интеграцию с Apache Iceberg. Май-Лан отметила, что при обработке данных агент предпочитает взаимодействовать с данными в формате SQL и Iceberg напрямую. Логика в том, что агент строится на больших моделях, а эти модели уже в процессе обучения сформировали зрелые навыки работы с синтаксисом SQL и форматом данных Iceberg. Хранение всех таблиц в формате Iceberg в S3 позволяет агенту эффективно работать с данными без необходимости изучать множество сложных API доступа. В настоящее время агент хорошо сочетается с S3 и Iceberg.

Когда возможности Iceberg были внедрены в S3, началась новая волна инноваций: источники данных, такие как Postgres и Oracle, начали напрямую писать в Iceberg, а системы агентов — взаимодействовать с этими таблицами. А с появлением S3 Vectors все больше приложений ИИ используют векторы как носители общего памяти, что добавляет «состояние» в взаимодействие с ИИ.

Май-Лан также отметила, что векторы были введены как нативный тип данных в S3. Их применение сосредоточено в двух направлениях: во-первых, для построения контекстной информации из данных, хранящихся в S3, во-вторых — как средство общего запоминающегося пространства. За пять месяцев после релиза S3 Vectors рынок дал ожидаемый отклик: множество клиентов начали использовать эту функцию, создавая векторы с помощью embedding-моделей для обогащения контекста данных. Использование S3 Vectors в системе памяти агента демонстрирует взрывной рост.

Стоит отметить, что S3 Files был выпущен несколько недель назад, позволяя агентам обрабатывать данные в S3 через POSIX-совместимый интерфейс, то есть через файловую систему. В системах агентов большие модели очень ориентированы на «файлы» — будь то библиотеки Python или скрипты Shell, — это привычные для обучения модели формы данных. Агент по своей природе склонен воспринимать файлы как интерфейс данных.

Для этого идея S3 Files — смонтировать файловую систему EFS на бакет S3. Благодаря этому механизмy пользователь может работать с данными S3 через POSIX-стандарт: небольшие файлы кэшируются для ускоренного доступа, большие — передаются потоково прямо из S3. Это позволяет агентам взаимодействовать с данными S3 на уровне привычной файловой системы и рассматривать совместную файловую систему как «общее запоминающее пространство» из S3.

С точки зрения развития памяти больших моделей, это важный шаг. Современный опыт ИИ постепенно вводит более глубокий диалоговый контекст и персонализированное взаимодействие — между агентами, между человеком и агентом, а также между агентами и данными. Расширение интерфейса через файловую систему обещает значительно усилить память системы агентов.

Автор заметил, что с 2006 года, когда доминировали полуструктурированные данные, такие как изображения, и далее — аналитические данные, от первых хранилищ данных до появления озерных хранилищ, Amazon Web Services активно продвигает Amazon S3 как ключевую платформу для ИИ-рабочих нагрузок, чтобы соответствовать текущим требованиям клиентов. Май-Лан считает, что ядро дизайна Amazon S3 — это экономичный рост основных типов данных, при этом неизменно соблюдаются принципы доступности, долговечности и устойчивости данных. Именно поэтому клиенты на протяжении 20 лет доверяют свои данные S3, и это, вероятно, станет платформой для их следующего 20-летия.

(Автор статьи | Ян Ли, редактор | Ян Лин)