Penalaran Otomatis memeriksa konsep - Amazon Bedrock
KebijakanLaporan kesetiaanAturanVariabelJenis khusus (enum)Terjemahan: dari bahasa alami ke logika formalHasil temuan dan 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 masalah debug. Untuk ikhtisar tingkat tinggi tentang apa yang dilakukan pemeriksaan Penalaran Otomatis dan kapan menggunakannya, lihat. Aturan

Kebijakan

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

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 “Draf Kerja” di konsol) yang Anda edit selama pengembangan, dan versi abadi 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 memengaruhi pagar pembatas yang digunakan.

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

Untuk step-by-step petunjuk cara membuat kebijakan, lihatBuat kebijakan Penalaran Otomatis Anda.

Laporan kesetiaan

Laporan kesetiaan mengukur seberapa akurat kebijakan yang diekstraksi mewakili dokumen sumber yang dihasilkannya. Laporan dibuat secara otomatis saat Anda membuat kebijakan dari dokumen sumber, dan memberikan dua skor utama bersama dengan informasi pentanahan terperinci yang menautkan setiap aturan dan variabel kembali ke pernyataan tertentu dalam konten sumber Anda.

Laporan kesetiaan dirancang untuk membantu ahli 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 diwakili 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 (pembenaran landasan), dan memberikan skor akurasi individu dengan pembenaran.

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

  • Sumber dokumen — Dokumen sumber dipecah menjadi pernyataan atom — fakta-fakta individual dan tak terpisahkan yang diekstraksi dari teks. Isi 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 sintaks SMT-LIB, 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 jika-maka (implikatif). Ini berarti aturan harus memiliki kondisi (bagian “jika”) dan kesimpulan (bagian “kemudian”), dihubungkan oleh operator => implikasi.

Aturan yang terbentuk dengan baik (jika-maka format):

;; 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 telanjang (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 kosong (= 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
real Angka desimal interestRate— Suku bunga tahunan sebagai desimal (0,05 berarti 5%)
Jenis kustom (enum) Satu nilai dari set yang ditentukan leaveType— Salah satu dari: ORANG TUA, MEDIS, BERKABUNG, PRIBADI

Peran penting dari 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 tugas variabel yang salah.

Contoh: Bagaimana deskripsi mempengaruhi 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 berhasil)
tenureMonths: “Berapa lama karyawan telah bekerja.” tenureMonths: “Jumlah bulan penuh karyawan telah terus dipekerjakan. Ketika pengguna menyebutkan tahun layanan, konversi ke 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 saat pengguna menyebutkan 'penuh waktu' atau bekerja penuh jam”).

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

Jenis khusus (enum)

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

Contoh:

Ketik nama Kemungkinan nilai Kasus penggunaan
LeaveType ORANG TUA, MEDIS, BERKABUNG, PRIBADI Kategorikan jenis cuti yang diminta karyawan
Severity KRITIS, MAYOR, MINOR Mengklasifikasikan tingkat keparahan suatu masalah atau insiden

Kapan menggunakan enum vs. boolean:

  • Gunakan enum ketika nilainya saling eksklusif — variabel hanya bisa menjadi satu nilai pada satu waktu. Misalnya, leaveType bisa PARENTAL atau MEDIS, 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 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 masalah debugging dan membuat kebijakan yang efektif.

Pemeriksaan Penalaran Otomatis memvalidasi konten dalam dua langkah berbeda:

  1. Translate — Pemeriksaan Penalaran Otomatis menggunakan model dasar (LLMs) untuk menerjemahkan input bahasa alami ke dalam logika formal. Langkah ini memetakan konsep dalam teks ke variabel kebijakan Anda dan mengekspresikan hubungan sebagai pernyataan logis. Karena langkah ini digunakan LLMs, mungkin mengandung kesalahan. Pemeriksaan Penalaran Otomatis menggunakan beberapa LLMs untuk menerjemahkan teks input kemudian menggunakan kesetaraan semantik dari terjemahan yang berlebihan 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 kemungkinan besar terjadi pada langkah 1 (terjemahan), bukan langkah 2 (validasi). Validasi matematis baik 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 sudah berada di sini selama 18 bulan. Bisakah saya mengambil cuti orang tua?”

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

