Penilaian RAG: liputan bukti dan ketepatan jawapan
Oleh Ai Flowi · Diterbitkan
Penilaian RAG menyemak sama ada carian semula menemukan bukti yang diperlukan dan sama ada jawapan yang dijana menggunakan bukti itu dengan betul. Nilai liputan petikan, asas bukti jawapan dan kegunaannya secara berasingan: jawapan yang kelihatan tepat boleh menyembunyikan carian semula yang lemah, manakala petikan yang relevan masih boleh menghasilkan respons tanpa sokongan bukti. Mulakan dengan soalan berlabel dan petikan sumber sebelum menambah penilai automatik.
Prosedur ini menggunakan komponen katalog AI Flowi Workflow untuk mengatur pelaksanaan penilaian yang dicadangkan. Komponen itu didokumenkan dalam katalog; belum diuji dalam produksi oleh Ai Flowi. Output penilai yang dihuraikan di sini ialah kontrak antara muka, bukan hasil kualiti yang diukur atau skor penanda aras.
1. Bina korpus soalan dengan label bukti
Simpan setiap kes dalam CSV dengan pengecam kes yang stabil, soalan, label kebolehan menjawab, versi sumber yang diluluskan, pengecam petikan yang diperlukan dan nota penerimaan ringkas. Tulis label berdasarkan dokumen, bukan jawapan semasa chatbot. Sertakan soalan yang memerlukan pengecualian serta peraturan utama; jika tidak, sistem yang menggugurkan pengecualian mungkin kelihatan memadai.
Ikuti antara muka Load CSV dan rujukan penukaran Data → DataFrame untuk mengimport korpus berlabel.
Pengecam kes mesti mengenal pasti soalan bersama versi sumber. Jika dasar berubah, simpan rekod kes lama dan cipta versi baharu label buktinya. Jika tidak, perubahan jawapan jangkaan boleh kelihatan seperti kemerosotan model walaupun model mengikuti dasar baharu dengan betul. Kekalkan kes dengan permintaan carian semula yang gagal dalam set data; menggugurkannya tanpa penjelasan menyebabkan perbandingan hanya mengukur respons yang kebetulan diterima.
| Kategori kes | Label bukti rujukan piawai | Kegagalan yang didedahkan |
|---|---|---|
| Peraturan dan pengecualian yang diliputi | Kedua-dua pengecam petikan diperlukan. | Carian semula atau penjanaan menggugurkan pengecualian. |
| Permintaan yang tidak dapat dijawab | Tiada petikan sokongan yang diluluskan tersedia. | Jawapan direka-reka daripada teks yang tidak berkaitan. |
| Konflik versi | Dua sumber bercanggah dan memerlukan semakan. | Percanggahan disembunyikan dalam jawapan yang lancar. |
| Pengalih perhatian yang kelihatan relevan | Hanya petikan tentang perkara yang diminta layak digunakan. | Persamaan kata pada permukaan diberi kedudukan lebih tinggi daripada bukti yang terpakai. |
2. Rekodkan input carian semula dan jawapan yang sebenar
Jalankan soalan melalui Knowledge Base.search_query dengan knowledge_base dan top_k yang tetap; kekalkan metadata menggunakan include_metadata. Simpan Results bersama pengecam kes. Penciptaan pangkalan dan semakan chunk diterangkan dalam panduan carian semula sedia ada. Untuk laluan jawapan, gunakan reka bentuk chatbot berasaskan bukti yang berasingan dan rekodkan teks yang benar-benar dihantar kepada model.
Petikan sumber dalam pangkalan data tidak sama dengan petikan sumber dalam prompt. Rekodkan baris yang diperoleh, konteks yang diformatkan dan jawapan akhir. Jika pemformatan memotong pengecualian yang diperlukan, labelkannya sebagai kegagalan pembinaan konteks. Jangan salahkan penjana atas maklumat yang tidak pernah sampai ke inputnya, atau menganggap dakwaan berasaskan bukti hanya kerana sumbernya wujud di tempat lain.
3. Konfigurasi input penilaian bagi setiap kes
Persediaan penilaian bagi setiap kes: contoh konfigurasi, bukan ujian yang direkodkan
| Komponen | Input katalog untuk ditetapkan | Semakan sebelum meneruskan |
|---|---|---|
| Load CSV dan Data → DataFrame | csv_file: korpus yang disemak; kemudian data_list: JSON List. | Sahkan terdapat satu kes yang boleh dikenal pasti bagi setiap baris yang dihasilkan. |
| Batch Run | df: jadual prompt yang disediakan; column_name: lajur prompt yang disemak; output_column_name: candidate_answer; model: LanguageModel yang dikonfigurasi. | Komponen ini memproses satu lajur; ia bukan bukti bahawa carian semula berjalan secara automatik bagi setiap baris. |
| Cleanlab RAG Evaluator | query: soalan kes; context: bukti sebenar yang dibekalkan; response: jawapan yang disimpan; model: pilihan yang disokong dan dikonfigurasi; quality_preset: "base"; api_key: kelayakan akses anda. | Semak trust_score dan penjelasan bersama label sumber. |
| LangWatch Evaluator | evaluator_name: penilai penyedia yang dikonfigurasi; input: soalan; output: jawapan; contexts: bukti; expected_output: teks penerimaan yang disemak. | Eksport tidak membekalkan pilihan nama penilai; konfigurasi penyedia sebelum percubaan. |
Anda memerlukan akaun model dan penilai sendiri, sebarang kunci API yang diperlukan serta kebenaran menghantar korpus sintetik kepada perkhidmatan tersebut. Penyedia mengenakan caj berasingan. Katalog memberikan input penilaian bertip tetapi tiada resipi orkestrasi lengkap daripada carian semula kepada pemprosesan kelompok. Mulakan dengan satu kes, petakan nilai yang diperhatikan secara jelas dan sahkan setiap sempadan sebelum mencuba pelaksanaan set data.
4. Bagaimana membezakan liputan, asas bukti dan kegunaan dalam penilaian RAG?
Untuk liputan carian semula, bandingkan pengecam petikan yang dipulangkan dengan pengecam rujukan piawai. Untuk asas bukti, semak sama ada setiap dakwaan penting dalam jawapan disokong oleh konteks yang benar-benar dibekalkan. Untuk kegunaan, pastikan jawapan menjawab soalan dan mengekalkan syarat yang terpakai. Semakan ini boleh menghasilkan keputusan berbeza: tidak memberikan jawapan adalah wajar bagi kes yang tidak dapat dijawab tetapi tidak memadai bagi kes yang diliputi sumber.
Cleanlab RAG Evaluator mengeksport suis bernama run_context_sufficiency, run_query_ease, run_response_groundedness dan run_response_helpfulness. Aktifkan semakan yang relevan dengan rubrik anda dan simpan other_scores, trust_explanation dan evaluation_summary untuk semakan. Eksport tidak mentakrifkan skala skor, penentukuran atau ambang lulus sejagat; output berangka bukan label kebenaran yang berautoriti.
Cleanlab Evaluator mempunyai input prompt dan response untuk penilaian respons umum. Ia tidak mempunyai kontrak context dan query yang dinamakan secara berasingan dalam penilai RAG. Pilih antara muka yang sepadan dengan bukti yang hendak anda nilai, dan kekalkan semakan petikan oleh manusia walaupun penjelasan automatik kedengaran meyakinkan.
5. Bandingkan versi berdasarkan pengecam kes
Kekalkan korpus, versi sumber dan rubrik penilaian. Ubah satu pilihan carian semula atau prompt, kemudian bandingkan hasil lama dan baharu bagi kes yang sama. Dalam Table Operations, tetapkan operation kepada pilihan eksport "Merge", merge_on_column kepada pengecam kes anda dan merge_how kepada "outer". Sahkan keunikan pengecam sebelum mencantumkan hasil.
Sebagai contoh perbandingan, bayangkan satu kes mempunyai jawapan garis dasar tetapi tiada jawapan calon kerana permintaan carian semula baharu gagal. Perbandingan luar sepatutnya mengekalkan kes itu untuk semakan kegagalan. Perbandingan dalaman akan menggugurkannya dan mungkin menjadikan calon kelihatan lebih baik. Ini ialah sifat perbandingan yang dijangkakan, bukan hasil Table Operations yang direkodkan; semak baris cantuman sebenar sebelum merumuskan perubahan.
Simpan pilihan model, bilangan hasil carian semula, teks prompt dan tetapan penilai bersama setiap pelaksanaan. Perubahan penilai boleh mengubah penilaian walaupun jawapan tidak berubah. Semak kes yang bertambah baik dan kes yang merosot, serta permintaan gagal dan output yang hilang. Jangan biarkan purata menyembunyikan kegagalan kes yang tidak dapat dijawab atau menganggap tamat masa penilai sebagai jawapan yang berjaya.
6. Gunakan kes sintetik sebagai calon, bukan kebenaran rujukan piawai
aGenerate boleh menyediakan draf baris contoh daripada schema, instructions dan jadual source pilihan. Minta variasi ungkapan soalan dan pengalih perhatian, kemudian semaknya berdasarkan petikan yang diluluskan sebelum memasukkannya ke dalam korpus. Bezakan calon yang dijana daripada kes yang dilabel secara manual. Skema jawapan yang dicipta model boleh mengulangi salah faham yang sama seperti sistem yang diuji.
Senarai semak penilaian platform merangkumi pemilihan dan pengujian pembina; panduan ini menilai tugas carian semula dan jawapan tertentu. Pilihan alat ejen memerlukan pemerhatian tersendiri, seperti yang dijelaskan dalam penilaian ejen AI. Jangan jadikan skor respons sebagai dakwaan tentang kebenaran, ketepatan alat atau kebolehpercayaan pelaksanaan produksi.
7. Uji pengendalian jawapan gantian selepas penilaian
Cleanlab Remediator menyediakan score, threshold, fallback_text dan show_untrustworthy_response. Gunakan ambang hanya selepas memahami output penilai yang dipilih dan menyemak kes berlabel. Input wajib score menerima number; sahkan keserasiannya dengan output berangka sebenar. Peraturan jawapan gantian tidak membaiki petikan yang hilang atau menjadikan jawapan salah sebagai betul.
Jangan gunakan rangka ujian yang dicadangkan ini sebagai gerbang pelepasan autonomi bagi keputusan sensitif. Semak ralat, liputan sumber dan perbezaan penilaian sebelum mengubah aliran yang dilihat pengguna. Simpan output terdahulu supaya jawapan gantian boleh diaudit tanpa mendedahkan jawapan yang tidak dipercayai kepada pengguna.
Bajet penilaian
Pelan: Go dari USD8/bulan dengan bil tahunan (USD10 bulanan), Plus dari USD16 (USD20 bulanan), Pro 100 dari USD80 (USD100 bulanan), Pro 200 dari USD160 (USD200 bulanan) dan Pro 500 dari USD400 (USD500 bulanan), dengan 5,000 hingga 250,000 Flowi Tokens sebulan dan pilihan tambah nilai; 1 token bagi setiap pelaksanaan nod; penggunaan API dan model pihak ketiga tidak termasuk.
Baris set data, pelaksanaan semula dan panggilan penilai menambah penggunaan secara berasingan daripada perbualan chatbot produksi. Anggarkan penggunaan berdasarkan laluan pelaksanaan yang diperhatikan dan bukannya bilangan kes sahaja.