- 2020’lerin başında üretken yapay zekaya büyük ilgi yoğunlaştı
- Tartışmaların odağında, üretken yapay zeka araçlarının bizi nasıl şekillendireceği; yazma, kodlama, animasyon ve bilgi tüketme biçimimizi nasıl etkileyeceği vardı
- Ancak araçlarımızın biçimi hakkında pek fazla şey söylenmedi
- 1960’ların sonlarında bilgi sistemleri, çok büyük miktarda veri nedeniyle ilgili bilgiyi bulmanın giderek daha maliyetli hale gelmesi sorunuyla karşı karşıya kaldı
- 1980’ler ve 90’larda ilişkisel veritabanları baskın çözüm haline geldi
- Sezgisel indeksleme sundular ve sorgu verimliliğini güvence altına aldılar
- İlişkisel veritabanları, veriyi yapılandırılmış ilişkiler içeren tablo koleksiyonları olarak ifade etmeyi mümkün kıldı
- SQL gibi sorgu dilleri aracılığıyla daha hızlı veri erişimi sağladılar
- Veritabanı mimarisi evrilirken IBM, Oracle, Sun Microsystems ve MongoDB gibi belirli şirketler ortaya çıkan pazarların her birinde güçlü bir konum edindi
- Oracle ilişkisel veritabanı dünyasına liderlik etti, ancak insanların bilgiyi depolama ve ona erişme biçimi değişmeye devam etti
- Her yeni iş yüküyle birlikte insanlar, bunu yönetmek için yeni mimariler tasarladı
- Veritabanlarının son dönemdeki evrimi, yapılandırılmamış veriyi işleme ihtiyacından doğdu
- Son 50 yılı aşkın sürede şemalar büyük ölçüde yapılandırılmış veri ilişkileri etrafında kuruldu
- Ancak giderek daha fazla insan, veri belirsizliğini çok daha iyi ele alabilen araçlara ihtiyaç duymaya başladı
- Bunun sonucunda vektör veritabanları ortaya çıktı
- GPT gibi transformer tabanlı büyük dil modelleri (LLM), metindeki uzun vadeli bağımlılıkları yakalayabilir
- Ancak uzun metinleri anlama yetisini korumak hesaplama açısından maliyetli olabilir
- Vektör veritabanları, bu modellerin bağlam penceresini genişletebilir
- Vektör veritabanları yapay zeka kullanım senaryolarında güçlü olabilse de, hâlâ girdi ve çıktıyla çalışan aptal bir altyapıdır
- Veriyi anlama ya da yorumlama becerisinden yoksundur
- Yalnızca kendisine söylendiği şekilde veriyi depolayan ve geri getiren bir depo görevi görür; özünde zekâsı ya da durumsal farkındalığı yoktur
- 2020’de GPT-3’ün yayımlanmasıyla yapay zeka, şirket ürünlerinin bir eki değil, giderek daha fazla çekirdeği haline gelmeye başladı
- Transformer mimarisi, artan veri miktarı ve performans iyileştirmeleri yapay zeka tabanlı ürün geliştirmenin temelini attı
- AI-Native (yapay zeka tabanlı) şirketler arttıkça ve büyüdükçe, yapay zeka tabanlı kullanım senaryolarını destekleyecek araçlara olan ihtiyaç da yükseldi
- İlk dalgadaki yapay zeka merkezli şirketler çoğunlukla mevcut modellerle yapılan çıkarıma odaklandı
- Ancak performansı iyileşmiş modellerin, özellikle de kolay erişilebilen açık kaynak modellerin, yaygınlaşmasıyla şirketler yapay zeka tabanlı bir işletme olarak yetkinliklerini daha derinlemesine inşa edebilir hale geldi
- Bu ölçeklenebilirlik, yapay zeka tabanlı teknoloji yığınının nasıl görünebileceğine dair bir fırsatlar dünyasının kapısını açıyor
Bizi Şekillendiren Araçlar (The Tools that Shape Us)
- 1967’de Marshall McLuhan’ın arkadaşı John M. Culkin, “Biz araçları yaparız, sonra araçlar bizi yapar” dedi
- Teknoloji inşa etmek de farklı değildir
- Yazılım yapmak için kullandığımız altyapı, inşa ihtiyaçlarımıza uyacak şekilde sürekli evrildi; ardından inşa ettiklerimiz de kurduğumuz altyapı tarafından şekillendirildi
- 2020’lerin başında üretken yapay zekaya büyük ilgi yoğunlaştı
- Özellikle üretilen metin ya da kod, render edilen görseller, oluşturulan deepfake’ler ve sentezlenen müzik gibi çıktılara odaklanıldı
- Tartışmaların odağında, bu araçların bizi nasıl şekillendireceği; yazma, kodlama, animasyon ve bilgi tüketme biçimimizi nasıl etkileyeceği vardı
- İnsanlar açık ve kapalı kaynak büyük dil modellerinin karşılaştırmalı performansını, halüsinasyon riskini, platforma karşı özellik tartışmasını ve yerleşik şirketler ile startup’lar arasındaki tartışmayı konuştu
- Ancak araçlarımızın biçimi hakkında pek fazla şey söylenmedi
- Temelde, teknolojiyi inşa etme biçimimiz, bu inşa için kurduğumuz altyapı tarafından şekillendirildi
- SaaS’ın yaygınlaşması internet tarafından hızlandırıldı, akıllı telefonların yaygınlaşması mobil geliştirmeyi mümkün kıldı ve cloud computing uygulama nesillerinin ölçeklenmesini teşvik etti
- Uygulamalarda yapay zekanın yaygınlığı; bilgi işlem kapasitesine, model yeteneklerine ve bu modellerin iş kullanım senaryoları içinde nasıl orkestre edildiğine bağlıdır
- Bu yazı, orkestrasyon unsuruna odaklanacaktır
- Tüm yapay zeka kullanım senaryolarını orkestre etmede temel unsurlardan biri şirketin veritabanıdır
- Verinin depolandığı, işlendiği ve çağrıldığı yer, bu yapbozun önemli bir parçasıdır
- Ancak göstereceğimiz gibi, veritabanlarının tarihi büyük ölçüde aptal altyapının tarihidir
- Yapay zekanın faydasını en üst düzeye çıkarmak için veritabanlarını üretim denkleminin bir parçası olacak şekilde tasarlamamız gerekecek
Veri İçin Bir Temel (A Base For Data)
- Mayıs 1959'da CODASYL (Conference on Data Systems Languages) ilk kez toplandı ve "iş uygulamaları oluşturmak için genel amaçlı bir dil" geliştirmeyi hedefledi
- 1960'ların sonlarında bilgi sistemleri, çok büyük miktardaki veri nedeniyle ilgili bilgilere erişme sürecinin giderek daha maliyetli hale gelmesi sorunuyla karşı karşıya kaldı
- Mainframe bilgisayarların kullanımı, genellikle uygulama bakımı, yamalar ve performansı korumak için gereken yükseltme maliyetleri nedeniyle, mainframe kullanımının artmasına paralel olarak MIPS (saniye başına milyonlarca komut) maliyetlerinin yükselmesine yol açtı
- Veritabanı yönetiminin karmaşıklığı, katı hiyerarşiler ve karmaşık gezinme yapısı eşlemeleri nedeniyle şirketler, istedikleri bilgiye erişmek için çoğu zaman teknik uzmanlığa ihtiyaç duyuyordu; hatta bazı geliştiriciler ilgili bilgilere erişmek için baştan sona program yazmak zorunda kalıyordu
- 1970'te E.F. Codd, "A Relational Model of Data for Large Shared Data Banks" makalesini yayımlayarak, tabloların ortak özellikler (yani benzersiz kayıtları tanımlayan birincil anahtarlar ve tablolar arası ilişkileri kuran yabancı anahtarlar) üzerinden birbirine bağlanabileceği bir model önerdi
- Bu sayede tek bir sorguyla heterojen tablolardan veri alınabilir hale geldi
- Codd'un ilişkisel veritabanı yaklaşımı, veri öğeleri arasındaki ilişkilere dayanarak veri işleme ve kullanımında esneklik sağladı
- 1973'te IBM San Jose Research Laboratory'deki bir programcı grubu, ilişkisel veritabanı sistemlerinin üretim kullanımı için gereken eksiksiz işlevleri entegre ederken yine de yüksek performans sunabileceğini göstermek amacıyla System R projesine başladı
- Bu ekip, veritabanı verimliliği için maliyet tabanlı bir optimize edici geliştirdi ve System R'den türeyen çalışmalar daha sonra IBM'in ilk ilişkisel veritabanı ürünü olan SQL/DS'nin piyasaya sürülmesine yol açtı
- 1980'ler ve 90'larda ilişkisel veritabanları baskın veritabanı çözümü haline geldi
- Sezgisel indeksleme sağlıyor ve sorgu verimliliğini güvence altına alıyordu
- İlişkisel veritabanları, verilerin yapılandırılmış ilişkiler içeren tablo koleksiyonları olarak ifade edilmesini mümkün kıldı
- SQL gibi sorgu dilleri sayesinde daha hızlı veri erişimi sağlandı
- İlişkisel veritabanları, tek bir makinede çalışacağı varsayımıyla inşa edildi
- Ancak 1990'lar ve 2000'lerde internetin kitlesel olarak benimsenmesi, muazzam miktarda veri akışına yol açtı ve bu da tek bir bilgisayarın kaldıramayacağı kadar ağır iş yükleri oluşturdu
- Geleneksel SQL veritabanları tek bir sunucuda çalışacak şekilde tasarlanmıştı ve kullanıcıların depolama kapasitesine uyacak biçimde fiziksel donanımı büyütmesi gerekiyordu; bu da daha büyük iş yükleri işleten şirketler için son derece maliyetli olduğunu kanıtladı
- 2010'larda OLTP (online transaction processing) verileri ve kullanıcı sayısı katlanarak arttı; bu da dağıtık veritabanları, veri ambarları ve OLAP'in (online analytical processing) yaygın biçimde büyümesine yol açtı
- İlişkisel veritabanları ve SQL, artık gerekli uygulama ölçeği ve karmaşıklığı için uygun değildi; NoSQL veritabanları da performansı artırmanın bir yolu olarak ortaya çıktı (ACID özelliklerinden feragat edilerek)
- İlişkisel veritabanları yapılandırılmış veriyi depolayıp işleyebiliyordu, ancak join maliyetleri ve CRUD işlemlerinin bedeli düşünüldüğünde, veriler arasındaki ilişkileri sürdürmek zordu
- İlişkisel veritabanları, mantıksal ya da ayrık gereksinimleri olan ilişkisel verileri işlemek için uygundu, ancak genellikle özellikle ilişkisel yapı için inşa edilmiş legacy sistemlere göre şekillenmişti
- NoSQL, yapılandırılmamış büyük veriyi işlemek için ilişkisel olmayan bir yaklaşım sunarak geliştiricilere veri kalıcılığı sağlayan bir araç olarak ortaya çıktı
- SQL'i temel sorgu dili olarak kullanmak yerine NoSQL, API üzerinden erişim sağlayarak daha yüksek ölçeklenebilirlik, dağıtık hesaplama, daha düşük maliyet ve şema esnekliği sundu
- NoSQL veritabanları yatay ölçeklenebilen verimli mimarilerle çalıştığından, depolama ya da hesaplama kapasitesini artırmak için yalnızca daha fazla sunucu veya bulut instance'ı eklemek yeterliydi
- Yapılandırılmamış verinin daha hızlı işlenmesi ya da analizine yönelik iş yükleri olan şirketlerde NoSQL veritabanları tercih edildi
OG veritabanı savaşları
- Veritabanı mimarileri evrilirken, belirli şirketler ortaya çıkan her pazarda konumlarını sağlamlaştırdı
- IBM, System R'yi piyasaya sürdükten kısa süre sonra, 33 yaşındaki Larry Ellison da Codd'un ilişkisel veritabanlarıyla ilgili aynı makalesini okudu
- Ellison ve iki kurucu ortağı, System R ile uyumlu bir şirket kurmak istedi ancak IBM bunu oldukça zorlaştırdı
- Sonuç olarak bu üçlü, yeni amiral gemisi veritabanı ürünü Oracle Databases etrafında işlerini kurdu
- O günden bu yana Oracle'ın veritabanı lider ürün oldu ve Mayıs 2024 itibarıyla pazar payı yaklaşık %28,7 seviyesinde
- Oracle'ın 1986'daki halka arzından hemen önceki yıllarda, başka bir şirket daha veritabanı alanına girdi
- Sun Microsystems, 1982'de çeşitli bilgisayar bileşenleri satarak başladı, ancak Java programlama dili ve Network File System gibi katkılarıyla tanınır hale geldi
- Daha da önemlisi, Sun Microsystems 2008'de MySQL adlı açık kaynaklı bir veritabanı yönetim sistemini satın aldı
- Sadece iki yıl sonra Oracle, Sun Microsystems'i (MySQL dahil) satın aldı
- Yaklaşık 15 yıl sonra, Mayıs 2024 itibarıyla önde gelen veritabanları Oracle (pazar payı %28,7) ve MySQL (yaklaşık %17,3) oldu
- Oracle, ilişkisel veritabanı dünyasına liderlik etmiş olsa da insanların bilgiyi depolama ve erişme biçimi değişmeye devam etti
- Her yeni iş yüküyle birlikte insanlar bunu yönetmek için yeni mimariler geliştirdi
- MongoDB (2007), Databricks (2013) gibi doküman depolarından InfluxDB (2013), Prometheus (2012) gibi zaman serisi veritabanlarına ve Neo4j (2007), Cosmos (2017) gibi grafik veritabanlarına kadar uzmanlaşmış veritabanlarının listesi giderek uzuyor
- İlişkisel veritabanlarının popülaritesi istikrarlı biçimde azalırken, bu yeni niş ihtiyaçlar için çeşitli çözümler ortaya çıktı
- Veritabanlarının en güncel evrimi, yapılandırılmamış veriyi işleme ihtiyacından doğdu
- Son 50 yıldan uzun süredir şemalar esas olarak yapılandırılmış veri ilişkileri etrafında kuruluydu
- Ancak giderek daha fazla kişi, veri belirsizliğini çok daha iyi ele alabilen araçlara ihtiyaç duymaya başladı
- Bunun sonucunda vektör veritabanları ortaya çıktı
Vektör veritabanlarının yükselişi
- Büyük dil modellerinin (LLM) ve üretken yapay zekanın yaygın biçimde benimsenmesiyle birlikte, vektör veritabanları yapılandırılmamış çok modlu verileri işleyebilen araçlar olarak öne çıktı
- Geleneksel ilişkisel veritabanları (Postgres, MySQL) yapılandırılmış şemalar için en uygunken, vektör veritabanları vektör embedding’lerini (dil modelinin ağırlıklarına göre göreli anlam içeren verinin sayısal temsili) depolamak ve sorgulamak için uygundur
- İlişkisel veritabanlarında yaygın olarak kullanılan satır ve sütunlar yerine, vektör veritabanları veriyi çok boyutlu uzaydaki noktalar olarak temsil eder ve tam değerlere göre değil benzerliğe göre eşleştirme yapar
- Embedding modeline bağlı olarak veri, farklı vektör uzaylarında ve çeşitli boyutlarda temsil edilebilir
- Vektör embedding’leri veri noktalarının anlamını yakalayarak, vektör veritabanında en yakın nesneleri bularak benzer nesnelerin aranmasını mümkün kılar
- Örneğin Word2Vec, kelimeleri vektörlere eşleyerek anlamı, anlamsal benzerliği ve diğer metinlerle bağlamsal ilişkileri yakalamaya yardımcı olur
- Bu algoritma, sığ bir sinir ağı kullanarak daha geniş bir metin külliyatından belirli bir kelimenin anlamını türetir ve lojistik regresyon yoluyla eş anlamlıları belirler
- Tekil değer ayrışımı (SVD) ve temel bileşen analizi (PCA) gibi, derin sinir ağlarına dayanmadan embedding çıkarmaya yardımcı olan yöntemler de vardır
- Uzaklık metrikleri, vektör uzayındaki noktalar arasındaki göreli "mesafeyi" belirlemeye yardımcı olur; yaygın yöntemler arasında Öklid mesafesi, Manhattan mesafesi, kosinüs mesafesi ve Jaccard benzerliği yer alır
- K-en yakın komşu (KNN) ve yaklaşık en yakın komşu (ANN), görüntü, video veya diğer çok modlu girdiler için benzerlik aramasını basitleştirerek çalışma süresini iyileştirmeye yardımcı olur
- Weaviate, Chroma, Qdrant ve Pinecone gibi yalnızca vektöre odaklı veritabanları, geliştiricilerin özellikle yapılandırılmamış girdiler dahil büyük ölçekli veriler üzerinde arama yapmayı kolaylaştırmasına yardımcı olur
- Geleneksel ilişkisel veritabanları veya NoSQL veritabanlarından farklı olarak, vektör veritabanları özellikle vektör embedding’lerini işlemek için tasarlanmıştır
- Geleneksel veritabanları veriyi skaler olarak depolarken, vektör veritabanları yalnızca vektör depolar ve niceleme ile kümeleme gibi indeksleme tekniklerinden yararlanarak arama işlemlerini optimize eder
- GPT gibi transformer tabanlı LLM’ler metindeki uzun vadeli bağımlılıkları yakalayabilir
- Ancak uzun metinleri anlama yetisini korumak hesaplama açısından maliyetli olabilir
- Güncel LLM’ler girdideki token çiftleri arasındaki küresel bağımlılıkları yakalayabilse de, zaman ve alan karmaşıklığı nedeniyle hesaplama kaynağı sorunları ortaya çıkar; bu da eğitim sırasında girdi metni uzunluğunu ve çıkarım sırasında etkili bağlam penceresini sınırlar
- Çok boyutlu durumlarda göreli konum kodlamasını uygulamak zordur ve göreli konumu kodlayan çoğu yaklaşım, çıkarım sırasında performans düşüşüne katkıda bulunan güçlü konum embedding mekanizmaları gerektirir
- Metin uzunluğu arttığında da vektör veritabanları modelin uzun süreli belleği olarak önemli olabilir
- Vektör veritabanları kullanmak, tam cümle bağlamının doğru sonuç üretmek için gerekli olabildiği metin tamamlama veya özetleme gibi görevleri kolaylaştırabilir
- Vektör veritabanları retrieval-augmented generation (RAG) yaklaşımını destekleyebilir; burada vektör veritabanı, LLM’e iletilen prompt’u, orijinal sorguyla birlikte ek bağlam sağlayarak güçlendirmek için kullanılabilir
- LLM’ler çoğu zaman self-supervised learning modellerine dayandığından, belirli bilgi veya daha yüksek doğruluk eşiği gerektiren alan özelindeki görevlerde zorlanabilir
- RAG, söz konusu sorguya ilişkin bağlam eksikliğinden kaynaklanabilecek halüsinasyonları azaltırken, yanıtların nasıl üretildiğini doğrulamaya, izlemeye veya açıklamaya yardımcı olabilir
- Geliştiriciler, bilgi grafikleri ile vektör aramayı birleştirerek LLM’leri eğitildikleri verinin ötesine genişletebilir
- Microsoft Research’ün GraphRAG gibi araçları, özel veri kümeleri üzerinde arama yapılırken prompt güçlendirmeyi kolaylaştırır
- Temel RAG, büyük veri koleksiyonlarındaki özetlenmiş anlamsal kavramları bütünsel olarak anlamakta sık sık zorlandığından, LlamaIndex ve GraphRAG gibi araçlar özel veri kümelerine dayalı bilgi grafikleri oluşturur
- Geliştiriciler, belirli gereksinimlere veya kullanım senaryolarına göre RAG yerine bilgi grafiği kullanmayı tercih edebilir
- Vektör veritabanları benzerlik araması için uygundur ve belge ya da görüntü arama ile öneri üretimi için daha elverişliyken, bilgi grafikleri akıl yürütme için daha uygundur (özellikle veri toplama, birbirine bağlı ilişkilerle birlikte varlık çıkarımı ve bu ilişkiler arasında gezinme sırasında faydalıdır)
- Gerçek zamanlı veya yarı gerçek zamanlı veri işleme gerektiren uygulamalarda, daha düşük gecikmeli sorgular nedeniyle vektör veritabanları tercih edilebilir
- Embedding’leri toplayıp depolayarak vektör veritabanları, girilen prompt’u benzer embedding’lerle eşleştirip benzerlik aramalarında daha hızlı erişim sağlar
- Benzerlik sıralaması; öneri sistemleri, anlamsal arama, görüntü tanıma ve diğer doğal dil işleme uygulamalarına kadar uzanan çeşitli makine öğrenimi görevlerini desteklemeye yardımcı olur
- Vektör veritabanları, vektör embedding’lerinin verimli şekilde depolanmasını ve alınmasını mümkün kılarak LLM performansını artırmada kritik bir rol oynar
- Bu sayede doğal dili büyük ölçekte otomatik olarak anlamak mümkün olur
- Ancak vektör embedding’leri N+1 inovasyonunu temsil eder
- İlişkisel veya zaman serisi verileri gibi önceki veri formatlarının devamı niteliğindedir
- Eski veritabanı sağlayıcıları da MongoDB’nin Atlas Vector Search’ü, SingleStore’un vektör veritabanı ve Neo4J’in vektör arama indeksleri gibi vektör özellikleri sunmaya başladı
- Vektör veritabanları yapay zeka kullanım senaryolarında güçlü olabilse de, hâlâ girdi ve çıktılarla çalışan aptal bir altyapıdır
- Veriyi anlama veya yorumlama yeteneğinden yoksundur
- Sadece kendisine söylendiği gibi veriyi depolayan ve geri getiren bir depo görevi görür; doğuştan gelen bir zekâsı ya da bağlamsal farkındalığı yoktur
- Modern yapay zeka tabanlı uygulamalar için bu tek başına yeterli olmayacaktır
- Şirketler giderek daha fazla AI modellerini merkeze alarak inşa ediliyor
- Bu nedenle uygulamalar giderek daha akıllı yetenekler sergiledikçe, altyapının da aynı ölçüde akıllı yeteneklere sahip olması gerekecektir
1. Nesil AI-Native Şirketler
- 1956’da Dartmouth College’da akademi ilk kez yapay zekayı araştırmaya başladığından beri, pratik kullanım örnekleri bu alanı ileri taşıdı
- Örneğin 1960’ların sonlarında Joseph Weizenbaum, ELIZA adlı bir bilgisayar programı geliştirdi; kalıp eşleştirme yoluyla konuşmayı simüle eden bu basit yaklaşım, ilkel terapi benzeri diyaloglarda kullanıldı (ilk chatbot)
- İş dünyasındaki kullanım senaryolarında yapay zekanın kullanıldığı tarihin büyük bölümünde, yapay zekadaki iyileşmeler kademeliydi
- “AI” terimi popüler hale gelmeden önce, aynı teknolojiyi ifade etmek için daha sık “makine öğrenimi” terimi kullanılıyordu
- Yani, “veriden öğrenebilen ve görülmemiş verilere genelleme yapabilen, açık talimatlar olmadan görevleri yerine getirebilen istatistiksel algoritmalar”
- Kamusal algı açısından yapay zeka, 30 Kasım 2022’de OpenAI’nin ChatGPT’yi kullanıma sunmasıyla bir kırılma noktasına ulaştı, ancak teknik açıdan dönüm noktası çok daha önce yaşanmıştı
- Kasım 2017’de uluslararası düzenleyici kuruluş Finansal İstikrar Kurulu (FSB), makine öğreniminin finansal hizmetler üzerindeki etkisine ilişkin bir genel bakış hazırladı
- Finansal hizmet şirketleri, “kredi kalitesinin değerlendirilmesi” gibi görevleri yerine getirmek için giderek daha fazla makine öğrenimi kullanıyor ve bununla “daha verimli bir finansal sisteme katkıda” bulunabiliyordu
- Yani verimliliği artırabiliyordu, ancak varoluşsal bir zorunluluk oluşturmuyordu
- Bu arada makine öğrenimi giderek daha iyi hale geldi ve Mayıs 2018’de OpenAI, büyük ölçekli model eğitimi için gereken hesaplama geçmişine dair bir araştırma yayımladı; bu araştırma, 2012’den sonra hesaplama gücünün her 3,4 ayda bir ikiye katlandığını ve toplamda 300 bin kat arttığını gösteriyordu
- Ertesi ay, Haziran 2018’de OpenAI, GPT modeline dair ilk tanıtımı yayımladı
- İki kamp arasında bir tartışma şekilleniyordu
- Bir tarafta, giderek büyüyen modellerin sürekli büyümesinin azalan getiri yasasına takılacağına inanan çok sayıda kişi vardı
- OpenAI’nin de içinde bulunduğu diğer kamp ise, ölçek büyüdükçe performansın artmaya devam edeceğine inanıyordu
- Ocak 2020’de OpenAI araştırmacısı ve Johns Hopkins Üniversitesi profesörü Jared Kaplan, başkalarıyla birlikte “Scaling Laws for Neural Language Models” adlı makaleyi yayımladı; burada şu ifade yer alıyordu:
- “Model boyutunu, veriyi ve hesaplamayı uygun şekilde ölçeklendirdikçe, dil modelleme performansı düzgün ve öngörülebilir biçimde iyileşir. Daha büyük dil modellerinin mevcut modellere kıyasla daha iyi performans göstermesini ve örnek verimliliğinin daha yüksek olmasını bekliyoruz.”
- Mayıs 2020’de OpenAI, GPT-3 hakkında “Language Models are Few-Shot Learners” başlıklı makaleyi yayımladı; bu çalışma, hesaplama artışıyla birlikte performansın pürüzsüz biçimde ölçeklendiğini gösteriyordu
- OpenAI ayrıca, ölçeği artırmanın genelleme kabiliyetini de iyileştirdiğini buldu ve “büyük dil modellerinin ölçeklendirilmesi, görevden bağımsız few-shot performansını ciddi ölçüde geliştirerek, zaman zaman önceki en ileri fine-tuning yaklaşımlarıyla rekabet edebilir hale getiriyor” iddiasında bulundu
- Bağımsız araştırmacı Gwern Branwen, bir blog yazısında ölçeklendirme hipotezini ortaya koydu ve şöyle dedi:
- “OpenAI’nin Mayıs 2020’de yayımladığı GPT-3, şimdiye kadar eğitilmiş en büyük sinir ağlarından biridir ve büyüklüğü bir basamaktan da fazladır... Pek çok kişinin (benim de dahil) beklentisinin aksine, ölçekteki bu devasa artışla birlikte, OpenAI’nin öngördüğü gibi ölçeğin faydaları ortaya çıkmaya devam etti ve birçok kişinin beklediği azalan getiriler ya da negatif getirilere çarpmadı.”
- Branwen’in hissettiği bu şaşkınlık, manzaranın değişmiş olmasından kaynaklanıyordu
- Yapay zeka artık şirket ürünlerinin bir eklentisi değil, giderek daha fazla çekirdeği olarak kullanılabiliyordu
- Transformer mimarisi, artan veri miktarı ve yükselen performans seviyeleri, yapay zeka tabanlı ürün geliştirme için gerekli zemini birlikte hazırladı
- GPT-3’ün yayımlanmasından hemen sonra, Mayıs 2020’de Writer ve Jasper gibi şirketler, yapay zeka modellerini işlerinin merkezine koyan metin yazarlığı ürünleri geliştirdi
- Harvey ve EvenUp gibi şirketler, hukuki teknoloji ürünlerini yapay zeka etrafında inşa etti
- DeepScribe ve Freed gibi şirketler, tıbbi transkripsiyonu yapay zeka etrafında kurdu
- Ancak geçmişte yeni kullanım örneklerinin veritabanı evrimini tetiklemesi gibi, yapay zeka tabanlı ürünlerin doğuşu da her şirketin teknoloji yığınının arkasındaki altyapının değişmesi ve uyum sağlaması gerektiği anlamına geliyordu
AI-Native Veritabanı
- Yapay zeka tabanlı şirketlerin sayısı artıp ölçek büyüttükçe, yapay zeka tabanlı kullanım senaryolarını destekleyen araçlara duyulan ihtiyaç da arttı
- Yapay zeka merkezli şirketlerin ilk dalgası, çoğunlukla mevcut modellerle yapılan çıkarıma odaklandı
- Uygulamalar, metin yazarlığı, tıbbi transkripsiyon ve benzeri alanlar için amaca özel iş akışı araçlarına sahiptiler
- Ürünün çekirdeği, modelin ürettiği metin ya da üretilen görseller gibi çıktılardı
- Kasım 2023’teki OpenAI DevDay’in ardından, “OpenAI girişimimi mahvetti” mem’i yayılmaya başladı
- Belirli uzman GPT’ler ya da AI agent’lar, mevcut modellerin çıkarım yeteneklerine odaklandıkları için bu ilk yapay zeka tabanlı girişimlerin rolünü üstleniyor gibi görünüyordu
- OpenAI tesadüfen hem modelin hem de uygulamanın sağlayıcısı haline geldi
- Model yetenekleri etrafında dönen inovasyon o kadar hızlı ilerliyordu ki startup’lar için bir tehdit gibi hissedilmeye başladı
- Ancak tersine, performansı artan modellerin varlığı (özellikle de kolay erişilebilen açık kaynak modeller), şirketlerin yapay zeka tabanlı işletmeler olarak yetkinliklerini daha derinlemesine inşa etmelerine olanak sağladı
- Yapay zeka tabanlı bir teknoloji yığını kurmak, modelin etrafına bileşenler eklemekten daha fazlasıydı
- Örneğin, özellikle yapay zeka için tasarlanmış bir veritabanı nasıl görünürdü?
- Eğer kritik çıktı çıkarımsa, o zaman yapay zeka tabanlı bir veritabanı yalnızca veriyi depolayıp getirmekle kalmamalı, aynı zamanda tuttuğu veri üzerinde hangi işlemlerin yapılacağına dair bağlamsal talimatları da üstlenebilmelidir
- Bunun bir örneği, e-ticaret için ürün açıklamalarının kişiselleştirilmesi olabilir
- Bir vektör veritabanı yalnızca ürün SKU’ları ve açıklamalarına ait vektör embedding’lerini değil, kullanıcı persona’larına ait embedding’leri de depolayabilir
- Veritabanındaki tüm bu bağlamsal veriler kullanılarak, altyapı ürün açıklamasına yönelik bir sorgunun ilgili kullanıcı persona’sına yönelik sorguyu da tetiklemesini ve ardından o ilgili kullanıcı persona’sına dayanarak ürün açıklamasını yazan üretken bir geri bildirim döngüsünden yararlanabilir
- Benzer şekilde dil de üretken bir geri bildirim döngüsü olarak kullanılabilir
- Örneğin kullanıcı, farklı dillerde ürün açıklamaları üretmek istiyor olabilir
- Böylece yalnızca kullanıcıya göre özelleştirilmiş değil, aynı zamanda kullanıcının seçtiği dile çevrilmiş ürün açıklamaları da üretilebilir
- Üretken yapay zeka gibi kullanım senaryoları giderek uygulamaların merkezî işlevi haline geldiği için, bu tür talimatlar doğrudan veritabanına gömülebilir
- Kullanım senaryolarına göre altyapıyı evrimleştirmek yeni bir şey değil
- Başlangıçta geliştiriciler, web sitelerini etkileşimli ve dinamik hale getirmek için tarayıcıda uygulama geliştirmede JavaScript kullanıyordu
- Ancak geliştiriciler bunu backend’e de taşıyabileceklerini fark edince node.js doğdu
- Sonrasında geliştiriciler daha fazla mobil uygulama oluşturmaya başladıkça, daha dinamik, daha tepkisel ve veri odaklı uygulamaları mümkün kılan JSON (JavaScript Object Notation) ortaya çıktı
- MongoDB, gelişen altyapı ihtiyaçlarını çözmek için ortaya çıkan bir şirket olarak bu dalgaya tam anlamıyla uydu
- Tarih yapay zeka ile yeniden tekerrür ediyor
- Gereksinimler değiştikçe, altyapının da bu gereksinimleri karşılayacak şekilde evrilmesi gerekiyor
- En büyük soru, insanların ne tür şirketler kurmak istediği ve ne tür altyapının bu şirketler için en uygun olduğu olacak
- Bob’un Matthew Lynley ile yaptığı röportajda söylediği gibi:
- “Gelecekteki tüm uygulamaların AI içereceğine güçlü biçimde inanıyorum. Bazı uygulamalarda AI serpiştirilmiş olacak, bazılarında ise AI uygulamanın merkezinde yer alacak. Onu çıkarırsanız artık var olmazlar. Bir web uygulaması geliştirip üstüne AI serpiştirmek istiyorsanız MongoDB kullanın. Özellikle de zaten kullanıyorsanız... Eğer AI’nın uygulamanın çekirdeği olduğu, yapay zeka tabanlı bir uygulama kurmak istiyorsanız, Weaviate’i değerlendirmenin zamanı gelmiştir.”
- İleriye dönük olarak şirketler, ürünlerini yapay zekayı bir eklenti olarak mı inşa edeceklerine, yoksa Bob’un dediği gibi bir “sprinkle” olarak mı ekleyeceklerine, yoksa onun ürünün çekirdeği mi olacağına karar verecek
AI-Native teknoloji yığını
- Yapay zekayı ürünün temel bileşeni olarak inşa etmek isteyen şirketler için mevcut altyapı büyük olasılıkla uygun değildir
- Legacy araçlar kullanıldığında veri depolama, düzenleme ve yürütme bir siloda, otomasyon ise başka bir siloda inşa edilir
- Bu yaklaşımın dezavantajı, ürünü daha iyi bilgilendirebilecek ve iyileştirebilecek üretken geri bildirim döngüleri gibi yapılarda bağlamın kaybolmasıdır
- "Yapay zekaya komşu" bir stack'ten gelen şirketler için belirli bir modelin çıkarımı çoğu zaman context window ile sınırlıdır
- Bazıları, verilen bir context window'un kapasitesi arttığında bunun vector database'in yerini alabileceğine inanır
- Ancak gerçekte daha olası olan karşı senaryo, vector database'lerin context window'un yerini alabilecek şekilde evrilmesidir
- Vector embedding'ler üretken modeller için son derece kritiktir ve üretken çıktılar için altyapı, vector embedding'leri birinci sınıf unsur olarak ele almalıdır
- Yalnızca context window boyutunu artırmak yerine, vector database'leri modele entegre ederek context window'un bağlamsal kavrayışı ile veritabanının güvenilirliğini ve ölçeklenebilirliğini birlikte sunmak mümkündür
- Özellikle model ne kadar genel amaçlıysa, belirli bir görev için özel olarak üretilmiş olma olasılığı o kadar düşer
- Yapay zeka tabanlı vector database'ler daha spesifik yetenekleri mümkün kılacaktır
- GPT-4 gibi genel amaçlı modeller, bilgiyi kasıtlı olarak genelleştirecek şekilde inşa edilmiştir
- Ürün biraz basit fine-tuning'e dayanıyorsa, temel model o işin benzersiz değer taşıyan kısmı olmayacaktır
- Yapay zeka tabanlı ürünler inşa etmek, modeli kullanmanın ötesinde, daha sıkı bağlı bir stack etrafında ürün inşa etmeyi de gerektirecektir
- Bu stack, veritabanının ölçeğini ve modelin yeteneklerini sağlayarak daha yetkin ürünler ortaya çıkaracaktır
1 yorum
Vektör embedding oluşturma ve vektör veritabanı kullanım örnekleri daha çok ortaya çıkıp standart bir iş akışı oluşsa harika olur. Sanırım bir yıl kadar beklemek gerekecek mi?