Çıktının kullanılacağı işi ve sınırını tanımlayın

Bir yapay zekâdan talep notlarını düzenli kayda çevirmesini istediğinizde “JSON olarak ver” demek yeterli değildir. Sonraki yazılım belirli alanları, veri türlerini ve eksik bilgi davranışını bekleyebilir. Bunlar açık değilse düzgün görünen çıktı yanlış kayda veya sessiz veri kaybına yol açabilir. Bu rehber, bir veri şeması kurmayı, çıktıyı sınamayı ve belirsiz durumda işlemi durdurmayı ele alır. Herhangi bir aracın biçimi her zaman kusursuz üretebildiği varsayılmaz.

Şemadan önce çıktının nerede kullanılacağını ve kimin karar vereceğini belirleyin. Bir başvuruyu ekibe yönlendirecek kayıt, toplantı eylem listesi ve ürün satırı aynı alanları gerektirmez. Görev yalnızca sınıflandırma taslağıysa fiyat belirleme, müşteri yanıtı gönderme veya kaydı değiştirme yetkisini içine almayın. Talimat, bulunmayan iş bilgisini oluşturamaz; alan sözlüğü ve geçerli örnekleri işletme sağlamalıdır.

Alan sözlüğünü ve veri türlerini belirleyin

Her alan için makine adını, insanın okuyacağı açıklamayı, türünü, kaynağını ve kullanım amacını yazın. Örneğin bir talep kaydında kategori metin, öncelik sınırlı bir değer, dayanak alıntısı metin, inceleme durumu mantıksal değer olabilir. Sonraki sistem tarih bekliyorsa biçimi; tutar bekliyorsa birimi ve para birimini belirleyin. Yalnız “125” değerini görmek, bunun para mı adet mi olduğunu açıklamaz.

Önce asıl iş için gereken en küçük alan kümesini kurun. Her yeni alan yeni bir kaynak, doğruluk ve bakım sorusu getirir. Ekip kullanmayacaksa veya kaynağını doğrulayamayacaksa yalnız ileride işe yarar düşüncesiyle alan eklemeyin. Serbest etiket, öneri veya açıklama alanı gerekiyorsa içeriğinin hangi işlemde kullanılacağını da kaydedin. Böylece çıktı biçimi, gerçek iş sözleşmesini taşır.

Zorunlu alanı, boş değeri ve bilinmeyeni ayırın

JSON Schema’da properties alan tanımını, required ise kayıtta bulunması gereken alanları belirtir; bir alanın tanımlanmış olması her kayıtta zorunlu olduğu anlamına gelmez. Ayrıca eksik alan ile null değeri aynı değildir. Bilgi hiç alınmadı, incelendi ama bilinmiyor veya mevcut işte uygulanamaz durumlarından hangisinin gösterileceğini süreç sahibi seçmelidir. Boş metin ve sıfır da yalnız açık anlamları varsa kullanılmalıdır.

Kaynakta tarih yoksa modelin makul bir tarih tahmin etmesine izin vermeyin. Eksik alan davranışını veya bilinmiyor anlamına gelen bir işaret belirleyin. İki kaynak çelişiyorsa birini sessizce seçmek yerine çelişki durumunu ve dayanakları taşıyın. Bu ayrım, sonraki çalışanların belirsiz kaydı kesin bilgi sanmasını önler; her belirsizliğin hangi sorumluya gideceğini de talimata ekleyin.

İzin verilen seçenekleri ve bilinmeyen durumu tarif edin

Kategori, durum veya öncelik gibi alanların seçenekleri sınırlıysa her birinin anlamını ve sınır örneklerini yazın. Örneğin iki kategori aynı talep için makul görünüyorsa hangi iş kuralının kullanılacağı önceden belli olmalıdır. JSON Schema’daki enum anahtar sözcüğü kabul edilebilir değerleri sınırlayabilir; ancak sözcük listesi tek başına doğru sınıflandırma sağlamaz. Hiçbir seçenek uymuyorsa “inceleme gerekli” gibi bir durma yolu tanımlayın.

