Structured Outputs pada AI: Cara Membuat Respons JSON yang Konsisten

Model kecerdasan buatan dapat menjelaskan ide dengan bahasa yang luwes, tetapi keluwesan itu menjadi tantangan ketika hasilnya harus diproses aplikasi. Satu permintaan bisa menghasilkan daftar, permintaan lain menghasilkan paragraf, atau model menambahkan teks di luar JSON. Akibatnya, parser gagal dan alur otomatisasi terhenti.

Structured Outputs adalah pendekatan untuk membatasi bentuk keluaran model agar mengikuti struktur yang ditentukan, biasanya menggunakan skema seperti JSON Schema. Fitur dengan nama dan dukungan yang berbeda tersedia pada sejumlah platform AI, tetapi prinsip dasarnya sama: tentukan bentuk data yang dibutuhkan, lalu minta model mengisi bentuk tersebut. Ini berguna untuk ekstraksi informasi, klasifikasi tiket, ringkasan terstruktur, dan integrasi AI dengan API.

Mengapa prompt saja tidak cukup?

Instruksi seperti “jawab hanya dengan JSON yang valid” membantu, tetapi bukan jaminan. Model masih mungkin menambahkan kalimat pembuka, menghilangkan properti, mengubah tipe nilai, atau mengembalikan nilai yang tidak sesuai harapan. JSON yang sintaksnya benar pun belum tentu memenuhi kebutuhan aplikasi: misalnya, kolom harga berisi teks “murah” padahal sistem mengharapkan angka.

Structured Outputs memisahkan dua hal: isi yang diprediksi model dan bentuk data yang harus dipenuhi. Jika platform mendukung pembatasan keluaran berbasis skema, model dapat diarahkan lebih ketat daripada sekadar instruksi dalam prompt. Namun, dukungan terhadap kata kunci JSON Schema tidak seragam. Periksa dokumentasi penyedia model dan jangan menganggap setiap skema kompleks pasti didukung.

Menentukan skema yang tepat

Mulailah dari data yang benar-benar diperlukan aplikasi. Misalnya, fitur katalog perlu menerima nama produk, harga, dan status ketersediaan. Skema sederhana bisa terlihat seperti berikut:

{
  "type": "object",
  "properties": {
    "nama_produk": { "type": "string" },
    "harga": { "type": "number" },
    "tersedia": { "type": "boolean" }
  },
  "required": ["nama_produk", "harga", "tersedia"],
  "additionalProperties": false
}

Contoh ini menggambarkan struktur yang diinginkan, bukan jaminan bahwa semua endpoint menerima konfigurasi persis sama. Properti wajib mengurangi risiko data hilang, sedangkan pembatasan properti tambahan membantu menjaga bentuk respons tetap stabil. Jika sebuah nilai boleh tidak diketahui, tentukan dengan jelas apakah nilainya boleh null, harus berupa string kosong, atau perlu menggunakan status khusus.

Hindari skema yang terlalu longgar seperti satu objek dengan banyak kolom opsional tanpa aturan. Sebaliknya, jangan pula membuat semua hal wajib jika sumber data sering tidak lengkap. Skema yang baik mencerminkan kebutuhan bisnis dan kondisi nyata data, bukan sekadar membuat respons tampak rapi.

Alur implementasi yang praktis

1. Definisikan kontrak data. Tentukan nama properti, tipe, nilai yang diperbolehkan, serta kolom yang wajib ada. Diskusikan kontrak ini dengan pengembang yang akan memakai hasilnya.
2. Kirim skema ke API yang mendukungnya. Gunakan mekanisme Structured Outputs atau mode keluaran terstruktur yang didokumentasikan penyedia. Jangan hanya menempelkan skema ke prompt jika API sebenarnya menyediakan parameter khusus.
3. Berikan konteks dan aturan ekstraksi. Jelaskan sumber mana yang harus dibaca, bagaimana menangani informasi yang tidak disebutkan, dan kapan model tidak boleh menyimpulkan nilai.
4. Validasi di sisi aplikasi. Periksa struktur dan tipe data dengan validator yang sesuai. Validasi tetap penting, terutama ketika keluaran akan disimpan, dipakai untuk keputusan, atau diteruskan ke layanan lain.
5. Tangani kegagalan dengan eksplisit. Bedakan respons yang selesai, penolakan model, keluaran terpotong, batas waktu, dan kesalahan API. Jangan menganggap semua respons yang bukan error HTTP sebagai data yang siap dipakai.

