View a markdown version of this page

Penalaran Otomatis memeriksa konsep - Amazon Bedrock
KebijakanLaporan kesetiaanAturanVariabelJenis kustom (enum)Terjemahan: dari bahasa alami ke logika formalTemuan dan hasil validasiAmbang kepercayaan

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

Penalaran Otomatis memeriksa konsep

Halaman ini menjelaskan blok bangunan pemeriksaan Penalaran Otomatis. Memahami konsep-konsep ini akan membantu Anda membuat kebijakan yang efektif, menafsirkan hasil pengujian, dan men-debug masalah. Untuk ikhtisar tingkat tinggi tentang apa yang dilakukan pemeriksaan Penalaran Otomatis dan kapan menggunakannya, lihatAturan.

Kebijakan

Kebijakan Penalaran Otomatis adalah sumber daya di akun AWS Anda yang berisi serangkaian aturan logika formal, skema variabel, dan tipe kustom opsional. Kebijakan ini mengkodekan aturan bisnis, peraturan, atau pedoman yang ingin Anda validasi tanggapan LLM.

Kebijakan dibuat dari dokumen sumber — seperti buku pegangan SDM, manual kepatuhan, atau spesifikasi produk — yang menjelaskan aturan dalam bahasa alami. Saat Anda membuat kebijakan, pemeriksaan Penalaran Otomatis mengekstrak aturan dan variabel dari dokumen Anda dan menerjemahkannya ke dalam logika formal yang dapat diverifikasi secara matematis.

Hubungan antara kebijakan, pagar pembatas, dan aplikasi Anda adalah sebagai berikut:


Source Document ──► Automated Reasoning Policy ──► Guardrail ──► Your Application
  (natural          (rules + variables +           (references     (calls guardrail
   language)         custom types)                  a policy        APIs to validate
                                                    version)        LLM responses)

Karakteristik utama kebijakan:

  • Setiap kebijakan diidentifikasi oleh Nama Sumber Daya Amazon (ARN) dan ada di Wilayah AWS tertentu.

  • Kebijakan memiliki DRAFT versi (disebut “Working Draft” di konsol) yang Anda edit selama pengembangan, dan versi yang tidak dapat diubah bernomor yang Anda buat untuk penerapan.

  • Pagar pembatas dapat merujuk kebijakan DRAFT atau versi bernomor tertentu. Menggunakan versi bernomor berarti Anda dapat memperbarui DRAFT tanpa mempengaruhi pagar pembatas yang Anda gunakan.

  • Setiap kebijakan harus fokus pada domain tertentu (misalnya, manfaat SDM, kelayakan pinjaman, aturan pengembalian produk) daripada mencoba mencakup beberapa area yang tidak terkait.

Untuk petunjuk langkah demi langkah tentang membuat kebijakan, lihatBuat kebijakan Penalaran Otomatis.

Laporan kesetiaan

Laporan kesetiaan mengukur seberapa akurat kebijakan yang diekstraksi mewakili dokumen sumber yang dihasilkan darinya. Laporan dibuat secara otomatis saat Anda membuat kebijakan dari dokumen sumber. Ini memberikan dua skor kunci bersama dengan informasi landasan terperinci yang menghubungkan setiap aturan dan variabel kembali ke pernyataan tertentu dalam konten sumber Anda.

Laporan kesetiaan dirancang untuk membantu pakar materi pelajaran non-teknis mengeksplorasi dan memvalidasi kebijakan tanpa perlu memahami logika formal. Di konsol, tab Dokumen Sumber menampilkan laporan kesetiaan sebagai tabel pernyataan atom bernomor yang diekstrak dari dokumen Anda, menunjukkan aturan dan variabel mana yang menjadi dasar setiap pernyataan. Anda dapat memfilter berdasarkan aturan atau variabel tertentu dan mencari konten dalam pernyataan.

Laporan kesetiaan mencakup dua skor, masing-masing berkisar antara 0,0 hingga 1,0:

  • Skor cakupan — Menunjukkan seberapa baik kebijakan mencakup pernyataan dalam dokumen sumber. Skor yang lebih tinggi berarti lebih banyak konten sumber terwakili dalam kebijakan.

  • Skor akurasi — Menunjukkan seberapa setia aturan kebijakan mewakili materi sumber. Skor yang lebih tinggi berarti aturan yang diekstraksi lebih cocok dengan maksud dokumen asli.

