Uji kebijakan Penalaran Otomatis - Amazon Bedrock
Strategi pengujian: skenario vs. tes qnABuat skenario pengujian secara otomatis di konsolBuat skenario pengujian secara otomatis menggunakan APIBuat tes QnA secara manual di konsolBuat tes QnA menggunakan APIJalankan tesMemahami hasil tes

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

Uji kebijakan Penalaran Otomatis

Pengujian memvalidasi bahwa aturan kebijakan Anda benar dan pemeriksaan Penalaran Otomatis dapat secara akurat menerjemahkan bahasa alami ke dalam logika formal. Anda menguji kebijakan dengan mengirimkan pernyataan bahasa alami untuk validasi, kemudian memeriksa umpan balik untuk memastikan terjemahan menggunakan variabel yang tepat dan bahwa aturan menghasilkan hasil yang diharapkan.

Ada dua pendekatan pengujian komplementer: skenario yang dihasilkan dan tes question-and-answer (qnA). Masing-masing menargetkan bagian yang berbeda dari pipeline validasi. Alur kerja yang disarankan adalah memulai dengan skenario untuk memvalidasi kebenaran aturan, lalu menambahkan tes QnA untuk memvalidasi akurasi terjemahan.

Strategi pengujian: skenario vs. tes qnA

Pemeriksaan Penalaran Otomatis memvalidasi konten dalam dua langkah: pertama, model dasar menerjemahkan bahasa alami ke dalam logika formal; kemudian, teknik matematika memverifikasi logika terhadap aturan kebijakan Anda. Setiap pendekatan pengujian menargetkan langkah yang berbeda dalam jalur ini.

Skenario yang dihasilkan (kebenaran aturan uji)

Skenario yang dihasilkan menguji semantik yang dikodekan dalam aturan kebijakan Anda secara langsung. Mereka menghilangkan ketidakpastian terjemahan bahasa alami dari persamaan, mengisolasi apakah aturan itu sendiri benar.

Skenario dihasilkan dari aturan kebijakan Anda dan mewakili situasi yang secara logis dimungkinkan mengingat aturan tersebut. Mereka diurutkan untuk memunculkan likely-to-be-wrong skenario terbanyak terlebih dahulu. Untuk setiap skenario, Anda meninjau tugas variabel dan memutuskan:

  • Jempol - Skenarionya realistis dan memang harus mungkin. Simpan sebagai SATISFIABLE ujian.

  • Jempol ke bawah - Ada yang tidak aktif. Skenario ini seharusnya tidak dimungkinkan mengingat pengetahuan domain Anda. Berikan umpan balik bahasa alami yang menjelaskan alasannya, dan pemeriksaan Penalaran Otomatis akan mencoba menyimpulkan perubahan aturan yang diperlukan.

Contoh: Kebijakan Anda mengatakan karyawan penuh waktu dengan masa jabatan 12+ bulan memenuhi syarat untuk cuti orang tua. Skenario yang dihasilkan mungkin menunjukkanisFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true. Jika skenario ini tidak memungkinkan (karena 3 bulan kurang dari 12), Anda akan mengacungkan jempol dan menjelaskan bahwa karyawan membutuhkan setidaknya 12 bulan masa jabatan. Ini menunjukkan aturan yang hilang atau salah.

Gunakan skenario sebagai langkah pengujian pertama Anda. Mereka membantu Anda menangkap masalah aturan sebelum Anda menginvestasikan waktu menulis tes QnA.

Tes QnA (akurasi terjemahan uji)

Tes QnA memvalidasi pipeline lengkap end-to-end: terjemahan bahasa alami dan validasi aturan bersama-sama. Mereka meniru interaksi pengguna nyata dan menangkap masalah terjemahan yang tidak dapat dideteksi oleh skenario.

Setiap tes QnA terdiri dari:

  • Input (opsional) - Pertanyaan yang mungkin diajukan pengguna pada aplikasi Anda.

  • Output — Respons yang mungkin dihasilkan oleh model pondasi Anda.

  • Hasil yang diharapkan — Hasil validasi yang Anda harapkan (misalnya, VALID atauINVALID).