İzin verilmeyen yeni değer bulunduğunda otomatik olarak en yakın seçeneğe yuvarlamayın. Bu davranış sessiz ve yanlış bir yönlendirme yaratabilir. Çıktıyı reddetmek, belirsiz olarak işaretlemek veya yetkiliye göndermek arasındaki kararı işletme verir. Her durumda modelin yeni kategori, sorumlu veya son tarih uydurmasını önleyen kuralı açıkça yazın.

Çıktı sözleşmesini sabitleyin

Talimat; girdinin sınırını, görevi, alan sözlüğünü, zorunlulukları, seçenekleri, eksik bilgi davranışını ve çıktı biçimini birlikte açıklamalıdır. Alan dışı açıklama veya yeni anahtar kabul edilecek mi, tek kayıt mı yoksa kayıt listesi mi beklenecek, bunları da söyleyin. JSON Schema’daki additionalProperties ek alanların kabulünü sınırlayabilir. IETF RFC 8259 nesne anahtarlarının benzersiz olmasını önerir; yinelenen adlarda alıcı uygulamaların davranışı öngörülemez olabilir.

Talimat örneğinde yalnız onaylı kaynağı kullanmasını, dayanak ve inceleme durumu üretmesini, listede olmayan değerde durmasını isteyin. Talimat modelden ne beklediğinizi söyler; ayrıştırıcı ve şema doğrulayıcısı yapıyı sınar. Bu katmanları tek serbest metin kontrolüne indirmeyin.

Biçim geçerliliğini bilgi doğruluğundan ayırın

JSON sözdiziminin geçerli olması, alanların beklenen türde bulunması ve içerik değerinin gerçek olması ayrı kontrollerdir. Önce çıktının ayrıştırılıp ayrıştırılamadığını, zorunlu alanları, türleri ve seçenekleri sınayın; sonra tarih, tutar, kategori ve dayanağı kaynakla karşılaştırın. Şema “bu değer hangi türde olmalı?” sorusuna yardım eder; “bu değer kaynaktan doğru çıkarıldı mı?” sorusunu tek başına çözmez.

JSON Schema dokümantasyonu, format ifadesinin bazı doğrulayıcılarda yalnız açıklayıcı bilgi olabileceğini ve her uygulamanın aynı doğrulamayı yapmayabileceğini belirtir. Bu nedenle e-posta veya tarih gibi alanlarda format etiketini gerçek ayrıştırma kontrolü yerine koymayın. Kullanılan doğrulayıcının hangi kuralları çalıştırdığını sınayın; başarısız durumda kaydın duracağı veya incelemeye geçeceği yolu belirleyin.

Kaynağı ve dönüştürme izini koruyun

Dış kaynaktan çıkarılan değerin nereden geldiğini göstermek, sonradan inceleme yapmayı kolaylaştırır. Kaynak satırı, kayıt kimliği veya kısa dayanak cümlesi alanlarından hangisinin gerekli olduğunu seçin. Bütün belgeyi çıktıya kopyalamak zorunlu değildir; gerekli kimliği ve ilgili parçayı tutmak çoğu durumda yeterli bir başlangıçtır. Kaynağı olmayan değeri “çıkarım” diye işaretlemek de yetmez; kullanıcıya hangi kararın beklediği gösterilmelidir.

Çıktıdaki alanla kaynak ifadesi arasındaki dönüşümü kayıt altında tutun. Para birimi dönüştürülüyorsa kur ve tarih olmadan ham ve hesaplanmış tutarı birleştirmeyin. Metindeki bir tarih farklı zaman dilimiyle yorumlanacaksa bunu tahmin etmeyin; iş kuralını sorun. Denetim izi, her kararın doğru olduğunu kanıtlamaz; ama hangi kaynağın ve hangi talimat sürümünün kullanıldığını bulmaya yarar.

Sınır ve hata örneklerini özellikle deneyin

