Rantai pengambilan keputusan berbiaya tinggi dalam sistem AI

Biaya online akan naik. Dalam banyak kasus, bukan hanya harga satuan token yang mahal, tetapi juga masalah serupa yang perlu diperiksa berulang kali. Di permukaan, Anda mungkin mengira Anda membeli layanan inferensi, namun kenyataannya, Anda membeli sistem yang perilakunya dapat berubah kapan saja. Jika terjadi kesalahan, Anda tidak akan dapat menghasilkan rangkaian bukti yang lengkap.

Inilah mengapa saya semakin tidak mempercayai algoritma “AI unit = token”.

Untuk panggilan yang sama, perbedaan antara yang dapat direproduksi dan tidak dapat direproduksi menentukan apa yang harus dibayar dalam rangkaian biaya teknis, biaya peninjauan, dan biaya kepatuhan berikut ini.

Bagaimana keadaan menjadi tidak terkendali

Pada awalnya, analisis biaya kami sangat sederhana, dan semua akun dapat ditempatkan dalam satu baris:

-Harga satuan token

• Jumlah token masukan dan keluaran
• Volume panggilan

Setelah laporan dibuat, terlihat sangat indah, dengan kurva pengurangan biaya yang jelas, dan bahkan dapat memberi tahu dunia luar “berapa penurunan biaya per unit”.

Masalah sebenarnya terjadi pada minggu kedua setelah peluncuran.

Staf layanan pelanggan mulai melaporkan, “Terkadang pertanyaan yang sama dapat dijawab dengan benar, dan terkadang dapat dijawab dengan salah.” Produk bertanya, “Apakah modelnya semakin buruk?” Reaksi pertama kami adalah melihat versi modelnya, namun ternyata versi modelnya tidak dipindahkan.

Kemudian kami melihat kata prompt, dan kata prompt tidak bergerak.

Melihat log lebih jauh, saya menemukan bahwa permintaan ini sebenarnya melalui perutean multi-model, mengenai model yang berbeda dari pemasok yang berbeda, dan panggilan alat tidak konsisten. Yang lebih buruk lagi adalah log pada saat itu hanya mencatat “hasil akhir” dan tidak mencatat alasan keputusan perutean pada saat itu, juga tidak menyimpan snapshot konteks.

Jadi masalah seperti ini akan menjadi jalan buntu pemecahan masalah yang sangat umum:

• Tidak dapat direproduksi
• Tidak dapat diatribusikan
• Hanya bisa menebak

Biasanya ada dua hasil tebakan, keduanya salah:

1. Atribusikan masalah ke “model keacakan”, lalu gunakan pendinginan dan hukuman untuk menekannya.
2. Atribusikan masalahnya pada “kata perintah tidak ditulis dengan baik”, dan kemudian mulailah menumpuk instruksi hingga kata perintah menjadi sistem lain yang tidak dapat dikendalikan.

Kedua pendekatan ini akan membuat token lebih mahal di akun, namun tidak membuat sistem lebih terkendali.

Jenis biaya ini akan menghabiskan anggaran

Biaya token bersifat linier: panggilan yang biayanya 10% lebih mahal mungkin sebenarnya memerlukan biaya 10% lebih mahal.

Biaya non-reprodusibilitas bersifat eksponensial karena hal ini akan memperkuat proses pemrosesan setiap masalah online:

• Waktu pemecahan masalah bertambah dari 30 menit menjadi 3 jam karena permintaan yang sama tidak dapat diputar ulang secara lokal.
• Keputusan rollback lebih lambat karena tidak diketahui model rollback, rute rollback, atau alat rollback yang mana.
• Pengumpulan bukti kepatuhan menjadi sulit karena tidak mungkin menjawab “mengapa kesimpulan ini dikeluarkan pada saat itu dan masukan apa yang mendasarinya.”
• Biaya pengerjaan ulang menjadi lebih tinggi karena penambalan harus dilakukan dengan “menambahkan lebih banyak pagar pembatas”, namun pagar pembatas itu sendiri juga memerlukan pemeliharaan.

Hal yang paling tersembunyi adalah bahwa mereka sering kali terpaksa menginvestasikan banyak sumber daya teknis untuk “menstabilkan perilaku online” alih-alih berinvestasi untuk “meningkatkan kemampuan”.

Hal ini juga menunjukkan bahwa banyak tim semakin suka mempertahankan sistem aturan yang kompleks. Pada akhirnya, mereka tidak menabung atau menjadi lebih pintar.

Saya menghitung ulang unit AI menjadi apa?

Jika Anda hanya menghitung “unit AI” sebagai token, Anda akan sering mengoptimalkan serangkaian strategi yang sangat berbahaya:

