Produksi End-to-End: Verifikasi, Pemantauan dan Etika — API, Biaya dan Integrasi

Keuntungan:

Dapat merancang arsitektur end-to-end yang mengambil fitur LLM dari ide hingga produksi
Menetapkan lapisan penegakan verifikasi, persetujuan manusia, dan pelacakan (logging/metrik)
Batasan menerjemahkan prinsip etika dan privasi ke dalam keputusan produksi

Dalam sepuluh unit sebelumnya, kita mempelajari bagian-bagiannya satu per satu: struktur permintaan, ekonomi token, aliran, perintah sistem, pemilihan model, cache, batch, manajemen kesalahan, kunci aman, dan otomatisasi. Pada unit terakhir ini, kami menggabungkan bagian-bagian dan membangun arsitektur holistik yang mengusung fitur LLM mulai dari ide hingga produksi. Produksi berbeda dengan “demokrasi kerja”: verifikasi bersifat wajib, keluaran harus dipantau, batasan dan prinsip etika harus tertanam dalam keputusan. Unit ini adalah kolom pembawa modul; Semua yang sebelumnya berkumpul di sini.

Lapisan Arsitektur Produksi

Kualifikasi LLM yang solid terdiri dari sekitar lima lapisan:

Lapisan masukan: Kumpulkan data, bersihkan, tutupi area sensitif, kirimkan hanya yang diperlukan.
Lapisan model: Pilih model yang benar (unit 5), atur prompt sistem dan parameter (unit 4), cache (unit 6).
Lapisan validasi: Periksa keluaran berdasarkan skema/aturan, sumber, dan persetujuan manusia jika perlu.
Lapisan tindakan: Melakukan tindakan dengan keluaran yang divalidasi; Tangkap tindakan berdampak tinggi.
Lapisan pemantauan: Catat dan ukur setiap panggilan, biaya, kesalahan, dan kualitas.

Lapisan-lapisan ini adalah sebuah saluran pipa; masing-masing memeriksa keluaran dari yang sebelumnya.

Mengapa Verifikasi Diperlukan?

LLM dapat menghasilkan keluaran yang lancar tetapi terkadang tidak akurat. Hal ini disebut halusinasi: model mungkin mengarang informasi yang tampaknya benar, namun sebenarnya tidak. Dalam permainan obrolan, hal ini bisa ditoleransi; tidak dapat ditoleransi dalam sistem produksi (faktur, kesehatan, hukum, keuangan). Ternyata, hal itu tidak bisa diandalkan; dikonfirmasi.

Lapisan verifikasi (meningkat berdasarkan dampak):

Validasi format/skema: Apakah output sesuai dengan skema JSON yang diharapkan? (Keluaran terstruktur sebagian besar menjamin hal ini.)
Verifikasi aturan/logika: Apakah nilainya masuk akal? (Apakah jumlahnya negatif, apakah tanggal di masa depan, apakah kategorinya valid?)
Verifikasi sumber: Apakah klaim berdasarkan dokumentasi yang diberikan? Apakah model mengatakan sesuatu yang tidak ada dalam dokumen?
Persetujuan manusia: Seorang ahli meninjau keputusan yang berdampak besar atau ambigu.

Perhatian: "Modelnya sangat bagus, tidak diperlukan verifikasi lebih lanjut" adalah kesalahan produksi yang paling berbahaya. Tidak peduli seberapa bagus modelnya, lapisan verifikasi adalah jaring pengaman dalam pengambilan keputusan yang berdampak besar. Bahkan satu keputusan otomatis yang salah dapat menghabiskan seluruh waktu yang dihemat.

Manusia dalam Lingkaran

Tidak setiap keputusan harus sepenuhnya otomatis. Dalam pendekatan human-in-the-loop, model mempercepat pekerjaan dan manusia menyetujuinya. Keseimbangan yang tepat bergantung pada dampak keputusan dan keandalan model pada tugas tersebut.

Dampak dari keputusan tersebut

Pendekatan

Rendah (saran label, draf)

Otomatisasi penuh; kesalahan itu murah dan dapat dibalik

Sedang (perutean, prioritas)

Otomatisasi + kontrol pengambilan sampel

Tinggi (uang, kontrak, kesehatan, penghapusan)