Yalnız temiz örneklerle yapılan deneme, belirsizlikteki davranışı göstermez. Geçerli kayıt yanında eksik kaynak, listede olmayan kategori, yanlış türde tarih, ek alan, çelişkili bilgi ve ilgisiz metin deneyin. Her test için beklenen sonucu önceden yazın: kabul, reddetme, inceleme veya durdurma. Kuralı çıktıdan sonra değiştirmek yerine, testi talimat ve işletme şartları netleşirken hazırlayın.

Sayısal alanlarda sıfır, sınır dışı değer, küsurat ve birim karışıklığını kontrol edin. Liste alanında boş listeyle eksik alanı ayırın. Anahtar adı iki kez gelirse doğrulayıcının nasıl davrandığını sınayın. Bir talep iki sınıfa uyuyorsa modelin seçimini kaynağa dayandırıp dayandırmadığını veya güvenli biçimde durup durmadığını görün. Test için gerçek müşteri kaydı gerekmez; örnekleri yapay ve anonim hazırlayabilirsiniz.

İnsan onayını ve veri sınırını koruyun

Şemaya uyan kayıt otomatik olarak doğru karar değildir. Müşteri yanıtı, fiyat, uygunluk veya hesap değişikliği gibi sonuç doğuran işler için hangi alanın insan tarafından onaylanacağını belirleyin. Onaylanmayan kaydı canlı sürece göndermeyin. Hata halinde ham veriyi gereksiz yere tekrar dolaşıma sokmak yerine, başarısız kontrolü ve gereken inceleme adımını sınırlı biçimde kaydedin.

Talimatı hazırlarken kişi adı, iletişim bilgisi veya gizli ticari ayrıntı gerçekten gerekli mi sorun. Gerekmiyorsa çıkarın veya anonimleştirin; erişim ve saklama kurallarını işletmenin onaylı sürecine göre belirleyin. Bu yazı herhangi bir sağlayıcının hesap ayarları, veriyi saklama süresi veya gizlilik davranışı hakkında genelleme yapmaz. Kullanılacak hizmetin güncel resmî belgeleri ayrıca incelenmelidir.

Şema değişikliğini sürüm ve kabul testiyle yönetin

Alan adı, türü veya anlamı değiştiğinde raporlar ve sonraki yazılım etkilenebilir. Şema için sürüm numarası, yürürlük tarihi, karar sahibi ve değişiklik nedenini tutun. Eski-yeni yapıyı karşılaştırıp hangi kayıtların yeniden işleneceğini ve eski sürümün ne zaman kapanacağını belirleyin. Değişikliği yalnız talimat metnine uygulamakla yetinmeyin; doğrulayıcı ve sonraki sistemi de güncelleyin.

Yeni sürümü küçük bir örnek kümesiyle deneyin; olumlu örneklerin yanı sıra eksik, çelişkili ve şema dışı durumları da çalıştırın. Model çıktısı ile insan düzeltmesini ayrı kaydedin. Bu iz, hangi kuralın değiştirilmesi gerektiğini anlamaya yardımcı olur. Kabul testinden geçmeyen şemayı otomatik aktarımda açmayın; gerekirse önce sınırlı bir insan inceleme akışında kullanın.

Örnek akış: Başvuruyu kayıt taslağına dönüştürmek

Bir ekip, genel başvuruları üç kategoriye ayırmak istesin. Önce tanımları, sınır örneklerini, sorumluyu ve belirsiz durumu yazar. Şemada kategori, kaynak kimliği, dayanak ve inceleme alanı bulunur. Talimat yalnız onaylı listeyi kullanır; fiyat veya yanıt üretmez. Birden fazla kategori uygunsa kayıt incelemeye gider.

Uydurma örneklerle biçim doğrulamasını ve dayanağı ayrı sınayın. Eksik kaynak, çelişki veya geçersiz çıktıda kayıt otomatik aktarılmasın. Sorumlu örnekleri ve durma kuralını onayladıktan sonra sınırlı kapsam seçin. Bu, doğruluk garantisi değil; hata yolu ve karar sahibini görünür kılan bir iş akışıdır.

