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.
Genelden değil, basitten başlayın
En basit seçenekten başlayın. Yalnızca görev daha fazla esneklik gerektirdiğinde ilerleyin.
Kurallar, regex veya şemalar
Deterministik kontroller, yönlendirme, doğrulama, temizleme ve basit veri çıkarma işleri.
Ne zaman kullanmalı?
Doğru cevabı doğrudan yazabiliyorsanız buradan başlayın.
Ne zaman daha genel bir araca geçmeli?
Girdi çeşitliliği kurallarınızı sürekli bozuyorsa.
Maliyet
Neredeyse ücretsiz
Gecikme
Anında
Gizlilik
Veri içeride kalır
İzlenebilirlik
Çok net
Ö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.
Prototip
Beş düzgün örnek. Çıktıyı izleyen biri var.
Girdiler özenle seçilmiş.
Hatalara kolayca mazeret bulunuyor.
Fatura fark edilmeyecek kadar küçük.
Üretim
Beklenmedik bir durum, hata kaydı açılana kadar tekrar tekrar yaşanıyor.
Maliyetler sessizce katlanıyor.
Output drift (çıktı sapması) sonraki sistemlere sızıyor.
Manuel inceleme ortadan kalkıyor.
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.
İş akışınız ne kadar esneklik gerektiriyor?
Model seçmeden önce yapabileceğiniz kısa bir sağlamlık testi.
1/5
Soru 1
Sonraki soru
Junior bir mühendis, kabul edilen çıktıları açıkça yazabilir mi?
Örnekler: Dört destek ekibinden biri, belirli bir aralıktaki sayı veya alanları önceden bilinen bir JSON nesnesi.
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.