Hasar Dosyaları, Ticket'lar ve KYC Belgeleri için Kendi Altyapınızın İçinde Bir LLM Pipeline'ı: Çıkarım, Doğrulama, İnceleme ve Denetim

Hasar dosyaları, destek ticket'ları ve KYC belgeleri ortak bir sorunu paylaşır: insanlar, başka bir sistemin ihtiyaç duyduğu alanları doldurmak için bunları okur. Bir hasar talebi bir poliçe numarasına, bir hasar tarihine ve fatura kalemlerine; bir ticket bir kategoriye ve bir müşteriye; bir kimlik belgesi bir ada, bir doğum tarihine ve bir geçerlilik bitiş tarihine dönüşür. Bu işle birlikte gelen gereksinim genellikle her şeyden önce dile getirilir: belgeler OpenAI'a ya da başka herhangi bir harici model sağlayıcısına gidemez.

Modelin nerede çalışacağı ayrı bir karardır ve bu blogdaki önceki bir yazıda karşılaştırılmıştır. Bu yazı, altyapınızın içinde sunulan açık ağırlıklı bir modeli varsayar ve etrafındaki pipeline'ı, alımdan başka bir sistemin tükettiği kayda kadar anlatır. İşleyişi açıklar; bir vaka çalışması değildir.

Yedi aşama ve her biri içeride kalır

Veriyi harici sağlayıcılardan uzak tutmak, model çağrısının değil, pipeline'ın bütününün bir özelliğidir: OCR motoru, inceleme aracı, değerlendirme seti, denetim deposu ve loglar belgeyi ya da ondan türetilmiş bir şeyi tutar; pilotlar hakkındaki önceki yazı bunları eksiksiz listeler.

Alım: belgeyi herhangi bir şey okumadan önce sınıflandırın

Sonraki her aşama belge türüne bağlıdır: şema, kurallar, inceleyiciler ve saklama süresi; bu yüzden sınıflandırma önce gelir ve yolu belirler. E-postayla gelen bir hasar dosyası bir hasar formu, faturalar, fotoğraflar ve bir tıbbi rapor içerebilir; her ek ayrı ayrı sınıflandırılır ve aynı dosyaya bağlanır.

• Geldiğinde kanalı, göndericiyi ve bir içerik hash'ini kaydedin; böylece iki kez gönderilen bir belge iki ayrı dosyaya dönüşmeden tanınır
• Kapalı bir tür listesinden sınıflandırın; vLLM'in structured outputs dokümantasyonu, çıktının seçeneklerden tam olarak biri olmasını sağlayan bir choice parametresi listeler; böylece sınıflandırıcı bir tür uyduramaz
• Hiçbir türle eşleşmeyen ya da düşük uyumla eşleşen bir belgeyi en yakın şemaya değil, bir kişiye gönderin

Önce metin ve yerleşim, sonra dil modeli

Bir yazılımın ürettiği PDF, doğrudan okunabilen bir metin katmanı taşır. Bir tarama ya da telefonla çekilmiş bir fotoğraf ise yalnızca piksel taşır ve bir şeyin bunları konumlarıyla birlikte karakterlere dönüştürmesi gerekir.

Bu adım için açık kaynaklı motorlar yerel olarak çalışır. Tesseract'ın komut satırı dokümantasyonu, her kelime için bir güven sütunu içeren TSV çıktısını ve kelime güveni özniteliği taşıyan hOCR çıktısını gösterir; bu, yönlendirme aşamasının kullanabileceği kelime başına bir sinyaldir. MIT lisansı altındaki açık kaynaklı bir dönüştürme kütüphanesi olan Docling, PDF özellikleri arasında sayfa yerleşimini, okuma sırasını ve tablo yapısını, taranmış PDF'ler ve görüntüler için OCR desteğini ve hassas veriler ile internetten yalıtılmış (air-gapped) ortamlar için yerel çalıştırmayı sayar.

