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

Praktik terbaik kebijakan Penalaran Otomatis

Halaman ini mengkonsolidasikan praktik terbaik untuk membuat dan memelihara kebijakan Penalaran Otomatis. Baca ini sebelum membuat kebijakan pertama Anda dan lihat kembali saat men-debug masalah. Untuk fondasi konseptual di balik praktik-praktik ini, lihatPenalaran Otomatis memeriksa konsep. Untuk instruksi step-by-step pembuatan, lihatBuat kebijakan Penalaran Otomatis Anda.

Mulai sederhana dan iterasi

Kesalahan paling umum saat membuat kebijakan Penalaran Otomatis adalah mencoba menangkap seluruh dokumen kompleks dalam satu lintasan. Sebaliknya, mulailah dengan subset terfokus dari aturan Anda dan bangun secara bertahap.

Pendekatan ini memiliki dua keuntungan: membuat masalah lebih mudah untuk diisolasi (Anda tahu bagian mana yang menimbulkan masalah), dan membuat kebijakan tetap dapat dikelola selama pengembangan. Kebijakan dengan 10 aturan yang teruji dengan baik lebih bermanfaat daripada satu dengan 100 aturan yang belum teruji.

Pra-proses dokumen dengan LLM

Untuk dokumen yang panjang, berisi prosa naratif, atau mencampur aturan dengan konten non-aturan (seperti penafian hukum atau latar belakang organisasi), jalankan dokumen melalui LLM sebelum mengunggahnya ke pemeriksaan Penalaran Otomatis. Minta LLM untuk mengekstrak konten sebagai aturan jika-maka eksplisit. Langkah pra-pemrosesan ini secara signifikan meningkatkan kualitas kebijakan yang diekstraksi karena pemeriksaan Penalaran Otomatis bekerja paling baik dengan pernyataan deklaratif yang jelas daripada teks yang tidak terstruktur.

Saat menulis prompt preprocessing Anda, sertakan petunjuk berikut untuk LLM:

Untuk templat prompt terperinci dan alur kerja step-by-step pra-pemrosesan, lihat. (Opsional) Gunakan LLM untuk menulis ulang dokumen sebagai aturan logis

Gunakan implikasi (=>) untuk menyusun aturan

Format jika-maka (menggunakan operator => implikasi) adalah pola penulisan aturan tunggal yang paling penting. Setiap aturan yang menyatakan hubungan bersyarat harus menggunakan format ini.

Pernyataan telanjang (aturan tanpa struktur jika-maka) menciptakan aksioma — pernyataan yang selalu benar. Pernyataan tersebut eligibleForParentalLeave memberi tahu Penalaran Otomatis memeriksa bahwa kelayakan cuti orang tua selalu benar, terlepas dari kondisi apa pun. Masukan apa pun yang mengatakan pengguna tidak memenuhi syarat akan kembali IMPOSSIBLE karena bertentangan dengan aksioma ini.

Pernyataan telanjang hanya sesuai untuk kondisi batas yang harus selalu berlaku, seperti:

;; Account balance can never be negative
(>= accountBalance 0)

;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))

Jika Anda menemukan pernyataan kosong dalam kebijakan yang diekstraksi, tulis ulang sebagai persyaratan atau hapus. Untuk informasi selengkapnya tentang meninjau kebijakan yang diekstraksi, lihat. Tinjau kebijakan yang diekstraksi

Tulis deskripsi variabel yang komprehensif

Deskripsi variabel adalah faktor utama 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 adalah penyebab hasil nomor satu. TRANSLATION_AMBIGUOUS

Deskripsi variabel yang baik harus menjawab empat pertanyaan:

Contoh: Sebelum dan sesudah

Gunakan boolean untuk status non-eksklusif

Saat memodelkan status yang dapat hidup berdampingan, gunakan variabel boolean terpisah alih-alih satu enum. Seseorang bisa menjadi veteran dan guru. Menggunakan enum customerType = {VETERAN, TEACHER} memaksa pilihan di antara mereka, menciptakan kontradiksi logis ketika keduanya berlaku.

Cadangan enum untuk kategori yang benar-benar saling eksklusif di mana hanya satu nilai yang dapat diterapkan pada satu waktu, seperti leaveType = {PARENTAL, MEDICAL, BEREAVEMENT} (seorang karyawan hanya dapat meminta satu jenis cuti pada satu waktu). Untuk informasi selengkapnya tentang jenis kustom, lihatJenis khusus (enum).

