TensorBundle Türkçe Blog

AI agent geliştirmenin ve işletmenin maliyeti ne kadar?

Fri, 04 Sep 2026 00:00:00 GMT

Bir AI agent için ne kadar bütçe gerekir diye sorulduğunda genellikle iki cevap duyulur. Biri, hangi varsayıma dayandığı belli olmayan kesin bir rakamdır. Diğeri “duruma göre değişir” diye başlar ve projede alınabilecek bütün teknik kararlarla devam eder. İkisi de bütçe hazırlamaya pek yardımcı olmaz.

2026’da yayımlanan tedarikçi tahminlerinde, tek ve dar kapsamlı bir görev yapan AI agent sistemi için 8.000-25.000 dolar aralığı sık görülüyor. Şirket verisi veya araçlarıyla çalışan bağlantılı sistemlerde rakam 25.000-80.000 dolara, birden fazla sisteme bağlı ya da büyük ölçüde otonom projelerde ise 80.000-250.000 dolara veya daha fazlasına çıkıyor. Aylık işletme giderleri de dar kapsamlı kurulumlarda birkaç yüz dolardan başlayıp daha karmaşık sistemlerde birkaç bin dolara ulaşabiliyor. Kurumsal projeler bu rakamları aşabilir.

Bunlar denetlenmiş piyasa ortalamaları değil. Projenin nerede geliştirildiği, sözleşme biçimi, güvenlik şartları ve şirketin hazır altyapısı fiyatı değiştirebilir. Dolayısıyla bu rakamlar teklif değil, bütçenin ölçeğini görmeye yarayan başlangıç aralıklarıdır. The Crunch Pharos Production

Aralıkların geniş olmasının basit bir nedeni var: “AI agent” tek başına ne kadar iş yapılacağını anlatmaz. Bir politikayı bulan, iadeyi onaya hazırlayan ve onay beklemeden gerçekleştiren üç sistem aynı modeli kullanabilir. Fakat modelin çevresinde kurulması gereken ürün aynı değildir.

Fiyatı modelin ne kadar zeki göründüğünden çok, sisteme ne yapma yetkisi verildiği belirler. Bağlanacağı sistemler, karşılaşacağı istisnalar ve kullanıma açılmadan önce ne kadar güven vermesi gerektiği de hesabı tamamlar.

AI agent geliştirme ve işletme bütçesi ne kadar?

İlk soru, AI agent sisteminin süreçte hangi işi üstleneceğidir. Prompt sayısı veya mimari şemadaki kutular bütçeyi açıklamaz.

Tablodaki aralıklar bilerek geniş tutuldu. Aylık rakamlar yayımlanmış piyasa rehberlerindeki model, altyapı, izleme ve rutin bakım giderlerine dayanıyor. İnsan incelemesi, istisnaların çözümü, güvenlik, mevzuata uyum ve ürün sorumluluğu için harcanan kurum içi zaman çoğu tahminde yer almıyor. Yüksek hacimde sürekli çalışan altyapı veya kapsamlı değerlendirme süreçleri de aylık gideri tablonun çok üzerine çıkarabilir.

Bu sınıfları olgunluk basamakları gibi okumamak gerekir. Kararın insanda kalması gereken bir süreçte yalnızca bilgi veren bir sistem, eksik değil tam olarak ihtiyaç duyulan ürün olabilir. Birden fazla agent kullanmak da ürünü kendiliğinden daha değerli yapmaz. OpenAI’ın uygulama rehberi, her yeni agent ek karmaşıklık ve yük getirdiği için önce tek agent ile ne kadar ilerlenebileceğine bakılmasını öneriyor. OpenAI

Tablo ölçeği gösterir. Projenin hangi aralığa girdiğini anlamak için model yanıt verdikten sonra sistemin ne yaptığına bakmak gerekir.

Yetki arttıkça maliyet de değişir

Aynı müşteri hizmetleri işi için üç ayrı AI agent sistemi düşünelim.

İlki güncel iade politikasını okur ve ilgili bölümü çalışana gösterir. Onaylanmış kaynağa erişmesi, doğru bölümü bulması ve dayandığı metni görünür biçimde sunması yeterlidir.

İkinci sistem siparişi de bulur, müşterinin koşulları karşılayıp karşılamadığını kontrol eder ve iadeyi onaya hazırlar. Bunun için kimliği doğrulanmış hesap erişimi, güvenilir araç tanımları ve yaptığı kontrolü inceleyecek kişiye gerekli bilgileri eksiksiz aktaran bir akış gerekir.

Üçüncüsü iadeyi doğrudan gerçekleştirir. Artık işlemi kimin yetkilendirdiği, tutarın politikaya uyup uymadığı ve ödeme hizmeti zaman aşımına uğrarsa ne yapılacağı açık olmalıdır. Aynı iade iki kez yapılmamalı, insan kararı gerektiren durumlar önceden belirlenmeli ve daha sonra bütün işlem kayıtlardan izlenebilmelidir.

Model üçünde de aynı olabilir. Değişen, modelin çevresindeki ürün ve ona verilen yetkidir.

Bilgi veren bir asistana işlem yetkisi eklemek, yalnızca bir API çağrısı daha eklemek değildir. Yazma erişimi varsa kimlik doğrulama ve yetkilendirme gerekir. İşlemin sonucu önemliyse onay kuralları, denetim kayıtları, hata sonrası toparlanma ve insan müdahalesi de tasarlanmalıdır. Geri alınamayan işlemlerde çıta daha da yükselir. OpenAI’ın rehberi araç riskini; okuma veya yazma erişimi, işlemin geri alınabilirliği, yetkiler ve finansal sonuç gibi somut ölçütlerle ele alıyor. Anthropic’in gerçek kullanımdaki sistemleri inceleyen araştırması da otonomiyi yalnızca modelin özelliği saymıyor. Sonuç; model, ürün tasarımı ve insan gözetiminin birleşiminden doğuyor. OpenAI Anthropic

Daha fazla otonomi insan incelemesini azaltabilir. Yine de güvenilirlik için harcanan emek kaybolmaz; başka yere taşınır. İnsan onayının yerine daha sıkı yetkiler, otomatik kontroller, daha geniş bir değerlendirme kümesi, sürekli izleme veya güvenli bir toparlanma yolu gerekir. Buna değip değmeyeceğini işlemin değeri ve olası bir hatanın sonucu belirler.

Kapsamı süreç şemasından çok istisnalar belirler

Bir iş akışı şemasında beş kutu bulunabilir: talebi al, müşteriyi bul, politikayı kontrol et, iadeyi yap, müşteriye haber ver. Kutuları saymak güvenilir bir maliyet tahmini üretmez.

Asıl iş bu kutuların dışına çıkıldığında başlar. Müşteri yanlış sipariş numarası verir. İki politika belgesi birbiriyle çelişir. Hesap sorgusu çalışır, ödeme hizmeti zaman aşımına uğrar. Sistem iadeyi başarısız sanarken ödeme aslında gönderilmiş olabilir. Müşteri yalnızca bölge yöneticisinin onaylayabileceği bir istisna ister. Ya da sistem geçen ay doğru olan, fakat dün yürürlükten kaldırılan politikayı bulur.

Bu vakaların her biri için bir karar gerekir. Sistem yeni bir soru sorabilir, başka bir kaynağı deneyebilir, bekleyip yeniden çalışabilir, güvenli biçimde durabilir, işlemi geri alabilir veya işi bir çalışana devredebilir. Devir sırasında hangi bilgiler paylaşılacak? Çözülemeyen işler kimde toplanacak?

Kısa bir iş akışının pahalı, daha uzun bir akışın öngörülebilir olması bu yüzden mümkündür. Kararlı API’ler üzerinden yapılan, iyi belgelenmiş on okuma işlemi; hata durumları belirsiz bir legacy sistemdeki iki yazma işleminden daha kolay geliştirilebilir. Şemada adımlar görünür. Mühendislik süresini tüketen ise çoğu zaman istisnalardır.

Beklenen güvenilirlik düzeyi de hesabı değiştirir. Çalışana yardımcı olan bir sistem belirsizliği gösterebilir ve son kararı insana bırakabilir. İşi tek başına tamamlayacak sistemin nerede yanılabileceğini ise çok daha iyi bilmek gerekir. “Çoğu zaman işe yarıyor” ile “rutin inceleme olmadan işlem yapabilecek kadar güvenli” arasında yalnızca birkaç puanlık kalite farkı yoktur. Değerlendirme yöntemi, güvenlik önlemleri ve hata sonrası davranış baştan tasarlanır.

Bu yüzden tahminden önce normal akışın yanı sıra gerçek istisnaları da toplamak gerekir. Temsil gücü olan birkaç düzine vaka, bütçe hakkında özenle hazırlanmış bir mimari şemadan daha çok şey söyleyebilir.

Mevcut sistemler fiyatı değiştirir

Aynı AI agent sistemi iki şirkette iki farklı fiyata çıkabilir. Çünkü bağlanacağı çalışma ortamı aynı değildir.

Bir şirkette müşteri kayıtlarına belgelenmiş bir API üzerinden erişilir. Her çalışanın yönetilen bir kimliği vardır. Politika arşivinin sahibi bellidir ve iade yetkileri operasyon kurallarına yazılmıştır. AI agent sisteminin ihtiyaç duyduğu yapı büyük ölçüde hazırdır.

Başka bir şirkette müşteri geçmişi eski bir CRM ile elektronik tablolar arasında dağılmıştır. Politikalar farklı klasörlerdedir. Çalışanlar ortak servis hesapları kullanır. İstisnalar özel mesajlarla, karar verme biçimi hiçbir yere yazılmamış kişiler tarafından çözülür. AI agent sistemi işe başlamadan önce şirketin henüz sahip olmadığı arayüzlerin bulunması veya geliştirilmesi gerekir.

Bütün bunlar “yapay zeka geliştirme” başlığı altında kolayca gözden kaçar. Oysa veri temizliği, API geliştirme, erişim kontrolü, süreçlerin yazılı hale getirilmesi ve hangi kaynağın geçerli olduğuna karar verilmesi gerekebilir. Bu işler dil modelini daha yetenekli yapmaz; ürünün o şirkette çalışmasını mümkün kılar.

Bu nedenle iki tedarikçi aynı mühendislik ücretleriyle çalışsa bile çok farklı teklifler verebilir. Biri temiz verinin, gerekli yetkilerin ve istisnalardan sorumlu kişilerin hazır olduğunu varsayar. Diğeri bunları oluşturacak çalışmayı da fiyatına ekler. Düşük teklif daha verimli bir yaklaşımdan kaynaklanabilir; daha dar bir sorumluluk üstleniyor da olabilir.

İyi bir tahmin bu varsayımları açıkça yazar: Hangi sistemlere erişilebiliyor? Veri ne kadar hazır? Yetkilere kim onay verecek? İş kurallarından ve istisnalardan kim sorumlu? Bunlar bilinmeden bir şirket için verilen fiyat, başka bir şirkete pek bir şey anlatmaz.

Geliştirme ve işletme maliyetleri farklı işleri karşılar

Geliştirme maliyeti sistemi kullanıma hazırlar. İşletme maliyeti, kullanıma açıldıktan sonra çalışır durumda tutar.

Geliştirme, iş akışının incelenmesi ve verinin hazırlanmasıyla başlar. Araçlar, arayüzler, yetkiler, değerlendirme vakaları, güvenlik önlemleri, deployment ve dokümantasyon da bu bütçeye girer. Bazı işler sistem açıldığında biter. Bazıları ise düzenli bakım isteyen parçalar bırakır.

İşletme bütçesinde model çağrıları, retrieval, harici araçlar, çalışma ortamı, depolama ve telemetri vardır. Sürekli değerlendirme, insan incelemesi, istisnaların çözümü, olaylara müdahale ve entegrasyon ya da politika değişiklikleri de aynı bütçenin parçasıdır. Yönetilen agent platformlarının fiyat sayfaları bu çeşitliliği açıkça gösteriyor. Örneğin AWS AgentCore; çalışma süresi, tarayıcı kullanımı, arama, araç geçidi çağrıları, kimlik istekleri, bellek, gözlemlenebilirlik, değerlendirme ve politika hizmetlerini ayrı ayrı ölçüyor. Başka bir platform kullanmak veya bu katmanları şirket içinde geliştirmek tabloyu değiştirmez: Model faturası, işletme giderlerinden yalnızca biridir. AWS

İlk yılın maliyet hesabı

Geliştirme sırasında alınan bazı kararlar, sistem kullanıma açıldıktan sonra da maliyet yaratır.

Bu iki maliyet grubunu ayırmayan şirketler sık sık aynı hataya düşer. Geliştirme için bütçe vardır; fakat gerçek kullanımı değerlendirecek, sistemin bıraktığı vakaları çözecek veya bağlı API değiştiğinde ürünü güncelleyecek kişi ve bütçe yoktur. Maliyet kaybolmaz. Arıza, plansız çalışan zamanı veya giderek düşen kullanım olarak geri döner.

Üretimdeki maliyet sabit kalmaz. Tüketim, altyapı, bakım, kullanım biçimi ve model değiştikçe hesap da değişir. AWS’in yaşam döngüsü rehberi bu nedenle finansal ölçüleri iş sonuçlarıyla birlikte izlemeyi, yatırım getirisini yalnızca sistem açılırken bir kez hesaplayıp bırakmamayı öneriyor. AWS Prescriptive Guidance

Basit bir ilk yıl hesabı bütün kalemleri görünür tutar:

İlk yıl maliyeti = keşif + geliştirme ve entegrasyon + güvenilirlik ve kullanıma alma + 12 × aylık işletme

Geliştirme ile bakım arasında her projeye uyacak tek bir oran yoktur. Düşük hacimli kurum içi asistan ile müşteriye dönük ve işlem yapabilen bir sistemin giderleri aynı şekilde dağılmaz. Yine de her iki projede de paranın nereye gideceği baştan yazılabilir.

İşe yarayan bir tahmin varsayımlarını gösterir

Bir rakamın kesin görünmesi, tahminin doğru olduğu anlamına gelmez. Ekip iş akışını, bağlı sistemleri, istisnaları ve kabul ölçütlerini incelemeden söylenen 47.500 doların son iki hanesi bilgiye değil, biçimlendirmeye dayanır.

Bu, erken tahminin işe yaramadığı anlamına gelmez. İyi bir ilk tahmin bir aralık verir, varsayımlarını açıklar, en büyük belirsizlikleri gösterir ve aralığı daraltmak için neyin öğrenilmesi gerektiğini söyler. Varsayımları belli geniş bir aralık, temeli bilinmeyen kesin bir rakamdan daha güvenilirdir. Keşif çalışmasının değeri de burada ortaya çıkar: Tahmin edilen işin bir bölümünü gözlenmiş işe çevirir.

Hesabın büyük bölümü altı bilgiyle şekillenir: Sistemin tamamlayacağı iş, sahip olacağı yetki, bağlanacağı sistemler, şirket ortamının hazırlığı, istisnaların çeşitliliği ve beklenen güvenilirlik düzeyi. Aylık hacim işletme giderini ciddi biçimde etkiler. Fakat ne yaptığı belli olmayan bir sistemi tanımlı hale getirmez.

Araç, yerel mühendislik ücretlerini bilmiyor ve şirketin sistemlerini görmüyor. Zaten amacı teklif vermek değil. Hangi koşulların fiyatı değiştirdiğini ve eldeki bilgilerden hangilerinin tahmini zayıflattığını görünür hale getiriyor.

Teklif aşamasında bu genel varsayımların yerini somut bilgiler almalıdır: bağlanacak sistemlerin adları, örnek vakalar, açık yetkiler, değerlendirme planı, sorumlular ve gözlenmiş görev hacmi. Fiyat değişiyorsa nedeni de teklifte görülmelidir.

Maliyeti tamamlanan işle karşılaştırın

20.000 dolara geliştirilen bir sistem ayda on saat kazandırıyor olsun. 100.000 dolarlık başka bir sistem ise geliri geciktiren, müşterileri bekleten ve birkaç uzmanın zamanını alan yoğun bir iş kuyruğunu ortadan kaldırsın. İlki daha ucuzdur. Fakat daha iyi yatırım olduğu buradan çıkmaz.

Fiyatı yatırım kararına çevirmek için karşılığında tamamlanan işe bakmak gerekir. Önce hangi sonucun kabul edileceği belirlenir. Ardından sistemin bu ölçüte göre kaç işi bitirdiği, geriye ne kadar insan emeği bıraktığı ve tamamlanan işin değeri ölçülür.

İşletme hesabının tamamı için şu formül kullanılabilir:

Kabul edilen görev başına maliyet = iş akışının toplam işletme maliyeti / kabul koşulunu karşılayan tamamlanmış görev sayısı

Hesaptaki payda önemlidir. Sürekli düzeltme isteyen veya zor vakaların çoğunu insanlara bırakan ucuz bir sistem, API faturasını düşürse bile iş sürecini pek değiştirmeyebilir. Daha pahalı bir sistem değerli işleri güvenilir biçimde tamamlıyor ve geride yönetilebilir bir istisna kuyruğu bırakıyorsa yaptığı harcamanın karşılığını verebilir.

Geliştirme kararının ayrıca bir zaman ufku olmalıdır:

Üç yıllık toplam maliyet = geliştirme maliyeti + 36 aylık işletme + kurum içi sorumluluk ve kalan işler

Üç yıllık rakam, aynı dönemde kabul edilen sonuçların değeriyle karşılaştırılmalıdır. Kullanım, istisna oranı ve işletme gideri için tek bir iyimser senaryo yerine aralıklarla çalışmak daha sağlıklıdır. TensorBundle’ın yapay zeka token ekonomisi yazısı yeniden denemeleri, araçları, insan incelemesini ve başarılı görev başına maliyeti daha ayrıntılı ele alıyor. Buradaki hesap daha geniştir; görev başına ekonomi, ürünü geliştirme ve ayakta tutma yatırımını da karşılamalıdır.

