Veriniz Yapay Zekâya Hazır mı? Önce Hangi Karar İçin Olduğunu Söyleyin

💡 Özet: Ana Çıkarımlar

• “Şirketimizin verisi yapay zekâya hazır mı?” tek başına fazla geniş bir sorudur. Hazırlık, bütün şirkete verilecek bir not değildir. Belirli bir kararın ihtiyaç duyduğu bilgi ve kanıtın o karar için yeterliliğidir.
• Buradaki veri yalnızca model eğitmek için kullanılan satırlar değildir. Belgeler, güncel işlem kayıtları, iş kuralları, örnekler, erişim yetkileri ve sonucu doğrulayacak kayıtlar aynı kararın farklı girdileridir.
• Eksik veri her zaman “önce büyük bir veri platformu kuralım” sonucuna götürmez. Doğru karar kapsamı daraltmak, belirli bir kaynağı hazırlamak, insan kararını korumak, yalnızca deney yapmak veya projeyi durdurmak olabilir.

AI projesine model seçerek başlamamak gerektiğini daha önce yazmıştım. Önce değiştirmek istediğimiz iş sonucunu, sistemin aksiyon sınırını ve başarıyı hangi kanıtla ölçeceğimizi belirlemeliyiz. AI'ın gerçekten doğru müdahale olup olmadığını da en sade alternatifle aynı iş sonucu üzerinden sınamalıyız.

Bu kararları verdiğimizde henüz model ekranına geçmiyoruz.

Bir satın alma ekibinin tedarikçi tekliflerini daha hızlı değerlendirmek istediğini düşünün. Hedef açık olabilir: Teklifleri karşılaştırmak için harcanan süreyi kısaltmak, sözleşme ve bütçe hatalarını azaltmak, satın alma kararını daha iyi bilgiyle hazırlamak.

Model teklif dosyalarından fiyatı, teslimat süresini ve garanti koşullarını düzgün biçimde çıkarabilir. Yine de sistem doğru bir öneri üretmeye hazır olmayabilir.

Tedarikçilerin güncel onay durumu erişilebilir mi? Kullanılabilir bütçe ve mevcut taahhütler hangi sistemde yaşıyor? “Teslimat riski” herkes için aynı anlama mı geliyor, yoksa deneyimli satın almacıların zihninde mi kalıyor?

Geçmiş tercihler doğru karar örnekleri mi, yoksa artık geçerli olmayan alışkanlıkların kaydı mı? Önerinin iyi olduğunu sınayacak temsilî vakalar var mı?

Bu boşlukları daha güçlü bir model kapatmaz. Problem doğru seçilmiş olsa bile o kararı taşıyacak bilgi zemini yetersiz olabilir.

Pramod Sadalage ve Prem Chandrasekaran'ın Martin Fowler'ın sitesinde yayımlanan Making Your Data Ready for Agentic AI yazısı bu eksik adımı görmemi sağladı. Yazarlar, bir agent'ın deneyimli bir çalışan gibi kurum içindeki örtük anlamı bilemeyeceğini veya şüpheli veriyi kendiliğinden fark edemeyeceğini söylüyor. Veri sözleşmeleri, kalite kontrolleri, ortak tanımlar, erişim sınırları ve izleme gibi mekanizmalar öneriyorlar.

Bu mekanizmalar gerekli olabilir. Fakat onlara karar vermeden önce daha temel bir soruyu yanıtlamalıyız: Değiştirmek istediğimiz iş, doğru kararı verebilmek için hangi bilgiye ihtiyaç duyuyor ve o bilgi bugün gerçekten kullanılabilir mi?

Yani bu soru, AI'ın doğru müdahale olduğuna karar verdikten sonra, veri mimarisini ve modeli seçmeden önce geliyor.

Doğru problem, yanlış hazırlık

Yapay zekâ projelerinde veri tartışması çoğu zaman iki uçtan birine gidiyor.

Bir uçta, “Model zaten çok şey biliyor, veriyi sonra bağlarız” yaklaşımı var. Diğer uçta ise “Önce şirketin bütün verisini temizleyip tek yerde toplayalım” deniyor.

İkisi de model seçimi kadar aceleci olabilir.