Persetujuan manusia adalah wajib; model hanya menyarankan

Pemantauan: Anda Tidak Dapat Mengelola Apa yang Tidak Anda Lihat

Dalam produksi, Anda harus memantau setiap panggilan. Tanpa pemantauan, Anda tidak dapat meningkatkan biaya, kualitas, atau mendeteksi masalah secara dini. Metrik utama yang perlu dicatat:

Penggunaan/biaya: Per permintaan dan total token, distribusi model, pembelanjaan harian.
Latensi: Waktu respons rata-rata dan kasus terburuk.
Tingkat kesalahan: tingkat 429/500, percobaan ulang, pengabaian.
Kualitas: Tingkat keluaran yang ditolak pada lapisan verifikasi, tingkat koreksi berdasarkan persetujuan manusia, umpan balik pengguna.

Tip: Jangan menulis data sensitif (informasi pribadi, kunci) ke log pemantauan. Pertimbangkan log dalam lingkup kerahasiaan; rekam dengan menutupi jika perlu (unit 9).

Etika dan Batasan

Tanggung jawab etis merupakan bagian dari keputusan produksi dan juga keakuratan teknis:

Transparansi: Pengguna harus mengetahui apakah mereka sedang berbicara dengan kecerdasan buatan atau manusia.
Keadilan dan bias: Model mungkin mengandung bias dari data yang dilatihnya; Pantau konsekuensi diskriminatif dalam keputusan yang berdampak besar (perekrutan, pemberian kredit).
Kewajiban: Jika keputusan otomatis menyebabkan kerugian, Anda bertanggung jawab; “Model mengatakan demikian” bukanlah suatu pembelaan.
Penerimaan batasan: Model tidak dapat melakukan beberapa tugas dengan andal; tidak mengotomatiskannya juga merupakan keputusan desain.

Templat yang Dapat Disalin

# Daftar periksa validasi (setelah pembuatan keluaran)1) Apakah skemanya valid? (validasi keluaran terstruktur)2) Apakah nilainya masuk akal? (pemeriksaan aturan: rentang, tanggal, enum)3) Apakah klaim berdasarkan sumber? (tolak jika tidak ada dalam dokumen)4) Apakah dampaknya tinggi? → kirim untuk persetujuan manusia5) Jika semua lolos → izinkan tindakan, simpan

# Perintah sistem yang memaksa mengandalkan sumberHanya bergantung pada informasi dalam dokumen yang disediakan. Jangan menambahkan apa pun yang tidak ada dalam dokumen. Jika suatu informasi tidak ada dalam dokumen, tulis "Tidak ditemukan dalam dokumen". Jangan pernah menebak atau mengarang sesuatu.

# Ambang batas persetujuan manusia (aturan keputusan)JIKA tipe_keputusan dalam [uang, kontrak, penghapusan, kesehatan] → persetujuan manusia wajibIF model_trust < ambang batas ATAU validasi "tidak pasti" → kirimkan ke persetujuan manusiaOTHER → penerapan otomatis + kontrol pengambilan sampel

# Templat log jejak (menulis data sensitif){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // data pribadi dan kunci TIDAK PERNAH ditulis

Prompt lemah / Prompt kuat (keandalan produksi)

# LEMAH (tidak ada verifikasi, tidak ada sumber, berlaku otomatis) Evaluasi permintaan ini, buat keputusan pengembalian dana, dan ajukan.

# KUAT (berbasis sumber, menghasilkan rekomendasi, diserahkan kepada persetujuan manusia) Evaluasi permintaan pengembalian ini berdasarkan dokumen kebijakan pengembalian saja. Merekomendasikan keputusan yang disertai justifikasi tetapi tidak dilaksanakan: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}. Jika tidak ada dasar yang jelas dalam dokumen kebijakan, berikan "tidak jelas". Seorang perwakilan akan menyetujui keputusan akhir.

Versi yang kuat; Pendekatan ini mengaitkan keputusan dengan sumbernya, memposisikan model sebagai “penyaran” dan bukan “pelaku”, dan menempatkan langkah yang berdampak besar di belakang persetujuan manusia. Inilah inti dari keandalan produksi.

Tiga Kasus Mini

