Belge Kabulünden Saklamaya Akıllı Belge İşleme Hattı Tasarlamak

Bir çıkarım modeli istenen alanların tamamını doğru okuyabilir; buna rağmen aynı belge iki kez işlenebilir, sonuç yanlış kuyruğa gidebilir veya hedef sistem çıktıyı almadan süreç tamamlandı görünebilir. Böyle bir durumda model başarılı, belge hizmeti başarısızdır. Üretimde güvenilir bir akıllı belge işleme hattı, yalnızca metin ve alan çıkarmakla yetinmez. Belgenin kabulünden hazırlığa, sınıflandırmadan doğrulamaya, insan incelemesinden teslim teyidi ve saklamaya kadar her devri izlenebilir bir sözleşmeye bağlar.

Belge araçları dizisini işletilebilir bir hatta dönüştüren nedir?

İşletilebilirlik, her mantıksal aşamayı açık bir sözleşmeyle tanımlamaktan gelir. Kabul, ön işleme, sınıflandırma, çıkarım, doğrulama, yönlendirme, insan incelemesi ve saklama ayrı ürünler olmak zorunda değildir; ancak girdileri, çıktıları ve kontrol noktaları görünür kalmalıdır. Microsoft’un referans mimarisi kabulden OCR, doğrulama, inceleme, saklama ve izlemeye uzanan bir yaşam döngüsü gösterirken AWS örneği zaman aşımı, desteklenmeyen dosya ve doğrulama hatalarını ayrı orkestrasyon sonuçları olarak ele alır.

Kabul anında oluşturulan sabit belge kimliği bu sözleşmelerin omurgasıdır. Korunan asıl nüsha, gerekli türevler, kullanılan işlemci ve kural sürümleri, doğrulama sonuçları, karar geçmişi ve son çıktı aynı kimliğe bağlanır. Böylece operatör yalnızca belgenin nerede olduğunu değil, hangi dönüşümden geçtiğini, neden beklediğini ve hangi durumdan güvenli biçimde devam edebileceğini de görebilir. Saklanacak ayrıntı düzeyi ise onaylı kayıt ve erişim kurallarına göre sınırlandırılır.

Bu matris bir çözüm şeması kadar bir toplantı aracıdır. Hücreleri operasyon, güvenlik, iş kuralı, kayıt ve entegrasyon sahipleriyle birlikte doldurmak; isimsiz kuyrukları, geri döndürülemeyen dönüşümleri ve teyitsiz teslimleri ürün seçilmeden önce görünür kılar. Bir aşama teknik olarak başka bir aşamayla birleşse bile kalıcı çıktısı ve hata rotası kaybolmamalıdır. Özellikle boş bırakılan sorumlu, yeniden başlatma durumu veya teslim teyidi hücresi, üretimde oluşacak sahiplik ve kurtarma açığının erken işaretidir.

Belgeler asıl kanıt kaybedilmeden nasıl kabul edilip hazırlanır?

Belgeler yalnızca yetkili kanallardan alınmalı ve ilk dönüşümden önce alınan asıl kopya korunmalıdır. Kabul kaydı sabit kimliği, alındı bilgisini, kaynak üstverisini, işleme amacını, yinelenen gönderim durumunu ve başlangıç hâlini taşımalıdır. OWASP’ın genel dosya yükleme rehberi izin verilen biçimler, tür ve imza kontrolü, boyut ile açılmış arşiv sınırları, ayrılmış depolama ve uygun içerik taraması gibi katmanları önerir; kullanıcı tarafından bildirilen içerik türü tek başına güvenilir sayılmaz.

Ön işleme, asıl belgeyi değiştirmek yerine yeniden üretilebilir bir çalışma paketi üretmelidir. Bu paket normalleştirilmiş sayfaları, varsa yerel PDF metnini, OCR metnini, okuma sırasını, yerleşimi, sayfa kökenini, uygulanan dönüşümleri ve kalite bulgularını içerir. Google’ın belgelediği döndürme düzeltmesi, bulanıklık, karanlık, kesilmiş içerik ve parlama gibi sinyaller bu pakete örnektir. Ancak kalite analizi yanlış pozitif üretebildiğinden tek başına kesin ret veya kabul kararı değildir.

• Yetkisiz veya desteklenmeyen girdiyi gerekçeli bir alındı kaydıyla reddedin.
• Şüpheli içeriği normal işleme alanından ayrılmış bir karantina rotasına gönderin.
• Yinelenen gönderimi belge kimliği ve tanımlı tekrar politikasıyla işaretleyin.
• Sayfa sırası, dil, parola koruması ve okunabilirlik bulgularını kayıt altına alın.
• Alternatif dönüşüm denemelerini sınırlayın ve kullanılan sürümü kaydedin.
• Kesilmiş veya hiç yakalanmamış içerik için sessiz onarım yerine yeniden edinme isteyin.

