Üretime Hiç Ulaşamayan Yapay Zekâ Pilotu: Veride ve Operasyonda Eksik Kalanlar

Pilot çalıştı. Elle seçilmiş bir belge setinde model alanları çıkardı, ticket'ları sınıflandırdı ve onu talep eden kişileri ikna etti. Aylar sonra hâlâ örnek veriyle bir sandbox'ta çalışıyor ve gerçek kuyruk için devreye alınmasının neler gerektireceğini kimse söyleyemiyor.

Bu boşluk modeli değiştirerek kapanmaz. Demo, bir modelin bir belgeyi okuyup okuyamadığını yanıtlar. Üretim ise taranmış belge, iletilmiş yazışma ve modelin yanlış işlediği belge dahil her belgeye ne olacağını sorar; üstelik pilotun kullandığı servise ulaşmasına hiç izin verilmemiş olabilecek veriler üzerinde.

Demo, modelin okuyabildiğini kanıtlar; üretim ise her belgeyi sorar

2015'te Google'daki Sculley ve meslektaşları, gerçek dünyadaki makine öğrenmesi sistemlerinin yalnızca küçük bir bölümünün makine öğrenmesi kodundan oluştuğunu ve etrafında gereken altyapının çok geniş ve karmaşık olduğunu yazdı. Bir dil modeli pipeline'ı da aynı biçimdedir ve yalnızca o küçük parçadan kurulmuş bir pilotun etrafında, onu üretimde çalıştıracak hiçbir şey yoktur.

Pilotun elinde olanı üretim kuyruğunun ihtiyaç duyduğunun yanına koyun; eksik iş bir listeye dönüşür:

• Değerlendirme: birinin beğendiği birkaç örnek; buna karşılık alan başına üzerinde uzlaşılmış bir geçme eşiği olan etiketli bir set
• Veri: dışa aktarımlar, örnekler ya da barındırılan bir API; buna karşılık altyapınızdan çıkmasına izin verilmeyebilecek canlı kaynaklar
• Girdi: temiz PDF'ler; buna karşılık taramalar, e-posta yazışmaları, ekler ve haber verilmeden değişen şablonlar
• Çıktı: bir kişinin okuduğu metin; buna karşılık başka bir sistemin tükettiği ve güvenmek zorunda olduğu kayıtlar
• Operasyon: aynı anda tek kullanıcı; buna karşılık tepe hacim, model sunucusu kesintisi ve lansmandan sonra bir sahip

Modele dokunmadan önce kabul setini yazın

Eksik olan ilk artefakt, her birinin üretmesi gereken yanıtla birlikte gerçek belgelerden oluşan etiketli bir settir. O olmadan her prompt ya da model değişikliğini, o gün çıktıyı kim okuyorsa o yargılar ve pilot, hiç yazıya dökülmemiş bir kapıdan geçemez.

Google'ın Rules of Machine Learning rehberi ölçümü modelin önüne koyar; Rule #2 şöyledir: önce metrikleri tasarlayın ve uygulayın. Veri çıkarma ve ticket yönlendirme için metrik, belgenin tamamına verilen tek bir puan değildir:

• Belgeleri, ay sonunu, tatilleri ve alışılmadık formatlar kullanan göndericileri kapsayacak kadar uzun bir dönem boyunca gerçek trafikten seçin
• Belgeleri bu işi bugün yapan kişilere etiketletin, setin bir kısmında ikisi birbirinden bağımsız etiketlesin ve aralarındaki anlaşmazlıkları gürültü olarak değil, spesifikasyondaki boşluklar olarak ele alın
• Her alanı ayrı puanlayın; çünkü yanlış bir tarih, doğru bir isimle ortalamada telafi edilmez
• Geçme eşiğini alan başına ve belge türü başına yazın; hangi alanların otomatikleştirilebileceğini, hangilerinin her zaman bir kişiye gideceğini açıkça belirtin
• Mevcut manuel süreci aynı set üzerinde ölçün; böylece model kusursuzlukla değil, gerçek referans düzeyiyle karşılaştırılır
• Setin bir kısmını prompt ayarlayan herkesten uzak tutun; böylece nihai puan, prompt'un kendilerine göre ayarlandığı örnekler üzerinde ölçülmez

