Bir yapay zeka sohbet robotunu ayarlamak için haftalarca uğraşıyorsunuz. Cevaplar doğru. İlgili taraflar onaylıyor ve sistemi kullanıma sunuyorsunuz. Üç ay sonra, sistem kullanıcıların sorduğu soruların yaklaşık üçte birinde açıkça yanlış cevaplar veriyor. Kimse modeli değiştirmedi ve kimse komut satırlarına dokunmadı. Dünya değişti, fiyatlar değişti, bir politika güncellendi, bir ürünün teknik özellikleri yeni bir sürümle piyasaya sürüldü, ancak altta yatan bilgi deposu bu değişikliklere ayak uyduramadı.
Bu varsayımsal bir durum değil. Şu anda kurumsal yapay zekada en yaygın üretim hatası türlerinden biri ve çoğu veri mühendisliği ekibi, yapay zeka sisteminin verileri nasıl aldığına bakılmaksızın bunu tespit edecek doğru araçlara sahip değil.Arıza gibi görünmeyen arıza Bir yapay zeka uygulaması, verileri bir vektör deposundan, belge dizininden veya bir API çağrısından alıp almadığını umursamaz. Mekanizma ne olursa olsun, standart bir veri alma boru hattında, sunulan bilginin hâlâ doğru olup olmadığını kontrol eden hiçbir şey yoktur. Eski bir fiyatlandırma belgesi, güncel bir belge kadar güvenle alınır; çünkü sistem doğruluğu değil, alaka düzeyini veya kullanılabilirliği değerlendirir. Aynı nedenden ötürü, bir alanı sessizce eksik olan bir kayıt da eksiksiz bir kayıt kadar sorunsuz bir şekilde geçer.
Dolayısıyla bu hata, tasarım gereği görünmez. Güncel olmayan veya eksik veriler, alaka düzeyinde yine de yüksek puan alır ya da veri boru hattının çalışması için oluşturulmuş her kontrolü geçer. Alınan bağlam güvenilir göründüğü için model tam bir güvenle yanıt verir. İzlediğiniz her gösterge paneli yeşil kalır. Sistem çalışıyor gibi görünür. Oysa bu tamamen yanlıştır.
Bunun benzer bir versiyonunun, AI bağlamı dışında, bir fintech boru hattında gerçekleştiğini gördüm. Bir üst akış sistemi, alt akış kullanıcılarına bildirimde bulunmadan bir alanı değiştirdi. Boru hattı hata vermedi; sistem sadece işin tamamlanıp tamamlanmadığını kontrol ettiği için, verilerin hala doğru olup olmadığını kontrol etmediği için hatalı değerleri göstergelere yansıttı. Sorun, ancak bir müşteri tutarsız bir durum fark ettiğinde ortaya çıktı. O zamana kadar hatalı veriler çoktan aşağı akışa ulaşmıştı.
İster güncelliğini yitirmiş bir belge, ister sessizce kaybolmuş bir alan olsun, arızanın şekli aynıdır: Hatanın olmaması, doğruluğun varlığı anlamına gelmez ve uygun doğrulama katmanları oluşturulmadıkça, iş akışındaki hiçbir şey sorunu tespit edemez.Bunun neden bir veri mühendisliği sorunu olduğu: Bu hatayla karşılaşan ekipler, sorunu yanlış teşhis etme eğilimindedir ve bunu genellikle iki kez yaparlar.
Modeli suçlamak: İlk içgüdü, modeli suçlamak, farklı bir LLM denemek ve komut satırını ayarlamaktır. Asıl sorun, daha yukarıda, veri mühendisliği katmanında yatmaktadır; bu, yukarıdaki fintech başarısızlığının ardındaki içgüdüyle aynıdır: izleme, veriler için değil, iş akışı için oluşturulmuştur.
Geri getirme katmanını suçlamak: Model ihtimal dışı bırakıldığında, bir sonraki içgüdü, bunun yerine geri getirme veya bağlam katmanını suçlamak ve daha iyisini satın almaktır. Zamanlama bir tesadüf değildir: İşletmeler bu sistemleri gerçek üretim ortamına geçirirken, ortaya çıkmaya başlayan tam da bu boşluktur ve satıcıların tepkisi her yerde görülmektedir. AWS, ajan kullanımından öğrenen bir bilgi grafiği ile “bağlam katmanı” yarışına yeni girmiştir. Snowflake’in yeni Horizon Context ve Cortex Sense çözümleri, bu yazının başında değinilen sorunun tam da belirtisini hedefliyor: Altta yatan iş mantığını düzenleyen hiçbir şey olmadığı için, ajansların kendinden emin bir şekilde yanlış yanıtlar vermesi. Her ikisi de gerçek bir soruna yönelik gerçek çözümler, ancak sorunun bir katman üstünde yer alıyorlar; bir bilgi grafiği yine de kendisine beslenen verilere bağlıdır.
Asıl sorun, daha yukarıda, veri mühendisliği katmanında yatıyor. Ekipler, bir işin çalışıp çalışmadığını kontrol eder, taşınan verilerin hâlâ doğru olup olmadığını değil; bu, yapay zekadan yıllar öncesine dayanan bir içgüdüdür. İzleme, veriler için değil, iş akışı için tasarlanmıştır. Aslında eksik olan şey: Veri gözlemlenebilirliği. Veri gözlemlenebilirliği, nasıl uygulandığı konusunda yeterince ilgi görmeyen, iyi bilinen bir kavramdır. İlgili metrik bir yüzde değildir — kapsama alanıdır: kritik veri kümelerinin ne kadarının, sadece birinin kafasında var olan değil, gerçekten sorgulanabilir bir köken bilgisine sahip olduğu.
Uber, geri alma ile güçlendirilmiş üretim kavramı ortaya çıkmadan çok önce özel bir veri kalitesi ve gözlemlenebilirlik platformu kurdu. Şirketin Unified Data Quality platformu, 2.000'den fazla kritik veri setini destekliyor ve veri kalitesi olaylarının yaklaşık %90'ını, bu olaylar aşağı akıştaki tüketicilere ulaşmadan tespit ediyor.
Netflix ise aynı sorunun farklı bir yönünü çözdü; şirket çapında bir veri soy ağacı sistemi kurarak, herkesin bir veri setinin nereden geldiğini ve bu süreçte hangi unsurlarla etkileşime girdiğini yanıtlayabilmesini sağladı. Bu sistem, Kafka konuları, makine öğrenimi modelleri ve denemeler arasındaki bağımlılıkları haritalandırır, j