Talimatı gerçek ihtiyaca uyarlarken dijital pazarlama hizmeti kapsamını netleştirin. İnsan sorumluya sınıflandırma için talep sınıflandırma taslağı, kaynaklı eylem kaydı için eylem kaydı rehberi, onaylı bilgi değişikliğinde SSS güncelleme haritası ve tablo incelemesinde kaynaklı fark kontrolü ayrı örnekler sunar.

Sık Sorulan Sorular

“JSON olarak ver” demek neden yeterli değildir?

Bu ifade yalnızca yazım biçimini kabaca belirtir. Alanlar, türleri, seçenekler, eksik bilgi davranışı ve ek açıklama kabulü belirsiz kalır. Sonraki sistemin beklediği sözleşmeyi ve hatalı çıktının nasıl duracağını ayrıca tanımlayın.

Bir alanı tanımlamak onu zorunlu kılar mı?

Hayır. JSON Schema’da properties ile tanımlanan alan varsayılan olarak her kayıtta bulunmak zorunda değildir; zorunluluk required ile ayrıca belirtilir. Her zaman elde olmayan bilgiyi zorunlu yapmak, modelin tahmin veya anlamsız boş değer üretmesine yol açabilir. İş kuralınıza göre karar verin.

Eksik alan ile null değeri aynı anlama gelir mi?

Her zaman değil. Alanın hiç gelmemesi “kaynak işlenmedi”, null ise “incelendi ama bilinmiyor” anlamına gelebilir. Bu ayrım farklı işlem gerektiriyorsa şemada ve talimatta açıkça tanımlayın. Boş metin, sıfır veya “yok” değerini de açıklamasız biçimde bilinmeyen bilgi yerine kullanmayın.

İzin verilen seçenekler dışında bir değer çıkarsa ne yapmalıyım?

Seçenekleri ve anlamlarını talimata ekleyin; karşılığı yoksa kullanılacak inceleme veya durdurma durumunu belirleyin. Çıktıyı doğrulayıcıdan geçirin. Başarısız sonucu yakın bir kategoriye sessizce çevirmek yerine kaydı durdurun veya yetkiliye gönderin.

Şemaya uygun çıktı doğru kabul edilebilir mi?

Tek başına hayır. Şema alan adlarını, türleri ve bazı değer sınırlarını kontrol eder; kaynakta bulunmayan bir bilginin doğru olduğunu kanıtlamaz. Kaynak kimliği veya dayanak alanı ekleyin, değeri kaynakla karşılaştırın ve önemli kararlarda insan onayını koruyun.

Ek alanları her zaman reddetmeli miyim?

Hayır; seçim sonraki sistemin ne beklediğine bağlıdır. Sabit kayıt sözleşmesinde tanımsız alanları reddetmek sürpriz veriyi önleyebilir. Keşif çalışmasında ek alanlar ayrı inceleme listesine alınabilir. Tercihi şema ve kabul testlerinde açıkça gösterin.

Modelden kendi çıktısını kontrol etmesini istemek yeterli mi?

Hayır. Bu istek ek bir kontrol adımı olabilir, fakat JSON ayrıştırıcısı ve şema doğrulayıcısının yerini tutmaz. Çıktıyı gerçek doğrulayıcıdan geçirin; ardından kaynak değerleri ve iş kurallarıyla karşılaştırın. Uyuşmazlıkta kimin karar vereceğini önceden belirleyin.

Aynı talimatı farklı yapay zekâ araçlarında kullanabilir miyim?

İş kuralları taşınabilir olsa da çıktı ve doğrulama davranışları aynı varsayılmamalıdır. Hizmetin güncel resmî belgelerini inceleyip testleri kendi ortamınızda çalıştırın. Araç değişse de doğrulama ve insan onayını koruyun.