Latency RAG dalam 1 gambar

Retrieval-augmented generation (RAG) menjawab pertanyaan dengan mencari di kumpulan dokumen lebih dulu, lalu memberikan bagian terbaik ke model bahasa. Sebagian besar upaya membangun RAG tercurah ke pencarian. Kalau digambar sesuai skala, pencarian itu nyaris tak terlihat.

1. 1
   Batang ini adalah satu query melalui rancangan bawaan studi kasus Membangun Sistem RAG: 50.000 dokumen dipotong menjadi 200.000 chunk berisi 512 token, model 7B yang menulis jawaban 150 token, dan GPU ilustratif 80 GB. Lima tahap berjalan berurutan. Embed mengubah pertanyaan menjadi vector. Search mencari vector chunk terdekat dalam indeks inverted file (IVF). Rerank menilai 15 kandidat dengan cross-encoder, model yang membaca pertanyaan dan chunk bersama-sama. Prefill membaca prompt, dan decode menulis jawaban satu token demi satu token.
2. 2
   Batang atas adalah keseluruhan query, 1,59 s. Prefill membaca prompt 2.790 token berisi lima chunk, pertanyaan, dan system prompt dalam satu lintasan: 125 ms. Decode memakan 1,46 s, sekitar 92% dari total, karena setiap dari 150 token jawaban memerlukan lintasannya sendiri yang membaca ulang 13,5 GB weight model. Di sini empat jawaban berbagi tiap lintasan, jadi tiap token memakan 9,7 ms.
3. 3
   Batang bawah memperbesar 10 ms pertama. Embedding pertanyaan memakan 0,11 ms. Pencarian memakan 0,77 ms, karena IVF membandingkan query dengan 12.564 vector, bukan semua 200.000. Rerank adalah tahap retrieval paling lambat, 5,96 ms, dan ketiganya bersama-sama memakan 6,8 ms. Indeks yang lebih cepat nyaris tidak mengubah waktu tunggu pengguna.