• Metin katmanı olan yerde onu okuyun, OCR'ı yalnızca olmadığı yerde kullanın; böylece temiz belgelere tanıma hataları bulaşmaz
• Her kelimenin sayfa numarasını ve sınırlayıcı kutusunu (bounding box) saklayın; böylece çıkarılan her alan daha sonra bir inceleyiciye geldiği sayfanın üzerinde gösterilebilir
• Tabloları tablo olarak koruyun: sütunları tek bir metin satırına düzleştirilmiş bir fatura, hangi tutarın hangi kaleme ait olduğu bilgisini kaybeder

Bunun yerine sayfa görüntüsünü bir görsel-dil modeli (vision-language model) okuyabilir: vLLM'in çok modlu girdilere ilişkin dokümantasyonu, görüntü girdisinin OpenAI Vision API'ye uygun olarak desteklendiğini belirtir. Hangisinin daha iyi çalıştığı sizin belgeleriniz üzerinde ölçülür; bunu yaparken ayrı bir OCR aşamasının kelime konumlarını ve güven değerlerini döndürdüğünü, bir görüntüyü okuyan modelin ise döndürmediğini akılda tutmak gerekir.

Şemayla kısıtlanmış çıktı: biçim zorlanır, içerik zorlanmaz

Her belge türü, kod gibi sürümlenen kendi çıktı şemasını alır. vLLM'in structured outputs dokümantasyonu beş tür kısıt listeler: choice, regex, bir JSON şeması, bağlamdan bağımsız bir dilbilgisi (context-free grammar) ve bir structural tag; backend'ler arasında xgrammar, guidance, outlines ve lm-format-enforcer bulunur ve varsayılan değer olan auto, isteğin ayrıntılarına göre uygun bir backend seçmeye çalışır.

• Her alan için “bulunamadı” değerini açık bir değer yapın; böylece eksik bir hasar tarihi tahmin edilmek yerine eksik olarak kaydedilir
• Başka bir sistemin üzerinde dallanacağı her şey için enum'lar kullanın: hasar türü, ticket kategorisi, belge türü, ülke kodu
• Her alana bir kaynak referansı, yani alındığı sayfayı ve kelimeleri ekleyin; böylece doğrulama ve inceleme, alanı belgeyle karşılaştırarak kontrol edebilir

Çıktıyı uygulama kodunda sıradan bir JSON Schema doğrulayıcısıyla yeniden doğrulayın. Backend'ler farklılık gösterir: aynı sayfa, xgrammar, guidance ve outlines'ın Rust tarzı düzenli ifadeler kullandığını, lm-format-enforcer'ın ise Python'un re modülünü kullandığını ve reasoning etkinleştirilmiş Qwen3 Coder modellerinde, reasoning içeriği ayrı bir alana ayrıştırılmazsa structured outputs'un devre dışı kalabileceğini not eder. Token limitine takılarak durdurulan bir çıktı üretimi de kaydın ortasında biter. İkinci kontrol ucuzdur.

Doğrulama: zaten var olan iş kuralları, kod olarak yazılmış hâliyle

Şemaya uyan bir kayıt yine de yanlış olabilir. Bunu yakalayan kontroller, back-office'in bugün elle uyguladığı kontrollerin belge türü başına kod olarak yazılmış hâlidir:

• Hasar talepleri: poliçe numarası poliçe sisteminde mevcuttur, hasar tarihi teminat süresinin içine düşer ve fatura kalemlerinin toplamı fatura tutarını verir
• Ticket'lar: müşteri tanımlayıcısı gerçek bir hesaba karşılık gelir ve adı geçen ürün müşterinin gerçekten sahip olduğu bir üründür
• KYC: makinece okunabilir bölgenin kontrol haneleri doğrudur, geçerlilik bitiş tarihi geçmemiştir ve makinece okunabilir bölgedeki ad ve doğum tarihi, görsel bölgeden okunan aynı alanlarla örtüşür