Döndürme ya da görüntü iyileştirme makine okunabilirliğini artırabilir, fakat taramada hiç yakalanmamış bir satırı yeniden oluşturamaz. Bu nedenle eksik sayfa, kesilmiş alan veya belirsiz paket sırası otomatik tahminle kapatılmamalıdır. Belgenin yeniden istenmesi mümkün değilse açık bir istisna durumu oluşturulmalı, sonraki aşamalara hangi kanıtın eksik olduğu taşınmalıdır. Böylece çıkarım modeli görünüşte makul bir değer ürettiğinde bile kaynak kusuru doğrulama ve inceleme sırasında görünür kalır.

Sınıflandırma, çıkarım ve doğrulama neden ayrı tutulmalıdır?

Bu üç aşama farklı sorulara cevap verdiği için mantıksal olarak ayrı tutulmalıdır: sınıflandırma belgenin ne olduğunu, çıkarım hangi değerlerin bulunduğunu, doğrulama ise aday çıktının ilan edilmiş kurallara uyup uymadığını belirler. Microsoft, karma paketlerdeki belge türlerini uygun çıkarım modelinden önce belirleyebilen sınıflandırıcıları belgeler. Çıktı; sınıfı, paket veya sayfa sınırlarını, taksonomi sürümünü, mevcutsa güveni ve bir sonraki aşamada kullanılacak şemayı açıkça göstermelidir.

Bilinmeyen, belirsiz veya karma sınıf, en yakın bilinen şemaya zorlanmamalıdır; adlandırılmış bir yeniden sınıflandırma ya da paket inceleme rotasına gitmelidir. Çıkarım sözleşmesi ise ham metni normalleştirilmiş değerden ayırmalı, veri türünü, tabloları, varlıkları, eksik alanları, işlemci sürümünü ve mevcutsa güven değerini saklamalıdır. Okuma sırası, tablo ilişkileri ve sayfa koordinatları gibi köken bilgileri, hem otomatik kontrolün hem de inceleyicinin aday değeri belgeye geri izlemesini kolaylaştırır.

• Zorunlu alan kontrolü, değerin bulunup bulunmadığını sınar.
• Tür ve biçim kontrolü, adayın ilan edilmiş şemaya uyumunu sınar.
• Aralık kontrolü, tanımlı iş sınırlarının dışındaki değerleri işaretler.
• Alanlar arası kontrol, aynı kayıttaki ilişkileri karşılaştırır.
• Belgeler arası kontrol, aynı paket içindeki tutarlılığı değerlendirir.
• Referans ve yinelenme kontrolü, sürümlü dış veriyle veya önceki kayıtla karşılaştırır.

AWS’nin IDP örneği çıkarımı bu tür doğrulama kurallarından ayırır. Yine de kuralları geçmek, belgenin gerçekliğini veya bir iddianın maddi doğruluğunu kanıtlamaz. Model güveni de doğrulamanın yerine geçmez; yalnızca rota politikasındaki sinyallerden biridir. Google, eşik yükseldiğinde kesinliğin genel olarak artarken duyarlılığın düşebileceğini açıklar. Bu nedenle otomatik geçiş ve inceleme eşikleri belge sınıfı, alanın kullanım sonucu ve temsilî etiketli örneklerde görülen hatalar dikkate alınarak belirlenmelidir; evrensel bir sayı yoktur.

Bir belge hattı, en az açık tanımlanmış devri kadar güvenilirdir.

Başarılı, hatalı ve belirsiz sonuçların tümü nasıl yönlendirilir?

Her sonuç, tek bir genel hata kuyruğu yerine anlamlı ve adlandırılmış bir duruma yönlendirilmelidir. AWS mimari örnekleri başarılı işlem, doğrulama hatası, zaman aşımı ve desteklenmeyen dosya gibi sonuçları ayırır; insan inceleme örneği ise güven veya iş kuralı koşulları başarısız olduğunda adayı ayrı göreve taşır. Yerel durum modeli otomatik teslimi, sınırlı yeniden denemeyi, yeniden edinmeyi, karantinayı, uzman işlemini, insan incelemesini ve terminal istisnayı gerektiği ölçüde birbirinden ayırabilir.

• Mevcut durum ve önceki durum geçişini kaydedin.
• Rota gerekçesini ve önceliği operatörün anlayacağı biçimde taşıyın.
• Deneme sayısını ve izin verilen yeniden deneme sınırını görünür tutun.
• Hedef sistemi veya kuyruğu açıkça adlandırın.
• Teslimden beklenen teyidi ve zaman aşımı sonucunu tanımlayın.
• Kuyruk sahibini, yaşını ve çözülemeyen işler için eskalasyonu izleyin.
• Yinelenen teslimi önlemek için aynı belge ve eylemi ayırt edilebilir kılın.

