@madda · 4 gün önce
Ajana rapor sorgusu yazdırdım, ciro iki katı çıktı: veri işinde yapay zekânın yanılttığı 4 yer
Bir müşterinin satış verisi için aylık rapor panelini hızlandırmak istedim ve SQL sorgularını bir kodlama ajanına yazdırdım. Tablo yapısını verdim, istediğim metrikleri yazdım, sorgular birkaç dakikada geldi ve çalıştı. Panelde ekim cirosu bir önceki aya göre neredeyse iki katına çıkmış görünüyordu. Müşteri çok sevinecekti ama ben pek sevinemedim, çünkü sektörde böyle bir ay olmamıştı. Sorguyu açınca sorun ortaya çıktı ve bu bana veri işinde ajan kullanmayla ilgili birkaç şey öğretti.
İlk ve en klasik hata çoğalan JOIN. Sipariş tablosu sipariş satırları tablosuyla birleştirilmiş, sonra da sipariş başlığındaki toplam tutar toplanmıştı. Her siparişin satır sayısı kadar tekrar eden tutar toplanınca ciro şişti. Sorgu sözdizimi olarak kusursuz, hata vermiyor, sadece yanlış.
İkinci yer iptal ve iadeler. Ajan durum sütununun ne anlama geldiğini bilmiyordu, ben de söylememiştim. İptal edilmiş siparişler ciroya dahil edilmişti.
Üçüncüsü tarih sınırları. Ay sonu filtresi saat bilgisiyle yazılınca son günün siparişlerinin bir kısmı dışarıda kalıyordu. Burada ajan yanlış yapmadı aslında, tarih sütununun saat de içerdiğini söylemediğim için öyle yazdı.
Dördüncüsü NULL değerler. İndirim sütununda boş olan satırlarda net tutar hesabı NULL dönüyordu ve bu satırlar toplamdan sessizce düşüyordu. Yani bir yerde şişen ciro başka bir yerde eksiliyordu, bu da hatayı daha zor fark ettiren bir şeydi.
Şimdi ajanla sorgu yazarken şunları yapıyorum. Tabloların sadece sütun adlarını değil her sütunun anlamını ve özel değerlerini de bağlama yazıyorum. Her yeni sorgu için bilinen bir ayın sonucunu muhasebe kayıtlarıyla karşılaştırıyorum. Toplamları satır sayısıyla birlikte kontrol ediyorum, birleştirme sonrası satır sayısı artıyorsa alarm. Bu kontroller ajanın hızını öldürmüyor, ama raporun güvenilir olmasını sağlıyor.
Kod hatası programı çökertir ve görürsünüz. Veri hatası rapor olarak masaya gelir ve kimse sorgulamaz. Ajanla rapor yazan herkesin bu farkı aklında tutması gerekiyor.
İlk ve en klasik hata çoğalan JOIN. Sipariş tablosu sipariş satırları tablosuyla birleştirilmiş, sonra da sipariş başlığındaki toplam tutar toplanmıştı. Her siparişin satır sayısı kadar tekrar eden tutar toplanınca ciro şişti. Sorgu sözdizimi olarak kusursuz, hata vermiyor, sadece yanlış.
İkinci yer iptal ve iadeler. Ajan durum sütununun ne anlama geldiğini bilmiyordu, ben de söylememiştim. İptal edilmiş siparişler ciroya dahil edilmişti.
Üçüncüsü tarih sınırları. Ay sonu filtresi saat bilgisiyle yazılınca son günün siparişlerinin bir kısmı dışarıda kalıyordu. Burada ajan yanlış yapmadı aslında, tarih sütununun saat de içerdiğini söylemediğim için öyle yazdı.
Dördüncüsü NULL değerler. İndirim sütununda boş olan satırlarda net tutar hesabı NULL dönüyordu ve bu satırlar toplamdan sessizce düşüyordu. Yani bir yerde şişen ciro başka bir yerde eksiliyordu, bu da hatayı daha zor fark ettiren bir şeydi.
Şimdi ajanla sorgu yazarken şunları yapıyorum. Tabloların sadece sütun adlarını değil her sütunun anlamını ve özel değerlerini de bağlama yazıyorum. Her yeni sorgu için bilinen bir ayın sonucunu muhasebe kayıtlarıyla karşılaştırıyorum. Toplamları satır sayısıyla birlikte kontrol ediyorum, birleştirme sonrası satır sayısı artıyorsa alarm. Bu kontroller ajanın hızını öldürmüyor, ama raporun güvenilir olmasını sağlıyor.
Kod hatası programı çökertir ve görürsünüz. Veri hatası rapor olarak masaya gelir ve kimse sorgulamaz. Ajanla rapor yazan herkesin bu farkı aklında tutması gerekiyor.
3 1 yorum
