Tingkatkan akurasi dengan menambahkan pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails - Amazon Bedrock

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Tingkatkan akurasi dengan menambahkan pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails secara matematis memverifikasi konten bahasa alami terhadap kebijakan yang Anda tetapkan, memastikan kepatuhan ketat terhadap pagar pembatas Anda. Pemeriksaan ini dapat membantu memblokir konten berbahaya atau tidak sesuai secara sistematis sebelum mencapai pengguna Anda. Tidak seperti pendekatan pencocokan pola, Penalaran Otomatis memberikan akurasi yang lebih tinggi dengan lebih sedikit positif palsu, terutama untuk persyaratan kebijakan yang kompleks. Untuk pelanggan yang memprioritaskan presisi, aturan kebijakan dapat disesuaikan untuk meningkatkan efektivitas pagar pembatas melalui pernyataan logika yang jelas.

Tantangan utama dengan model bahasa besar (LLMs) adalah memastikan keakuratan tanggapan mereka. Tanpa validasi, terkadang LLMs dapat menghasilkan halusinasi atau informasi yang tidak akurat yang merusak kepercayaan.

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails memecahkan masalah ini dengan menggunakan teknik matematika untuk:

  • Mendeteksi halusinasi dalam respons LLM

  • Sorot asumsi yang tidak dinyatakan

  • Berikan penjelasan mengapa pernyataan yang akurat benar

Fitur ini sangat berharga ketika Anda perlu menunjukkan dasar faktual untuk respons LLM di:

  • Industri yang diatur seperti perawatan kesehatan dan sumber daya manusia

  • Aplikasi dengan aturan kompleks (persetujuan hipotek, undang-undang zonasi)

  • Skenario kepatuhan yang membutuhkan respons AI yang dapat diaudit

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails tidak akan melindungi terhadap serangan injeksi yang cepat. Pemeriksaan ini memvalidasi dengan tepat apa yang Anda kirimkan kepada mereka - jika konten berbahaya atau dimanipulasi disediakan sebagai input, validasi akan dilakukan pada konten tersebut apa adanya (sampah-masuk, sampah). Untuk mendeteksi dan memblokir serangan injeksi cepat, gunakan filter Konten dalam kombinasi dengan pemeriksaan Penalaran Otomatis.

Penalaran Otomatis hanya menganalisis dan mendeteksi teks yang relevan dengan kebijakan Penalaran Otomatis. Ini akan mengabaikan sisa konten dan tidak dapat memberi tahu pengembang apakah jawabannya di luar topik atau tidak. Jika Anda perlu mendeteksi respons di luar topik, gunakan komponen pagar pembatas lainnya seperti kebijakan topik.

catatan

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails umumnya tersedia di Wilayah AS (Virginia N., Oregon, dan Ohio) dan UE (Frankfurt, Paris, Irlandia).

catatan

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails melengkapi fitur Amazon Bedrock Guardrails lainnya seperti filter konten dan kebijakan topik. Untuk informasi lebih lanjut, lihat komponen Guardrail.

CloudFormation saat ini tidak didukung. CloudFormation Dukungan akan segera hadir.

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails saat ini hanya mendukung bahasa Inggris (AS).

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails tidak mendukung streaming. APIs

Pertimbangan dan batasan

Sebelum menerapkan pemeriksaan Penalaran Otomatis, waspadai batasan penting ini:

  • Kompleksitas dokumen: Dokumen sumber harus terstruktur dengan baik dengan aturan yang jelas dan tidak ambigu. Dokumen yang sangat kompleks dengan kondisi bersarang atau pernyataan yang kontradiktif mungkin tidak mengekstrak secara bersih ke dalam logika formal.

  • Waktu pemrosesan: Validasi Penalaran Otomatis menambahkan latensi ke respons aplikasi Anda. Rencanakan waktu pemrosesan tambahan, terutama untuk kebijakan kompleks dengan banyak aturan.

  • Cakupan kebijakan: Setiap kebijakan harus fokus pada domain tertentu (misalnya, SDM, keuangan, hukum) daripada mencoba mencakup beberapa area yang tidak terkait dalam satu kebijakan.

  • Batas variabel: Kebijakan dengan jumlah variabel yang berlebihan atau interaksi aturan yang terlalu kompleks dapat mencapai batas pemrosesan atau mengembalikan hasil TOO_COMPLEX.

  • Ketergantungan bahasa alami: Keakuratan validasi sangat bergantung pada seberapa baik bahasa alami dalam permintaan pengguna dan respons model dapat diterjemahkan ke variabel logika formal kebijakan Anda.

Praktik terbaik