Teknik olarak basit bir sistem, geliştirme giderini karşılamayacak kadar küçük bir işi otomatikleştiriyor olabilir. Daha pahalı ve işlem yapabilen bir sistem ise sık tekrarlanan, sonucu önemli ve çözümsüz kalması pahalı bir işte doğru yatırım olabilir. Model seçimi veya teklifin toplamı bunu tek başına söylemez.

Bütçeden önce yetkiyi tanımlayın

AI agent bütçesi hazırlamak için önce eksiksiz bir mimari çizmek gerekmez. Yapılacak işi, sisteme verilecek yetkiyi, çalışacağı ortamı ve güvenmek için hangi kanıtların aranacağını bilmek yeterlidir.

Piyasa aralıkları bütçenin ölçeğini görmek için kullanılabilir. Sonra sistemin neyi okuyacağı, ne önereceği ve neyi değiştireceği yazılır. Süreç şemasında görünmeyen istisnalar toplanır; bağlı sistemler ve veri incelenir. İlk geliştirme bütçesi, şirketin sistem çalışırken üstleneceği giderlerden ayrılır. En sonunda toplam maliyet, gerçekçi bir dönem boyunca tamamlanacak işin değeriyle karşılaştırılır.

Bilgiler netleştikçe tahmin aralığı daralır. Ortadaki rakamın değişmesi sorun değildir. Artık geçerli olmayan varsayımlara dayanan ilk tahmini korumak, yalnızca düzeltmeyi geciktirir.

Bütün bu sorular yanıtlandığında model yine bütçedeki küçük kalemlerden biri olabilir. En azından eldeki tahmin artık şirketin gerçekten kurup çalıştıracağı sistemi anlatır.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Yapay zeka token ekonomisi: Gerçek maliyeti kim ödüyor?

Mon, 24 Aug 2026 00:00:00 GMT

Token fiyatları gerçekten düşüyor. Bugün aynı düzeyde model kapasitesine birkaç yıl öncesine göre çok daha ucuza erişilebiliyor. Fiyat listesindeki rakamlarla hızlı bir hesap yapınca, yapay zeka özelliğinin maliyeti de yok denecek kadar az görünüyor.

Fakat bu hesap genellikle tek bir model çağrısında bitiyor. Üretimde ise prompt’a system prompt, konuşma geçmişi, getirilen belgeler ve araç tanımları ekleniyor. AI agent sistemi işi tamamlayana kadar modeli birkaç kez çağırabiliyor. Bu sırada başarısız denemeler tekrarlanıyor, bazı yanıtlar başka bir modelden, bazıları da bir insandan onay bekliyor. Pilotta faturayı hafifleten bulut kredisi de bir gün tükeniyor.

Fiyat sayfasında yanlış bir şey yok, ancak şirketin asıl merak ettiği soruyu yanıtlamıyor.

Token, faturalandırma için kullanışlı bir birim. Ürünün gerçekten kaça mal olduğunu görmek içinse başarıyla tamamlanan görev başına maliyete bakmak gerekiyor. Bir destek aracında bu, çözülen talebin maliyetidir. Fatura mutabakatında ise yeniden denemeler ve insan kontrolü dahil, kabul edilen işlem başına maliyettir.

Sübvansiyon tartışmasının karışmasının bir nedeni de bu. Fiyat listesinde yazan tutar, bugün ödenen fatura ve kredi bittikten sonra şirkete kalacak maliyet aynı olmayabilir.

LLM faturası neyi sayıyor?

Token, modelin işlediği küçük bir bilgi parçası. Kullanıcının sorusu, system prompt, getirilen bir belge, araç tanımı, görsel, modelin akıl yürütmesi ve verdiği yanıtın her biri token üretiyor.

Sağlayıcıların bunları ücretlendirme biçimi aynı değil. OpenAI girdi, çıktı, önbelleğe alınmış tokenlar ve akıl yürütme tokenları için ayrı kullanım bilgisi veriyor. Google’ın kullanım verilerinde girdi, çıktı, düşünme, önbelleğe alınmış içerik ve araç kullanımı bulunuyor. Anthropic ise normal girdiyi önbelleğe yazılan, önbellekten okunan ve çıktı olarak üretilen tokenlardan ayırıyor. Dolayısıyla “10.000 token harcadık” demek, maliyeti açıklamaya yetmiyor. Hangi tokenların harcandığı ve sonunda işe yarar bir sonuç alınıp alınmadığı da önemli. OpenAI Google Anthropic

Şirket içi destek asistanına bir müşterinin para iadesi alıp alamayacağını soran çalışanı düşünelim. Ekranda yalnızca soru ve yanıt görünse de arkada talep sınıflandırılıyor, güncel politika bulunuyor, müşteri hesabı açılıyor, modelden öneri alınıyor, yapılandırılmış yanıt doğrulanıyor ve son bir kontrol yapılıyor olabilir. Hesap sorgusu zaman aşımına uğrarsa zincirin bir bölümü yeniden çalışır. Kısacası kullanıcı tek işlem görürken faturaya küçük bir iş akışı yansır.

Hesapta bir milyon girdi tokenı $1, bir milyon çıktı veya akıl yürütme tokenı $5 kabul edildi.

Çubuğun genişliği, kabul edilen görev başına beklenen model maliyetini gösterir. Belge ve araç bağlamı modele gönderilen içeriği kapsar. Veri tabanı, harici API, insan incelemesi ve altyapı maliyetleri bu grafikte yok.

Bu, RAG veya AI agent kullanımının gereksiz olduğu anlamına gelmiyor, çünkü her iki mimari de ek maliyetinin karşılığını verebilir. Mesele, tek model çağrısının fiyatıyla bütün iş akışının maliyetini birbirine karıştırmamak.

Ucuz model her zaman ucuz sonuç vermiyor

Aynı belgeden veri çıkarıp doğrulayan iki model olsun. Model A’nın girdi ve çıktı ücretleri daha düşük, fakat daha uzun bir prompt istiyor ve daha uzun yanıt veriyor. Üstelik her beş isteğin biri yeniden çalıştırılıyor. Model B ise token başına daha pahalı olmasına rağmen daha az bağlam kullanıyor ve geçerli sonucu ilk denemede daha sık üretiyor.

Fiyat listesinde Model A ucuz. Kabul edilen belge başına hesap yapıldığında ise Model B öne geçebilir.

2026 tarihli bir çalışma, karşılaştırılan model çiftlerinin yüzde 21,8’inde tam olarak bu durumla karşılaştı. Bu örneklerde token fiyatı daha düşük olan modelin gerçekleşen toplam maliyeti daha yüksekti. En büyük fark 28 kata ulaştı. The Price Reversal Phenomenon

Bunun şaşırtıcı olmayan birkaç nedeni var. Farklı tokenizer’lar aynı metni farklı sayıda tokena bölebiliyor. Modellerin akıl yürütme ve çıktı uzunlukları da değişiyor. İlk yanıt işe yaramadığında sistem aynı modeli tekrar çağırıyor, başka bir modele geçiyor veya işi insan incelemesine gönderiyor. Dolayısıyla ilk denemede doğru çalışan pahalı model, toplamda daha ucuz kalabiliyor.

Örneğin küçük bir model API faturasını yüzde 40 azaltırken kabul edilen görev oranını yüzde 90’dan yüzde 60’a düşürüyorsa ortada net bir tasarruf olmayabilir. Aradaki fark tekrar yapılan işlere, inceleme süresine ve müşteri şikayetlerine gider.

Bu nedenle önce kabul edilebilir sonucun ne olduğu belirlenmeli, ardından o sonucu en düşük toplam maliyetle üreten seçenek bulunmalı.

Token ucuzluyor, kullanım artıyor

American Economic Association’ın Journal of Economic Perspectives dergisinde yayımlanan bir analiz, yapay zeka kapasitesinin fiyatının yaklaşık bin kat düştüğünü tahmin ediyor. Benzer düzeydeki açık modeller de kapalı modellere göre çok daha ucuza sunuluyor. Düşüşün tam oranı seçilen benchmark’a ve döneme bağlı, ama yönü açık. American Economic Association

Şirket faturalarının aynı hızla düşmesi gerekmiyor. Model çağrısı ucuzlayınca ekipler daha fazla bağlam ekliyor, bir doğrulama adımı daha çalıştırıyor, daha çok çıktıyı değerlendiriyor veya AI agent sistemine ek adımlar veriyor. Bunların hepsi israf değil. Daha iyi kanıt yanıtı iyileştirebilir, ek bir kontrol de token maliyetinden çok daha pahalı bir hatayı önleyebilir.

Yine de ucuz kapasite, gereksiz harcamayı fark etmeyi zorlaştırıyor. Bağlam penceresine sığıyor diye bütün konuşma geçmişi her istekte yeniden gönderilebiliyor. İki sistem aynı belgeyi ayrı ayrı okuyabiliyor veya bir araç hata verince daha da büyümüş bağlam baştan işleniyor. Basit bir kuralın ya da örneklem kontrolünün yeterli olacağı yerde her çıktı başka bir modele puanlatıldığında, birim fiyat düşse bile kullanılan birim sayısı artıyor.

Stanford Digital Economy Lab’in kodlama görevleri üzerine yaptığı çalışma, aradaki farkın ne kadar büyüyebildiğini gösteriyor. AI agent kullanılan görevler, kod üzerinde akıl yürütme ve sohbet görevlerinden bin kata kadar daha fazla token tüketti. Aynı görevin farklı çalıştırmaları arasında 30 kata varan fark vardı. Üstelik daha çok token harcanan çalıştırma düzenli olarak daha iyi sonuç vermedi. En iyi performans çoğu zaman orta bir maliyet düzeyinde görüldü. Stanford Digital Economy Lab

Bu sayılar kodlama ortamından geldiği için her iş akışına doğrudan taşınamaz. Yine de çağrı sayısını model belirlediğinde maliyetin de sabit kalmadığını açıkça gösteriyor: Tutar ancak çalıştırma bittikten sonra belli oluyor.

Ortalama maliyet de bu farkı örtebilir. Çoğu görev ucuza tamamlanırken az sayıdaki uzun ve başarısız çalışma bütçenin büyük bölümünü yiyebilir. Bu yüzden medyanı ve pahalı uçtaki çalışmaları ayrı izlemek, ardından en pahalı hataların kayıtlarını tek tek okumak gerekir.

”Sübvanse edilmiş fiyat” derken neyi kastediyoruz?

Yapay zeka fiyatları konuşulurken “sübvanse ediliyor” sözü birkaç farklı durum için kullanılıyor. Müşterinin faturasında benzer görünen bu durumların ekonomik anlamı aynı değil.

Bulut kredisi doğrudan bir sübvansiyon. Örneğin Google, koşulları karşılayan yapay zeka odaklı girişimlere önemli miktarda kredi vererek normalde girişimin ödeyeceği kullanımı karşılıyor. Deneme yapmak için değerli olan bu destek, promosyon bittiğinde ürünün model faturasını taşıyabileceğini kanıtlamıyor. Google for Startups Cloud Program

Sabit ücretli abonelikte durum farklı. Aylık ücret, ürünü nadiren açanlarla yoğun kullananları aynı havuzda topluyor. Bu yüzden bir kullanıcının API fiyatlarıyla hesaplanan tüketimi abonelik ücretini aşarken bir başkası hizmeti neredeyse hiç kullanmayabilir. Fakat bu tüketim tutarı, sağlayıcının gerçek hesaplama maliyeti değil. API fiyatının içinde kâr marjı ve fiyatlandırma tercihi de bulunduğundan, şirketin iç maliyetlerini bilmeden yalnızca aradaki farka bakıp zarar ettiği sonucuna varılamaz.

Rekabet amacıyla düşük tutulan fiyatları dışarıdan anlamak daha da zor. Sağlayıcı pazar payı kazanmak için düşük kâr marjını kabul ediyor olabilir. Bulut şirketi geliri başka hizmetlerden elde ettiği için yapay zeka ürününde indirim yapabilir. Ya da fiyat gerçekten daha iyi donanım kullanımı ve önbellekleme sayesinde düşmüştür. Fiyat sayfası bunlardan hangisinin geçerli olduğunu söylemez.

Müşterinin bu tartışmayı dışarıdan çözmesi gerekmiyor. Onun açısından asıl risk, kalıcı olmayan bir fiyata bağımlı olmak. Ürün yalnızca belirli bir kredi veya olağan dışı düşük tarife devam ederken para kazanıyorsa bunun maliyet hesabında açıkça görülmesi gerekir.

Aynı iş, üç farklı maliyet

Tek bir ayın maliyeti, hesaba hangi kalemlerin girdiğine göre değişiyor.

Örnek: 10.000 istek, kabul edilen 8.000 sonuç ve $500 bulut kredisi.

İnceleme ekibi saatlik $40 maliyetle 100 saat çalışıyor. Ürün geliştirme ve genel giderler hesaba dahil değil. Kamuya açık API fiyatı da sağlayıcının gerçek hesaplama maliyetini göstermiyor.

Kredi ve tanıtım fiyatlarından elbette yararlanılabilir, ancak aynı hesabı ikisi de yarın bitecekmiş gibi bir kez daha yapmak gerekir.

Sabit aboneliğin altında değişken maliyet var

Bulut kredisi bittiğinde kullanım ortadan kalkmıyor ve faturayı artık ürünü sunan şirket ödüyor. Müşteri sabit bir aylık ücret öderken arka plandaki yapay zeka maliyeti her istekte değişiyorsa bu fark kolayca büyüyebilir.

Aynı paketteki iki müşteri düşünelim. Biri ilk model çağrısında tamamlanan kısa istekler gönderiyor. Diğeri uzun belgeler yüklüyor, AI agent sisteminde çok sayıda adım çalıştırıyor ve daha fazla işi insan incelemesine bırakıyor. İkisinden gelen abonelik geliri aynı, hizmet maliyeti farklı.

Bu, müşteriye token üzerinden fatura kesmek gerektiği anlamına gelmiyor. Kullanıcı veya iş akışı başına ücretlendirme devam edebilir. Fakat şirketin, her paketin normal fiyatlarla ne kadar kabul edilmiş iş ürettiğini bilmesi gerekir. Sabit abonelik değişken maliyeti ortadan kaldırmaz, yalnızca şirketin tarafında bırakır.

Doğru metrik: kabul edilen işin maliyeti

Önce neyin başarılı görev sayılacağı belirlenmeli, çünkü bir yanıtın ekrana gelmiş olması tek başına başarı değil.

Destek asistanında başarı, daha sonra yeniden açılmayan bir talep olabilir. Belge işlemede, sonraki sistemin kabul ettiği doğrulanmış kayıt sayılabilir. Veriyi değiştiren bir AI agent sisteminde ise doğru kaydın değişmesi ve işlemin belirlenen kurallara uyması gerekir.

Temel hesap şu:

Başarıyla tamamlanan görev başına maliyet = iş akışının toplam işletme maliyeti / kabul koşulunu karşılayan görev sayısı

Toplam maliyete model tokenları, harici araçlar, retrieval altyapısı, yeniden denemeler, doğrulama, izleme ve gereken insan incelemesi girer. Yazılım geliştirme gibi sabit giderler, tam yatırım hesabı yapılacaksa ayrıca dağıtılabilir. Yeniden yapılması gereken veya sonraki aşamada düzeltme çıkaran işler başarılı görev sayısına eklenmez.

Örnek bir ayda 10.000 görev geldiğini düşünelim. Model çağrıları, araçlar ve yeniden denemeler 600 dolar, izleme 400 dolar tutuyor. İnceleme ekibi de saatlik toplam maliyeti 40 dolar olmak üzere 120 saat çalışıyor. Ay sonunda 8.000 görev kabul koşulunu karşılıyor.

Yalnızca API faturasına bakıldığında maliyet istek başına altı sent çıkıyor. İşletme maliyetinde ise 5.800 dolar kabul edilen 8.000 göreve bölünüyor ve başarılı görev başına yaklaşık 73 sent bulunuyor. İki hesap da doğru, fakat tamamlanan işin değeriyle karşılaştırılabilecek rakam ikincisi.

Bu hesap, farklı çözümleri aynı ölçüyle karşılaştırmayı da sağlıyor. Küçük model, inceleme yükünü artırmadan kabul edilen görev başına maliyeti düşürüyorsa işe yarıyor. Önbellekleme de sonucu değiştirmeden tekrarları azalttığı sürece fayda sağlıyor. Daha pahalı bir model ise yeterince yeniden denemeyi ortadan kaldırdığında yüksek token ücretini çıkarabiliyor.

API faturasındaki bir kalemin küçülmesi tek başına tasarruf değil. Kabul edilen işin de ucuzlaması gerekiyor.

Harcama başlamadan sınır belli olmalı

İzleme, bir çalıştırmanın ne kadar harcadığını bittikten sonra gösterir. Bütçe ise daha başlamadan sınırı belirler.

Tek model yanıtında çıktı sınırı yeterli olabilir. Birden fazla adımdan oluşan iş akışında model çağrısı, araç denemesi, yeniden deneme ve toplam maliyet için de sınır gerekir. Bir deneme daha yapmanın harcanacak paraya değip değmeyeceğini sisteme bırakmak iyi bir fikir değil.

Sınıra gelindiğinde ne olacağı işe göre değişir. Araştırma aracı, o ana kadar bulduklarını ve nerede durduğunu gösterebilir. Müşteri talebi, toplanan kanıtlarla birlikte bir çalışana aktarılabilir. Sonucu önemli bir işlemde ise eksik bilgiyle yanıt üretmek yerine durmak daha güvenli olabilir.

Bütçe yalnızca altyapı ekibinin göreceği bir ayar değil. Sınır dolduğunda kullanıcıya ne olacağını belirlediği için ürün kararının da bir parçası.