Kasus 1 — Hari dimana lapisan verifikasi disimpan. Fintech memiliki model yang mengklasifikasikan deskripsi transaksi dan membuat catatan akuntansi otomatis. Mereka menambahkan validasi aturan: setelah model mengeluarkan jumlah yang salah (12.500 bukannya 1.250 dalam dokumen), aturan "jumlah tidak cocok dengan dokumen" menolak keluaran dan catatan jatuh ke tangan manusia. Jika tidak ada verifikasi, catatan yang salah akan masuk ke sistem secara diam-diam.

Kasus 2 — Buronan tertangkap oleh pengawasan. Tim SaaS telah menyiapkan panel pemantauan; Suatu pagi, biaya harian meningkat tiga kali lipat. Terlihat dari log bahwa klien memasuki loop dan mengirimkan permintaan yang sama ribuan kali. Mereka menambahkan kuota dan deduplikasi; Masalahnya teratasi dalam beberapa jam. Tanpa pelacakan, tagihan tersebut akan menjadi kejutan di akhir bulan.

Kasus 3 — Menerima batasan. Sebuah startup layanan kesehatan berencana membuat rekomendasi diagnosis secara otomatis dan menunjukkannya kepada pasien. Dalam tinjauan etika dan tanggung jawab, mereka memutuskan bahwa hal ini terlarang: model hanya memberikan ringkasan dan poin-poin yang memungkinkan kepada dokter, dokterlah yang membuat diagnosis. Tidak mengotomatiskan pekerjaan juga merupakan keputusan desain yang matang.

Kesalahan umum

Melewatkan validasi: Menerapkan keluaran secara membabi buta, dengan mengatakan "modelnya bagus".
Mengotomatiskan keputusan berdampak besar: Persetujuan manusia sangat penting dalam bidang keuangan/kesehatan/hukum.
Tidak melakukan pemantauan: Masalah biaya dan kualitas terlambat diketahui.
Menulis data sensitif ke log: Pelanggaran privasi; Simpan dengan menutupinya.
Tidak mencoba mengandalkan sumbernya: Model mungkin membuat apa yang tidak ada dalam dokumen.
Mengabaikan batasan: Tidak mengotomatiskan beberapa tugas adalah keputusan yang tepat; Transparansi dan tanggung jawab ada di tangan Anda.

Lebih Dalam: Manajemen Rilis, Rollback, dan Penerapan Tambahan

Mengambil fitur LLM ke dalam produksi bukan tentang menyiapkan dan melupakannya; adalah dengan aman memodifikasi sistem live dari waktu ke waktu. Ia memiliki tiga pilar.

Pembuatan versi. Perintah sistem, pemilihan model, dan aturan verifikasi Anda berubah seiring waktu. Versi setiap perubahan signifikan dan catat versi mana yang aktif. Jika suatu saat kualitasnya turun, “apa yang kita ubah?” Anda seharusnya bisa menjawab pertanyaan itu dalam hitungan menit. Dalam sistem tanpa versi, menemukan akar penyebab regresi memerlukan waktu berhari-hari.

Kembalikan. Jika prompt atau model baru berperilaku lebih buruk dari yang diharapkan saat live, Anda seharusnya dapat dengan cepat kembali ke versi sebelumnya yang sudah dikenal. Perubahan tanpa rencana kemunduran berarti menerima risiko langsung secara membabi buta. "Saya mengubah sesuatu, menjadi buruk, saya tidak bisa kembali" adalah skenario produksi yang paling mahal.

Peluncuran bertahap. Daripada menerapkan perubahan ke semua lalu lintas sekaligus, Anda menerapkannya ke persentase kecil (misalnya 5%) terlebih dahulu dan memantau metrik (kualitas, biaya, kesalahan). Jika bagus, Anda tingkatkan persentasenya; Jika buruk, Anda akan mendapatkannya kembali dengan hanya sebagian kecil yang terpengaruh. Ini sangat membatasi risikonya.

Ketiga praktik ini menggabungkan teknik dari semua unit sebelumnya: eval (unit 5) mengukur perubahan terlebih dahulu, pemantauan (unit ini) memberikan peringatan dini selama propagasi, lapisan verifikasi menangkap keluaran yang salah sebelum dapat ditindaklanjuti. Produksi bukanlah satu-satunya pengaturan yang benar; Ini adalah disiplin berkelanjutan yang mengukur, memantau, dan dapat berubah dengan percaya diri. Seluruh modul diperuntukkan bagi Anda untuk membangun disiplin ini.

