Saluran paip RAG anda melepasi ujian beban standard dengan cemerlang. Latensi p95 kelihatan sihat. Kadar ralat hampir sifar. Namun, pengguna melaporkan jawapan yang mengelak soalan, memetik dokumen yang tidak wujud, atau mengeluarkan perenggan yang tidak relevan daripada kertas putih yang dimuat naik enam bulan lalu. Papan pemuka menyatakan semuanya baik-baik saja. Pengalaman pengguna pula menyatakan ia rosak.
Ketidakselarasan itu wujud kerana ujian prestasi konvensional dibina untuk sistem permintaan-respons (request-response), bukan untuk sistem yang berfikir. Apabila anda menghantar seribu permintaan selari ke titik akhir (endpoint) REST, anda mengetahui sama ada pelayan anda kekal stabil. Anda tidak belajar apa-apa tentang sama ada lapisan capaian (retrieval layer) anda mengambil cebisan (chunks) yang betul, sama ada templat arahan (prompt template) anda mengekalkan konteks, atau sama ada model tersebut mereka-reka sumber apabila stor vektor kosong. Ujian beban standard mengukur kelajuan. Aplikasi RAG menuntut anda mengukur pemahaman.
Melangkaui Kod Status 200
Ujian beban API tipikal menyemak tiga perkara: ketersediaan, latensi, dan daya pemprosesan (throughput). Ia bertanya sama ada pelayan menjawab, berapa lama masa yang diambil, dan berapa ramai pengguna serentak yang dapat ditampung. Bagi aplikasi RAG, angka-angka tersebut adalah prasyarat, bukan kesimpulan. Jawapan salah yang pantas tetap merupakan jawapan yang salah, dan jawapan salah pada skala besar menelan kos yang lebih tinggi berbanding jawapan yang lambat.
RAG menambah dua fasa berbeza pada setiap permintaan. Pertama, sistem menukarkan soalan pengguna kepada embedding, membuat pertanyaan pada stor vektor, dan menarik balik satu set cebisan konteks. Kedua, ia memasukkan cebisan tersebut ke dalam prompt, menghantar semuanya ke model bahasa, dan menghantar semula pelengkapan (completion) secara penstriman. Ujian tradisional sering menggabungkan ini ke dalam satu metrik "masa respons" tunggal. Ia menganggap enjin capaian dan penjana sebagai satu kotak hitam (black box).
Anda perlu membuka kotak tersebut. Jika pangkalan data vektor anda menjadi perlahan di bawah beban, latensi capaian akan meningkat. LLM mungkin masih bertindak balas dengan cepat, tetapi ia bertindak balas berdasarkan konteks sampah yang diambil secara terburu-buru. Sebaliknya, carian vektor kekal pantas manakala barisan (queue) LLM tersumbat, meningkatkan masa-ke-token-pertama (time-to-first-token) sehingga pengguna hanya merenung kursor yang berkelip. Satu pemasa hujung-ke-hujung (end-to-end) menyembunyikan kedua-dua kegagalan tersebut.
Uji Capaian, Bukan Sekadar Pangkalan Data
Kebanyakan pasukan menjalankan penanda aras carian vektor yang pantas dan menganggap lapisan capaian telah diuji. Penanda aras tersebut biasanya mengukur betapa cepat pangkalan data mengembalikan jiran terdekat (nearest neighbors) untuk pertanyaan yang dipilih secara manual. Ia jarang mengukur sama ada jiran-jiran tersebut benar-benar mengandungi jawapan.
Kualiti capaian berubah mengikut beban dalam cara yang halus. Di bawah tekanan serentak, indeks jiran terdekat anggaran (approximate nearest neighbor indexes) boleh berkelakuan berbeza berbanding semasa ia berfungsi secara terasing. Strategi pembahagian (chunking) yang kelihatan sempurna dalam notebook mula membocorkan konteks merentasi sempadan apabila sepuluh ribu dokumen bersaing untuk ruang embedding yang sama. Satu pertanyaan yang mengembalikan perenggan ideal dalam persekitaran yang tenang mungkin memaparkan slaid pemasaran yang mengelirukan apabila indeks sedang dibina semula atau apabila penapisan metadata dibuang di bawah tekanan permintaan.
Untuk menguji ini dengan betul, anda memerlukan set data kebenaran asas (ground-truth dataset). Kurasi soalan di mana anda sudah tahu dokumen sumber mana yang sepatutnya muncul. Jalankan soalan-soalan tersebut pada tahap keserentakan yang berbeza dan semak sama ada cebisan yang dijangkakan berada dalam keputusan top-k. Jejaki kadar padanan (hit rate), bukan sekadar tempoh pertanyaan. Jika lima cebisan teratas anda terlepas sumber kritikal sepenuhnya, saluran paip capaian anda telah gagal sebelum LLM sempat berfungsi.
Anda juga harus melakukan ujian tekanan (stress-test) pada bahagian pinggir. Hantar pertanyaan yang tidak mempunyai jawapan dalam korpus. Hantar soalan yang kabur yang boleh dipetakan kepada pelbagai domain. Hantar soalan panjang yang melebihi had token model embedding anda dan dipotong secara senyap. Perhatikan apa yang diberikan semula oleh lapisan capaian. Dalam setiap kes, mod kegagalan adalah lebih penting daripada milisaat yang berlalu.
Apabila Model Tersedak Secara Senyap
Sebaik sahaja cebisan tersebut sampai ke LLM, ujian beban standard terus menipu