Di luar skor agregat, laporan kesetiaan memberikan landasan terperinci untuk setiap aturan dan variabel dalam kebijakan:

  • Laporan aturan — Untuk setiap aturan, laporan mengidentifikasi pernyataan spesifik dari dokumen sumber yang mendukungnya (pernyataan landasan), menjelaskan bagaimana pernyataan tersebut membenarkan aturan (justifikasi landasan), dan memberikan skor akurasi individu dengan justifikasi.

  • Laporan variabel — Untuk setiap variabel, laporan mengidentifikasi pernyataan sumber yang mendukung definisi variabel, menjelaskan justifikasi, dan memberikan skor akurasi individu.

  • Sumber dokumen — Dokumen sumber dipecah menjadi pernyataan atom — fakta individu yang tak terpisahkan yang diekstraksi dari teks. Konten dokumen dianotasi dengan nomor baris sehingga Anda dapat melacak setiap aturan dan variabel kembali ke lokasi yang tepat di dokumen asli.

Aturan

Aturan adalah inti dari kebijakan penalaran otomatis. Setiap aturan adalah ekspresi logika formal yang menangkap hubungan antar variabel. Aturan dinyatakan menggunakan subset SMT-LIB sintaks, format standar untuk logika formal yang digunakan pemeriksaan Penalaran Otomatis untuk verifikasi matematika. Lihat Izin KMS untuk kebijakan Penalaran Otomatis

Sebagian besar aturan harus mengikuti format if-then (implikatif). Ini berarti aturan harus memiliki kondisi (bagian “jika”) dan kesimpulan (bagian “lalu”), dihubungkan oleh operator => implikasi.

Well-formed aturan (format jika-maka): 

;; If the employee is full-time AND has worked for more than 12 months,
;; then they are eligible for parental leave.
(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)

;; If the loan amount is greater than 500,000, then a co-signer is required.
(=> (> loanAmount 500000) requiresCosigner)

Pernyataan kosong (aturan tanpa struktur jika-maka) menciptakan aksioma — pernyataan yang selalu benar. Ini berguna untuk memeriksa kondisi batas seperti saldo akun yang memiliki nilai positif, tetapi juga dapat membuat kondisi tertentu secara logis tidak mungkin dan menyebabkan IMPOSSIBLE hasil yang tidak terduga selama validasi. Misalnya, pernyataan sederhana (= eligibleForParentalLeave true) berarti pemeriksaan Penalaran Otomatis memperlakukannya sebagai fakta bahwa pengguna memenuhi syarat untuk cuti orang tua. Setiap masukan yang menyebutkan tidak memenuhi syarat akan menghasilkan hasil validasi IMPOSSIBLE karena bertentangan dengan aksioma ini.

;; GOOD: Useful to check impossible conditions such as 
;; negative account balance
(>= accountBalance 0)

;; BAD: This asserts eligibility as always true, regardless of conditions.
eligibleForParentalLeave

Aturan mendukung operator logika berikut:

Operator Arti Contoh
=> Implikasi (jika-maka) (=> isFullTime eligibleForBenefits)
and Logis DAN (and isFullTime (> tenure 12))
or Logis ATAU (or isVeteran isTeacher)
not Logis TIDAK (not isTerminated)
= Kesetaraan (= employmentType FULL_TIME)
>, <, >=, <= Perbandingan (>= creditScore 700)

Untuk praktik terbaik dalam menulis aturan yang efektif, lihatPraktik terbaik kebijakan Penalaran Otomatis.

Variabel

Variabel mewakili konsep dalam domain Anda yang digunakan pemeriksaan Penalaran Otomatis untuk menerjemahkan bahasa alami ke dalam logika formal dan untuk mengevaluasi aturan. Setiap variabel memiliki nama, tipe, dan deskripsi.

Pemeriksaan Penalaran Otomatis mendukung jenis variabel berikut:

