Yapay Zeka Uygulamaları: Gelişmiş Mimari Önerileri (AKA AAAA!)

Sürpriz! Bu, yakın zamanda tamamladığım Web Geliştiricileri için Yapay Zeka serisine yönelik bir bonus blog yazısıdır. Eğer henüz bu seriyi okumadıysanız, okumanızı tavsiye ederim. buna bir bak .

Bu yazıda mevcut proje mimarisine ve onu hem uygulama geliştiricileri hem de son kullanıcı için geliştirebileceğimiz yollara bakacağız.

Örneklerimde bazı genel kavramları tartışacağım ve belirli Akamai ürünlerini kullanacağım.

Temel Uygulama Mimarisi

Mevcut uygulama oldukça basittir. Bir kullanıcı iki rakip gönderir ve ardından uygulama, dövüşte kimin kazanacağına dair yapay zeka tarafından oluşturulan bir yanıtı geri gönderir.

Mimari de basittir:

1. İstemci sunucuya bir istek gönderir.

   
   

2. Sunucu bir istem oluşturur ve istemi OpenAI'ye iletir.

   
   

3. OpenAI, sunucuya bir akış yanıtı döndürür.

   
   

4. Sunucu gerekli ayarlamaları yapar ve akış yanıtını istemciye iletir.

Akamai'nin bulut bilişim hizmetlerini kullandım (eski adıyla Linode ), ancak bu aslında herhangi bir barındırma hizmeti için aynı olacaktır.

🤵 lüks bir restorandaki sunucuya benziyor ve 👁️‍🗨️ "göz" veya yapay zeka anlamına geliyor. haha

Teknik olarak bu iyi çalışıyor ancak özellikle kullanıcılar yinelenen isteklerde bulunduğunda birkaç sorun ortaya çıkıyor. Yanıtları sunucumuzda depolamak ve yalnızca benzersiz istekler için OpenAI'ye gitmek daha hızlı ve daha uygun maliyetli olabilir.

Bu, her isteğin deterministik olmamasına ihtiyacımız olmadığını varsayar (aynı girdi farklı bir çıktı üretir). Aynı girdinin aynı çıktıyı üretmesinin sorun olmadığını varsayalım. Sonuçta bir kavgada kimin kazanacağına dair tahmin muhtemelen değişmeyecekti.

Veritabanı Mimarisi Ekle

OpenAI'den gelen yanıtları depolamak istiyorsak, bunları koyabileceğimiz pratik bir yer, iki rakibi kullanarak hızlı ve kolay arama yapılmasına olanak tanıyan bir tür veritabanıdır. Bu şekilde bir istek yapıldığında önce veritabanını kontrol edebiliriz:

1. İstemci sunucuya bir istek gönderir.

   
   

2. Sunucu, veritabanında kullanıcının girdisiyle eşleşen mevcut bir girdiyi kontrol eder.

   
   

3. Önceki bir kayıt mevcutsa sunucu bu verilerle yanıt verir ve istek tamamlanır. Aşağıdaki adımları atlayın.

   
   

4. Değilse, sunucu önceki akıştaki üçüncü adımdan devam eder.

   
   

5. Yanıtı kapatmadan önce sunucu, OpenAI sonuçlarını veritabanında saklar.

Noktalı çizgiler isteğe bağlı istekleri temsil eder ve 💽 türü bir sabit diske benzer.

Bu kurulumla, yinelenen istekler veritabanı tarafından işlenecektir. OpenAI isteklerinden bazılarını isteğe bağlı hale getirerek potansiyel olarak kullanıcıların yaşadığı gecikme miktarını azaltabilir, ayrıca API isteklerinin sayısını azaltarak paradan tasarruf edebiliriz.

Bu iyi bir başlangıçtır, özellikle de sunucu ve veritabanı aynı bölgede bulunuyorsa. Bu, OpenAI sunucularına gitmekten çok daha hızlı yanıt süreleri sağlayacaktır.

Ancak uygulamamız popülerleştikçe dünyanın her yerinden kullanıcı almaya başlayabiliriz. Daha hızlı veritabanı aramaları harikadır, ancak darboğaz uçuşta geçirilen süreden kaynaklanan gecikmeyse ne olur?

Nesneleri kullanıcıya yaklaştırarak bu endişeyi giderebiliriz.

Edge Compute'u getirin

Eğer “kenar” terimine henüz aşina değilseniz bu kısım kafa karıştırıcı olabilir ama basit bir şekilde açıklamaya çalışacağım. Edge, içeriğin kullanıcıya mümkün olduğunca yakın olmasını ifade eder. Bazı insanlar için bu, Nesnelerin İnterneti cihazları veya cep telefonu baz istasyonları anlamına gelebilir, ancak web söz konusu olduğunda, kanonik örnek, İçerik Dağıtım Ağı (CDN) .

