Kurum İçi LLM Dağıtımlarında Yapılandırılmış Çıktı Zorunluluğu

Yapılandırılmış çıktı kurumsal yapay zeka için neden önemlidir

Büyük dil modelleri varsayılan olarak serbest biçimli metin üretir. Bir kurumsal uygulama belirli alanlarla bir JSON nesnesi, bir şemaya uyan XML belgesi veya geçerli söz dizimine sahip bir SQL sorgusu gerektirdiğinde, serbest biçimli üretim bir güvenilirlik sorunu ortaya çıkarır. Model zamanın %95'inde geçerli çıktı üretebilir, ancak kalan %5 eksik alanlar, geçersiz türler, bozuk söz dizimi veya alt akış ayrıştırıcılarını bozan konuşma ön ekleri içerebilir.

Bulut tabanlı API hizmetlerinde yapılandırılmış çıktı modları giderek daha fazla yönetilen bir özellik olarak sunulmaktadır. Kurum içi dağıtımlar bu kolaylıktan yararlanamaz. Açık ağırlıklı modelleri vLLM, TGI veya llama.cpp gibi çıkarım çerçeveleri aracılığıyla çalıştırıyorsunuz ve yapılandırılmış çıktı zorunluluğunu kendiniz uygulamanız gerekiyor. İyi haber şu ki, kurum içinde mevcut teknikler genellikle bulut API'lerinin sunduğundan daha esnek ve yapılandırılabilir olup çıktı kısıtlamaları üzerinde hassas kontrol sağlar.

İş gerekçesi basittir: bir alt akış sistemine ulaşan her bozuk çıktı ya hata işleme gerektiren bir başarısızlığa yol açar ya da daha kötüsü, verileri sessizce bozar. Yapılandırılmış çıktı zorunluluğu, güvenilirlik garantisini uygulama düzeyindeki yeniden deneme mantığından çıkarım katmanına taşır ve tüm bir entegrasyon hatası sınıfını ortadan kaldıran inşa yoluyla doğru çıktılar üretir.

Kısıtlı kod çözme: token düzeyinde yapı zorunluluğu

Yapılandırılmış çıktıya yönelik en sağlam yaklaşım, üretim sırasında token seçim sürecini değiştirerek yalnızca çıktının mevcut durumu ve hedef şema göz önüne alındığında geçerli olan tokenlara izin veren kısıtlı kod çözmedir. Tüm olası sonraki tokenlar arasından seçim yapmak yerine, model istenen yapıyla uyumluluğu koruyan maskelenmiş bir alt kümeden seçim yapar.

Mekanizma, üretim sürecinin yanında bir durum makinesi veya ayrıştırıcı tutarak çalışır. Her kod çözme adımında, sistem hangi tokenlerin hedef dilbilgisi veya şemaya göre kısmi çıktının geçerli devamlarını üreteceğini belirler. Şemayı ihlal edecek tokenlar sıfır olasılık alır ve modelin doğal tercihlerinden bağımsız olarak asla seçilmemelerini sağlar.

JSON çıktısı için bu, modelin her adımda yalnızca geçerli JSON tokenleri üretebileceği anlamına gelir. Bir açılış parantezinden sonra yalnızca geçerli JSON anahtarları veya boşluk karakterleri gelebilir. Bir anahtar-değer ayırıcıdan sonra yalnızca doğru türde bir değer başlatan tokenlar izin verilir. Sonuç olarak, üretilen her çıktının belirtilen şemaya uyan geçerli JSON olması garanti edilir.

Kısıtlı kod çözmeyi destekleyen kurum içi çerçeveler arasında vLLM (Outlines veya lm-format-enforcer kullanan yönlendirilmiş kod çözme özelliği ile), llama.cpp (GBNF dilbilgisi ile) ve TGI (dilbilgisi parametresi ile) bulunur. Her birinin farklı performans özellikleri ve şema belirtim biçimleri vardır, ancak temel ilke aynıdır: örneklemeden önce geçersiz tokenleri maskeleyin.

GBNF ve Outlines ile dilbilgisi destekli üretim