Tipe Deskripsi Contoh
BOOL Nilai benar atau salah isFullTime— Apakah karyawan bekerja penuh waktu
INT Bilangan bulat tenureMonths- Jumlah bulan karyawan telah bekerja
NUMBER Angka desimal interestRate— Tingkat bunga tahunan sebagai desimal (0,05 berarti 5%)
Jenis kustom (enum) Satu nilai dari set yang ditentukan leaveType— Salah satu dari: ORANGTUA, MEDIS, BERKABUNG, PRIBADI
Awas

Model domain Anda hanya menggunakan tipe variabel di tabel sebelumnya. Hindari merancang kebijakan yang bergantung pada data yang tidak didukung — seperti string mentah atau teks bentuk bebas — atau yang memerlukan langkah terjemahan untuk menghitung atau menafsirkan nilai. Bertujuan untuk meminimalkan kompleksitas terjemahan.

Pemeriksaan Penalaran Otomatis dirancang untuk menafsirkan bahasa alami, dan tidak berlaku untuk semua bentuk verifikasi. Misalnya, memvalidasi bahwa kata sandi memenuhi serangkaian persyaratan lebih baik ditangani oleh kode deterministik berbasis aturan, karena itu tergantung pada evaluasi nilai mentah karakter demi karakter daripada penalaran di atas bahasa alami.

catatan

Dalam definisi kebijakan, nama variabel, nama tipe kustom, dan nilai yang ditentukan dalam tipe kustom semuanya berbagi satu namespace. Masing-masing dari nama-nama ini harus unik di ketiga kategori. Anda tidak dapat menggunakan nama yang sama untuk variabel dan tipe, dan nilai yang sama tidak dapat muncul di lebih dari satu jenis kustom. Misalnya, jika LeaveType tipe mendefinisikan OTHER nilai, tidak ada tipe lain (sepertiSeverity) juga dapat mendefinisikanOTHER, dan tidak ada variabel yang dapat diberi namaOTHER. Ketika Anda memerlukan nilai serupa di lebih dari satu jenis, awali dengan nama tipe untuk menjaga setiap nama tetap unik sambil mempertahankan artinya - misalnya, LeaveType_OTHER danSeverity_OTHER.

Peran kritis deskripsi variabel

Deskripsi variabel adalah satu-satunya faktor terpenting dalam akurasi terjemahan. Ketika pemeriksaan Penalaran Otomatis menerjemahkan bahasa alami ke dalam logika formal, ia menggunakan deskripsi variabel untuk menentukan variabel mana yang sesuai dengan konsep yang disebutkan dalam teks. Deskripsi yang tidak jelas atau tidak lengkap menyebabkan TRANSLATION_AMBIGUOUS hasil atau penugasan variabel yang salah.

Contoh: Bagaimana deskripsi memengaruhi terjemahan

Pertimbangkan pengguna yang bertanya: “Saya telah bekerja di sini selama 2 tahun. Apakah saya memenuhi syarat untuk cuti orang tua?”

Deskripsi yang tidak jelas (kemungkinan gagal) Deskripsi terperinci (kemungkinan akan berhasil)
tenureMonths: “Berapa lama karyawan telah bekerja.” tenureMonths: “Jumlah bulan lengkap karyawan telah terus dipekerjakan. Ketika pengguna menyebutkan tahun layanan, ubah menjadi bulan (misalnya, 2 tahun = 24 bulan). Setel ke 0 untuk karyawan baru.”

Dengan deskripsi yang tidak jelas, pemeriksaan Penalaran Otomatis mungkin tidak tahu untuk mengubah “2 tahun” menjadi 24 bulan, atau mungkin tidak menetapkan variabel sama sekali. Dengan deskripsi terperinci, terjemahannya tidak ambigu.

Deskripsi variabel yang baik harus:

  • Jelaskan apa yang diwakili variabel dalam bahasa sederhana.

  • Tentukan unit dan format (misalnya, “dalam bulan”, “sebagai desimal di mana 0,15 berarti 15% “).

  • Sertakan sinonim yang tidak jelas dan frasa alternatif yang mungkin digunakan pengguna (misalnya, “Setel ke true ketika pengguna menyebutkan 'penuh waktu' atau bekerja jam penuh”).

  • Jelaskan kondisi batas (misalnya, “Setel ke 0 untuk karyawan baru”).

Jenis kustom (enum)