İlk yaklaşım, bir iş kararının dayandığı güncel ve kuruma özgü gerçekleri varsayıyor. İkincisi ise hangi kararın hangi bilgiye ihtiyaç duyduğunu belirlemeden büyük bir hazırlık programı başlatıyor.

Bu sorunlar tek bir veri alanında kalmayabilir. Sambasivan ve çalışma arkadaşları bu tür birikmeyi “data cascades” olarak adlandırıyor. Dört kıtadan 53 uygulayıcıyla yaptıkları görüşmelerde, küçük görünen veri sorunlarının sonraki model ve sistem kararlarına nasıl yayıldığını inceliyorlar.

Bu nitel çalışma bütün AI projeleri için bir başarısızlık oranı vermiyor. Daha sınırlı bir noktayı destekliyor: Kaynağı, anlamı veya sahibi belirsiz bırakılan bilgi, sonraki teknik kararlarla kendiliğinden düzelmiyor.

Bu yüzden veri işi, model seçildikten sonra başlayacak teknik bir hazırlık değildir. Model seçimine geçip geçemeyeceğimizi belirleyen iş kararının parçasıdır.

“Verimiz hazır mı?” neden yanlış başlangıç sorusu?

Bir şirketin verisine kendi başına “hazır” ya da “hazır değil” diyemeyiz.

Aynı müşteri kayıtları haftalık satış raporu hazırlamak için yeterli, gerçek zamanlı kredi kararı için yetersiz olabilir. Bir bakım kılavuzu teknik bir soruyu doğrudan yanıtlayabilir fakat güncel stok durumunu söyleyemez. Geçmiş satışlar genel talep tahmininde işe yarayabilir. Ancak stokta bulunmayan ürünlerin kaç satış kaybettirdiğini göstermiyorsa belirli bir planlama kararını yanıltabilir.

Hazırlık ancak bir kullanım bağlamında anlam kazanır:

• Hangi karar veya iş adımı için?
• Karardan kim etkilenecek?
• Bilgi hangi anda geçerli olmalı?
• Eksik veya yanlış olduğunda ne olacak?
• Sistem yalnız açıklama mı yapacak, bir kararı mı etkileyecek, yoksa işlem mi gerçekleştirecek?
• Sonucun yeterli olduğunu hangi örnek veya kayıt gösterecek?

Doğru ölçü “mükemmel veri” değildir. Amaçlanan karar ve hata sonucu için yeterli bilgidir.

Buradaki veri yalnızca eğitim verisi değil

“Veri hazırlığı” denildiğinde akla çoğu zaman tablo temizlemek, eksik alanları doldurmak ve model eğitmek geliyor. Kurumsal bir sistemin bilgi zemini bundan daha geniştir.

Bir karar aynı anda şunlara ihtiyaç duyabilir:

1. Yazılı bilgi: Politika, sözleşme, ürün belgesi veya teknik kılavuz.
2. Güncel işlem durumu: Bakiye, fiyat, stok, sipariş, izin veya onay kaydı.
3. Açık kural ve tanım: Harcama limiti, uygunluk koşulu, “aktif müşteri” veya “gelir” tanımı.
4. Öğrenilecek örnekler: Tahmin, sınıflandırma veya çıkarım için geçmiş gözlemler, etiketler ve geri bildirim.
5. Kimlik ve erişim: Hangi kullanıcının hangi bilgiyi hangi amaçla görebileceği.
6. Kanıt: Modelin görevini, tamamlanan işlemi ve iş sonucunu sınayacak örnekler ile yetkili kayıtlar.

Bunların hepsini tek bir merkezi veri platformunda toplamak gerekmez. Aynı sistem içinde farklı sahipleri ve geçerlilik süreleri olabilir.

Çalışanın kalan izin günü insan kaynakları sisteminden o anda okunmalıdır. İzin devri kuralı onaylı politika belgesinde bulunabilir. İstisnanın nasıl yorumlanacağı insan kaynakları uzmanının sorumluluğunda kalabilir. Çalışanın yalnız kendi kaydını görmesi de bilginin kalitesinden değil, yetkiden kaynaklanan ayrı bir sınırdır.