Hesabı daha kötü koşullarla da denemek gerekir. Promosyon kredisi kaldırılabilir, model fiyatı artırılabilir. Ortalama yerine gözlenen 95. yüzdelik çalışma kullanılabilir. İlk denemedeki başarı oranı düşürülüp pilot ekibinin şimdiye kadar görünmeden üstlendiği inceleme süresi hesaba eklenebilir. Ürün bu koşullarda da değer üretiyorsa maliyet hesabı sağlamdır. Kredi kalkınca hesap dağılıyorsa pilotun başarısını ürün kadar finansman koşulları da açıklıyor demektir.

Bir milyon token yerine yüz görevi takip edin

Başlangıç için şirket çapında bir maliyet projesine gerek yok. Üretimde çalışan tek bir iş akışını seçip yüz gerçek görevi, ilk istekten kabul edilen sonuca kadar izlemek yeterli.

Bu yüz görev için ekip model çağrılarını, token kullanımını, araç ücretlerini, yeniden denemeleri, inceleme süresini ve nihai sonucu kaydeder. Önce medyan çalışmayı inceler, ardından pahalı uçtaki kayıtları ayırıp tek tek okur. Son olarak kredi ve geçici indirimleri hesaptan çıkarır ve maliyeti yeniden hesaplar.

Çoğu zaman büyük bir mimari sorundan önce daha sıradan israflar bulunur: Aynı bağlam iki kez gönderiliyordur, yeniden deneme sınırı gereğinden yüksektir veya tamamlanmış görünen bir çıktı sonradan elle düzeltiliyordur.

Model, prompt, araçlar ya da kabul koşulları değiştikçe ekip aynı ölçümü yeniden yapar. Ucuzlayan tokenların ürün maliyetini gerçekten düşürüp düşürmediği ancak böyle anlaşılır. Belki de yalnızca daha fazla token harcamayı kolaylaştırıyordur.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

LLM fine-tuning için 50 örnek yeter mi?

Mon, 10 Aug 2026 00:00:00 GMT

LLM fine-tuning için kaç örnek gerekir? Bu soruya 50, 500 ya da 5.000 gibi tek bir sayıyla yanıt vermek kolay. Sorun şu ki veri kümesinin büyüklüğü, tek başına pek bir şey anlatmaz.

Birbirinin neredeyse aynısı 1.000 kayıt, olağan vakaları, sınır durumlarını, reddedilmesi gereken istekleri, farklı çıktı biçimlerini ve şirkete para kaybettiren hataları kapsayan 100 iyi seçilmiş örnekten daha az işe yarayabilir. Asıl mesele kaç satır olduğu değil, modelin öğrenmesi gereken davranışların veri kümesinde yer alıp almadığıdır.

Yine de bir yerden başlamak gerekir. Temel model hedeflenen davranışa zaten yakınsa, supervised fine-tuning (denetimli ince ayar) için özenle incelenmiş 50 örnek, tek ve dar kapsamlı bir davranışı sınamaya yetebilir. Birkaç farklı vaka türü içeren görevlerde çoğu zaman yüzlerce örnek gerekir. Kapsam genişledikçe, birden fazla dil devreye girdikçe veya hataların maliyeti arttıkça ihtiyaç binlere çıkabilir. Ancak ilk değerlendirmeyi yapmadan bu kadar veri toplamak genellikle hatadır.

Dolayısıyla aşağıdaki sayılar üretim garantisi değil, ilk deney için başlangıç noktalarıdır. Gerçek ihtiyaç; modelin ne öğrenmesi gerektiğine, temel modelin bugünkü performansına ve önemli vakaların veri kümesinde ne ölçüde temsil edildiğine bağlıdır.

Bu yazıda, girdi ve istenen çıktı örnekleriyle yapılan supervised fine-tuning ele alınıyor. Modelin tamamını güncellemek veya LoRA gibi parametre verimli bir yöntem kullanmak bu kapsama girer. Tercih optimizasyonu ile reinforcement fine-tuning ise farklı veri türleri gerektirir ve ayrıca değerlendirilmelidir.

İlk deneyde kaç örnek kullanılmalı?

Tablodaki aralıklar, üretimde kullanılacak nihai veri kümesini değil ilk deneyi planlamak içindir.

50 örnek önerisi rastgele seçilmiş değil. OpenAI’ın supervised fine-tuning dokümanına göre iyileşmeler çoğu zaman 50 ila 100 örnek arasında görülmeye başlıyor. Doküman, özenle hazırlanmış 50 gösterimle başlayıp sonucu ölçmeyi öneriyor. Bu, ilk deney için anlamlı bir dayanak sunar; her görev için geçerli evrensel bir alt sınır koymaz. OpenAI supervised fine-tuning rehberi

Araştırmalar da aynı sayının her durumda aynı sonucu vermediğini gösteriyor. Kontrollü bir soru yanıtlama çalışmasında, o çalışmaya özgü koşullar altında 60 eğitim örneğiyle faydalı sonuçlar elde edildi. Başka bir çalışmada ise Llama 3 8B Instruct modeline 1.000 veya 2.000 çeviri örneğiyle fine-tuning uygulanması, temel modelden daha kötü sonuç verdi. Örnek sayısının anlamını görev, model, veri ve değerlendirme yöntemi birlikte belirler. Soru yanıtlama çalışması Çeviri çalışması

Fine-tuning gerçekten gerekli mi?

Bazen doğru sayı sıfırdır.

Şirket içinde kullanılan bir asistan güncel olmayan ürün fiyatları veriyorsa, son kataloğu eğitim verisine dönüştürmek değişen bilgileri model ağırlıklarına gömer. Fiyatlar yeniden değiştiğinde eğitim verisi de eskir. Retrieval veya doğrudan veri tabanı sorgusu daha uygundur; çünkü bilgi kaynağı, modeli yeniden eğitmeden güncellenebilir.

Fine-tuning, eksik olan şey bilgi değil davranışsa daha anlamlıdır. Model belirli bir yanıt biçimini tutarlı kullanamıyor, sabit bir sınıflandırma sistemini uygulayamıyor, kuruma özgü terminolojiyi karıştırıyor veya yanıt politikasına her zaman uymuyor olabilir. Yine de eğitime geçmeden önce daha açık bir prompt ve bağlam içinde verilen birkaç örnek denenmelidir. Fine-tuning, prompt veya deterministik kodla yeterince iyi çözülemeyen, ölçülmüş bir soruna karşılık gelmelidir.

Hedef de ölçülebilir olmalıdır. “Şirketimizi anlasın” böyle bir hedef değildir. “Her talebi altı kategoriden birine atasın ve sonucu bu şemayla döndürsün” ise doğrudan sınanabilir. Uzmanlar doğru yanıtın ne olduğu konusunda anlaşamıyorsa, veri kümesi kaç örnek içerirse içersin eğitime hazır değildir.

Veri ihtiyacını belirleyen dört etken

1. Görev ne kadar geniş?

Yalnızca dört etiketten birini seçen bir sınıflandırıcının kapsamı, bir konuşmayı okuyup sözleşmeyi uygulayan, yanıt taslağı hazırlayan ve insan onayı gerekip gerekmediğine karar veren bir sisteminkinden çok daha dardır. Doğru çıktıyı değiştiren kararları ve koşulları sayın. Proje çok genişse veri miktarını tahmin etmeden önce birkaç küçük fine-tuning görevine ayırmak gerekebilir.

Örnek sayısı, eğitim verisinin token miktarını da gizler. Elli kısa sınıflandırma kaydı ile araç çağrıları ve yapılandırılmış çıktılar içeren 50 çok turlu konuşma, aynı miktarda eğitim malzemesi sunmaz. Vaka kapsamını planlarken kayıt sayısına, eğitim maliyetini hesaplarken token miktarına bakın.

2. Veri kümesi hangi vakaları kapsıyor?

Geçmiş kayıtlar doğal olarak sık karşılaşılan vakalarda yoğunlaşır. Destek kayıtlarından rastgele alınan bir örneklemde yüzlerce teslimat güncellemesi bulunabilir. Buna karşılık itirazlı ücretler, belirsiz iptaller, birbiriyle çelişen politikalar veya modelin reddetmesi gereken talepler yok denecek kadar az olabilir. Ortalama doğruluk yükselirken riskli vakalardaki performans yerinde sayabilir.

Tekrarlanan kayıtlar da sayıyı yanıltır. Kopyalar, aynı şablonun küçük farklarla üretilmiş sürümleri ve tek bir konuşmanın birkaç kez dışa aktarılması, modele yeni bir davranış göstermeden satır sayısını artırır. Birbirinden farklı ve uzmanlarca incelenmiş 100 örnek, tekrarlardan oluşan binlerce kayıttan daha fazla şey öğretebilir.

Aşağıdaki karşılaştırma, yüksek örnek sayısıyla geniş vaka kapsamının aynı şey olmadığını gösteriyor.

3. Temel model göreve ne kadar yakın?

Fine-tuning, mevcut bir modeli sıfırdan eğitmek yerine modelin zaten sahip olduğu yetenekleri belirli bir göreve uyarlar. Model neredeyse doğru yanıt veriyorsa küçük bir veri kümesi davranışı tutarlı hâle getirebilir. Girdiyi sık sık yanlış anlıyor veya görev için gereken temel bir yeteneğe sahip değilse, daha fazla örnek yalnızca benzer vakalarda çalışan kırılgan bir iyileşme sağlayabilir.

Büyük bir etiketleme çalışmasına bütçe ayırmadan önce, eğitimden ayrı tutulan aynı değerlendirme kümesini birkaç uygun temel modelle deneyin. Daha güçlü bir model daha az veriye ihtiyaç duyabilir. Daha küçük bir model de dar kapsamlı görevi öğrenip daha düşük işletme maliyeti sunuyorsa daha iyi seçenek olabilir.

4. Etiketler tutarlı mı, hatalar ne kadar riskli?

Birbiriyle çelişen örnekler kendi kendine tutarlı bir politikaya dönüşmez; yalnızca modelin ne yapması gerektiğini belirsizleştirir. Uzmanların anlaşamadığı vakaları inceleyin, hangi kuralın uygulanacağını yazılı hâle getirin ve kuralın sınırında kalan örnekleri veri kümesine ekleyin.

Hatanın doğuracağı sonuçlar da gereken kanıt düzeyini değiştirir. Düşük riskli bir biçimlendirme görevi, sınırlı bir değerlendirmeden sonra ilerleyebilir. Para, erişim, güvenlik veya hukuki yükümlülükleri etkileyen bir iş akışı ise daha geniş vaka kapsamı ve daha güçlü testler gerektirir. Hiçbir örnek sayısı, zayıf kanıtı güvenli bir sisteme dönüştürmez.

Değerlendirme verisini baştan ayırın

Uzmanların incelediği 200 vakanın tamamı eğitimde kullanılamaz. Bir bölümü modele hiç gösterilmemelidir.

Eğitimden ayrı tutulan bu küme, modelin yalnızca gördüğü örnekleri ezberleyip ezberlemediğini ve öğrendiği davranışı yeni vakalara taşıyıp taşıyamadığını gösterir. Birbiriyle ilişkili kayıtları birlikte tutun. Aynı konuşmadaki mesajlar, aynı belge şablonundan gelen sayfalar veya tek bir örnekten üretilmiş sentetik varyasyonlar eğitim ve değerlendirme kümelerine bölünmemelidir.

Aksi hâlde veri sızıntısı, gerçekte olmayan bir ilerleme izlenimi yaratabilir. Bir çalışmada modelin değerlendirme şablonlarını ve yanıtlarını görmesi, ayrı bir değerlendirmede benzer bir iyileşme sağlamadığı hâlde ilgili benchmark üzerindeki performansı yüzde 45’ten fazla artırdı. ACL 2024

Değerlendirme yalnızca iyileştirilmek istenen davranışı değil, modelin kaybetmemesi gereken yetenekleri de sınamalıdır. Genel talimatları izleme ve gerektiğinde yanıt vermeyi reddetme bunlara örnektir. Riskli işlerde tek bir ortalama puanla yetinmeyin; sonuçları vaka türlerine göre ayrı ayrı raporlayın.

Doğru sayıyı deneyerek bulun

Önemli vakaları temsil eden küçük bir veri kümesiyle başlayın. Modeli eğitin ve eğitimde kullanılmamış vakalarla ölçün. Önemli hatalar azalıyorsa, veri kümesinde eksik kalan alanlardan ve gözlenen hatalardan seçilmiş yeni bir grup ekleyin. Ayarları mümkün olduğunca sabit tutarak tekrar eğitin.

Bu deneyler bir öğrenme eğrisi oluşturur ve bir sonraki kararı kolaylaştırır:

Sonuçlar hızla iyileşiyorsa hedefli bir grup daha eklemek işe yarayabilir.
İyileşme yavaşlıyorsa beklenen kazancı etiketleme ve eğitim maliyetiyle karşılaştırın.
Sonuç değişmiyorsa daha fazla veri toplamak yerine görevi, etiketleri, prompt yaklaşımını veya temel modeli yeniden değerlendirin.

Model kabul ölçütlerini karşıladığında, yeni bir grubun sağlayacağı iyileşme harcanacak emeğe değmediğinde veya hata analizi başka bir çözüme işaret ettiğinde durun. Veri kümesinin büyüklüğü baştan konan bir satın alma hedefi değil, deneyler ilerledikçe ortaya çıkan bir sonuçtur.

Aşağıdaki araç, projenin koşullarına göre ilk deney için makul bir aralık önerir. Proje henüz böyle bir tahmine hazır değilse sayı vermek yerine önce çözülmesi gereken sorunu gösterir.

Kısa cevap

Temel model hedef davranışa zaten yakınsa, tek ve dar kapsamlı bir supervised fine-tuning görevi için yaklaşık 50 iyi örnekle başlayın. Birden fazla vaka türünün, çıktı biçiminin veya dilin temsil edilmesi gerekiyorsa 100 ila 300 örnek daha makul bir başlangıç olabilir. Geniş görevleri ise veri miktarını tahmin etmeden önce parçalara ayırın.

Değerlendirme vakalarını eğitimin dışında tutun, önemli hata türlerini ayrı ayrı ölçün ve yeni veriyi rastgele değil, eksik kalan alanlara göre ekleyin. Model eğitimde görmediği vakalarda kabul ölçütlerini karşılıyor ve yeni bir veri grubu artık en iyi iyileştirme yolu olmaktan çıkıyorsa yeterli veri var demektir.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Yapay zeka projenizdeki iş ortağınız şirketinizi gerçekten anlıyor mu?

Mon, 27 Jul 2026 00:00:00 GMT

Yapay zeka, danışmanlık firmalarının müşterinin işini anlamadan önce hazırlıklı görünmesini kolaylaştırdı. Ekip, teklif hazırladığı şirket hakkında henüz çok şey öğrenmeden açık, somut ve görsel açıdan tamamlanmış bir teklif hazırlayabiliyor. İnandırıcı bir demo için de eskisi kadar zaman ve teknik çalışma gerekmiyor.

Özenli bir teklifin sahte olması gerekmez. Yetkin ekipler aynı araçları çoğu zaman çok iyi kullanır. Ancak teklifin görünümü, alıcıya eskisine göre daha az şey söyler.

Bu önemli; çünkü şirketler yapay zeka projelerinde birlikte çalışacakları iş ortağını seçerken hâlâ alışıldık işaretlere bakıyor. Sunumun kalitesini, önerinin ne kadar güvenle sunulduğunu ve demonun çalışıp çalışmadığını değerlendiriyorlar. Bunların hepsi dikkate değer. Ama hiçbiri, iş ortağının doğru işi önerecek kadar şirketi anlayıp anlamadığını göstermez.

Bir öneri sunmadan önce iş ortağının hangi soruları sorduğuna bakın. Ardından cevap verirken hangi koşulları vurguladığını, eksik ya da tartışmalı bilgilerle nasıl başa çıktığını dinleyin. Bunları üretmek daha zordur; çünkü müşterinin gerçek durumuna dayanırlar.

Her yerde kusursuz görünen çıktılar varken asıl değerli işaret, önerinin arkasındaki muhakemedir.

Demo yalnızca demoda olanı kanıtlar

Demo görmeye değerdir. Ekibin bir fikri somut bir şeye dönüştürüp dönüştüremediğini gösterir ve herkese somut olarak üzerinde konuşabileceği bir şey sunar. Bu bile bir saatlik belirsiz vaatlerden iyidir.

Bir demodan kanıtlayabileceğinden fazlası beklendiğinde sorun başlar.

Demoların çoğu seçilmiş girdiler ve iş akışı boyunca sorunsuz ilerleyen bir yol kullanır. Bu normaldir. Kimse bir satış toplantısına, prototipin bozuk bir elektronik tabloda hata vermesini izleyerek başlamak istemez. Ancak demoyu anlaşılır kılan koşullar, çoğu zaman üretimde ortadan kaybolan koşullarla aynıdır.

Kaynak verinin nereden geldiğini sorun. Hangi izinlerin basitleştirildiğini sorun. İlk sürümde ele almak için fazla zahmetli bulunduğu için prototipin dışında bırakılan şeyleri sorun. İki belge birbiriyle çelişirse hangisi geçerli sayılacak? Sistem kötü bir öneride bulunursa bunu kim fark edecek? Bir vaka bir insana ulaştığında, onunla birlikte hangi bağlam aktarılacak?

Yanıtlar, demonun neleri kapsadığını gösterir. Ayrıca iş ortağının demo ekranının çalışmasıyla yazılımın gerçek kullanımda çalışması arasındaki farkı ciddiyetle düşünüp düşünmediğini de açığa çıkarır.

Yapay zeka yardımıyla hazırlanan sunumlara ilişkin araştırmalar bu ayrımı somutlaştırıyor. Columbia Business School’da yapılan bir deneyde, yapay zeka desteği deneyimli değerlendiricilerin yalnızca sunuma bakarak uzmanları uzman olmayanlardan ayırmasını zorlaştırdı. Araştırma, gerçek uzmanların dil engellerini aşarak daha etkili iletişim kurabildiğini de buldu. Özenli bir sunum iyi işin daha geniş kitlelere ulaşmasına yardımcı olabilir. Ama alıcıya asıl düşünmeyi kimin yaptığını daha az gösterir. Columbia Business School

