Türkçe belgeleri yapay zekayla okumak: OCR, tablolar, kaşe ve imzalar.

Bir yapay zeka sistemi bir belgeyi yanlış okuduğunda suç genellikle modele atılır. Oysa modele ne verildiğine bakın: her “ş” harfinin “s” olduğu bir metin, tek paragrafa dönüşmüş bir kalem listesi, şirket kaşesinin altında kalmış bir tutar. Model, hasarlı bir kopyayla elinden geleni yaptı.

Belge hatalarının çoğu modelden önce başlar; Türkçe belgeler ise kendi tuzaklarını ekler: İngilizceyle eğitilmiş OCR araçlarının düşürdüğü harfler, ondalık ayracının yerini değiştiren sayı biçimleri, irsaliye ve sözleşmelerdeki kaşeler ve ıslak imzalar. Çözüm, her belge türü için kendi yolunu seçen, Türkçe karakterlerdeki ve temel alanlardaki hataları ölçen ve okunamayan sayfaları tahmin yürütmek yerine bir insana gönderen bir işleme hattıdır.

Belge işleme hatları bilgiyi nerede kaybeder?

Beş noktada; her biri çıktıya ulaştığında bir model hatası gibi görünür:

1. Giriş. Açılı çekilmiş fotoğraflar, düşük çözünürlüklü ya da yeniden taranmış kopyalar, tek bir PDF’te birleştirilmiş birkaç belge.
2. Metin. Yanlış okunan karakterler ve yanlış okuma sırası: solda Türkçe, sağda İngilizce metin bulunan iki dilli bir sözleşme, satır satır ve iki sütunu birden kesecek biçimde okunur.
3. Yapı. Metne dönüşmüş tablolar, sayfalara bölünmüş satırlar, gövdeye karışan tekrarlı başlıklar.
4. Üst katmanlar. Basılı metnin üstündeki kaşeler, imzalar ve elle yapılmış düzeltmeler.
5. Normalleştirme. Yanlış kurallarla dönüştürülen tarihler, tutarlar ve karakter kodlamaları.

İş bittiğinde: çıkarılan her değer, sayfadaki bölgesine ve modelin gördüğü metne kadar izlenebilir.

Türkçe karakterler neden yanlış okunur?

Türkçeye özgü ç, ğ, ı, İ, ö, ş ve ü harflerini ayıran işaretler küçüktür: bir çengel, bir kısalık işareti, bir nokta ya da noktanın yokluğu, iki nokta. Düşük çözünürlüklü taramalar, fakslar ve bulanık fotoğraflar önce bunları kaybeder. Yalnızca İngilizceye göre ayarlanmış bir OCR aracı bu harfleri hiç üretemez ve yerine en yakın Latin harfini koyar; bu yüzden önce dil ayarını kontrol edin. Hasar sonraki adımlara yayılır:

• İsimler ve adresler. “Gökçe Şahin” “Gokce Sahin” olur ve doğru yazımla yapılan arama kaydı kaçırır.
• Eşleştirme. ERP’deki tedarikçi adı Türkçe karakterlerle yazılıdır, belgeden çıkarılan ad ise değildir. Adayları bulmak için ASCII karşılıklarına indirgenmiş biçimleri karşılaştırın; eşleşmeyi ise bir kural ya da bir insan onaylasın.
• Geçerli ama yanlış kelimeler. Bazı hatalı okumalar başka bir gerçek kelime üretir; “çam” yerine “cam” gibi. Bu yüzden sözlük kontrolü her hatayı yakalamaz.
• Büyük/küçük harf. “İRSALİYE” kelimesindeki noktaları düşüren OCR aracı “IRSALIYE” üretir; doğru Türkçe küçültme kuralları da bunu “ırsalıye” yapar. Harf dönüşümü kuralları bir OCR hatasını onaramaz.

Sayılar da aynı özeni ister. “4.500,00” dört bin beş yüzdür; ama İngilizce biçim bekleyen bir ayrıştırıcı “4.500” değerini dört buçuk diye okur. IBAN’lar ve TC kimlik numaraları kontrol hanesi taşır; metne güvenmek yerine bunları doğrulayın.

İş bittiğinde: Türkçe harflerdeki hatalar ayrıca ölçülür; isimler ve adresler ana veriyle karşılaştırılarak kontrol edilir.

Dijital metin, OCR ve görsel modeller arasında nasıl seçim yapılır?

Önce elinizde ne olduğunu tespit edin, sonra yönlendirin:

Metin katmanı, dosyanın dijital PDF olduğunu kanıtlamaz: biri uzun zaman önce üzerinde kötü bir OCR çalıştırmış olabilir; bu yüzden katmanın kalitesini test edin. Yapılandırılmış elektronik faturalar zaten veri olarak gelir ve e-Fatura otomasyonunu anlatan notta açıklandığı gibi, bunların görüntülenmiş kopyasını okumak yalnızca hata ekler.