Contoh: Untuk kebijakan cuti orang tua yang sama, tes QnA mungkin: input = “Saya telah bekerja di sini selama 2 tahun penuh waktu. Bisakah saya mengambil cuti orang tua?” , output = “Ya, Anda memenuhi syarat untuk cuti orang tua. “, hasil yang diharapkan =VALID. Ini menguji apakah pemeriksaan Penalaran Otomatis menerjemahkan dengan benar “2 tahun” ke tenureMonths = 24 dan “penuh waktu” ke. isFullTime = true

Tip

Buat tes yang mencakup skenario yang valid dan tidak valid. Misalnya, jika kebijakan Anda menyatakan “Karyawan membutuhkan 1 tahun layanan untuk cuti orang tua,” buat tes untuk tanggapan yang menyatakan aturan ini dengan benar dan tes untuk tanggapan yang salah menyatakan persyaratan yang berbeda.

  1. Hasilkan dan tinjau skenario. Mulai di sini untuk memvalidasi bahwa aturan Anda benar. Perbaiki masalah aturan apa pun sebelum melanjutkan.

  2. Tulis tes QnA untuk kasus penggunaan utama. Fokus pada pertanyaan yang paling mungkin diajukan pengguna Anda dan tanggapan LLM Anda kemungkinan besar akan dihasilkan. Sertakan kasus tepi dan kondisi batas.

  3. Jalankan semua tes. Periksa apakah skenario dan tes QnA lulus.

  4. Iterasi. Jika tes gagal, tentukan apakah masalahnya ada dalam aturan (perbaiki kebijakan) atau dalam terjemahan (tingkatkan deskripsi variabel). Untuk informasi selengkapnya, lihat Memecahkan masalah dan menyempurnakan kebijakan Penalaran Otomatis Anda.

Buat skenario pengujian secara otomatis di konsol

  1. Buka kebijakan Penalaran Otomatis yang ingin Anda uji (misalnya, MyHrPolicy).

  2. Pilih Lihat tes, lalu pilih Hasilkan.

  3. Dalam dialog Hasilkan skenario, tinjau skenario yang dihasilkan dan aturan terkait. Setiap skenario menunjukkan serangkaian penugasan variabel yang secara logis dimungkinkan mengingat aturan kebijakan Anda. Evaluasi apakah skenario realistis di domain Anda:

    • Jika skenario bisa terjadi di domain Anda (itu memuaskan), pilih ikon jempol ke atas. Ini menyimpan skenario sebagai tes yang mengharapkan SATISFIABLE hasil.

    • Jika skenario tidak memungkinkan, pilih ikon jempol ke bawah. Berikan anotasi yang menjelaskan alasannya — misalnya, “Karyawan membutuhkan setidaknya 12 bulan masa jabatan untuk cuti orang tua, tetapi skenario ini menunjukkan 3 bulan dengan kelayakan.” Pemeriksaan Penalaran Otomatis menggunakan umpan balik Anda untuk menyimpulkan perubahan aturan yang akan mencegah skenario ini.

    • Jika Anda menginginkan skenario yang berbeda, pilih Regenerasi skenario.

    Tip

    Untuk memeriksa versi logika formal skenario, aktifkan Tampilkan SMT-LIB. Ini berguna untuk memahami dengan tepat aturan dan penugasan variabel mana yang terlibat.

  4. Pilih Simpan dan tutup untuk menyimpan tes, atau Simpan dan tambahkan yang lain untuk melanjutkan meninjau skenario.

  5. Jika Anda memberikan anotasi (umpan balik jempol ke bawah) ke skenario apa pun, pilih Terapkan anotasi. Pemeriksaan Penalaran Otomatis akan memulai alur kerja build untuk menerapkan perubahan pada kebijakan Anda berdasarkan umpan balik Anda.

  6. Pada layar Meninjau perubahan kebijakan, tinjau perubahan yang diusulkan pada aturan, variabel, dan jenis variabel kebijakan Anda. Kemudian pilih Terima perubahan.

Buat skenario pengujian secara otomatis menggunakan API

Gunakan GetAutomatedReasoningPolicyNextScenario API untuk mengambil skenario pengujian yang dihasilkan berdasarkan aturan kebijakan Anda.