Tentukan unit dan format dalam deskripsi variabel

Ambiguitas tentang unit adalah sumber umum kesalahan terjemahan. Jika pengguna mengatakan “Saya telah bekerja di sini selama 2 tahun” dan variabel AndatenureMonths, terjemahannya perlu diketahui untuk mengonversi tahun ke bulan. Jika deskripsi variabel Anda tidak menentukan unit, terjemahan dapat menetapkan tenureMonths = 2 sebagai gantinya. tenureMonths = 24

Selalu tentukan:

Contoh:

Validasi rentang untuk nilai numerik

Untuk variabel numerik, tambahkan aturan batas yang membatasi rentang yang valid. Ini mencegah skenario yang secara logis tidak mungkin dan membantu pemeriksaan Penalaran Otomatis menghasilkan hasil yang lebih bermakna.

;; Account balance cannot be negative
(>= accountBalance 0)

;; Interest rate must be between 0 and 1 (0% to 100%)
(and (>= interestRate 0) (<= interestRate 1))

;; Credit score ranges from 300 to 850
(and (>= creditScore 300) (<= creditScore 850))

;; Tenure in months cannot be negative
(>= tenureMonths 0)

Tanpa aturan batas ini, pemeriksaan Penalaran Otomatis dapat mempertimbangkan skenario dengan saldo akun negatif atau skor kredit di atas 1000, yang tidak ada artinya di domain Anda. Aturan batas adalah salah satu dari sedikit kasus di mana pernyataan telanjang (aturan tidak dalam format jika-maka) sesuai.

Gunakan variabel perantara untuk abstraksi

Ketika beberapa aturan berbagi kondisi umum, ekstrak kondisi itu ke dalam variabel boolean perantara. Ini menyederhanakan aturan Anda dan membuat kebijakan lebih mudah dipertahankan.

Contoh: Tingkatan keanggotaan

Alih-alih mengulangi kondisi keanggotaan di setiap aturan manfaat:

;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)

Tentukan variabel perantara dan referensikan:

;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)

Pola ini memudahkan untuk memperbarui kriteria keanggotaan nanti - Anda hanya perlu mengubah satu aturan, bukan tiga.

Gunakan enum untuk kategorisasi

Ketika variabel mewakili kategori dengan set tetap nilai yang saling eksklusif, gunakan tipe kustom (enum) alih-alih beberapa boolean atau string. Enum membatasi nilai yang mungkin dan membuat aturan lebih jelas.

Jaga logika deklaratif, bukan prosedural

Kebijakan Penalaran Otomatis menggambarkan apa yang benar, bukan bagaimana menghitungnya. Hindari menulis aturan yang terlihat seperti kode dengan langkah-langkah berurutan atau logika prioritas.

Demikian pula, hindari pengkodean prioritas atau prioritas antar aturan. Dalam logika formal, semua aturan berlaku secara bersamaan. Jika Anda perlu menyatakan bahwa satu kondisi mengesampingkan yang lain, kodekan secara eksplisit dalam kondisi aturan:

;; GOOD: Explicit exception handling
;; General rule: full-time employees with 12+ months get parental leave
(=> (and isFullTime (> tenureMonths 12) (not isOnProbation))
    eligibleForParentalLeave)

;; BAD: Trying to encode precedence
;; "Rule 1 takes priority over Rule 2" — this concept doesn't exist
;; in formal logic. Instead, combine the conditions into a single rule.

Konvensi penamaan

Penamaan yang konsisten membuat kebijakan lebih mudah dibaca, dipelihara, dan di-debug. Ikuti konvensi ini:

Hindari singkatan yang mungkin ambigu. Gunakan tenureMonths sebagai penggantitenMo, dan isFullTime bukannyaft. Nama yang jelas membantu pengulas manusia dan proses penerjemahan.

Anti-pola umum

Pola berikut sering menyebabkan masalah dalam kebijakan Penalaran Otomatis. Jika Anda menemukan hasil pengujian yang tidak terduga, periksa apakah kebijakan Anda berisi salah satu dari anti-pola ini.

Aksioma bukan implikasi

Seperti dijelaskan dalamGunakan implikasi (=>) untuk menyusun aturan, pernyataan telanjang menciptakan aksioma yang selalu benar. Ini adalah anti-pola yang paling umum dan paling merusak — itu membuat seluruh kategori input kembali. IMPOSSIBLE