Ayrıntıları size vermeyeceğim ancak CDN, ağdaki en yakın düğümden gelen kullanıcı isteklerine yanıt verebilen, küresel olarak dağıtılmış bilgisayarlardan oluşan bir ağdır ( geçmişte yazdığım bir şey ). Geleneksel olarak statik varlıklar için tasarlanmış olsalar da son yıllarda uç bilişimi desteklemeye başladılar ( ayrıca geçmişte yazdığım bir şey ).

Edge hesaplamayla, arka uç mantığımızın çoğunu kullanıcıya çok yakın bir yere taşıyabiliriz ve bu işlemle bitmez. Çoğu uç bilgi işlem sağlayıcısı aynı uç düğümlerde bir tür sonuçta tutarlı anahtar/değer deposu da sunar.

Bu durum uygulamamızı nasıl etkileyebilir?

1. İstemci arka uçumuza bir istek gönderir.

   
   

2. Edge hesaplama ağı, isteği en yakın uç düğüme yönlendirir.

   
   

3. Kenar düğümü, anahtar-değer deposunda kullanıcının girişiyle eşleşen mevcut bir girişi kontrol eder.

   
   

4. Önceki bir kayıt mevcutsa kenar düğüm bu verilerle yanıt verir ve istek tamamlanır. Aşağıdaki adımları atlayın.

   
   

5. Aksi takdirde uç düğüm, isteği kaynak sunucuya iletir ve o da bunu OpenAI'ye ve yadda yadda yadda'ya iletir.

   
   

6. Yanıtı kapatmadan önce sunucu, OpenAI sonuçlarını uç anahtar/değer deposunda saklar.

Kenar düğümü mavi kutudur ve bir kenarı olduğundan 🔪 ile temsil edilir, EdgeWorker, Akamai'nin 🧑‍🏭 ile temsil edilen uç bilişim ürünüdür ve EdgeKV, Akamai'nin 🔑🤑🏪 ile temsil edilen anahtar/değer deposudur. Kenar kutusu, fiziksel mesafeyi temsil etmek için istemciye buluttaki kaynak sunucudan daha yakındır.

Origin sunucusu burada kesinlikle gerekli olmayabilir, ancak orada olma ihtimalinin daha yüksek olduğunu düşünüyorum. Veri, bilgi işlem ve mantık akışı açısından bu çoğunlukla önceki mimariyle aynıdır. Temel fark, önceden saklanan sonuçların artık kullanıcılara çok yakın olması ve neredeyse anında geri döndürülebilmesidir.

(Not: Veriler uçta önbelleğe alınsa da yanıt yine de dinamik olarak oluşturulur. Dinamik yanıtlara ihtiyacınız yoksa, başlangıç sunucusunun önünde bir CDN kullanmak ve doğru HTTP başlıklarını ayarlamak daha kolay olabilir. yanıtı önbelleğe alın. Burada çok fazla nüans var ve daha fazlasını söyleyebilirim ama… yani, yorgunum ve gerçekten söylemek istemiyorum. Sorularınız olursa bize ulaşmaktan çekinmeyin.)

Şimdi yemek pişiriyoruz! Yinelenen isteklere neredeyse anında yanıt verilecek ve aynı zamanda gereksiz API isteklerinden de kurtulacağız.

Bu, metin yanıtlarının mimarisini çözüyor, ancak aynı zamanda yapay zeka tarafından oluşturulan görsellerimiz de var.

Bu Görüntüleri Önbelleğe Alın

Bugün ele alacağımız son şey resimlerdir. Görüntülerle uğraşırken teslimat ve depolamayı düşünmemiz gerekiyor. Eminim OpenAI'deki kişilerin kendi çözümleri vardır, ancak bazı kuruluşlar güvenlik, uyumluluk veya güvenilirlik nedeniyle tüm altyapıya sahip olmak ister. Bazıları OpenAI kullanmak yerine kendi görüntü oluşturma hizmetlerini bile çalıştırabilir.

Mevcut iş akışında kullanıcı, sonuçta OpenAI'ye giden bir istekte bulunur. OpenAI görüntüyü oluşturur ancak döndürmez. Bunun yerine, OpenAI'nin altyapısında barındırılan görüntünün URL'sini içeren bir JSON yanıtı döndürürler.

Bu yanıtla, URL kullanılarak sayfaya bir <img> etiketi eklenebilir ve bu, gerçek görüntü için başka bir isteği başlatır.

İmajı kendi altyapımızda barındırmak istiyorsak onu saklayacak bir yere ihtiyacımız var. Görüntüleri kaynak sunucunun diskine yazabiliriz, ancak bu, disk alanını hızla tüketebilir ve sunucularımızı yükseltmek zorunda kalabiliriz, bu da maliyetli olabilir.

Nesne depolama çok daha ucuz bir çözümdür ( Bu konuda da yazdım ). Görüntü için OpenAI URL'sini kullanmak yerine onu kendi nesne depolama örneğimize yükleyebilir ve onun yerine bu URL'yi kullanabiliriz.