GBNF (GGML Backus-Naur Form), llama.cpp tarafından çıktı kısıtlamalarını tanımlamak için kullanılan bir dilbilgisi belirtim biçimidir. JSON, XML, SQL, CSV ve çoğu yapılandırılmış metin biçimini kapsayan herhangi bir bağlamdan bağımsız dilbilgisi ifade etmenize olanak tanır. Ad, yaş ve e-posta alanlarına sahip bir kişi kaydını belirleyen bir JSON şeması için GBNF dilbilgisi, modeli yalnızca o tam yapıya uyan çıktılar üretmeye kısıtlayacaktır.

GBNF'nin avantajı ifade gücüdür. Basit JSON şemalarının ötesine geçen biçimler için dilbilgisi tanımlayabilirsiniz: alana özgü diller, gerekli bölümleri olan yapılandırılmış raporlar veya hatta belirli biçimlendirme gereksinimleriyle kısıtlanmış doğal dil. Değiş tokuş olarak, elle GBNF dilbilgisi yazmak biçimsel dilbilgisi gösterimini anlamayı gerektirir, ancak JSON Şemasından GBNF otomatik üretimi yapan araçlar mevcuttur.

Outlines, doğrudan JSON Şeması ile çalışarak ve onu token maskeleme için verimli bir sonlu durum makinesine derleyerek farklı bir yaklaşım benimser. vLLM ve Hugging Face Transformers ile entegre olup Python tabanlı çıkarım yığınları için en pratik seçeneği oluşturur. Outlines, şemayı her üretim durumunu izin verilen token kimlikleri kümesine eşleyen bir dizine önceden derler ve böylece ilk derleme adımından sonra token başına ek yükü minimuma indirir.

Üretim dağıtımları için şemalarınızı istek zamanında değil başlangıçta önceden derleyin. Şema derleme, karmaşık şemalar için birkaç yüz milisaniye sürebilir; bu tek seferlik bir maliyet olarak kabul edilebilir ancak her istekte gerçekleştirilirse istenmeyen gecikme ekler. Derlenmiş şemaları önbelleğe alan ve API uç nokta tanımlayıcılarını ilgili çıktı kısıtlamalarına eşleyen bir şema kayıt defteri tutun.

Performans etkileri ve optimizasyon

Kısıtlı kod çözme, her token üretim adımında hesaplama ek yükü getirir. Token maskeleme işlemi, mevcut ayrıştırıcı durumuna göre hangi tokenlerin geçerli olduğunu değerlendirmeyi gerektirir ve modern modellerdeki büyük kelime dağarcıkları için (32.000 ila 128.000 token) bu değerlendirmenin verimli olması gerekir. Pratikte ek yük, uygulamaya bağlı olarak ihmal edilebilir düzeyden orta düzeye kadar değişir.

Outlines ve vLLM ile ek yük, önceden derlenmiş şemalar için tipik olarak toplam çıkarım süresinin %5'inin altındadır. Sonlu durum makinesi yaklaşımı, her durum için geçerli token kümelerinin O(1) aramasına olanak tanır ve durum geçişleri derleme zamanında hesaplanır.

Llama.cpp'deki GBNF dilbilgileri, karmaşık dilbilgileri için daha yüksek ek yüke sahip olabilir çünkü dilbilgisi ayrıştırıcısı her adımda değerlendirilir. Basit JSON şemaları için etki minimumdur, ancak derin iç içe alternatifler veya özyinelemeli yapılara sahip dilbilgileri üretimi yavaşlatabilir.

Önemli bir husus, kısıtlı kod çözme ile toplu çıkarım arasındaki etkileşimdir. Bir toplu işteki farklı isteklerin farklı çıktı şemaları olduğunda, her istek kendi token maskesine ihtiyaç duyar. Bu, toplu iş genelinde tek bir paylaşılan maskenin kullanılmasını engeller ve toplu kod çözme verimliliğini azaltabilir. vLLM bunu istek başına yönlendirilmiş kod çözme durumu tutarak doğru şekilde ele alır, ancak yoğun heterojen şema toplu işlerinin düzgün toplu işlerden daha düşük verim göreceğini unutmayın.

Katmanlı doğrulama: derinlemesine savunma