Bu yüzden demoyu ciddiye alın. Ardından neleri göstermediğini sorun.

İş ortağının sorduğu sorulara dikkat edin

Diyelim ki iş özeti şöyle: “Müşteri desteğini otomatikleştirmek istiyoruz.”

Bir iş ortağı bunu destek asistanı geliştirme isteği olarak duyar. Diğeri ise müşterilerin şirkete hangi nedenlerle ulaştığını, bu taleplerin nasıl çözüldüğünü ve hangi vakaların en uzun sürdüğünü görmek ister. Bu ikinci yaklaşım, temsilcilerin zaten hızlı yanıt verdiğini ortaya çıkarabilir. Gecikme daha sonra, para iadesi için başka bir departmandaki birinin onayı gerektiğinde ortaya çıkıyordur.

Bu şirkette daha iyi metin üretimi darboğazı çözmez. İlk iş özeti, sürecin gecikmeye yol açan kısmını değil, görünür kısmını işaret eder.

Bu sorular, iş ortağının çözümü doğrudan iş özetine göre şekillendirmeden önce şirketin işleyişini nasıl kavradığını gösterir. Yapay zekanın ürettiği yanıttan sonra ne olduğunu sormak, konuşmayı sonuca bağlı tutar. Kararı kimin değiştirebileceğini sormak ise yetki meselesini görünür kılar. Fiilen karşılaşılan istisnaları da incelemek gerekir; çünkü projeyi pahalılaştıran yer nadiren ortalama vakadır.

Tersi bir hata da var: keşif tiyatrosu. Bir ekip düzinelerce soru sorabilir, beyaz tahtayı oklarla doldurabilir ve yine de öneriyi değiştirecek hiçbir şey öğrenmeyebilir. Ayrıntılı çalışmak, isabetli muhakeme kurmakla aynı şey değildir.

İyi iş ortağı, hangi ayrıntının yaklaşımı değiştireceğini, hangisinin sonraki aşamaya bırakılabileceğini ayırt eder. Bu ayrımı konuşmada duyabilmelisiniz: “Politikalarınız çelişiyorsa önce bunu çözmeliyiz. Sorun yalnızca biçimlendirmeyse iş akışının içinde ele alabiliriz.”

Bu, teklifte kaç atölye çalışmasının yer aldığından çok daha fazla şey anlatır.

Bu yaklaşımın işe yaraması için ne gerekli?

“Bunu daha önce yaptınız mı?” sorusu yerindedir. Ne var ki çoğu zaman yanıt yerine bir vaka çalışması gelir.

Daha önceki işler, iş ortağının benzer yöntemleri ve bunların nerelerde aksadığını gördüğünü gösterebilir. Ama aynı koşulların burada da geçerli olup olmayacağını söylemez. Aynı destek asistanı, politikaların sabit olduğu bir şirkette iyi çalışabilir; ilişki yöneticilerinin her gün istisna yaptığı bir şirkette ise başarısız olabilir. Bir fatura iş akışı, sınıflandırma hatasının sözleşme uyuşmazlığı doğurduğu az sayıdaki belgeyle karşılaşana kadar kusursuz görünebilir.

Daha iyi soru şudur: “Bu yaklaşımın burada işlemesi için neyin doğru olması gerekiyor?”

Yanıt somut olmalıdır. Belki projenin tek ve yetkili bir politika kaynağına ihtiyacı vardır. Belki entegrasyon, güvenlik ekibinin vermeyi henüz kabul etmediği izinlere bağlıdır. Belki şirketin istisnalardan sorumlu olacak yeterli yetkiye sahip birine ihtiyacı vardır. Bunlar, iş ortağını korumak için eklenen çekinceler değildir. Önerinin parçasıdır.

Aynısı pilot çalışma için de geçerlidir. “Bunu dört haftada yapabiliriz” demek hız hakkında bir şey söyler. Şirketin bu dört haftanın sonunda ne öğreneceği hakkında ise hiçbir şey söylemez. Pilotun hangi kararı değiştirmesi beklendiğini sorun. Yanıt yoksa pilot etkileyici bir nesne üretip ilk belirsizliği olduğu gibi bırakabilir.

Araçtaki iddiaların hiçbiri tek başına bir uyarı işareti değildir. Takip sorusunun amacı, iddiayı satış dilinden çıkarıp müşterinin gerçek koşulları içinde değerlendirmektir.

Geniş bir hedefi karara dönüştürün

“Verimizi daha iyi kullanmak” kötü bir başlangıç noktası değildir. “Yapay zekadan yararlanabilecek bir iş bulmak” da öyle. Şirketler çoğu zaman sorunun henüz net olmaması nedeniyle dışarıdan destek arar.

Yine de iş birliği bu hedeften ileri gitmelidir.

Bir satış ekibinin müşteri adaylarına öncelik vermek için yapay zeka kullanmak istediğini düşünün. İlk soru, geçmiş verinin gelecek vaat eden bir müşteriyi satış ekibinin yalnızca daha çok ilgi gösterdiği bir müşteriden ayırıp ayıramadığı olabilir. Ayıramıyorsa model seçimi için erkendir. Acil karar; şirketin satış faaliyetlerini kaydetme biçimini düzeltmesi, daha temiz kanıtlarla daha küçük bir test yapması ya da fikri rafa kaldırması gerekip gerekmediğidir.

Bu, müşteri adaylarını puanlayan bir demodan daha az heyecan verici gelebilir. Ama şirketin harekete geçebileceği bir karardır.

Bize göre bu, dışarıdan gelen bir iş ortağının verilen görevi kavradığının en açık işaretlerinden biridir. Belirsizliğin ortadan kalkmış gibi davranmadan geniş bir talebi daha net bir şeye dönüştürebilirler. Müşteri, önündeki seçeneğin ne olduğunu, hangi kanıtın yardımcı olacağını ve hangi işlerin güvenle bekleyebileceğini bilir.

İş ortağı yalnızca iş dilini teknik gereksinimlere çevirmekten fazlasını yapmıştır. Soruyu iyileştirmiştir.

Uzmanlık, bilgi tükendiğinde ortaya çıkar

Her ciddi projede mevcut bilginin tükendiği bir nokta vardır. Veri kümesi eksiktir. İki ekip istenen sonuç konusunda anlaşamaz. Kullanıcıların öneriye göre hareket edecek kadar güvenip güvenmeyeceğini kimse bilmez.

Özenli görünen teklifler bu karmaşıklığı gizlemeye eğilimlidir. Oysa müşterinin muhakemeye en çok ihtiyaç duyduğu yer burasıdır.

Yetkin bir iş ortağı her bilgi boşluğuna aynı şekilde yaklaşmaz. Bazı bilinmeyenler kısa bir testle çözülebilir. Bazılarında işin sahibi karar vermelidir. Bazılarının ise öneriyi etkilemesi pek olası değildir; şimdilik açık bırakılabilirler. Asıl iş, hangisinin hangisi olduğuna karar vermektir.

Her bilinmeyeni sessizce bir varsayıma dönüştüren tekliflere temkinli yaklaşırız. Müşteriden kusursuz bilgi gelmeden hiçbir şey önermeyi reddeden bir iş ortağı da pek yardımcı olmaz. Şunu söyleyebilmelidir: “Bunu henüz bilmiyoruz, ama öğrenmenin hem dürüst hem de en düşük maliyetli yolu bu.” Ardından sonucun ters çıkması durumunda ne yapacağını açıklamalıdır.

2.000’den fazla inovasyon teklifini kapsayan bir Harvard Business School saha deneyi, yapay zekanın ayrıntılı açıklamalar eşliğinde sunduğu önerilerin, öneri yanlış olsa bile değerlendiricileri ikna edebildiğini gösterdi. Nesnel eleme ölçütleri, insanların ve yapay zekanın değerlendirmeleri arasında daha iyi uyum sağladı. Sorun akıcı bir gerekçenin varlığı değildi. Değerlendiriciler, gerekçeye dayandığı kanıtın hak ettiğinden daha fazla ağırlık verdi. Harvard Business School

Bir iş ortağı seçerken de aynı dikkati göstermek gerekir. Kanıttan öneriye giden yolu takip edebilmelisiniz. Hangi bilgiler müşteriden geliyor? Hangi bölümler varsayım? İş ortağı hangi alternatifleri, neden reddetti? Önerinin hangi durumda değişeceğini de bildiğinizde ona güvenmek kolaylaşır.

Bir sonraki görüşmede nelere odaklanmalı?

Yapay zeka her danışmanlık firmasını birbirine benzetmedi. Hazırlıklı görünmenin maliyetini düşürdü. Güçlü ekipler de bundan yararlanıyor; bu yüzden özenli görünmesi, ne iyi ne kötü olduğuna tek başına kanıt sayılmaz.

Demoyu ciddiye alın, ama demonun neyi kanıtladığına dair iddiayı sınırlı tutun. İş ortağının sorularının ilk talepte eksik olan bir şeyi ortaya çıkarıp çıkarmadığına bakın. Şirketinizde neyin doğru olması gerektiğini sorun. Başkasının vaka çalışması buna yanıt veremez. Bilgi eksik olduğunda sırf kendinden emin sözler ya da bitmek bilmeyen çekinceler yerine, gerekçelendirilmiş bir sonraki adımı dinleyin.

İyi geçen ilk görüşmenin sonunda, en kendinden emin tedarikçinin vaat ettiği nihai sistemin nasıl görüneceği hakkında daha az şey biliyor olabilirsiniz. Ama önünüzdeki karar hakkında çok daha fazla şey biliyor olmalısınız.

Bize göre ölçüt budur. Bir iş ortağı, çözümü satmayı zorlaştıran kısımlar dahil olmak üzere problemi daha iyi anlamanızı sağladığında şirketinizi anlamıştır.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Başlamak kolaylaştı. İşi bitirmek hâlâ zor.

Mon, 13 Jul 2026 00:00:00 GMT

Yapay zeka, henüz çözülmemiş tek bir müşteri probleminden araştırmaları ve çalışan prototipleriyle birlikte birkaç özenli çözüm üretebilir. Bir ürün ekibi bu seçenekleri kısa sürede hazırlar ve her biri peşinden gitmeye değecek kadar ikna edici görünür.

Eskiden bir ay süren işi birkaç günde çıkarmak ilerleme gibi görünür.

Sonra değerlendirme toplantısı başlar.

Prototiplerin her biri problemin farklı bir yorumuna yanıt verir. Araştırmalar birbiriyle bağdaşmayan birkaç sonucu destekler. Aralarında seçim yapmak için hangi kanıtın gerektiği baştan kararlaştırılmamıştır. Seçeneklerden biri güvenlik onayı ister. Bir diğeri destek ekibinin iş akışını değiştirir. Üçüncüsünün ise devreye alındıktan sonra belirgin bir sahibi yoktur. Toplantı bir karşılaştırma daha yapılması talebiyle biter.

Çıktılarda bir sorun yoktur. Sadece kurumun sonuçlandırabileceğinden çok daha fazlası üretilmiştir.

Aynı durum farklı bilgi işlerinde de görülüyor. Yapay zeka, insanların üzerinde konuşabileceği makul bir ilk sürüm üretmenin maliyetini düşürüyor. Bu ilk sürüm bir taslak, analiz, tasarım, öneri ya da prototip olabilir. Ancak şirketler makul başlangıçları biriktirerek değer yaratmaz. Önce hangi işe kaynak ayıracaklarına karar vermeleri gerekir. Ardından o işi gerçeğe dönüştüren kısıtları aşmalı ve geri kalanını durdurmalıdırlar.

Yapay zeka işe başlamayı ucuzlatıyor. Avantaj, başladığı işi bitirebilen kurumlara geçiyor.

Üretim ucuzlarken yarım işlerin maliyeti artar

Yapay zeka desteğiyle bir işe başlamak neredeyse bedavaymış gibi gelebilir. Kimse henüz zor bir karar vermemişken fikir, bir araştırma özetine, birkaç tasarıma ve bir prototipe dönüşür.

Maliyetler daha sonra ortaya çıkar.

Her yeni girişimin mevcut önceliklerle karşılaştırılması gerekir. Kanıtları kontrol edecek ve bağımlılıkları çözecek biri olmalıdır. Sonraki adıma da yine birinin karar vermesi gerekir. Bir prototip güvenlik incelemesinden geçebilir. Bir kampanya içinse hukuk onayı ve üretim kapasitesi gerekebilir. İş müşteriye ulaşsın ya da ulaşmasın, kurum ona ayırdığı dikkatin bedelini öder.

Üretilmiş bir belge, tamamlanmamış iş stoğudur. Bir kararı değiştirmediği ya da tamamlanmış bir sonuca ulaşmadığı sürece kurumun sınırlı dikkati için diğer işlerle rekabet eder.

İş hayatında yapay zeka üzerine yapılan araştırmalar bu ayrımın bir bölümünü şimdiden gösteriyor. 6.000 bilgi çalışanıyla altı ay boyunca yürütülen rastgele kontrollü bir saha deneyinde üretken yapay zekaya erişim, insanların tek başına değiştirebildiği faaliyetleri etkiledi: Kullanıcılar e-postaya daha az zaman ayırdı ve belgeleri daha hızlı tamamlamış göründü. Ancak ilerlemenin başkalarının da birlikte değişmesine bağlı olduğu toplantılarda geçirilen süre anlamlı ölçüde değişmedi. Araç, bireysel üretimi kurumsal koordinasyondan daha kolay hızlandırdı. Microsoft Research

Bireysel kazanımlar gerçek. Ancak işin geri kalanına kendiliğinden yayılmıyorlar.

Başlangıçlar ucuzladıkça kurumlar daha fazla işe başlanmasına izin verir. Bunun sonucunda değerlendirme yapanların önüne daha çok içerik gelir. Yöneticiler dikkatlerini daha fazla girişim arasında bölmek zorunda kalır. Ekipler de kolayca onaylanan denemelerin bakım işini devralır.

Düşük üretim maliyeti, yüksek fırsat maliyetini gizleyebilir. Ekipler “Bunu ne kadar hızlı yapabiliriz?” sorusunun yanına şunu da koymalı: “Bu işi sürdürürsek hangi başka işten vazgeçeceğiz?”

Prototip artık tek başına güven telkin etmez

Çalışan bir prototip eskiden birinin bütçe bulduğuna ve ciddi zaman harcadığına işaret ederdi. Bu, ürünün iyi olduğunu kanıtlamazdı ama maliyet bir filtre görevi görürdü. Çok az fikir o aşamaya tesadüfen ulaşırdı.

Yapay zeka bu filtreyi zayıflatıyor.

Küçük bir ekip artık problemle ilgili temel soruları yanıtlamadan ikna edici bir şey üretebilir. Arayüz çalışır. Örnek veri inandırıcı görünür. Demo da tamamlanmış bir ürünü andırır.

Bu tamamlanmışlık hissi konuşmanın yönünü değiştirir. Karar vericiler problemin yatırıma değip değmediğini sormayı bırakıp renkleri, özellikleri ve çıkış tarihini tartışmaya başlar. Prototipin varlığı, fark ettirmeden çalışmaya devam etmenin gerekçesine dönüşür.

Oysa bir prototip yalnızca bu sürümün yapılabildiğini kanıtlar. Problemin önemli olduğunu göstermez. Müşterilerin ürünü kullanacağını ya da kurumun onu güvenle işletebileceğini de kanıtlamaz.

Ucuz prototipler ispat yükünü tersine çevirir. Artık taahhütten önce bir şeyler inşa edilebildiği için, ortaya çıkan ürün tek başına yatırım kararını haklı çıkaramaz. Ekibin bu kararı ayrıca gerekçelendirmesi gerekir.

Yararlı bir prototip, bir karara bağlanmalıdır. Örneğin destek temsilcilerinin bir öneriyi anlayıp anlamadığını ya da müşterilerin yeni bir kayıt akışını tamamlayıp tamamlamadığını sınayabilir. Prototipin hangi kararı kolaylaştırması gerektiğini kimse söyleyemiyorsa ortada devam etmek için gerekçe arayan bir demo vardır.

Hız belirsiz yönü daha tehlikeli hâle getirir

Rutin onaylar ve aynı veriyi tekrar tekrar girmek çoğu zaman işe katkı sağlamaz. Yapay zeka ve otomasyon bu tür gecikmeleri ortadan kaldırmalı.

Ancak bazı sürtünmeler bilgi taşıyordu.

Bir iş özeti yazmak, birini problemi açıklamaya zorluyordu. Bir talebi teknik gereksinimlere dönüştürmek, eksik kararları görünür kılıyordu. Üretimin yavaş olması, farklı ekiplerin aynı sözcükleri farklı hedefler için kullandığını fark etmelerine de zaman tanıyordu.

Yapay zeka, bu konuşmalar yapılmadan çıktıyı üretebilir.

Bir müşteri elde tutma planı istendiğinde, finans ve müşteri başarısı ekipleri hangi müşterilerin önemli olduğu konusunda anlaşamasa bile yapay zeka bir plan çıkarır. Bir ürün prototipi istendiğinde, kimsenin bilinçli olarak seçmediği makul varsayımlarla boşlukları doldurur.

Çıktı o kadar özenli olabilir ki alttaki belirsizliği görmek zorlaşır. Başlıklar, ekranlar ve hesaplar ortaya çıktıkça muğlak yön tarifleri somutlaşmış gibi görünür. Kendinden emin anlatım da bu yanılsamayı güçlendirir.

Bu yüzden netleştirme daha erken yapılmalı. Üretime başlamadan önce verilecek karar ve hedef kullanıcı tanımlanmalıdır. Kısıtlar ile çıktının çözmeye yardımcı olması gereken anlaşmazlık da açıkça ortaya konmalıdır. Aksi takdirde hız, zayıf bir önermenin itirazla karşılaşmadan daha uzun yol almasını sağlar.

