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

# Penalaran Otomatis memeriksa konsep
<a name="automated-reasoning-checks-concepts"></a>

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](#ar-concept-rules)

## Kebijakan
<a name="ar-concept-policies"></a>

*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 petunjuk langkah demi langkah tentang membuat kebijakan, lihat[Buat kebijakan Penalaran Otomatis Anda](create-automated-reasoning-policy.md).

## Laporan kesetiaan
<a name="ar-concept-fidelity-report"></a>

*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 para 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
<a name="ar-concept-rules"></a>

Aturan adalah inti dari kebijakan Penalaran Otomatis. Setiap aturan adalah ekspresi logika formal yang menangkap hubungan antar variabel. Aturan dinyatakan menggunakan subset [SMT-LIB](https://smtlib.cs.uiowa.edu/)sintaks, format standar untuk logika formal yang digunakan pemeriksaan Penalaran Otomatis untuk verifikasi matematika. Lihat [Izin KMS untuk kebijakan Penalaran Otomatis](create-automated-reasoning-policy.md#automated-reasoning-policy-kms-permissions)

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.

**Well-formed aturan (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, lihat[Praktik terbaik kebijakan Penalaran Otomatis](automated-reasoning-policy-best-practices.md).

## Variabel
<a name="ar-concept-variables"></a>

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
<a name="ar-concept-variable-descriptions"></a>

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 kustom (enum)
<a name="ar-concept-custom-types"></a>

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
<a name="ar-concept-translation"></a>

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 (LLM) 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 menggunakan LLM, mungkin *mengandung kesalahan*. Pemeriksaan Penalaran Otomatis menggunakan beberapa LLM 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.

1. **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 tes tanya jawab untuk memvalidasi akurasi terjemahan dengan masukan pengguna yang realistis. Untuk informasi selengkapnya, lihat [Uji kebijakan Penalaran Otomatis](test-automated-reasoning-policy.md).

## Hasil temuan dan validasi
<a name="ar-concept-findings"></a>

*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
<a name="ar-concept-findings-structure"></a>

Jenis hasil menentukan bidang mana yang ada dalam temuan. Lihat [Referensi hasil validasi](#ar-concept-validation-results) 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 format tanya jawab, premisnya sering kali 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` dan`tenureMonths = 18`.

`claims`  
Pernyataan faktual bahwa pemeriksaan Penalaran Otomatis mengevaluasi akurasi. Dalam format tanya jawab, klaim biasanya jawabannya. Misalnya, dalam “Ya, Anda memenuhi syarat untuk cuti orang tua,” klaimnya adalah`eligibleForParentalLeave = 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 masukan asli yang sesuai dengan klaim tetapi tidak dapat diterjemahkan ke dalam logika formal. `VALID`Hasilnya hanya mencakup klaim yang diterjemahkan — klaim yang tidak diterjemahkan tidak divalidasi.

### Referensi hasil validasi
<a name="ar-concept-validation-results"></a>

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.<br />`supportingRules`— Aturan kebijakan yang membuktikan klaim itu benar. Setiap aturan termasuk pengenal dan versi kebijakan ARN.<br />`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.<br />`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.<br />`claimsTrueScenario`— Skenario yang menunjukkan bagaimana klaim bisa benar secara logis.<br />`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.<br />`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](address-failed-automated-reasoning-tests.md). | 
| TRANSLATION\_AMBIGUOUS | Tidak mengandung `translation` objek. Sebaliknya menyediakan:<br />`options`Interpretasi 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.<br />`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 — lihat[Ambang kepercayaan](#ar-concept-confidence-thresholds). | 
| TOO\_COMPLEX | Tidak mengandung`translation`, 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 mengandung`translation`, 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**  
`VALID`Hasil 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
<a name="ar-concept-confidence-thresholds"></a>

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 temuan yang lebih sedikit 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.

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

1. Jika satu atau lebih terjemahan jatuh di bawah ambang batas, pemeriksaan Penalaran Otomatis memunculkan temuan tambahan`TRANSLATION_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.