Banka ekstrelerini açmak kimsenin eğlencesi değildir. Bunlar taranmış PDF'ler, CSV dışa aktarımları veya OFX gibi gizemli kısaltmalarla süslenmiş XML dosyaları olarak gelir. Muhasebeciler, defter tutanlar ve fintech geliştiricileri için bu belgeleri temiz ve yapılandırılmış verilere dönüştürmek bitmek bilmeyen bir baş ağrısıdır. Büyük dil modelleri sahneye çıktığında, bir çıkış yolu sunuyor gibi göründüler. Makineye bir PDF verin ve JSON isteyin. Ne ters gidebilir ki?

Banka ekstrelerini kullanılabilir verilere dönüştürmek için tasarlanan bir araç olan StatementDecoder'ı geliştirirken, tam olarak nelerin ters gidebileceğini öğrendim. Birçok geliştirici gibi, zor kısmın sisteme farklı belge düzenlerini okumayı öğretmek olacağını varsaydım. Yanılmışım. Belgeleri okumak neredeyse önemsiz bir işti. Asıl kabus, makinenin sessizce bir sayı uydurduğunu veya bir işlem tutarındaki iki rakamın yerini değiştirdiğini fark etmekti.

Çok İyi Çalışan Demo

İlk denemem baştan çıkarıcı derecede basitti. Banka ekstrelerini doğrudan bir LLM'e aktardım ve karşılığında yapılandırılmış JSON talep ettim. Sonuçlar sihir gibiydi. Model, farklı düzenleri kolaylıkla yönetiyordu. Standart ayrıştırıcıların takıldığı taranmış PDF'leri okuyordu. Açık talimatlar olmadan tabloları, başlıkları ve çok sayfalı ekstreleri anlıyor gibi görünüyordu. Birkaç görkemli saat boyunca sorunun çözüldüğünü sandım.

Sonra gerçek müşteri verileriyle test ettim ve sihir buharlaştı. Birleşik Krallık bankalarının her biri kendi ekstre tasarımlarını kullanıyor ve aradaki farklar sadece kozmetik değil. Wise ekstreleri kendine has biçimlendirme tuhaflıkları taşıyor. Revolut CSV dışa aktarımları, çoklu para birimi işlemlerini ve meta veri alanlarını nasıl yönettiklerini fark edene kadar basit görünüyor. Gerçekten 1990'lardan kalma gibi görünen eski OFX dosyaları, modern işaretleme bekleyen herhangi bir ayrıştırıcıya arkaik etiket yapıları ve kodlama sorunları fırlatıyor.

Model, verileri hala piyasadaki herhangi bir hazır şablon sisteminden çok daha iyi çıkarıyordu. Ancak işin içinde para olduğunda, "çok daha iyi" olması yeterli değil.

%99 Doğruluk Ne Zaman Bir Başarısızlıktır?

Finansal veri çıkarımı için yapay zeka kullanmanın temel sorunu şudur: Eğer bir model iki yüz işlem satırını işler ve yüz doksan dokuzunu doğru yaparsa, çıktı kusursuz görünür. JSON düzgün yapılandırılmıştır. Anahtarlar ve değerler birbirine uyar. Yüzeysel bir inceleme şüpheli hiçbir şey göstermeyebilir. Ancak o tek hata, bir tutardaki iki rakamın yerini değiştirirse, bir yatırımı çekim işlemine dönüştürürse veya ondalık virgülü kaydırırsa, muhasebe kayıtlarınız bozulur. Yapılandırılmış veri yığınına göz ucuyla bakarak bunu yakalayamazsınız.

Ham JSON'u inceleyen bir insan, bir işlem tutarındaki yer değiştirmiş bir rakamı nadiren fark eder. Biçimlendirme mükemmeldir, bu da paradoksal olarak hatayı daha tehlikeli hale getirir. Çoğu zaman doğru olan bir finansal araç piyasaya süremezsiniz. Ya doğru olmalı ya da emin olmadığını yüksek sesle ilan etmeli.