Perimetreden çıkamayan veri yalnızca sağlayıcıyı değil, mimariyi değiştirir

Pilot, barındırılan bir model üzerinde örneklerle, sentetik veriyle ya da birinin elle onayladığı belgelerle kurulmuşsa ve gerçek verinin harici bir sağlayıcıya ulaşmasına izin yoksa, pilotun sonucu aktarılamaz: içerideki model farklı bir model olabilir ya da farklı kuantizasyon ve serving ayarlarıyla aynı açık ağırlıklı model olabilir; her iki durumda da kalitesi kabul seti üzerinde yeniden ölçülmelidir.

İçeri alınacak bariz bileşen modeldir. Tek bileşen o değildir; çünkü bir dil modeli pipeline'ı veriyi model çağrısından daha fazla yere kopyalar:

• Sürümleri sabitlenmiş çıkarım sunucusu ve model ağırlıkları
• Belgelerden türetilen ve belgeler gibi korunması gereken embedding'ler ile vektör indeksi
• Loglardaki prompt'lar, çıktılar ve trace'ler; çünkü loglanan bir prompt, oluşturulduğu belgeyi içerir
• Kabul seti, etiketleme aracı ve inceleme kuyruğu
• Barındırılan bir servis olarak çalıştıklarında verinin harici bir kopyasına dönüşen izleme ve hata takibi

Logların kısıtlı bir bölgeden çıkması gereken yerlerde maskeleme işe yarar. Microsoft'ta başlatılmış açık kaynaklı bir framework olan Presidio, metindeki kişisel verileri tespit edip anonimleştirir; dokümantasyonu ise tespit otomatik olduğu için tüm hassas bilgileri bulacağının garantisi olmadığını belirtir. Maskeleme maruziyeti daraltır; verinin içeride tutulmasının yerini almaz.

Girdi işin gösterişsiz yarısıdır: taramalar, yazışmalar ve ekler

Pilot belge alır; üretim ise göndericilerin ne ürettiyse onu alır. Herhangi bir model çağrısından önce pipeline'ın bunu, kaynağına geri bağlayabileceği metne dönüştürmesi gerekir:

• Taramalar ve fotoğraflar OCR işleminden geçer; bu işlemin rakamlarda ve tablo sütunlarında yaptığı hatalar modele kendinden emin bir metin olarak ulaşır
• E-posta ve ticket yazışmaları alıntılanmış yanıtlar, imzalar ve yasal uyarı metinleri taşır; bu yüzden en son mesajın geçmişten ayrılması gerekir
• İçerik çoğu zaman eklerdedir ve her format kendi veri çıkarma yolunu gerektirir
• Her parça kaynağını, yani dosyayı, sayfayı ve offset'i korur; böylece çıkarılan her alan geldiği metin aralığına kadar izlenebilir
• İletilmiş bir bildirim ya da e-postayla yeniden açılmış bir ticket gibi mükerrerler, iki ayrı kayda dönüşmeden önce tespit edilir

Uzun girdiler ayrıca özen ister. Liu ve meslektaşları, 2024'te TACL'de yayımlanan Lost in the Middle çalışmasında, test ettikleri modeller için performansın, ilgili bilgi girdi bağlamının başında ya da sonunda olduğunda çoğu zaman en yüksek olduğunu, uzun bir bağlamın ortasında olduğunda ise belirgin biçimde düştüğünü gösterdi. Uzun bir belgeyi, her parçada kaynağı korunarak bölümlere ayırmak, modelin bağlamın tamamını eşit biçimde okuduğunu varsaymaktan daha güvenli bir varsayılandır; sizin belgeleriniz için hangisinin geçerli olduğunu kabul seti gösterir.

Yapılandırılmış çıktı bir şema, bir doğrulayıcı ve yanlış yanıt için bir yer ister