Jenis kustom menentukan satu set nilai bernama yang dapat diambil variabel. Mereka setara dengan enumerasi (enum) dalam bahasa pemrograman. Gunakan tipe kustom ketika variabel mewakili kategori dengan set tetap dari nilai yang mungkin.

Contoh:

Jenis nama Kemungkinan nilai Kasus penggunaan
LeaveType ORANG TUA, MEDIS, BERKABUNG, PRIBADI Mengkategorikan jenis cuti yang diminta karyawan
Severity KRITIS, MAYOR, MINOR Klasifikasi tingkat keparahan masalah atau insiden

Kapan menggunakan enum vs boolean:

  • Gunakan enum ketika nilai-nilai saling eksklusif — variabel hanya bisa menjadi satu nilai pada satu waktu. Misalnya, leaveType bisa PARENTAL atau MEDICAL, tetapi tidak keduanya secara bersamaan.

  • Gunakan variabel boolean terpisah ketika status dapat hidup berdampingan. Misalnya, seseorang bisa menjadi veteran dan guru. Menggunakan enum customerType = {VETERAN, TEACHER} akan memaksa pilihan di antara mereka, menciptakan kontradiksi logis ketika keduanya berlaku. Sebagai gantinya, gunakan dua boolean: isVeteran dan. isTeacher

Tip

Jika mungkin variabel tidak memiliki nilai apa pun dari enum, sertakan NONE nilai OTHER atau. Ini mencegah masalah terjemahan ketika input tidak cocok dengan salah satu nilai yang ditentukan.

Terjemahan: dari bahasa alami ke logika formal

Terjemahan adalah proses di mana pemeriksaan Penalaran Otomatis mengubah bahasa alami (pertanyaan pengguna dan tanggapan LLM) menjadi ekspresi logika formal yang dapat diverifikasi secara matematis terhadap aturan kebijakan Anda. Memahami proses ini adalah kunci untuk men-debug masalah dan menciptakan kebijakan yang efektif.

Pemeriksaan Penalaran Otomatis memvalidasi konten dalam dua langkah berbeda:

  1. Terjemahkan — Pemeriksaan Penalaran Otomatis menggunakan model dasar (LLM) untuk menerjemahkan input bahasa alami ke dalam logika formal. Langkah ini memetakan konsep dalam teks ke variabel kebijakan Anda dan mengungkapkan hubungan sebagai pernyataan logis. Karena langkah ini menggunakan LLM, mungkin berisi kesalahan. Pemeriksaan Penalaran Otomatis menggunakan beberapa LLM untuk menerjemahkan teks input kemudian menggunakan kesetaraan semantik dari terjemahan redundan untuk menetapkan skor kepercayaan. Kualitas terjemahan tergantung pada seberapa baik deskripsi variabel Anda cocok dengan bahasa yang digunakan dalam input.

  2. Validasi — Pemeriksaan Penalaran Otomatis menggunakan teknik matematika (melalui pemecah SMT) untuk memeriksa apakah logika yang diterjemahkan konsisten dengan aturan kebijakan Anda. Langkah ini secara matematis masuk akal — jika terjemahannya benar, hasil validasi akan konsisten.

penting

Perbedaan dua langkah ini sangat penting untuk debugging. Jika Anda yakin aturan dalam kebijakan sudah benar, ketika pengujian gagal atau mengembalikan hasil yang tidak terduga, masalahnya mungkin kabur pada langkah 1 (terjemahan), bukan langkah 2 (validasi). Validasi matematika adalah benar dan jika terjemahan menangkap makna input dengan benar, hasil validasi akan benar. Fokuskan upaya debugging Anda untuk meningkatkan deskripsi variabel dan memastikan terjemahan menetapkan variabel yang tepat dengan nilai yang tepat.

Contoh: Terjemahan dalam tindakan

Diberikan kebijakan dengan variabel isFullTime (BOOL), tenureMonths (INT), dan eligibleForParentalLeave (BOOL), dan input:

  • Pertanyaan: “Saya seorang karyawan penuh waktu dan saya telah berada di sini selama 18 bulan. Bisakah saya mengambil cuti orang tua?”

  • Jawab: “Ya, Anda memenuhi syarat untuk cuti orang tua.”

Langkah 1 (menerjemahkan) menghasilkan:

Premises: isFullTime = true, tenureMonths = 18
Claims: eligibleForParentalLeave = true

Langkah 2 (validasi) memeriksa penugasan ini terhadap aturan kebijakan (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) dan mengonfirmasi klaim tersebutVALID.

Untuk meningkatkan akurasi terjemahan:

  • Tulis deskripsi variabel terperinci yang mencakup bagaimana pengguna merujuk pada konsep dalam bahasa sehari-hari.

  • Hapus variabel duplikat atau hampir duplikat yang dapat membingungkan terjemahan (misalnya, tenureMonths danmonthsOfService).

  • Hapus variabel yang tidak digunakan yang tidak direferensikan oleh aturan apa pun — variabel tersebut menambahkan noise ke proses terjemahan.

  • Gunakan tes tanya jawab untuk memvalidasi akurasi terjemahan dengan input pengguna yang realistis. Untuk informasi selengkapnya, lihat Uji kebijakan Penalaran Otomatis.

Temuan dan hasil validasi

Ketika Penalaran Otomatis memeriksa memvalidasi konten, itu menghasilkan serangkaian temuan. Setiap temuan mewakili klaim faktual yang diambil dari input, bersama dengan hasil validasi, penetapan variabel yang digunakan, dan aturan kebijakan yang mendukung kesimpulan. Hasil keseluruhan (agregat) ditentukan dengan menyortir temuan dalam urutan keparahan dan memilih hasil terburuk. Urutan tingkat keparahan dari yang terburuk ke yang terbaik adalah: TRANSLATION_AMBIGUOUSIMPOSSIBLE,INVALID,SATISFIABLE,,VALID.

Struktur temuan

Jenis hasil menentukan bidang mana yang ada dalam temuan. Lihat Referensi hasil validasi bagian untuk deskripsi mendalam tentang setiap jenis temuan. Namun, sebagian besar jenis temuan berbagi translation objek umum yang berisi komponen-komponen berikut:

premises

Konteks, asumsi, atau kondisi yang diambil dari input yang mempengaruhi bagaimana klaim harus dievaluasi. Dalam format tanya jawab, premisnya seringkali merupakan pertanyaan itu sendiri. Jawaban juga dapat berisi premis yang menetapkan kendala. Misalnya, dalam “Saya seorang karyawan penuh waktu dengan 18 bulan pelayanan,” tempat tersebut adalah isFullTime = true dantenureMonths = 18.

claims

Pernyataan faktual yang diperiksa Penalaran Otomatis mengevaluasi keakuratannya. Dalam format tanya jawab, klaim biasanya jawabannya. Misalnya, dalam “Ya, Anda memenuhi syarat untuk cuti orang tua,” klaimnya adalaheligibleForParentalLeave = true.

confidence

Skor dari 0,0 hingga 1,0 mewakili bagaimana pemeriksaan Penalaran Otomatis tertentu tentang terjemahan dari bahasa alami ke logika formal. Skor yang lebih tinggi menunjukkan kepastian yang lebih besar. Keyakinan 1,0 berarti semua model terjemahan sepakat pada interpretasi yang sama.

untranslatedPremises

Referensi ke bagian dari teks masukan asli yang sesuai dengan premis tetapi tidak dapat diterjemahkan ke dalam logika formal. Ini menyoroti bagian dari input yang diakui Penalaran Otomatis sebagai relevan tetapi tidak dapat memetakan ke variabel kebijakan.

untranslatedClaims

Referensi ke bagian dari teks masukan asli yang sesuai dengan klaim tetapi tidak dapat diterjemahkan ke dalam logika formal. VALIDHasil hanya mencakup klaim yang diterjemahkan — klaim yang tidak diterjemahkan tidak divalidasi.

Referensi hasil validasi

Setiap temuan persis salah satu dari jenis berikut. Jenis menentukan arti hasil, bidang yang tersedia dalam temuan, dan tindakan yang disarankan untuk aplikasi Anda. Semua jenis temuan yang menyer translation takan bidang juga menyertakan logicWarning bidang yang ada ketika terjemahan berisi masalah logis yang independen dari aturan kebijakan (misalnya, pernyataan yang selalu benar atau selalu salah).

Hasil Menemukan bidang Tindakan yang disarankan
VALID

