CSV dosyasını yapay zekâya vermeden önce tarihleri ve sayıları kontrol edin.

Doğru hesap, yanlış okunmuş veriyi kurtarmaz

Bir CSV dosyasından aylık toplam istediğinizde model kusursuz bir tablo oluşturabilir. Fakat 03/04 tarihini farklı yorumladıysa kayıt yanlış aya gitmiştir. 0017 kodunu 17’ye çevirdiyse başka bir sistemle eşleştirme bozulabilir. Buradaki sorun hesaplamanın son adımında değildir; metnin hangi anlama geldiğine karar verilirken başlamıştır. Sonuç tablosunu incelemeden önce girdi tablosunun nasıl okunduğunu kontrol edin.

CSV, değerlerin nasıl ayrıldığını taşır; her sütunun iş anlamını tek başına garanti etmez. Kayıt kodu, gün/ay sırası, para birimi ve eksik değerin anlamı için ayrıca bilgi gerekir. Bir sütunda rakamların bulunması, o sütunun üzerinde toplama yapılabileceğini göstermez. AI’dan analiz istemeden önce küçük bir veri sözleşmesi hazırlamak bu belirsizlikleri görünür kılar.

Microsoft’un Power Query belgesi, metin kaynaklarında otomatik tür algılamayı ve bölgesel ayarın dönüşüm üzerindeki etkisini açıklar. Aynı metin farklı bölgesel kurallarla farklı yorumlanabilir veya hata verebilir. Bu nedenle otomatik algılamayı doğruluk kanıtı saymayın; seçtiğiniz veri türünü ve kaynak biçimini birlikte denetleyin.Kaynak: Microsoft Learn — Data types in Power Query

Beş satırlık dosyanın anlamı henüz kesin değil

TR burada gün/ay/yıl ve ondalık virgül; US ay/gün/yıl ve ondalık nokta anlamına geliyor. Bunlar kişilerin ülkesi değil, dosyayı üreten sistemin bildirdiği biçimlerdir. Bütün tutarların TL olduğu ayrıca verilmiştir. Yalnızca sayı görünümünden para birimi çıkarılmaz. Örneğin ikinci satırdaki biçimin US olması tutarın dolar olduğu anlamına gelmez.

Özgün dosyayı değişmeden saklayın ve çalışma kopyasında ham sütunlarla dönüştürülmüş sütunları yan yana tutun. İlk iki kodun başındaki sıfırları korumak için kod alanını metin olarak tanımlayın. Sıfırlar önceki bir işlemde kaybolmuşsa sonradan hücreye metin biçimi vermek onları geri getirmez; güvenilir ham kaynağa dönmeniz gerekir.

Modelden düzeltme değil, açık dönüşüm kuralı isteyin

• Kod: Kimliktir, metin olarak korunur; bu örnekte dört karakterlidir.
• Tarih: Bildirilmiş bölgesel kuralla yorumlanır; sonuç YYYY-AA-GG biçiminde gösterilir. Takvimde olmayan tarihler reddedilir.
• Tutar: Kaynak biçimine göre sayıya dönüştürülür; para birimi ayrı bilgidir. Boş alan sıfıra çevrilmez.
• Belirsizlik: Bilinmeyen biçimli satır tahmin edilmez. Tarihli toplam için gerekli alanı eksik satır istisna listesinde tutulur.

Bağlam: Tarihe göre tutar analizi hazırlıyorum; henüz toplam veya eğilim yorumu istemiyorum.
Girdi: [beş ham satır] ve [dönüşüm sözleşmesi].
Görev: Ham alanları değiştirmeden yorumlanabilir satırları ayır. Her sorunlu satır için alanı, nedeni ve kaynaktan istenecek bilgiyi yaz.
Kısıtlar: Kodlardaki sıfırları silme. Bilinmeyen yerel biçimi çoğunluğa bakarak seçme. Boşu sıfır yapma, geçersiz tarihi yakın güne taşıma.
Çıktı: Doğrulanabilir kayıtlar ve istisnalar olarak iki tablo.
Kontrol: Girdi satır sayısı, iki çıktı tablosunun toplam satır sayısına eşit kalmalı; her kod bir kez görünmeli.

Bu promptu kullanmak, dönüşümün gerçekten yapıldığına dair kanıt değildir. Kullanılan aracın tablo işleme adımlarını veya oluşturduğu dosyayı inceleyin. Yalnızca sohbet yanıtı varsa, beklenen sonuçla satır satır karşılaştırın. Büyük dosyalarda aynı kuralları Excel/Power Query gibi tekrar çalıştırılabilen bir işlemde uygulamak, elle düzeltilmiş bir sonuç tablosundan daha kolay denetlenebilir.

Kısmi sonucu bütün dosyanın toplamı diye sunmayın

Girdi: 5 satır. Doğrulanmış: 2. İstisna: 3.
2 + 3 = 5; kayıp veya çoğaltılmış satır yok.
Doğrulanmış alt küme toplamı: 1.250,50 + 2.500,75 = 3.751,25 TL.
Bu değer bütün dosyanın toplamı değildir. Üç istisna çözülmeden tam tarihli toplam raporlanamaz.

Dördüncü satırın tutarı yorumlanabilir olsa da tarihi geçersizdir. Bu yazının amacı tarihli analiz olduğundan satırın tamamını doğrulanmış alt kümeye almıyoruz. Başka bir görevde yalnızca tutarlar inceleniyorsa farklı bir uygunluk kuralı kurulabilir. Önemli olan hangi ölçütle hangi satırın dahil edildiğini raporda belirtmektir; istisna satırlarını silip kalan veriyi eksiksiz gibi sunmak değildir.

Dönüşümü sessiz hatalara karşı sınayın

Microsoft belgesi, dönüştürülmüş tarihin gün, ay ve yıl parçalarını ayrı sütunlarda inceleyerek sonucu kontrol etmeyi de açıklar. Bu örnekte ilk iki tarih farklı metinler olmasına rağmen 3 Nisan 2026’ya karşılık gelir. Sadece son hücrenin görünümüne bakmak yerine yıl 2026, ay 4 ve gün 3 değerlerini ayrıca denetleyebilirsiniz.Kaynak: Microsoft Learn — Data types in Power Query

Sayılarda kontrol toplamı kadar sınır örnekleri de önemlidir. Tek bir yanlış dönüşüm diğer satırdaki ters hatayla toplamda gizlenebilir. Bu nedenle başında sıfır olan bir kodu, hem gün hem ay olabilecek bir tarihi ve ondalık ayraç içeren bir tutarı özellikle seçin. Ham dosya yeniden geldiğinde bu örneklerin sonucu aynı kalmalı; kaynak biçimi değişmişse işlem durmalıdır.

Küçük alıştırma: Üçüncü satırın üreticisi biçimin TR olduğunu teyit etsin. Tarih 5 Haziran 2026 olur; 1,250 ise bin iki yüz elli değil, 1,25 TL’dir. Doğrulanmış satır sayısı üçe, alt toplam 3.752,50 TL’ye çıkar. Diğer iki istisna devam eder. Sadece tarihi düzeltip tutarı eski tahminle bırakmak yarım bir düzeltmedir.

Kendi dosyanız için önce beş ila on temsilî satırla bir dönüşüm sözleşmesi hazırlayın. Sonra aynı kuralları bütün dosyaya uygulayıp istisna sayısını raporlayın. Böylece yapay zekâdan istediğiniz yorumun hangi veriye dayandığını bilir, temiz göründüğü için yanlış okunmuş bir tabloya güvenmezsiniz.