Büyük dil modeli ile belgeden yapılandırılmış veri nasıl çıkarılır

LLM ile veri çıkarma ne zaman uygun?

Belgeden veri çıkarmanın klasik yolu kurallar, düzenli ifadeler ve şablonlardır. Belge biçimi sabitse (aynı formdan binlerce kopya) bu yöntemler hızlı ve ucuzdur. Belge biçimi çok değişkense, örneğin farklı firmalardan gelen sözleşmeler, serbest yazılmış e-postalar, özgeçmişler ya da teklif yazıları, kural yazmak sürekli bakım gerektirir.

Büyük dil modeli (LLM) bu tür yarı yapılandırılmış belgelerde, alan adını ve tanımını okuyup metinden ilgili bilgiyi bulabilir. Aynı komutla farklı düzenlerdeki belgeleri işleyebilmek en büyük avantajıdır.

Karşılığında dikkat gerekir: model bulamadığı bilgiyi uydurabilir, aynı belgede farklı çalıştırmalarda farklı çıktı verebilir ve her belge için maliyet ve gecikme doğurur. Bu yüzden LLM ile çıkarma, mutlaka doğrulama katmanı ve ölçüm ile birlikte kurulmalıdır.

Önce alan şemasını tasarlayın

Model ne istendiğini bilmezse tahmin eder. Çıkarılacak alanları bir şema olarak yazın: • Alan adı: kısa ve tutarlı (örneğin invoice_no, contract_start, party_name). • Tür: metin, sayı, tarih, liste, evet/hayır. • Tanım: alanın neyi ifade ettiği, belgede hangi etiketlerle geçebileceği. • Biçim: tarih ve tutar için beklenen biçim (örneğin tarihler gün-ay-yıl düzeninde, tutarlar nokta ayraçlı sayı olarak). • Bulunamazsa: değer boş (null) olacak; tahmin yapılmayacak.

Şemayı iş birimiyle birlikte belirleyin. Hangi alanın iş kararını gerçekten etkilediğini onlar bilir; gereksiz alan hem hata hem maliyet getirir.

Alan tanımlarında belirsizliği azaltın. "Tarih" yerine "sözleşmenin imza tarihi" ve "geçerlilik başlangıç tarihi" gibi ayrı alanlar tanımlamak, modelin yanlış tarihi seçmesini önler.

Komutun (prompt) yapısı

İyi bir veri çıkarma komutu şu parçalardan oluşur: • Görev: "Verilen belge metninden yalnızca şemada tanımlı alanları çıkar." Bu cümlede modelin kapsamı daraltılır. • Şema: alan adları, türler ve tanımlar. • Kurallar: bilgi yoksa null yaz; metinde olmayan değeri tahmin etme; yalnızca geçerli JSON döndür; ek açıklama ekleme. • Örnek: bir belge parçası ve beklenen çıktı. Örnekler, biçim konusundaki belirsizliği büyük ölçüde giderir. • Belge: ayraçlarla (örneğin belge başı ve sonu işaretleriyle) ayrılmış asıl metin.

Belge içeriği güvenilmeyen kaynaktan geliyorsa içinde komut gibi görünen metin olabilir. Belge metninin yalnızca veri olduğunu, içindeki yönergelerin uygulanmaması gerektiğini komutta açıkça belirtin ve çıktıyı yine de doğrulayın.

Bazı sağlayıcılar çıktıyı bir şemaya zorlayan özellikler sunar. Bu özellikler hızlı değişebildiği için kullandığınız sağlayıcının güncel belgesine bakın; özellik olsa da doğrulama katmanını atlamayın.

Kısa uygulama: çağır, ayrıştır, doğrula

Şu iskelet, modelin çıktısını güvenli işlemenin temel akışını gösterir. call_llm işlevi, kullandığınız sağlayıcıyı saran kendi işlevinizdir; belge metni ve komut metni dışarıdan gelir.

import json

FIELDS = ["invoice_no", "date", "supplier", "total_amount"]

def extract_fields(document_text): response = call_llm(PROMPT + document_text) try: data = json.loads(response) except json.JSONDecodeError: return None result = {} for field in FIELDS: value = data.get(field) if value is not None and str(value) not in document_text: value = None result[field] = value return result

Bu akış birkaç koruma sağlar: bozuk JSON atılır, şemada olmayan alanlar yok sayılır ve değeri belge metninde hiç geçmeyen alan boşaltılır. Son kontrol, tarih gibi biçim dönüştürülen alanlarda çok katı kalabilir; bu durumda alan bazında özel karşılaştırma yazın. Boşaltılan ya da None dönen belgeleri insan inceleme kuyruğuna gönderin.