Bilgi, açık kural ve öğrenilecek örüntü arasındaki ayrım bu nedenle önemli. Önce kararın hangi tür girdilere ihtiyaç duyduğunu ve bunların gerçekten kullanılabilir olup olmadığını görürüz. Ancak sonra yazılı bilginin doğrudan bağlama mı, aramaya mı; güncel durumun API'ye mi, sorguya mı; öğrenilecek ilişkinin istatistiksel bir yönteme mi gitmesi gerektiğini konuşabiliriz.

Model seçmeden önce altı soru

Bir şirketin bütün veri varlığını puanlamak yerine, değiştirmek istediğiniz tek bir karar veya iş adımı için şu soruları cevaplayın:

1. Bu kararın doğru verilebilmesi için tam olarak ne bilinmesi gerekiyor? Belgeyi, güncel alanı, kuralı, örneği ve sonuç kaydını ayrı ayrı yazın.
2. Bu bilginin anlamına ve güncel haline kim sahip? Aynı alan iki ekipte farklı anlama geliyorsa önce model değil, tanım ve sahiplik problemi vardır.
3. Bilgi eksik, eski veya tartışmalı olduğunda karar nasıl değişiyor? Sistem duruyor mu, dar bir cevap mı veriyor, yoksa fark etmeden devam mı ediyor?
4. Bilgi gereken kimlik ve amaçla erişilebilir mi? Verinin var olması, sisteme veya kullanıcıya gösterilebileceği anlamına gelmez.
5. Sonucun çalıştığını hangi temsilî örnek veya dış kayıt gösterecek? Birkaç etkileyici demo, gerçek hata dağılımını veya tamamlanan işi kanıtlamaz.
6. Eksik parçayı hazırlamanın maliyeti ve süresi beklenen değere uyuyor mu? Kaynak sistemi düzeltmek, tanımları sahiplenmek, test seti hazırlamak ve izleme yapmak projenin gerçek maliyetidir.

Bu liste bir puanlama cetveli değil. Her soruya beş üzerinden not verip ortalamasını alamayız. Yetkisiz bir fiyat kaynağı, güncel belgelerin yüksek puanıyla telafi edilemez. Tamamlanan işi gösterecek kayıt yoksa diğer girdilerin güçlü olması sonucu kanıtlamaz.

Bu soruların amacı yeni bir yöntem tanımlamak değil, karar görüşmesinde tasarımı değiştirecek eksiği erkenden görünür kılmak.

Örneğin ürün belgeleri güncel ve temiz olabilir. Fakat sistem kişiye özel fiyatı yetkili kaynaktan okuyamıyorsa teklif vermeye hazır değildir. Geçmiş satış verisi hacimli olabilir. Fakat yeni ürünün hedef kitlesini temsil etmiyorsa tahmin için yeterli değildir. Bir işlem için bütün girdiler hazır olabilir. Fakat tamamlanmayı kanıtlayan kaynak belirlenmemişse sistem sonucu erken bildirebilir.

RAG yazısında gerekli bilginin sisteme hangi yoldan ulaşacağını ele almıştım. Buradaki soru ondan önce geliyor: Bu bilgi yolu kurulabilir ve bu karar için sınanabilir mi? Cevap evetse doğrudan bağlam, arama, RAG veya canlı sorgu seçeneklerini karşılaştırmak anlam kazanır.

Sonuç her zaman “önce veriyi hazırlayın” değildir

Bilgi yetersizliği tespit edildiğinde refleks olarak büyük bir veri programı başlatmak, model seçimine acele etmek kadar sorunlu olabilir.

Karşınıza şu sonuçlardan biri çıkabilir:

• Devam edin: Bilgi ve kanıt zemini, mimari ve mekanizma karşılaştırmasına geçmek için yeterlidir. Bu üretime çıkma onayı değildir.
• Kapsamı daraltın: Belge türünü, kullanıcı grubunu, ürün ailesini, hata sonucunu veya sistemin yetkisini küçültün.
• Önce belirli bir parçayı hazırlayın: Eksik bir tanımı, kaynak bağlantısını, kuralı veya test setini tamamlayın.
• Kararı insanda tutun: Sistem bilgi toplayabilir ve taslak hazırlayabilir. Belirsiz veya sonuç doğuran kararı adı belli bir kişi verir.
• Yalnız deney yapın: Operasyonel kararı etkilemeden, sınırlı örneklerde öğrenin ve veri toplayın.
• Bu yolu durdurun: Hazırlama maliyeti beklenen değeri aşıyorsa veya gerekli kaynak ve yetki kurulamayacaksa AI iddiasından vazgeçin.