İlk tepkim öngörülebilirdi. Daha iyi istemler (prompts) tasarladım. Daha yetenekli modellere geçiş yaptım. Modelin çalışma sürecini göstermesi için "düşünce zinciri" (chain-of-thought) akıl yürütme yöntemini denedim. Bunların hiçbiri temel sorunu çözmedi. Aynı olasılıksal sistemden bir cevap üretmesini istiyor, sonra aynı sisteme bu cevabın doğru olduğunu onaylatmaya çalışıyordum. Bu bir doğrulama değildir. Bu, bir "öz-tutarlılık tiyatrosu"dur.

Kararı Matematiğe Bırakın

Banka ekstrelerinin çoğu belgede olmayan bir özelliği vardır: yerleşik aritmetik kısıtlamalar. Açılış bakiyesi artı tüm işlemlerin toplamı, kapanış bakiyesine eşit olmalıdır. Varsa, bakiye hareketleri satır satır birbirini tutmalıdır. Bunlar üslup tercihleri değildir; bunlar katı kurallardır.

Mimarinin yeniden inşasını bu içgörü üzerine kurdum. Artık, kaynağı ne olursa olsun her veri çıkarımı, herhangi bir kullanıcı görmeden önce bir doğrulama katmanından geçer. Verinin bulanık bir PDF'yi yorumlayan bir LLM'den mi, taranmış bir sayfayı okuyan bir OCR motorundan mı yoksa doğrudan bir CSV ayrıştırmasından mı geldiği önemli değildir. Doğrulayıcı, tüm kaynakları eşit derecede şüpheli kabul eder.

Kontrol vahşi bir basitliktedir. Her işlemi açılış bakiyesine ekleyin. Sonucu belirtilen kapanış bakiyesiyle karşılaştırın. Sayılar eşleşmiyorsa bir şeyler yanlıştır. Ekstreyi inceleme için işaretleyin. Veri çıkarımını reddedin. Kullanıcıya ulaşmasına izin vermeyin.

Bu tek değişiklik ürünün tüm karakterini değiştirdi. Dil modelinin artık mükemmel olmasına gerek yoktu. Sadece matematiksel bir sınavdan geçebilecek bir çıktı üretecek kadar iyi olması yeterliydi. Baskı, kısıtlanmamış bir alanda imkansız doğruluğa ulaşmaktan, üretim ve doğrulama arasında sıkı bir geri bildirim döngüsü kurmaya kaydı.

Doğrulayıcı ayrıca hatalardaki kalıpları da ortaya çıkardı. Belirli belge türleri matematik kontrolünden sürekli olarak geçemiyordu; bu da bana çabayı tam olarak nereye harcamam gerektiğini söylüyordu. Her alanda körü körüne istem mühendisliğini (prompt engineering) iyileştirmek yerine, belirli banka düzenlerinin sistematik hatalara neden olduğunu görebiliyordum.

Kodun Gerektiği Yerde Kod, Parladığı Yerde Yapay Zeka

Belki de en öğretici ders, iş akışının (pipeline) ne kadar büyük bir kısmının yapay zekaya hiç ihtiyaç duymadığını fark etmekti. Karışık Avustralya OFX dosyalarıyla karşılaştığımda, içgüdüm soruna token'lar fırlatmak yönündeydi. Bozuk XML'i modele beslemeyi ve ayrıştırmadan (parsing) önce yapıyı onarmasını istemeyi kısa bir süreliğine düşündüm. Bunun yerine, yirmi satırlık deterministik bir kod yazdım. Kodlama tuhaflıklarını ve hatalı etiketleri, dosya başına sıfır maliyet ve mükemmel tekrarlanabilirlik ile anında düzeltti.

Bu deneyim, veri çıkarma iş akışlarının (extraction pipelines) nasıl organize edilmesi gerektiğini netleştirdi. Üç farklı görev vardır ve bunlar birbirine karıştırılmamalıdır.

  • Model, karmaşık belgeleri anlar. Eğri büğrü tablolar, karışık yazı tipleri ve el yazısı içeren taranmış PDF'ler