Gejala: Tes yang harus kembali VALID atau INVALID kembali IMPOSSIBLE sebagai gantinya.

Perbaiki: Temukan pernyataan kosong dalam aturan Anda dan tulis ulang sebagai implikasi, atau hapus jika tidak mewakili kondisi batas.

Variabel yang tumpang tindih

Memiliki dua variabel yang mewakili konsep yang sama atau serupa (misalnya, tenureMonths danmonthsOfService) membingungkan proses penerjemahan. Pemeriksaan Penalaran Otomatis tidak dapat menentukan variabel mana yang akan digunakan untuk konsep tertentu, yang mengarah ke terjemahan dan hasil yang tidak konsisten. TRANSLATION_AMBIGUOUS

Gejala: Tes kembali TRANSLATION_AMBIGUOUS bahkan dengan teks input yang jelas dan tidak ambigu.

Perbaiki: Gabungkan variabel yang tumpang tindih menjadi satu variabel dengan deskripsi komprehensif. Perbarui semua aturan yang mereferensikan variabel yang dihapus.

Kebijakan yang terlalu kompleks

Kebijakan dengan terlalu banyak variabel, kondisi bersarang dalam, atau aritmatika non-linier dapat melebihi batas pemrosesan dan mengembalikan hasil. TOO_COMPLEX

Gejala: Tes kembali TOO_COMPLEX atau waktu habis.

Perbaiki: Sederhanakan kebijakan. Hapus variabel yang tidak digunakan, pecahkan aturan kompleks menjadi yang lebih sederhana menggunakan variabel perantara, dan hindari aritmatika non-linier (eksponen, bilangan irasional). Jika domain Anda benar-benar kompleks, pertimbangkan untuk membaginya menjadi beberapa kebijakan terfokus.

Aturan kontradiktif

Aturan yang saling bertentangan membuat pemeriksaan Penalaran Otomatis tidak mungkin mencapai kesimpulan. Misalnya, satu aturan mengatakan karyawan penuh waktu memenuhi syarat untuk cuti, sementara yang lain mengatakan karyawan di tahun pertama mereka tidak memenuhi syarat - tanpa menentukan apa yang terjadi pada karyawan penuh waktu di tahun pertama mereka.

Gejala: Tes kembali IMPOSSIBLE untuk input yang melibatkan aturan yang bertentangan.

Perbaiki: Periksa laporan kualitas untuk aturan yang bertentangan. Selesaikan konflik dengan menggabungkan aturan menjadi satu aturan dengan kondisi eksplisit, atau dengan menghapus salah satu aturan yang bertentangan. Untuk informasi selengkapnya, lihat Tinjau kebijakan yang diekstraksi.

Variabel yang tidak digunakan

Variabel yang tidak direferensikan oleh aturan apa pun menambah noise pada proses penerjemahan. Terjemahan dapat menetapkan nilai ke variabel yang tidak digunakan, membuang-buang kapasitas pemrosesan dan berpotensi menyebabkan TRANSLATION_AMBIGUOUS hasil ketika variabel yang tidak digunakan bersaing dengan variabel aktif yang serupa.

Gejala: TRANSLATION_AMBIGUOUS Hasil yang tidak terduga, atau terjemahan yang menetapkan nilai ke variabel yang tidak memengaruhi aturan apa pun.

Perbaiki: Hapus variabel yang tidak digunakan. Di konsol, cari indikator peringatan di sebelah variabel. Melalui API, periksa laporan kualitas dari GetAutomatedReasoningPolicyBuildWorkflowResultAssets dengan--asset-type QUALITY_REPORT.

Nilai enum tidak ada

Jika enum Anda tidak menyertakan nilai untuk setiap kategori yang mungkin disebutkan pengguna, terjemahan mungkin gagal atau menghasilkan hasil yang tidak terduga ketika input tidak cocok dengan nilai yang ditentukan.

Gejala: Tes kembali TRANSLATION_AMBIGUOUS atau NO_TRANSLATIONS ketika input menyebutkan kategori yang tidak ada di enum.

Perbaiki: Tambahkan NONE nilai OTHER atau ke enum Anda untuk menangani input yang tidak cocok dengan kategori yang ditentukan. Perbarui deskripsi nilai enum untuk memperjelas kapan setiap nilai berlaku.