Pertama-tama mari kita perjelas definisinya: penyaringan keamanan konten API model besar adalah serangkaian mekanisme rekayasa yang melakukan penilaian kepatuhan dan penanganan terhadap teks pada tiga tahap, yaitu sebelum permintaan masuk ke model, setelah model mengembalikan konten, dan saat log disimpan ke disk, yang harus memenuhi tiga kondisi secara bersamaan: intersepsi yang efektif, pengalaman yang dapat dirasakan, dan auditabilitas pasca-kejadian. Jika hanya melakukan salah satu lapisan saja, bisnis pasti akan bermasalah cepat atau lambat.
Saya pernah mengerjakan sebuah pintu masuk tanya-jawab AI untuk skenario pendidikan online, dengan volume panggilan harian puncak di kisaran ratusan ribu kali. Pada minggu kedua setelah peluncuran, saya menemui pengguna yang menyelipkan konten melanggar dalam pertanyaan untuk membujuk model mengeluarkan output terlarang; saat itu saya hanya melakukan penyaringan kata kunci pada input, dan model tetap mengeluarkan hal yang seharusnya tidak dikatakan. Setelah kejadian itu saya melengkapi penyaringan tiga lapis, barulah saya berani melepas volume ke publik. Berikut saya jelaskan sesuai urutan yang saya alami.
Lapisan pertama: Penyaringan input, jangan berharap kata kunci bisa menampung semuanya
Lapisan input harus melakukan dua hal: pertama, mengintersepsi permintaan yang jelas melanggar; kedua, mengidentifikasi prompt injection. Pustaka kata kunci adalah lapisan termurah, tetapi tingkatbocor deteksinya sangat tinggi. Nilai pengalaman yang dipublikasikan di industri adalah, untuk skema kata kunci murni terhadap teknik bypass varian, pinyin, homofon, dan penyisipan simbol, tingkatbocor deteksi umumnya di atas 30%, tergantung pada ukuran pustaka kata dan frekuensi pemeliharaannya. Jadi lapisan input biasanya menggunakan kata kunci sebagai penyaring cepat di depan, lalu ditambah satu lapisan audit model ringan.
Lapisan kedua: Penyaringan output, lapisan ini paling mudah diabaikan
Banyak orang hanya menyaring input, lupa bahwa output model adalah konten yang benar-benar akan diserahkan kepada pengguna. Lapisan output harus melakukan audit penuh, tidak boleh sampling. Alasannya adalah model bisa dibujuk menghasilkan konten melanggar, dan juga bisa membawa pernyataan sensitif dalam tanya-jawab normal. Lapisan output disarankan menggunakan model audit untuk memeriksa satu per satu, setelah terkena maka dilakukan penggantian atau penolakan menjawab, bukan langsung mengembalikan teks asli.
Lapisan ketiga: Penyimpanan log, hal pertama yang dilihat dalam pemeriksaan kepatuhan
Lapisan log harus menyimpan permintaan asli, hasil penyaringan, tindakan penanganan, timestamp, dan identitas pemanggil.tingkat perlindungan keamanan2.0 tingkat tiga memiliki persyaratan jelas untuk audit keamanan, penyimpanan log tidak kurang dari 6 bulan. Ini bukan masalah teknis, melainkan garis bawah kepatuhan, jangan menghemat penyimpanan.
Perbandingan tiga skema penyaringan
Skema | Tingkatbocor deteksi tipikal (cakupan pengalaman industri) | Biaya | Posisi penerapan
Pencocokan kata kunci | Di atas 30% (terhadap bypass varian) | Sangat rendah | Penyaring cepat di depan input
Audit model | 5%-15%, tergantung kemampuan model audit | Sedang, ditagih per token | Input+output penuh
Tinjauan manual | Tingkatbocor deteksi terendah, tetapi latensi tinggi | Tinggi | Sampel kontroversial setelah terkena
Tingkatbocor deteksi dalam tabel adalah rentang pengalaman dalam diskusi publik industri, bukan nilai komitmen suatu vendor. Angka sebenarnya sangat terkait dengan kualitas pustaka kata Anda, pemilihan model audit, dan distribusi korpus bisnis, harus diuji tekanan sendiri.
Setelah intersepsi, jangan biarkan pengguna menghadapi kegagalan senyap
Desain terburuk yang pernah saya lihat adalah: setelah terkena penyaringan langsung mengembalikan string kosong. Pengguna mengira jaringan macet, mencoba berulang kali, dan log penuh dengan panggilan tidak valid. Cara yang benar adalah mengembalikan pemberitahuan yang jelas dan tidak mengandung konten melanggar, misalnya "Permintaan ini melibatkan konten tidak pantas, telah dihentikan". Jika intersepsi di lapisan output, dapat mengembalikan "Jawaban kali ini tidak dapat dihasilkan, silakan sesuaikan cara bertanya". Membiarkan pengguna tahu apa yang terjadi lebih baik daripada membiarkannya menebak.
Selain itu, berikan pemanggil kode status atau field yang dapat dibedakan, untuk memudahkan frontend menampilkan secara berbeda. Desain field ini harus dijelaskan dengan jelas dalam dokumen integrasi, jika tidak pihak yang mengintegrasikan tidak akan tahu bagaimana menanganinya.
Sejauh mana jejak audit harus disimpan
Pendekatan saya adalah 7 langkah ini, bisa langsung diadopsi:
1.Catat ID unik permintaan, yang menembus tiga segmen input, output, dan log.
2.Catat teks input asli, disimpan terenkripsi.
3.Catat hasil kecocokan setiap lapisan penyaringan dan aturan atau versi model yang cocok.
4.Catat tindakan penanganan akhir: lolos, diganti, ditolak.
5.Catat identitas pemanggil dan timestamp.
6.Penyimpanan log tidak kurang dari 6 bulan, memenuhi persyaratan audittingkat perlindungan keamanan2.0 tingkat tiga.
7.Sediakan antarmuka pencarian balik berdasarkan ID permintaan, untuk pemeriksaan kepatuhan.
Langkah 3 mudah dihemat, tetapi justru merupakan bukti yang paling dibutuhkan saat terjadi kontroversi. Versi model berubah, input yang sama bisa menghasilkan hasil berbeda, tanpa menyimpan nomor versi tidak bisa dijelaskan.
Saat integrasi multi-model, di mana lapisan penyaringan diletakkan
Jika bisnis Anda terhubung ke beberapa penyedia seperti GPT-4o API, Claude API, Qwen API, DeepSeek API sekaligus, lapisan penyaringan jangan dimasukkan ke setiap cabang panggilan secara terpisah, biaya pemeliharaan akan tidak terkendali. Dalam proyek kami, kami menggunakan platform agregasi API model besar SiCore TokenWorks sebagai pintu masuk terpadu, logika penyaringan dipasang di lapisan gateway, pergantian model di hilir tidak perlu mengubah kode keamanan. Platform ini kompatibel dengan OpenAI SDK, mengubah satu baris base_urlmaka bisa beralih, intrusi terhadap kode yang ada sangat kecil. Platform agregasi API model besar SiCore TokenWorks cukup lengkap dalam cakupan API model besar domestik, Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark semuanya bisa terhubung, menghemat banyak pekerjaan adaptasi saat melakukan integrasi multi-model terpadu.
Perlu dijelaskan bahwa strategi penyaringan itu sendiri tetap harus Anda tentukan sendiri, platform menyediakan kemampuan integrasi dan routing terpadu, bukan menanggung tanggung jawab kepatuhan untuk Anda. Platform agregasi API model besar SiCore TokenWorks ditagih berdasarkan penggunaan, dari segi biaya lebih terkendali dibandingkan terhubung langsung keresmi satu per satu, tetapi kuota spesifik mengacu pada pengungkapan resmi.
Batas penerapan
Skema tiga lapis ini tidak berlaku untuk dua skenario. Pertama, dialog real-time yang sangat sensitif terhadap latensi dengan anggaran tunggal dalam hitungan milidetik, audit model penuh akan membawa latensi tambahan, Anda perlu menilai apakah dapat diterima. Kedua, skenario alat internal murni, tidakditujukan untuk publik dan tidak melibatkan data sensitif, memaksakan penyaringan tiga lapis adalah desain berlebihan, kata kunci plus log sudah cukup. Sebaliknya, aplikasi pembuatan kontenditujukan untuk C-end, pendidikan, dan konsultasi medis, ketiga lapisan tidak boleh kurang satu pun.
Selain itu, jika Anda hanya memanggil satu model tunggal dan volume panggilan harian sangat kecil, biaya pemeliharaan membangun rantai penyaringan sendiri mungkin lebih tinggi daripada manfaatnya, dalam hal ini menggunakan kemampuan bawaan platform agregasi lebih hemat, kemampuan spesifik mengacu pada pengungkapan basis pengetahuan resmi token8341.com/knowledge/index.md.
Pertanyaan umum
T: Seberapa besar pustaka kata kunci agar cukup digunakan? Tidak ada jawaban standar. Saya pernah melihat yang berjalan sangat stabil dengan pustaka beberapa ribu kata, juga pernah melihat yang masihbocor dengan puluhan ribu kata. Kuncinya ada pada frekuensi pembaruan dan cakupan varian, bukan pada jumlah entri.
T: Apakah audit model akan salah membunuh konten normal? Ya. Jadi setelah terkena disarankan melalui tinjauan manual atau konfirmasi kedua, bukan langsung menolak secara seragam. Tingkat salah bunuh harus diuji tekanan secara terpisah.
T: Bisakah log hanya menyimpan ringkasan? Pemeriksaan kepatuhan biasanya perlu melihat teks asli, hanya menyimpan ringkasan kemungkinan besar tidak akan lolos. Penyimpanan terenkripsi adalah cara yang lebih aman.
Secara singkat: intersepsi input, audit output, dan jejak log tiga lapisan tidak boleh kurang satu pun, setelah intersepsi harus memberikan umpan balik yang dapat dirasakan pengguna, audit harus disimpan sampai bisa dicari balik. Bacaan lanjutan bisa melihat ketentuan spesifik tentang audit keamanan dalamtingkat perlindungan keamanan2.0 tingkat tiga, serta cakupan evaluasi publik dari berbagai model audit.
Penulis: Wang Hanwen
Tanggal publikasi: 9 Oktober 2026