Structured Outputs bukan verifikasi fakta

Struktur yang valid tidak berarti informasinya benar. Model masih bisa menghasilkan harga yang keliru, mengklasifikasikan keluhan secara salah, atau mengisi kolom dengan dugaan. Skema memastikan bentuk data, bukan kebenaran semantik. Karena itu, gunakan aturan bisnis untuk memeriksa rentang nilai, cocokkan hasil dengan sumber tepercaya, dan minta peninjauan manusia untuk keputusan berdampak tinggi.

Perlakukan teks dari pengguna dan dokumen eksternal sebagai masukan yang mungkin berisi instruksi berbahaya. Jangan biarkan nilai keluaran model langsung menjadi perintah SQL, kode, atau tindakan sensitif. Gunakan parameterisasi, kontrol izin, daftar nilai yang diizinkan, serta konfirmasi tambahan sebelum melakukan tindakan yang sulit dibatalkan. Keluaran terstruktur membantu integrasi, tetapi bukan pengganti kontrol keamanan.

Pengujian dan pemeliharaan skema

Uji dengan contoh normal, data kosong, ejaan yang ambigu, informasi bertentangan, teks panjang, dan kasus ketika jawabannya memang tidak tersedia. Catat tingkat kegagalan validasi, jumlah respons yang perlu diperbaiki, latensi, dan biaya. Ukuran keberhasilan bukan hanya seberapa sering JSON berhasil diparse, tetapi juga seberapa berguna serta akurat nilai di dalamnya.

Ketika skema berubah, perlakukan perubahan itu seperti perubahan kontrak API. Menambah kolom opsional biasanya lebih mudah ditangani daripada mengganti nama kolom wajib atau mengubah tipe angka menjadi string. Beri versi pada skema bila banyak layanan bergantung padanya, dan uji kompatibilitas sebelum menerapkannya ke produksi.

Untuk alur yang memanggil fungsi atau alat, bedakan keluaran JSON biasa dari tool calling. Structured Outputs mengatur format data; tool calling meminta model memilih atau menyusun pemanggilan alat sesuai mekanisme platform. Keduanya dapat dipakai bersama, tetapi izin menjalankan alat harus tetap dikendalikan aplikasi.

Kapan pendekatan ini paling berguna?

Gunakan keluaran terstruktur ketika aplikasi memerlukan kolom yang konsisten: mengubah faktur menjadi data, mengelompokkan tiket dukungan, mengekstrak detail dari dokumen, atau mengirim hasil analisis ke sistem lain. Untuk percakapan bebas yang dibaca manusia, format ketat mungkin tidak diperlukan dan justru mengurangi keluwesan jawaban.

Sebelum memilih platform, bandingkan dukungan skema, cara menangani penolakan dan respons terpotong, batasan tipe data, serta biaya validasi tambahan. Buat prototipe kecil dengan data nyata yang sudah disamarkan, lalu ukur hasilnya. Jangan memilih hanya berdasarkan contoh demo yang selalu berhasil.

Kesimpulan

Structured Outputs membuat integrasi AI lebih terprediksi dengan menetapkan bentuk respons sejak awal. Hasil terbaik datang dari kombinasi skema yang dirancang dengan baik, instruksi yang jelas, validasi aplikasi, pengujian kasus tepi, dan kontrol keamanan. Anggap keluaran terstruktur sebagai kontrak format—bukan bukti bahwa setiap jawaban benar. Dengan batasan itu dipahami, AI lebih mudah dipadukan ke alur kerja digital tanpa mengorbankan keandalan sistem.