Приложения искусственного интеллекта: советы по расширенной архитектуре (также известные как AAAA!)

Сюрприз! Это бонусная запись в блоге к серии статей об искусственном интеллекте для веб-разработчиков, которую я недавно завершил. Если вы еще не читали эту серию, я советую вам это сделать. проверьте это .

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

Я буду обсуждать некоторые общие концепции и использовать в своих примерах конкретные продукты Akamai.

Базовая архитектура приложения

Существующее приложение довольно простое. Пользователь указывает двух противников, затем приложение возвращает сгенерированный ИИ ответ о том, кто победит в бою.

Архитектура также проста:

1. Клиент отправляет запрос на сервер.

   
   

2. Сервер создает приглашение и пересылает его в OpenAI.

   
   

3. OpenAI возвращает потоковый ответ на сервер.

   
   

4. Сервер вносит все необходимые корректировки и пересылает потоковый ответ клиенту.

Я пользовался услугами облачных вычислений Akamai (ранее называвшимися Линод ), но на самом деле это будет то же самое для любого хостинга.

🤵 выглядит как официант в модном ресторане, а 👁️‍🗨️ — это «глаз» или ИИ. лолз

Технически это работает нормально, но есть пара проблем, особенно когда пользователи делают повторяющиеся запросы. Было бы быстрее и экономичнее хранить ответы на нашем сервере и обращаться к OpenAI только для уникальных запросов.

Это предполагает, что нам не нужно, чтобы каждый отдельный запрос был недетерминированным (один и тот же ввод дает другой результат). Предположим, что один и тот же ввод может давать один и тот же результат — это нормально. В конце концов, прогноз о том, кто победит в бою, вряд ли изменится.

Добавить архитектуру базы данных

Если мы хотим хранить ответы от OpenAI, практичным местом для их размещения является некая база данных, позволяющая быстро и легко выполнять поиск по двум оппонентам. Таким образом, когда делается запрос, мы можем сначала проверить базу данных:

1. Клиент отправляет запрос на сервер.

   
   

2. Сервер проверяет существующую запись в базе данных, соответствующую введенным пользователем данным.

   
   

3. Если предыдущая запись существует, сервер отвечает этими данными, и запрос завершается. Пропустите следующие шаги.

   
   

4. Если нет, сервер следует шагу третьему в предыдущем потоке.

   
   

5. Прежде чем закрыть ответ, сервер сохраняет результаты OpenAI в базе данных.

Пунктирные линии обозначают необязательные запросы, а значок 💽 выглядит как жесткий диск.

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

Это хорошее начало, особенно если сервер и база данных находятся в одном регионе. Это позволит значительно сократить время ответа, чем обращение к серверам OpenAI.

Однако по мере того, как наше приложение становится все более популярным, у нас могут появиться пользователи со всего мира. Более быстрый поиск в базе данных — это хорошо, но что произойдет, если узким местом станет задержка из-за времени, проведенного в полете?

Мы можем решить эту проблему, переместив вещи ближе к пользователю.

Внедрение периферийных вычислений

Если вы еще не знакомы с термином «край», эта часть может вас сбить с толку, но я постараюсь объяснить это просто. Edge означает, что контент должен быть максимально приближен к пользователю. Для некоторых людей это может означать устройства Интернета вещей или вышки сотовой связи, но в случае с Интернетом каноническим примером является Сеть доставки контента (CDN) .

Я избавлю вас от подробностей, но CDN — это сеть глобально распределенных компьютеров, которые могут отвечать на запросы пользователей с ближайшего узла сети ( кое-что, о чем я писал раньше ). Хотя традиционно они разрабатывались для статических ресурсов, в последние годы они начали поддерживать периферийные вычисления ( также кое-что, о чем я писал раньше ).

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

Как это может повлиять на наше приложение?

1. Клиент отправляет запрос на наш бэкэнд.

   
   

2. Периферийная вычислительная сеть направляет запрос на ближайший пограничный узел.

   
   

3. Граничный узел проверяет наличие в хранилище значений ключа существующей записи, соответствующей вводу пользователя.

   
   

4. Если предыдущая запись существует, граничный узел отвечает этими данными, и запрос завершается. Пропустите следующие шаги.

   
   

5. Если нет, то пограничный узел пересылает запрос на исходный сервер, который передает его OpenAI и да-да-да-да.

   
   

6. Прежде чем закрыть ответ, сервер сохраняет результаты OpenAI в пограничном хранилище значений ключа.

Краевой узел представляет собой синий прямоугольник и обозначается 🔪, поскольку у него есть край, EdgeWorker — это продукт граничных вычислений Akamai, представленный 🧑‍🏭, а EdgeKV — хранилище ключей-значений Akamai, представленное 🔑🤑🏪. Пограничный блок находится ближе к клиенту, чем исходный сервер в облаке, что отражает физическое расстояние.

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

