Pengeluaran Hujung ke Hujung: Pengesahan, Pemantauan dan Etika

Keuntungan:

Boleh mereka bentuk seni bina hujung ke hujung yang mengambil ciri LLM daripada idea kepada pengeluaran
Menubuhkan lapisan penguatkuasaan pengesahan, kelulusan manusia dan penjejakan (pelogan/metrik)
Sempadan menterjemahkan prinsip etika dan privasi ke dalam keputusan pengeluaran

Dalam sepuluh unit sebelumnya, kami mempelajari bahagian satu demi satu: struktur permintaan, ekonomi token, aliran, gesaan sistem, pemilihan model, cache, kelompok, pengurusan ralat, kunci selamat dan automasi. Dalam unit terakhir ini, kami menggabungkan bahagian dan mewujudkan seni bina holistik yang membawa ciri LLM daripada idea kepada pengeluaran. Pengeluaran adalah berbeza daripada "demo kerja": pengesahan adalah wajib, output mesti dipantau, sempadan dan prinsip etika mesti diterapkan dalam keputusan. Unit ini ialah lajur pembawa modul; Semua yang sebelumnya berkumpul di sini.

Lapisan Seni Bina Pengeluaran

Kelayakan LLM yang kukuh terdiri daripada kira-kira lima lapisan:

Lapisan input: Kumpul data, bersihkannya, tutup kawasan sensitif, hantar hanya yang perlu.
Lapisan model: Pilih model yang betul (unit 5), tetapkan gesaan dan parameter sistem (unit 4), cache (unit 6).
Lapisan pengesahan: Semak output berdasarkan skema/peraturan, sumber dan kelulusan manusia jika perlu.
Lapisan tindakan: Lakukan tindakan dengan output yang disahkan; Tangkap tindakan berimpak tinggi.
Lapisan pemantauan: Rekod dan ukur setiap panggilan, kos, ralat dan kualiti.

Lapisan ini adalah saluran paip; masing-masing menyemak output yang sebelumnya.

Mengapa Pengesahan Diperlukan?

LLM boleh menghasilkan keluaran yang lancar tetapi kadangkala tidak tepat. Ini dipanggil halusinasi: model itu mungkin mengada-adakan maklumat yang nampaknya benar tetapi tidak. Dalam permainan sembang ini boleh diterima; tidak boleh diterima dalam sistem pengeluaran (invois, kesihatan, undang-undang, kewangan). Jadi ternyata, secara membuta tuli tidak boleh dipercayai; disahkan.

Lapisan pengesahan (meningkat mengikut kesan):

Pengesahan format/skema: Adakah output mematuhi skema JSON yang dijangkakan? (Keluaran berstruktur sebahagian besarnya menjamin ini.)
Pengesahan peraturan/logik: Adakah nilai itu munasabah? (Adakah jumlahnya negatif, adakah tarikh pada masa hadapan, adakah kategori itu sah?)
Pengesahan sumber: Adakah tuntutan berdasarkan dokumentasi yang disediakan? Adakah model menyatakan sesuatu yang tiada dalam dokumen?
Kelulusan manusia: Pakar menyemak keputusan berimpak tinggi atau samar-samar.

Awas: "Modelnya sangat bagus, tiada pengesahan lanjut diperlukan" adalah kesilapan pengeluaran yang paling berbahaya. Tidak kira seberapa baik model itu, lapisan pengesahan adalah jaringan keselamatan dalam keputusan berimpak tinggi. Malah satu keputusan automatik yang salah boleh menghilangkan semua masa yang disimpan.

Manusia-dalam-Gelung

Tidak setiap keputusan mesti automatik sepenuhnya. Dalam pendekatan manusia-dalam-gelung, model mempercepatkan kerja dan manusia meluluskannya. Keseimbangan yang betul bergantung pada kesan keputusan dan kebolehpercayaan model pada tugas itu.

Kesan keputusan

Pendekatan

Rendah (cadangan label, draf)

Automasi penuh; ralat adalah murah dan boleh diterbalikkan

Sederhana (laluan, keutamaan)

Automasi + kawalan pensampelan

Tinggi (wang, kontrak, kesihatan, pemadaman)

Persetujuan manusia adalah wajib; model hanya mencadangkan

