Bidang Wajib vs Opsional/Boleh Null

Keluaran terstruktur dengan tool_use dan JSON Schema menghilangkan kesalahan sintaks dan memungkinkan Anda memberlakukan bidang wajib. Namun, kemampuan ini memiliki sisi yang berisiko.

Aturan yang sangat penting untuk ujian dalam pelajaran ini: tandai suatu bidang sebagai required hanya jika bidang itu selalu ada. Jangan pernah mewajibkan bidang yang mungkin tidak ada.

Mengapa? Saat suatu bidang diwajibkan, model harus menghasilkan nilainya. Jika data sumber sebenarnya tidak memuat nilai tersebut, model tidak punya pilihan selain mengarang nilai untuk memenuhi skema. Bidang wajib adalah janji yang akan dipenuhi model bahkan ketika seharusnya tidak.

Array required dalam JSON Schema adalah batasan tegas, bukan petunjuk. Model tidak dapat mengembalikan objek yang valid secara struktural jika menghilangkan kunci yang diwajibkan.

Bayangkan Anda mengekstrak phone_number pelanggan dari email dukungan yang sama sekali tidak menyebutkan nomor telepon. Jika phone_number diwajibkan, model harus menghasilkan sesuatu — dan nomor yang tampak masuk akal tetapi dikarang lebih buruk daripada tidak ada nomor sama sekali, karena tidak ada proses di hilir yang dapat membedakannya dari nomor asli.

Solusinya bersifat struktural: jadikan bidang opsional benar-benar opsional, sehingga model dapat secara sah menghilangkannya ketika informasinya tidak ada.

Berikut adalah alat ekstraksi yang menandai setiap bidang sebagai required. Email di bawah tidak memiliki nomor telepon — tetapi skema memaksa model untuk mengarangnya.

Ini adalah pola yang harus dihindari. Baca required dengan saksama: daftar tersebut memuat bidang yang mungkin benar-benar tidak ada dalam input nyata.

Masukkan ke dalam required hanya bidang yang selalu ada. Semua yang mungkin tidak ada harus tetap di luar required — model kemudian dapat menghilangkannya dengan jujur.

Perhatikan bahwa name dan email tetap wajib karena setiap tiket dukungan memilikinya, sedangkan phone_number dihapus dari daftar.

Ada dua cara untuk memungkinkan suatu bidang "tidak ada", dan maknanya berbeda:

• Opsional — kunci tersebut cukup dihilangkan dari required. Model dapat menghilangkan kunci itu sepenuhnya dari objek.
• Nullable — kunci tersebut selalu ada, tetapi tipenya mengizinkan null, yang menandakan "slot ini sudah diperiksa dan ternyata kosong".

Opsional menjawab "apakah model melaporkan bidang ini sama sekali?" Nullable menjawab "model sudah memeriksanya, dan nilainya secara eksplisit tidak ada." Pilih nullable ketika konsumen di hilir memerlukan setiap kunci hadir agar bentuk data tetap stabil.

Untuk membuat bidang nullable, izinkan null sebagai salah satu tipenya. Dengan keluaran terstruktur, biasanya Anda menyatakannya menggunakan anyOf (kata kunci yang didukung) yang menggabungkan tipe sebenarnya dan null.

Di sini phone_number selalu dikeluarkan sebagai kunci, tetapi nilainya null ketika email tidak memuat nomor — sebuah "kosong" yang jujur, bukan string digit yang dikarang.

Tipe nullable mengizinkan null, tetapi model tetap menentukan kapan menggunakannya. Perjelas maksudnya dalam description bidang tersebut: beri tahu model untuk mengembalikan null, bukan menebak.

Ini memadukan jaminan struktural (tipe mengizinkan null) dengan jaminan perilaku (deskripsi menjelaskan kapan menggunakannya). Skema menentukan bentuk; deskripsi mengarahkan penilaian.

Risiko pengarang-ngarangan yang sama juga muncul pada enum. Jika suatu bidang harus berupa salah satu dari sekumpulan nilai tetap dan input nyata tidak cocok dengan satu pun nilai tersebut, enum yang ketat memaksa model memilih jawaban salah yang paling mendekati.

Pola yang direkomendasikan dalam ujian untuk ekstensibilitas: sertakan nilai "other" dalam enum serta bidang detail berupa teks bebas. Ini memberi model tempat yang jujur untuk menampung kasus ketika kenyataan melampaui enum Anda — alih-alih salah mengklasifikasikannya.

Saat validasi gagal, percobaan ulang dengan umpan balik sangat berguna — Anda mengirim ulang dokumen asli, keluaran model yang salah, dan kesalahan validasi yang tepat untuk memperbaiki kesalahan format, struktural, atau aritmetika.

Namun, percobaan ulang NOT membantu ketika informasi memang tidak ada dalam sumber. Jika nomor telepon tidak ada di email, pengulangan perintah sebanyak apa pun tidak akan memunculkan nomor yang benar. Rancangan yang tepat memungkinkan bidang tersebut tidak ada sejak awal — bidang yang wajib tetapi tidak ditemukan adalah bug skema, bukan kesalahan sementara yang perlu dicoba ulang.

Untuk nilai yang seharusnya ada dan dapat diverifikasi, teknik pelengkapnya adalah koreksi mandiri: ekstrak calculated_total dan stated_total secara BOTH agar ketidakcocokan menampilkan perbedaan yang dapat Anda temukan.

Namun, koreksi mandiri mendeteksi kesalahan dalam data yang ada; teknik ini tidak dapat memvalidasi bidang yang sejak awal tidak pernah ada dalam sumber. Garis pertahanan pertama terhadap pengarang-ngarangan tetaplah skema itu sendiri: jangan mewajibkan sesuatu yang mungkin tidak ada. Gunakan validasi bergaya Pydantic pada hasilnya untuk memberlakukan invarian ini dalam kode.

Ada satu pembedaan penting lainnya bagi arsitek: hasil kosong yang valid ("email tidak memiliki nomor telepon") tidak sama dengan kegagalan akses ("alat ekstraksi mengalami kesalahan").

Bidang nullable merepresentasikan kasus pertama dengan jelas. Jangan memodelkan ketiadaan yang memang terjadi sebagai kesalahan untuk dicoba ulang, dan jangan menyembunyikan kegagalan nyata sebagai null. Buat skema menjelaskan perbedaannya: null untuk kondisi kosong yang memang sah, dan jalur kesalahan terpisah untuk kegagalan akses. Sinyal yang jelas dan terstruktur di hilir lebih baik daripada sinyal yang ambigu.

Inti pembelajaran:

• Wajibkan hanya bidang yang selalu ada. Mewajibkan bidang yang mungkin tidak ada akan memaksa model mengarang nilai.
• Opsional = kunci boleh dihilangkan; nullable = kunci selalu ada, tetapi nilainya boleh berupa null. Pilih nullable ketika pihak yang menggunakan data memerlukan kumpulan kunci yang konsisten.
• Pasangkan tipe nullable dengan deskripsi yang menyatakan "kembalikan null jika tidak ada — jangan menebak."
• Untuk kumpulan nilai tertutup, tambahkan nilai enumerasi "other" serta bidang detail teks bebas agar dapat diperluas.
• Pengulangan dengan umpan balik memperbaiki kesalahan format, struktur, dan aritmetika, bukan informasi yang tidak ada. Koreksi mandiri mendeteksi ketidaksesuaian pada data yang tersedia, bukan bidang yang hilang.
• Bedakan hasil kosong yang valid dari kegagalan akses — jangan pernah menyembunyikan salah satunya secara diam-diam.