translation— Premis yang diterjemahkan, klaim, skor kepercayaan, dan referensi yang tidak diterjemahkan.

supportingRulesAturan kebijakan yang membuktikan klaim itu benar. Setiap aturan menyertakan pengidentifikasi dan versi kebijakan ARN.

claimsTrueScenario— Sebuah skenario (serangkaian penugasan variabel) yang menunjukkan bagaimana klaim itu benar secara logis.

 Sajikan respons kepada pengguna. Log supportingRules dan claimsTrueScenario untuk tujuan audit — mereka memberikan bukti validitas yang dapat diverifikasi secara matematis. Periksa untranslatedPremises dan untranslatedClaims untuk bagian input yang tidak divalidasi.
INVALID

translation— Premis yang diterjemahkan, klaim, skor kepercayaan, dan referensi yang tidak diterjemahkan.

contradictingRules— Aturan kebijakan yang dilanggar klaim. Setiap aturan menyertakan pengidentifikasi dan versi kebijakan ARN.

 Jangan melayani tanggapan. Gunakan translation (untuk melihat apa yang diklaim) dan contradictingRules (untuk melihat aturan mana yang dilanggar) untuk menulis ulang respons atau memblokirnya. Dalam loop penulisan ulang, berikan aturan yang bertentangan dan klaim yang salah ke LLM untuk menghasilkan respons yang dikoreksi.
SATISFIABLE

translation— Premis yang diterjemahkan, klaim, skor kepercayaan, dan referensi yang tidak diterjemahkan.

claimsTrueScenario— Sebuah skenario yang menunjukkan bagaimana klaim bisa benar secara logis.

claimsFalseScenario— Sebuah skenario yang menunjukkan bagaimana klaim bisa salah secara logis dalam kondisi yang berbeda.

 Bandingkan claimsTrueScenario dan claimsFalseScenario mengidentifikasi kondisi yang hilang. Tulis ulang tanggapan untuk memasukkan informasi tambahan yang diperlukan untuk membuatnyaVALID, minta klarifikasi pengguna tentang kondisi yang hilang, atau sajikan respons dengan peringatan bahwa itu mungkin tidak lengkap.
IMPOSSIBLE

translation— Premis yang diterjemahkan, klaim, skor kepercayaan, dan referensi yang tidak diterjemahkan. Periksa tempat untuk mengidentifikasi kontradiksi.

contradictingRules— Aturan kebijakan yang bertentangan dengan tempat atau satu sama lain. Jika diisi, kontradiksi mungkin ada dalam kebijakan itu sendiri.

 Periksa apakah input berisi pernyataan yang kontradiktif (misalnya, “Saya penuh waktu dan juga paruh waktu”). Jika input valid, kontradiksi kemungkinan ada dalam kebijakan Anda - periksa contradictingRules dan tinjau laporan kualitas. Lihat Memecahkan masalah dan menyempurnakan kebijakan Penalaran Otomatis Anda.
TRANSLATION_AMBIGUOUS

Tidak mengandung translation objek. Sebaliknya menyediakan:

options— Interpretasi logis yang bersaing (hingga 2). Setiap opsi berisi premis, klaim, dan kepercayaan dirinya sendiritranslations. Bandingkan opsi untuk melihat di mana model tidak setuju.

differenceScenarios— Skenario (hingga 2) yang menggambarkan bagaimana interpretasi yang berbeda berbeda dalam makna, dengan penugasan variabel yang menyoroti dampak praktis dari ambiguitas.

 Periksa options untuk memahami ketidaksepakatan. Tingkatkan deskripsi variabel untuk mengurangi ambiguitas, menggabungkan atau menghapus variabel yang tumpang tindih, atau meminta klarifikasi pengguna. Anda juga dapat menyesuaikan ambang kepercayaan — lihatAmbang kepercayaan.
TOO_COMPLEX

Tidak mengandungtranslation, aturan, atau skenario. Input melebihi kapasitas pemrosesan karena volume atau kompleksitas.

 Persingkat input dengan memecahnya menjadi potongan-potongan kecil, atau menyederhanakan kebijakan dengan mengurangi jumlah variabel, dan hindari aritmatika kompleks (misalnya, eksponen atau bilangan irasional). Anda dapat membagi kebijakan Anda menjadi kebijakan yang lebih kecil dan lebih fokus.