Pemantauan: Anda Tidak Boleh Mengurus Perkara yang Anda Tidak Nampak

Dalam pengeluaran, anda mesti memantau setiap panggilan. Tanpa pemantauan, anda tidak boleh meningkatkan kos, kualiti atau mengatasi masalah lebih awal. Metrik utama untuk direkodkan:

Penggunaan/kos: Setiap permintaan dan jumlah token, pengedaran model, perbelanjaan harian.
Latensi: Masa tindak balas purata dan kes terburuk.
Kadar ralat: 429/500 kadar, percubaan semula, pengabaian.
Kualiti: Kadar output yang ditolak pada lapisan pengesahan, kadar pembetulan pada kelulusan manusia, maklum balas pengguna.

Petua: Jangan tulis data sensitif (maklumat peribadi, kunci) pada log pemantauan. Pertimbangkan log dalam skop kerahsiaan; rekod dengan menutup jika perlu (unit 9).

Etika dan Sempadan

Tanggungjawab etika adalah sebahagian daripada keputusan pengeluaran seperti ketepatan teknikal:

Ketelusan: Pengguna harus tahu sama ada mereka bercakap dengan kecerdasan buatan atau manusia.
Keadilan dan berat sebelah: Model mungkin membawa berat sebelah daripada data yang dilatih; Pantau akibat diskriminasi dalam keputusan berimpak tinggi (pengambilan pekerja, kredit).
Liabiliti: Jika keputusan automatik menyebabkan kemudaratan, anda bertanggungjawab; "Model itu berkata begitu" bukan pembelaan.
Penerimaan had: Model tidak dapat melaksanakan beberapa tugas dengan pasti; tidak mengautomasikannya juga merupakan keputusan reka bentuk.

Templat Boleh Disalin

# Senarai semak pengesahan (selepas penjanaan output)1) Adakah skema itu sah? (pengesahan output berstruktur)2) Adakah nilai-nilai itu masuk akal? (semakan peraturan: julat, tarikh, enum)3) Adakah tuntutan berdasarkan sumber? (tolak jika tiada dalam dokumen)4) Adakah impaknya tinggi? → hantar untuk kelulusan manusia5) Jika semua lulus → benarkan tindakan, simpan

# Gesaan sistem yang memaksa bergantung pada sumberBergantung hanya pada maklumat dalam dokumen yang disediakan. Jangan tambah apa-apa yang tiada dalam dokumen. Jika maklumat tiada dalam dokumen, tulis "Tidak dijumpai dalam dokumen". Jangan sekali-kali meneka atau mengada-adakan perkara.

# Ambang kelulusan manusia (peraturan keputusan)JIKA keputusan_jenis dalam [wang, kontrak, padam, kesihatan] → mandatori kelulusan manusiaIF model_amanah < ambang ATAU pengesahan "tidak pasti" → serahkan kepada kelulusan manusia LAIN → permohonan automatik + kawalan pensampelan

# Templat log jejak (menulis data sensitif){ "masa":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"lulus|ditolak|manusia", "cost_usd" dan kunci TIDAK PERNAH menulis data peribadi:... } //

Gesaan lemah / Gesaan kuat (kebolehpercayaan pengeluaran)

# LEMAH (tiada pengesahan, tiada sumber, terpakai secara automatik) Nilai permintaan ini, buat keputusan bayaran balik dan mohon.

# KUAT (berasaskan sumber, menjana pengesyoran, menyerahkan kepada kelulusan manusia)Nilai permintaan pemulangan ini berdasarkan dokumen polisi pemulangan sahaja. Syorkan keputusan dengan justifikasi tetapi jangan laksanakan: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}.Jika tiada asas yang jelas dalam dokumen polisi, berikan "unclear". Seorang wakil akan meluluskan keputusan muktamad.

Versi berkuasa; Ia mengaitkan keputusan itu kepada sumber, meletakkan model sebagai "pencadang" dan bukannya "pelaku", dan meletakkan langkah berimpak tinggi di belakang persetujuan manusia. Ini adalah intipati kebolehpercayaan pengeluaran.

Tiga Kes Mini

