Finans PDF’lerinde %15 daha doğru veri: LlamaParse + Gemini 3.1 Pro

Bir broker ekstre PDF’ini açıp “şu işlemleri düzgünce Excel’e aktaralım” dediğiniz an, çoğu ekip aynı gerçekle yüzleşiyor: PDF, veri gibi görünür ama veri değildir. Hele finans PDF’leri… Çok satırlı açıklamalar, bir hücreye sıkışmış dipnotlar, sayfa sonuna taşan tablolar, “Toplam” satırlarıyla karışan alt kırılımlar… Tek bir hatalı parse, yanlış bakiye, yanlış risk raporu ya da daha kötüsü yanlış uyum (compliance) alarmı demek.

Tam da bu yüzden Google for Developers’ın paylaştığı bir örnek dikkat çekici: Finansal PDF’lerde doküman ayrıştırma doğruluğunu %15 artırmayı hedefleyen bir akıştan bahsediyorlar. Paylaşımın çıkış noktası, “unstructured” yani dağınık görünen broker ekstrelerini ve karmaşık tabloları daha tutarlı biçimde yüksek kaliteli, yapılandırılmış veriye dönüştürmek. İlgili tweet’te anlatılan yaklaşımın detaylarına, Google for Developers’ın paylaştığı örnek koda dair tweet’te göz atabilirsiniz.

Finans PDF’leri neden bu kadar zor?

Finans dokümanları “standart” görünse de, sahada durum farklı. Aynı aracı kurumun iki farklı ayındaki ekstresi bile farklı şablonlara kayabiliyor. Bazı satırlar “ISIN / Ticker” ile başlıyor, bazıları açıklamayla. Bazı tablolar sayfa ortasında kesilip devam sayfasında yeniden başlıyor. Üstelik sayısal alanlar da başlı başına tuzak: “1.234,56” mı “1,234.56” mı, eksi değer parantez içinde mi, komisyonlar ayrı mı yazılmış, vergi satırları hangi başlığa bağlı?

Burada klasik OCR + regex yaklaşımı genelde duvara tosluyor. Çünkü problem sadece karakterleri tanımak değil; tablonun mantığını, satırların birbirine bağlılığını ve dipnotların hangi satıra ait olduğunu anlamak.

LlamaParse burada neyi çözüyor?

LlamaParse gibi araçlar, PDF’ten metni çekmekle yetinmeyip dokümanın yapısını daha “modelin anlayacağı” şekilde çıkarmaya odaklanıyor. Yani tablo hücrelerini, başlık hiyerarşisini, satır gruplarını daha isabetli bir şekilde yakalayıp bunu yapılandırılmış bir ara formata dökme fikri öne çıkıyor.

Bu ara format kritik; çünkü bir sonraki aşamada devreye giren büyük modelin (burada Gemini 3.1 Pro) işi, dağınık ham metinle boğuşmak yerine daha temiz bir temsil üzerinde akıl yürütmek oluyor. Tweet’te geçen “Precise reasoning” vurgusu da aslında buna işaret ediyor: modelin sadece “çıktı üretmesi” değil, finansal tablonun bağlamını doğru kurması.

Gemini 3.1 Pro ile “çıkarım” katmanı

PDF’ten gelen veriyi yapılandırdığınızda bile hâlâ karar verilmesi gereken noktalar kalıyor. Örneğin “Net Amount” hangi formülle oluşmuş, komisyon ve vergi nerede ayrışıyor, aynı varlık için farklı satırlara bölünmüş hareketler tek bir işlem mi sayılmalı?

Büyük modellerin güçlü olduğu yer burası: sınırlı, kural tabanlı bir parser yerine, tabloda neyin neye karşılık geldiğini daha esnek biçimde çözümleyebilmek. Tabii bu esneklik kontrollü olmazsa risk üretir. Bu nedenle pratikte iyi sonuç veren kurgu genelde şu oluyor: önce LlamaParse gibi bir araçla yapısal iskeleti çıkar, sonra Gemini 3.1 Pro ile alan eşleştirme, tutarlılık kontrolü ve zorlu istisnaları çöz.

“Event-driven scaling” neden önemli?

Finans PDF’leri genelde toplu halde gelir: ay sonu kapanışı, günlük saklama raporları, KYC dokümanları, işlem teyitleri… Yani trafik patlamaları yaşanır. Event-driven yaklaşım, örneğin bir PDF bir klasöre düştüğünde ya da bir bucket’a yüklendiğinde otomatik pipeline’ın tetiklenmesi demek. Böylece 10 dosyada da 10.000 dosyada da aynı akış çalışır; kapasiteyi ihtiyaca göre büyütürsünüz.

Bu model, özellikle denetim izi açısından da avantajlıdır. Hangi PDF ne zaman işlendi, hangi sürüm parser kullanıldı, hangi model çağrıldı, çıktı hangi şemaya göre üretildi gibi soruların cevabı kayıt altında kalır. Finans tarafında “doğru veri” kadar “izlenebilir süreç” de önemlidir.

%15 artış pratikte neye karşılık gelir?

%15 doğruluk artışı kulağa küçük gelebilir ama finans işlerinde etkisi büyür. 100 satırlık bir ekstrede 10 satır hatalı parse ediliyorsa, %15 iyileşme o hatayı 8-9 satıra indirmekten fazlası olabilir; kritik satırların (toplamlar, bakiye, vergi) daha sık doğru yakalanması demektir. Üstelik downstream sistemlerde, küçük bir ayrıştırma hatası zincirleme hatalara yol açar: yanlış sınıflandırma, yanlış toplam, yanlış rapor.

Bu yüzden LlamaParse + Gemini 3.1 Pro kombinasyonunu “PDF’ten veri çıkarma” diye küçümsememek lazım. Asıl mesele, finansal gerçeği temsil eden bir veri setini, dağınık bir dokümandan güvenilir biçimde üretmek. Eğer elinizde broker ekstreleri, saklama raporları ya da yatırım hesap dökümleri gibi PDF’ler varsa, bu yaklaşım denemeye değer bir referans mimari gibi duruyor.