Singkatnya

Produksi lebih dari sekadar demo yang berfungsi: ini adalah saluran masukan, model, verifikasi, tindakan, dan pemantauan. Outputnya tidak dapat diandalkan tanpa verifikasi; keputusan yang berdampak besar bergantung pada persetujuan manusia; Setiap panggilan dipantau untuk biaya, kesalahan dan kualitas. Etika, transparansi, pengendalian bias, akuntabilitas, dan penerimaan batasan merupakan bagian integral dari keputusan teknis. Setiap bagian yang dipelajari dalam modul ini dipadukan dalam desain holistik ini.

Tugas aplikasi

Rancang fitur LLM ujung ke ujung. (1) Isi lima lapisan (input, model, verifikasi, tindakan, pemantauan) untuk tugas spesifik Anda. (2) Tandai berdasarkan dampak keputusan mana yang memerlukan persetujuan manusia. (3) Tulis setidaknya tiga pemeriksaan validasi (skema, aturan, sumber). (4) Tentukan metrik utama yang akan Anda lacak dan apa yang tidak akan Anda catat. (5) Tuliskan batasan dan prinsip etika yang Anda terima dalam fitur ini.

daftar periksa

[ ] Saya dapat mendesain lima lapisan pipa produksi.
[] Saya dapat memvalidasi keluaran terhadap skema, aturan, dan sumber.
[ ] Saya dapat menetapkan ambang batas persetujuan manusia berdasarkan dampak keputusan tersebut.
[ ] Saya memantau biaya, kesalahan dan kualitas serta berlatih untuk tidak menulis data sensitif dalam log.
[ ] Saya dapat mengubah etika, tanggung jawab, dan batasan menjadi keputusan produksi.

Ujian Modul

1. Apa fungsi peran 'sistem' dalam API obrolan LLM?

A) Memberikan model instruksi permanen dan aturan perilaku yang berlaku sepanjang percakapan ✔
B) Menyimpan pertanyaan terakhir yang ditulis oleh pengguna
C) Menyimpan respons yang dihasilkan oleh model
D) Mengenkripsi kunci API

Deskripsi: Peran sistem memberikan model instruksi, kepribadian, dan aturan yang terus-menerus yang berlaku di seluruh percakapan; Ini adalah pengalihan tingkat tinggi, terpisah dari pesan pengguna.

2. Mengapa riwayat percakapan (pesan sebelumnya) dikirim lagi setiap kali dalam permintaan API?

A) Penting untuk membuat cadangan karena server menghapus riwayat
B) Panggilan API tidak memiliki kewarganegaraan; ✔ Konteks dikirim ulang pada setiap permintaan karena model tidak mengingat riwayat
C) Hanya diperlukan untuk pembuatan faktur, tidak berpengaruh pada model
D) Mengirim riwayat adalah wajib untuk menghindari memperlambat respons

Penjelasan: Panggilan API LLM tidak memiliki kewarganegaraan; Model ini tidak mengingat putaran sebelumnya, sehingga semua riwayat yang relevan dikirim ulang pada setiap permintaan untuk menjaga konteks.

3. Apa yang dimaksud dengan 'token' dalam penetapan harga LLM?

A) Kata sandi satu kali digunakan untuk masuk ke API
B) Biaya tetap dibayarkan pada setiap permintaan
C) Unit terkecil tempat model memproses teks; biasanya sesuai dengan bagian kata ✔
D) Satuan yang hanya mengukur panjang keluaran

Deskripsi: Token adalah unit terkecil tempat model memproses teks; Biasanya sesuai dengan fragmen kata, dan input dan output dibebankan berdasarkan jumlah token.

4. Mengapa token keluaran lebih mahal daripada token masukan di sebagian besar penyedia LLM?

A) Token keluaran selalu lebih panjang dari token masukan
B) Token masukan gratis
C) Token keluaran dikirim dua kali melalui internet
D) Biaya unit lebih tinggi karena pembangkitan keluaran memerlukan perhitungan tambahan untuk setiap token ✔