İnceleme paketi, karar vermeye yetecek fakat belgenin hassasiyeti bakımından gereksiz olmayan bağlam sunmalıdır. Asıl sayfa, aday değer, kaynak konumu, başarısız kontroller, ilgili güven sinyalleri, işlem geçmişi ve inceleyicinin izin verilen eylemleri birlikte gösterilmelidir. Kaynak koordinatları ile doğrulama geçmişinin korunması bu doğrulamayı destekler. Ancak bir insan dalı tek başına güvence değildir: kuyruk sahibi, kapasite, hedef yanıt süresi ve geciken ya da çözülemeyen işler için eskalasyon yolu bulunmalıdır.

Düzeltme sonrasında inceleyici kimliği, zaman, gerekçe, makine tarafından önerilen önceki değer, kabul edilen yeni değer ve iş akışına yeniden katılım sonucu korunmalıdır. Bu kayıt denetim ve iyileştirme için değerlidir; yine de her insan düzeltmesi otomatik olarak onaylanmış eğitim verisine dönüştürülmemelidir. Son aşamada hedef sistem kabul edilen çıktıyı teyit etmelidir. Teyit gelmezse belge tamamlandı sayılmamalı, teslim hatası adıyla kaydedilmeli ve belirlenen yeniden deneme ya da eskalasyon yoluna girmelidir.

Çıkarım ve inceleme bittikten sonra hat nasıl denetimli kalır?

Hat, son çıktıyı gönderdikten sonra da varlıkları onaylı bilgi yaşam döngüsüne alarak denetimli kalır. Asıl belge, normalleştirilmiş türevler, çıkarılan yapılandırılmış veri, inceleme kayıtları ve operasyon günlükleri aynı şey değildir; üstverileri, erişim ihtiyaçları ve tasfiye sonuçları ayrı tanımlanmalıdır. NARA’nın ABD federal gereksinimleri yakalama, bakım ve kullanım, aktarım, imha, üstveri ve raporlama gibi yararlı planlama kategorileri sunar, ancak Türkiye’deki özel kuruluşlar için bağlayıcı veya evrensel kurallar değildir.

• Her varlık türü için kayıt, gizlilik, güvenlik ve iş sahibini belirleyin.
• Erişim yetkisini ve bütünlük beklentisini belge sınıfına göre tanımlayın.
• Bekletme, aktarım ve yetkili tasfiye durumlarını ayrı sonuçlar olarak kaydedin.
• Silme gerekiyorsa yetkilendirmeyi ve gerçekleşen tasfiye kanıtını koruyun.
• Eksik veya çelişkili politika için sessiz süresiz saklama yerine eskalasyon açın.
• Tek bir evrensel saklama süresi veya varsayılanı bütün belge sınıflarına uygulamayın.

Operasyon görünümü belge sınıfı ve hat sürümüne göre hacmi, mevcut durumu, gecikmeyi, hata gerekçelerini, inceleme kuyruğu yaşını, düzeltme örüntülerini ve hedef teslim sonuçlarını göstermelidir. Google işlenen belge ve sayfa sayıları, durum ve gecikme izlemesini; Microsoft ise işlem performansı ile geri bildirim örüntülerini örnekler. Sayıların tek başına yeterli olmadığı unutulmamalıdır: başarısızlık dağılımındaki değişim, kuyrukların yaşlanması veya belirli bir sürümde artan düzeltmeler sahipli bir inceleme ve müdahale sürecine bağlanmalıdır.

Taksonomi, sayfa dönüşümü, model, şema, iş kuralı ve eşik değişiklikleri sürümlenmeli; üretime geçmeden önce ilgili belge nüfusunu temsil eden örneklerde değerlendirilmelidir. NIST AI RMF, belirli bir IDP uygulaması tarif etmese de yaşam döngüsü boyunca belgelenmiş roller, test, sürekli izleme ve risk takibini destekler. Hazırlık toplantısını şu soruyla bitirin: Her aşamanın sahibi, kabul edilen girdisi, kalıcı çıktısı, ilerleme kontrolü, hata rotası, ölçülebilir hizmet hedefi ve geri kazanılabilir durumu gerçekten tanımlı mı?

Matristeki boşlukları hizmet veya model seçmeden önce kapatın. Kabul ve erişim tasarımına güvenlik sorumlularını; saklama kararlarına kayıt, gizlilik ve bilgi sahiplerini; yetki alanına veya sonuç riskine bağlı gereksinimlere ise uygun hukuk ve düzenlenmiş alan uzmanlarını dâhil edin. Hukuki, klinik, kredi, sigorta, vergi ve benzeri yüksek sonuçlu yargılar yetkili insan sorumluluğunda kalmalıdır. Otomatik doğrulama veya insan kuyruğu, altta yatan karar riskini ortadan kaldırmaz.