Kimlik belgeleri kendi doğrulayıcılarıyla gelir. Makinece okunabilir seyahat belgelerinin spesifikasyonu olan ICAO Doc 9303, makinece okunabilir bölgedeki kontrol hanelerini tanımlar: bunlar, sürekli tekrarlanan 7, 3, 1 ağırlıklandırmasıyla modül 10 üzerinden hesaplanır; A'dan Z'ye harfler 10 ile 35 arası, dolgu karakteri ise sıfır olarak sayılır. Belge, kontrol hanelerinin okuyucuların verilerin doğru yorumlandığını doğrulamasına olanak tanıdığını belirtir.

Yönlendirme: bir kişinin hangi alanları göreceğine kurallar ve sinyaller karar verir

Yönlendirme belge başına değil, alan başına belirlenir: diğer her şey geçerken fatura toplamı başarısız olan bir hasar talebi, dosyanın tamamını değil, tek bir alanı bir kişiye gönderir. Sinyaller:

• Herhangi bir doğrulayıcı hatası; şemanın zorunlu tuttuğu ve modelin bulunamadı olarak işaretlediği bir alan da buna dahildir
• Alanın oluşturulduğu kelimelerde düşük OCR güven değeri; eşik, değerlendirme seti üzerinde alan başına belirlenir
• Birbiriyle çelişen iki kaynak; örneğin aynı pasaportun makinece okunabilir bölgesi ile görsel bölgesi
• Alınmış bir kararla hiçbir zaman otomatikleştirilmeyen alanlar; örneğin belirlenmiş bir limitin üzerindeki talep tutarı
• Her şeyi geçmiş alanlardan rastgele bir örneklem; böylece kimsenin işaretlemediği hataların oranı varsayılmak yerine ölçülür

Modelin kendi kesinlik beyanı bilerek dışarıda bırakılır; bu blogdaki önceki bir yazı bunun neden zayıf bir kapı olduğunu açıklar.

İnceleme ekranı, önerilen değerin yanında, atıf yapılan kelimeleri vurgulanmış hâlde sayfayı gösterir; böylece inceleyici yeniden okumak yerine kontrol eder. Her düzeltme alan başına eski değer, yeni değer, inceleyici ve kısa bir listeden seçilen bir gerekçeyle saklanır. İkinci bir kişi onayladığında düzeltme değerlendirme setine katılır, ancak sürüm kararlarının verildiği dondurulmuş kısma asla katılmaz.

Tek bir genel puan değil, belge türü ve alan başına değerlendirme

Pipeline için tek bir doğruluk rakamı, önemli olan sonucu gizler; örneğin diğer tüm alanlar geçerken bir ülkenin kimlik kartlarında geçerlilik bitiş tarihlerinin başarısız olması. Yönlendirmenin kullandığı eksenler boyunca ölçün:

• Alan başına: normalizasyondan sonra tam eşleşme ve bunun yanında ayrıca, belge alanı içerdiğinde ya da içermediğinde alanın ne sıklıkla atlandığı ya da uydurulduğu
• Belge türü ve girdi türü başına, örneğin dijital PDF, tarama ve telefon fotoğrafı; çünkü her birinin kendine özgü bir hata örüntüsü vardır
• Yol başına: otomatikleştirilen alanların payı ve bunlardan alınan örneklemdeki hata oranı
• Maliyete göre ağırlıklandırılmış: yanlış bir banka hesap numarası ile yanlış yazılmış bir sokak adı aynı hata değildir

Yeni bir model, prompt, şema, OCR sürümü ya da doğrulayıcı olsun, her sürüm canlıya çıkmadan önce dondurulmuş set üzerinde puanlanır ve kapı alan başınadır: ortalama yükselse bile hiçbir belge türündeki hiçbir alan kendi geçme eşiğinin altına düşmez. İlk etiketli setin oluşturulması, üretime hiç ulaşamayan pilotlar hakkındaki önceki yazıda ele alınıyor.