Deskripsi: Setiap token keluaran memerlukan model untuk melakukan pembuatan langkah demi langkah (perhitungan); Biaya produksi ini lebih tinggi dibandingkan memproses input sekaligus, sehingga harga satuan output biasanya lebih tinggi.

5. Dalam situasi apa penggunaan streaming paling bermanfaat?

A) Dalam jawaban yang panjang; Mengurangi penundaan yang dirasakan dan mencegah batas waktu ✔
B) Hanya dalam jawaban yang sangat singkat dan satu kata
C) Untuk mengurangi biaya menjadi nol
D) Untuk menyembunyikan kunci API

Deskripsi: Dalam respons yang panjang, streaming mengurangi latensi yang dirasakan dengan membuat kata pertama segera muncul dan mencegah batas waktu HTTP pada nilai max_tokens yang besar.

6. Apa pengaruh peningkatan parameter 'usaha' dalam model modern secara umum?

A) Selalu mempersingkat jawabannya
B) Secara otomatis memutar kunci API
C) Ini hanya mengurangi harga token input
D) Meningkatkan kedalaman berpikir dan belanja token; Ini mungkin meningkatkan kualitas, tetapi juga meningkatkan latensi dan biaya ✔

Deskripsi: Parameter upaya menyesuaikan seberapa dalam model akan memikirkan suatu tugas dan berapa banyak token yang akan dikeluarkan; Peningkatan versi mungkin meningkatkan kualitas, namun juga meningkatkan latensi dan biaya. Untuk tugas sederhana, sedikit usaha saja sudah cukup.

7. Pendekatan apa yang secara umum paling hemat biaya untuk tugas klasifikasi sederhana dan bervolume tinggi?

A) Selalu gunakan model yang paling mahal dan paling kuat
B) Memanggil semua model secara bersamaan untuk setiap permintaan
C) Memilih model paling ringan/termurah yang menyelesaikan tugas dengan memverifikasinya dengan sedikit eval ✔
D) menjaga nilai max_tokens terlalu tinggi

Penjelasan: Jika tugasnya tidak rumit, memilih model yang lebih cepat dan lebih murah yang dapat menyelesaikan tugas dengan mudah (misalnya kelas Haiku) daripada menggunakan model yang paling mahal dan kuat akan mengurangi biaya secara signifikan.

8. Dalam skenario manakah caching cepat mengurangi biaya paling banyak?

A) Ketika konteks besar dan tetap digunakan berulang kali di banyak permintaan ✔
B) Ketika teks yang sama sekali berbeda dikirim dengan setiap permintaan
C) Ketika hanya satu permintaan yang dibuat
D) Untuk mengurangi token keluaran

Deskripsi: Caching adalah pencocokan awalan; Dalam kasus di mana konteks besar yang tidak dapat diubah (perintah sistem, dokumen) digunakan kembali di banyak permintaan, pembacaan dari cache hanya sebagian kecil (~0,1x) dari harga penuh.

9. Bagaimana cara mengedit prompt agar cache prompt dapat ditemukan?

A) Menempatkan konten variabel di awal dan konten tetap di akhir
B) Cantumkan tanggal dan waktu saat ini di prompt sistem untuk setiap permintaan
C) Menempatkan konten tetap (prompt sistem, dokumen) di awal dan konten variabel di akhir ✔
D) Mengubah urutan daftar alat dengan setiap permintaan

Penjelasan: Karena cache adalah kecocokan awalan, konten tetap/tidak berubah (prompt sistem, dokumen) diinisialisasi; konten variabel (tanggal, pertanyaan pengguna, ID permintaan) diletakkan di akhir. Bahkan satu byte pun yang diubah di awal akan membuat cache tidak valid.

10. Jenis beban kerja apa yang paling cocok untuk pemrosesan batch?

A) Obrolan langsung di mana pengguna mengharapkan respons instan di layar
B) Hanya satu pertanyaan singkat
C) Menghasilkan kunci API
D) Pekerjaan yang toleran terhadap penundaan, volume besar dan tidak memerlukan hasil segera ✔

Deskripsi: Pemrosesan batch cocok untuk pekerjaan dalam jumlah besar yang tidak memerlukan respons segera dan toleran terhadap penundaan; hasilnya diberikan setelah beberapa waktu, tetapi biaya satuannya biasanya lebih rendah.