Uzun belgeler ve OCR girdisi

Sözleşmeler ve raporlar modelin bağlam penceresine sığmayabilir ya da sığsa bile uzun metinde dikkat dağılabilir. Çözüm olarak belgeyi bölümlere ayırın (madde, sayfa, başlık bazında) ve ilgili alanı barındırması muhtemel bölümü modele verin. Önce bir arama ya da sınıflandırma adımıyla ilgili bölümü bulmak, her alanı tüm belgeyle sormaktan hem ucuz hem daha doğrudur.

Taranmış belgelerde LLM'e giden girdi OCR çıktısıdır. OCR hataları (karışan karakterler, bozulan tablolar) çıkarma kalitesini düşürür. Ön işlemeyi iyileştirin, tabloları satır-sütun yapısını koruyacak biçimde metne dönüştürün ve gerekirse belge düzeni bilgisini komuta ekleyin.

Görüntüyü doğrudan okuyabilen modeller de vardır; yine de maliyet, doğruluk ve veri gizliliği açısından kendi belgelerinizde OCR hattıyla karşılaştırın.

Hatalı çıktıyı yakalamak ve değerlendirme

LLM'in en tehlikeli hatası, makul görünen yanlış değerdir. Yakalamak için çok katmanlı kontrol kurun: • Kaynak kontrolü: çıkarılan değer belgede geçiyor mu? • Biçim kontrolü: tarih gerçek bir tarih mi, tutar sayıya dönüşüyor mu? • İş kuralı: toplam, kalemlerle uyuşuyor mu; bitiş tarihi başlangıçtan sonra mı? • Tutarlılık: aynı belge birden fazla kez çalıştırıldığında sonuç aynı mı? Farklıysa belge belirsizdir ve incelemeye gitmelidir.

Değerlendirme için elle etiketlenmiş bir altın küme hazırlayın: gerçek belge dağılımını yansıtan yeterli sayıda belgeden oluşmalıdır. Alan bazında doğruluğu ölçün; tam eşleşme ile anlamsal eşleşmeyi ayırın (örneğin "A.Ş." ile "Anonim Şirketi"). Komutu ya da modeli değiştirdiğinizde bu kümeyi yeniden koşturun.

Güven değeri sıklıkla modelden doğrudan gelmez; doğrulama başarısı, tekrar tutarlılığı ve belge kalitesi birleştirilerek türetilir.

Gizlilik, maliyet ve sık yapılan hatalar

Belgeler kişisel veri, ticari sır ya da sözleşme bilgisi içerebilir. Verinin hangi sağlayıcıya gittiği, orada nasıl saklandığı ve kişisel verilerin korunması mevzuatı açısından uygunluğu bilgi güvenliği ve hukuk ekipleriyle birlikte değerlendirilmelidir. Hassas belgelerde kurum içinde çalışan modeller ya da kişisel bilgiyi önceden maskeleyen bir adım tercih edilebilir.

Maliyet için belge başına işlenen metin miktarı belirleyicidir. Gereksiz kısımları (imza sayfası, tekrarlı üst bilgiler) çıkarmak, ilgili bölümü seçmek ve önbellekleme kullanmak maliyeti düşürür.

Sık hatalar: • Şema tanımadan modele "bütün önemli bilgileri çıkar" demek. • Bilgi yoksa ne yapılacağını söylememek: model uydurur. • Çıktıyı doğrulamadan veritabanına yazmak. • Birkaç belgeyle başarılı görünüp gerçek çeşitlilikte ölçüm yapmamak. • Model güncellendiğinde sonuçların değişebileceğini unutmak; sürümü sabitleyin ve sınama kümesini yeniden koşturun.

Mindset programında belge işleme bağlamı

Mindset kataloğundaki OCR ve Belge İşleme programı, belge düzeni analizi ve yapısal çıkarımı, kurumsal belge işlem hattı tasarımını, görüntü ön işlemeyi ve bulut OCR servisleri ile sektör uygulamalarını kapsar. Doküman Sınıflandırması programı, belgenin türünü belirleme, model dağıtımı ve izleme başlıklarıyla bu hattın önceki adımını tamamlar.

İçerik; belge yoğun süreçleri otomatikleştirmek isteyen veri, yazılım ve dönüşüm ekipleri için uygundur. Kurumlar kendi belge türlerini şemaya dökerek çıkarma, doğrulama ve inceleme akışını uygulamalı olarak çalışabilir.