Yapay zeka uygulamaları neden yapılandırılmış çıktıya ihtiyaç duyar?
Yapay zeka uygulamalarının yapılandırılmış çıktıya ihtiyacı vardır; çünkü yazılımlar samimi bir dille yazılmış bir paragrafı güvenilir biçimde okuyamaz. Her seferinde aynı adlara ve türlere sahip aynı alanlara ihtiyaç duyarlar. Fazladan bir cümle veya eksik bir alan, uygulamanızın bir sonraki adımını bozabilir.
12 kişilik hayali bir lojistik girişimi olan Parcelwise'ı düşünün. Geliştiricisi Sana, müşteri e-postalarını okuyup teslimat değişikliği formunu dolduran bir araç geliştiriyor: sipariş referansı, istenen tarih, yeni adres ve müşterinin para iadesi isteyip istemediği. Tipik bir e-posta şöyle: 'Merhaba, sipariş PW-88213, perşembe evde olmayacağım, onun yerine cumartesi getirebilir misiniz? Ya da 14 numaraya bırakın. Olmazsa iptal edip parayı iade edin lütfen.' İlk sürümde modelden 'JSON biçiminde yanıt ver' diye istiyor. Yanıtların çoğu ayrıştırılabiliyor, ancak bazıları 'Elbette, işte JSON' diye başlıyor, bazıları alanı 'requested_date' yerine 'date' olarak adlandırıyor, biri de tarihi 'Cumartesi' olarak döndürüyor.
JSON şeması nedir ve neden yararlıdır?
JSON şeması, beklediğiniz verilerin biçimsel bir tanımıdır: hangi alanların bulunduğunu, hangilerinin zorunlu olduğunu, her birinin türünü ve hangi değerlere izin verildiğini belirtir. Modele bir şema vermek, 'lütfen JSON biçiminde yanıt ver' isteğini kodunuzun denetleyebileceği bir sözleşmeye dönüştürür.
Sana için şema şöyle der: order_reference zorunlu bir metin dizgesidir; requested_date tarih biçiminde zorunlu bir metin dizgesi, tarih belirtilmediyse null olmalıdır; new_address bir metin dizgesi veya null olabilir; refund_requested zorunlu bir mantıksal değerdir ve başka hiçbir alana izin verilmez. Son kural, modelin yorum alanları eklemesini engeller.
Model API'leri yapılandırılmış çıktıyı nasıl destekler?
Başlıca model API'leri, istekle birlikte bir JSON şeması göndermenize olanak tanır ve modelin çıktısı bu şemaya uyacak şekilde sınırlandırılır.
OpenAI
OpenAI'nin Yapılandırılmış Çıktılar özelliği, katı mod açıkken yanıtları sağlanan JSON şemasına uymaya zorlar. Belgelerde bu özellik, yalnızca geçerli JSON üretilmesini sağlayan ancak şemanıza uyulmasını sağlamayan eski JSON modundan ayrı tutulur ve mevcut olduğunda Yapılandırılmış Çıktılar'ın kullanılması önerilir.
Anthropic
Claude API’si, sağladığınız şemaya uyan JSON çıktıları sunar. Ayrıca araç tanımlarında katı doğrulama seçeneği sunarak araç girdilerinin aracın şemasına göre doğrulanmasını sağlar. Belgelerinde hangi şema özelliklerinin desteklendiği ve hangilerinin hata verdiği listelenir.
Gemini API, yanıtlar için bir JSON şeması kabul eder ve şema anahtar sözcüklerinin tanımlanmış bir alt kümesini destekler. Belgelerinde, çıktı sözdizimi açısından geçerli JSON olsa da uygulamanızda değerleri yine de doğrulamanız gerektiği belirtilir.
Doğrulama ve yeniden denemeler neden hâlâ gereklidir?
Yine de doğrulama yapmanız gerekir; çünkü şema, verilerin biçimini denetler, değerlerin doğru olup olmadığını değil. Kusursuz biçimlendirilmiş bir yanıt bile yanlış tarih, uydurma sipariş referansı veya müşterinin hiç istemediği bir para iadesi işareti içerebilir.
İki katmanda doğrulayın. Önce, OpenAI, Anthropic ve Google belgelerinin tümünde örnekleri gösterilen Python için Pydantic veya JavaScript için Zod gibi bir şema kütüphanesiyle yapıyı kontrol edin. Ardından iş kurallarını kontrol edin: sipariş referansı beklenen biçime uyuyor ve sistemde bulunuyor mu, tarih gelecekteki bir teslimat günü mü ve adres teslimat bölgesinde mi? Sağlayıcıların belgelediği durumları da ele alın: şemanıza uymayabilecek bir ret yanıtı ve azami belirteç sınırı nedeniyle kesilip eksik JSON bırakan bir yanıt.
Dikkatli biçimde yeniden deneyin. Bir kontrol başarısız olursa, 'requested_date bir tarih olmalıdır; e-postada Cumartesi yazıyor ve sipariş tarihi 14 Ekim' gibi, hatayı açıkça belirten bir yeniden deneme gönderin. Yeniden deneme sayısını bir veya ikiyle sınırlayın, ardından e-postayı bir kişiye yönlendirin.
Yetersiz ve sağlam bir yapılandırılmış çıktı nasıl olur?
Zayıf sürüm: İstem, 'Ayrıntıları çıkar ve JSON biçiminde yanıt ver.' diyor. Uygulama, gelen yanıt ne olursa olsun okuyor. Yukarıdaki e-posta için order ve date adlı alanlar, 'Cumartesi' tarih değeri ve true iade değeri alıyor; çünkü model, 'olmazsa iptal edin' ifadesini kesin bir talep olarak yorumluyor. Form yanlış dolduruluyor ve müşteriye istemediği bir para iadesi yapılıyor.
Sağlam sürüm: istek, Sana'nın şemasını katı modda içerir ve istem, 'refund_requested yalnızca müşteri koşulsuz olarak para iadesi istiyorsa true olur' açıklaması da dahil olmak üzere her alanı açıklar. Model, order_reference alanını PW-88213, requested_date alanını bir sonraki Cumartesi'nin tarihi, new_address alanını null, refund_requested alanını false olarak döndürür. Sana'nın tam da bu durum için şemaya eklediği conditional_request alanını ise 'Cumartesi teslimatı veya komşuya teslimat mümkün değilse para iadesi' olarak ayarlar. Doğrulama, siparişin mevcut olduğunu ve Cumartesi'nin bir teslimat günü olduğunu teyit eder. E-posta koşullu bir istek içerdiği için kurallar, son kararı vermesi için e-postayı bir kişiye yönlendirir.
Yapılandırılmış çıktılarda sık yapılan hatalar nelerdir?
En yaygın hata, geçerli JSON biçimindeki veriyi doğru veri sanmaktır. Diğer hatalar: API şemaya uyumu zorunlu kılma olanağı sunarken yalnızca istem talimatlarına güvenmek, açıklama eklemeden belirsiz alan adları kullanmak, gerçeği yansıtan yanıt null iken bir değer vermeye zorlamak, ret yanıtlarını ve yarıda kesilen yanıtları göz ardı etmek ve modele neyin yanlış olduğunu söylemeden yeniden denemek.
Yapılandırılmış çıktının Tosheo.ai kataloğundaki yeri nedir?
Yapılandırılmış çıktı, Yapay Zeka Uygulamaları Geliştirme kategorisindeki yapay zeka uygulamaları geliştirme kursunda yer alan bir Kod dersidir. Şema tanımladığınız, API çağrısı yaptığınız, yanıtları doğruladığınız ve yeniden deneme eklediğiniz, kod içeren tam uygulamalı sürüm, kayıt olduktan sonra Kod eğitim yolunda sunulur. Her adımda puanlama ölçütlerine göre geri bildirim alırsınız.