Ke mana perginya milidetik: anggaran latensi untuk RAG
Pengguna tidak merasakan arsitektur Anda. Mereka merasakan sebuah angka, dan kebanyakan tim tidak bisa menjelaskan dari mana angka itu berasal.
Apa yang terjadi
Pengguna melaporkan asistennya lambat. Tim memprofil modelnya, menemukan generasi sebagai bottleneck, dan menghabiskan satu sprint mengoptimasinya. Latensi yang dirasakan hampir tidak berubah, karena masalah sebenarnya ada pada rantai sekuensial: retrieval menunggu query rewriting, reranking menunggu retrieval, dan tidak ada yang berjalan bersamaan.
Mengapa ini penting bagi tim deployment
Latensi adalah anggaran, dan seperti anggaran lain, syarat pertamanya adalah tahu ke mana perginya. Permintaan RAG pada umumnya punya lima tahap — pemahaman kueri, retrieval, reranking, packing, generasi — dan pada sistem yang sehat masing-masing sekitar 20 sampai 60 milidetik, 20 sampai 60, 40 sampai 150, bisa diabaikan, dan 300 sampai 900. Dua angka lebih penting dari totalnya: waktu ke token pertama, yang benar-benar dirasakan pengguna, dan p99, yang mereka ingat.
Apa yang harus dilakukan
Instrumentasi setiap tahap secara terpisah sebelum mengoptimasi apa pun; kebanyakan tim salah menebak tahap mana yang dominan. Lalu cari pekerjaan yang berjalan sekuensial padahal bisa overlap — query rewriting dan embedding bisa berjalan paralel dengan lookup metadata. Kurangi set kandidat yang dikirim ke reranker sebelum mengoptimasi reranker-nya sendiri. Cache secara agresif: retrieval dan reranking deterministik untuk versi korpus tertentu, dan pertanyaan support berulang jauh lebih sering daripada yang tim duga.
Kemenangan murah
Streaming. Waktu ke token pertama adalah keputusan produk sekaligus teknis, dan men-streaming jawaban parsial pada 400 milidetik terasa jauh lebih cepat daripada jawaban lengkap pada 1.400 milidetik. Ini biasanya perubahan performa persepsual dengan imbal hasil tertinggi, dan hanya butuh satu sore.