“Önce hazırlayın” tek başına bir karar değildir. Hangi belge, tanım, kaynak bağlantısı veya test seti hazırlanacak? Sahibi kim? Ne zaman bitecek? Tamamlandığını ne gösterecek? Hazırlık işe yaramazsa ne yapacağız? Bunları söyleyemiyorsak bir karar vermiş değil, ucu açık bir veri projesi başlatmış oluruz.

Örneğin bir fatura giriş sistemi kurarken şirketin bütün fatura arşivini temizleyip dönüştürmek zorunda değilsiniz. İlk aşamada yalnızca belirli tedarikçilerden gelen ve metni okunabilen PDF faturaları sisteme alabilirsiniz. Taranmış veya düzeni bozuk faturaları ise çalışanlar mevcut yöntemle işlemeye devam eder. Yeni bir ürün için yeterli geçmiş yoksa “kesin talep tahmini” iddiasını bırakıp açık varsayımlarla senaryo planlaması yapabilirsiniz. Tek bir onaylı bakım sayfasından cevap verilecekse RAG, semantik katman veya veri platformu kurmadan doğrudan kaynağı kullanabilirsiniz.

Karmaşıklık ancak adı konmuş bir boşluğu kapatıyorsa anlamlıdır.

Bilginin yeterli olması, yetki vermek değildir

Bir sistemin doğru ve güncel bilgiye erişmesi, o bilgiyle şirket adına karar verebileceği veya işlem yapabileceği anlamına gelmez.

Satın alma sistemi bütün teklifleri doğru karşılaştırabilir. Yine de tedarikçi seçme, bütçeyi onaylama ve sipariş oluşturma yetkileri farklı kişilerde kalabilir. Çalışanın izin bakiyesi doğru okunabilir. Bu, sistemin izin talebini onaylayabileceğini göstermez.

Yapay zekâya ne kadar yetki verilmesi gerektiği ayrı bir tasarım kararıdır. Bilgi yeterliliği hangi girdilerle güvenilir biçimde çalışabileceğimizi söyler. Yetkilendirme ise kimin neyi görebileceğini ve hangi sonucu doğurabileceğini belirler.

Bir test setinde tedarikçi tekliflerini doğru karşılaştırmak, sistemin işletmeye değer kattığını tek başına göstermez. Önce önerinin doğru olup olmadığını test ederiz. Sonra seçilen tedarikçinin veya oluşturulan siparişin satın alma sistemine gerçekten kaydedildiğini kontrol ederiz. En son, teklif değerlendirme süresinin veya hata sayısının zaman içinde değişip değişmediğine bakarız.

Model çıktısının, tamamlanan işin ve işletme sonucunun nasıl ayrı ölçüleceğini bu nedenle ayrı bir yazıda ele aldım.

Model seçimi iki kez ertelenir

Model seçimini ertelemek modeli önemsiz görmek değildir. Doğru model kaliteyi, maliyeti, gecikmeyi ve mümkün olan iş türlerini değiştirebilir.

Seçim iki aşamadan sonra anlamlı hale gelir.

Önce hangi iş sonucunu değiştirmek istediğinizi ve bunun hangi iş adımında ortaya çıktığını belirlersiniz. AI, klasik yazılım, süreç değişikliği veya başka bir müdahale arasından gerçekten gerekli olanı ayırırsınız.

Sonra o iş adımının ihtiyaç duyduğu bilgi ve kanıt yolunun yeterli, erişilebilir ve ekonomik olarak hazırlanabilir olduğunu gösterirsiniz.

Ancak bundan sonra hangi modelin veya başka hangi mekanizmanın bu işi en sade biçimde üstleneceğini karşılaştırmak anlam kazanır.

Şirketin bütün verisine “hazır” ya da “hazır değil” etiketi yapıştırmak kolaydır. Daha yararlı soru şudur:

Bu karar için neyi bilmemiz gerekiyor ve bugün elimizdeki bilgi, bu kararın sonucunu taşıyacak kadar yeterli mi?

Model, bilgi, yetki ve kanıtla ilgili diğer kararları yapay zekâ sistemi tasarlama rehberinde birlikte görebilirsiniz.