Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Setelah Anda menginterpretasikan skor evaluasi dan mengidentifikasi area fokus, tentukan mengapa kasus pengujian individual gagal dan siapa yang perlu bertindak.
Artikel ini menyediakan panduan terstruktur untuk mendiagnosis kegagalan di tingkat kasus pengujian. Ini membantu Anda mengklasifikasikan akar penyebab, membedakan antara agen, evaluasi, dan masalah infrastruktur, dan memilih tindakan berikutnya yang sesuai.
Sebelum Anda mulai
Sebelum Anda memulai triase kegagalan:
- Selesaikan penilaian interpretasi dan kesiapan skor dan identifikasi kumpulan evaluasi mana yang perlu diperhatikan.
- Fokus pada kegagalan prioritas tertinggi berdasarkan kesiapan dan risiko.
Penting
Jika Anda melewati langkah ini, Anda mungkin menghabiskan waktu untuk masalah berdampak rendah atau masalah yang tidak menghalangi.
Pemeriksaan pra-triase: Memverifikasi kesehatan infrastruktur
Sebelum Anda mendiagnosis kegagalan masing-masing, konfirmasikan bahwa semua dependensi dalam keadaan baik saat evaluasi berlangsung. Masalah infrastruktur dapat menghasilkan kegagalan yang terlihat seperti masalah agen atau evaluasi tetapi tidak terkait dengan keduanya.
Verifikasi kondisi berikut:
- Sumber pengetahuan dapat diakses dan diindeks sepenuhnya.
- Backend atau konektor API tidak mengembalikan kesalahan, batas waktu, atau respons pembatasan laju.
- Token autentikasi valid selama proses.
- Lingkungan evaluasi cocok dengan konfigurasi agen yang dimaksudkan.
Jika dependensi tidak sehat, perbaiki masalah itu dan jalankan kembali evaluasi sebelum melanjutkan. Melakukan triase pada hasil dari eksekusi yang bermasalah dapat menyebabkan kesimpulan yang salah.
Langkah 0: Memprioritaskan kegagalan
Sebelum Anda melakukan triase kasus pengujian individual, putuskan di mana harus fokus terlebih dahulu.
Prioritaskan kegagalan dalam urutan ini:
| Prioritas | Triase pertama | Alasan |
|---|---|---|
| 1 | Kegagalan keamanan dan kepatuhan | Konsekuensi tertinggi. Atasi kegagalan ini sebelum penyebaran. |
| 2 | Kegagalan skenario bisnis inti | Dampak langsung pada proposisi nilai agen. |
| 3 | Kegagalan dalam kumpulan evaluasi penilaian terendah | Kemungkinan sistemik. Memperbaiki akar penyebab dapat mengatasi beberapa kegagalan. |
| 4 | Kegagalan berulang di beberapa pengulangan | Kegagalan yang konsisten lebih mudah didiagnosis. |
| 5 | Kegagalan skenario kemampuan | Penting, tetapi biasanya dampaknya lebih rendah. |
Jika Anda mengalami banyak kegagalan (misalnya, lebih dari 15), jangan melakukan triase setiap kegagalan satu per satu. Mulailah dengan kumpulan evaluasi penilaian terendah dan tinjau beberapa kegagalan secara manual. Jika mereka berbagi akar penyebabnya, memperbaikinya dapat menyelesaikan banyak kegagalan sekaligus.
Mengidentifikasi sinyal kualitas untuk pengujian yang gagal
Jika hasil evaluasi menunjukkan kasus pengujian yang gagal tetapi tidak mengidentifikasi sinyal kualitas dengan jelas, gunakan set evaluasi dan metode penilaian untuk menyimpulkan sinyal.
Contohnya:
- Set evaluasi menunjukkan area kemampuan, seperti keamanan, fondasi, atau penggunaan alat.
- Metode penilaian, seperti kecocokan kata kunci atau penilaian berbasis rubrik, memberikan lebih banyak konteks.
Mengidentifikasi sinyal kualitas yang dimaksudkan membantu Anda memilih pertanyaan diagnostik yang paling relevan.
Langkah 1: Verifikasi penyiapan evaluasi
Penting
Selalu mulai di sini. Sebelum menyelidiki agen, verifikasi bahwa penyiapan evaluasi sudah benar.
Untuk setiap kegagalan, tinjau respons aktual agen secara manual bersama nilai yang diharapkan dan metode penilaian.
Lakukan pertanyaan berikut secara berurutan. Berhenti ketika Anda mencapai hasil.
Apakah respons agen dapat diterima? Apakah pengguna nyata akan puas dengan jawaban ini, meskipun gagal dievaluasi?
- Jika Ya, penyiapan evaluasi memiliki masalah: Sistem penilaian atau nilai yang diharapkan salah.
- Jika Tidak, lanjutkan ke pertanyaan berikutnya.
Apakah jawaban yang diharapkan mutakhir dan akurat terhadap sumbernya?
- Jika Ya, lanjutkan ke pertanyaan berikutnya.
- Jika Tidak, penyiapan evaluasi memiliki masalah: Jawaban yang diharapkan sudah kedaluarsa atau salah.
Apakah kasus pengujian mencerminkan input pengguna yang realistis?
- Jika Ya, lanjutkan ke pertanyaan berikutnya.
- Jika Tidak, penyiapan evaluasi memiliki masalah: Kasus pengujian tidak realistis.
Mungkinkah respons alternatif yang wajar juga benar, tetapi grader tidak mengizinkannya?
- Jika Ya, penyiapan evaluasi memiliki masalah: Grader terlalu kaku dan tidak memperhitungkan variasi yang valid.
- Jika Tidak, lanjutkan ke pertanyaan berikutnya.
Apakah metode evaluasi sesuai untuk apa yang Anda uji?
- Jika Ya, evaluasi valid. Lanjutkan ke Langkah 2: Diagnosis agen.
- Jika Tidak, penyiapan evaluasi memiliki masalah: Metode evaluasi tidak cocok untuk sinyal kualitas ini.
Menentukan penerimaan respons
Gunakan sinyal berikut untuk membantu menentukan apakah respons agen dapat diterima:
- Fakta utama yang sama, kata-kata yang berbeda → Sering dapat diterima (grader mungkin terlalu kaku).
- Informasi penting yang hilang ditemukan di sumber → Seringkali tidak dapat diterima.
- Ambang batas "cukup baik" ambigu → Kriteria penerimaan mungkin tidak jelas (bendera untuk langkah 4).
Jika Anda tidak yakin, bandingkan konten dengan sumber asli, bukan hanya jawaban yang diharapkan.
Sinyal ini menginformasikan penilaian Anda, tetapi jangan menggantinya.
Jenis kegagalan penyiapan evaluasi umum
| Jenis kegagalan | Deskripsi | Example |
|---|---|---|
| Jawaban yang diharapkan kedaluarsa | Konten sumber berubah tetapi nilai yang diharapkan tidak diperbarui | Kebijakan diperbarui hingga 15 hari, tetapi evaluasi masih mengharapkan "jendela pengembalian 30 hari." |
| Grader terlalu kaku | Kecocokan kata kunci gagal pada sinonim atau frasa ulang yang valid | Diharapkan "air dingin." Respons agen mengatakan "air dingin, 30 derajat C," yang secara semantik benar. |
| Kasus pengujian tidak realistis | Skenario pengujian tidak cocok dengan perilaku pengguna yang sebenarnya | Menguji kueri 4 paragraf saat pengguna nyata mengetikkan 5-10 kata. |
| Metode evaluasi yang salah | Metode evaluasi tidak cocok dengan apa yang sebenarnya Anda uji | Menggunakan Kecocokan Kata Kunci (Semua) untuk pertanyaan sintesis di mana Bandingkan Arti sesuai. |
| Kesalahan faktual penilai | Model bahasa sebagai hakim menciptakan alasan kegagalan yang tidak nyata (kesalahan terisolasi) | Grader model bahasa mengatakan "respons tidak menyebutkan kebijakan pengembalian" padahal sebenarnya jelas disebutkan. |
| Bias sistematis penilai | Model bahasa sebagai hakim menerapkan standar yang tidak konsisten di seluruh kasus pengujian (masalah kalibrasi) | Grader meluluskan respons singkat tetapi gagal meluluskan respons yang lebih panjang untuk sinyal kualitas yang sama, apa pun kontennya. |
| Kriteria penerimaan ambigu | Nilai yang diharapkan dapat ditafsirkan beberapa cara | "Harus menyertakan informasi harga." Bulanan? Tahunan? Per pengguna? |
Validasi grader
Keandalan grader adalah prasyarat untuk triase yang andal. Jika grader itu sendiri tidak dapat diandalkan, Anda salah dalam mendiagnosis setiap kegagalan yang disentuhnya.
Untuk memvalidasi keandalan grader:
- Pilih 5-10 kasus pengujian di mana Anda mengetahui hasil pass/fail yang benar dari tinjauan manual.
- Jalankan evaluasi dan bandingkan output grader dengan putusan manual.
- Jika grader tidak setuju pada lebih dari 20% kasus, lakukan kalibrasi ulang pada grader sebelum melakukan debug pada agen.
Tanda-tanda seorang siswa membutuhkan perhatian:
- Kasus pengujian yang sama menghasilkan putusan yang berbeda di seluruh eksekusi.
- Kluster kegagalan dalam set evaluasi yang menggunakan penilaian berbasis model sementara metode deterministik lulus.
- Grader menandai masalah yang tidak dapat Anda reproduksi dengan meninjau respons agen.
Opsi kalibrasi ulang grader:
- Gunakan metode deterministik jika memungkinkan.
- Tambahkan contoh "dapat diterima" dan "tidak dapat diterima" eksplisit ke rubrik.
- Perluas kumpulan kata kunci untuk menyertakan sinonim dan frasa ulang yang valid.
- Gunakan Bandingkan makna alih-alih Kecocokan kata kunci (Semua) untuk memeriksa kesetaraan semantik.
Langkah 2: Mendiagnosis agen
Pada titik ini, evaluasi valid dan agen menghasilkan respons yang salah. Diagnosis apa yang salah dalam konfigurasi agen.
Petunjuk / Saran
Beberapa pertanyaan diagnostik memerlukan visibilitas ke dalam apa yang dilakukan agen secara internal (misalnya, sumber pengetahuan mana yang diambil, alat mana yang dipanggil, atau topik mana yang dipicu). Gunakan log pelacakan, transkrip percakapan, atau analitik pengujian saat tersedia. Jika platform Anda tidak mengekspos detail ini, simpulkan dari respons (misalnya, konten yang hanya muncul di Sumber A kemungkinan berasal dari Sumber A).
Periksa akurasi faktual dan kegagalan landasan pengetahuan
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah agen mengambil dari sumber pengetahuan yang salah? | Konfigurasi sumber pengetahuan. Sumber yang salah diindeks atau diprioritaskan. |
| Apakah agen mengambil sumber yang tepat tetapi mengekstrak informasi yang salah? | Celah perintah atau instruksi. Model membutuhkan panduan ekstraksi. |
| Apakah konten sumber itu sendiri salah atau ketinggalan tahun? | Konten sumber pengetahuan. Perbarui dokumen sumber. |
| Apakah agen menjawab tanpa menggunakan sumber pengetahuan apa pun (membuat jawaban)? | Aksesibilitas sumber. Sumber tidak diindeks, atau penyusunan frasa kueri tidak cocok dengan kosakata sumber. |
| Apakah agen bertentangan dengan informasi yang ada di sumbernya? | Informasi yang salah. Tambahkan instruksi grounding eksplisit. |
Periksa kegagalan pemanggilan alat
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah alat yang salah berfungsi? | Ambiguitas deskripsi alat. Deskripsi tumpang tindih antar alat. |
| Apakah alat yang tepat diaktifkan dengan parameter yang salah? | Definisi parameter. Skema atau deskripsi tidak jelas. |
| Apakah alat tidak menembak sama sekali? | Kondisi pemicu. Input tidak memenuhi kriteria pemanggilan. |
| Apakah alat beroperasi ketika seharusnya tidak? | Pagar pembatas negatif hilang. Tidak ada instruksi kapan tidak memanggil alat. |
| Apakah alat diaktifkan dengan benar tetapi respons menyalahgunakan output? | Instruksi respons. Agen memerlukan panduan tentang output alat pemformatan. |
| Apakah alat diaktifkan dengan benar tetapi alat itu sendiri gagal (kesalahan, waktu habis, data yang salah)? | Masalah alat atau integrasi; kegagalannya ada di sistem backend, bukan agen. Perbaiki alat, bukan agen. |
Periksa kegagalan perutean pemicu
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah topik yang salah diaktifkan? | Pemicu topik tumpang tindih. Pemicu bersifat ambigu antar topik. |
| Apakah tidak ada topik yang diaktifkan (menggunakan fallback)? | Kesenjangan cakupan topik. Tidak ada topik yang menangani jenis input ini. |
| Apakah beberapa topik cocok dengan disambiguasi yang salah? | Logika disambiguasi. Alur prioritas atau klarifikasi salah dikonfigurasi. |
Periksa nada dan kegagalan kualitas respons
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah nada agen tidak konsisten dengan panduan petunjuk sistem? | Kesenjangan instruksi nada. Atasi panduan yang hilang atau bertentangan. |
| Apakah respons terlalu bertele-tele atau terlalu singkat untuk pertanyaan? | Instruksi format. Tambahkan panduan panjang atau struktur. |
| Apakah agen tidak memiliki empati dalam konteks sensitif? | Kesenjangan instruksi empati. Tambahkan panduan eksplisit untuk input emosional. |
| Apakah respons secara struktural buruk (dinding teks, tanpa langkah)? | Instruksi format. Tambahkan persyaratan pemformatan. |
Memeriksa kegagalan keamanan dan batasan
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah agen mengungkapkan informasi sistem? | Perlindungan perintah sistem. Tambahkan instruksi "jangan ungkapkan". |
| Apakah agen keluar dari cakupan? | Kesenjangan definisi cakupan. Lebih jelas mendefinisikan batasan. |
| Apakah agen mematuhi injeksi perintah? | Instruksi keselamatan. Tambahkan panduan ketahanan lawan. |
| Apakah agen salah menangani data pribadi? | Aturan penanganan PII. Tambahkan instruksi perlindungan data. |
Memeriksa eskalasi dan kegagalan yang terkontrol
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah agen gagal melakukan eskalasi ketika seharusnya? | Pemicu eskalasi. Kriteria tidak ditentukan atau terlalu sempit. |
| Apakah agen mengeskalasikan terlalu cepat? | Ambang eskalasi. Kriteria terlalu sensitif. |
| Apakah eskalasi kehilangan konteks percakapan? | Konfigurasi penyerahan. Pelestarian konteks tidak disiapkan. |
| Apakah agen melakukan perulangan alih-alih mengakui kegagalan? | Logika cadangan. Batas coba lagi atau perilaku fallback tidak dikonfigurasi. |
Setelah mendiagnosis, petakan pola kegagalan ke strategi remediasi berdasarkan akar penyebabnya.
Langkah 3: Identifikasi batasan platform
Jika evaluasi benar dan perubahan konfigurasi yang wajar tidak meningkatkan hasil, masalahnya mungkin merupakan batasan platform.
Indikator batasan platform
| Indicator | Apa yang disarankan |
|---|---|
| Kegagalan yang sama berlanjut di beberapa prompt dan variasi konfigurasi | Bukan masalah konfigurasi |
| Pengambilan secara konsisten mengembalikan dokumen yang salah meskipun konfigurasi sumber yang benar | Batasan pemeringkatan pengambilan ulang |
| Agen tidak dapat melakukan penalaran yang diperlukan meskipun ada instruksi yang jelas | Batas kemampuan model |
| Pola orkestrasi yang diperlukan tidak didukung oleh opsi konfigurasi apa pun | Pembatasan logika orkestrasi |
| Grader berbasis model salah mengklasifikasikan secara konsisten meskipun dilakukan penyetelan rubrik | Batasan model penilai |
Jalur tindakan terhadap batasan platform
- Dokumentasikan batasan dengan jelas (apa yang gagal, apa yang Anda coba, dan bukti bahwa itu tidak terkait konfigurasi).
- Terapkan solusi jika memungkinkan (misalnya, restrukturisasi dokumen sumber untuk meningkatkan pengambilan).
- Tandai kasus pengujian sebagai batasan yang diketahui atau sesuaikan ambang batas sehingga tidak memblokir kemajuan yang tidak terkait.
- Eskalasi dengan disertai bukti untuk tim platform.
- Lacak item di log kegagalan untuk evaluasi ulang saat kemampuan platform diperbarui.
Setelah melakukan klasifikasi, tinjau panduan solusi serta eskalasi untuk merespons keterbatasan platform.
Ketika kegagalan tidak sesuai dengan kerangka kerja
Beberapa kegagalan tidak dapat dipetakan dengan jelas ke satu jenis akar penyebab. Contoh umumnya termasuk:
- Masalah kualitas data backend: Konten sumber pengetahuan secara teknis benar tetapi ditulis secara ambigu, jadi agen maupun evaluasi tidak salah.
- Masalah infrastruktur terputus-terputus: Batas waktu jaringan, pembatasan laju API, dan masalah konektor yang tidak bereproduksi secara konsisten.
- Perubahan versi model: Perilaku agen berubah setelah pembaruan model platform yang tidak Anda mulai.
- Kasus pengujian ambigu: Skenarionya ambigu, dan orang yang wajar tidak setuju pada jawaban yang benar.
Pendekatan yang disarankan: Dokumentasikan apa yang Anda amati (kegagalan, respons agen, apa yang Anda periksa). Rekam item sebagai "tidak diklasifikasikan" di log kegagalan. Jika kegagalan berulang, sering kali menjadi dapat diklasifikasikan dengan bukti tambahan.
Menangani penyebab gabungan
Satu kegagalan dapat memiliki beberapa akar penyebab berkontribusi. Contohnya:
- Kegagalan akurasi faktual di mana jawaban yang diharapkan sedikit kedaluarsa (pengaturan evaluasi) dan sumber pengetahuan juga tidak lengkap (konfigurasi agen).
- Kegagalan pemanggilan alat di mana deskripsi alat ambigu (konfigurasi agen) dan orkestrasi tidak mendukung panggilan alat bersyarat (batasan platform).
Pendekatan yang disarankan: Selesaikan penentuan prioritas penuh untuk setiap kegagalan sistem. Jika beberapa jenis akar penyebab berlaku, atasi dalam urutan prioritas:
- Perbaiki evaluasi terlebih dahulu untuk mendapatkan sinyal bersih tentang apakah perubahan agen benar-benar membantu.
- Perbaiki konfigurasi agen untuk menentukan apakah kegagalan yang tersisa benar-benar merupakan masalah platform.
- Dokumentasikan batasan platform hanya setelah 1 dan 2 ditangani.
Jalankan ulang kasus pengujian yang terpengaruh setelah setiap perubahan sebelum melanjutkan.
Menangani kegagalan percakapan berulang
Untuk skenario multi-giliran, kegagalan hanya muncul di seluruh giliran.
Kapan harus mencurigai adanya masalah multi-giliran
- Agen menjawab dengan benar pada giliran awal tetapi bertentangan dengannya sendiri belakangan.
- Agen kehilangan konteks dari panggilan alat sebelumnya atau pengambilan pengetahuan di giliran selanjutnya.
- Waktu eskalasi hanya masuk akal ketika mengacu pada riwayat percakapan lengkap.
- Nada suara agen terdegradasi secara progresif seiring percakapan berlangsung.
- Agen meminta informasi yang sudah disediakan pengguna.
Petunjuk / Saran
Kegagalan mungkin muncul di giliran selanjutnya, sementara akar penyebab terjadi sebelumnya. Telusuri kembali untuk mengidentifikasi putaran pertama tempat percakapan menyimpang.
Pertanyaan diagnostik tambahan
| Pertanyaan | Jika ya → Akar penyebab |
|---|---|
| Apakah kegagalan bergantung pada informasi dari giliran sebelumnya yang hilang? | Masalah manajemen konteks; status percakapan tidak dipertahankan di seluruh giliran. |
| Apakah agen bertentangan dengan sesuatu yang dikatakannya pada giliran sebelumnya? | Kekurangan panduan konsistensi; tidak ada instruksi untuk mempertahankan koherensi di seluruh giliran bicara. |
| Apakah agen meminta informasi lagi yang sudah disediakan pengguna? | Masalah pengambilan konteks; agen tidak mereferensikan putaran percakapan sebelumnya. |
| Apakah kegagalan hanya muncul setelah banyak putaran (5+)? | Panjang konteks efektif terlampaui. |
Panduan remediasi untuk masalah multi-giliran
- Kehilangan konteks: Periksa konfigurasi status percakapan. Pastikan hasil alat dan fakta penting tetap ada di seluruh giliran.
- Kontradiksi: Tambahkan instruksi konsistensi, seperti: "Pertahankan konsistensi dengan respons Anda sebelumnya dalam percakapan ini."
- Mengajukan pertanyaan ulang: Verifikasi konfigurasi memori percakapan platform.
- Degradasi percakapan panjang: Pertimbangkan ringkasan percakapan atau strategi pemangkasan konteks.
Memvalidasi kasus pengujian yang lolos (pemeriksaan positif palsu)
Kerangka kerja ini berfokus pada kasus pengujian yang gagal. Namun, kasus pengujian yang lulus salah dapat menciptakan celah kualitas tersembunyi.
Praktik yang direkomendasikan: Tinjau 5-10% kasus pengujian secara manual setiap kali evaluasi dijalankan, terutama untuk:
- Penilaian berbasis model (risiko positif palsu yang lebih tinggi)
- Sinyal subjektif (nada, kebergunaan)
- Sebelumnya gagal dalam pengujian yang sekarang dinyatakan lulus setelah perubahan
Jika Anda menemukan positif palsu, kalibrasi ulang grader.
Langkah berikutnya
Setelah menyelesaikan triase kegagalan:
- Gunakan Lapisan 3: Memetakan pola kegagalan ke strategi remediasi.
- Gunakan Lapisan 4: Menganalisis pola untuk mengidentifikasi masalah sistemik.
- Tinjau contoh praktis yang menunjukkan bagaimana lapisan kerangka kerja bekerja sama dalam skenario dunia nyata.