NO_TRANSLATIONS

Tidak mengandungtranslation, aturan, atau skenario. Dapat muncul bersama temuan lain jika hanya sebagian dari input yang dapat diterjemahkan.

 Tem NO_TRANSLATIONS uan dimasukkan dalam output setiap kali salah satu temuan lain mencakup premis atau klaim yang tidak diterjemahkan. Lihatlah temuan lain untuk melihat bagian input mana yang tidak diterjemahkan. Jika konten harus relevan, tambahkan variabel ke kebijakan Anda untuk menangkap konsep yang hilang. Jika konten di luar topik, pertimbangkan untuk menggunakan kebijakan topik untuk memfilternya sebelum mencapai pemeriksaan Penalaran Otomatis.
catatan

Hasil VALID hanya mencakup bagian-bagian dari input yang ditangkap melalui variabel kebijakan dalam premis dan klaim yang diterjemahkan. Pernyataan yang berada di luar cakupan variabel kebijakan Anda tidak divalidasi. Misalnya, “Saya dapat mengirimkan pekerjaan rumah saya terlambat karena saya memiliki catatan dokter palsu” mungkin dianggap valid jika polis tidak memiliki variabel untuk menangkap apakah catatan dokter itu palsu. Pemeriksaan Penalaran Otomatis kemungkinan akan memasukkan “catatan dokter palsu” sebagai premis yang tidak diterjemahkan dalam temuannya. Perlakukan konten dan NO_TRANSLATIONS temuan yang tidak diterjemahkan sebagai sinyal peringatan.

Ambang kepercayaan

Pemeriksaan Penalaran Otomatis menggunakan beberapa model dasar untuk menerjemahkan bahasa alami ke dalam logika formal. Setiap model menghasilkan terjemahannya sendiri secara independen. Skor kepercayaan mewakili tingkat kesepakatan di antara terjemahan ini — khususnya, persentase model yang menghasilkan interpretasi yang setara secara semantik.

Ambang kepercayaan adalah nilai yang Anda tetapkan (dari 0,0 hingga 1,0) yang menentukan tingkat minimum kesepakatan yang diperlukan agar terjemahan dianggap cukup andal untuk divalidasi. Ini mengontrol pertukaran antara cakupan dan akurasi:

  • Ambang batas yang lebih tinggi (misalnya, 0,9): Membutuhkan kesepakatan yang kuat di antara model terjemahan. Menghasilkan lebih sedikit temuan tetapi dengan akurasi yang lebih tinggi. Lebih banyak input akan ditandai sebagaiTRANSLATION_AMBIGUOUS.

  • Ambang batas bawah (misalnya, 0,5): Menerima terjemahan dengan persetujuan yang lebih sedikit. Menghasilkan lebih banyak temuan tetapi dengan risiko terjemahan yang salah yang lebih tinggi. Lebih sedikit input akan ditandai sebagaiTRANSLATION_AMBIGUOUS.

Cara kerja ambang batas:

  1. Beberapa model pondasi masing-masing menerjemahkan input secara independen.

  2. Terjemahan yang didukung oleh persentase model yang sama dengan atau di atas ambang batas menjadi temuan kepercayaan tinggi dengan hasil definitif (VALID,INVALID, dll.).

  3. Jika satu atau lebih terjemahan jatuh di bawah ambang batas, pemeriksaan Penalaran Otomatis menampilkan tem TRANSLATION_AMBIGUOUS uan tambahan. Temuan ini mencakup detail tentang ketidaksepakatan antara model, yang dapat Anda gunakan untuk meningkatkan deskripsi variabel Anda atau meminta klarifikasi pengguna.

Tip

Mulailah dengan ambang batas default dan sesuaikan berdasarkan hasil pengujian Anda. Jika Anda melihat terlalu banyak TRANSLATION_AMBIGUOUS hasil untuk input yang seharusnya tidak ambigu, fokuslah pada peningkatan deskripsi variabel Anda daripada menurunkan ambang batas. Menurunkan ambang batas dapat mengurangi TRANSLATION_AMBIGUOUS hasil tetapi meningkatkan risiko validasi yang salah.