Ikuti praktik terbaik ini untuk memaksimalkan efektivitas kebijakan Penalaran Otomatis Anda:

  • Mulai sederhana: Mulailah dengan kebijakan terfokus yang mencakup aturan inti, kemudian secara bertahap tambahkan kompleksitas. Uji secara menyeluruh pada setiap tahap.

  • Tulis deskripsi variabel yang komprehensif: Sertakan bagaimana pengguna secara alami merujuk pada konsep, bukan hanya definisi teknis dari dokumen sumber Anda.

  • Kasus tepi uji: Buat pengujian yang secara khusus menargetkan kondisi batas, pengecualian, dan skenario tidak biasa yang mungkin ditemui pengguna Anda.

  • Pantau ambang kepercayaan: Mulailah dengan ambang kepercayaan yang lebih tinggi (0,8-0,9) dan sesuaikan berdasarkan toleransi Anda untuk positif palsu vs negatif palsu.

  • Pemeliharaan kebijakan rutin: Tinjau dan perbarui kebijakan Anda saat aturan bisnis berubah atau saat Anda mengidentifikasi kesenjangan melalui pengujian dan penggunaan produksi.

  • Dokumentasikan anotasi Anda: Melacak modifikasi kebijakan dan alasan di baliknya untuk referensi future dan berbagi pengetahuan tim.

Harga

Pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails dibebankan berdasarkan jumlah permintaan validasi yang diproses. Untuk informasi harga saat ini, lihat halaman harga Amazon Bedrock.

Biaya dikenakan untuk setiap permintaan validasi, terlepas dari hasilnya (misalnya, VALID, INVALID, TRANSLATION_AMBIGUOUS). Untuk mengoptimalkan biaya:

  • Gunakan ambang kepercayaan yang sesuai untuk menyeimbangkan akurasi dengan persyaratan pemrosesan

  • Pertimbangkan hasil validasi caching untuk kueri identik atau serupa bila sesuai untuk kasus penggunaan Anda

  • Pantau pola penggunaan dan sesuaikan kebijakan untuk mengurangi permintaan validasi yang tidak perlu

Inferensi lintas wilayah untuk operasi kebijakan

Penalaran Otomatis menggunakan inferensi lintas wilayah untuk mengoptimalkan kinerja dan ketersediaan pembuatan kebijakan dan operasi pengujian. Operasi API tertentu secara otomatis mendistribusikan pemrosesan di seluruh Wilayah AWS dalam batas geografis Anda untuk memastikan pengiriman layanan yang andal.

Operasi API Penalaran Otomatis berikut menggunakan inferensi lintas wilayah:

  • StartAutomatedReasoningPolicyBuildWorkflow- Dipanggil selama pembuatan kebijakan dan kompilasi dari dokumen sumber

  • StartAutomatedReasoningPolicyTestWorkflow- Dipanggil selama validasi kebijakan dan prosedur pengujian

Operasi ini memanggil model bahasa besar untuk mengekstrak aturan logika formal dari dokumen sumber dan menerjemahkan konstruksi bahasa alami ke dalam representasi logis terstruktur. Untuk memastikan kinerja dan ketersediaan yang optimal, pemrosesan permintaan didistribusikan sesuai dengan perutean geografis berikut:

  • Wilayah Amerika Serikat: Permintaan API yang berasal dari US East (Virginia N.), US West (Oregon), atau US East (Ohio) dapat diproses di Wilayah AS yang didukung.

  • Wilayah Uni Eropa: Permintaan API yang berasal dari UE (Frankfurt), UE (Paris), atau UE (Irlandia) dapat diproses di Wilayah UE mana pun yang didukung.

penting

Data pelanggan tetap berada dalam batas geografis asal (Amerika Serikat atau Uni Eropa) dan diproses sesuai dengan komitmen residensi data AWS. Rute inferensi lintas wilayah meminta secara eksklusif dalam Wilayah geografis yang sama untuk mengoptimalkan kinerja dan ketersediaan layanan.

Inferensi lintas wilayah beroperasi secara transparan tanpa memerlukan konfigurasi pelanggan. Fungsionalitas API tetap konsisten terlepas dari Wilayah tertentu yang memproses permintaan.

Untuk menggunakan pemeriksaan Penalaran Otomatis di Amazon Bedrock Guardrails, ikuti langkah-langkah berikut:

  1. Unggah dokumen sumber yang berisi aturan yang ingin Anda terapkan

  2. Tinjau kebijakan yang diekstraksi dengan konsep dan aturan yang diidentifikasi secara otomatis

  3. Uji dan perbaiki kebijakan untuk memastikannya berfungsi dengan benar

  4. Terapkan kebijakan untuk memvalidasi tanggapan model yayasan Anda

Alur kerja dapat divisualisasikan sebagai:

Source Document → Extracted Policy → Testing → Deployment → Runtime Validation (rules) (formal logic) (verify) (activate) (check responses)

Kebijakan

Kebijakan Penalaran Otomatis adalah dasar dari validasi akurasi, yang berisi aturan logika dan variabel yang secara otomatis diekstraksi dari dokumen sumber Anda. Kebijakan ini berfungsi sebagai representasi matematis dari aturan bisnis Anda, memungkinkan sistem untuk memvalidasi secara sistematis apakah respons model dasar sesuai dengan batasan yang Anda tentukan. Untuk melakukan pemeriksaan Penalaran Otomatis di aplikasi, Anda mengonfigurasi pagar pembatas untuk menggunakan kebijakan yang sesuai dengan persyaratan domain dan validasi spesifik Anda.