policyArn(Diperlukan)

ARN dari kebijakan Penalaran Otomatis.

buildWorkflowId(Diperlukan)

Pengidentifikasi alur kerja build untuk skenario yang dihasilkan. Ambil alur kerja build terbaru menggunakan API. ListAutomatedReasoningPolicyBuildWorkflows

Contoh:

aws bedrock get-automated-reasoning-policy-next-scenario \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

Respons mencakup skenario yang dihasilkan dengan penugasan variabel dan aturan kebijakan terkait. Tinjau skenario dan gunakan CreateAutomatedReasoningPolicyTestCase API untuk menyimpannya sebagai pengujian, atau gunakan anotasi APIs untuk memberikan umpan balik jika skenario mengungkapkan masalah aturan.

Buat tes QnA secara manual di konsol

  1. Buka kebijakan Penalaran Otomatis yang ingin Anda uji (misalnya, MyHrPolicy).

  2. Pilih Lihat tes, lalu pilih Tambah.

  3. Dalam Tambahkan tes dialog, lakukan hal berikut:

    1. Untuk Input (opsional), masukkan pertanyaan yang mungkin diajukan pengguna. Untuk Output, masukkan respons yang mungkin diberikan model foundation Anda. Bersama-sama ini membentuk pasangan QnA yang menguji bagaimana kebijakan Anda memvalidasi interaksi pengguna yang sebenarnya.

    2. Pilih hasil yang Anda harapkan dari tes (seperti Valid atau Tidak Valid).

    3. (Opsional) Pilih ambang Keyakinan, yang merupakan tingkat kepercayaan minimum untuk validasi logika. Pemeriksaan Penalaran Otomatis menggunakan beberapa LLMs untuk menerjemahkan bahasa alami ke dalam temuan. Ini hanya mengembalikan temuan yang didukung oleh persentase yang signifikan dari terjemahan LLM. Ambang batas kepercayaan mendefinisikan persentase minimum dukungan yang diperlukan untuk terjemahan untuk menjadi temuan dengan hasil validitas. Temuan di bawah ambang batas muncul sebagaiTRANSLATION_AMBIGUOUS.

  4. Pilih Simpan untuk membuat tes.

Buat tes QnA menggunakan API

Gunakan CreateAutomatedReasoningPolicyTestCase API untuk membuat pengujian secara terprogram.

policyArn(Diperlukan)

ARN dari kebijakan Penalaran Otomatis.

queryContent (opsional)

Kueri input atau prompt yang menghasilkan konten, seperti pertanyaan pengguna. Ini memberikan konteks untuk validasi.

guardContent(Diperlukan)

Konten keluaran untuk memvalidasi — respons model dasar yang akan diperiksa akurasinya.

expectedAggregatedFindingsResult (opsional)

Hasil validasi yang diharapkan (misalnya, VALID atauINVALID). Hasil aktual ditentukan dengan menyortir temuan dalam urutan keparahan dan memilih hasil terburuk. Urutan keparahan dari yang terburuk ke yang terbaik adalah:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,,SATISFIABLE,VALID.

confidenceThreshold (opsional)

Tingkat kepercayaan minimum untuk validasi logika.

Contoh:

aws bedrock create-automated-reasoning-policy-test-case \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --query-content "Can I take a leave of absence if I'm a part-time employee?" \
  --guard-content "No, only full-time employees are eligible for leave of absence." \
  --expected-aggregated-findings-result "VALID" \
  --confidence-threshold 0.8

Contoh respons:

{
  "testCaseId": "test-12345abcde",
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk"
}

Jalankan tes

Jalankan tes di konsol

  1. Buka kebijakan Penalaran Otomatis yang ingin Anda validasi (misalnya, MyHrPolicy).

  2. Pilih Lihat tes.

  3. Lakukan salah satu tindakan berikut:

    • Untuk menjalankan semua pengujian, pilih Validasi semua pengujian.

    • Untuk menjalankan tes tunggal, pilih tombol Tindakan di sebelah tes dan pilih Validasi.

Jalankan pengujian menggunakan API

