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

> Bu saha notunda veridive, model çıktısını güvenilmeyen bir girdi gibi ele alarak bir dil modelinden güvenilir yapılandırılmış verinin nasıl alınacağını anlatıyor. Sabit listeler ve açık null değerleriyle şema tasarımını, kısıtlanmış üretimi, iş kuralları ve ana veriyle katmanlı doğrulamayı, tekrar deneme sınırlarını, insan kuyruğunu ve değerlendirme setinde alan bazında doğruluğu ele alıyor.

Model çıktısını güvenilmeyen her girdi gibi ele alın: 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 yönlendirin.

## Öne çıkanlar

- Model çıktısını güvenilmeyen girdi olarak ele alın: katı bir şema, kısıtlanmış üretim ve başka bir sisteme ulaşmadan önce kodla doğrulama.
- Şemaları sabit listelerle, “belgede yok” için açık bir null değeriyle ve açıkça yazılmış birim ve biçimlerle tasarlayın.
- Türleri, iş kurallarını, alanlar arası toplamları ve ana veri eşleşmelerini doğrulayın; birkaç kez yeniden deneyin, sonra hataları bir insana gönderin.
- Doğruluğu değerlendirme setinde alan alan ölçün; yanlış değerleri, kaçırılan değerleri ve olmayan yerde uydurulan değerleri ayrı sayın.

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](https://veridive.com/tr/saha-notlari/e-fatura-otomasyonu-ve-yapay-zeka/) 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](https://veridive.com/tr/saha-notlari/turkce-ocr-ve-belge-okuma/) 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ı.

| Alan | Tam eşleşme | Başlıca hata | Çözüm |
|---|---|---|---|
| Tedarikçi vergi numarası | 50’de 49 | Taramada yanlış okunan bir rakam | Sağlama toplamı ve tedarikçi ana verisiyle eşleştirme |
| Fatura tarihi | 50’de 46 | Yerine teslim tarihi alınmış | Daha net bir alan açıklaması, iki örnek |
| Net toplam | 50’de 50 | Yok | Gerek yok |
| Kalemler | 50’de 42 | Sayfalara bölünmüş satırlar | Sayfa birleştirme adımı, toplam kontrolü |
| Satın alma siparişi numarası | 50’de 45 | Olmadığında uydurulmuş | “Tahmin yerine null” kuralı, açık siparişlerle eşleştirme |

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](https://veridive.com/tr/cozumler/erp-ve-kurumsal-is-akislari/) tipik bir ilk projedir; geliştirdiğimiz [özel yapay zeka yazılımının](https://veridive.com/tr/hizmetler/ozel-yapay-zeka-yazilimi/) da standart bir parçasıdır.

## Sık sorulan sorular

### Bir LLM’den güvenilir JSON çıktısı nasıl alınır?

Sabit listeler, açık null değerleri ve açıkça yazılmış biçimlerle katı bir şema tanımlayın; mümkünse her yanıt ayrıştırılabilsin diye modelin yapılandırılmış çıktı ya da şema modunu kullanın. Ardından her alanı kodla doğrulayın: türler, iş kuralları, alanlar arası toplamlar ve ana veriyle eşleştirme. Hata mesajıyla bir iki kez yeniden deneyin; yine de geçemeyeni bir insana gönderin.

### LLM ile veri çıkarmanın doğruluğu nasıl ölçülür?

Belgelerin tamamına göz gezdirerek değil, referans değerleri olan gerçek belgelerden oluşan bir değerlendirme setinde alan alan ölçün. Her alan için tam eşleşmeleri, kaçırılan değerleri ve belgede olmayan yerde uydurulan değerleri sayın; sonuçları belge türüne, tedarikçiye ve tarama kalitesine göre ayırın. Hiç düzeltme gerekmeden bütün kontrollerden geçen belgelerin sayısını da izleyin.

### Belgede olmayan bir değer için LLM ne yapmalı?

Tahmin değil, açık bir null döndürmeli. Şema her isteğe bağlı alan için null değerine izin vermeli ve “belgede yok” ile “belgede var ama okunamıyor” durumlarını ayırmalıdır; ikincisi bir işaret ve gerekçe alır. Varsayılan değerler kodda ve görünür biçimde uygulanır. Her alan için, eksik değerin kabul edilebilir olup olmadığını ya da belgeyi bir insana gönderip göndermediğini söyleyen bir kural gerekir.