Aturan

Aturan adalah logika yang diekstrak oleh Penalaran Otomatis dari dokumen sumber Anda. Ini mungkin ditulis sebagai pernyataan jika-maka. Berikut adalah beberapa contoh format aturan:

if <premise>, then <claim>

<premise> is true

catatan

Penting: Aturan yang tidak dalam format jika-maka dapat memiliki konsekuensi yang tidak diinginkan dengan meletakkan aksioma tentang dunia. Misalnya, jika aturan hanya menyatakanaccountBalance > 5, maka menjadi tidak mungkin saldo akun menjadi 5 atau kurang, terlepas dari apa yang dikatakan konten untuk validasi. Aturan tersebut telah membuat secara logis tidak mungkin kondisi itu ada. Ini dapat menghasilkan hasil validasi yang tidak terduga di mana konten salah ditandai sebagai tidak sesuai karena bertentangan dengan aksioma yang ditetapkan oleh aturan. Untuk menghindari hal ini, struktur aturan sebagai pernyataan bersyarat (jika-maka format) yang menggambarkan hubungan daripada kendala absolut.

Variabel

Variabel mewakili konsep dalam kebijakan Penalaran Otomatis Anda yang dapat memiliki nilai yang ditetapkan padanya saat menerjemahkan bahasa alami ke dalam logika formal. Aturan kebijakan Anda menentukan batasan pada nilai apa yang valid atau tidak valid untuk variabel-variabel ini.

Variabel memiliki nama, tipe, dan deskripsi. Misalnya, kebijakan tentang tunjangan karyawan mungkin memiliki variabel dengan nama “employee_age”, tipe “integer”, dan deskripsi “Usia karyawan dalam tahun”. Variabel ini dapat diberi nilai seperti 25 berdasarkan bahasa alami dalam prompt ke aplikasi.

Misalnya, is_full_time variabel dalam kebijakan SDM mungkin memiliki deskripsi yang menyatakan “Karyawan yang bekerja lebih dari 20 jam per minggu,” yang merupakan kutipan langsung dari dokumen sumber. Saat menggunakan chatbot, pengguna lebih cenderung mengatakan “Saya penuh waktu,” dan bukan, “Saya bekerja lebih dari 20 jam per minggu.”

Keakuratan terjemahan dari bahasa alami ke logika formal sangat tergantung pada kualitas deskripsi variabel. Sementara proses penalaran masuk akal setelah terjemahan selesai, deskripsi variabel yang jelas dan komprehensif memastikan bahwa permintaan pengguna ditafsirkan dengan benar. Tanpa deskripsi variabel lengkap, Penalaran Otomatis mungkin kembali NO_DATA karena tidak dapat menerjemahkan bahasa alami input ke dalam representasi logika formalnya.

Penting untuk deskripsi variabel untuk memperhitungkan skenario seperti ini. Deskripsi variabel yang komprehensif mungkin menyatakan, “Karyawan yang bekerja lebih dari 20 jam per minggu penuh waktu. Pengguna akan mengatakan penuh waktu untuk menetapkan nilai ini ke true, atau paruh waktu untuk mengaturnya ke false.

Jenis variabel yang telah ditentukan

Tabel berikut menjelaskan jenis variabel yang telah ditentukan sebelumnya yang dapat dimiliki kebijakan Anda.

Tipe Deskripsi

bool

Variabel Boolean bisa benar atau salah. Misalnya, dalam kebijakan cuti, Anda akan menggunakan bool variabel untuk mengidentifikasi apakah cuti diperbolehkan atau tidak.

int

intVariabel numerik dapat menyimpan bilangan bulat positif atau negatif. Misalnya, dalam kebijakan cuti, Anda akan menggunakan int variabel untuk menyimpan hari liburan yang masih harus dibayar jika hari pecahan tidak diizinkan.

real

realVariabel numerik dapat menyimpan angka positif atau negatif yang membutuhkan presisi desimal. Misalnya, dalam kebijakan cuti, Anda akan menggunakan real variabel untuk menyimpan jumlah pembayaran dolar untuk hari liburan yang tidak digunakan.

enum

Variabel Enum dapat menyimpan nilai tunggal yang dipilih dari satu set opsi tetap. Misalnya, dalam kebijakan cuti, Anda dapat menggunakan variabel enum untuk menyimpan jenis cuti: (1) Liburan Berbayar; (2) Waktu pribadi; (3) Cuti Ketidakhadiran

Anda juga dapat membuat jenis enum khusus yang ditentukan pengguna yang menyediakan konteks tambahan di luar tipe variabel yang telah ditentukan sebelumnya. Jenis kustom ini memungkinkan Anda menentukan kumpulan nilai tertentu yang relevan dengan domain kebijakan Anda.