Sayfa görüntüsünü doğrudan okuyan görsel modeller dağınık sayfa düzenleriyle iyi başa çıkar, ama boşlukları akla yatkın tahminlerle doldurur: “okunamıyor” yanıtına izin verin ve verdikleri sayıları çapraz kontrol edin.

İş bittiğinde: her belge türünün, gerçek dosyalardan alınmış bir örneklemle seçilmiş, adı konmuş bir yolu vardır; hiçbir yola uymayan her şey bir insana gider.

Tablolar nasıl bozulmadan çıkarılır?

Kalemler, miktarlar ve fiyatlar tablolarda durur. Metne dönüştüklerinde model hangi sayının hangi satıra ait olduğunu tahmin etmek zorunda kalır. Tabloları satırları, sütunları ve hücre konumlarıyla tablo olarak çıkarın; birleştirilmiş hücreleri, birden çok satıra yayılan açıklamaları ve sonraki sayfada devam eden tabloları da ele alın.

Sonra doğrulayın. Miktar çarpı birim fiyat satır tutarını vermeli, satırların toplamı ara toplamı tutmalı; ara toplam, KDV ve varsa tevkifat da genel toplamla uyuşmalı. Bir kontrol başarısız olursa tabloyu, hatalı hücreleri vurgulayarak işaretleyin; toplamı tutturmak için işleme hattının bir sayıyı değiştirmesine asla izin vermeyin. Aynı disiplin, bir modelden alınan her yapılandırılmış çıktı için de geçerlidir.

İş bittiğinde: çıkarılan her tablo aritmetik kontrollerinden geçer ya da işaretlenir.

Kaşe, imza ve el yazısında ne yapılmalı?

Ticari belgelerde şirket kaşesi ve çoğu zaman ıslak imza bulunur; ikisi de sık sık basılı metnin üstüne gelir. Bunları yorumlanacak değil, tespit edilecek nesneler olarak ele alın: var mı yok mu, nerede ve okunması gereken bir alanın üstünü kapatıyor mu? İmzanın gerçek olup olmadığı ya da kaşenin doğru şirkete ait olup olmadığı insanların kontrol edeceği bir konudur. Elle yapılmış düzeltmeler, örneğin üstü çizilip yanına yenisi yazılmış bir miktar, bir insanın ele alacağı istisnalardır.

Bölgesel bir tedarikçiden gelen temsili bir taranmış irsaliye düşünün. OCR teslimat adresini “Şişli” yerine “Sisli” diye okur; mavi bir kaşe de ikinci satırdaki miktarın üstünü kapatır. Kontroller olmadan “Sisli” adres alanına girer, model de miktarı bağlamdan tahmin eder. Kontrollerle ise üç şey olur. Adres kontrolü müşteri ana verisinde “Şişli” kaydını bulur ve işaretli bir düzeltme olarak önerir. Kaşe algılayıcı çakışmayı bildirir; miktar doldurulmak yerine “okunamıyor” olarak işaretlenir. Satır tutarının birim fiyata bölünmesi de bir değer verir, ama bu yalnızca öneri olarak gösterilir. İrsaliye, kaşe bölgesi vurgulanmış sayfa görüntüsüyle birlikte bir insana gider; o kişi miktarı asıl belgeyle karşılaştırıp onaylar.

“Okunamıyor” diye işaretlenmiş bir alan doğru bir yanıttır. Tahminle doldurulmuş bir alan değildir.

Veri çıkarma kalitesi nasıl ölçülür?

Alan alan ölçün. Bunun için tedarikçilerinizi, tarama kalitelerini ve girdi türlerini kapsayan; telefon fotoğraflarını, kaşeli ve el yazılı sayfaları da içeren gerçek belgelerden bir değerlendirme seti kurun. Doğru değerleri belgeleri işleyen kişiler etiketler. Sonra şunları ölçün:

• Alan doğruluğu: biçimler normalleştirildikten sonra her temel alan için.
• Türkçe harflerdeki hatalar: ayrıca raporlanır.
• Tablo doğruluğu: hücreler doğru mu, satırlar hizalı mı?
• Kaşe ve imza tespiti: var ya da yok, doğru tespit edildi mi?
• Sessiz hatalar: kimsenin işaretlemediği yanlış değerler. Asıl maliyet bunlardadır; işaretlenen vakalardan ayrı izlenir.

Sonuçları belge türüne ve yola göre raporlayın; her alan için eşiği süreç sahibiyle birlikte belirleyin.

Hangi belge türüyle başlamalı?

İrsaliye gibi tek bir belge türü seçin ve elinize geçen en kötü kopyaları da içeren bir örneklem toplayın. Temel alanları etiketleyin, mevcut işleme hattınızı çalıştırın; Türkçe karakter hatalarını ve sessiz hataları sayın. Sonuçlar her girdinin hangi yola ihtiyaç duyduğunu gösterir. Bu belgelerden ERP kayıt taslakları hazırlamak ERP ve kurumsal iş akışları çalışmasının özüdür. Alttaki işleme hatları veri ve yapay zeka altyapısı işidir ve aynı ayrıştırma her doküman asistanına de hizmet eder.