Bir dil modelinden güvenilir yapılandırılmış veri almak.

Veri çıkarma demosu, ekibin denediği her fatura için temiz bir JSON döndürdü. Ardından tutarları 3.480,00 biçiminde yazan bir tedarikçi ilk faturasını gönderdi. Tutar metin olarak geldi, noktayı ondalık ayracı sanan bir ayrıştırıcı onu üç virgül kırk sekiz olarak okudu ve ERP taslağı kabul etti. Hiçbir şey çökmedi. Model faturayı doğru okumuştu; ama model ile ERP arasındaki sözleşme, bir tutarın neye benzediğini hiç tanımlamamıştı.

Bir LLM’den yapılandırılmış çıktı almak, model çıktısını güvenilmeyen her girdi gibi ele aldığınızda işe yarar: katı bir şema tanımlayın, üretimi kısıtlayın, her alanı iş kurallarıyla doğrulayın ve doğrulamadan geçemeyeni sonsuza kadar yeniden denemek yerine bir insana gönderin.

Serbest metin entegrasyonları neden bozar?

Çıktıyı alan sistemler kesin değerlere ihtiyaç duyar: bir tarih, ondalıklı bir tutar, bir listeden bir kod. “Teslimden itibaren 30 gün vadeli”, “mart ortası” ya da “ekte” gibi serbest metni birinin yorumlaması gerekir; bir entegrasyon bunu yapamaz.

Dil modelleri akıcıdır, kesin değildir. Makul biçimlerde makul değerler üretirler; makul olan ise yanlışın tehlikeli türüdür. Fatura tarihi yerine teslim tarihini gösteren ama biçimi doğru olan bir tarih, her biçim kontrolünden geçer. Çıktı çalıştırmadan çalıştırmaya ve modelden modele de değişir; testte tutan bir biçim, bir model güncellemesinden sonra kayabilir.

Bir şey çıkarmadan önce verinin zaten veri olarak var olup olmadığını kontrol edin. Örneğin yapılandırılmış e-faturaların okunmasına değil, ayrıştırılmasına ihtiyaç vardır; bunun için e-Fatura’nın bittiği yerde yapay zekanın başladığını anlatan nota bakın.

Şema nasıl tasarlanır?

Belgeleri elle sisteme giren kişilerle birlikte ve her belge türü için ayrı bir şema:

• Serbest metin yerine sabit listeler. Belge türü, para birimi, vergi oranı ve ölçü birimi, ana verinizle örtüşen listelerden gelir.
• “Belgede yok” için açık bir null. Her isteğe bağlı alan null değerine izin verir ve talimatlar tahmin yerine null kullanılmasını söyler. Belgede olan ama okunamayan değerleri ayrı bir işaret belirtir.
• Açıkça yazılmış birimler ve biçimler. Tarihler yıl-ay-gün biçiminde; tutarlar binlik ayracı olmadan, ondalık ayracı nokta olan düz sayılar olarak; para birimi kendi alanında; miktarlar birimleriyle birlikte.
• Tek satırlık alan açıklamaları. Değerin genellikle nerede yer aldığı ve hangi benzerinin göz ardı edileceği: “fatura tarihi; teslim tarihi ya da vade tarihi değil”.
• Kanıt. Önemli alanlar için değerin geldiği sayfa ve metin; inceleyenler ve doğrulayıcılar kontrol edebilsin diye.

Şemaları düz ve küçük tutun. Derin iç içe yapılar ve onlarca isteğe bağlı alan, eksik bırakılan alanlara davetiye çıkarır.

Çıktı nasıl kısıtlanır ve doğrulanır?

Birçok model API’si ve model sunma altyapısı, üretimi bir JSON şemasıyla kısıtlayabilir. Bu olanak varsa kullanın: her yanıt ayrıştırılabilir ve türleri doğru olur. Böylece biçim sorunu çözülür ama doğruluk sorunu çözülmez; bu yüzden ardından sıradan kodla katmanlı doğrulama gelir:

1. Türler ve biçimler. Zorunlu alanlar dolu, tarihler geçerli, tutarlar sayısal, kodlar listelerden.
2. İş kuralları. Vade tarihi fatura tarihinden sonra gelir, tutarlar iade faturaları dışında pozitiftir ve vergi oranı işletmenizin kullandığı oranlardan biridir.
3. Alanlar arası kontroller. Kalemlerin toplamı net toplama eşittir; net tutar artı vergi, bir yuvarlama toleransı içinde brüt tutara eşittir; miktar çarpı birim fiyat her satırın tutarına eşittir.
4. Ana veriyle eşleştirme. Tedarikçinin vergi numarası tedarikçi ana verisinde vardır, satın alma siparişi açıktır, banka hesabı tedarikçi kaydıyla eşleşir.
5. Kanıt kontrolleri. Fatura numarası gibi tanımlayıcılar belge metninde gerçekten geçer.

Her katman ucuz, deterministik ve test edilebilirdir; prompta eklenecek bir talimat için bunu söylemek zordur.

Doğrulama başarısız olursa ne olur?

Bir iki kez yeniden deneyin ve belirli hatayı modele geri verin: “kalemlerin toplamı net toplamı tutmuyor; toplamlar bölümünü yeniden okuyun”. Tekrar denemeler biçim kaymalarını ve dikkatsiz okumaları düzeltir. Belirsiz, hasarlı ya da yeni bir belgeyi düzeltmez.

Bu yüzden kesin bir sınır koyun; ardından belgeyi, çıkarılan alanlar doldurulmuş ve başarısız kontroller vurgulanmış halde bir insana gönderin. Sınır olmazsa tekrar denemeler para yakar ve er ya da geç bir çıktı doğrulamadan tesadüfen geçer.

Çıktı doğrulamadan geçene kadar yeniden denemek, makul görünen yanlış bir yanıt üretmenin yoludur.

Kişinin düzelttiği kayıt bir değerlendirme vakası olur. Hata oranını tedarikçiye ve belge türüne göre izleyin: ani bir artış genellikle daha kötü bir modele değil, yeni bir belge düzenine ya da kaynak taraftaki bir değişikliğe işaret eder.

Bilinmeyen ve eksik değerler nasıl ele alınır?

Her alan için üç durumu birbirinden ayırın: belgede var ve okundu; belgede yok (null); belgede var ama okunamıyor ya da belirsiz (gerekçesiyle işaretlenir). Modelin bir boşluğu genel bilgiyle (“ödeme vadesi genellikle otuz gündür”) ya da komşu bir alandan doldurmasına asla izin vermeyin.

Eksikliğin kabul edilebilir olup olmadığına her alan için ayrı karar verin. Bazı tedarikçilerin belgelerinde satın alma siparişi numarası çoğu zaman hiç yer almayabilir; eksik bir toplam ise belgeyi her zaman durdurmalıdır. Varsayılan değerler kodda ve görünür biçimde uygulanır; model onları asla uydurmaz. Belgeler tarama ya da fotoğraf olarak geliyorsa birçok hata, model daha hiçbir şey okumadan başlar. Bu aşamayı Türkçe belgelerin yapay zekayla okunmasını anlatan not ele alıyor.

Veri çıkarmanın kalitesi nasıl ölçülür?

Alan alan ve referans değerleri olan gerçek belgelerden oluşan bir değerlendirme setinde. Her alan için normalleştirme sonrası tam eşleşmeleri, kaçırılan değerleri ve belgede olmayan yerde uydurulan değerleri sayın; en tehlikelisi sonuncusudur. Sonuçları belge türüne, tedarikçi grubuna, dile ve tarama kalitesine göre ayırın ve doğrudan geçiş oranını izleyin: bütün kontrollerden geçen ve hiçbir düzeltme gerektirmeyen belgelerin oranı.

Temsili bir örnek; sayılar varsayımsaldır: bir değerlendirme setinden elli tedarikçi faturası.

Belge düzeyinde tek bir puan bu sistemi neredeyse hazır sayardı. Alan tablosu ise tam olarak nerede çalışmak gerektiğini ve hangi hataları doğrulamanın zaten yakalayacağını gösterir.

Neden önce şema, sonra prompt?

Bir belge türü seçin ve şemasını o belgeyi elle sisteme giren kişilerle birlikte yazın: her alan, biçimi, belgede nerede yer aldığı ve “eksik”in ne anlama geldiği. Doğrulama kurallarını prompttan önce yazın. Doğrulamalı veri çıkarma ve bir inceleme kuyruğu, ERP ve kurumsal iş akışlarında tipik bir ilk projedir; geliştirdiğimiz özel yapay zeka yazılımının da standart bir parçasıdır.