Kes 1 — Hari lapisan pengesahan disimpan. Sebuah fintech mempunyai model mengklasifikasikan perihalan transaksi dan mencipta rekod perakaunan automatik. Mereka menambah pengesahan peraturan: setelah model mengeluarkan amaun secara salah (12,500 dan bukannya 1,250 dalam dokumen), peraturan "jumlah tidak sepadan dengan dokumen" menolak output dan rekod jatuh kepada manusia. Jika tiada pengesahan, rekod yang salah akan memasuki sistem secara senyap.

Kes 2 — Pelarian ditangkap melalui pengawasan. Pasukan SaaS telah menubuhkan panel pemantauan; Suatu pagi kos harian meningkat tiga kali ganda. Ia dilihat dari log bahawa pelanggan memasuki gelung dan menghantar permintaan yang sama beribu-ribu kali. Mereka menambah kuota dan penyahduplikasian; Masalah itu diselesaikan dalam beberapa jam. Tanpa penjejakan, bil akan menjadi kejutan pada akhir bulan.

Kes 3 — Menerima had. Permulaan penjagaan kesihatan sedang merancang untuk membuat pengesyoran diagnosis sepenuhnya secara automatik dan menunjukkannya kepada pesakit. Dalam semakan etika dan liabiliti, mereka memutuskan ini adalah di luar had: model hanya memberikan ringkasan dan kemungkinan mata kepada doktor, doktor membuat diagnosis. Tidak mengautomasikan kerja juga merupakan keputusan reka bentuk yang matang.

Kesilapan biasa

Melangkau pengesahan: Menggunakan output secara membuta tuli, mengatakan "modelnya bagus".
Mengautomasikan keputusan berimpak tinggi: Kelulusan manusia adalah penting dalam wang/kesihatan/undang-undang.
Tidak memantau: Masalah kos dan kualiti ditemui lewat.
Menulis data sensitif pada log: Pelanggaran privasi; Simpan dengan menutupnya.
Tidak cuba bergantung pada sumber: Model mungkin membentuk perkara yang tidak ada dalam dokumen.
Mengabaikan had: Tidak mengautomasikan beberapa tugas adalah keputusan yang tepat; Ketelusan dan tanggungjawab adalah milik anda.

Lebih Dalam: Pengurusan Keluaran, Rollback dan Penggunaan Bertambah

Mengambil ciri LLM ke dalam pengeluaran bukan tentang menyediakannya dan melupakannya; adalah untuk mengubah suai sistem hidup dengan selamat dari semasa ke semasa. Ia mempunyai tiga tiang.

Versi. Gesaan sistem anda, pemilihan model dan peraturan pengesahan berubah dari semasa ke semasa. Versi setiap perubahan ketara dan rekod versi yang disiarkan secara langsung. Jika suatu hari kualitinya menurun, "apa yang kita ubah?" Anda sepatutnya dapat menjawab soalan dalam beberapa minit. Dalam sistem tanpa versi, mencari punca regresi mengambil masa beberapa hari.

Balik semula. Jika gesaan atau model baharu berkelakuan lebih teruk daripada yang dijangkakan dalam siaran langsung, anda seharusnya dapat kembali dengan cepat kepada versi terdahulu yang terkenal. Perubahan tanpa pelan pengembalian adalah menerima risiko langsung secara membuta tuli. "Saya menukar sesuatu, ia menjadi teruk, saya tidak boleh kembali" adalah senario pengeluaran yang paling mahal.

Pelancaran secara beransur-ansur. Daripada menggunakan perubahan pada semua trafik sekaligus, anda melancarkannya kepada peratusan kecil (mis. 5%) dahulu dan memantau metrik (kualiti, kos, ralat). Jika ia bagus, anda meningkatkan peratusan; Jika ia buruk, anda akan mendapatkannya semula dengan hanya sebahagian kecil yang terjejas. Ini sangat mengehadkan risiko.

Tiga amalan ini menggabungkan teknik daripada semua unit sebelumnya: eval (unit 5) mengukur perubahan lebih awal, pemantauan (unit ini) memberi amaran awal semasa penyebaran, lapisan pengesahan menangkap output yang salah sebelum ia boleh diambil tindakan. Pengeluaran bukan satu persediaan yang betul; Ia adalah disiplin berterusan yang mengukur, memantau dan boleh berubah dengan yakin. Keseluruhan modul adalah untuk anda menubuhkan disiplin ini.

