OpenAI Decisions API: mengubah penilaian AI menjadi alur kerja yang dapat diprediksi

Aplikasi AI semakin baik dalam menghasilkan teks, kode, dan penjelasan. Namun, masalah produksi sering kali lebih sempit: apakah pesan ini harus diarahkan ke tim penagihan atau dukungan teknis, apakah gambar menunjukkan kerusakan, dan seberapa parah sebuah masalah dalam skala yang sudah ditentukan? OpenAI Decisions API kini tersedia secara umum untuk pertanyaan terbatas seperti ini, bukan untuk generasi terbuka.

Perbedaannya penting. Jawaban umum bisa terlihat bagus tetapi sulit divalidasi. Endpoint keputusan berguna ketika aplikasi membutuhkan jawaban bertipe, distribusi probabilitas, atau skor yang menentukan langkah berikutnya. Panduan Decisions resmi dan referensi pembuatan keputusan menjelaskan evaluasi teks, gambar, dan JSON melalui pertanyaan predikat, pilihan, dan skor.

Perubahan utamanya adalah lapisan penilaian bertipe

Banyak tim sudah memiliki prompt seperti “klasifikasikan permintaan ini”. Titik lemahnya belum tentu model, melainkan kontrak di sekelilingnya. Jika prompt dapat mengembalikan paragraf bebas, kode berikutnya harus menafsirkan prosa, menebak tingkat keyakinan, dan menentukan cara menangani kasus di luar pola.

Decisions API membuat pertanyaannya eksplisit. Predikat memeriksa apakah suatu kondisi benar dan mengembalikan probabilitas. Pilihan memilih salah satu nilai yang ditentukan, seperti billing, technical, atau other. Skor menilai input berdasarkan tingkat berurutan, misalnya masalah kosmetik, tersedia solusi sementara, atau tugas sepenuhnya terblokir. Hasilnya tetap bersifat probabilistik, tetapi bentuknya dapat diperiksa aplikasi sebelum bertindak.

Dengan begitu, AI berubah dari panggilan model yang terisolasi menjadi batas kebijakan kecil. Aplikasi menentukan hasil yang diperbolehkan, penjelasan yang membedakan kategori, dan kapan kasus harus dikirim ke pemeriksaan manusia.

Jenis pertanyaan yang dapat dijawab

Kasus paling jelas adalah perutean. Pesan dukungan dapat dikirim dengan pertanyaan pilihan lalu diarahkan ke antrean yang benar, sambil mempertahankan other untuk permintaan di luar taksonomi. Alur moderasi dapat memakai predikat untuk memeriksa atribut yang terlihat. Tim operasi dapat memakai skor untuk memprioritaskan masalah berisiko tinggi.

Kemampuan gambar juga penting karena setiap pertanyaan dapat menerima buktinya sendiri. Input bersama dapat berisi gambar referensi, sementara pertanyaan berbeda membandingkan gambar kandidat. Ini cocok untuk pemeriksaan produk, pembersihan katalog, peninjauan dokumen, dan kontrol kualitas visual. Input JSON juga didukung sehingga data terstruktur tidak perlu diubah menjadi string panjang.

Panduan terbaru menyebutkan beberapa peningkatan praktis: input bersama dapat di-cache, satu permintaan dapat memuat hingga 400 pertanyaan, dan gambar dapat dikirim melalui URL HTTP/HTTPS publik atau data base64 inline. Fitur ini tidak menggantikan evaluasi, tetapi membuat layanan keputusan batch lebih mudah dirancang.

Posisi API ini dalam arsitektur produksi

Decisions API bukan pengganti semua panggilan model. Gunakan Decisions ketika jawabannya berupa predikat, pilihan tetap, atau skor berurutan. Gunakan Structured Outputs dengan Responses API ketika membutuhkan objek lebih kaya yang mengikuti JSON Schema sendiri. Gunakan function calling ketika model perlu meminta alat dengan argumen.