Denetim izi: hangi alanı hangi model ve prompt üretti

İtiraz edilen bir hasar talebi ya da bir denetçinin kabul edilmiş bir kimlik hakkındaki sorusu, tek bir belgedeki tek bir alanla ilgilidir. Bunu yanıtlayan kayıt, pipeline çalışırken, alan başına bir girdi olarak, yalnızca ekleme yapılabilen (append-only) bir depoya yazılır:

• Belge kimliği ve içerik hash'i, alanın atıfta bulunduğu sayfa ve kelimeler
• OCR ya da yerleşim motorunun sürümü ve bu kelimeler için güven değeri
• Model adı ve ağırlıkların sağlama toplamı (checksum), prompt şablonunun sürümü ve şema sürümü
• Her doğrulayıcının sonucu, izlenen yol ve bunun nedeni
• Değeri bir kişi değiştirdiyse inceleyici, önceki ve sonraki değer ve zaman

AB Yapay Zekâ Yasası (EU AI Act), yüksek riskli saydığı sistemler için bir kayıt tutma gereksinimi getirir: Madde 12(1), yüksek riskli yapay zekâ sistemlerinin, sistemin kullanım ömrü boyunca olayların (logların) otomatik olarak kaydedilmesine teknik olarak olanak tanıması gerektiğini belirtir. Ek III yüksek riskli kullanımları listeler; bunlar arasında finansal dolandırıcılığın tespiti hariç olmak üzere gerçek kişilerin kredi değerliliğinin değerlendirilmesi ile hayat ve sağlık sigortasında risk değerlendirmesi ve fiyatlandırma yer alır. Madde 6(3), listelenmiş bir sistemin hangi durumlarda yine de yüksek riskli sayılmadığını belirler; örneğin dar kapsamlı bir usul görevini yerine getirdiğinde. Belirli bir pipeline'ın kapsama girip girmediği, müşterinin hukuk ekibinin yanıtlayacağı bir sorudur; çalışma anında yazılan alan başına bir kayıt her iki durumda da işe yarar.

Kişisel veriler: her aşama yalnızca görevinin gerektirdiğini görür

Bir pipeline, kişisel verileri asıl klasörden daha fazla yere kopyalar. GDPR Madde 5(1)(c), kişisel verilerin işlendikleri amaçlarla bağlantılı olarak yeterli, ilgili ve gerekli olanla sınırlı olmasını şart koşar (veri minimizasyonu). Madde 25(2), varsayılan olarak yalnızca her bir belirli amaç için gerekli olan kişisel verilerin işlenmesini sağlayan tedbirler ister ve bunu toplanan verilerin miktarına, işlemenin kapsamına, saklama süresine ve erişilebilirliğe uygular. Pipeline açısından:

• Model, dosyanın tamamını değil, şemasının ihtiyaç duyduğu sayfaları alır
• İnceleyiciler kendi kuyruklarındaki alanları görür; tam belgelere erişim role göre verilir ve loglanır
• Uygulama logları belge kimliklerini, alan adlarını ve sonuçları kaydeder; alan değerlerini ya da prompt'ları kaydetmez
• Hata ayıklama için saklandıkları durumlarda prompt ve çıktı trace'leri, belgelerle aynı kısıtlı erişimli depoda, kendilerine ait kısa bir saklama süresiyle tutulur
• Değerlendirme seti gerçek belgelerin bir kopyasıdır ve aynı erişim kontrollerine tabidir

OWASP Logging Cheat Sheet, hassas kişisel verileri ve sağlık verileri ile devlet tarafından verilen kimlik numaraları gibi bazı kişisel tanımlayıcı bilgi türlerini, genellikle doğrudan loglara kaydedilmemesi gereken veriler arasında sayar ve bu tür verilerin bunun yerine kaldırılması, maskelenmesi, temizlenmesi, hash'lenmesi ya da şifrelenmesi gerektiğini söyler.