Secara ringkasnya

Pengeluaran adalah lebih daripada demo yang berfungsi: ia adalah saluran paip input, model, pengesahan, tindakan dan lapisan pemantauan. Output tidak boleh dipercayai tanpa pengesahan; keputusan berimpak tinggi terikat dengan kelulusan manusia; Setiap panggilan dipantau untuk kos, ralat dan kualiti. Etika, ketelusan, kawalan berat sebelah, akauntabiliti dan penerimaan had adalah penting kepada keputusan teknikal. Setiap bahagian yang dipelajari dalam modul ini disatukan dalam reka bentuk holistik ini.

Tugasan permohonan

Reka ciri LLM hujung ke hujung. (1) Isikan lima lapisan (input, model, pengesahan, tindakan, pemantauan) untuk tugas khusus anda. (2) Tandakan mengikut kesan keputusan yang memerlukan kelulusan manusia. (3) Tulis sekurang-kurangnya tiga semakan pengesahan (skema, peraturan, sumber). (4) Tentukan metrik utama yang anda akan jejak dan perkara yang anda tidak akan log. (5) Tulis had dan prinsip etika yang anda terima dalam ciri ini.

senarai semak

[ ] Saya boleh mereka bentuk lima lapisan saluran paip pengeluaran.
[ ] Saya boleh mengesahkan output terhadap skema, peraturan dan sumber.
[ ] Saya boleh menetapkan ambang kelulusan manusia berdasarkan kesan keputusan.
[ ] Saya memantau kos, ralat dan kualiti serta berlatih untuk tidak menulis data sensitif dalam log.
[ ] Saya boleh mengubah etika, tanggungjawab dan sempadan kepada keputusan pengeluaran.

Peperiksaan Modul

1. Apakah peranan 'sistem' dalam API sembang LLM?

A) Memberi model arahan kekal dan peraturan tingkah laku yang digunakan sepanjang keseluruhan perbualan ✔
B) Menyimpan soalan terakhir yang ditulis oleh pengguna
C) Menyimpan tindak balas yang dihasilkan oleh model
D) Menyulitkan kunci API

Penerangan: Peranan sistem memberikan model arahan yang berterusan, personaliti dan peraturan yang digunakan sepanjang keseluruhan perbualan; Ia adalah ubah hala peringkat tinggi, berasingan daripada mesej pengguna.

2. Mengapakah sejarah perbualan (mesej sebelumnya) dihantar semula setiap kali dalam permintaan API?

A) Ia adalah perlu untuk membuat sandaran kerana pelayan memadamkan sejarah
B) Panggilan API adalah tanpa kewarganegaraan; ✔ Konteks dibenci pada setiap permintaan kerana model tidak mengingati sejarah
C) Diperlukan hanya untuk invois, tidak mempunyai kesan ke atas model
D) Menghantar sejarah adalah wajib untuk mengelakkan melambatkan respons

Penjelasan: Panggilan API LLM adalah tanpa kewarganegaraan; Model tidak mengingati pusingan sebelumnya, jadi semua sejarah yang berkaitan dihantar semula pada setiap permintaan untuk mengekalkan konteks.

3. Apakah 'token' dalam harga LLM?

A) Kata laluan sekali digunakan untuk log masuk ke API
B) Yuran tetap dibayar pada setiap permintaan
C) Unit terkecil di mana model memproses teks; biasanya sepadan dengan bahagian perkataan ✔
D) Unit yang mengukur panjang keluaran sahaja

Penerangan: Token ialah unit terkecil di mana model memproses teks; Ia biasanya sepadan dengan serpihan perkataan, dan kedua-dua input dan output dicaj berdasarkan bilangan token.

4. Mengapakah token output lebih mahal daripada token input di kebanyakan penyedia LLM?

A) Token output sentiasa lebih panjang daripada input
B) Token input adalah percuma
C) Token output dihantar dua kali melalui internet
D) Kos unit lebih tinggi kerana penjanaan output memerlukan pengiraan tambahan untuk setiap token ✔

Penerangan: Setiap token output memerlukan model untuk melaksanakan penjanaan langkah demi langkah (pengiraan); Kos pengeluaran ini lebih tinggi daripada pemprosesan input sekaligus, jadi harga unit output biasanya lebih tinggi.