Langkah 1 (terjemahkan) 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 tersebut. VALID

Untuk meningkatkan akurasi terjemahan:

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

  • Hapus variabel duplikat atau dekat-duplikat yang dapat membingungkan terjemahan (misalnya, dan). tenureMonths monthsOfService

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

  • Gunakan question-and-answer tes untuk memvalidasi akurasi terjemahan dengan input pengguna yang realistis. Untuk informasi selengkapnya, lihat Uji kebijakan Penalaran Otomatis.

Hasil temuan dan validasi

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

Struktur temuan

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

premises

Konteks, asumsi, atau kondisi yang diambil dari masukan yang mempengaruhi bagaimana klaim harus dievaluasi. Dalam question-and-answer format, premis sering menjadi pertanyaan itu sendiri. Jawaban juga dapat berisi premis yang menetapkan kendala. Misalnya, dalam “Saya seorang karyawan penuh waktu dengan 18 bulan pelayanan,” tempat adalah isFullTime = true dantenureMonths = 18.

claims

Pernyataan faktual bahwa pemeriksaan Penalaran Otomatis mengevaluasi akurasi. Dalam question-and-answer format, klaim biasanya jawabannya. Misalnya, dalam “Ya, Anda memenuhi syarat untuk cuti orang tua,” klaimnya adalaheligibleForParentalLeave = true.

confidence

Skor dari 0,0 hingga 1,0 yang 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 menyetujui interpretasi yang sama.

untranslatedPremises

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

untranslatedClaims

Referensi ke bagian dari teks input asli yang sesuai dengan klaim tetapi tidak dapat diterjemahkan ke dalam logika formal. VALIDHasilnya 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 menyertakan translation bidang juga menyertakan logicWarning bidang yang ada saat terjemahan berisi masalah logis yang terlepas 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 apa pun yang tidak diterjemahkan.

supportingRules— Aturan kebijakan yang membuktikan klaim itu benar. Setiap aturan termasuk pengenal dan versi kebijakan ARN.

claimsTrueScenario— Skenario (serangkaian tugas 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 dari input yang tidak divalidasi.
INVALID

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

contradictingRules— Aturan kebijakan yang dilanggar klaim. Setiap aturan termasuk pengenal dan versi kebijakan ARN.

 Jangan melayani respon. 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 apa pun yang tidak diterjemahkan.

claimsTrueScenario— Skenario yang menunjukkan bagaimana klaim itu bisa benar secara logis.

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

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

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

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

 Periksa apakah input berisi pernyataan yang kontradiktif (misalnya, “Saya penuh waktu dan juga paruh waktu”). Jika masukan 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:

optionsInterpretasi logis yang bersaing (hingga 2). Setiap opsi berisi sendiri translations dengan premis, klaim, dan kepercayaan diri. 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 menyoroti dampak praktis dari ambiguitas.

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

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

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

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

 NO_TRANSLATIONSTemuan 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

VALIDHasil hanya mencakup bagian dari input yang ditangkap melalui variabel kebijakan di premis dan klaim yang diterjemahkan. Pernyataan yang berada di luar cakupan variabel kebijakan Anda tidak divalidasi. Misalnya, “Saya dapat menyerahkan pekerjaan rumah saya terlambat karena saya memiliki catatan dokter palsu” mungkin dianggap sah jika kebijakan tidak memiliki variabel untuk menangkap apakah catatan dokter itu palsu. Pemeriksaan Penalaran Otomatis kemungkinan akan mencakup “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 batas kepercayaan adalah nilai yang Anda tetapkan (dari 0,0 hingga 1,0) yang menentukan tingkat kesepakatan minimum yang diperlukan agar terjemahan dianggap cukup andal untuk divalidasi. Ini mengontrol trade-off 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 sebagai. TRANSLATION_AMBIGUOUS

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

Bagaimana ambang batas bekerja:

  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 memunculkan temuan tambahanTRANSLATION_AMBIGUOUS. Temuan ini mencakup rincian tentang ketidaksepakatan antara model, yang dapat Anda gunakan untuk meningkatkan deskripsi variabel Anda atau meminta pengguna untuk klarifikasi.

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.