Yapay zeka netlik ihtiyacını ortadan kaldırmaz. Netlik eksikliğinin eskiden açığa çıktığı anların birçoğunu ortadan kaldırır.

Seçim ayrı bir beceridir

Yaratıcı ve analitik iş akışlarının çoğu seçimi kısa bir son aşama olarak görür: Birkaç seçenek üret, değerlendir, en iyisini seç ve ilerle. Seçenekleri üretmek zamanın büyük bölümünü aldığında bu iş bölümü makuldü.

Üretim ucuzluyor. Seçim ucuzlamıyor.

Makul seçenekler arasından seçim yapmak farklı bir emek gerektirir. Önce hangi kanıtın geçerli olduğuna karar verilmelidir. Ardından seçeneklerin gerçekten aynı problemi çözüp çözmediğine bakılmalıdır. Öneriyi değiştiren istisnaları fark etmek de bu işin parçasıdır. Üstelik geri alınabilir bir deney ile kurumun yıllarca desteklemek zorunda kalacağı bir taahhüdü birbirinden ayırmak gerekir.

Daha fazla zeka bu soruları kendiliğinden çözmez. Bir model, büyüme stratejisiyle risk azaltma stratejisini karşılaştırabilir. Ancak şirket bu ödünleşimin sorumluluğunu birine vermedikçe hangi sonuca daha çok değer verdiğine karar veremez. Bir politikanın olası etkisini tahmin edebilir. Sonuçlarının sorumluluğunu şirket adına üstlenemez.

Procter & Gamble’dan 791 profesyonelin katıldığı bir saha deneyi önemli bir ayrım sunuyor. Yapay zeka, üretilen fikirlerin kalitesini artırdı. Ürün inovasyonu çalışmalarında bireylerin iki kişilik ekiplerle karşılaştırılabilir düzeyde performans göstermesine de yardımcı oldu. Ancak araştırmacılar fikir üretimini değerlendirmeden ayırdığında insan muhakemesinin hâlâ değer taşıdığı görüldü. Bu değer özellikle seçenekler arasından seçim yaparken ortaya çıktı. Organization Science

Bu bulgu uzmanlığın ortadan kalkacağına değil, biçim değiştireceğine işaret ediyor. Deneyimli bir çalışan temel yanıtı üretmeye daha az zaman ayırabilir. Bunun yerine bir yanıtın kabul edilebilir olup olmadığını anlamaya odaklanabilir. Hangi kaynağın eksik olduğunu ve hangi istisnanın sıradan olmadığını bilir. Kurumun hangi sözü veremeyeceğini de görür. Görünüşte küçük bir ayrıntının üretimde ne zaman pahalıya mal olacağını deneyimi sayesinde fark eder.

Şirketler bunu üretimin sonuna eklenebilecek sıradan bir inceleme işi olarak görmemeli. Seçimin kendi ölçütleri ve ayrılmış bir zamanı olmalıdır. Bu işi yapacak kişilerin yetkiye ihtiyacı vardır. Seçim yapma becerisinin de ayrıca geliştirilmesi gerekir. Kurum reddetme kabiliyetini güçlendirmeden çıktıyı çoğaltırsa üretilen bolluk, en deneyimli çalışanların önünde bir kuyruğa dönüşür.

Üretim ucuzladığında seçimin kalitesi daha önemli hâle gelir.

Ne zaman durulacağına baştan karar verilmeli

Üretken sistemler devam etme konusunda son derece iyidir. Her zaman çalıştırılacak başka bir sorgu ve özetlenecek başka bir kaynak vardır. Yeni bir sürüm üretmek ya da yeni bir istisnayı ele almak da mümkündür. Bir başka prototip yönü ise biraz daha iyi olabilir.

Birisi dur diyene kadar üretken sistemler memnuniyetle devam eder. Kurumların bu sınırı koyması gerekir.

Bir durdurma kuralı, araştırma ve deneme sürecinin hangi koşullarda devam edeceğini ya da sona ereceğini tanımlar. Önce sınanan işi ve yeterli sayılacak kanıtı belirler. Ardından kararın sahibini ve kanıtın ortaya çıkması gereken son tarihi tanımlar.

Sıralama önemlidir. Kural, prototip etkileyici göründükten sonra konursa ölçütler üretilmiş işe göre esner. Ekip haftalarca araştırma yaptıktan sonra konursa durmak, yapılan yatırımı boşa çıkarmak gibi gelir. Üretim başlamadan yazılan bir kural, kararı çıktının ikna gücünden korur.

Zaman da kuralın parçası olmalıdır. Analizler güncelliğini yitirir. Pazar fırsatları kapanır. Müşteri ihtiyaçları değişir. Olası bir girişim, bir revizyon daha üretmek ucuz olduğu için süresiz olarak iş listesinde kalmamalıdır. Bazı işler zaman aşımına uğramalıdır.

Kural yine de öğrenmeye alan tanımalıdır. Yeni kanıtlar sürenin uzatılmasını haklı çıkarabilir. Ancak bu uzatma, yarım kalmış işlerin varsayılan durumu değil bilinçli bir karar olmalıdır.

Bir durdurma kuralı iyi karar vermeyi garanti etmez, ama karar vermeyi mümkün kılar.

Otomasyon insanlara işin daha zor kısmını bırakır

Üretimden otomasyona geçmek işi bitirme problemini çözmez. Yalnızca problemin biçimini değiştirir.

100 vakayı ele alan bir hizmet ekibi düşünelim. Vakaların çoğu rutindir. Bazıları yorum gerektirir. Az sayıda vaka ise sıra dışıdır. Bu vakalar önemli sonuçlar doğurabilir ya da duygusal açıdan zor olabilir. Rutin vakaları otomatikleştirmek insanlara ulaşan iş sayısını azaltır. Bu genellikle gerçek bir iyileşmedir.

Ancak insanlara kalan sıradan bir vakanın niteliğini de değiştirir.

Çalışan artık kolay ve zor işler arasında gidip gelmez. Kuyruğundaki istisnaların oranı yükselir. Eksik belgeler ve çelişen politikalarla daha sık karşılaşır. Sıra dışı müşteri koşulları ile sistemin çözemediği vakalar da bu kuyrukta birikir. Toplam hacim düşerken ortalama zorluk artar.

OECD’nin farklı iş yerlerinde yürüttüğü vaka çalışmaları bu örüntüyü belgeliyor. Avusturya’daki bir sigorta operasyonunda otomasyon, manuel indeksleme işinin büyük bölümünü ortadan kaldırdı ve çalışanları orta zorluktaki ve karmaşık vakalara yöneltti. Birleşik Krallık’taki bir finansal hizmetler örneğinde ise chatbot temel soruları yanıtlarken insan temsilciler daha fazla zor konuyla ilgilendi. İş yalnızca azalmadı. Vakaların dağılımı değişti. OECD

Bu durum, iş gerekçesini hacme dayandıranlar için önemlidir. Otomatik bir sistem kuyruğun yarısını ortadan kaldırdı diye kurumun insan kapasitesini de yarıya indirebileceği sonucu çıkmaz. Kalan işler daha uzun sürebilir ve daha deneyimli çalışanlar gerektirebilir. Çalışanlar üzerindeki stresi artırabilir. Kötü ele alındıklarında daha büyük risk de taşıyabilirler.

Uzmanlığın gelişimi açısından da önemlidir. İnsanlar yalnızca istisnaları görürse alanı öğrendikleri rutin vakalarla daha az karşılaşır. Kurum uzman muhakemesine daha çok bağımlı hâle gelirken yeni uzmanların yetiştiği yolu zayıflatabilir.

Doğru ölçüt, sistemin tek başına kaç vakayı tamamladığı değildir. Otomasyon ve insanlardan oluşan bütünün, iş dağılımının tamamını güvenilir biçimde sonuçlandırıp sonuçlandıramadığıdır.

Otomasyon yine de yapılmaya değer olabilir. Burada önemli olan, sistemin rutin vakaları sonuçlandırdığı titizlikle düşünme sürecini de tamamlamaktır.

Nelerin biteceğini tesadüfe bırakmayın

Üretilen bolluğa verilecek kolay yanıt, araçları kimlerin kullanabileceğini ya da bir ekibin kaç deney yapabileceğini daha sıkı kurallara bağlamaktır. Bu, görünür hareketliliği azaltabilir. Ancak kurumun asıl ihtiyaç duyduğu beceriyi geliştirmez.

Daha iyi yanıt, tamamlanmanın ne anlama geldiğini açıkça tanımlamaktır.

İşe başlamadan önce verilecek kararı belirleyin. Bir prototipe yatırım yapmadan önce onun neyi kanıtladığını ve neyi kanıtlamadığını açıklayın. Alternatifler üretmeden önce aralarından kimin seçim yapacağına karar verin. Rutin işleri otomatikleştirmeden önce geride kalacak vakaları inceleyin. Yarım kalmış işe, devam etmesi için bir koşul ve sona ermesi için bir tarih verin.

Bu uygulamalar, yapay zekadan yeni bir sürüm istemekten daha yavaş görünebilir. Değildir. Kurumun hiçbir zaman bir karara ulaşamayacak işleri haftalarca değerlendirmesini, koordine etmesini ve sürdürmesini engeller.

Bolluk gerçek. Ekipler daha fazla olasılığı araştırabilir, fikirleri daha açık anlatabilir ve varsayımları birkaç yıl önce mümkün olmayacak bir hızla sınayabilir. Buradaki fırsat, her başlangıcın pahalı olduğu dünyaya geri dönmek değildir.

Fırsat, işe başlamanın maliyetiyle işi bitirmenin değerini birbirine karıştırmamaktır.

Bir sonraki etkileyici taslak, analiz ya da prototip ortaya çıktığında yalnızca ne kadar hızlı üretildiğini sormayın. Önce hangi kararı sonuçlandırması gerektiğini sorun. Ardından bu kararı hangi kanıtın mümkün kılacağını belirleyin. Sonuçların sorumluluğunu kimin üstleneceği de açık olmalıdır. Kanıt hiç gelmezse çalışmanın ne zaman duracağına baştan karar verin.

Başlamak giderek ucuzlayacak. Avantaj, işi bitirebilmekte kalacak.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Yapay zeka projelerinde asıl iş çoğu zaman entegrasyondur

Mon, 29 Jun 2026 00:00:00 GMT

Şirketler, yapılan işin büyük kısmı entegrasyon olsa bile birçok projeyi yapay zeka girişimi olarak tanımlıyor. Bir destek aracına dil modeli ekleniyor, raporlama ekranına tahmin özelliği geliyor veya şirket içi arama kutusu soruları yanıtlamaya başlıyor. Ardından bu etiket strateji sunumlarına, ürün yol haritalarına, işe alım planlarına ve çeyreklik değerlendirmelere giriyor.

Yapay zeka etiketi, birbirinden oldukça farklı işleri aynı şeymiş gibi gösteriyor.

Bir tarafta yeni yapay zeka yetenekleri geliştiren çalışmalar var: Model mimarileri geliştirmek, model eğitmek, öğrenme yöntemleri tasarlamak ve bir sistemin yapabileceklerini genişletmek. Diğer tarafta ise mevcut bir yeteneği belirli bir şirket içinde işe yarar hâle getiren çalışmalar bulunuyor. Bunun için sistemi doğru veriye bağlamak, iş akışına yerleştirmek, neleri yapabileceğine karar vermek, arayüzü kurmak, hataları yönetmek ve sonucun bir sonraki iş adımına ulaşmasını sağlamak gerekiyor.

Şirketlerin çoğu ikinci tür işi yapıyor. Yapay zeka geliştirmiyorlar. Yapay zeka kullanan ürünler ve iş akışları geliştiriyorlar.

Bu daha önemsiz bir iş değil. Çoğu durumda iş değerinin tamamını bu çalışma yaratıyor. Ancak bileşenle yapılan işi birbirine karıştırmak, dikkati yanlış yere yöneltiyor. Ekipler için asıl sorun modelin zekasını belirli bir işletme içinde faydaya dönüştürmekken modelin ne kadar akıllı olduğuna odaklanıyorlar.

Bu ayrım önemli. Çünkü iki çalışma farklı insanlar, farklı mimariler ve farklı başarı ölçütleri gerektiriyor. Entegrasyon, kendi adıyla anılacak kadar değerli bir iş.

”Yapay zeka ekleyelim” bir proje kapsamı değildir

Bir yöneticinin “Müşteri desteğine yapay zeka eklemeliyiz” dediğini düşünün.

Bu cümle bir yön gösteriyor gibi görünse de işe yarar soruların hiçbirini yanıtlamıyor. Desteğin hangi bölümü değişmeli? Sistem talebi mi anlamalı, ilgili hesap bilgilerini mi bulmalı, sonraki adımı mı önermeli, yanıt mı hazırlamalı, yoksa vakayı tamamen mi çözmeli? Sonucu kim kullanacak? Sistem emin olmadığında ne olacak? Hangi eylem işin tamamlandığını gösterecek?

“Yapay zeka eklemek”, yeteneğin ne işe yarayacağını söylemeden yalnızca adını koyar.

Cümleyi daralttığınızda proje gerçek bir kapsama kavuşur: Abonelik vakalarında temsilcilerin doğru iade politikasını bulmak için harcadığı süreyi azaltmak. Artık ortada bir kullanıcı, karar, bilgi kaynağı ve gözlemlenebilir bir sonuç vardır. Model, talebi anlamaya veya doğru bölümü bulmaya yardımcı olabilir. Ancak projeyi tanımlayan modelin varlığı değil, iş akışında neyin değiştiğidir.

Finans tarafında da aynı sorun görülür. “Faturalarda yapay zeka kullanalım” demek alanları çıkarmak, mükerrer faturaları tespit etmek, satın alma siparişleriyle eşleştirmek, bir anormalliği açıklamak veya hangi vakaların incelenmesi gerektiğine karar vermek anlamına gelebilir. Bunlar farklı ürünlerdir. Farklı verilere ihtiyaç duyar ve farklı biçimlerde hata verirler. Hepsini tek bir teknoloji etiketi altında toplamak, yapılacak işi asıl belirleyen kararları görünmez kılar.

Etiketi kaldırmak projenin iddiasını küçültmez. Tam tersine, bu iddiayı geliştirilebilir bir kapsama dönüştürür.

Bir yetenek, tek başına ürün değildir

Bir model belgeyi özetleyebilir. Ürünün ise hangi belgenin özetleneceğini, belgenin güncel olup olmadığını, onu kimin görebileceğini, nasıl bir özetin işe yarayacağını, özetin nerede gösterileceğini ve okurun ardından ne yapabileceğini bilmesi gerekir.

Bir model talebi tahmin edebilir. Ürün doğru geçmiş veriyi bir araya getirmeli, stok tükenmesiyle ilgi eksikliğini ayırt etmeli, planlama dönemini seçmeli, tahmini satın alma kararından önce ulaştırmalı ve sonuca göre hareket edilip edilmediğini kaydetmelidir.

Bir model destek talebini sınıflandırabilir. Ürün bu sınıflandırmayı doğru müşteriyle ilişkilendirmeli, yönlendirme kurallarını uygulamalı, hizmet taahhütlerine uymalı ve vakayı sorumlusu belli bir kuyruğa yerleştirmelidir.

Yetenek, bir teknolojinin teoride yapabildiği şeydir. Ürün ise bu yeteneğin gerçek bir çalışma ortamının gerekleriyle nasıl buluştuğudur.

Etkileyici bir demo, kimseyi yanıltmayı amaçlamasa bile yanlış izlenim verebilir. Demo, kolayca görülebilmesi için yeteneği diğer her şeyden ayırır. Faydalı bir ürün bunun tersini yapar. Yeteneği bağlam ve kısıtlarla çevreleyerek günlük işlere güvenilir biçimde katılmasını sağlar. Sistem tamamlandıkça model daha az görünür olur.

Her iki şeye de “yapay zeka” demek, belirsizliğin nerede kaldığını görmeyi zorlaştırır. Model dar kapsamlı görevi zaten iyi yapıyorsa bir ay daha model karşılaştırmak pek az katkı sağlayabilir. Yanıt bekleyen asıl sorular kimlik, yetkiler, verinin güncelliği, istisnaların sahibi veya sonraki sistemin hangi çıktıyı beklediğiyle ilgili olabilir. Bunlar entegrasyon sorularıdır. Model daha akıllı olduğunda ortadan kaybolmazlar.

Şirkete özel yapay zeka, şirkete özel model demek değildir

Şirketler farklılaşan bir yapay zeka ürününün herkesten farklı bir modelle başlaması gerektiğini sıkça varsayar. Rakipler de aynı API’yi kullanabiliyorsa bu ürünün şirkete özel yanı nedir?

Onu işletmenin parçası yapan neredeyse her şey.

İki şirket aynı müşteri destek modelini kullanıp birbirinden tamamen farklı ürünler geliştirebilir. İlk şirket çalışanlara ayrı bir sohbet ekranı verir ve müşteri mesajlarını buraya yapıştırmalarını ister. İkincisi sistemi bilgi bankasına bağlar. Yanıt artık daha fazla bilgiye dayanır, ancak çalışan yine hesabı kendisi bulur ve sonucu destek sistemine kopyalar. Üçüncüsü doğrulanmış müşteri, sipariş, abonelik ve politika bilgilerini otomatik olarak bir araya getirir. Öneriyi mevcut vaka ekranında gösterir, sistemin kendi başına yapabileceği işlemlerle onay gerektirenleri ayırır ve sonucu daha sonra incelemek üzere kaydeder.

Kullandıkları temel yetenek aynıdır. Ortaya çıkan ürünler değildir.

Şirkete özel kısım pek çok yerde olabilir: Problemin nasıl parçalara ayrıldığı, hangi bağlamın bir araya getirildiği, kuralların nerede uygulandığı, insanların sonuçla nasıl etkileşime girdiği ve sonuçların nasıl geri bildirime dönüştürüldüğü. Bu kararlar zamanla birikerek rakibin aynı model sağlayıcısında hesap açarak kopyalayamayacağı bir sistem oluşturur.