Alur yang praktis adalah mengumpulkan dan menormalkan bukti, membuat pertanyaan sempit yang tidak tumpang tindih, menerapkan ambang terkalibrasi di kode aplikasi, mengirim kasus tidak pasti ke manusia atau jalur penalaran yang lebih luas, lalu menyimpan versi pertanyaan, probabilitas, dan tindakan akhir untuk evaluasi berikutnya.

Jalur pemeriksaan adalah pengaman. Keyakinan bukan jaminan. Probabilitas tinggi tetap bisa salah jika taksonomi tidak lengkap atau buktinya ambigu. API seharusnya membuat ketidakpastian dapat dikelola, bukan menyembunyikannya di balik kalimat yang terdengar yakin.

Cara memulai dengan kasus nyata

Mulailah dari kumpulan kecil data berlabel yang berasal dari alur kerja sebenarnya, lalu catat biaya false positive dan false negative. Definisikan pertanyaan berdasarkan kriteria yang dapat diamati. Jika dua kategori tumpang tindih, perbaiki deskripsinya sebelum menambah kompleksitas model.

Untuk perutean dukungan, mulai dengan empat atau lima antrean dan fallback yang jelas. Untuk inspeksi visual, gunakan satu predikat untuk setiap kondisi independen, bukan satu pertanyaan besar yang mencampur kerusakan, kategori, dan tingkat keparahan. Untuk prioritas, tetapkan dua sampai sepuluh tingkat berurutan dan jelaskan perbedaan antar tingkat yang berdekatan.

Pantau juga perubahan data. Nama produk, kebijakan dukungan, dan distribusi gambar akan berubah. Simpan sampel untuk ditinjau, bandingkan jawaban model dengan label manusia, dan sesuaikan ambang ketika biaya kesalahan berubah. Untuk menemukan perangkat lunak terkait, kunjungi katalog software BTTC atau blog teknologi BTTC.

Batasan dan perlindungan

Jawaban bertipe bukan fakta yang sudah diverifikasi. Jangan mengizinkan tindakan yang tidak dapat dibatalkan hanya berdasarkan probabilitas. Simpan kredensial di server, validasi semua nilai yang dikembalikan, catat model dan versi pertanyaan, serta lindungi gambar dan data pelanggan sesuai persyaratan privasi.

Deskripsi yang dikirim ke model juga harus bisa ditinjau oleh pemilik proses. Jika tim bisnis tidak dapat menjelaskan mengapa input masuk ke sebuah kategori, model tidak akan menjadikan kebijakan itu lebih jelas dengan sendirinya.

Pertanyaan yang sering diajukan

Apakah Decisions API sama dengan Structured Outputs?

Tidak. Decisions ditujukan untuk predikat, pilihan tetap, dan skor berurutan. Structured Outputs cocok untuk objek yang lebih kompleks dengan schema sendiri.

Apakah API ini dapat menganalisis gambar?

Ya. Gambar dapat berada di input bersama atau instruksi pertanyaan tertentu.

Haruskah setiap jawaban langsung menjalankan tindakan otomatis?

Tidak. Gunakan data berlabel untuk mengatur ambang dan pertahankan fallback atau pemeriksaan manusia.

Apa manfaatnya bagi tim software kecil?

API ini mengurangi kode penghubung yang diperlukan untuk mengubah penilaian model menjadi cabang yang dapat diprediksi. Tim dapat memulai dari satu alur kecil, mengukurnya, lalu memperluas berdasarkan bukti.

Kesimpulan

Decisions API mendekatkan AI multimodal dengan logika aplikasi biasa. Pengembang dapat mendefinisikan pertanyaan bertipe dan menjaga ketidakpastian tetap terlihat. Ini adalah pola praktis untuk perutean dukungan, inspeksi gambar, dan triase, ketika tindakan berikutnya lebih penting daripada paragraf yang indah.