Structured Output: Meminta JSON Rapi dari LLM

· Tim GunaStudio

LLM Tools

Meminta model bahasa menjawab pertanyaan itu mudah, tetapi mengambil hasilnya dan memasukkannya ke sistem lain sering jadi masalah. Kalau jawabannya berupa paragraf bebas, program harus menebak mana nama, mana tanggal, dan mana status. Structured output menawarkan jalan keluar: kamu memberi tahu model bentuk data yang kamu inginkan, lalu model diminta mengikutinya.

Masalah dengan jawaban teks bebas

Saat kamu meminta model mengembalikan informasi, cara termudah adalah membiarkannya menjawab dengan kalimat biasa. Pendekatan ini nyaman dibaca manusia, tetapi merepotkan begitu hasilnya harus diolah program. Kamu perlu mencari pola, memotong string, atau menebak urutan kalimat. Setiap kali model mengubah gaya bahasanya sedikit saja, kode pemrosesmu bisa patah.

Masalah makin terasa ketika data harus masuk ke struktur tetap seperti tabel, API, atau basis data. Kolom bernilai angka tidak boleh terisi kalimat, dan tanggal harus punya format konsisten. Tanpa aturan bentuk, kamu menyerahkan pekerjaan rapi-rapi ke fungsi parsing yang rapuh. Inilah alasan banyak tim memilih memaksa model mengeluarkan JSON sejak awal.

Ide di balik structured output

Structured output adalah cara memberi model sebuah cetak biru bentuk data. Alih-alih hanya mengirim pertanyaan, kamu juga mengirim skema yang menjelaskan field apa saja yang harus ada, tipe datanya, dan mana yang wajib. Model lalu diminta menghasilkan jawaban yang mengikuti skema itu.

Pada Gemini API, kamu bisa mengatur tipe keluaran menjadi JSON dan menyertakan schema respons. Model akan berusaha mengisi field sesuai definisi yang kamu tetapkan. Pada OpenAI, fitur Structured Outputs memakai JSON Schema dan menyediakan mode ketat (strict) yang memastikan keluaran benar-benar mengikuti skema, bukan sekadar mengarah ke sana.

Kuncinya adalah keterikatan pada struktur. Bukan hanya soal JSON yang valid secara sintaks, tetapi soal bentuk data yang kamu definisikan sendiri. Kamu bisa menandai field mana yang opsional dan mana yang harus selalu hadir, sehingga program penerima bisa mengandalkan bentuk datanya tanpa banyak tebak-tebakan.

Contoh skema JSON singkat

Skema tidak perlu rumit untuk mulai berguna. Contoh sederhana untuk data kontak:

{
  "type": "object",
  "properties": {
    "nama": { "type": "string" },
    "email": { "type": "string" },
    "aktif": { "type": "boolean" }
  },
  "required": ["nama", "email"]
}

Skema di atas menyatakan bahwa jawaban harus berupa objek dengan tiga field, dan dua di antaranya wajib ada. Kamu bisa menambah batasan seperti daftar nilai yang diizinkan (enum) untuk memastikan model hanya memilih dari pilihan yang kamu tetapkan. Pendekatan enum sangat berguna untuk kolom kategori atau status yang jumlahnya terbatas.

Kapan memakai structured output

Structured output paling berguna saat hasil model akan dikonsumsi mesin, bukan hanya dibaca orang. Beberapa situasi yang cocok:

  • Mengekstraksi entitas dari teks, misalnya nama, alamat, atau nomor.
  • Mengisi formulir otomatis dari percakapan bebas.
  • Mengklasifikasikan tiket dukungan ke kategori tetap.
  • Menyiapkan data untuk dipanggil ke API lain.

Sebaliknya, kalau tujuanmu adalah penjelasan, ringkasan, atau tulisan kreatif yang dibaca manusia, memaksa skema kaku justru bisa mengurangi kualitas jawaban. Model yang terlalu dikurung pada bentuk tertentu kadang kehilangan keluwesan dalam menyampaikan nuansa. Jadi pikirkan dulu apakah hasilnya memang akan diproses program atau tidak.

Keterbatasan yang perlu diketahui

Perlu diingat bahwa dukungan skema biasanya hanya sebagian dari JSON Schema. Tidak semua kata kunci atau fitur canggih didukung, jadi baca batasannya di dokumentasi penyedia. Kalau skema kamu memakai fitur yang tidak didukung, permintaan bisa gagal, atau fitur itu diabaikan tanpa kamu sadari.

Ada juga kemungkinan model tidak bisa memenuhi permintaan karena alasan keamanan atau kesulitan. Beberapa penyedia menyediakan jalur khusus untuk menandai penolakan semacam itu. Artinya, keluaran tidak selalu berupa data yang kamu harapkan, sehingga kode pemanggil harus siap menangani dua kemungkinan: data berhasil atau penolakan.

Tip validasi di sisi aplikasi

Beberapa kebiasaan praktis berikut membantumu memakai structured output dengan aman:

  1. Mulai dari skema sesederhana mungkin, lalu tambah field hanya saat perlu.
  2. Tandai dengan jelas field mana yang wajib dan mana yang opsional.
  3. Gunakan enum untuk nilai yang seharusnya terbatas.
  4. Tetap validasi hasil di sisi aplikasi, jangan percaya penuh.
  5. Tangani kemungkinan model menolak atau tidak bisa menjawab.
  6. Simpan skema bersama kode agar setiap perubahan terlacak.

Poin keempat penting. Walaupun model diminta mengikuti skema, lapisan validasi di aplikasimu tetap jaring pengaman terakhir. Validasi menangkap kasus tepi, perubahan versi model, atau perbedaan perilaku antar model. Dengan begitu, kegagalan terdeteksi sebelum data rusak masuk ke sistem.

Validasi juga membantu saat skema berevolusi. Andaikan kamu menambah field baru di kemudian hari, validasi lama bisa dipakai untuk menguji mundur apakah perubahan itu masih cocok dengan data yang sudah ada. Ini menjaga kompatibilitas dan memudahkan pelacakan bila ada yang tidak sesuai.

Satu hal yang sering terlewat adalah menguji skema pada model yang berbeda. Karena tiap penyedia punya tingkat dukungan fitur yang tidak sama, skema yang mulus di satu model bisa bermasalah di model lain. Kalau aplikasimu memakai lebih dari satu penyedia, jalankan uji yang sama pada keduanya dan bandingkan tingkat keberhasilannya. Dengan begitu, kamu tahu batas tiap model sebelum memutuskan mana yang dipakai untuk tugas tertentu.

Menyatukan ke alur kerja

Menggabungkan structured output dengan alur kerja biasa sangat mungkin. Kamu mengirim prompt dan skema, menerima JSON, memvalidasi, lalu meneruskan ke komponen berikutnya. Pola ini membuat integrasi lebih dapat diprediksi dan lebih mudah diuji, karena bentuk data sudah pasti sejak awal.

Untuk sistem yang menangani banyak data, kebiasaan ini menghemat waktu debug sekaligus membuat kode lebih rapi. Kamu tidak lagi menulis parser khusus untuk tiap variasi jawaban. Sebaliknya, kamu berfokus pada logika bisnis, sementara bentuk data sudah dijaga oleh skema dan validasi.