Bazı problemler gerçekten yeni bir model geliştirmeyi gerektirir. TensorBundle bu problemler üzerinde de çalışıyor. Ancak mevcut bir model ihtiyaç duyulan yeteneği zaten sunuyorsa yeni bir model eğitmek işi ciddiye almanın göstergesi değildir. Asıl ürün çalışmasının nerede olduğunu görmezden gelmek anlamına gelebilir.

En iyi entegrasyon yapay zekayı görünmez kılabilir

Bir ürünün yapay zeka kullandığını göstermenin en kolay yolu ürüne chatbot eklemektir. Kullanıcı boş bir kutu görür, talebini yazar ve üretilen yanıtı alır. Kullanılan teknoloji ortadadır.

İş akışındaki iyileşmeyi görmek ise o kadar kolay olmayabilir.

Bir destek temsilcisinin vakadan çıkması, yapay zeka aracını açması, müşteri mesajını yapıştırması, eksik bağlamı eklemesi, yanıtı kontrol etmesi ve sonucu destek sistemine geri kopyalaması gerekiyorsa şirket yeteneği entegre etmemiş, yalnızca yeni bir arayüz eklemiştir. Sistemler arasındaki bağlantıyı hâlâ çalışan kurar.

Daha derin bir entegrasyon, doğru politikanın vakanın yanında gösterilmesi, mevcut hesap bilgilerine dayanan bir taslak veya işlemin onaylanabileceği ekranda sunulan bir öneri biçiminde görünebilir. Talep planlamasında, alışılmadık bir tahminin satın alma için son tarihten önce öne çıkarılması olabilir. Belge işlemede ise belirsiz üç alan incelemeye yönlendirilirken geri kalan verilerin normal biçimde ilerlemesi olabilir.

Bu deneyimlerin hiçbirinin kendini parıltı ikonuyla duyurması gerekmez. Kullanıcı sistemin ne önerdiğini, bu önerinin hangi kanıta dayandığını ve kontrolün ne kadarının kendisinde kaldığını anlamalıdır. Sonucun üretilmesinde bir modelin rol aldığını sürekli hatırlamasına gerek yoktur.

Ürün ekipleri için yararlı soru şudur: Yapay zeka özelliğini nasıl görünür kılarız diye sormak yerine, kullanıcının yolundaki gereksiz işlerin ne kadarını kaldırabiliriz? En olgun sonuç, gidilecek ayrı bir yapay zeka ekranından çok kullanıcının ne yapmak istediğini sonunda anlayan mevcut ürüne benzeyebilir.

Model, sistemin en kolay değiştirilen parçası olmalı

Yapay zeka ürünleri ilk aşamada model seçimini çoğu zaman kalıcı bir kimlik gibi ele alır. Ürünlerini belirli bir sağlayıcı veya model ailesi tarafından destekleniyor diye tanımlar, ardından bu tercihin promptlara, veri yapılarına, uygulama mantığına ve kullanıcı arayüzlerine yayılmasına izin verirler.

Oysa modeller, içinde kullanıldıkları işletmeden daha hızlı değişecektir. Sağlayıcılar yeni sürümler çıkarır, eskilerini kullanımdan kaldırır, fiyatları değiştirir ve farklı yetenekleri farklı hızlarda geliştirir. Şirket ayrıca maliyet için daha küçük, gizlilik için yerel veya iş akışının bir bölümü için uzmanlaşmış bir modele ihtiyaç duyabilir.

Müşteri kaydı, onay politikası, vaka geçmişi ve tamamlanmış bir iadenin tanımı bunlarla birlikte değişmek zorunda kalmamalıdır.

İyi entegre edilmiş bir ürün, modele sınırları belli bir rol verir. Bağlam, istek modele ulaşmadan hazırlanır. Modelin çıktısı tanımlanmış bir sözleşmeye uymalıdır. İş kuralları, yetkiler ve önemli sonuçlar doğuran eylemler çevredeki sistemde kalır. Değerlendirme vakaları tek bir sağlayıcının özelliklerini değil, ürünün ihtiyaç duyduğu davranışı tanımlar. Modeli değiştirmek yine emek ister, ancak iş sürecinin ne olduğunu baştan keşfetmeyi gerektirmez.

İlk API çağrısı başarıyla tamamlandığında entegrasyon bitmiş olmaz. Veri şemaları, yetkiler ve iş kuralları değişir. Kullanıcılar aracı kullanmanın yeni yollarını bulur. Entegrasyon, içindeki yetenek gelişirken veya değiştirilirken tüm bu değişiklikleri taşıyan uzun ömürlü üründür.

Model sistemden çıkarılması en zor bileşense ürünün kontrolü yeterince şirkette olmayabilir.

İşin adını doğru koymak, onu kimin yapması gerektiğini de değiştirir

Kullanılan dil, mimariden önce projeyi biçimlendirir.

Bir çalışmaya yapay zeka projesi dendiğinde ilk sorular genellikle modellerle ilgilidir: Hangi sağlayıcı, hangi benchmark (karşılaştırmalı test), hangi prompt, hangi uzman? Bunlar geçerli sorular olabilir. Ancak şirket mevcut bir yeteneği entegre ediyorsa zor iş başka bir yerde duruyor olabilir.

Birinin iş sürecini neyin değişmesi gerektiğine karar verecek kadar iyi anlaması gerekir. Birinin erişim sınırlarını görmezden gelmeden ilgili verileri kullanılabilir hâle getirmesi gerekir. Birinin ürün akışını kurması, bileşenler arasındaki sözleşmeleri tanımlaması, istisnaların nasıl ele alınacağını tasarlaması, sonucun tamamını test etmesi ve lansmandan sonra sorumluluk alması gerekir.

Bu ekip, özellikle model davranışını değerlendirmek ve modelin sınırlarının nerede önemli olduğunu anlamak için makine öğrenmesi uzmanlığına ihtiyaç duyabilir. Ürün, backend, veri, güvenlik ve alan uzmanlığı da gerekir. Daha önemlisi, ekipte bu alanlar arasında çalışabilen insanlar bulunmalıdır. Alanlar arasındaki geçişlerin sorumluluğunu kimse üstlenmiyorsa çok iyi uzmanlardan oluşan bir ekip kendiliğinden entegre bir sistem ortaya çıkarmaz.

İşin adını doğru koymak, başarı tanımını da değiştirir. Yeni bir model yeteneği geliştiren ekip, bir araştırma sonucunu veya benchmark iyileşmesini haklı olarak başarı sayabilir. Mevcut bir yeteneği entegre eden ekip ise ortaya çıkan sistemin yerleştirildiği kararı veya iş akışını iyileştirip iyileştirmediğine bakmalıdır. Vakalar daha hızlı çözüldü mü? Yeniden işlenmesi gereken fatura sayısı azaldı mı? Planlama ekipleri tahmine göre hareket etti mi? Çalışanlar aracın sistemler arasındaki manuel bağlantısına dönüşmeden onu benimsedi mi?

TensorBundle’da bu ayrım, probleme yaklaşımımızı değiştiriyor. Bazen kısıt gerçekten modelin içindedir ve yeni yöntemler geliştirmek gerekir. Çoğu zaman model kendi payına düşeni zaten yapabiliyordur. Asıl zorluk, çevresindeki sistemi kurmaktır. Bu iki durumu aynı kabul etmek, daha proje başlamadan yanlış öneriye götürür.

Bir dahaki sefere biri yapay zeka girişimi önerdiğinde bunun doğru etiket olup olmadığını tartışarak başlamayın. Daha yararlı bir soru sorun: Yeni bir yetenek mi geliştiriyoruz, yoksa mevcut bir yeteneğin burada işe yaramasını mı sağlıyoruz?

Cevap entegrasyonsa bunu açıkça adlandırmak gerekir. Ürün, ekip ve beklentiler de gerçekten yapılan işe göre tasarlanmalıdır.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Probleminize bire bir uyan hazır bir çözüm yok

Mon, 22 Jun 2026 00:00:00 GMT

Kanıtlanmış hiçbir yapay zeka yöntemi doğrudan sizin veriniz, iş akışınız ve kısıtlarınız için geliştirilmedi.

Başka bir yerde kanıtlanmış yöntemler yine de işe yarayabilir. Bu nedenle her şeye sıfırdan başlamak veya yerleşik çalışmaları göz ardı etmek gerekmez. Sorun, bu yöntemleri destekleyen kanıtın genellikle başkasının verisine, iş akışına, kısıtlarına ve hata maliyetine dayanmasıdır.

Bu yüzden sorulması gereken rahatsız edici soru “bu yöntem çalışıyor mu?” değildir. Muhtemelen bir yerde çalışıyordur. Daha iyi soru şudur: Tam olarak hangi koşullarda çalıştığı kanıtlandı ve bu kanıtın ne kadarı sizin koşullarınızda hâlâ geçerli?

Ekipler burada “yeni” sözcüğüne aldanır. Bu sözcük, yalnızca araştırmanın sınırındaki ve daha önce hiç kimsenin çözemediği problemler için kullanılır. Geri kalan her şey “çözülmüş” sayılır. Çözülmüş problemler de yalnızca uygulama işi gibi görünür. Oysa genel anlamda çözülmüş bir problem, daha önce kimsenin ele almadığı koşullarla karşılaştığı anda sizin için yeni olabilir.

Problem bu anlamda yeniyse deneme yanılma kaçınılmazdır. Ne denemeniz gerektiğini sırayla anlatan hazır bir yol haritası yoktur. Ancak teori ve alan bilgisi olmadan yürütülen deneme yanılma, daha düzenli bir proje planına yerleştirilmiş kör aramadan ibarettir. Teori ve alan bilgisi, bir denemeyi yalnızca tekrarlanabilecek bir tahmin olmaktan çıkarıp bir şey öğrenebileceğiniz bir hipoteze dönüştürür.

Yeni bir problem hazır yol haritasıyla gelmez

Deney yapmaya ilişkin standart anlatı, süreci basit bir prosedür gibi gösterir: Bir tahmin kur, sına, düzelt ve tekrarla. Bu anlatı, önce gelen ve çok daha zor olan adımı atlar: Neyin tahmin edilmeye değer olduğuna karar vermek. Yeni bir üretim hattı için kusur tespit sistemi geliştiren ekip, eşit derecede makul fikirlerin bulunduğu boş bir sayfayla başlamaz. Yönetilmesi imkansız bir seçenek uzayıyla başlar. Aydınlatma koşulları, kamera açısı, hat hızı, kullanılan hammadde, sensör konumu ve etkili olabilecek onlarca değişken vardır. Üretim hattı devreye girmeden önce hepsini sınamak mümkün değildir.

Teori ilk işini burada yapar ve bu iş çoğu kişinin ona atfettiği şey değildir. Teori doğru yanıtı önceden bilmenizi sağlamaz. Problem hakkında sağlam bir model, henüz tek bir deneme yapmadan hangi değişkenlerin belirleyici olamayacağını elemenizi sağlar. Alan bilgisi, değişkenlerden hangilerinin bu kusur türü için fiziksel olarak mümkün olduğunu gösterir. Teori ise mümkün görünen değişkenlerden hangilerinin yakalamaya çalıştığınız hatayla mekanik bir ilişkisi olduğunu söyler. İkisi birlikte yönetilemez bir seçenek uzayını, gerçekten sınanmaya değer kısa bir listeye indirir.

Bu adım olmadan bir deneme aslında deneme değildir. Yalnızca sınanabilir bir tahmindir. Başarısız olduğunda size ne öğrettiği bakımından sıradaki tahminden ayırt edilemez. Gerçekten yeni bir problem, yararlı bir girişimin neye benzediğini anlatan hazır bir yol haritası sunmaz. Ekip bu yolu teori ve alan bilgisiyle çizer.

Bir deneme gerçekte neyi kanıtlar?

İlk denemenin işe yaradığını düşünün. Kusur oranı düşer, metrik iyileşir, gösterge paneli yeşile döner. Genellikle kutlama burada başlar ve bir sonraki soru atlanır: Başka bir üretim hattına veya vardiyaya geçildiğinde ya da farklı bir hammadde kullanıldığında aynı sonuç alınır mı? Çoğu ekip bunu bilmez, çünkü tek bir başarılı deneme kendi başına bu sorunun cevabını vermez.

Alan bilgisi başlangıçta nereye bakmanız gerektiğini daraltır. Teori ise bulduğunuz sonucun sınadığınız koşulların dışında geçerli olup olmayacağını gösteren ayrı bir araçtır. Arkasındaki mekanizmayı anladığınız için çalışan bir sonuç başka koşullara taşınabilir. Tek bir test çalışmasına özgü rastlantısal bir unsur nedeniyle çalışan sonuç ise taşınamaz. Belirli bir hammadde, aydınlatma düzeni veya hafta sonucu etkilemiş olabilir. Dışarıdan bakarak aradaki farkı anlayamazsınız. Metrik iki durumda da aynı görünür. Elinizdekinin hangisi olduğunu yalnızca sonucun neden işe yaradığını anlayarak ayırt edebilirsiniz.

Bu fark proje sırasında görünmez. Daha sonra, sistem ilk testin hiç kapsamadığı bir koşulla karşılaştığında sessizce ortaya çıkar. Bir bölgenin başvuru örüntülerine göre ayarlanmış sigorta talebi işleme modeli, pilot çeyrekte kusursuz çalışır. Farklı bir bölgenin evrak düzeniyle karşılaştığı anda öngörülemez biçimde bozulmaya başlar. Kimse bozulmanın tam olarak ne zaman başladığını söyleyemez, çünkü ilk başarının hangi koşula bağlı olduğunu en başta kimse bilmiyordur.

Bir sonucun neden geçerli olduğunu anlayan ekip her denemeden birikerek büyüyen bir kazanımla çıkar: Mekanizmaya dair biraz daha net bir model. Bu model, hammadde, üretim hattı veya bölge değiştiğinde de kullanılabilir. Nedenini anlamayan ekip ise yalnızca bir kez işe yaramış, koşulları kaydedilmemiş bir reçeteyle kalır. Bu koşullardan biri değiştiğinde çözümü baştan keşfetmesi gerekir.

On denemenin sonunda neden yalnızca bir ekip ilerler?

Birikim ile tekrar arasındaki fark budur. Ekiplerin geçmiş denemelerini anlatma biçiminde açıkça görülür. Teoriyle ilerleyen ekip geçmişini bir sıra hâlinde anlatır: Önce sorunun sensör açısından kaynaklandığını düşündük. Bunun bir kısmını açıkladığını, ancak tamamını açıklamadığını görünce kullanılan hammaddedeki değişime yöneldik ve bunu doğruladık. Her cümle bir öncekine dayanır. Bu temelden yoksun ekip ise geçmişini liste olarak anlatır: Eşiği değiştirdik, işe yaramadı. Daha fazla veriyle yeniden eğittik, biraz yardımcı oldu. Başka bir sağlayıcının modelini denedik, daha çok yardımcı olmuş gibi göründü. Cümleler birbirinden bağımsızdır. Önceki denemenin işe yaramaması dışında, listedeki bir sonraki şeyin neden denendiğini açıklayan hiçbir bağ yoktur.

İkinci ekip tembel veya özensiz değildir. Ellerindeki tek yöntemle çalışırlar. Nedensel bir model olmadığında kısmi başarının yanında bulunan rastlantısal etkenlerden hangisinin gerçekten işe yaradığını anlamak mümkün değildir. Her yeni girişim baştan başlamak zorunda kalır, çünkü önceki girişim yeniden kullanılabilecek bir şey öğretmemiştir. Bir düzeltmeyi üretime alabilirler. Ama genellikle neden işe yaradığını söyleyemezler. Bu nedenle ne zaman çalışmayı bırakacağını da bilemezler.

Yenilik yalnızca daha önce çözülmemiş olmak değildir

Önceki üç bölüm, çoğu zaman doğrudan araştırmanın sınırındaki problemlerle ilişkilendirilen bir mekanizmayı anlatıyor: Dünyanın hiçbir yerinde henüz çalışan bir cevabı bulunmayan problem. Bu ilişki yanlış değildir, yalnızca fazla dardır. Yenilik, problemin araştırma sınırının ne kadar ilerisinde olduğuyla sınırlı değildir. Bağlama da bağlıdır.

Sahtecilik skorlama yaklaşımı iyice yerleşmiş, sektörün tamamında başarıyla kullanılmış olabilir. Yine de bir şirketin kendine özgü işlem örüntüleri, müşteri profili ve iç inceleme süreciyle ilk kez karşılaştığında işlevsel olarak yenidir. Çünkü yerleşik yaklaşım bu koşullarda değil, başka koşullarda kanıtlanmıştır. Yöntem yeni değildir. Bu vakaya uyumu yenidir.

Bir şirket için çözmeye en çok değen problemlerin çoğu tam olarak sol üst bölümde yer alır: Alan genelinde çözülmüş olsalar bile bu koşullar altında henüz çözülmemişlerdir. Bu tesadüf değildir. Bir kullanım alanını şirket için değerli kılan özgüllük, yani belirli müşteriler, iş akışı ve karar geçmişi, genel amaçlı hiçbir cevabın o vakayı tam olarak kapsayamayacağı anlamına da gelir. Problem, başkasının çözümünün doğrudan aktarılabileceği kadar genel olsaydı onu çözmek büyük ihtimalle bu kadar değerli olmazdı.

Aslında kimin kanıtına dayanıyorsunuz?

“Sektör standardı bu” iş dünyasının en güven veren ve en az sorgulanan cümlelerinden biridir. Güven verir, çünkü kanıta dayanıyormuş gibi görünür. Nadiren sorgulanır, çünkü bu kanıtın gerçekte neyi gösterdiğini sormak herkesin çoktan sorgulamayı bıraktığı bir kararı yeniden açmak gibi hissettirir.

