Yapılandırılmış çıktılar: bir dil modelinden güvenilir JSON elde etme

Her LLM entegrasyonunun ilk sürümü düzyazıyı ayrıştırır. Yeni satırlara bölünmüş "her satıra bir tane olmak üzere üç ana risk" istersiniz ve bu, modelin önce bir giriş cümlesi yazdığı güne kadar işe yarar. Bu döngüyü sona erdirmek için yapılandırılmış çıktılar mevcuttur: Modele bir JSON Şeması verirsiniz, kod çözücü onu ihlal eden hiçbir şey yayamayacak şekilde sınırlandırılır ve istediğiniz alanları içeren bir yükü geri alırsınız. Bu garanti gerçektir ancak göründüğünden daha dardır ve aradaki fark, böceklerin yaşadığı yerdir.

Garanti aslında neleri kapsıyor

Kısıtlı kod çözme garantileri şekil. Yanıt JSON olarak ayrıştırılacak, anahtarlarınızı içerecek, türler eşleşecek ve numaralandırma alanları listelenen değerlerinizden birini içerecektir. Bu, hızlı ve umutlu yaklaşıma göre büyük bir gelişme.

Hakkında hiçbir şeyi garanti etmez içerik. Dize olarak yazılan alan bir dize içerecektir; bu dizenin doğru olup olmadığı veya şemayı karşılamak için icat edilmiş olup olmadığı öncekiyle aynı değildir. Aslında katı bir şema, buluşu biraz daha olası hale getirir, çünkü zorunlu bir alanın bir şeyle doldurulması gerekir ve modelin "kaynakta mevcut değil" demesine imkan yoktur. Bu, üretimdeki en yaygın tek başarısızlıktır: gerekli bir invoice_number hiçbiri olmayan bir belgede.

Etrafında tasarım yapın. Devamsızlığın mümkün olduğu durumlarda null'a izin verin, açık bir değer ekleyin found: boolean veya bir "unknown" enum üyesi olun ve cevap her girişte gerçekten mevcut olmadığı sürece asla bir alanı gerekli kılmayın.

Bir modelin doldurabileceği bir şema tasarlama

Doğrulama için yazılan şemalar ile nesil için yazılan şemalar farklı görünür. Sağlayıcılar arasında geçerli olan birkaç kural:

• Düz vuruşlar iç içe geçmiş. Her yuvalama düzeyi, modelin izini kaybettiği bir yerdir. Üç çağrıda çıkarılan üç sığ nesne, derinlemesine yuvalanmış bir ağacı yener.
• Numaralandırmalar serbest dizeleri yener. Bir alanın beş geçerli değeri varsa bunları listeleyin. Normalleştirme kodunun bir sınıfının tamamını kaldırırsınız ve kısıtlı kod çözücü bunu sizin için uygular.
• Alan adları talimatlardır. due_date_iso8601 olduğundan daha iyi çıktı üretir date format ayrı bir bilgi isteminde açıklanmıştır. İsimler bağlamdadır; onları kullan.
• Kullanmak description tarlalarda. Çoğu sağlayıcı modele şema açıklamalarını aktarır. Belirsiz alan başına bir cümle, yukarıdaki düzyazı talimatlarının bir paragrafından daha ucuz ve daha güvenilirdir.
• Ayarlamak additionalProperties: false. Pek çok sağlayıcı zaten katı mod için buna ihtiyaç duyuyor ve modelin ayrıştırıcınızın sessizce yok saydığı ekstra bir anahtar icat etmesini faydalı bir şekilde durduruyor.
• Haritalara düz nesne dizilerini tercih edin. Özellik adları önceden bilinmeyen bir nesne olan dinamik anahtarlar, katı modlar tarafından yeterince desteklenmez ve alıcı tarafta yazılması zordur.

Sağlayıcılar ayrıca katı modda destekledikleri JSON Şeması anahtar kelimelerini de kısıtlar: oneOf, desen kısıtlamaları, sayısal sınırlar ve yineleme genellikle sınırlandırılır veya göz ardı edilir. Şemanın yalnızca yapıyı kısıtladığını varsayalım ve ayrıştırma sonrasında iş kurallarınızı kendiniz uygulayın.

Yine de doğrula

Katı modda bile, her yanıtı veritabanınıza dokunmadan önce doğrulayın. Katı mod, bir yapılandırma değişikliği nedeniyle devre dışı bırakılabilir, bir geri dönüş yolu onu desteklemeyen bir modele çarpabilir, ağ yeniden denemesi bir hata nesnesi döndürebilir ve yanıt, nesnenin ortasındaki bir belirteç sınırı tarafından kesilebilir; bu da geçersiz JSON hiçbir şema modunun engellemesine neden olmaz.