Saklama belge türüne göre değişir ve AB'de KYC için kara para aklamayla mücadele mevzuatıyla belirlenir. 10 Temmuz 2027'den itibaren uygulanan (AB) 2024/1624 sayılı Tüzük'ün 77. maddesi, yükümlü kuruluşların müşteri durum tespiti kapsamında elde edilen belge ve bilgilerin bir kopyasını saklamasını ve bu kayıtların karartılmamasını sağlamasını şart koşar. Madde, iş ilişkisinin sona ermesinden ya da arızi bir işlemin tarihinden itibaren hesaplanan beş yıllık bir saklama süresi belirler; bu sürenin sonunda, aynı maddedeki istisnalar saklı kalmak kaydıyla kişisel verilerin silinmesi gerekir. Asıl KYC kaydı, kayıt sisteminde (system of record) eksiksiz kalır; pipeline'ın trace'lerden inceleme anlık görüntülerine kadar kendi kopyaları ise en aza indirilir ve kendine ait daha kısa bir takvime göre silinir.

Throughput: ani yük için bir kuyruk, olağan yük için kapasite

Back-office hacmi düzensizdir: tek bir olay aynı anda çok sayıda poliçe sahibini etkileyebilir ve bir kesinti ticket kuyruğunu doldurur. Kuyruklar, backpressure ve manuel fallback, pilotlar hakkındaki önceki yazıda ele alındı; kendi barındırdığınız bir belge pipeline'ına özgü olanlar şunlardır:

• Kuyrukları aciliyete göre ayırın: bir müşterinin onboarding sırasında beklediği bir KYC kontrolü, geçmişe ait bir hasar talebi yığınının arkasında sıra beklemez
• CPU üzerindeki OCR worker'larını ve hızlandırıcılar üzerindeki model sunucularını birbirinden bağımsız ölçeklendirin; çünkü farklı hacimlerde doygunluğa ulaşırlar
• Serving motorunun kendi kuyruğunu izleyin: vLLM, /metrics endpoint'inde, işlenmeyi bekleyen isteklerin sayısı ve kullanımdaki key-value cache bloklarının oranı dahil Prometheus metrikleri sunar
• Worker'ları CPU yüküne göre değil, kuyruk derinliğine göre ölçeklendirin; KEDA'nın dokümantasyonu, Kubernetes'teki herhangi bir container'ın işlenmeyi bekleyen olay sayısına göre ölçeklendirilmesini, diğerlerinin yanı sıra mesajlaşma sistemleri için scaler'larla ve sıfıra ölçeklemeyle (scale-to-zero) birlikte anlatır

Kendi altyapınızdaki hızlandırıcı kapasitesi kısa vadede sabittir; bu yüzden kuyrukların hangi sırayla geri çekileceğine ani yük sırasında değil, önceden karar verilir.

Hasar talepleri, ticket'lar ve KYC: aynı iskelet, farklı kurallar

• Hasar talepleri: dosya başına çok sayıda belge, faturalarda tablolar ve çoğu zaman sağlık verisi; GDPR Madde 9 sağlık verisini, aynı maddedeki bir istisna uygulanmadıkça işlenmesi yasak olan özel nitelikli kategoriler arasında sayar. Madde 22, bir kişiye, hakkında hukuki sonuç doğuran ya da onu benzer şekilde önemli ölçüde etkileyen, yalnızca otomatik işlemeye dayalı bir karara tabi olmama hakkını tanır; istisnalar Madde 22(2)'de yer alır. Bu nedenle pipeline'ın yalnızca çıkarım ve kontrol yapıp kararı bir hasar uzmanının vermesi, bir mühendislik varsayılanı değil, müşterinin veri koruma görevlisiyle birlikte alınan bir tasarım kararıdır
• Ticket'lar: kısa metinler, yüksek hacim ve yanıt bekleyen biri; bu yüzden gecikme daha önemlidir; çıktı çoğunlukla bir kategori, bir öncelik ve birkaç tanımlayıcıdır. Ticket metni şirket dışındaki kişiler tarafından yazılır ve model için güvenilmeyen girdidir; bu risk pilotlar hakkındaki önceki yazıda ele alındı
• KYC: pasaportlar ve kimlik kartları gibi katı formatlara sahip az sayıda belge türü; bu da kural tabanlı doğrulamayı güçlü kılar. Belgedeki fotoğrafla eşleştirilen bir selfie biyometrik veri ekler; GDPR Madde 9, bir kişiyi benzersiz şekilde tanımlamak amacıyla işlendiğinde bu veriyi de özel nitelikli bir kategori olarak sayar. Saklama, kara para aklamayla mücadele mevzuatına tabidir ve sonuç, bir kişinin ya da belgelenmiş bir kuralın verdiği bir uyum kararına girdi olur