Oysa gösterdiği şey göründüğünden daha dardır: Bu yaklaşım başka birinin koşullarında, verisinde ve kısıtları içinde işe yaradı. Bu gerçek ve yararlı bir bilgidir. Ancak “burada da işe yarayacak” demek değildir. Genel olarak kanıtlanmış bir yöntem ile sizin koşullarınızda kanıtlanmış bir yöntem arasındaki farkı kapatmak için, daha önce çözülmemiş bir problemi sıfırdan ele alırken gereken teori ve alan bilgisi birlikteliğine yeniden ihtiyaç vardır. Aradaki fark şudur: İşaret edebileceğiniz rahatlatıcı bir genel cevap bulunduğu için bu çalışma isteğe bağlı görünür. Genel ile özgül arasındaki fark bir şeylerin bozulmasına yol açana kadar.

Hiç kapanmayan fark

Gerçekten çözülmemiş bir araştırma probleminin doğal bir bitiş noktası vardır. Eninde sonunda biri problemi çözer, alan bu bilgiyi benimser ve bilinmeyen alan daralır. Bağlama özgü yenilik aynı şekilde davranmaz. Bir şirketin verisi, iş akışı ve kısıtları, tek seferde ve kalıcı biçimde çözülecek kadar uzun süre aynı kalmaz. Yeni müşteriler, düzenlemeler, ürün grupları ve iç süreçlerle değişmeye devam eder. Bu nedenle “genel bir çözüm” ile “bizim koşullarımız” arasındaki fark ilk başarılı uygulamadan sonra kapanmaz. Şirket, ilk çözümün hesaba katmadığı bir yönde her değiştiğinde sessizce yeniden açılır.

Bu durum, bağlama özgü yeniliği sıradan araştırma yeniliğinden daha kolay değil, daha zor aşılır hâle getirir. Şirketin bu çalışmayı bir kez yapıp tamamlayabileceği bir senaryo yoktur. Teoriyle yönlendirilen deneme yanılma ve ekibin gerçek alan bilgisi, ilk proje başarıya ulaştıktan sonra önemini kaybetmez. Şirket kendine özgü ve sürekli değişen bir yapı olarak kaldığı sürece bu ihtiyaç devam eder. Yani süresiz olarak.

Bu düşüncenin dürüst hâli rahatlatıcı değildir, zaten öyle olması da amaçlanmıyor. Ancak bugün “bu işe yarar” diye kabul ettiğiniz varsayımlardan hangilerinin nedenini bildiğiniz için sağlam olduğunu, hangilerinin ise sessizce başkasının kanıtına dayandığını erkenden görmenizi sağlar. İlk tür koşullar değiştiğinde ayakta kalır. İkinci tür ise sorun çoktan ortaya çıkana kadar başarısız olduğunu belli etmez.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Kağıt üzerinde kusursuz, pratikte sorunlu

Mon, 15 Jun 2026 00:00:00 GMT

Bir yapay zeka değerlendirmesi, genellikle insanların daha sonra o skora yüklediği anlamdan daha dar bir soruyu yanıtlar. Bir müşteri destek asistanı için soru çoğu zaman basittir: Yanıt, beklenen cevapla eşleşti mi? Operasyonel soru ise daha karmaşıktır. Müşteri problemini çözebildi mi? Öfkeli bir şekilde geri döndü mü? Bu yanıt daha sonra insan ekibe ek iş çıkardı mı?

Bunlar farklı sorulardır. Destek asistanı sık karşılaşılan parola sıfırlama sorularını iyi yanıtlayabilir, ama en çok uzman müdahalesi gerektiren karmaşık hesap problemlerinde başarısız olabilir. Değerlendirme bu iki hatayı aynı sayıyorsa aslında bunu açıkça söylemeden bir ürün kararı vermiştir.

Doğru bir değerlendirme bu şekilde yanıltıcı hâle gelir. Test, kendisine sorulan soruyu doğru yanıtlar. Sonra elde edilen skor üretime hazır olma, iş riski, müşteri etkisi veya operasyonel yük gibi çok daha geniş konularda kanıt olarak kullanılmaya başlanır.

Sorun ölçüm yapmak değildir. Sorun, her metriğin “iyi”yi kendi başına tanımladığını ve bu tanımın desteklemesi beklenen karardan çok daha dar olabileceğini unutmaktır.

Ölçmesi kolay olan, çoğu zaman önemli olan değildir

Her değerlendirme, ekibin asıl yanıtlaması gereken sorudan daha kolay bir soruyu yanıtlar. Bu, ekibin özensiz davrandığı anlamına gelmez. Ucuz soru yerel ve anlıktır: Bu örnekteki çıktı, referans yanıtla eşleşti mi? Zor soru ise daha sonra ortaya çıkar: Bu yanıt problemi çözdü mü, müşteriyi kaybetmeye yaklaştırdı mı, hatalar en fazla zarar verecek vakalarda mı yoğunlaştı?

Bu sorular aynı şeyi ölçmez. Ekip aynı değerlendirmeyi daha dikkatli çalıştırdığında aradaki fark kapanmaz. Fark, biri bu soruların birbirinin yerine kullanıldığını fark ettiğinde ve testin ne iddia edebileceğine sınır koyduğunda kapanır.

Destek asistanı örneğinde de olan budur. Yüzde 98 uydurma bir sonuç değildi. Yanlış soruya verilen dürüst bir yanıttı.

Neyi ölçeceğinize karar vermek, “iyi”nin ne olduğunu belirlemektir

Metrik, sistemi tarafsızca ölçen bir araç değildir. Başarının ne sayılacağını önceden sabitleyen bir tanımdır. O anda bir tercih gibi görünmese bile bu tanımı birileri seçmiştir.

“Yüzde 98 doğruluk” model hakkında nesnel bir gerçek gibi görünür. Ancak daha önce verilmiş bir karara dayanır: Değerlendirme veri kümesindeki her destek vakası eşit sayılır ve hangi iki vakanın yanlış yanıtlandığından bağımsız olarak yüz vakanın doksan sekizini doğru yanıtlamak “iyi” kabul edilir. Kimse oturup “kafası karışmış kurumsal bir müşteriyi yanlış yönlendirmekle rutin bir sık sorulan soruya biraz özensiz cevap vermeyi aynı sayıyoruz” dememiştir. Yine de değerlendirme her vakayı birbirinin yerine geçebilir kabul ederek bu takası yapmıştır.

Herhangi bir skor hesaplamadan önce “bir hata bize neye mal olur ve bu maliyet vakaya göre değişir mi?” diye soran ekip, farklı bir değerlendirme kurar. Aynı değerlendirmenin daha düzenli bir sürümünü değil, gerçekten farklı bir değerlendirmeyi.

Sistemi kuranların kör noktası

Bu ayrımın gözden kaçmasının bir nedeni daha vardır. Neyin “iyi” sayılacağına karar veren kişiler sistemi de kurduysa değerlendirme, sistemi sınamak yerine alınmış kararları doğrulamaya başlayabilir.

Bu dürüstlük sorunu değildir. Daha çok bir kör noktadır. İçerik moderasyonu için sınıflandırıcı geliştiren bir ekip, yüzlerce küçük uygulama kararı boyunca bir “hata”nın nasıl göründüğüne dair çalışma alışkanlığı edinir. Bu anlayış zamanla daralıp sistemin zaten iyi yönettiği vakalarla örtüşebilir. Kimse hatayı özellikle dar tanımlamaya çalışmaz. Ekip yalnızca aylar boyunca sisteme, sistemin kendilerine öğrettiği alışkanlıklarla bakar.

Sistemin geliştirildiği odada hiç bulunmamış birinin tasarladığı değerlendirme genellikle farklı bir soru sorar. Her zaman daha akıllıca bir soru değildir. Yalnızca daha az tanıdıktır. Bazen sistemin ihtiyaç duyduğu şey de tam olarak budur.

Değerlendirme tasarlamak, deney tasarlamaktır

Geçerli bir değerlendirme tasarlamak, test paketi yazmaktan çok deney tasarlamaya benzer. Birçok mühendislik ekibi bunun için eğitim almamıştır, çünkü bu yalnızca bir mühendislik becerisi değildir.

Gerçek bir deney, sonucun anlamlı olabilmesi için nelerin doğru olması gerektiğini belirleyerek başlar. Hangi değişkenler sabit tutulacak? Sınanan varsayımın aleyhinde ne kanıt sayılacak? Sonuç geldiğinde hangi iddiaları destekleyebilecek? Örnekleri bir araya getirip başarı oranı hesaplamak bir sayı üretir. Hesabın yapılmış olması o sayıyı anlamlı kılmaz.

Bu nedenle daha fazla test vakası eklemek çoğu zaman problemi çözmez. Daha fazla vaka aynı soruyu daha yüksek hassasiyetle yanıtlar, ama soruyu iyileştirmez. Destek ekibi on kat fazla konuşmayı değerlendirebilir ve aynı dolaylı ölçüt için daha dar bir güven aralığıyla yine yüzde 98 sonucuna ulaşabilirdi.

Bu hatayı önceden görmek deneyim ister

Bu örüntüyü geriye dönüp bakınca anlatmak kolay, önceden görmek zordur. Onu tanımak, daha önce benzerini görmüş olmayı gerektirir. İlk değerlendirmesini tasarlayan bir ekibin elindeki temel veri noktası kendi sistemidir. Bu yüzden her hata biçimini ilk kez üretimde, maliyet ortaya çıktıktan sonra keşfeder.

Bir müşteri destek sistemi “yanıt beklenen cevapla eşleşti mi?” ölçümünde iyi skor alır, ama müşterileri hayal kırıklığı içinde bir yetkiliye başvurmak zorunda bırakır. Bir içerik moderasyonu sınıflandırıcısı precision (kesinlik) hedefine ulaşır, ancak kimsenin test etmeyi düşünmediği bir zarar kategorisini gözden kaçırır. Bir potansiyel müşteri yönlendirme modeli, değerli sınır vakalarını rutin taleplerle aynı kuyruğa yollar. Tek bir şirketin içinde bunlar birbirinden bağımsız sorunlar gibi görünür. Yeterince örnek gördüğünüzde ise aynı birkaç hatanın farklı kılıklara girdiğini fark edersiniz.

Bu işin gerektirdiği yetkinlik tek bir rolde toplanmıyor

Son birkaç noktayı bir araya getirdiğinizde ortaya kolay tanımlanamayan bir rol çıkar. İyi bir değerlendirme için istatistik, ürün muhakemesi ve alan riskinin aynı konuşmada buluşması gerekir. Çoğu kariyer yolu insanları bunlardan yalnızca birinde yetiştirir. Bir mühendis istatistiksel açıdan sağlam bir test kurmayı bilebilir, ama vakaların hangi yüzde ikisinin gözden kaçması hâlinde işin zarar göreceğini bilmeyebilir. Bir ürün yöneticisi hatanın maliyetini çok iyi anlayabilir, ama bunu sınanabilir bir ölçüte dönüştürmekte zorlanabilir. Ölçüm uzmanı güven aralıklarında güçlü olabilir, ancak ürünü ve alanı yeterince tanımayabilir.

Bir alanda güçlü ekipler diğer alanlardaki kör noktaları yine de göremeyebilir. Bu boşluk çoğu zaman üretim onu görünür kılana kadar saklı kalır. Yani düzeltmenin en pahalı olduğu ana kadar.

Bir skora güvenmeden önce sorulması gereken soru

Bu, ölçüme karşı bir argüman değildir. Mesele skor geldikten sonra ne olduğudur. Bir değerlendirmeden çıkan sayı, belirli bir iddia için kanıttır. O iddianın ne olduğunu ve ihtiyaç duyduğunuz iddia olup olmadığını hâlâ bilmeniz gerekir.

Bir sonraki skor tartışmasız gerçek kabul edilmeden önce daha küçük bir soru sorun: Bu sayıya bu kadar güvenebilmemiz için ne anlama gelmesi gerekir ve bu anlama kim karar verdi?

Bu sorunun tek bir doğru cevabı yoktur. Ama her zaman bir cevabı vardır. Çoğu ekip onu hiç sormaz.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Model seçmek aslında bir teori seçmektir

Mon, 08 Jun 2026 00:00:00 GMT

Bir yapay zeka modeli için mimari seçmek sıradan bir teknik karar gibi görünebilir. Piyasada açık ara önde görünen bir model olabilir. Ekipten biri o modeli daha önce kullanmış veya probleme yeterince yakın bir benchmark (karşılaştırmalı test) bulmuş olabilir. Karar verilir ve yola devam edilir.

Seçilen mimari, probleme dair bir teoriyi zaten içinde taşır. Verinin yapısı, görevin gerektirdikleri ve sistemin neyi öğrenebileceği hakkında varsayımlarla gelir. Bu varsayımları ilk bakışta görmek zordur. Daha fazla yatırımla neyin gelişeceğini ve neyin sınıra dayanacağını belirleyen de onlardır.

Çoğu ekip bununla er ya da geç karşılaşır. Performans belli bir noktada takılır ve alışıldık müdahaleler sonuç vermez. Mimari, genellikle sorgulanan son şey olur.

Her mimari, akıl yürütmenin nasıl çalıştığına dair bir teoridir

Her mimari, anlamanın nasıl gerçekleştiğine dair belirli bir görüşe dayanır. Sonraki bütün kararları da bu görüş biçimlendirir. Bu tercih tasarıma sonradan eklenmez, tasarımın içine baştan yerleşmiştir.

Transformer mimarilerini düşünün. Temel varsayımları, bağlamın belirleyici olduğudur. Girdinin her parçası diğer bütün parçalarla ilişkili olabilir ve model hangi bağlantıların önemli olduğunu öğrenir. Örneğin İngilizcedeki “bank” sözcüğünün anlamını çevresindeki kelimeler belirler: Nehir kıyısından mı, bankadan mı söz ediliyor? Transformer mimarileri, girdide birbirinden ne kadar uzakta olursa olsun bu tür ilişkileri çözmek için tasarlanmıştır. Böylece model, girdinin her noktasında bağlamın tamamından yararlanabilir.

CNN’ler farklı bir varsayımla başlar: Yapıyı belirleyen şey yakınlıktır. Birbirine yakın pikseller birbirini sınırlar, uzaktakilerin etkisi ise çoğunlukla daha azdır. Basit ve yerel özellikler giderek büyüyen ölçeklerde birleşir. Kenarlar şekillere, şekiller nesnelere dönüşür ve karmaşık görsel anlam bu şekilde ortaya çıkar. Bu yaklaşım, görüntü verisinin gerçek yapısıyla iyi örtüşür. “Yakınlığın” mekansal bir anlam taşımadığı sahtecilik grafiklerinde ise aynı şey geçerli değildir.

GNN’ler, ilişkilerin bizzat veri olduğu problemler içindir. Burada belirleyici olan node’lar değil, edge’lerdir. Bir sahtecilik ağında tek bir işlemin kendisinden çok, parayı kimin kime gönderdiği, hangi hesapların birlikte kümelendiği ve farklı isimler altında hangi bağlantıların tekrarlandığı önemlidir. GNN, bilgiyi bu bağlantılar boyunca taşır. Anlamın tek tek kayıtlarda değil, grafik üzerinde birikmesini sağlar.

Diffusion modelleri bunların hepsinden farklı çalışır. Çıktıyı sırayla tahmin etmek yerine gürültüyle başlar, bir sinyalin yönlendirmesiyle bu gürültüyü adım adım gidererek hedefe yaklaşır. Üretimi tahmin değil, iyileştirme süreci olarak ele alır. Ortaya çıkan sonuçları görene kadar tuhaf gelebilecek bir yaklaşımdır.

Bunlar yalnızca farklı fiyat-performans dengeleri sunan mühendislik tercihleri değildir. Bir sistem akıl yürütürken hesaplamanın gerçekte ne yaptığı sorusuna verilen farklı yanıtlardır. Her problem bu yanıtlardan birine örtük olarak daha yakındır. Asıl soru, seçilen mimarinin bu yapıyla uyuşup uyuşmadığıdır.

Mimari yalnızca yöntemi değil, varsayımları da belirler

Bir transformer seçmek, daha tek satır eğitim kodu yazılmadan global bağlamın değerli olduğu varsayımını kabul etmek demektir. Girdinin herhangi bir bölümünü anlamak için başka herhangi bir bölümüne dikkat etmek gerekebilir. Dil söz konusu olduğunda bu çoğu zaman doğrudur. Önemli olanın bir nesnenin kenarının düz mü kıvrımlı mı olduğu bir görüntü sınıflandırma probleminde ise gereksiz ve pahalı olabilir.

Bir CNN seçildiğinde mekansal yakınlığın önemli olduğu varsayımı da kabul edilmiş olur. Yakındaki pikseller yapıyı belirler, uzaktaki piksellerin birbirine etkisi daha sınırlıdır. Bu varsayım görsel verinin yapısıyla o kadar iyi örtüşür ki CNN’ler yıllarca bilgisayarlı görü alanına hakim oldu. Aynı nedenle, ne kadar dikkatle ayarlanırsa ayarlansın, ilişkisel bir grafiğe uygulandığında zayıf sonuç verir. Grafikte “yakınlığın” anlamlı bir tanımı yoktur. Temel varsayım geçerli değildir.

Problemle uyuşmayan bir mimarinin yarattığı fark bütünüyle kapatılamaz. Daha iyi promptlar yazmak, fine-tuning (ince ayar) uygulamak ve çevresine yardımcı katmanlar kurmak mümkündür. Ancak bunların hepsi mimarinin doğal yönüne karşı çalışır ve sonunda mimari ağır basar. Çıktılar teknik açıdan makul görünürken yapısal olarak yanlış kalır. Bu yanlışlığı anlatmak zordur, düzeltmek daha da zor.

Bazı sorular bazı mimarilere uymaz

Model belirli bir görev türünde zayıf kalır. Veri iyidir ama sistem yine de çalışmaz. İlk refleks yüzeyde bir çözüm aramaktır: Daha net promptlar, daha fazla örnek. Ya da sorun veriye yüklenir. Bazen neden bunların hiçbiri değildir. Sorunun yapısıyla onu yanıtlaması beklenen mimari birbiriyle uyuşmuyordur.