Constrained decoding (kısıtlı kod çözme), modeli bir şemaya uyan JSON ile sınırlar: vLLM bunu structured outputs olarak, llama.cpp ise grammar'lar üzerinden destekler. Bu, backend'in desteklediği şema özellikleri dahilinde ve çıktı üretimi token limitine takılıp kesilmediği sürece kaydın biçimini sabitler, ama doğruluğunu değil: biçimce geçerli bir kayıt yine de yanlış tarihi taşıyabilir.

Doğruluk modelden sonra, şirketin zaten güvendiği kodla kontrol edilir:

• Tür ve format kontrolleri: tarihler, para birimleri ve ISIN gibi kontrol basamağı olan tanımlayıcılar
• Alanlar arası kurallar; örneğin başlangıç tarihinden önceye düşemeyen bir dönem bitiş tarihi
• Şirketin halihazırda tuttuğu referans verileri üzerinde sorgular; örneğin bilinen bir enstrüman ya da müşteri
• Kaynakla tutarlılık: çıkarılan her değer, normalizasyondan önceki hâliyle, atıfta bulunduğu metin aralığında geçmelidir

Modelin kendi güven düzeyi zayıf bir kapıdır. OpenAI'ın 2023'te yayımlanan GPT-4 Technical Report belgesi, çoktan seçmeli bir benchmark'ta ön eğitimli modelin yüksek düzeyde kalibre olduğunu, eğitim sonrası aşamanın (post-training) ise kalibrasyonu düşürdüğünü gösterir. Modelin kendi bildirdiği bir kesinlik ya da bir token olasılığı, varsayılan olarak güvenilecek bir eşik değil, kabul setine karşı test edilecek bir sinyaldir.

Herhangi bir kontrolden geçemeyen kayıt, aşağı akıştaki sisteme değil, bir inceleme kuyruğuna gider. Kuyruk başlı başına bir üründür: bir sahibe, inceleyici saati cinsinden bir kapasite planına, her alanın yanında gösterilen kaynak metin aralığına ve kabul setine geri akan düzeltmelere ihtiyaç duyar.

Ticket'lar ve belgeler model için güvenilmeyen girdidir

Bir destek ticket'ı şirket dışından birinin yazdığı metindir ve bir belge, göndericisinin kasıtlı olarak yerleştirdiği talimatlar taşıyabilir. OWASP Top 10 for LLM Applications 2025, prompt injection'ı ilk sıraya koyar; buna, talimatların modelin işlediği harici bir içeriğin, örneğin bir web sitesinin ya da bir dosyanın içinde geldiği dolaylı injection da dahildir.

Aynı listenin üç maddesi, bir belge pipeline'ı için tasarım kurallarına dönüşür:

• Prompt injection: her belgeyi ve ticket'ı güvenilmeyen içerik olarak işaretleyin ve göndericinin düzenleyemediği bir şablondaki talimatlardan ayrı tutun
• Hatalı çıktı işleme (Improper output handling): herhangi bir sistem model çıktısına göre harekete geçmeden önce onu, bir kullanıcıdan gelen girdiyi doğrular gibi doğrulayın
• Aşırı yetki (Excessive agency): pipeline'a görevinin gerektirdiği en az yetkiyi verin; böylece ticket okuyan bir model hesap kapatamaz ya da ödeme gönderemez

OWASP ayrıca prompt injection'ı kesin olarak önlemenin bir yolu olup olmadığının belirsiz olduğunu not eder. Yükü prompt'un ifadesi değil, çıktı kontrolleri ve yetki sınırı taşır.

Modeli, prompt'u ve parser'ı tek bir sürüm olarak sabitleyin

Bir pipeline'ın davranışı, birbirinden bağımsız değişen birkaç artefaktın ortak sonucudur. Bunları tek bir sürüm olarak ele alın ve sürümün kimliğini ürettiği her kayıtta saklayın:

• Checksum ile tanımlanan model ağırlıkları; kuantizasyon ve çıkarım sunucusu sürümüyle birlikte
• Prompt şablonu, çıktı şeması ve decoding parametreleri
• OCR motoru, parçalama kuralları ve doğrulayıcılar
• Sürümün puanlanmasında kullanılan kabul setinin sürümü

Sabitlemek çıktıları özdeş yapmaz. Thinking Machines Lab, Eylül 2025'te bir çıkarım sunucusunun temperature sıfırken aynı prompt için farklı tamamlamalar döndürebildiğini gösterdi; çünkü bir isteğin sonucu, batch'ini kaç başka istekle paylaştığına bağlıdır. Aynı yazı, batch'ten bağımsız (batch-invariant) kernel'lerin bunu hız karşılığında ortadan kaldırdığını da gösterir. Sunucu bu tür kernel'ler çalıştırmıyorsa tekrarlanabilirlik, özdeş metin beklemek değil, her sürümde kabul setini yeniden çalıştırıp puanları karşılaştırmak demektir.

Operasyon: kapasite, kuyruklar ve model sunucusunun çalışmadığı saat

Kapasite belge üzerinden değil, token üzerinden planlanır. Girdi ve çıktı uzunluğunun dağılımını gerçek trafikte ölçün; çünkü tek bir uzun ek, çok sayıda kısa ticket kadar maliyet çıkarabilir ve çıktı üretme süresi çıktının uzunluğuyla birlikte artar.

Serving sistemleri hızlandırıcıyı meşgul tutmak için istekleri batch'ler hâlinde toplar. Kwon ve meslektaşları, SOSP 2023'te sunulan vLLM makalesinde, attention key-value önbelleğini sayfalamanın, değerlendirdikleri sistemlere kıyasla aynı latency düzeyinde throughput'u 2 ila 4 kat artırdığını bildirdi. Daha büyük batch'ler throughput'u yükseltirken her isteğin latency'sini de yükseltir. Bunu bir back-office kuyruğu kaldırabilir, etkileşimli bir adım kaldıramaz; bu yüzden ikisi ayrılır:

• Bir destek temsilcisinin sonucunu beklediği ticket triyajı gibi etkileşimli işler; kendi kapasitesi ve bir latency hedefiyle
• Gece boyunca veri çıkarma gibi batch işler; yük tepelerini sönümleyen ve duraklatılabilen bir kuyrukta
• Belge alımı ile model sunucusu arasında backpressure (geri basınç): sınırlı bir kuyruk ve bir eşzamanlılık limiti; böylece ani bir belge artışı sunucuyu aşırı yüklemek yerine bekler ya da yeniden deneme sinyaliyle reddedilir
• Belgeye göre anahtarlanmış idempotent işleme; böylece bir çökmeden sonraki yeniden deneme ikinci bir kayıt oluşturmaz
• Model sunucusu erişilemez olduğunda manuel sürece bir fallback; böylece iş kaybolmak yerine bir kişiyi bekler

Pipeline'ı devreye almayı geri alınabilir kılan şey fallback'tir. Bugün var olan manuel süreç taban olarak kalır; pipeline ise onun yerini tek bir tarihte almak yerine, üzerindeki işi alan alan devralır.

Yalnızca sunucuları değil, yanıtları da izleyin

Sunucu panoları pipeline'ın yanıt verip vermediğini söyler. Yanıtların doğru olup olmadığını söylemez; yeni bir şablonda kötüleşen bir model de latency'sini korur. Bir veri çıkarma ya da ticket pipeline'ını izlemek ikisini de kapsar:

• Alan, belge türü ve sürüm başına inceleme kuyruğuna düşme oranı ve inceleyici düzeltmeleri
• Otomatik üretilen kayıtlardan düzenli olarak alınan ve insanlar tarafından kabul kriterlerine göre yeniden kontrol edilen bir örneklem
• Girdi kayması (drift): yeni göndericiler, yeni şablonlar, dil karışımı ve belge uzunluğu
• Kurala göre doğrulayıcı hataları; bunlar doğruluk metrikleri değişmeden önce yeni bir formatı ortaya çıkarabilir
• Her aşamanın latency'sinin yanında, belge türü başına token'lar, hızlandırıcı saatleri ve kuyruk yaşı