Gunakan StartAutomatedReasoningPolicyTestWorkflow API untuk menjalankan pengujian dan GetAutomatedReasoningPolicyTestResult API untuk mengambil hasil.

policyArn(Diperlukan)

ARN dari kebijakan Penalaran Otomatis.

buildWorkflowId(Diperlukan)

Pengidentifikasi alur kerja build untuk menjalankan pengujian terhadap. Ambil alur kerja build terbaru menggunakan API. ListAutomatedReasoningPolicyBuildWorkflows

testCaseIds (opsional)

Daftar pengidentifikasi pengujian untuk dijalankan. Jika tidak disediakan, semua pengujian untuk kebijakan dijalankan.

Contoh:

# Run tests
aws bedrock start-automated-reasoning-policy-test-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

# Get results for a specific test
aws bedrock get-automated-reasoning-policy-test-result \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690 \
  --test-case-id test-12345abcde

Tanggapan tersebut mencakup hasil tes terperinci dengan temuan validasi dan status eksekusi. Untuk mencantumkan semua hasil pengujian alur kerja build, gunakan ListAutomatedReasoningPolicyTestResults API.

Memahami hasil tes

Ketika tes selesai, Anda menerima serangkaian temuan. Setiap temuan mewakili klaim faktual yang diambil dari input pengujian Anda, bersama dengan hasil validasi, penetapan variabel yang digunakan, dan aturan kebijakan yang mendukung kesimpulan. Untuk penjelasan rinci tentang menemukan struktur dan semua jenis hasil validasi, lihatHasil temuan dan validasi.

Anatomi hasil tes

Setiap hasil tes meliputi:

  • Hasil yang diharapkan - Hasil yang Anda tetapkan saat membuat tes.

  • Hasil aktual — Hasil agregat dari menjalankan tes. Ini ditentukan dengan menyortir temuan dalam urutan keparahan dan memilih hasil terburuk. Urutan keparahan dari yang terburuk ke yang terbaik adalah:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,,SATISFIABLE,VALID. Misalnya, tes dengan dua VALID temuan dan satu IMPOSSIBLE temuan memiliki hasil agregat. IMPOSSIBLE

  • Hasil eksekusi — Apakah tes lulus (hasil yang diharapkan dan aktual cocok) atau gagal.

  • Temuan — Hasil validasi individu. Setiap temuan berisi premis dan klaim yang diterjemahkan, skor kepercayaan, tugas variabel, dan aturan kebijakan yang mendukung kesimpulan.

Interpretasi praktis dari hasil

Tabel berikut merangkum apa arti setiap hasil validasi dalam praktik dan tindakan apa yang harus diambil ketika Anda melihatnya dalam tes. Untuk referensi lengkap termasuk bidang pencarian dan deskripsi terperinci, lihatReferensi hasil validasi.