Her mimari ailesi farklı türde sorulara uygundur. Bazıları sınıflandırma ve bilgi getirme, bazıları üretim, bazıları da grafikler ile ağlardaki yapıyı bulmak için kurulmuştur. Mimari bu soruları yalnızca farklı verimlilik düzeylerinde yanıtlamaz. Hangi soruların kendi yapısına uyduğunu da belirler.

Grafik ilişkilerine dayalı bir problemde transformer, GNN’den yalnızca daha düşük performans göstermez. Problemi çözülebilir hâle getiren ilişkisel yapıdan yararlanamaz. Parametre sayısını artırmak veya promptu sıkılaştırmak bunu değiştirmez. Çünkü iki müdahale de modelin mevcut yapısı içinde kalır.

Bir model aynı görev türünde sürekli başarısız oluyorsa alışıldık açıklamalar yüzeydedir: prompt, veri veya hiperparametreler. Mimarinin bu tür bir soruya baştan uygun olup olmadığı daha temel bir sorudur ve nadiren sorulur.

Tavanı mimari, ona ne kadar yaklaşıldığını diğer kararlar belirler

Aynı veriyle eğitilen iki model, mimarileri farklıysa aynı görevde farklı yetenek tavanlarına ulaşır. Veri, her modelin kendi tavanına ne kadar yaklaşacağını belirler. Tavanın nerede olduğu ise verinin değil mimarinin meselesidir. Ne kadar yatırım yapılırsa yapılsın o tavan yerinden oynamaz.

İyi veriyle eğitilmiş bir model belirli bir görev türünde hâlâ beklenen performansı göstermiyorsa sorun veri olmayabilir. Model sınıfı, bu görev türünde yapabileceklerinin yapısal sınırına dayanmış olabilir.

Bu hatanın pahalı hâli, sınırı erken fark etmemektir. Ekip, ürünün gerçekte ihtiyaç duyduğu şeyi yapamayacak bir mimarinin çevresinde ciddi bir altyapı kurduktan ve uzun süre iyileştirme denedikten sonra sorun ortaya çıkar. O aşamada mimariyi değiştirmek pahalıdır, ilk kararın gerekçesi çoktan unutulmuştur. Sorun ilk sprintte verilen kararda değil, veri kalitesinde, eğitim sürecinde veya model sağlayıcısında aranır.

Bilinçli seçim için üç katmanlı bir çerçeve

Doğru mimari, probleme aynı anda üç katmandan bakıldığında genellikle belirginleşir. Çoğu ekip yalnızca tek katmana göre seçim yapar. Bu da çoğu zaman marka bilinirliği veya başkasına ait bir problemin benchmark sonuçlarıdır. Üç katmanı birlikte değerlendirmek seçenekleri hızla daraltır. Bunun için gereken tek şey, problemin gerçekte ne olduğuna dair dürüst bir konuşmadır.

İlk katman, problemin hesaplama yapısıdır. Problem ikili ilişkilerden mi oluşuyor? Bir cümlede birbirinden uzaktaki kelimelerin birbirini sınırlaması gibi, her öğe başka herhangi bir öğeyle ilişkili olabilir mi? Bu yapı transformer mimarilerine işaret eder. Yapı, görüntüdeki piksellerin konumla tanımlanması gibi mekansal yakınlıktan mı doğuyor? Bu durumda CNN’ler öne çıkar. Anlam tek tek varlıklarda değil, aralarındaki bağlantılarda mı taşınıyor? Sahtecilik ağları, öneri sistemleri ve molekül modelleri gibi problemler GNN’lere işaret eder. Yoksa sıralı tahmin yerine adım adım iyileştirmeyle yüksek kaliteli ve yapılandırılmış bir çıktı mı gerekiyor? Bu da diffusion modellerinin alanıdır. Problemin hesaplama yapısı, tek bir benchmark sonucuna bakmadan önce seçenekleri ciddi ölçüde azaltır.

İkinci katman, sorunun türüdür. Bu, verinin biçiminden farklıdır. Burada inference (çıkarım) sürecinin yapısına bakılır. “Bu nedir?” sorusu encoder tabanlı mimarilere uygundur. “Bundan bir şey üret” sorusu decoder tabanlı transformer mimarilerine, “Bu neye benziyor?” sorusu diffusion modellerine, “Bunların arasındaki ilişki nedir?” sorusu ise GNN’lere işaret eder. Aynı sektördeki iki ekip, verilerine yapısal olarak farklı sorular sorduğu için bambaşka mimarilere ihtiyaç duyabilir. Sorunun türü tek başına bile belirli bir modeli değerlendirmeye başlamadan önce seçeneklerin çoğunu eleyebilir.

Üçüncü katman, alandaki verinin gerçekte nasıl göründüğüdür. Sağlık verisi tek biçimli değildir. Uzun klinik notlar geniş bağlam destekleyen transformer modellerine, yapılandırılmış kayıtlar çoğu zaman klasik yöntemlere veya hibrit mimarilere, tıbbi görüntüler ise CNN’lere işaret eder. Böylece aynı kurumda, çoğu zaman aynı hastayı anlatan üç veri biçimi için üç farklı mimari ailesi gerekir. Finans verisi, zaman serisi hâlindeki işlem akışlarını, tablolardaki risk özelliklerini ve işlemler arasındaki bağlantıları gösteren sahtecilik ağlarını birlikte barındırır. Hukuk alanında karmaşık çapraz referanslara sahip çok uzun belgeler ağırlıktadır. Bu da geniş bağlam için tasarlanmamış transformer mimarilerini zorlar. Üretimde ise sensör akışları ve büyük ölçekte, yüksek hassasiyetli görsel denetim vardır. Sektörün adı, verinin biçiminden daha az şey söyler.

Üç katman aynı yönü gösterdiğinde seçim genellikle açıktır. Farklı yönleri gösterdiklerinde ise bu gerilim dikkate değerdir. Çoğu zaman problem, farklı mimarilere ihtiyaç duyan birden fazla alt problem içeriyordur. Doğru sistem tasarımı her şeyi tek bir modele zorlamak yerine bu ayrımı yansıtır.

Fark edilmeden verilen karar

Çoğu ekip mimarisini bilinçli biçimde seçmekten çok, o dönemde en çok konuşulan seçeneğe doğru sürüklenir. Bugün bu seçenek transformer tabanlı dil modelleridir. Güçlüdürler ve geniş bir problem kümesine iyi uyarlar. Ancak mekansal görsel sınıflandırma, işlem bağlantılarına dayalı sahtecilik tespiti, yapılandırılmış görüntü üretimi veya sıralamanın katı olduğu zaman serisi tahminleri için aynı ölçüde uygun değildirler. Bu problemlerde transformer kullanmak beceriksizlik değildir. Soruyu hiç sormamış olmanın öngörülebilir sonucudur.

Her sistemin bir mimarisi vardır. Tek soru, bu mimarinin seçilmiş mi yoksa varsayılan olarak mı kabul edilmiş olduğudur.

Mimariyi, uygulamaya dair ilk tercihten önce bilinçli biçimde değerlendirmek gerekir. Bu üç katmanı gerçek probleme dürüstçe uygulamak yeterlidir. Bunu yapan ekipler genellikle daha iyi çalışan ve bakımı daha kolay sistemler kurar. Daha iyi bir model buldukları için değil, neyi seçtiklerini anladıkları için.

Bunun için geliştirmeye başlamadan önce doğru soruyu sormak yeterli.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun

Hesap makinesinin işini dâhiye yaptırmayın

Mon, 01 Jun 2026 00:00:00 GMT

Dar ve kuralları belli şirket süreçlerinde büyük dil modeli (LLM) çoğu zaman yanlış araçtır. Yine de elimizin altındaki en güçlü ve esnek araca yönelmek kolaydır. Yeni bir teknoloji ortaya çıktığında yapabileceklerine odaklanır, kısa sürede onu varsayılan tercih hâline getiririz. Problemin gerçekte neye ihtiyaç duyduğunu sormak yerine yeni teknolojinin bu işi nasıl üstlenebileceğini düşünmeye başlarız.

Frontier modeller şiir yazabilir, kod hatalarını bulabilir ve sohbet edebilir. Bu esneklik, onları dar kapsamlı ve yapılandırılmış şirket süreçlerinde de cazip bir varsayılan hâline getiriyor. Oysa genellik ile hassasiyet ters yönlerde ilerler. Neredeyse her işi yapabilmek için kurulmuş bir sistem, belirli bir iş için optimize edilmemiştir.

Dar kapsamlı bir işte büyük ve genel amaçlı bir modeli varsayılan tercih yaptığınızda yalnızca gereksiz yere karmaşık bir sistem kurmazsınız. Ürününüzün ihtiyaç duymadığı yeteneklere para öder, bu yeteneklerin doğurabileceği zararı da üstlenirsiniz.

Şöyle düşünün: Dünyanın en zeki insanlarından biri elbette basit aritmetik işlemler yapabilir. Önüne 10.000 toplama işleminin olduğu bir hesap tablosu koyarsanız sonunda bütün sonuçları verir. Yine de bu iş için bir dâhi tutmazsınız. Dâhinin getirdiği bağlam kurma, yaratıcılık ve soyut düşünme becerilerinin hiçbirine burada ihtiyaç yoktur. Bu işte önemli olan işlem hızı, mutlak tutarlılık ve yüzde sıfır hata oranıdır. İnsan dehasının zorlandığı ölçütler de tam olarak bunlardır. Dâhiye değil, hesap makinesine ihtiyacınız vardır.

TensorBundle’da şunu sık sık görüyoruz: Teknik ekipler ve ürün yöneticileri, sırf genel yapay zeka bugün çok ilgi görüyor diye Nobel ödüllü birine sistemler arasında veri kopyalatıyor.

Önce problemi sınayın

Teknik mimaride karar kılmadan, sağlayıcı bütçesini onaylamadan veya yeni bir ürün akışı tasarlamadan önce kendinize tek bir soru sorun:

Doğru cevabın nasıl görünmesi gerektiğini açıkça yazabiliyor musunuz? Burada kabaca “iyi görünüyor” demekten söz etmiyoruz. Çıktının tam metin biçimini, kabul edilebilir sayı aralığını veya seçilebilecek kategorilerin kesin listesini tanımlayabiliyor musunuz?

Cevap evetse problemin sınırları bellidir. Bu tür problemleri en iyi, sınırları belli araçlar çözer. “Doğru” sonucu açık kurallar, şemalar veya kısıtlarla tanımlayabiliyorsanız bu iş için amaca özel bir araç zaten vardır. Maliyet, hız ve güvenilirlik bakımından büyük ve genel amaçlı bir modeli her seferinde geride bırakır.

Doğru cevabın nasıl görünmesi gerektiğini gerçekten tanımlayamıyorsanız durum farklıdır. Açık uçlu fikir üretimi, yaratıcı metin taslakları veya esnek keşif için bir araç geliştiriyorsanız sınırları baştan çizilmemiş genel bir sisteme ihtiyacınız vardır.

İşe, gündemdeki teknolojinin neler yapabildiğinden değil, operasyonel problemin sınırlarından başlayın.

Sınırları belli ve açık uçlu problemler

Şirket süreçlerinin çoğu kapalı ve öngörülebilir bir alanda gerçekleşir. Gelen bir müşteri destek talebi dört ekipten birine aktarılır, PDF faturadaki toplam tutar çıkarılır veya bir kullanıcı yorumu spam olarak işaretlenir.

Üretken bir modeli böyle kapalı bir probleme zorladığınızda, aracın doğal esnekliğiyle mücadele etmek için ciddi zaman harcarsınız. Felsefe çözümleyebilen bir sistemden basit ve öngörülebilir bir “Evet” ya da “Hayır” alabilmek için devasa system promptlar (sistem talimatları) yazar, katı doğrulama mantığı kurar ve kırılgan ayrıştırma kodları geliştirirsiniz.

Veri çıkarma işini düşünün. Bir faturayı frontier LLM’e verdiğinizde toplam tutarı kusursuz biçimde bulabilir. Ama cevabın sonuna durup dururken “İstediğiniz bilgiler burada!” gibi nazik bir not da ekleyebilir. Çıktı artık yalnızca düz metin veya geçerli JSON olmadığı için sonraki otomatik veri alma süreci bozulur.

Amaca özel bir parser (belge ayrıştırıcı), veri tabanı sorgusu veya küçük bir sınıflandırma modeli nazik olmaya çalışmaz. Tasarlandığı tek işi yapar, yapılandırılmış veriyi döndürür ve durur.

Ölçek büyüdüğünde ortaya çıkan maliyet

Her genel araç prototipte kusursuz görünür. Hızlı bir deneme hazırlayıp birkaç test örneği verirsiniz. Model cevapları doğru üretir. Demo çalışır, paydaşlar etkilenir ve proje onaylanır.

Fakat prototip yalnızca tek bir veri noktasıdır. Üretim, aynı iş akışının gerçek koşullarda günde 50.000 kez çalışmasıdır. Bu ölçekte genel araçlar iki ciddi sorun yaratır: Katlanarak büyüyen altyapı maliyeti ve değişken çıktılar.

Geliştirme sırasında istek başına bir sentin küçük bir kısmı gibi görünen maliyet, milyonlarca otomatik işlemle çarpıldığında bütçede ciddi bir gider kalemine dönüşür.

Değişkenlik de iş açısından bir risktir. Açık uçlu ve yaratıcı bir araçta değişkenliğe yaratıcılık deriz. Bu istenen bir özelliktir. Kurumsal bir data pipeline (veri işleme hattı) içinde ise girdideki önemsiz bir ifade farkı modeli şaşırttığı için sistemin salı günü pazartesiden farklı davranması anlamına gelir.

Öngörülebilirlik ve hata biçimleri

Son derece esnek bir aracın tehlikesi, tamamen yanlışken bile son derece ikna edici görünebilmesidir.

Kural tabanlı bir motor, veri tabanı kısıtı veya klasik ML sınıflandırıcısı hata verdiğinde bunu açıkça belli eder. Boş değer döndürür, anlaşılır bir hata verir veya düşük bir güven puanı gösterir. Nerede bozulduğunu bildiğiniz için temiz hata yönetimi yolları ve otomatik yedek akışlar kurabilirsiniz.

Üretken modeller hata yaptığında çökmez. Halüsinasyon üretir. Kusursuz biçimlendirilmiş, son derece makul, tamamen yanlış bir cevabı son derece kendinden emin biçimde sunabilir. Çıktıyı kontrol eden bir insan varsa bu sorun yönetilebilir. Fakat sonuç doğrudan otomatik backend iş akışlarını besliyorsa akıcı ama yanlış bir cevap, bütün platformdaki veri bütünlüğünü bozabilir. Sınırlarını dürüstçe belli eden bir araç, hiç duraksamadan tahmin yürüten bir araçtan her zaman daha güvenlidir.

Kararların izlenebilirliği

Şirketiniz finans, mevzuat uyumu, hukuk veya sağlık alanında faaliyet gösteriyorsa yalnızca doğru cevaba ihtiyacınız yoktur. Sistemin o karara neden vardığını da kanıtlamanız gerekir.

Otomatik bir işlem sahtecilik şüphesiyle işaretlendiğinde veya bir kullanıcı başvurusu belirli bir uyum sürecine yönlendirildiğinde, “Büyük bulut modelimizin ağırlıkları bu karara yöneldi” demek operasyonel bir başarısızlıktır. Bir kara kutunun iç işleyişi prompttaki küçük ifade değişiklikleriyle ya da model sağlayıcısının duyurmadan yaptığı güncellemelerle değişiyorsa o sistemi denetleyemezsiniz.

Daha basit ve amaca özel araçlar izlenebilir karar yolları üretir. Bir karar ağacını uyum ekipleri için görselleştirebilirsiniz. Kural motorunda işareti hangi kod satırının tetiklediğini tam olarak görebilirsiniz. Amaca özel, yerel bir modeli sabit ve değişmez bir veri kümesi üzerinde sınayarak zaman içinde tutarlı çalışmasını güvence altına alabilirsiniz. Temel iş mantığınızı büyük bir harici API’ye bıraktığınızda, temeli sürekli değişen bir sistem kurarsınız.

Altyapı seçenekleri

Doğru yaklaşımı seçerken önünüzde yalnızca iki seçenek yoktur: büyük bir ticari API kullanmak ya da her şeyi sıfırdan yazmak. Bunların arasında pek çok uygulanabilir seçenek vardır. Burada önemli olan en basit seçenekten başlamak ve yalnızca problemin karmaşıklığı gerçekten gerektirdiğinde daha genel bir araca geçmektir.

Altyapı seçenekleri arasında nereden başlamanız gerektiğini görmek için şu kısa soruları yanıtlayın.

Modayı değil, problemi izleyin

Bunların hiçbiri güçlü ve genel amaçlı modellerin etkileyici olmadığı anlamına gelmiyor. Aksine, etkileyiciler. Birkaç yıl önce yapılamayan pek çok işi mümkün kıldılar. Dağınık fikirleri bir araya getiren, konuşmadaki ince anlamları kavrayan veya yaratıcı içerik taslakları hazırlayan bir ürün geliştiriyorsanız doğru araç olabilirler.

Ama iyi teknik strateji hiçbir zaman mevcut en güçlü aracı kullanmakla ilgili değildi. Önemli olan, iş için en uygun aracı seçmektir.

Ürün tasarımı “Bu problem tam olarak ne gerektiriyor?” yerine “Burada yapay zekayı nasıl kullanırız?” sorusuyla başlarsa şirketler pahalı ve kırılgan üretim süreçleri kurar. En dayanıklı ürünleri en uygun maliyetle geliştiren ekipler, piyasadaki en büyük araca hemen yönelenler değildir. Bir iş akışının ne zaman dâhiye, ne zaman yalnızca hesap makinesine ihtiyaç duyduğunu bilenlerdir.

Yazının etkileşimli sürümünün tamamını tensorbundle.com üzerinden okuyun