Belgeleri harici bir model sağlayıcısından uzak tutmak, modelin nerede çalıştığıyla belirlenir. Pipeline'a bu belgelerin emanet edilip edilemeyeceğini ise modelin etrafındaki her şey belirler: şema, kurallar, inceleme kuyruğu ve her alanı kimin ürettiğinin kaydı.

Bunu sizin kendi altyapınızın içinde hangi mühendislik şirketleri kurar?

Bu sorunun üç tür yanıtı vardır ve her biri farklı bir şey satar. Belge işleme tedarikçileri, bazen şirket içine (on-premises) kurulabilen ve sizin belgelerinize göre yapılandırdığınız bir platform satar. Bulut sağlayıcıları kendi altyapılarında çalışan yönetilen servisler satar. Mühendislik firmaları ise pipeline'ı sizin ortamınızda açık bileşenlerden ve sizin kurallarınızla kurar.

Hangi türle görüşürseniz görüşün, bir ekibin bunu daha önce kurup kurmadığını şu sorular gösterir:

• Hangi aşamalar, OCR, izleme, hata takibi ve etiketleme aracı dahil, ağınızın dışındaki herhangi bir servisi çağırıyor?
• Belge türlerinizden biri için çıktı şeması neye benziyor ve “bulunamadı” nasıl temsil ediliyor?
• Hangi sinyaller bir alanı incelemeye gönderir ve eşikler nasıl seçildi?
• İnceleyici düzeltmeleri, sürüm kararları için kullanılan kısmı kirletmeden değerlendirme setine nasıl ulaşır?
• Tek bir belgedeki tek bir alan için, değerini üreten modeli, prompt'u, şemayı ve inceleyiciyi gösterebiliyorlar mı?
• İş bittiğinde pipeline kodunun, şemaların ve değerlendirme setinin sahibi kimdir ve hangi parçalar tedarikçinin yeniden kullanılabilir bileşenleri olarak kalır?

Birinci ve beşinci soruda genel kalan bir yanıt, veri yolunun ve denetim izinin henüz tasarlanmadığı anlamına gelir.

amBrain'in bu alandaki kendi çalışması hakkında söyleyebilecekleri

amBrain'in yukarıdaki özette anlatılan üretim entegrasyonunun ötesinde kamuya kanıtlayabildikleri: amBrain 2019'dan beri yazılım geliştiriyor. Üç formatta çalışıyoruz: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.

Bu yazı böyle bir pipeline'ın nasıl çalıştığını anlatır; bir vaka çalışması değildir, hiçbir müşterinin adını vermez ve amBrain'in bir hasar, ticket ya da KYC sistemi kurduğunu iddia etmez. Yukarıda adı geçen üretim çalışması, bir trading sistemi için broker ve işlem yeri bildirimlerinin çıkarımıdır.

Dolayısıyla ilk adım bir model seçmek değildir. İlk adım, herhangi bir belge pipeline'a ulaşmadan önce, tek bir belge türü için şemayı, onu kontrol eden kuralları ve bir kişinin her zaman görmesi gereken alanları yazıya dökmektir.