Bir veri yükü başarısız olduğunda asıl soru hangi alanda ve bunun nedenidir. JSON Şema doğrulayıcı belgeyi ve şemayı alır ve JSON İşaretçisi yolu, başarısız olan anahtar kelime ve gerçekte bulunan değerle birlikte sorun başına bir satır rapor eder. Bu tam olarak iki amaç için istediğiniz biçimdir: geliştirme sırasında şemanızı düzeltmek ve yeniden denemeye geri bildirimde bulunmak - bir takip mesajına yapıştırılan başarısız bir doğrulama raporu, oldukça etkili bir onarım istemidir, çünkü model tam olarak neyin yanlış olduğunu görebilir.

Yeniden deneme sayısını bir veya ikiyle sınırlandırın. Bir şemayı iki kez başarısızlığa uğratan bir modelden genellikle girdinin içermediği bir şey istenir ve üçüncü denemede onu icat edilir.

Örnek veriden koda

Çoğu şema, birisinin sohbete yapıştırdığı örnek bir yanıt olarak hayata başlar. Bunu elle yazılmış, doğrulanmış koda dönüştürmek sıkıcı ve hataya açıktır, bu yüzden yapmayın.

Örneği içine yapıştırın JSON'dan Zod'a şema ve bir Zod şemasına ek olarak türetilen TypeScript türünü elde edersiniz. Her şeyi bir dize olarak genel olarak yazmak yerine alan başına sonuç çıkarır: e-postalar, URL'ler, UUID'ler veya ISO tarihleri gibi görünen değerler elde edilir .email(), .url(), .uuid() Ve .datetime() çıplak olmak yerine z.string()diziler kendi öğe türlerini taşır ve türü olaylara göre değişen bir alan, ilk gördüğü alanı sessizce seçmek yerine bir birleşim haline gelir. Bu son davranışı bilinçli olarak beslemeye değer: bir değil, birleştirilmiş üç veya dört gerçek yanıtı yapıştırın, böylece isteğe bağlı ve polimorfik alanlar, ilk örneğin içerdiği şeye kilitlenmek yerine birleşimler olarak görünür.

Yükün zaten güvendiğiniz bir kaynaktan gelmesi nedeniyle yalnızca türlere ihtiyacınız varsa ve çalışma zamanı doğrulamasına ihtiyacınız yoksa - JSON'dan TypeScript'e satır içi anonim lekeler yerine adlandırılmış alt arayüzler olarak ayrılmış iç içe geçmiş nesnelerle arayüzleri doğrudan üretir.

Gerçeğin yönünü düz tutun: diğer her şeyin ondan üretildiği tek bir şema tanımı. Ayrı ayrı tutulan bir Zod şeması ve bir JSON Şeması bir ay içinde fikir ayrılığına düşecek ve anlaşmazlık, bir test hatası yerine üretim ayrıştırma hatası olarak ortaya çıkacaktır.

Geri gelenleri okuyorum

Model yanıtları tek satırda küçültülmüş olarak geliyor, bu da onlara göz kulak olmayı perişan ediyor. JSON biçimlendirici bunları okunabilir bir şey halinde girintiler ve sıralar ve doğrulaması kesme durumunu anında yakalar - dizenin ortasında biten bir veri, isabet belirteci sınırının imzasıdır ve düzeltme, hızlı bir değişiklik değil, daha yüksek bir çıktı sınırı veya daha küçük bir şemadır.

Aynı girdiden üretilen iki modeli karşılaştırırken veya hızlı bir değişikliğin çıktıyı istemediğiniz şekilde değiştirip değiştirmediğini kontrol ederken, her ikisini de okumak yerine biçimlendirilmiş yükleri farklılaştırın. Bir sayı yerine sessizce bir rakam dizisi haline gelen bir alan olan JSON'un duvarında görünmeyen yapısal farklılıklar, farkta hemen göze çarpıyor.

Sürüm oluşturma

Şemalar değişir ve model çıktısı da onlarla birlikte değişir. İlk günden itibaren payload'a bir sürüm alanı koyun, böylece saklanan kayıtlar, altına yazıldığı şekli taşır. Milyonlarca satır etiketsiz JSON'a sahip olduktan sonra, kimsenin zaman planlamadığı türden bir geçiş olduğunu yeniden uyarlamak.

Bu araçların tümü tarayıcınızda yerel olarak çalışır ve bu, bu iş akışı için normalden daha önemlidir: şemalara dönüştürdüğünüz örnek veriler genellikle içlerinde gerçek müşteri verileri bulunan gerçek API yanıtlarıdır ve bunların güzelleştirilmesi için bir biçimlendirme hizmetine yüklenmemeleri gerekir.