Yazı
On-Premises Doküman Operasyonları İçin SLM Cascade Tasarımı
Küçük dil modellerini aşamalı bir doküman işleme hattında birleştirerek gecikmeyi ve GPU yükünü nasıl azaltabileceğinizi anlatıyoruz.
Doküman İşleri, SLM Kullanmak İçin Neden En Doğru Başlangıç Alanlarından Biri
Birçok kurum içi yapay zeka girişimi büyük bir genel modelle başlar çünkü demoda etkileyici görünür. Sonra ilk gerçek iş akışı gelir: tedarikçi sözleşmeleri, bakım raporları, kalite kayıtları, faturalar ya da IK formları. O noktada problem açık uçlu reasoning olmaktan çıkar ve yüksek hacimli, tekrar eden doküman operasyonu haline gelir. Tam da burada küçük dil modelleri ve kompakt görev modelleri, tek bir büyük modele dayalı stratejiden daha iyi operasyonel sonuçlar verebilir. Girdi yapıları tekrarlıdır, çıktılar sınırlandırılabilir ve iş değeri geniş yaratıcı kapasiteden çok throughput, tutarlılık ve doğru escalation disipliniyle oluşur.
Cascade yaklaşımı bu gerçeği avantaja çevirir. Her sayfayı sahip olduğunuz en büyük modele göndermek yerine akışı parçalara ayırır ve her parçayı o işi güvenilir şekilde yapabilen en küçük bileşene verir. OCR metni çıkarır. Hafif bir classifier doküman tipini belirler. Küçük bir dil modeli yapısal alanları çıkarır veya belirli bir bölümü özetler. Kurallar ve schema validator'lar açık hataları yakalar. Sadece belirsiz vakalar daha büyük bir modele veya insan incelemesine eskale edilir. Bu yapı genellikle daha iyi kuyruk davranışı, daha düşük gecikme ve paylaşımlı altyapıda çok daha az GPU baskısı yaratır.
Cascade Yapısı Departmanlara Göre Değil, İş Aşamalarına Göre Kurulmalı
En etkili doküman hatları sıralı karar adımları olarak tasarlanır. Pratik bir desen beş aşamadan oluşur. İlk olarak preprocessing katmanı taramaları normalize eder, dili tespit eder, boş sayfaları ayıklar ve Tesseract, PaddleOCR ya da kurum tarafından onaylı farklı bir OCR motoruyla metni çıkarır. İkinci olarak hafif bir classifier, girdinin fatura, servis raporu, güvenlik prosedürü ya da tanımsız bir belge olup olmadığını belirler. Üçüncü adımda bir SLM, sabit bir schema kullanarak alan çıkarma veya yapısal özet üretir. Dördüncü adımda iş kuralları sonucu kontrol eder. Beşinci adımda ise sadece düşük güvenli veya yüksek riskli belgeler daha büyük modele ya da insan incelemesine gider.
Bu aşama tabanlı tasarım önemlidir çünkü ekibin tek bir modele OCR temizleme, anlamsal yorumlama, politika kontrolü ve nihai taslak üretme görevlerini aynı anda yaptırmasını engeller. Her şeyi tek prompt'a sığdırdığınızda teşhis zorlaşır. Extraction başarısız olduğunda sorun düşük tarama kalitesinden mi, yanlış classification'dan mı, eksik bağlamdan mı, yoksa çıktı formatındaki halüsinasyondan mı kaynaklanıyor, anlamak zorlaşır. Cascade, hata durumlarını görünür hale getirir. İyileştirme de zaten bu görünürlük sayesinde mümkün olur.
Bu desen on-prem altyapı kısıtlarıyla da uyumludur. Classification ve extraction adımları, llama.cpp, vLLM veya Text Generation Inference gibi serving araçlarıyla CPU dostu modellerde ya da daha küçük GPU'larda çalışabilir. Büyük reasoning modeli ise sürekli yük taşıyan varsayılan katman olmak yerine istisna yönetimi için ayrılır.
Production'da Dayanacak Bir Referans Mimari
Pek çok kurum için sağlam bir production deseni şu şekildedir: dokümanlar bir message bus veya güvenli dosya kabul servisi üzerinden sisteme girer, metadata bir iş kuyruğuna yazılır ve orijinal dosya dahili bir object store'da saklanır. Preprocessing worker'ı sayfa görüntüleri ve OCR çıktısı üretir. Classifier workflow tipini ve güven puanını verir. Bu puan, hangi extraction prompt'unun ve hangi schema'nın kullanılacağını belirler. SLM, serbest metin yerine JSON döner ve bu JSON kayıt altına alınmadan önce validate edilir. Validation başarısız olursa aynı iş fallback prompt ile tekrar denenir ya da eskale edilir.
Destekleyici bileşenler burada beklenenden daha kritik hale gelir. Schema validator, downstream sistemlerin hatalı biçimde gelen veriyi kabul etmesini engeller. Prompt registry, extraction talimatlarını uygulama koduna gömmek yerine versioned şekilde yönetir. Gerektiğinde retrieval katmanı müşteriye özel terimler, onaylı field tanımları veya sözleşme madde katalogları sağlayabilir; ancak retrieval dar kapsamlı kalmalıdır. Doküman operasyonlarında geniş retrieval genellikle fayda değil zarar getirir çünkü prompt gürültüsünü artırır. Burada hacim değil hassasiyet kazanır.
Başka bir önemli nokta da şu: sayfa düzenini daha önceki aşamalarda koruyabiliyorsanız, SLM'e bütün layout'u baştan kurdurmayın. Table detector, key-value eşleştirme ve page segmentation gibi adımlar, model büyütmekten daha fazla kalite kazancı sağlayabilir. Birçok fatura ya da bakım senaryosunda asıl sıçrama, daha pahalı modele geçmekten değil preprocessing ve schema tasarımını iyileştirmekten gelir.
Kalitenin Asıl Belirleyicisi Escalation Mantığıdır
Bir cascade yapısının başarısı escalation politikasına bağlıdır. Eşik çok düşükse büyük model fiilen varsayılan hale gelir ve ekonomik denge bozulur. Eşik çok yüksekse düşük kaliteli extraction sonuçları operasyonel sistemlere sızar. İyi politikalar tek başına model confidence skoruna güvenmez; doküman tipi kesinliği, field doluluğu, schema validation sonuçları, bilinen şablonlara benzerlik ve iş kritiklik seviyesi birlikte değerlendirilir. İçine birim fiyat yazılmamış bir dahili not belki önemsiz olabilir. Ama ilaç doz bilgisi eksik bir sağlık dokümanı aynı şekilde ele alınamaz.
Güçlü bir desen, escalation'ı anlamsal belirsizlik ve süreç riski olarak ikiye ayırmaktır. Anlamsal belirsizlik, modelin dokümanın ne anlattığından emin olmamasıdır. Süreç riski ise içerik anlaşılır olsa bile downstream etkisinin hassas olmasıdır. Bu ayrım önemlidir çünkü bazen model kendinden emin görünse bile belge yine de eskale edilmelidir. Sorumluluk değiştiren sözleşme maddeleri, ödeme blokajı doğurabilecek tedarik koşulları veya regüle üretimi etkileyen kalite sapmaları daha sıkı inceleme ister.
İnsan incelemesini de mimarinin resmi bir parçası olarak tasarlamak gerekir. İnceleme ekranları orijinal snippet'ı, çıkarılan alanları, güven göstergelerini ve neden eskale edildiğini göstermelidir. Bu geri bildirim; prompt tuning, daha iyi doküman şablonları veya classifier için retraining verisi üretilmesinde doğrudan kullanılabilir.
Yalnızca Doğruluğu Değil, Düz Akış Oranını Ölçün
Ekiplerin çoğu extraction accuracy ölçer ve orada durur. Bu yeterli değildir. Doküman operasyonlarında daha anlamlı operasyonel metrikler; straight-through processing oranı, reviewer correction rate, ortalama ele alma süresi, bin doküman başına GPU dakikası ve belge türüne göre escalation dağılımıdır. Bu metrikler cascade'in gerçekten iş yükünü azaltıp azaltmadığını gösterir. Yüzde 96 doğru çalışan ama belgelerin yarısını insan incelemesine gönderen bir hat, büyük ölçekte hala pahalı olabilir.
Kaçınılması gereken birkaç hata da tekrar tekrar karşımıza çıkar. İlki, tarama kalitesini iyileştirmeden modelin bunu telafi etmesini beklemektir. İkincisi, downstream sistemler yapısal veri isterken serbest metin çıktı kabul etmektir. Üçüncüsü, çok farklı belge ailelerini tek bir genel prompt içine sıkıştırmaktır. Dördüncüsü ise prompt, validator ve extraction schema'larını version control dışında bırakmaktır. Production'da bunlar da kod kadar sistemin parçasıdır ve aynı disiplinle yönetilmelidir.
Düzgün tasarlanmış bir SLM cascade yetersiz bir taviz değildir. Aksine, on-prem doküman operasyonları için en pratik mimarilerden biridir çünkü hesaplama maliyetini görev karmaşıklığıyla eşleştirir. Kazanç, küçük modelin her yerde büyük modeli değiştirmesi değildir. Kazanç, büyük modelin yalnızca gerçek belirsizlik olduğunda devreye girmesidir.