NIST'in Temmuz 2024'te yayımlanan Generative AI Profile belgesi (NIST AI 600-1), bu işi AI Risk Management Framework'ün dört işlevi altında düzenler: yönetişim (govern), haritalama (map), ölçme (measure) ve yönetme (manage). İsimler sonuçtan daha az önemlidir: lansmandan sonra ölçüm, pilot ekibinin vakit bulduğunda yaptığı bir şey değil, adı konmuş ve kadrosu ayrılmış bir faaliyettir.

Alan ve belge türü bazında devreye alın: gölge, destekli, sonra otomatik

Pipeline'ı tek bir tarihte her şey için devreye almak, bütün riskleri tek bir olaya bağlar. Aşamalı bir devreye alma onları ayrı tutar:

• Gölge: pipeline canlı trafiği işler, hiçbir yere yazmaz ve kayıtları insanların ürettikleriyle karşılaştırılır
• Destekli: pipeline ön doldurma yapar, her kaydı bir kişi onaylar ve düzeltmeler alan başına sayılır
• Otomatik: alan ve belge türü başına, yalnızca geçme eşiğinin canlı trafikte de karşılandığı yerlerde; geri kalan her şey yine incelenir
• Belge türü başına destekli moda geri dönüş anahtarı; izlenen bir oran sınırını aştığında operasyon sahibi tarafından ayrıca onay alınmadan kullanılır

Belgeleri iyi okuyup yine de üretime hiç ulaşamayan bir pilot, okumada başarısız olmamıştır. Ona hiçbir zaman geçmesi gereken bir kabul seti, kullanmasına izin verilen bir veri yolu, yanlış yanıtları için bir yer ya da lansmanın ertesi günü için bir sahip verilmemiştir.

Bu işi üretime taşıyan firma, model tercihinizden önce belgelerinizi ister

Bu yazının arkasındaki sorunun - bir LLM pipeline'ını kimin sizin kendi altyapınızın içine kurup gerçekten üretime taşıyabileceğinin - bir tedarikçi listesine ihtiyaç duymayan bir testi var. Bu işi yapan bir firma, bir model önermeden önce kabulü ve operasyonu sorar:

• Kötü olanlar dahil gerçek belge ve ticket'lardan bir örneklemi sizin ortamınızda ya da veri sözleşmeniz kapsamında incelemeyi ister ve manuel sürecin bunları bugün nasıl ele aldığını sorar
• Herhangi bir ayarlamadan önce, alan başına geçme eşikleriyle birlikte kabul setini ilk iş olarak sizin ekibinizle kurmayı önerir
• Ağırlıklar ve indekslerden loglara, trace'lere, değerlendirme verisine, inceleme aracına ve izlemeye kadar verinin kopyalanacağı her yeri listeler ve her birinin içeride kaldığını gösterir
• Doğrulayıcıları, inceleme kuyruğunu ve manuel işlemeye fallback'i modelle aynı tasarım belgesine koyar
• Model, prompt, şema ve parser'ı birlikte sabitleyen bir sürüm ile alan başına gölge moddan otomatik moda uzanan bir devreye alma getirir
• Lansmandan sonra pipeline'ı kimin işleteceğini, örneklemi kimin inceleyeceğini ve model sunucusu durduğunda kimin aranacağını açıkça belirler

Her madde ilk görüşmede sorabileceğiniz bir şeydir ve muğlak bir yanıt, pilotun eksik işinin kapsamının henüz belirlenmediği anlamına gelir.

Dolayısıyla ilk soru, perimetrenizin içinde hangi modeli çalıştıracağınız değildir. Soru şudur: hangi belgelerde hangi alanların otomatik işlenmesini kabul edersiniz, neye göre ölçülerek ve doğrulamadan geçemeyen kayıtları kim devralır.

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.