Kalau aplikasi kamu langsung memakai jawaban AI, bentuk yang rapi bisa memberi rasa aman yang keliru. Bayangkan model diminta mengambil status peluncuran, lalu mengisi status dengan available saat sumber mengatakan “akan tersedia”. Datanya bisa terbaca tanpa kesalahan, tetapi keputusan aplikasi tetap salah.
Bentuk data yang tersusun dalam pasangan nama dan nilai sering disebut JSON. Alat pembacanya, atau parser, memeriksa apakah bentuk itu bisa dibaca. Structured Outputs membantu membatasi keluaran model agar mengikuti aturan bentuk data, atau skema, yang didukung.
Aturan bentuk tetap perlu dilengkapi pemeriksaan fakta dan aturan kerja aplikasi. Kita akan menyusun kontrak ekstraksi redaksi dengan tiga lapisan: cara penulisan atau sintaks, susunan data atau struktur, dan makna. Skema serta data di sini adalah contoh rancangan Nalarku.
Mulai dari kebutuhan aplikasi yang menerima hasil
Tentukan data yang benar-benar dibutuhkan langkah berikutnya. Untuk mengisi kartu produk, misalnya, aplikasi mungkin membutuhkan nama, status akses, tanggal sumber, dan daftar bukti. Permintaan “semua informasi penting” belum menjelaskan bentuk hasil yang harus diterima.
Bedakan informasi yang belum diketahui dari yang tidak berlaku. Teks kosong, bagian data atau field yang hilang, dan nilai null belum tentu punya arti sama. Saat sumber tidak menyebut tanggal ketersediaan, null dengan arti yang jelas lebih aman daripada menebak dari tanggal terbit artikel.
Simpan versi kontrak di dalam atau di luar objek data. Arti field yang berubah bisa merusak hubungan antarbagian aplikasi meski tipe datanya tetap teks atau string. Contohnya, available yang awalnya berarti bisa mendaftar daftar tunggu tidak boleh diam-diam berubah arti menjadi bisa langsung memakai produk.
Skema memeriksa susunan data
Referensi JSON Schema membedakan daftar properti properties, daftar yang wajib ada required, dan izin properti tambahan additionalProperties. Mendefinisikan properti belum otomatis membuatnya wajib. Penyedia bisa hanya mendukung sebagian aturan JSON Schema, jadi cocokkan dengan dokumentasi alamat layanan atau endpoint yang kamu pakai.
{
"type": "object",
"properties": {
"schema_version": {"type": "string", "enum": ["1"]},
"product": {"type": "string"},
"access": {
"type": "string",
"enum": ["announced", "private_preview", "public", "unknown"]
},
"availability_date": {"type": ["string", "null"]},
"evidence_ids": {"type": "array", "items": {"type": "string"}}
},
"required": [
"schema_version", "product", "access",
"availability_date", "evidence_ids"
],
"additionalProperties": false
}
Contoh ini adalah objek skema. Untuk memanggil layanan, aplikasi masih perlu menaruhnya pada field yang sesuai dengan antarmuka atau API dan model yang didukung. Kamu bisa mempelajari alat pemeriksa lokalnya tanpa memanggil layanan berbayar.
Setelah bentuknya benar, periksa maknanya
Pemeriksaan arti dan hubungan nilai disebut validasi semantik. Tanggal 2026-02-31 tampak mengikuti pola tahun-bulan-hari dalam format ISO, tetapi tidak valid. ID bukti S99 juga terlihat wajar meski mungkin tidak ada di aplikasi.
Contoh berikut memeriksa beberapa aturan itu:
from datetime import date
def validate_release(data, known_evidence):
errors = []
if not data["product"].strip():
errors.append("Nama produk kosong")
if data["availability_date"] is not None:
try:
parsed = date.fromisoformat(data["availability_date"])
if parsed.isoformat() != data["availability_date"]:
errors.append("Gunakan tanggal YYYY-MM-DD")
except ValueError:
errors.append("Tanggal tidak valid")
refs = data["evidence_ids"]
if len(refs) != len(set(refs)):
errors.append("ID bukti berulang")
if any(ref not in known_evidence for ref in refs):
errors.append("Ada bukti yang tidak ditemukan")
if data["access"] != "unknown" and not refs:
errors.append("Status pasti memerlukan bukti")
return errors
Fungsi ini menganggap struktur data sudah diperiksa. Ia belum membaca isi bukti. Status public dengan sumber yang hanya mengatakan private_preview tetap perlu pemeriksaan apakah klaim benar-benar mengikuti isi sumber, atau entailment, maupun peninjauan manusia.
Pisahkan pesan kesalahan teknis dari alasan redaksi. Dengan begitu, pengguna tahu apakah yang perlu diperbaiki adalah bentuk data atau dasar klaimnya.
Siapkan jalur untuk penolakan dan jawaban terpotong
Model dapat menolak menjawab, yang disebut refusal. Dokumentasi OpenAI menjelaskan bahwa penolakan bisa muncul di luar bentuk jawaban yang diminta. Jawaban yang berhenti karena batas panjang keluaran juga belum boleh dianggap sebagai objek selesai.
Penanganannya bergantung pada bungkus respons layanan, atau envelope, dari endpoint yang dipakai. Buat lapisan penyesuai atau adapter yang menghasilkan status aplikasi seperti completed, refused, incomplete, atau failed. Mulai membaca JSON dan memeriksa datanya setelah status completed.
Jangan mengembalikan objek kosong hanya agar langkah berikutnya terus berjalan. Jika hasil belum lengkap, simpan alasan lalu tentukan apakah perlu mencoba ulang atau retry dengan masukan lebih terfokus atau batas jawaban yang sesuai. Meminta “hasilkan JSON yang benar” saja bisa memperbaiki bentuk sambil mengarang isi, jadi pertahankan sumber awal dan catat tiap percobaan.
Data yang menyebut tindakan belum memberi izin bertindak
Objek {"action":"publish"} tetap berupa data. Aplikasi pelaksana yang harus memeriksa izin publikasi. Daftar pilihan nilai, atau enum, membatasi variasi jawaban tanpa memberi model wewenang untuk menjalankan tindakan.
Tindakan juga perlu aman saat permintaan yang sama diulang, sifat yang disebut idempotensi. Tiap lapisan punya pemeriksaan dan batasnya sendiri:
| Lapisan | Yang diperiksa | Yang belum dijamin |
|---|---|---|
| Pembaca JSON | Data bisa dibaca | Susunannya sesuai kebutuhan |
| Pemeriksa skema | Field dan tipe data cocok | Nilai didukung sumber |
| Pemeriksa makna | Aturan antarfield dan rujukan terpenuhi | Semua bukti ditafsirkan dengan benar |
| Pemeriksaan redaksi | Klaim dan konteks sesuai | Ada izin untuk tindakan di luar aplikasi |
| Pelaksana tindakan | Izin, versi, dan idempotensi | Mutu seluruh isi |
Pemisahan ini membantu kamu menangani kegagalan sesuai penyebabnya. Bukti yang salah tidak perlu dilaporkan sebagai “JSON error”.
Ubah skema tanpa mengubah arti arsip lama
Jika menambah status regional_preview, jangan langsung mengubah arti data lama. Tambahkan versi kontrak, adapter pembaca, dan contoh data uji atau fixture untuk kedua versi. Aplikasi lama perlu pilihan jelas: menolak versi baru atau memetakannya ke kategori yang aman.
Uji field tambahan, ID bukti hilang, tanggal mustahil, dan status tanpa sumber. Sertakan penolakan serta keluaran terpotong. Bandingkan tingkat kebenaran struktur dengan ketepatan fakta, karena keduanya bisa berubah ke arah berbeda saat instruksi model atau prompt dan model berganti.
Untuk latihan, ambil sepuluh dokumen pengumuman dan buat label acuan sebelum menjalankan model. Catat kesalahan per field agar kelemahan pada tanggal, syarat akses, atau pemberian rujukan terlihat. Panduan evaluasi dan regresi membantu memeriksa apakah kontrak itu sudah cukup baik untuk pekerjaan nyata.