Bu, depolama sorununu çözer ancak nesne depolama paketleri genellikle tek bir bölgeye dağıtılır. Bu, metni bir veritabanında saklama konusunda yaşadığımız sorunu yansıtıyor. Tek bir bölge kullanıcılardan uzakta olabilir ve bu da çok fazla gecikmeye neden olabilir.

Edge'i zaten tanıttıktan sonra, yalnızca statik varlıklar için CDN özellikleri eklemek oldukça önemsiz olacaktır (açıkçası her sitenin bir CDN'si olmalıdır). Yapılandırıldıktan sonra CDN, ilk istek üzerine görüntüleri nesne deposundan çekecek ve aynı bölgedeki ziyaretçilerin gelecekteki istekleri için bunları önbelleğe alacaktır.

Resimlere yönelik akışımız şu şekilde görünecektir:

1. Bir müşteri, rakiplerine dayalı bir görüntü oluşturmak için bir istek gönderir.

   
   

2. Edge hesaplama, söz konusu isteğe ilişkin görüntü verilerinin zaten mevcut olup olmadığını kontrol eder. Eğer öyleyse, URL'yi döndürür.

   
   

3. Resim, URL'nin bulunduğu sayfaya eklenir ve tarayıcı, resmi ister.

   
   

4. Görüntü daha önce CDN'de önbelleğe alınmışsa tarayıcı onu hemen yükler. Bu akışın sonudur.

   
   

5. Görüntü daha önce önbelleğe alınmamışsa CDN, görüntüyü nesne depolama konumundan çeker, gelecekteki istekler için bir kopyasını önbelleğe alır ve görüntüyü istemciye geri gönderir. Bu da akışın başka bir sonu.

   
   

6. Görüntü verileri uç anahtar/değer deposunda değilse, görüntüyü oluşturma isteği sunucuya ve ardından görüntüyü oluşturan ve URL bilgisini döndüren OpenAI'ye gider. Sunucu, görüntüyü nesne depolama paketine kaydetmek için bir görev başlatır, görüntü verilerini uç anahtar/değer deposunda saklar ve görüntü verilerini uç bilişime geri döndürür.

   
   

7. Yeni görüntü verileriyle istemci, yeni bir istek oluşturan görüntüyü oluşturur ve yukarıdaki beşinci adımdan devam eder.

İçerik dağıtım ağı, bir teslimat kamyonu (🚚) ve bir ağ sinyali (📶) ile gösterilir ve nesne depolama, bir kutudaki çoraplar (🧦📦) veya depodaki nesnelerle gösterilir. Bunların açık olduğunu düşündüğüm için bu başlık muhtemelen gerekli değil, ancak emoji oyunumla fazlasıyla gurur duyuyorum ve doğrulamaya ihtiyacım var. Beni şımarttığın için teşekkür ederim. Sürdürmek.

Bu son mimarinin biraz daha karmaşık olduğu kabul edilir, ancak uygulamanız ciddi bir trafiği yönetecekse dikkate almaya değer.

işte

Kesinlikle doğru! Tüm bu değişiklikler uygulandığında, benzersiz istekler için yapay zeka tarafından oluşturulan metin ve resimler oluşturduk ve yinelenen istekler için önbelleğe alınmış içeriği uçtan sunduk. Sonuç, daha hızlı yanıt süreleri ve çok daha iyi bir kullanıcı deneyimidir (daha az API çağrısına ek olarak).

Bu mimari diyagramlarını çeşitli veritabanları, uç bilişim, nesne depolama ve CDN sağlayıcıları genelinde uygulanabilir olarak tuttum. İçeriğimin geniş çapta uygulanabilir olmasını seviyorum. Ancak kenarı entegre etmenin performanstan daha fazlası olduğunu belirtmekte fayda var. Etkinleştirebileceğiniz çok sayıda harika güvenlik özelliği de var.

Örneğin Akamai'nin ağında aşağıdaki gibi şeylere erişebilirsiniz: web uygulaması güvenlik duvarı (WAF) , dağıtılmış hizmet reddi (DDoS) koruması , akıllı bot tespiti , ve dahası. Ancak bunların hepsi bugünkü yazının kapsamı dışında.

Şimdilik, okuduğunuz için size kocaman bir “teşekkür ederim” ile baş başa bırakıyorum. Umarım bir şeyler öğrenmişsindir. Ve her zaman olduğu gibi yorumlarınız, sorularınız veya endişeleriniz için istediğiniz zaman bize ulaşmaktan çekinmeyin.

Okuduğunuz için çok teşekkür ederim. Bu makaleyi beğendiyseniz ve bana destek olmak istiyorsanız bunu yapmanın en iyi yolu: Paylaş , bültenime kaydol , Ve beni Twitter'da takip et .

İlk olarak şu tarihte yayınlandı: austingil.com .