LLM Uygulamaları için Yeni Bir Mimari
(a16z.com)- a16z tarafından derlenen "LLM uygulama yığını için referans mimari"
Emerging LLM App Stack
Bağlamsal Veri
- Veri Hatları: Databricks, Airflow, Unstructured,..
- Embedding Modeli: OpenAI, Cohere, Hugging Face
- Vektör Veritabanı: Pinecone, Weaviate, Chroma, pgvector
Prompt Few-shot Örnekleri
- Playground: OpenAI, nat.dev, Humanloop
- Orkestrasyon: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
- API'ler/Eklentiler: Serp, Wolfram, Zapier,...
Sorgu ve Çıktı
- Uygulama Barındırma: Vercel, Steamship, Streamlit, Modal
- LLM Önbelleği: Redis, SQLite, GPTCache
- Loglama/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
- Doğrulama: Guardrails, Rebuff, Guidance, LMQL
LLM API'leri ve Barındırma
- Proprietary API: OpenAI, Anthropic
- Open API: Hugging Face, Replicate
- Bulut Sağlayıcısı: AWS, GCP, Azure, Coreweave
- Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...
Tasarım Kalıbı: In-context Learning
- In-Context Learning: LLM'i fine-tuning yapmadan olduğu gibi kullanıp, akıllı prompting ve bazı "bağlamsal" verilere dayalı koşullardan yararlanmak
- Örnek) Hukuki belgelere yanıt veren bir chatbot yaparken, naif bir yaklaşım tüm belgeleri ChatGPT'ye verip soru sormak olurdu; ancak bu yalnızca küçük veri kümelerinde mümkün. ChatGPT'nin en büyük modeli bile yaklaşık 50 sayfa işleyebiliyor
In-Context Learning'de ise yalnızca ilgili belgeler gönderilir ve yanıtlar bunların içinden alınır - Bu yüzden şu 3 aşamalı iş akışından oluşur
- Adım 1. Veri ön işleme / embedding
- Adım 2. Prompt oluşturma / vektör veritabanından ilgili belgeleri retrieval etme
- Adım 3. Prompt çalıştırma / çıkarım
- Çok iş gibi görünse de LLM'in kendisini eğitmek ve fine-tune etmekten çok daha kolay
Adım 1. [Veri ön işleme / embedding]
→ Bağlamsal Veri, Data Pipeline'dan geçip Embedding Modeli üzerinden Vektör Veritabanı'na kaydedilir
Bağlamsal Veri
- Metin belgeleri, PDF, CSV ve SQL tabloları
- Çoğu durumda veri yükleme ve dönüştürme için mevcut ETL araçları (Databricks, Airflow) aynen kullanılır
- Bazı durumlarda LangChain, LlamaIndex gibi orkestrasyon framework'lerine gömülü belge yükleyiciler kullanılır
- Yığının bu bölümünün hâlâ görece az gelişmiş olduğu düşünülüyor; LLM uygulamaları için özel olarak yapılmış veri replikasyonu çözümlerinde fırsat var
Embedding'ler
- Geliştiricilerin çoğu OpenAI API'sini kullanıyor (
text-embedding-ada-002modeli)- Kullanımı kolay, makul derecede iyi sonuç veriyor ve giderek ucuzluyor
- Bazı büyük şirketler Cohere'i araştırıyor. Belirli senaryolarda daha iyi performans sunuyor
- Açık kaynağı tercih eden geliştiriciler için Hugging Face'in Sentence Transformers kütüphanesi standart kabul ediliyor
- Ayrıca kullanım senaryosuna uygun farklı türlerde embedding üretmek de mümkün
- Bu niş bir alan ama umut verici bir araştırma konusu
Vektör Veritabanı
- Ön işleme hattının en önemli parçası vektör veritabanı
- En fazla milyarlarca embedding'i (vektörü) verimli biçimde depolama, karşılaştırma ve arama görevini üstlenir
- Piyasadaki en yaygın tercih Pinecone
- Tamamen bulutta barındırıldığı için başlamak kolay
- Büyük işletmelerin prodüksiyonda ihtiyaç duyduğu pek çok özelliğe sahip (iyi performans, SSO, uptime SLA vb.)
- Ancak kullanılabilir vektör veritabanı sayısı çok fazla. Özellikle:
- Weaviate, Vespa, Qdrant gibi açık kaynak seçenekler
- Tek düğümde çok iyi performans sunar ve belirli uygulamalara göre ayarlanabilir
- Kendi özel platformunu kurmayı tercih eden deneyimli yapay zeka ekipleri arasında popülerdir
- Chroma, Faiss gibi yerel vektör yönetim kütüphaneleri
- Harika bir geliştirici deneyimi sunar
- Küçük uygulamalar ve geliştirme deneyleri için kolayca kullanılabilir
- Tam ölçekli büyük veritabanlarının yerini almak için tasarlanmamıştır
- pgvector gibi OLTP eklentileri
- Tüm veritabanı ihtiyaçlarını Postgres içine sığdırmak isteyen geliştiriciler ya da veri altyapısının büyük kısmını tek bulut sağlayıcısından alan şirketler için vektör desteğinde iyi bir çözüm
- Uzun vadede vektör ve skaler iş yüklerini sıkı şekilde birleştirmenin mantıklı olup olmadığı net değil
- Weaviate, Vespa, Qdrant gibi açık kaynak seçenekler
- İleriye bakıldığında açık kaynak vektör veritabanı şirketlerinin çoğu bulut ürünleri geliştiriyor
- Araştırmamıza göre bulutta çok çeşitli kullanım senaryolarında yüksek performans sağlamak oldukça zor
- Bu yüzden bu tercihler kısa vadede değişmeyebilir, ancak uzun vadede değişme olasılığı yüksek
- Temel soru şu: Vektör veritabanları da OLTP ve OLAP örneklerinde olduğu gibi bir veya iki öne çıkan sistemde konsolide olacak mı?
- Bir başka soru da, çoğu modelde kullanılabilen context window büyüdükçe embedding ve vektör veritabanlarının nasıl evrileceği
- Tüm bağlamsal veriyi prompt'a koyabildiğiniz için embedding'e gerek kalmayacağını söylemek cazip gelebilir,
- ancak uzman geri bildirimleri embedding hatlarının giderek daha önemli hâle gelebileceğini söylüyor
- Büyük context window'lar güçlü bir araçtır ama ciddi hesaplama maliyetleri getirir. Bu yüzden onları verimli kullanmak önceliklidir
- Yakında farklı türlerde embedding modellerinin yaygınlaştığını, model ilişkilerine göre doğrudan eğitildiğini ve bunları verimli biçimde etkinleştirip kullanan vektör veritabanları gördüğümüz bir döneme girebiliriz
Adım 2. [Prompt oluşturma / retrieval]
- LLM prompting'i ile duruma uygun verileri birleştirme stratejileri giderek daha karmaşık hâle geliyor ve ürün farklılaştırmasının önemli bir kaynağına dönüşüyor
- Geliştiricilerin çoğu yeni projelere doğrudan talimatlardan oluşan basit prompt'larla (zero-shot prompting) veya birkaç örnek içeren prompt'larla (few-shot prompting) başlıyor
- Bu prompt'lar bazen iyi sonuç verse de prodüksiyon dağıtımı için gereken doğruluk seviyesine ulaşmıyor
- Prompting'in bir sonraki aşaması, model yanıtlarını belli bir doğruluk kaynağına dayandırmak ve modele eğitim almadığı dış bağlamı sağlamaktır
- Prompt Engineering Guide, 12 gelişmiş prompt stratejisini derliyor
- Tam da burada LangChain/LlamaIndex gibi orkestrasyon framework'leri öne çıkıyor
- Prompt chaining'in birçok ayrıntısını soyutluyorlar
- Harici API entegrasyonu, vektör veritabanından bağlamsal veri getirme, birden fazla LLM çağrısı arasında hafızayı koruma gibi işler yapıyorlar
- Ayrıca pek çok yaygın program için şablon da sağlıyorlar
- Çıktıları, dil modeline gönderilecek bir prompt veya birden fazla prompt oluyor
- Startup'lar ve hobi geliştiriciler arasında en yaygın kullanılanı LangChain
- LangChain hâlâ yeni bir proje (mevcut sürüm 0.0.220)
- Buna rağmen onunla geliştirilmiş uygulamaların prodüksiyona çıktığı görülmeye başlandı
- Bazı geliştiriciler, özellikle LLM erken benimseyenleri, bağımlılıkları azaltmak için prodüksiyonda saf Python'a geçmeyi tercih ediyor
- Ancak bize göre bu DIY yaklaşımı da web uygulama yığınında olduğu gibi zamanla azalacak (çoğu kişi framework kullanacak)
- Dikkatli okurlar orkestrasyon kutusunda ChatGPT'yi fark etmiş olabilir
- Genelde ChatGPT bir geliştirici aracı değil, bir uygulamadır; ama API üzerinden erişilebilir
- Bir bakıma bu orkestrasyon framework'lerine benzer şekilde çalışır (prompt soyutlama, durum koruma, eklentilerle bağlamsal veri arama vb.)
- Burada bahsedilen araçların doğrudan rakibi olmasa da ChatGPT alternatif bir çözüm olarak görülebilir. Hızlıca kurulup kullanılabilecek basit bir alternatif olabilir
Adım 3. [Prompt çalıştırma / çıkarım]
- Şu anda OpenAI, dil modellerinde lider konumda
- Neredeyse tüm geliştiriciler LLM uygulaması geliştirmeye GPT-4 ve GPT-4-32k modelleriyle başlıyor
- Kullanımı kolay, farklı alanlarda işe yarıyor ve fine-tuning ya da self-hosting gerektirmiyor
- İş prodüksiyona girip ölçek büyüdükçe çeşitli seçenekler mümkün hâle geliyor
gpt-3.5-turbo'ya geçiş:- 50 kattan fazla daha ucuz ve GPT-4'ten çok daha hızlı
- GPT-4 düzeyinde doğruluk gerekmiyorsa, hızlı yanıt süresi isteniyorsa veya ücretsiz kullanıcıları verimli biçimde desteklemek gerekiyorsa tercih edilir
- Diğer sağlayıcı modellerini denemek (özellikle Anthropic'in Claude modeli)
- Claude, hızlı çıkarım, GPT-3.5 seviyesinde doğruluk, daha fazla özelleştirme seçeneği ve 100k'ye kadar context window sunar (ancak uzadıkça doğruluk düşer)
- Bazı istekleri açık kaynak modellere yönlendirmek
- Sorgu karmaşıklığının değiştiği veya ücretsiz kullanıcıların düşük maliyetle servis edilmesi gereken arama/sohbet gibi büyük ölçekli B2C kullanım senaryolarında verimli olabilir
- Açık kaynak modeller şu an hâlâ kapalı ürünleri yakalamaya çalışıyor, ancak aradaki fark kapanmaya başladı
- Meta'nın LLaMA modeli, açık kaynak doğruluğunda yeni bir çıta belirledi ve pek çok varyantın ortaya çıkmasını sağladı
- LLaMA yalnızca araştırma amaçlı lisanslanmış olsa da birçok sağlayıcı alternatif temel modelleri (Together, Mosaic, Falcon, Mistral) eğitmek için bu alana girdi
- Meta'nın gerçek anlamda açık kaynak LLaMa 2 modelini yayımlaması tartışılıyor
- Açık kaynak LLM'ler GPT-3.5'e benzer doğruluk düzeyine ulaştığında, metin tarafında da Stable Diffusion anına benzer bir kırılma bekleniyor
- Büyük ölçekli deneyler, paylaşım ve fine-tune edilmiş modellerin prodüksiyona alınması gibi
- Replicate gibi barındırma şirketleri geliştiricilerin bu modelleri daha kolay kullanabilmesi için şimdiden araçlar ekliyor
- Daha küçük ama fine-tune edilmiş modellerin son teknoloji modellerin doğruluğuna yaklaşabileceğine dair geliştirici inancı büyüyor
- Konuştuğumuz geliştiricilerin çoğu LLM'ler için operasyon araçlarına henüz çok derin girmemişti
- Caching yaygın ve genelde Redis ile yapılıyor (yanıt süresi ve maliyeti iyileştirdiği için)
- Weights & Biases, MLFlow, PromptLayer, Helicone gibi araçlar da sık kullanılıyor
- Hızlı prompt üretimi, pipeline ayarı ve model seçimi için LLM çıktılarını loglayabilir, izleyebilir ve değerlendirebilirler
- LLM çıktılarını doğrulayan (Guardrails) veya prompt injection tespit eden (Rebuff) araçlar da hızla çoğalıyor
- Bu operasyon araçlarının çoğu LLM çağrılarını kendi Python istemcileriyle yapmayı önerdiği için, ileride bunların nasıl bir arada var olacağını görmek ilginç olacak
- Son olarak, LLM'in statik kısmı da (model dışındaki her şey) bir yerde barındırılmak zorunda
- En yaygın çözümler Vercel veya büyük bulut sağlayıcıları
- Ancak iki yeni kategori ortaya çıkıyor
- Steamship, LLM uygulamaları için uçtan uca barındırma sunuyor; orkestrasyon (LangChain), çok kiracılı veri bağlamı, asenkron görevler, vektör deposu, anahtar yönetimi gibi özellikler sağlıyor
- Anyscale ve Modal, geliştiricilerin modeli ve Python kodunu aynı anda barındırmasına olanak tanıyor
Peki ya Agent?
- Bu referans mimaride eksik olan en önemli unsur AI Agent framework'ü
- AutoGPT, "GPT-4'ü tamamen otonom hâle getirmeye yönelik açık kaynak bir deney" olarak bu bahar GitHub tarihinin en hızlı büyüyen reposu oldu
- Bugünlerde her AI projesinde bir şekilde agent bulunuyor
- Konuştuğumuz geliştiricilerin çoğu agent'ların potansiyeli konusunda çok heyecanlı
- Bu yazıda anlatılan in-context learning kalıbı, içerik üretim görevlerini daha iyi destekliyor ve halüsinasyon ile veri tazeliği sorunlarını çözmekte iyi
- Buna karşılık agent'lar AI uygulamalarına temelden yeni yetenekler kazandırıyor
- Karmaşık sorunları çözmek, dış dünyada aksiyon almak veya dağıtımdan sonra deneyimlerinden öğrenmek gibi
- Bunu gelişmiş akıl yürütme/planlama, araç kullanımı, hafıza/özyineleme/self-reflection kombinasyonuyla yapıyorlar
- Agent'lar, LLM uygulama mimarisinin merkezine yerleşebilir (özyinelemeyle kendi kendini geliştirmeye inanıyorsanız tüm yığını bile kaplayabilir)
- LangChain gibi framework'ler agent kavramını şimdiden entegre etti
- Tek sorun, agent'ların henüz gerçekten düzgün çalışmıyor olması
- Şu anda agent framework'lerinin çoğu PoC aşamasında — etkileyici demolar mümkün ama kararlı ya da tekrarlanabilir değiller
- Nasıl evrileceklerini izliyoruz
İleriye bakış
- Önceden eğitilmiş yapay zeka modelleri, internetten bu yana yazılımdaki en önemli mimari değişim
- Bu sayede her geliştirici, büyük ekiplerin aylarca uğraşarak yaptığı supervised machine learning projelerini aşan AI uygulamalarını birkaç günde geliştirebilir
- Burada tanıtılan araçlar ve kalıplar nihai durum değil; büyük olasılıkla LLM entegrasyonu için bir başlangıç noktası
6 yorum
İçgörü barındıran, birikimi hissettiren bir yazı olmuş.
Bu içerik temel alınarak LLM uygulama mimarisi tasarlarken çok yardımcı olacak gibi görünüyor.
Ekosistemde alan bazında net kazananlar olmadığı için pek çok çözümün bir arada bulunduğu bir durum var;
bu da seçim sorunlarını artırıyor ve buna uygun, senin gereksinimlerine uyan doğru kombinasyonu bulmanın bir yetkinlik haline geldiği bir dönemdeyiz gibi görünüyor.
Bu gerçekten çok dolu bir yazı. Sakin sakin okuyorum.
LLM'e GN öğretilirse guru-san da rahat eder mi? ^^;
Teşekkürler.
Aaa, GN+ yapmışsınız :-o
Daha rahat olacak gibi, ama sanırım böyle yazıları da öğrenme niyetine okumaya devam edeceğim. haha
GN⁺ diğer tüm haberleri hallederse, böyle yazıların daha da artması gibi bir etki de ortaya çıkabilir!
Güzel yazı ve özet için teşekkürler.