5. Dalam situasi apakah menggunakan penstriman paling berfaedah?

A) Dalam jawapan yang panjang; Mengurangkan kelewatan yang dirasakan dan menghalang tamat masa ✔
B) Hanya dalam jawapan yang sangat pendek, satu perkataan
C) Untuk mengurangkan kos kepada sifar
D) Untuk menyembunyikan kunci API

Penerangan: Dalam respons yang panjang, penstriman mengurangkan kependaman yang dirasakan dengan membuat perkataan pertama muncul serta-merta dan menghalang tamat masa HTTP pada nilai max_tokens yang besar.

6. Apakah kesan peningkatan parameter 'usaha' dalam model moden secara amnya?

A) Sentiasa pendekkan jawapan
B) Putar kunci API secara automatik
C) Ia hanya mengurangkan harga token input
D) Meningkatkan kedalaman pemikiran dan perbelanjaan token; Ia mungkin meningkatkan kualiti, tetapi ia juga meningkatkan kependaman dan kos ✔

Perihalan: Parameter usaha melaraskan sejauh mana model akan memikirkan tugasan dan bilangan token yang akan dibelanjakan; Peningkatan boleh meningkatkan kualiti, tetapi ia juga meningkatkan kependaman dan kos. Untuk tugasan mudah, usaha yang rendah sudah memadai.

7. Apakah secara amnya pendekatan paling kos efektif untuk tugas pengelasan volum tinggi yang mudah?

A) Sentiasa gunakan model yang paling mahal dan paling berkuasa
B) Memanggil semua model pada masa yang sama untuk setiap permintaan
C) Memilih model paling ringan/paling murah yang menyelesaikan tugas dengan mengesahkannya dengan sedikit eval ✔
D) mengekalkan nilai max_tokens tidak perlu terlalu tinggi

Penjelasan: Jika tugas itu tidak rumit, memilih model yang lebih pantas dan lebih murah yang dapat menyelesaikan tugas dengan mudah (cth. kelas Haiku) dan bukannya menggunakan model yang paling mahal dan berkuasa akan mengurangkan kos dengan ketara.

8. Dalam senario yang manakah caching segera mengurangkan kos paling banyak?

A) Apabila konteks yang besar dan tetap digunakan berulang kali merentasi banyak permintaan ✔
B) Apabila teks yang sama sekali berbeza dihantar dengan setiap permintaan
C) Apabila hanya satu permintaan dibuat
D) Untuk mengurangkan token keluaran

Penerangan: Caching ialah padanan awalan; Dalam kes di mana konteks yang besar dan tidak boleh ubah (gesaan sistem, dokumen) digunakan semula merentas banyak permintaan, bacaan daripada cache ialah pecahan kecil (~0.1x) daripada harga penuh.

9. Bagaimanakah saya harus mengedit gesaan supaya cache gesaan mencecah?

A) Meletakkan kandungan berubah pada permulaan dan kandungan tetap pada akhir
B) Benamkan tarikh dan masa semasa dalam gesaan sistem untuk setiap permintaan
C) Meletakkan kandungan tetap (gesaan sistem, dokumen) pada permulaan dan kandungan berubah di akhir ✔
D) Mengubah susunan senarai alat dengan setiap permintaan

Penjelasan: Memandangkan cache ialah padanan awalan, kandungan tetap/tidak berubah (gesaan sistem, dokumen) dimulakan; kandungan berubah-ubah (tarikh, soalan pengguna, ID permintaan) diletakkan di penghujung. Malah satu bait yang diubah pada mulanya akan membatalkan cache.

10. Untuk jenis beban kerja apakah pemprosesan kelompok paling sesuai?

A) Sembang langsung di mana pengguna mengharapkan respons segera pada skrin
B) Hanya satu soalan ringkas
C) Menjana kunci API
D) Pekerjaan yang bertolak ansur dengan kelewatan, jumlah yang besar dan tidak memerlukan keputusan segera ✔

Penerangan: Pemprosesan kelompok sesuai untuk jumlah kerja yang besar yang tidak memerlukan respons segera dan bertolak ansur dengan kelewatan; keputusan dihantar selepas beberapa ketika, tetapi kos unit biasanya lebih rendah.

