A16Z: Büyük Model Uygulamaları için Gelişmekte Olan Bir Mimari

Editörün notu: Üretken yapay zeka patlaması, biri yazılım sektörü olmak üzere birçok sektörü alt üst etme potansiyeline sahip. Büyük dil modelinin (LLM) yükselişi, ilgili uygulamaların patlamasını sağladı.Teknoloji devleri ve start-up'lar çeşitli LLM uygulamaları başlattı.Peki bu uygulamalar ne tür araçlar ve tasarım kalıpları kullanıyor? Bu makale özetlemektedir. Makale derlemeden alınmıştır.

Görsel kaynağı: Unbounded AI tarafından oluşturuldu

Büyük dil modelleri (LLM'ler), yazılım geliştirmek için güçlü yeni ilkel öğelerdir. Ancak LLM çok yeni olduğundan ve normal bilgi işlem kaynaklarından çok farklı davrandığından, LLM'nin nasıl kullanılacağı her zaman açık değildir.

Bu yazıda, ortaya çıkan LLM uygulama yığını için bir referans mimarisi paylaşacağız. Mimari, AI girişimleri ve en iyi teknoloji şirketleri tarafından kullanıldığını gördüğümüz en yaygın sistemleri, araçları ve tasarım modellerini sergileyecek. Bu teknoloji yığını hala nispeten ilkeldir ve temel teknoloji ilerledikçe büyük değişikliklere uğrayabilir, ancak bunun günümüzde LLM geliştirme üzerinde çalışan geliştiriciler için yararlı bir referans sağlayabileceğini umuyoruz.

Bu çalışma, AI girişimlerinin kurucuları ve mühendisleri ile yapılan görüşmelere dayanmaktadır. Özellikle Ted Benson, Harrison Chase, Ben Firshman, Ali Ghodsi, Raza Habib, Andrej Karpathy, Greg Kogan, Jerry Liu, Moin Nadeem, Diego Oppenheimer, Shreya Rajpal, Ion Stoica, Dennis Xu, Matei gibi kişilerin katkılarına güveniyoruz. Zaharia ve Jared Zoneraich. Yardımlarınız için teşekkürler!

LLM teknoloji yığını

LLM uygulama yığınının mevcut sürümü şöyle görünür:

Gri kutular temel bileşenlerdir ve oklu olanlar farklı veri akışlarını temsil eder: siyah noktalı çizgi, uygulama geliştiricisi tarafından çıktıyı sınırlamak için sağlanan bağlam verileridir, siyah düz çizgi bilgi istemidir ve LLM'ye iletilen birkaç örnek örnektir. ve mavi düz çizgi Kullanıcı sorgusu, kırmızı düz çizgi ise kullanıcıya döndürülen çıktıdır.

Hızlı başvuru için her bir öğeye bağlantıların bir listesi aşağıdadır:

, uygulama yığınının her bir temel bileşeni için ortak araçlar/sistemler

Sıfırdan eğitim modelleri, açık kaynak modellerinde ince ayar yapmak veya yönetilen API'lerden yararlanmak dahil olmak üzere LLM ile geliştirmenin birçok yolu vardır. Burada sunduğumuz teknoloji yığını, çoğu geliştiricinin yararlanmaya başladığını (ve şu anda yalnızca temel modellerle mümkün olduğunu) gözlemlediğimiz bir tasarım modeli olan bağlam içi öğrenmeye dayanmaktadır.

Bir sonraki bölümde bu tasarım modeli kısaca açıklanmaktadır.

Tasarım Modeli: Bağlamsal Öğrenme

Bağlamsal öğrenmenin temel fikri, kullanıma hazır LLM'lerden (yani herhangi bir ince ayar yapmadan) yararlanmak ve ardından akıllı ipuçları ve özel "bağlam" verileri üzerinde koşullandırma yoluyla davranışlarını kontrol etmektir.

Örneğin, bir dizi yasal belgeyle ilgili soruları yanıtlamak için bir sohbet robotu geliştirdiğinizi varsayalım. Basit yol, tüm belgeleri ChatGPT veya GPT-4 komut istemine yapıştırabilir ve ardından ilgili soruları sorabilirsiniz. Bu, çok küçük veri kümeleri için işe yarayabilir, ancak ölçeklenemez. En büyük GPT-4 modelleri yalnızca yaklaşık 50 sayfalık giriş metnini işleyebilir ve performans (çıkarım süresi ve doğrulukla ölçülür) bu sözde bağlam penceresi sınırına yaklaşıldığında ciddi şekilde düşer.

Bağlam öğrenimi, bu sorunu düzgün bir numarayla çözer: LLM bilgi istemi her girildiğinde tüm belgeleri göndermek yerine, yalnızca en alakalı birkaç tanesini gönderir. En alakalı belgelerin hangileri olduğuna karar vermeye kim yardımcı olacak? Tahmin ettin... LLM.

Çok yüksek düzeyde, bu iş akışı üç aşamaya ayrılabilir:

• Veri ön işleme/gömme: Bu aşama, daha sonra almak için özel verileri (bu durumda yasal belgeler) depolar. Genel olarak, belgeler parçalara bölünür, gömme modeline geçirilir ve vektör veritabanı adı verilen özel bir veritabanında saklanır.
• İstem oluşturma/geri alma: Bir kullanıcı bir sorgu gönderdiğinde (bu durumda yasal bir soru), uygulama bir dizi istem oluşturur ve bunlar daha sonra dil modeline gönderilir. Derlenmiş ipuçları genellikle geliştirici tarafından sabit kodlanmış ipucu şablonlarıyla birleştirilir; geçerli çıktı örneklerine birkaç örnek denir; gerekli tüm bilgiler harici bir API aracılığıyla alınır; ve bir dizi ilgili belge bir vektör veritabanından alınır.
• İpucu yürütme/çıkarma: İpuçları derlendikten sonra, çıkarım için özel model API'leri ve açık kaynaklı veya kendi kendine eğitilmiş modeller dahil olmak üzere önceden eğitilmiş LLM'lere gönderilir. Bu aşamada, bazı geliştiriciler ayrıca günlük kaydı, önbelleğe alma ve doğrulama gibi işletim sistemleri ekler.

Bunlar çok iş gibi görünebilir, ancak uygulanması genellikle diğer alternatiflerden daha kolaydır: LLM'yi eğitmek veya LLM'nin kendisine ince ayar yapmak aslında daha zordur. Bağlamsal öğrenme yapmak için makine öğrenimi mühendislerinden oluşan özel bir ekibe ihtiyacınız yoktur. Ayrıca kendi altyapınızı barındırmanız veya OpenAI'den pahalı, özel olarak ayrılmış bulut sunucuları satın almanız gerekmez. Bu model, yapay zeka sorunlarını, çoğu yeni başlayanın yanı sıra büyük şirketlerin zaten nasıl çözeceğini bildiği veri mühendisliği sorunlarına etkili bir şekilde indirger. Ayrıca, nispeten küçük veri kümeleri için ince ayardan daha iyi performans gösterme eğilimindedir, çünkü LLM'nin belirli bilgileri hatırlamak üzere ince ayarının yapılabilmesi için belirli bilgilerin eğitim setinde en az yaklaşık 10 kez gerçekleşmiş olması gerekir ve bağlamsal öğrenme de yeni bilgileri içerebilir. neredeyse gerçek zamanlı olarak.

Bağlam öğrenimindeki en büyük sorulardan biri şudur: Bağlam penceresini büyütmek için temeldeki modeli değiştirirsek ne olur? Gerçekten mümkün ve aktif bir araştırma alanı. Ancak bu, bazı değiş tokuşlarla birlikte gelir - esas olarak çıkarımın maliyeti ve süresi, ipucunun uzunluğuyla birlikte ikinci dereceden ölçeklenir. Günümüzde doğrusal ölçeklendirme (en iyi teorik sonuç) bile birçok uygulama için çok maliyetlidir. Mevcut API oranlarında, 10.000 sayfanın üzerindeki tek bir GPT-4 sorgusu yüzlerce dolara mal olur. Bu nedenle, genişletilmiş bağlam pencerelerine dayalı olarak yığında büyük ölçekli değişiklikler öngörmüyoruz, ancak bunu daha sonra daha ayrıntılı olarak ele alacağız.

Bu makalenin geri kalanında, yukarıdaki iş akışını kılavuz olarak kullanarak bu teknoloji yığınını inceleyeceğiz.

Veri işleme/gömme

Veri işleme/gömme kısmı: verileri vektörleştirme için veri boru hattı yoluyla gömülü modele iletin ve ardından vektör veritabanında saklayın

LLM uygulamaları için bağlam verileri metin belgelerini, PDF'leri ve hatta CSV veya SQL tabloları gibi yapılandırılmış biçimleri içerir. Görüştüğümüz geliştiriciler tarafından kullanılan veri yükleme ve dönüştürme (ETL) çözümleri çok çeşitliydi. Çoğu, Databricks veya Airflow gibi geleneksel ETL araçlarını kullanır. LangChain (Unstructed tarafından desteklenmektedir) ve LlamaIndex (Llama Hub tarafından desteklenmektedir) gibi bazıları, düzenleme çerçevesinde yerleşik olan belge yükleyicilerden de yararlanır. Ancak, teknoloji yığınının bu kısmının nispeten az gelişmiş olduğuna ve özellikle LLM uygulamaları için bir veri çoğaltma çözümü geliştirme fırsatı olduğuna inanıyoruz.

gömme'ye gelince, çoğu geliştirici OpenAI API'sini, özellikle de text-embedding-ada-002 modelini kullanır. Bu modelin kullanımı kolaydır (özellikle halihazırda diğer OpenAI API'lerini kullanıyorsanız), oldukça iyi sonuçlar verir ve giderek ucuzlamaktadır. Bazı büyük kuruluşlar, ürün çalışmaları daha çok yerleştirmeye odaklanan ve bazı senaryolarda daha iyi performans gösteren Cohere'ı da araştırıyor. Açık kaynağı tercih eden geliştiriciler için Hugging Face'in Sentence Transformers kitaplığı standarttır. Kullanım durumuna bağlı olarak farklı gömme türleri oluşturmak da mümkündür; bu, günümüzde nispeten niş bir uygulamadır, ancak umut verici bir araştırma alanıdır.

Sistem açısından, ön işleme hattının en önemli kısmı vektör veri tabanıdır. Bir vektör veritabanı, milyarlarcaya kadar gömmeyi (vektörler olarak da bilinir) verimli bir şekilde depolamaktan, karşılaştırmaktan ve almaktan sorumludur. Piyasada gördüğümüz en yaygın seçenek çam kozalağıdır. Varsayılandır, tamamen bulutta barındırıldığı ve büyük kuruluşların üretimde ihtiyaç duyduğu özelliklerin çoğuna sahip olduğu için (ör. ölçekte iyi performans, çoklu oturum açma ve çalışma süresi SLA'sı) başlaması kolaydır.

Bununla birlikte, çok sayıda vektör veri tabanı da mevcuttur. Önemli olanlar şunları içerir:

• Weaviate, Vespa ve Qdrant gibi Açık Kaynaklı Sistemler: Bu sistemler tipik olarak mükemmel tek düğümlü performansa sahiptir ve belirli uygulamalar için özelleştirilebilir, bu da onları özel platformlar geliştirmeyi seven deneyimli yapay zeka ekipleri arasında popüler kılar.
• Faiss ve diğerleri Yerel Vektör Yönetim Kitaplıkları: Bu kitaplıklar kapsamlı geliştirici deneyimine sahiptir ve küçük uygulamalar ve geliştirme deneyleri için kolayca başlatılabilir. Ancak bunlar, büyük ölçekte tam veritabanlarının yerini almayabilir.
• pgvector gibi OLTP uzantıları: Her veritabanı şeklinde boşluklar gören ve Postgres'e bağlanmaya çalışan geliştiriciler veya veri altyapılarının çoğunu tek bir bulut sağlayıcı Nice vektör destek çözümünden satın alan kuruluşlar için idealdir. Vektör ile skaler iş yüklerini sıkı bir şekilde birleştirmenin uzun vadede anlamlı olup olmadığı açık değildir.

İleriye dönük olarak, çoğu açık kaynak vektör veritabanı şirketi bulut ürünleri geliştiriyor. Araştırmamız, bulutta sağlam performans elde etmenin, olası kullanım durumlarının geniş tasarım alanında çok zor bir sorun olduğunu gösteriyor. Dolayısıyla, seçenek seti kısa vadede önemli ölçüde değişmeyebilir, ancak uzun vadede değişebilir. Anahtar soru, vektör veritabanlarının OLTP ve OLAP veritabanlarına benzer bir veya iki popüler sistem etrafında birleştirilip birleştirilemeyeceğidir.

Çoğu model için mevcut bağlam penceresi genişledikçe gömme ve vektör veritabanlarının nasıl gelişeceğine dair açık bir soru da var. Bağlamsal veriler doğrudan bilgi istemine konulabileceğinden, yerleştirmenin daha az önemli hale geldiğini kolayca iddia edebilirsiniz. Bununla birlikte, konuyla ilgili uzmanlardan alınan geri bildirimler, durumun tam tersi olduğunu, gömülü ardışık düzenlerin zaman içinde daha önemli hale gelebileceğini gösteriyor. Büyük bağlam pencereleri gerçekten güçlü araçlardır, ancak aynı zamanda önemli hesaplama maliyeti gerektirir. Bu nedenle, bu pencereden etkin bir şekilde yararlanmak zorunludur. Farklı gömme model türlerinin popüler hale geldiğini, doğrudan model alaka düzeyi üzerine eğitim verdiğini ve bunu etkinleştirmek ve kullanmak için tasarlanmış vektör veritabanlarının ortaya çıktığını görmeye başlayabiliriz.

Derlemeyi iste ve al

İnşa et ve al

LLM'yi teşvik eden ve bağlamsal verileri içeren stratejiler daha karmaşık hale geliyor ve aynı zamanda bir ürün farklılaştırma kaynağı olarak kullanılıyor ve rollerinin önemi artıyor. Çoğu geliştirici, doğrudan talimatlar (sıfır atış ipuçları) içeren basit ipuçları veya bazı örnekler (birkaç adım ipuçları) içerebilen çıktılar deneyerek yeni projelere başlar. Bu ipuçları genellikle iyi sonuçlar verir, ancak üretim dağıtımları için gereken doğruluk düzeyini sağlamaz.

İpucu hilelerinin bir sonraki seviyesi, modelin yanıtlarını bir hakikat kaynağına dayandırmak ve modelin üzerinde eğitilmediği dış bağlamı sağlamaktır. İşaret Mühendisliği Kılavuzu, düşünce zincirleri, kendi kendine tutarlı, üretken bilgi, düşünce ağaçları, yönlü uyaranlar ve daha fazlasını içeren en az bir düzine (!) daha gelişmiş ipucu stratejisi listeler. Bu stratejiler, belge Soru-Cevap, sohbet robotları vb. gibi farklı LLM kullanım durumlarını desteklemek için birleştirilebilir.

LangChain ve LlamaIndex gibi düzenleme çerçevelerinin devreye girdiği yer burasıdır. Bu çerçeveler, ipucu zincirleme, harici API'lerle etkileşim (bir API çağrısının ne zaman gerekli olduğunun belirlenmesi dahil), bir vektör veritabanından bağlam verilerinin alınması ve birden çok LLM'deki çağrılar arasında belleğin korunması gibi birçok ayrıntıyı soyutlar. Ayrıca yukarıda belirtilen yaygın uygulamaların çoğu için şablonlar sağlarlar. Çıktısı, dil modeline gönderilen bir ipucu veya bir dizi ipucudur. Bu çerçeveler, LangChain'in lider olduğu uygulama geliştirmek isteyen hobiler ve yeni başlayanlar tarafından yaygın olarak kullanılmaktadır.

LangChain hala nispeten yeni bir projedir (şu anda 0.0.201 sürümündedir), ancak onunla geliştirilen uygulamaların üretime geçtiğini şimdiden görmeye başlıyoruz. Bazı geliştiriciler, özellikle LLM'yi erken benimseyenler, ek bağımlılıkları kaldırmak için üretimde ham Python'a geçmeyi tercih ediyor. Ancak, geleneksel web uygulaması yığınlarında olduğu gibi, çoğu kullanım durumunda bu kendin yap yaklaşımının azalmasını bekliyoruz.

Dikkatli okuyucular, düzen kutusunda garip görünen bir giriş fark edecekler: ChatGPT. Normal şartlar altında ChatGPT bir uygulamadır, geliştirici aracı değildir. Ancak bir API olarak da erişilebilir. Ve yakından bakarsanız, diğer düzenleme çerçeveleriyle aynı işlevlerden bazılarını yerine getirir, örneğin: özel ipuçlarına olan ihtiyacı ortadan kaldırmak; durumu korumak; eklentiler, API'ler veya diğer kaynaklar aracılığıyla bağlamsal verileri almak. ChatGPT, burada listelenen diğer araçlara doğrudan bir rakip olmasa da, alternatif bir çözüm olarak kabul edilebilir ve hızlı oluşturmaya uygun, kolay bir alternatif haline gelebilir.

İpucu yürütme/akıl yürütme

İpucu yürütme/akıl yürütme

Bugün OpenAI, dil modelleri alanında liderdir. Görüştüğümüz hemen hemen her geliştirici, OpenAI API kullanarak yeni bir LLM uygulaması başlattı, genellikle gpt-4 veya gpt-4-32k modelini kullanıyorlar. Bu, uygulama performansı için en iyi kullanım senaryosunu sağlar ve çok çeşitli girdi etki alanlarını kullanabildiği ve genellikle ince ayar veya kendi kendine barındırma gerektirmediği için kullanımı kolaydır.

Bir proje üretime geçtiğinde ve ölçeklenmeye başladığında, daha geniş bir seçenek yelpazesi devreye girebilir. Duyduğumuz bazı yaygın sorular şunları içerir:

• gpt-3.5-turbo'ya geçin: bu, GPT-4'ten yaklaşık 50 kat daha ucuzdur ve çok daha hızlıdır. Birçok uygulama GPT-4 düzeyinde doğruluğa ihtiyaç duymaz, ancak düşük gecikmeli çıkarım ve ücretsiz kullanıcılar için uygun maliyetli destek için buna ihtiyaç duyar. *Diğer tescilli satıcılarla denenmiştir (özellikle Anthropic'in Claude modeli): Claude hızlı çıkarım, GPT-3.5 düzeyinde doğruluk, büyük istemciler için daha fazla özelleştirme seçeneği ve 100.000'e kadar bağlam pencereleri sunar (artan giriş uzunluğuyla doğruluğun azaldığını bulmamıza rağmen) .
• Açık kaynak modelleri için kısmi istekleri sınıflandırın: Bu, özellikle sorgu karmaşıklıklarının büyük ölçüde değiştiği ve ücretsiz kullanıcılara ucuza hizmet verilmesi gereken arama veya sohbet gibi yüksek hacimli B2C kullanım durumları için etkilidir:

1. Bu, genellikle açık kaynak temel modelinde ince ayar yapılmasıyla birlikte en mantıklı olanıdır. Bu makalede bu araç yığınına girmeyeceğiz ancak Databricks, Anyscale, Mosaic, Modal ve RunPod gibi platformlar mühendislik ekipleri tarafından giderek daha fazla kullanılıyor.

2. Açık kaynak modeller, Hugging Face ve Replicate'in basit API arayüzü, büyük bulut sağlayıcılarından ham bilgi işlem kaynakları ve yukarıda listelenenler gibi daha net tercihlere sahip bulut ürünleri (fikirli bulut) dahil olmak üzere birden çok çıkarım seçeneğini kullanabilir.

Şu anda açık kaynak modeli tescilli ürünlerin gerisinde kalıyor, ancak aradaki fark kapanmaya başlıyor. Meta'nın LLaMa modeli, açık kaynak doğruluğu için yeni standartlar belirledi ve bir dizi değişken ortaya çıkardı. LLaMa yalnızca araştırma kullanımı için lisanslandığından, birçok yeni sağlayıcı alternatif temel modelleri eğitmeye başlamıştır (örn. Together, Mosaic, Falcon, Mistral). Meta, hala LLaMa 2'nin gerçek bir açık kaynak sürümünü başlatıp başlatmamayı tartışıyor.

Açık kaynaklı LLM, GPT-3.5 ile karşılaştırılabilir doğruluk seviyelerine ulaştığında (eğer değilse), büyük ölçekli deneme, paylaşım ve ince ayar modellerinin üretime girmesiyle birlikte metnin kendi Kararlı Yayılma momentine sahip olduğunu görmeyi bekliyoruz. Replicate gibi barındırma şirketleri, bu modelleri yazılım geliştiriciler için daha erişilebilir hale getirmek için araçlar eklemeye başladı. Geliştiriciler, daha küçük, ince ayarlı modellerin dar bir kullanım durumu yelpazesi için son teknoloji doğruluk elde edebileceğine giderek daha fazla inanıyor.

Görüştüğümüz geliştiricilerin çoğu, LLM'nin operasyonel araçları hakkında derin bir anlayışa sahip değildi. Uygulama yanıt süresini iyileştirdiği ve maliyetleri azalttığı için önbelleğe alma nispeten yaygındır (genellikle Redis'e dayalıdır). MLflow (geleneksel makine öğreniminden taşınan) veya Layer with Helicone (LLM için oluşturulmuş) ile Ağırlıklar ve Önyargılar gibi araçlar da oldukça yaygın olarak kullanılmaktadır. Bu araçlar, genellikle uç yapımını iyileştirmek, boru hatlarını ayarlamak veya model seçmek amacıyla LLM'nin çıktısını kaydedebilir, izleyebilir ve değerlendirebilir. LLM çıktısını doğrulamak (örn. Guardrails) veya ipucu enjeksiyon saldırılarını tespit etmek (örn. Rebuff) için geliştirilmekte olan birçok yeni araç da bulunmaktadır. Bu operasyonel araçların çoğu, kendi Python müşterilerini LLM çağrıları gerçekleştirmeye teşvik eder, bu nedenle bu çözümlerin zaman içinde nasıl bir arada var olduğunu görmek ilginç olacaktır.

Son olarak, LLM uygulamasının statik kısmının (yani model dışındaki her şeyin) de bir yerde barındırılması gerekir. Şimdiye kadar gördüğümüz en yaygın çözümler, Vercel veya büyük bulut sağlayıcıları gibi standart seçeneklerdir. Ancak, iki yeni kategori ortaya çıkıyor. Steamship gibi girişimler, düzenleme (LangChain), çok kiracılı veri bağlamı, eşzamansız görevler, vektör depolama ve anahtar yönetimi dahil olmak üzere LLM uygulamaları için uçtan uca barındırma sağlar. Anyscale ve Modal gibi şirketler, geliştiricilerin modelleri ve Python kodunu tek bir yerde barındırmasına olanak tanır.

Proxy'ler ne olacak?

Bu referans mimaride eksik olan en önemli bileşenlerden biri yapay zeka aracı çerçevesidir. AutoGPT, "GPT-4'ü tamamen otomatikleştirmeye yönelik deneysel bir açık kaynak girişimi" olarak tanımlandı ve bu bahar, tarihteki en hızlı büyüyen Github deposu oldu ve bugün neredeyse her yapay zeka projesi veya girişimi, .

Konuştuğumuz geliştiricilerin çoğu, proxy'lerin potansiyeli konusunda çok heyecanlıydı. Bu yazıda tanımladığımız bağlamsal öğrenme modeli, halüsinasyonları ve veri tazeliği sorunlarını etkili bir şekilde ele alabilir, böylece içerik oluşturma görevlerini daha iyi destekler. Aracılar ise yapay zeka uygulamaları için yepyeni bir dizi yetenek sağlar: karmaşık sorunları çözme, dış dünyaya göre hareket etme ve dağıtım sonrası deneyimden öğrenme. Bu, gelişmiş muhakeme/planlama, araç kullanımı ve hafıza/yineleme/kendini yansıtan düşünmenin bir kombinasyonu yoluyla yapılır.

Bu nedenle aracılar, LLM uygulama mimarisinin temel bir parçası olma potansiyeline sahiptir (hatta yinelemeli kişisel gelişime inanıyorsanız, tüm teknoloji yığınını devralabilir). LangChain gibi mevcut çerçeveler zaten vekil kavramının bir bölümünü içermektedir. Tek bir sorun var: Proxy'ler henüz gerçekten çalışmıyor. Günümüzde çoğu aracı çerçevesi, inanılmaz gösteriler sunan ancak görevleri güvenilir ve tekrarlanabilir bir şekilde yerine getirmeyen, hala kavram kanıtı aşamasındadır. Yakın gelecekte proxy'nin nasıl geliştiğini yakından izliyoruz.

Geleceğe bakmak

Önceden eğitilmiş AI modelleri, internetten bu yana yazılım mimarisindeki en önemli değişikliği temsil eder. Bireysel geliştiricilerin, büyük ekipler tarafından geliştirilmesi aylar süren denetimli makine öğrenimi projelerini bile geride bırakarak günler içinde inanılmaz yapay zeka uygulamaları oluşturmasına olanak tanır.

Burada listelediğimiz araçlar ve modeller, LLM'yi entegre etmek için bir bitiş noktası değil, bir başlangıç noktası olabilir. Ayrıca, önemli değişiklikler olduğunda (örneğin, model eğitimine geçiş) güncelleme yaparız ve mantıklı olan yerlerde yeni referans mimarileri yayınlarız.