Hasil Apa artinya Apa yang harus dilakukan
VALID Klaim dalam tanggapan terbukti secara matematis benar mengingat premis dan aturan kebijakan Anda. Temuan ini mencakup supportingRules yang membuktikan klaim dan claimsTrueScenario menunjukkan bagaimana klaim itu benar. Jika ini adalah hasil yang diharapkan, tes lulus. Periksa untranslatedPremises dan untranslatedClaims untuk bagian dari input yang tidak divalidasi - VALID hasilnya hanya mencakup klaim yang diterjemahkan.
INVALID Klaim tersebut bertentangan dengan aturan kebijakan Anda. Temuan ini termasuk contradictingRules menunjukkan aturan mana yang dilanggar. Jika ini adalah hasil yang diharapkan, tes lulus. Jika tidak terduga, periksa apakah aturannya benar atau apakah terjemahan menetapkan variabel yang salah. Tinjau contradictingRules untuk memahami aturan mana yang menyebabkan hasilnya.
SATISFIABLE Klaim konsisten dengan kebijakan Anda tetapi tidak membahas semua aturan yang relevan. Responsnya benar dalam beberapa kondisi tetapi tidak semua. Temuan ini mencakup a claimsTrueScenario dan a yang claimsFalseScenario menunjukkan kondisi di mana klaim itu benar dan salah. Bandingkan dua skenario untuk mengidentifikasi kondisi yang hilang. Ini biasanya berarti responsnya tidak lengkap — itu tidak salah, tetapi tidak menyebutkan semua persyaratan. Pertimbangkan apakah tes Anda harus diharapkan SATISFIABLE atau apakah responsnya harus lebih lengkap.
IMPOSSIBLE Pemeriksaan Penalaran Otomatis tidak dapat mengevaluasi klaim karena premisnya kontradiktif atau kebijakan itu sendiri mengandung aturan yang bertentangan. Periksa apakah input pengujian berisi pernyataan yang kontradiktif (misalnya, “Saya penuh waktu dan juga paruh waktu”). Jika masukan valid, kontradiksi kemungkinan ada dalam kebijakan Anda — periksa laporan kualitas untuk aturan yang bertentangan. Lihat Memecahkan masalah dan menyempurnakan kebijakan Penalaran Otomatis Anda.
TRANSLATION_AMBIGUOUS Terjemahan dari bahasa alami ke logika formal ambigu. Beberapa yang LLMs digunakan untuk terjemahan tidak setuju tentang bagaimana menafsirkan input. Temuan ini mencakup interpretasi alternatif untuk membantu Anda memahami ketidaksepakatan. Ini biasanya merupakan masalah deskripsi variabel. Tinjau interpretasi alternatif untuk memahami di mana ketidaksepakatan itu, kemudian tingkatkan deskripsi variabel yang relevan. Penyebab umum: variabel yang tumpang tindih, deskripsi yang tidak jelas, atau teks input yang ambigu. Lihat Memecahkan masalah dan menyempurnakan kebijakan Penalaran Otomatis Anda.
TOO_COMPLEX Input berisi terlalu banyak informasi untuk pemeriksaan Penalaran Otomatis untuk diproses dalam batas latensinya. Sederhanakan input tes. Jika masalah berlanjut, kebijakan Anda mungkin terlalu rumit — pertimbangkan untuk membaginya menjadi beberapa kebijakan terfokus atau menyederhanakan aturan yang melibatkan aritmatika non-linier.
NO_TRANSLATIONS Input tidak dapat diterjemahkan ke dalam logika formal. Ini biasanya berarti input tidak relevan dengan domain kebijakan Anda, atau kebijakan tidak memiliki variabel untuk memodelkan konsep dalam input. Jika input harus relevan dengan kebijakan Anda, tambahkan variabel yang hilang dan perbarui aturan Anda. Jika input benar-benar di luar topik, hasil ini diharapkan — aplikasi Anda harus menangani konten di luar topik secara terpisah (misalnya, menggunakan kebijakan topik).

Kiat debugging untuk pengujian yang gagal

Ketika tes gagal (hasil sebenarnya tidak sesuai dengan hasil yang diharapkan), gunakan pendekatan berikut untuk mendiagnosis masalah:

  1. Periksa terjemahannya terlebih dahulu. Lihatlah tempat dan klaim dalam temuan. Apakah variabel yang tepat ditetapkan? Apakah nilainya benar? Jika terjemahannya salah, masalahnya ada di deskripsi variabel Anda, bukan aturan Anda. Misalnya, jika “2 tahun” diterjemahkan ke tenureMonths = 2 alih-alihtenureMonths = 24, deskripsi variabel perlu menentukan konversi unit.

  2. Periksa aturannya. Jika terjemahan terlihat benar, masalahnya ada dalam aturan kebijakan Anda. Lihatlah supportingRules atau contradictingRules dalam temuan untuk mengidentifikasi aturan mana yang terlibat. Bandingkan dengan dokumen sumber Anda.

  3. Periksa konten yang tidak diterjemahkan. Lihat untranslatedPremises danuntranslatedClaims. Jika bagian penting dari input tidak diterjemahkan, Anda mungkin perlu menambahkan variabel untuk menangkap konsep-konsep tersebut.

  4. Periksa skor kepercayaan diri. Skor kepercayaan yang rendah menunjukkan model terjemahan tidak setuju. Ini menunjukkan deskripsi variabel ambigu untuk jenis input ini.

Untuk panduan pemecahan masalah terperinci, lihat. Memecahkan masalah dan menyempurnakan kebijakan Penalaran Otomatis Anda