Yapay Zeka şirketlere avantaj sağlamalıydı. Aynı zamanda yeni bir bağımlılık yaratabilir
Birkaç yıl öncesine kadar vendor lock-in konuşmaları öncelikle bulut, ERP sistemleri, veritabanları veya kritik teknoloji platformlarıyla ilgiliydi.
Şirketler kendilerine soruyordu: Uygulamayı başka bir bulut sağlayıcısına taşıyabilir miyiz?, Veritabanını değiştirebilir miyiz?, Belirli bir sistemden vazgeçebilir miyiz?
Bugün bu listeye yeni bir öğe eklendi - yapay zeka.
Organizasyonlar giderek daha sık dil modelleri, üretken AI, RAG çözümleri, süreç otomasyonu ve AI ajanları kullanan sistemler inşa ediyor. Modeller uygulamaların, satış süreçlerinin, müşteri hizmetlerinin, belge analizlerinin, karar destek sistemlerinin ve ekiplerin günlük işinin bir parçası haline geliyor.
Pratikte bu, şirketin yalnızca belirli bir yazılıma değil, aynı zamanda sistemlerinde kullanılan zekanın belirli bir sağlayıcısına da bağımlı olmaya başlaması demektir.
Ve işte sorun burada başlıyor. Çünkü AI hizmetini kullanmak başka; ona bağımlı olmak başka bir şeydir.
Bu, teknolojik bilinçli bağımlılık ile vendor lock-in arasındaki farktır.
AI Vendor Lock-in nedir?
Vendor lock-in, bir organizasyonun bir teknoloji sağlayıcısına o kadar sıkı bağlı olması durumunu ifade eder ki, rakip bir çözüme geçiş zor, maliyetli, zaman alıcı veya riskli hale gelir.
AI dünyasında bu klasik tek API'ye bağımlılıktan daha çok biçim alabilir.
Şirket şu konularda bağımlı olabilir:
- belirli bir AI modeline,
- belirli bir API sağlayıcısına,
- belli bir iletişim formatına,
- sadece tek bir sağlayıcıda bulunan işlevlere,
- ajan sistemine,
- bulut altyapısına,
- veri depolama yöntemine,
- belirli embedding mekanizmasına,
- spesifik bir RAG sistemine,
- ajanların araç çağırma yöntemine,
- belirli modele optimize edilmiş promptlara,
- belli bir ekosisteme bağlı ekip yetkinliklerine.
Bu yüzden soru: "OpenAI mı kullanıyoruz?"
kesinlikle çok basit kalır.
Daha iyi soru şudur: "Altı ay içinde sağlayıcıyı değiştirmek zorunda kalsak, bu bizim için ne kadar zor olur?"
Eğer cevap: "Bilmiyoruz." ise - bu bir uyarı işareti olabilir.
OpenAI, Anthropic, Google - sağlayıcı seçiminin önemi var mı?
Bugün pazarda OpenAI, Anthropic ve Google gibi güçlü model ve hizmet ekosistemleri var.
Bu sağlayıcıların her biri kendi modellerini, API'lerini, araçlarını ve ek hizmetlerini geliştiriyor.
Sorun, bu sağlayıcılardan birinin "kötü" olması değil. Tam tersine.
Hazır, yüksek kaliteli modelleri kullanmak çoğu iş için en iyi çözümdür. Her şirket kendi modelini eğitmemeli; her şirketin kendi GPU altyapısına ihtiyacı yok; her şirket tüm AI yığınını sıfırdan inşa etmemeli.
Dış sağlayıcı kullanmak, piyasaya daha hızlı girmenizi, başlangıç maliyetlerini düşürmenizi ve kendi başınıza yaratmanızın mümkün olmadığı teknolojiden faydalanmanızı sağlar.
Sorun, şirket bir sağlayıcıyı değiştirilebilir bir bileşen olarak görmeyi bırakıp tüm ürünü seçilen sağlayıcının varlığına göre tasarladığında başlar.
Ve bunu kimse garanti edemez...
Modeller güncellenir, eski sürümler emekliye ayrılır, fiyatlar, limitler ve API'ler değişir; yeni modeller, lisans koşulları ve rekabet imkanları ortaya çıkar.
Bu, teknoloji pazarının normal bir parçasıdır.
Bu yüzden AI mimarisi sadece "Bugün hangi model en iyi?" sorusunu değil, aynı zamanda: "Eğer gelecek yıl başka bir modeli kullanmak istesek ne kadar öderiz?" sorusunu da göz önünde bulundurmalı.
En büyük tuzak - "API'yi değiştiririz zaten"
İlk bakışta migrasyon basit görünebilir.
Uygulamamız var. Uygulama modele istek gönderiyor. Model cevap veriyor. Sağlayıcıyı değiştiriyoruz. İş tamam...
Gerçekte durum çok farklı olabilir.
İki yıldır tek bir model etrafında geliştirilen bir uygulamayı düşünün.
Bu süre içinde ekip:
- yüzlerce prompt oluşturdu,
- bunları optimize etti,
- cevap formatını uyarladı,
- RAG sistemi kurdu,
- tool calling yapılandırdı,
- ajanlar geliştirdi,
- iş akışını tasarladı,
- testleri hazırladı,
- kullanıcıları sistemi kullanmaya eğitti.
İki yıl sonra model artık aynı sürümle kullanılmaz hale gelebilir.
Ya fiyat artar, ya rakip model çok daha iyi olur, ya da şirket verilerin bir kısmını başka bir ortama taşımak ister.
Teoride API'yi değiştirmek yeterli olabilir; pratikte tüm sistem mantığını yeniden test etmeniz gerekebilir.
Neden?
Çünkü modeller aynı değildir:
- Talimatları yorumlama biçimleri farklıdır.
- Cevap kaliteleri farklıdır.
- Uzun bağlam davranışları farklıdır.
- Araç kullanım biçimleri farklıdır.
- Yapılandırılmış çıktıları işleme şekilleri farklıdır.
- Multimodal yetenekleri farklıdır.
- Hızları farklıdır.
- Fiyatları farklıdır.
- Kenar durumlardaki davranışları da farklıdır.
Bu nedenle model değişimleri basit bir URL değiştirmeye benzemeyebilir; daha çok bir iş bileşeninin göçüne benzer.
AI Vendor Lock-in'in beş seviyesi
Vendor lock-in'e daha geniş bakmak faydalıdır.
1. Model kilitlenmesi
En basit seviye.
Uygulama belirli bir modele göre optimize edilmiştir.
Prompt bir modelde mükemmel çalışır, başka birinde daha kötü performans gösterir.
Sistem belirli modelin özgün yeteneklerine dayanır.
Değişim yeniden ayarlama gerektirir.
2. API kilitlenmesi
Sistem doğrudan belirli bir sağlayıcının fonksiyonlarını kullanır.
Ne kadar çok özel fonksiyon kullanırsak, migrasyon o kadar zor olabilir.
Sadece metin üretmekten ibaret değildir.
Ayrıca önem taşıyanlar:
- yapılandırılmış çıktılar,
- function calling,
- tool calling,
- multimodal yetenekler,
- bağlam yönetimi,
- güvenlik mekanizmaları,
- ajan sistemleri.
3. Veri kilitlenmesi
Veriler belirli bir ekosisteme sıkı bağlı biçimde saklanabilir.
Bu ayrıca şunları kapsar:
- embeddingler,
- vektör indeksleri,
- metaveriler,
- etkileşim geçmişi,
- RAG konfigürasyonları.
Göç yalnızca verileri taşımayı değil, aynı zamanda yeniden işlemeyi de gerektirebilir.
4. Mimari kilitlenmesi
Bu daha ciddi bir seviyedir.
Tüm uygulama bir sağlayıcı etrafında tasarlanmıştır.
Sağlayıcının mekanizmaları sistemin birçok yerinde entegredir.
Böyle bir durumda tek bir bileşeni değiştirmiyoruz.
Mimari bir parçayı yeniden kurguluyoruz.
5. Organizasyonel kilitlenme
Çoğu zaman en az değerlendirilen problemdir.
Ekip tek bir ekosistemi bilir.
Tüm yetkinlikler tek bir çözüm etrafında yoğunlaşmıştır.
Dokümantasyon, prosedürler, testler ve know-how tek bir sağlayıcıyla ilişkilidir.
Teknik olarak modeli değiştirebilsek bile, organizasyonda bunu yapabilecek insanlar olmayabilir.
O zaman vendor lock-in yalnızca teknik bir sorun olmaktan çıkar.
İşsel bir sorun haline gelir.
Multi-Model sorunu çözer mi?
Doğal yanıt: "Tek sağlayıcı riskliyse, birkaçını kullanalım."
Bu her zaman en iyi strateji değildir.
Multi-model mimarinin maliyeti vardır.
Şunları yönetmeniz gerekir:
- birden fazla API,
- farklı limitler,
- farklı fiyat modelleri,
- farklı kalite seviyeleri,
- farklı cevap formatları,
- testler,
- izleme,
- güvenlik.
Sistem daha karmaşık hale gelir.
Bu yüzden amaç: "Beş sağlayıcı kullanmak zorundayız." olmamalıdır.
Amaç: "İş gerekirse sağlayıcıyı değiştirebilme yeteneğine sahip olmak." olmalıdır.
Temel fark budur.
Her şirketin Multi-Model'e ihtiyacı yoktur.
Ancak her şirket başka bir modele geçişin nasıl olacağını bilmelidir.
AI Gateway ve Model Gateway - uygulamayı sağlayıcıdan ayıran katman
Bağımlılığı azaltmanın yollarından biri ara bir katman kullanmaktır.
Bu, AI Gateway veya Model Gateway işlevi görebilir.
Basitleştirilmiş mimari şöyle olabilir:
İş uygulaması
↓
AI soyutlama katmanı
↓
Model yönlendirme
↓
Sağlayıcı adaptörü
↓
OpenAI / Anthropic / Google / open-weight model / yerel model
Böylece iş mantığı uygulaması her sağlayıcının ayrıntılarını doğrudan bilmek zorunda kalmaz.
Kendi katmanımız şu görevleri üstlenebilir:
- model seçimi,
- routing,
- fallback,
- maliyet kontrolü,
- izleme,
- loglama,
- güvenlik politikaları,
- limit yönetimi.
Bir sağlayıcı arızalandığında sistem başka bir modeli deneyebilir.
Fiyat artarsa routing değiştirilebilir.
Daha iyi bir model çıktığında testler yapılıp migrasyon kararı verilebilir.
Bu, değişikliğin her zaman ağrısız olacağı anlamına gelmez.
Ama değişikliğin gerçekçi bir seçenek olarak tasarlandığı anlamına gelir.
Model Router - AI her zaman aynı modeli seçmek zorunda değil
Daha ilginç bir çözüm model yönlendirmesidir.
Farklı görevler alan bir sistemi düşünün.
Basit görev: "Bu metni özetle."
Hızlı ve ucuz bir modele verilebilir.
Daha karmaşık görev: "Belgeyi analiz et ve ayrıntılı bir tavsiye hazırla."
Daha güçlü bir modele yönlendirilebilir.
Görüntü analizi gerektiren görevler multimodal bir modele gidebilir.
Sistem böylece göreve göre modeli dinamik olarak seçer.
Bu, şu avantajları getirir:
- maliyet optimizasyonu,
- kalite optimizasyonu,
- cevap süresi optimizasyonu,
- erişilebilirlik.
Böylece sağlayıcı AI, iş mantığının ayrılmaz bir parçası olmaktan çıkar.
Altyapının bir bileşeni haline gelir.
Ve bu, önemli bir mimari değişimdir.
Soyutlama, tüm modellerin aynı olduğu anlamına gelmez
Burada tek bir tuzağa dikkat etmek gerekir.
Kendi generateText() fonksiyonunuzu yazıp problemi çözdünüz sanmak yanıltıcıdır.
Çözülmedi.
Modeller LEGO parçaları gibi birbirinin yerine geçmez.
Eğer uygulama bir modelin spesifik yeteneklerini kullanıyorsa, basit bir soyutlama sorunu sadece gizleyebilir.
İyi bir mimari sağlayıcıdan soyutlarken aynı zamanda modeller arasındaki farkları bilinçli yönetmelidir.
Pratikte AI katmanı şunları bilmelidir: modelin farklı olabileceğini —
- yetkinlikler,
- limitler,
- maliyetler,
- kalite seviyeleri,
- fonksiyonlar,
- bağlam kapasiteleri,
- parametreler.
Bu yüzden "provider-agnostic" tasarım her modelin aynı olduğunu varsaymamalıdır.
Aksine sistem, modeller arasındaki farklardan bilinçli şekilde yararlanabilmelidir.
Evals - bunlar olmadan AI göçü tahmine dayanır
Değişime dayanıklı bir mimarinin en önemli bileşenlerinden biri evals, yani modellerin düzenli kalite testleridir.
Diyelim 1000 gerçek kullanım örneğimiz var. Bunları mevcut modelde çalıştırıyoruz. Sonra yeni modelde çalıştırıyoruz. Sonuçları karşılaştırıyoruz.
Kontrol ettiğimiz noktalar:
- kalite,
- doğruluk,
- tamlık,
- halüsinasyonlar,
- gereksinimlerle uyum,
- cevap süresi,
- maliyet.
Ancak o zaman diyebiliriz: "Yeni model yeterince iyi."
Evals olmadan göç bir deney gibi olur; evals ile mühendisliksel bir süreç haline gelir.
Bu yüzden AI kullanan şirketler kendi test setlerini kurmalıdır. Sadece API'leri test etmek değil; kendi iş vakalarını test etmek gerekir. Bu çok büyük bir farktır.
Prompt da vendor lock-in kaynağı olabilir
Promptları çoğu zaman sadece metin gibi ele alırız; oysa onlar iş mantığının bir parçası haline gelebilir.
Eğer ekip uzun aylar boyunca bir modele göre talimatları optimize ederse, prompt bir kod parçası gibi davranmaya başlar.
Bu nedenle promptlar:
- versiyonlanmalı,
- test edilmeli,
- dökümante edilmeli,
- izlenmelidir.
Hangi promptların sistem için kritik olduğunu bilmek faydalıdır. Model değişimi onların etkinliğini düşürürse, sorunun nerede olduğunu bilmemiz gerekir.
Bu yüzden olgun AI sistemlerinde prompt mühendisliği giderek yazılım mühendisliğinin bir parçası olarak görülmelidir.
Open-weight ve kendi modelleri kullanmak vendor lock-in'den kaçış mı?
Open-weight modeller ve modelleri kendi altyapınızda çalıştırma imkanı teknoloji üzerinde daha fazla kontrol sağlar.
Ama bu otomatik olarak tam bağımsızlık anlamına gelmez.
Modeli kendi altyapınıza taşırsanız bile şunlara ihtiyaç duyarsınız:
- GPU,
- altyapı,
- MLOps,
- izleme,
- güvenlik,
- güncellemeler,
- uzmanlık.
Böylece model sağlayıcısına bağımlılığı azaltabilirsiniz, ama altyapı sağlayıcısına olan bağımlılığı artırabilirsiniz. Open-weight modelleri çalıştırmak için yine bulutu kullanabilirsiniz; o zaman sorun farklı bir seviyede tekrar ortaya çıkar. Bu yüzden bağımsızlığı daha geniş bir perspektiften görmek gerekir.
Tamamen bağımlılıktan arındırılmış bir sistem yoktur.
Ama bağımlılıkların:
- bilinmesi,
- kontrol edilebilmesi,
- ölçülebilmesi,
- ve gerektiğinde değiştirilebilmesi
En tehlikeli vendor lock-in ekip zihninde olabilir
Tek bir AI sağlayıcısı kullanan bir şirket düşünün.
Teknik olarak modeli değiştirebilirler. Ama firmada bunu yapacak kimse yoktur.
Ekip alternatifleri tanımaz.
Benchmark yoktur.
Evals yoktur.
Test yoktur.
Diğer modellerle deneyim yoktur.
Tüm çözümler tek bir ekosistem etrafında inşa edilmiştir.
Bu organizasyonel kilitlenmedir.
Bu yüzden vendor lock-in'e dayanıklılık, yetkinliklere yatırım yapmayı da gerektirir.
Ekip şunları anlamalıdır:
- modeller nasıl çalışır,
- sağlayıcılar arasındaki farklar nelerdir,
- soyutlama katmanı nasıl kurulur,
- modeller nasıl test edilir,
- kalite nasıl ölçülür,
- maliyetler nasıl yönetilir,
- göç nasıl yapılır.
Her geliştiricinin her API'yi bilmesi gerekmez.
Ama organizasyonun tek bir ekosistemin ötesinde teknolojik olarak kör olmaması gerekir.
Ne zaman vendor lock-in kabul edilebilir?
Vendor lock-in her zaman kötü değildir.
Bazen bilinçli bir bağımlılık makul bir iş kararıdır.
Eğer:
- sağlayıcı eşsiz bir fonksiyon sunuyorsa,
- çözüm uygulama süresini ciddi biçimde kısaltıyorsa,
- göç maliyeti biliniyorsa,
- risk kabul edilebilirse,
- alternatifler zayıfsa,
- iş hızlılık gerektiriyorsa,
tek bir sağlayıcıyla güçlü bağlanma gerekçeli olabilir.
Sorun kilitlenmenin kendisi değil, bilinçsiz kilitlenmedir.
Şirket şunları bilmelidir:
- neyin bağımlılık yarattığını,
- neden bağımlı olduğunu,
- değiştirmenin maliyetinin ne olacağını,
- göçün ne kadar süreceğini,
- hangi alternatiflerin olduğunu.
Ancak o zaman bunun bilinçli bir mimari kararı olduğundan söz edilebilir.
Şirketinizde AI Vendor Lock-in nasıl değerlendirilir?
Basit bir denetim yapmak faydalıdır.
Kendinize sorun:
Uygulamayı tümüyle yeniden inşa etmeden modeli değiştirebilir miyiz?
İş mantığı AI sağlayıcısından bağımsız mı?
Promptlar versiyonlanıyor mu?
Kendi evals'imiz var mı?
En kritik kullanım senaryoları için regresyon testlerimiz var mı?
Verileri dışa aktarabilir ve taşıyabilir miyiz?
Embedding sağlayıcısını değiştirsek veri kaybı olur mu?
Ajanlar orkestrasyon katmanından mı faydalanıyor yoksa doğrudan bir ekosisteme mi bağlı?
Alternatif bir modeli uygulamaya alma imkanımız var mı?
Fallback mekanizmamız var mı?
Göçün maliyetini biliyor muyuz?
Göçün ne kadar süreceğini biliyor muyuz?
Göçü yapabilecek insanlara sahip miyiz?
Ne kadar çok "hayır" cevabı alırsanız, o kadar büyük bağımlılık vardır.
Ayrıca kendi AI Taşınabilirlik Skorunuzu oluşturabilirsiniz. Örneğin beş alanda değerlendirebilirsiniz:
Mimari - sağlayıcı değiştirilebilir mi?
Veri - veriler taşınabilir mi?
Modeller - alternatiflerimiz var mı?
Evals - modelleri karşılaştırabiliyor muyuz?
Yetkinlikler - ekip göçü yapabilir mi?
Bu skor resmi bir standart olmak zorunda değil; fakat yönetim için güçlü bir araç olabilir.
Çünkü bazen en büyük problem vendor lock-in değil; şirketin bunun farkında olmamasıdır.
Değişime dayanıklı bir AI mimarisi nasıl tasarlanır?
Evrensel tek bir mimari yok. Ancak birkaç pratik ilke takip edilebilir.
İlke 1 - İş mantığını AI sağlayıcısından ayırın
Tüm sistemi doğrudan tek bir API etrafında kurmayın.
İlke 2 - Mantıklı yerlerde soyutlama katmanı kullanın
AI Gateway veya Model Gateway uygulamanın belirli sağlayıcıya bağımlılığını azaltabilir.
İlke 3 - Promptları versiyonlayın
Onları yalnızca serbest metinler gibi değil, sistem bileşeni olarak ele alın.
İlke 4 - Evals kurun
"Yeni model çalışıyor" varsaymayın. Test edin.
İlke 5 - Alternatifleri test edin
Onları üretimde kullanmak zorunda değilsiniz; ama kendi vakalarınızda nasıl performans gösterdiklerini bilmelisiniz.
İlke 6 - Verileri kontrol edin
İş verileriniz tek bir platformun rehinine dönüşmesin.
İlke 7 - Bağımlılıkları dökümante edin
Hangi parçaların belirli bir sağlayıcıyla bağlı olduğunu bilmek mimari dokümantasyonun parçasıdır.
İlke 8 - Güçlü soyutlama yapmaya çalışmayın
Taşınabilirlik görünümü elde etmek için modeller arasındaki farkları saklamayın.
İlke 9 - Göç maliyetini ölçün
"Bir gün sağlayıcıyı değiştirebiliriz" demek yetmez.
Bilinmesi gerekir: "Bunun için üç aya ve beş kişiye ihtiyacımız var."
Veya: "Sistemi yeniden inşa etmeden bunu yapamayız."
İlke 10 - Kararları bilinçli verin
Bazen tek bir sağlayıcıya güçlü bağlanmak en iyi çözüm olabilir.
Ama bunun bilinçli bir risk olması gerekir.
Rastgele bir tercih değil.
Her CTO'nun sorması gereken soru
Yarın AI sağlayıcımız:
- fiyatları iki katına çıkarırsa,
- kullandığımız modeli emekliye ayırırsa,
- limitleri değiştirirse,
- ürünümüzün dayanıklı olduğu bir fonksiyonu kısıtlarsa,
- uyumluluk gereksinimlerimizi artık karşılamazsa.
Ne yaparız?
Eğer cevap: "Sağlayıcıyı değiştiririz." ise
sonraki soru şu olmalıdır: "Bu bize ne kadar sürer?"
Bir gün mü?
Bir hafta mı?
Bir ay mı?
Yarım yıl mı?
Ya da bilmiyor muyuz?
İşte bu, teknolojik dayanıklılığımızın ölçüsüdür.
Özet - amaç sağlayıcısız olmak değil
Dış AI sağlayıcılarından tamamen bağımsız bir sistem inşa etmek maliyetsiz, gereksiz veya imkansız olabilir.
Ama amaç bu değil.
Amaç bağımlılıkları bilinçli şekilde yönetmek olmalıdır.
OpenAI, Anthropic veya Google kullanabilirsiniz. Open-weight modelleri veya farklı çözümleri de kullanabilirsiniz.
En önemlisi şudur: "Teknolojiyi kullanıyoruz" ile "onun bağımlısıyız" arasındaki sınırın nerede olduğunu bilmektir.
AI dünyasında bu sınır fark edilmesi özellikle zor olabilir. Çünkü vendor lock-in bir günde oluşmaz; kademeli gelişir. Önce API'yi entegre edersiniz. Sonra bir fonksiyon inşa edersiniz. Sonra RAG eklenir. Sonra ajanlar. Sonra süreçler otomatikleşir. Sonra tüm ekip bu sisteme göre çalışmaya başlar. Ve bir anda model değişimi artık sadece bir model değişimi değil — organizasyonun bir parçasının değişimidir.
Bu yüzden AI mimarisi sadece bugün neyin çalıştığını değil, aynı zamanda teknoloji dünyası yarın değiştiğinde ne olacağını da göz önünde bulundurarak tasarlanmalıdır.
OpenAI, Anthropic veya Google olmadan çalışan bir sistem inşa etmek zorunda değilsiniz. Ancak herhangi birinin ortadan kalktığı durumda da çalışmayı sürdürebilen bir sistem tasarlamalısınız.
İşte bu, AI kullanmak ile AI teknolojisini bilinçli şekilde tasarlamak arasındaki farktır.