11. Apa yang digunakan untuk mencocokkan permintaan mana yang hasilnya termasuk dalam suatu batch?

A) Mengirim pesanan (posisi) permintaan
B) Panjang jawaban
C) 4 digit terakhir kunci API
D) Custom_id unik yang diberikan untuk setiap permintaan ✔

Catatan: Hasil massal dapat dikembalikan dalam urutan yang berbeda dari urutan penyerahan; jadi penting untuk mencocokkan hasil berdasarkan ID, bukan lokasi, dengan custom_id unik yang diberikan untuk setiap permintaan.

12. Perilaku apa yang disarankan saat Anda menerima kesalahan 429 (batas kecepatan) dari API?

A) Memaksa dengan mengirimkan lebih banyak permintaan secara bersamaan
B) Mencoba lagi dengan backoff eksponensial, mengikuti judul coba lagi setelah ✔
C) Batalkan permintaan sepenuhnya dan tunjukkan kesalahan sebagai kerusakan kepada pengguna
D) Mengubah kunci API

Penjelasan: 429 adalah kesalahan yang dapat dicoba lagi; Pendekatan yang benar adalah mencoba lagi dengan backoff eksponensial, dengan memperhatikan header coba lagi setelahnya. Kebanyakan SDK resmi melakukan ini secara otomatis.

13. Manakah dari kode kesalahan HTTP berikut yang umumnya dianggap dapat dicoba ulang?

A) 400 (permintaan tidak valid)
B) 401 (kesalahan otentikasi)
C) 529 (server kelebihan beban) ✔
D) 404 (tidak ditemukan)

Penjelasan: 429 (batas kecepatan), 500 (kesalahan server) dan 529 (kelebihan beban) adalah kesalahan sementara dan dapat dicoba ulang dengan mundur. Kesalahan seperti 400 dan 401 adalah masalah permintaan/identitas; Mencoba lagi tidak akan menyelesaikannya.

14. Manakah dari berikut ini yang merupakan cara aman untuk mengelola kunci API?

A) Menyimpan di variabel lingkungan/manajer tersembunyi, tidak menyematkannya ke dalam kode dan memutarnya secara teratur ✔
B) Tulis kunci langsung ke kode sumber dan kirimkan ke repositori
C) Menempatkan kunci di sisi klien (browser) JavaScript
D) Berbagi satu kunci dengan seluruh tim melalui email

Deskripsi: Kunci tidak pernah ditulis ke kode sumber atau repositori; Itu disimpan dalam variabel lingkungan atau alat manajemen tersembunyi, diberikan dengan hak istimewa minimal, dan dirotasi secara teratur.

15. Apa pendekatan terbaik untuk integrasi LLM dengan alat otomatisasi (n8n, Zapier, Make) dalam hal privasi?

A) Mengirim semua data mentah ke model, meskipun tidak diperlukan
B) Menulis kunci API dalam teks biasa di dalam langkah alur
C) Meminimalkan dan menutupi data sensitif dan menyimpan kunci sebagai kredensial rahasia ✔
D) Menyimpan data pribadi secara permanen dalam riwayat aliran

Deskripsi: Saat otomatisasi pemasukan data melewati sistem dan model pihak ketiga, data sensitif/pribadi perlu diminimalkan, disembunyikan, dan hanya kolom wajib yang dikirim; Kunci API juga disimpan sebagai kredensial rahasia dalam alat tersebut.

16. Mengapa validasi keluaran wajib dalam fitur produksi berbasis LLM?

A) Hanya pemformatan yang diperlukan karena model tidak pernah melakukan kesalahan
B) Karena model dapat berproduksi dengan lancar tetapi terkadang salah; Skema/aturan harus diaudit dengan persetujuan sumber daya dan manusia ✔
C) Validasi sebaiknya dihindari karena hanya menambah biaya
D) Verifikasi hanya untuk mengurangi jumlah token

Deskripsi: LLM dapat menghasilkan keluaran yang lancar tetapi terkadang tidak akurat (halusinasi); sehingga hal ini menghasilkan keputusan yang berdampak besar; Ini harus diaudit dengan pemeriksaan skema/aturan, validasi sumber, dan persetujuan manusia bila diperlukan.