Kısıtlı kod çözme bile olsa, sağlam bir üretim sistemi katmanlı doğrulama uygulamalıdır. Kısıtlı kod çözme söz dizimsel doğruluğu garanti eder (çıktı şemaya uyan geçerli JSON'dur), ancak anlamsal doğruluğu garanti etmez (değerlerin alanınız için anlamlı olduğu). Bir kısıtlı kod çözücü, şema türü yalnızca tamsayı veya dize olarak belirtilmişse yaş alanı 99999 veya tarih alanı "2099-13-45" olarak ayarlanmış geçerli bir JSON nesnesi memnuniyetle üretecektir.

Üç katmanlı bir doğrulama hattı uygulayın. Birinci katman söz dizimsel zorunluluk için kısıtlı kod çözmedir. İkinci katman değer kısıtlamalarıyla şema doğrulamasıdır: min/maks aralıkları, dizeler için regex kalıpları, enum kısıtlamaları ve çapraz alan tutarlılık kontrolleri. Üçüncü katman alana özgü doğrulamadır: iş kuralları, veritabanlarınıza karşı referans bütünlüğü kontrolleri ve geçmiş veri dağılımlarına dayalı olasılık kontrolleri.

İkinci veya üçüncü katmanda bir doğrulama hatası oluştuğunda, birkaç kurtarma seçeneğiniz vardır. En basiti, doğrulama hatasını geri bildirim olarak içeren değiştirilmiş bir istemle yeniden denemektir. Daha sofistike yaklaşımlar, çıktının geçerli kısımlarını korurken yalnızca başarısız alanların kısıtlı yeniden üretimini kullanır.

Tüm doğrulama hatalarını tam bağlamla kaydedin: istem, üretilen çıktı, doğrulama hatası ve yeniden deneme sonucu. Bu veriler sistematik sorunları belirlemek için paha biçilmezdir. Belirli bir alan sürekli olarak anlamsal doğrulamada başarısız oluyorsa, sorun modelin kendisinden ziyade istem mühendisliğinde olabilir.

Pratik dağıtım önerileri

Halihazırda çalıştırdığınız çıkarım çerçevesiyle başlayın. vLLM kullanıyorsanız, Outlines ile yönlendirilmiş kod çözmeyi etkinleştirin ve çıktı şemalarınızı JSON Şeması olarak tanımlayın. llama.cpp kullanıyorsanız, GBNF dilbilgileri yazın veya bir JSON Şemasından GBNF dönüştürücü kullanın. Yalnızca yapılandırılmış çıktı desteği için çerçeve değiştirmekten kaçının; entegrasyon ek yükü nadiren haklı çıkar.

Şemaları mümkün olduğunca katı tanımlayın. Her isteğe bağlı alan potansiyel bir tutarsızlık kaynağıdır. Geçerli değerler kümesi bilindiğinde serbest biçimli dizeler yerine enum'lar kullanın. Genel sayı türleri yerine min/maks sınırlarına sahip tamsayı türleri kullanın. Şemanız ne kadar sıkıysa, kısıtlı kod çözücü sizin için o kadar çok iş yapar.

Şemalarınızı modelin olağandışı çıktılar üretmesini sağlamak için tasarlanmış karşıt istemlerle test edin. Beklenmeyen dillerdeki istemler, aşırı uzun girdiler, çıktı biçimini geçersiz kılmaya çalışan girdiler ve alanınızdaki uç durumlar, hepsi geçerli, şema uyumlu çıktılar üretmelidir.

Son olarak, kısıtlı çıktılar için üretim kalitesi metriklerini kısıtlanmamış üretimden ayrı olarak izleyin. Her adımda maskelenen token sayısını (kısıtlama baskısı), ikinci katman doğrulama hatalarının sıklığını ve yeniden deneme sayılarının dağılımını takip edin. Yüksek kısıtlama baskısı, modelin şemayla çatıştığını gösterir ve bu, modelin eğitim dağılımı ile beklenen çıktı biçiminiz arasındaki uyumsuzluğa işaret edebilir.

Öne çıkan görsel: Shoeib Abolhassani tarafından Unsplash'ta yayınlanmıştır.