(Примечание: хотя данные кэшируются на границе, ответ по-прежнему создается динамически. Если вам не нужны динамические ответы, может быть проще использовать CDN перед исходным сервером и установить правильные HTTP-заголовки для кэшируйте ответ. Здесь много нюансов, и я мог бы сказать больше, но… ну, я устал и не очень хочу. Не стесняйтесь обращаться, если будут вопросы.)

Теперь готовим! На любые повторяющиеся запросы будут даны ответы практически мгновенно, при этом мы избавим нас от ненужных запросов к API.

Это разбирает архитектуру текстовых ответов, но у нас также есть изображения, сгенерированные ИИ.

Кэшируйте эти изображения

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

В текущем рабочем процессе пользователь делает запрос, который в конечном итоге попадает в OpenAI. OpenAI генерирует изображение, но не возвращает его. Вместо этого они возвращают ответ JSON с URL-адресом изображения, размещенного в инфраструктуре OpenAI.

С помощью этого ответа на страницу можно добавить тег <img> с использованием URL-адреса, который запускает другой запрос фактического изображения.

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

Хранилище объектов это гораздо более дешевое решение ( я тоже об этом писала ). Вместо использования URL-адреса OpenAI для изображения мы могли бы загрузить его в наш собственный экземпляр хранилища объектов и использовать вместо этого этот URL-адрес.

Это решает вопрос с хранилищем, но сегменты объектного хранилища обычно развертываются в одном регионе. Это повторяет проблему, с которой мы столкнулись при хранении текста в базе данных. Один регион может находиться далеко от пользователей, что может вызвать большую задержку.

Уже представив преимущества, было бы довольно просто добавить функции CDN только для статических ресурсов (честно говоря, каждый сайт должен иметь CDN). После настройки CDN будет извлекать изображения из хранилища объектов по первому запросу и кэшировать их для любых будущих запросов от посетителей в том же регионе.

Вот как будет выглядеть наш поток изображений:

1. Клиент отправляет запрос на создание изображения на основе своих оппонентов.

   
   

2. Пограничные вычисления проверяют, существуют ли уже данные изображения для этого запроса. Если да, он возвращает URL-адрес.

   
   

3. Изображение добавляется на страницу с URL-адресом, и браузер запрашивает изображение.

   
   

4. Если изображение ранее было кэшировано в CDN, браузер загружает его практически сразу. Это конец потока.

   
   

5. Если изображение ранее не было кэшировано, CDN извлечет изображение из места хранения объекта, закеширует его копию для будущих запросов и вернет изображение клиенту. Это еще один конец потока.

   
   

6. Если данные изображения отсутствуют в пограничном хранилище «ключ-значение», запрос на создание изображения поступает на сервер и в OpenAI, который генерирует изображение и возвращает информацию URL-адреса. Сервер запускает задачу по сохранению изображения в сегменте хранилища объектов, сохраняет данные изображения в пограничном хранилище пар «ключ-значение» и возвращает данные изображения в пограничные вычисления.

   
   

7. Используя новые данные изображения, клиент создает изображение, которое создает новый запрос и продолжает пятый шаг, описанный выше.

Сеть доставки контента обозначается грузовиком доставки (🚚) и сетевым сигналом (📶), а хранилище объектов обозначается носками в коробке (🧦📦) или предметами на складе. В этой подписи, вероятно, нет необходимости, так как я думаю, что она и так понятна, но я слишком горжусь своей игрой в смайлики и требую подтверждения. Спасибо, что побаловали меня. Продолжать.

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

Вуаля

Право на! Благодаря всем этим изменениям мы создали текст и изображения, сгенерированные искусственным интеллектом, для уникальных запросов и предоставляем кэшированный контент на периферии для повторяющихся запросов. Результатом является более быстрое время отклика и гораздо лучший пользовательский опыт (помимо меньшего количества вызовов API).

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

Например, в сети Akamai вы можете получить доступ к таким вещам, как брандмауэр веб-приложений (WAF) , распределенная защита от отказа в обслуживании (DDoS) , интеллектуальное обнаружение ботов , и более. Однако это все выходит за рамки сегодняшнего поста.

Итак, на данный момент я оставлю вам большое «спасибо» за чтение. Надеюсь, вы чему-то научились. И, как всегда, не стесняйтесь обращаться к нам в любое время с комментариями, вопросами или замечаниями.

Большое спасибо за чтение. Если вам понравилась эта статья и вы хотите меня поддержать, лучший способ сделать это — Поделиться , Подпишитесь на мою рассылку , и Подпишись на меня в Твиттере .

Первоначально опубликовано на austingil.com .