11. Apakah yang digunakan untuk memadankan dengan yakin permintaan keputusan yang dimiliki dalam satu kelompok?

A) Menghantar pesanan (kedudukan) permintaan
B) Panjang jawapan
C) 4 digit terakhir kunci API
D) Custom_id unik diberikan kepada setiap permintaan ✔

Catatan: Keputusan pukal boleh dikembalikan dalam susunan yang berbeza daripada pesanan penyerahan; jadi adalah perlu untuk memadankan hasil mengikut ID, bukan lokasi, dengan custom_id unik diberikan kepada setiap permintaan.

12. Apakah tingkah laku yang disyorkan apabila anda menerima ralat 429 (had kadar) daripada API?

A) Memaksa dengan menghantar lebih banyak permintaan pada masa yang sama
B) Mencuba sekali lagi dengan mundur eksponen, mengikuti tajuk cuba semula selepas ✔
C) Batalkan permintaan sepenuhnya dan tunjukkan ralat sebagai ranap kepada pengguna
D) Menukar kunci API

Penjelasan: 429 ialah ralat yang boleh dicuba semula; Pendekatan yang betul ialah mencuba lagi dengan pengunduran eksponen, dengan menghormati pengepala cuba semula selepas. Kebanyakan SDK rasmi melakukan ini secara automatik.

13. Antara kod ralat HTTP berikut, yang manakah dianggap boleh dicuba semula?

A) 400 (permintaan tidak sah)
B) 401 (ralat pengesahan)
C) 529 (pelayan terlebih muatan) ✔
D) 404 (tidak ditemui)

Penjelasan: 429 (had kelajuan), 500 (ralat pelayan) dan 529 (lebih muatan) adalah ralat sementara dan boleh dicuba semula dengan mengundur. Ralat seperti 400 dan 401 ialah isu permintaan/identiti; Mencuba lagi tidak akan menyelesaikannya.

14. Antara berikut, yang manakah cara selamat untuk mengurus kunci API?

A) Menyimpan dalam pembolehubah persekitaran/pengurus tersembunyi, tidak membenamkannya dalam kod dan berputar secara kerap ✔
B) Tulis kunci terus ke dalam kod sumber dan hantar ke repositori
C) Meletakkan kunci di sisi klien (pelayar) JavaScript
D) Berkongsi kunci tunggal dengan seluruh pasukan melalui e-mel

Penerangan: Kunci tidak pernah ditulis pada kod sumber atau repositori; Ia disimpan dalam pembolehubah persekitaran atau alat pengurusan tersembunyi, diberikan dengan keistimewaan yang minimum dan diputar secara kerap.

15. Apakah pendekatan terbaik untuk penyepaduan LLM dengan alat automasi (n8n, Zapier, Make) dari segi privasi?

A) Menghantar semua data mentah kepada model, walaupun ia tidak perlu
B) Menulis kunci API dalam teks biasa di dalam langkah aliran
C) Meminimumkan dan menutup data sensitif dan menyimpan kunci sebagai bukti kelayakan rahsia ✔
D) Menyimpan data peribadi secara kekal dalam sejarah aliran

Penerangan: Memandangkan data yang memasuki automasi melalui sistem dan model pihak ketiga, data sensitif/peribadi perlu diminimumkan, bertopeng dan hanya medan yang diperlukan dihantar; Kunci API juga disimpan sebagai bukti kelayakan rahsia dalam alat.

16. Mengapakah pengesahan output diwajibkan dalam ciri pengeluaran berasaskan LLM?

A) Hanya pemformatan diperlukan kerana model tidak pernah membuat kesilapan
B) Kerana model boleh menghasilkan dengan lancar tetapi kadangkala tidak betul; Skema/peraturan mesti diaudit dengan kelulusan sumber dan manusia ✔
C) Pengesahan harus dielakkan kerana ia hanya meningkatkan kos
D) Pengesahan hanya untuk mengurangkan bilangan token

Penerangan: LLM boleh menghasilkan keluaran yang lancar tetapi kadangkala tidak tepat (halusinasi); jadi ia keluar dalam keputusan berimpak tinggi; Ia harus diaudit oleh semakan skema/peraturan, pengesahan sumber dan kelulusan manusia apabila perlu.