• Untuk menghemat uang, lakukan perutean dan penurunan versi yang lebih agresif.
• Untuk menghemat uang, pindahkan lebih banyak logika ke dalam petunjuk dan alat.
• Untuk menghemat uang, serahkan lebih banyak penilaian pada model untuk “memutuskan secara otomatis”.

Hal ini mendorong sistem ke arah “tidak dapat direproduksi”.

Saya lebih suka membagi unit AI menjadi dua bagian:

1. Unit inferensi: token, penundaan, throughput.
2. Unit bukti: Berapa biaya penelusuran yang diperlukan untuk suatu keputusan.

Unit penalaran memecahkan “berapa biaya menjalankannya”.

Unit bukti membahas “berapa biaya yang harus dikeluarkan jika terjadi kesalahan.”

Yang paling mahal sering kali adalah yang kedua.

Rantai pengambilan keputusan yang dapat direproduksi, setidaknya seperti apa bentuknya

Saya menganggapnya sebagai “buku besar”, dan setiap permintaan harus dapat merangkai simpul-simpul kunci.

Setidaknya jenis bidang ini diperlukan. Jika salah satu dari mereka hilang, tautannya akan terputus karena suatu kecelakaan:

• Keputusan Perutean: Model mana yang terkena dampak, alasannya, kandidat apa, dan apakah akan diturunkan peringkatnya.
• Versi kata cepat: sistem + pengembang + nomor versi templat, parameter utama.
• Context Snapshot: Berpartisipasi dalam ringkasan hasil pencarian, versi dokumen, dan hasil pemfilteran izin yang dihasilkan.
• Rantai panggilan alat: Alat mana yang dipanggil, apa saja parameter inputnya, apa yang dikembalikan, dan berapa lama waktu yang diperlukan.
• Output dan pasca-pemrosesan: output akhir, aturan pemfilteran tercapai, alasan penolakan (jika penolakan).

Saya sengaja tidak menganggap “konteks teks lengkap” sebagai item wajib di sini, karena banyak skenario tidak dapat disimpan, atau risiko kepatuhannya terlalu besar jika disimpan.

Namun setidaknya pastikan bahwa hal tersebut dapat diputar ulang ke “jalur keputusan yang sama” jika perlu.

Kesalahpahaman paling umum

Kesalahpahaman 1: Mengandalkan suhu untuk menekan keacakan

Keacakan bukanlah masalah inti.

Masalah sebenarnya adalah: Saya bahkan tidak bisa menjelaskan dari mana keluaran ini berasal. Menurunkan suhu hanya menjadikannya “lebih seperti kotak hitam yang stabil”.

Kesalahpahaman 2: Perlakukan prompt sebagai pusat konfigurasi

Ketika prompt membawa lebih banyak aturan bisnis, itu bukan lagi kata prompt, tetapi “konfigurasi runtime” tanpa sistem tipe, tanpa tes, dan tanpa mekanisme rollback.

Ini secara langsung akan menaikkan unit bukti.

Kesalahpahaman 3: Hanya ingat hasil akhir, bukan jalur perantara

Mengingat hasilnya saja sama dengan mengubah pemecahan masalah menjadi “menebak”.

Banyak masalah online disebabkan oleh kesalahan panggilan alat tertentu, kesalahan pencarian tertentu, atau kesalahan penurunan versi rute tertentu. Jika Anda tidak mencatat jalurnya, Anda akan selalu dapat menyimpulkan dari hasilnya, dan inferensi ke belakang biasanya tidak dapat dilakukan.

Batasan yang berlaku

Tidak semua sistem memerlukan buku besar yang lengkap untuk setiap permintaan.

Saya akan menggunakan tiga kondisi untuk memutuskan apakah akan menyertakan unit bukti:

• Apakah keluaran ini akan memasuki lingkaran tertutup bisnis (memengaruhi transaksi, persetujuan, pengendalian risiko, dan komitmen eksternal)?
• Apakah keluaran ini dapat dipertanggungjawabkan oleh pengguna atau audit eksternal.
• Jika keluaran ini salah, apakah biaya perbaikannya lebih tinggi daripada biaya satu inferensi?

Jika dua dari tiga kondisi tersebut terpenuhi, saya akan menganggap “rantai keputusan yang dapat direproduksi” sebagai prioritas pertama pengendalian biaya.

Ringkasan

Token adalah biaya eksplisit, dan ketidakberulangan adalah pajak implisit.

Sistem AI yang benar-benar hemat biaya mengubah setiap perilaku online menjadi rantai bukti yang dapat dilacak.

Yang terselamatkan adalah malam-malam saat kecelakaan berikutnya.