Dibangun di atasRetrieval-Augmented Generation EmbeddingChunking dan Reranking untuk RAGVector Search dan HNSWK-Means ClusteringKV Cache

Lensa ML

Membangun Sistem RAG

Q: Apa yang mendominasi latency RAG?

Generation. Pada desain bawaan, meng-embed pertanyaan, mencari di 200.000 vector, dan melakukan rerank pada 15 kandidat totalnya sekitar 7 ms. Prefill prompt 2.790 token butuh 125 ms, dan decode jawaban 150 token butuh 1,46 s. Jawaban yang lebih pendek, atau lebih sedikit jawaban yang di-decode bersamaan per GPU, jauh lebih mengubah total waktu daripada index yang lebih cepat.

Q: Berapa memori yang dibutuhkan vector index?

Kalikan jumlah chunk dengan dimensi embedding dan byte per nilai, lalu tambahkan overhead index-nya. 200.000 chunk berisi 768 nilai fp32 butuh 614 MB, dan IVF menambahkan id 8 byte per vector dan centroid-nya, di sini sekitar 1,8 MB. Menyimpan nilai int8 memangkas vector menjadi 154 MB, biasanya dengan sedikit penurunan akurasi.

Q: Apakah reranker sepadan dengan latency-nya?

Sering kali ya, karena biayanya kecil dibanding generation. Cross-encoder 110 juta parameter yang menilai 15 kandidat berisi 512 token butuh sekitar 6 ms pada GPU ilustratif. Dalam simulasi studi kasus ini, ia menaikkan recall@5 dari 0,69 menjadi 0,85, tetapi peningkatan itu adalah asumsi simulasi; ukur pada datamu sendiri sebelum mengandalkannya.

Langkah 1 dari 6: Dua Pipeline

Ingest offline dan jalur query online

End-to-end

1.59 s

Per query

$0.00028

Index

616 MB

Recall@5, data contoh

0.92

Desain untuk 50.000 dokumen · 20 query/s · di bawah 2,0 s dan $0,002 per query

Dokumen50,000

Token per dokumen1,500

Query per detik saat puncak20

Target latency end-to-end2.0 s

Target biaya per query$0.002

Token korpus

75M

Chunk untuk di-index

200K

GPU generation

Retrieval (embed, search, rerank) mengambil 6,8 ms dari 1,59 s. Menulis jawaban token demi token mengambil 92%, jadi latency sistem RAG sebagian besar berasal dari generation, topik studi kasus Merancang Serving LLM.

Asumsi

Efisiensi GPU terhadap roofline ideal100%

Generator	7B, fp16	Model dari Merancang Serving LLM: bentuk Llama 2 7B, jendela 4.096 token
GPU	80 GB · 2 TB/s · 300 TFLOP/s	Ilustrasi, akselerator yang sama dengan Merancang Serving LLM; meleset sebesar faktor efisiensi jika kernel sungguhan kurang dari itu
Pass encoder	2 × params FLOPs/token	Model embedding dan cross-encoder; satu query butuh max(komputasi, baca weight fp16)
Node pencarian	50 GB/s	Asumsi: CPU mengalirkan vector dari RAM. Kalau angka ini separuhnya, waktu pencarian jadi dua kali lipat
Overhead IVF	8 B id · fp32 centroids	Per vector dan per list; tanpa kompresi seperti product quantization
Data contoh	2,000 × 16-d, 12 clusters	Memakai seed; 50 query; k-means berjalan 8 iterasi
Model reranker	noise 0.05 → 0.015	Disimulasikan: noise skor tahap pertama dan cross-encoder pada data contoh
Harga	$2.00/GPU-jam	Tarif contoh yang sama dengan Merancang Serving LLM; atur di langkah terakhir
Headroom untuk lonjakan	1.3×	GPU cadangan untuk puncak traffic, seperti di Merancang Serving LLM
Tidak dimodelkan	antrean, jaringan, overhead DB	Latency mengasumsikan antrean kosong; biaya node pencarian tidak dihitung dalam biaya per query

Seret Dokumen di sepanjang rentangnya dan lihat kotak offline berubah, sementara batang online nyaris diam. Biaya ingest tumbuh seiring korpus, tetapi satu query hanya menyentuh sedikit chunk yang diambilnya, jadi latency query bergantung pada korpus hanya lewat pencarian. Batang latency dibangun dari langkah-langkah berikutnya: ubah pengaturan di sana dan batang ini ikut berubah. GPU generation adalah query per detik dikali GPU-detik per query dikali headroom lonjakan 1,3, dibulatkan ke atas.

Langkah 2 dari 6: Chunking

Ukuran chunk, overlap, dan apakah jawaban tetap utuh

End-to-end

1.59 s

Per query

$0.00028

Index

616 MB

Recall@5, data contoh

0.92

Desain untuk 50.000 dokumen · 20 query/s · di bawah 2,0 s dan $0,002 per query

Ukuran chunk c (token)512

Overlap o (token)64

Chunk per dokumen

Chunk N

200K

Penyimpanan

1.37×

Jawaban di chunk terbaik

100%

Chunk terbaik memuat seluruh jawaban, dan jawaban itu mengisi 23% chunk tersebut. Overlap 64 token mengulang 64 token di setiap batas, jadi korpus tersimpan 1,37 kali, dengan tiap chunk dihitung pada ukuran penuhnya c.

Asumsi

Efisiensi GPU terhadap roofline ideal100%

Generator	7B, fp16	Model dari Merancang Serving LLM: bentuk Llama 2 7B, jendela 4.096 token
GPU	80 GB · 2 TB/s · 300 TFLOP/s	Ilustrasi, akselerator yang sama dengan Merancang Serving LLM; meleset sebesar faktor efisiensi jika kernel sungguhan kurang dari itu
Pass encoder	2 × params FLOPs/token	Model embedding dan cross-encoder; satu query butuh max(komputasi, baca weight fp16)
Node pencarian	50 GB/s	Asumsi: CPU mengalirkan vector dari RAM. Kalau angka ini separuhnya, waktu pencarian jadi dua kali lipat
Overhead IVF	8 B id · fp32 centroids	Per vector dan per list; tanpa kompresi seperti product quantization
Data contoh	2,000 × 16-d, 12 clusters	Memakai seed; 50 query; k-means berjalan 8 iterasi
Model reranker	noise 0.05 → 0.015	Disimulasikan: noise skor tahap pertama dan cross-encoder pada data contoh
Harga	$2.00/GPU-jam	Tarif contoh yang sama dengan Merancang Serving LLM; atur di langkah terakhir
Headroom untuk lonjakan	1.3×	GPU cadangan untuk puncak traffic, seperti di Merancang Serving LLM
Tidak dimodelkan	antrean, jaringan, overhead DB	Latency mengasumsikan antrean kosong; biaya node pencarian tidak dihitung dalam biaya per query

Atur Overlap ke 0 dan seret Ukuran chunk dari 128 ke 1.024. Chunk dimulai setiap c − o token, jadi satu dokumen butuh ⌈(T − o) ÷ (c − o)⌉ chunk. Jawaban contoh membentang dari token 920 sampai 1.040, dan porsi tiap chunk adalah panjang irisannya dengan jawaban. Penyimpanan menghitung tiap chunk pada ukuran penuhnya c, jadi chunk terakhir yang lebih pendek sedikit terhitung berlebih. Splitter sungguhan juga memotong di batas kalimat dan judul, seperti dibahas di penjelasan chunking.

Langkah 3 dari 6: Embedding dan Ukuran Index

Vector di memori, waktu ingest, biaya re-index

End-to-end

1.59 s

Per query

$0.00028

Index

616 MB

Recall@5, data contoh

0.92

Desain untuk 50.000 dokumen · 20 query/s · di bawah 2,0 s dan $0,002 per query

Dimensi embedding d768

Presisi vector

Ukuran model embedding E (parameter)110M

Dokumen yang berubah per hari2.0%

Memori index

616 MB

Ingest penuh

1.3 min

Biaya ingest

$0.042

Re-index per hari

$0.00083

Meng-embed 102M token chunk dengan 2 × 110M FLOP per token butuh 1,3 min pada GPU ideal, sekitar $0,042. Biaya yang terus berjalan adalah index: 614 MB vector di RAM, yang bisa dipangkas int8 menjadi seperempat fp32.

Asumsi

Efisiensi GPU terhadap roofline ideal100%

Generator	7B, fp16	Model dari Merancang Serving LLM: bentuk Llama 2 7B, jendela 4.096 token
GPU	80 GB · 2 TB/s · 300 TFLOP/s	Ilustrasi, akselerator yang sama dengan Merancang Serving LLM; meleset sebesar faktor efisiensi jika kernel sungguhan kurang dari itu
Pass encoder	2 × params FLOPs/token	Model embedding dan cross-encoder; satu query butuh max(komputasi, baca weight fp16)
Node pencarian	50 GB/s	Asumsi: CPU mengalirkan vector dari RAM. Kalau angka ini separuhnya, waktu pencarian jadi dua kali lipat
Overhead IVF	8 B id · fp32 centroids	Per vector dan per list; tanpa kompresi seperti product quantization
Data contoh	2,000 × 16-d, 12 clusters	Memakai seed; 50 query; k-means berjalan 8 iterasi
Model reranker	noise 0.05 → 0.015	Disimulasikan: noise skor tahap pertama dan cross-encoder pada data contoh
Harga	$2.00/GPU-jam	Tarif contoh yang sama dengan Merancang Serving LLM; atur di langkah terakhir
Headroom untuk lonjakan	1.3×	GPU cadangan untuk puncak traffic, seperti di Merancang Serving LLM
Tidak dimodelkan	antrean, jaringan, overhead DB	Latency mengasumsikan antrean kosong; biaya node pencarian tidak dihitung dalam biaya per query

Ganti Presisi vector antara fp32, fp16, dan int8. Tiap vector butuh d × byte per nilai, dan IVF menambahkan id 8 byte per vector plus satu centroid fp32 per list. Ingest menghitung sekitar 2 FLOP per parameter per token, aturan yang sama dengan prefill di Merancang Serving LLM, pada puncak GPU dikali efisiensi di Asumsi. Biaya re-index harian mengasumsikan setiap dokumen yang berubah di-chunk dan di-embed ulang seluruhnya, seperti cara kebanyakan pipeline menangani suntingan.

Langkah 4 dari 6: Pencarian Eksak dan Aproksimasi

Index IVF yang dibangun dan diukur di browser

End-to-end

1.59 s

Per query

$0.00028

Index

616 MB

Recall@5, data contoh

0.92

Desain untuk 50.000 dokumen · 20 query/s · di bawah 2,0 s dan $0,002 per query

n_list (centroid k-means)64

n_probe (list yang dipindai per query)4

k (hasil yang dikembalikan)5

Recall@5, data contoh

0.92

Dipindai dari 2.000, data contoh

141

Jarak pada 200K

12.6K

Waktu pencarian

0.77 ms

Dengan 4 dari 64 list, index contoh menemukan 92% dari 5 tetangga teratas sebenarnya sambil memindai 141 dari 2.000 vector (rumus n_probe × N ÷ n_list memberi 125; query cenderung jatuh di list yang lebih padat). Pada 200K chunk, itu berarti 12,6K perhitungan jarak, bukan 200K, 0,77 ms, bukan 12 ms, dan pekerjaan 16 kali lebih sedikit.

Tidak dimodelkan: HNSW, graph index bawaan kebanyakan vector database, memakai lebih banyak memori demi perhitungan jarak yang lebih sedikit. Penjelasan vector search membangun satu index seperti ini.

Asumsi

Efisiensi GPU terhadap roofline ideal100%

Generator	7B, fp16	Model dari Merancang Serving LLM: bentuk Llama 2 7B, jendela 4.096 token
GPU	80 GB · 2 TB/s · 300 TFLOP/s	Ilustrasi, akselerator yang sama dengan Merancang Serving LLM; meleset sebesar faktor efisiensi jika kernel sungguhan kurang dari itu
Pass encoder	2 × params FLOPs/token	Model embedding dan cross-encoder; satu query butuh max(komputasi, baca weight fp16)
Node pencarian	50 GB/s	Asumsi: CPU mengalirkan vector dari RAM. Kalau angka ini separuhnya, waktu pencarian jadi dua kali lipat
Overhead IVF	8 B id · fp32 centroids	Per vector dan per list; tanpa kompresi seperti product quantization
Data contoh	2,000 × 16-d, 12 clusters	Memakai seed; 50 query; k-means berjalan 8 iterasi
Model reranker	noise 0.05 → 0.015	Disimulasikan: noise skor tahap pertama dan cross-encoder pada data contoh
Harga	$2.00/GPU-jam	Tarif contoh yang sama dengan Merancang Serving LLM; atur di langkah terakhir
Headroom untuk lonjakan	1.3×	GPU cadangan untuk puncak traffic, seperti di Merancang Serving LLM
Tidak dimodelkan	antrean, jaringan, overhead DB	Latency mengasumsikan antrean kosong; biaya node pencarian tidak dihitung dalam biaya per query

Atur n_list ke 256 dan n_probe ke 1, lalu naikkan n_probe. IVF mengelompokkan vector dengan k-means dan menyimpan tiap vector di list milik centroid terdekatnya. Query dibandingkan dengan semua centroid, lalu hanya memindai n_probe list terdekat. Recall@k adalah porsi k tetangga terdekat sebenarnya, yang ditemukan dengan membandingkan semua vector, yang berhasil dikembalikan index. Waktu pencarian mengasumsikan tiap perbandingan mengalirkan satu vector dari RAM pada 50 GB/s.

Langkah 5 dari 6: Top-k dan Reranking

Panjang konteks, cross-encoder, prefill, dan decode

End-to-end

1.59 s

Per query

$0.00028

Index

616 MB

Recall@5, data contoh

0.92

Desain untuk 50.000 dokumen · 20 query/s · di bawah 2,0 s dan $0,002 per query

Chunk top-k dalam prompt5

Reranker

Ukuran cross-encoder R (parameter)110M

Panjang jawaban (token)150

Jawaban yang di-decode bersamaan per GPU4

Token konteks

2,790

Rerank

6.0 ms

Prefill

125 ms

Decode

1.46 s

Cross-encoder membaca pertanyaan bersama tiap 15 kandidat, 6,0 ms waktu GPU. Dalam simulasi, ia menaikkan recall@5 dari 0,69 menjadi 0,85. Prefill 2.790 token butuh 125 ms; decode 150 token dengan 9,7 ms per token, 4 jawaban sekaligus, butuh 1,46 s.

Asumsi

Efisiensi GPU terhadap roofline ideal100%

Generator	7B, fp16	Model dari Merancang Serving LLM: bentuk Llama 2 7B, jendela 4.096 token
GPU	80 GB · 2 TB/s · 300 TFLOP/s	Ilustrasi, akselerator yang sama dengan Merancang Serving LLM; meleset sebesar faktor efisiensi jika kernel sungguhan kurang dari itu
Pass encoder	2 × params FLOPs/token	Model embedding dan cross-encoder; satu query butuh max(komputasi, baca weight fp16)
Node pencarian	50 GB/s	Asumsi: CPU mengalirkan vector dari RAM. Kalau angka ini separuhnya, waktu pencarian jadi dua kali lipat
Overhead IVF	8 B id · fp32 centroids	Per vector dan per list; tanpa kompresi seperti product quantization
Data contoh	2,000 × 16-d, 12 clusters	Memakai seed; 50 query; k-means berjalan 8 iterasi
Model reranker	noise 0.05 → 0.015	Disimulasikan: noise skor tahap pertama dan cross-encoder pada data contoh
Harga	$2.00/GPU-jam	Tarif contoh yang sama dengan Merancang Serving LLM; atur di langkah terakhir
Headroom untuk lonjakan	1.3×	GPU cadangan untuk puncak traffic, seperti di Merancang Serving LLM
Tidak dimodelkan	antrean, jaringan, overhead DB	Latency mengasumsikan antrean kosong; biaya node pencarian tidak dihitung dalam biaya per query

Naikkan Top-k sampai batang prompt melewati garis 4.096 token. Cross-encoder membaca pertanyaan dan satu chunk bersamaan lalu mengeluarkan skor relevansi, jadi biayanya satu forward pass penuh per kandidat, di sini 3k kandidat. Simulasi menambahkan noise acak ke tiap jarak contoh: lebih besar untuk skor tahap pertama, lebih kecil untuk skor cross-encoder. Jawaban yang di-decode bersamaan per GPU adalah batch decode: tiap jawaban tambahan ikut berbagi pembacaan weight, tetapi menambah pembacaan cache-nya sendiri.

Langkah 6 dari 6: Tinjauan Desain

Desain dibandingkan dengan kebutuhan, dan apa yang bisa salah

End-to-end

1.59 s

Per query

$0.00028

Index

616 MB

Recall@5, data contoh

0.92

Desain untuk 50.000 dokumen · 20 query/s · di bawah 2,0 s dan $0,002 per query

✓End-to-end ≤ 2.0 s1.59 s

✓Biaya per query ≤ $0.002$0.00028

✓Prompt muat di jendela ≤ 4,0962,940 token

·Memori index 200K × 768 fp32616 MB

·Re-index per hari 2.0% dokumen$0.00083

·GPU generation 20 query/s × 1.313

Berisiko · Re-index setiap

Index usang: sampai 1.000 dokumen yang berubah (2,0%) dijawab dari vector lama sebelum proses berikutnya.

Aman · Ukuran chunk dan overlap

Jawaban tetap utuh: satu chunk memuat seluruh jawaban contoh, yang mengisi 23% chunk itu.

Aman · Top-k

Konteks masih aman: 5 chunk menjadi 2.790 token, di dalam jendela 4.096 token dan di bawah 10 chunk.

Re-index setiap (jam)24

Harga GPU ($ per jam)$2.00

GPU-detik per query

0.497

Per 1.000 query

$0.276

Dokumen usang, kasus terburuk

1,000

Kedua target terpenuhi: 1,59 s end-to-end dan $0,00028 per query, hampir semuanya untuk generation. Index memakai 616 MB RAM dan $0,00083 per hari agar tetap segar, jadi kesegarannya dibatasi oleh seberapa sering re-index berjalan, bukan oleh harganya.

Asumsi

Efisiensi GPU terhadap roofline ideal100%

Generator	7B, fp16	Model dari Merancang Serving LLM: bentuk Llama 2 7B, jendela 4.096 token
GPU	80 GB · 2 TB/s · 300 TFLOP/s	Ilustrasi, akselerator yang sama dengan Merancang Serving LLM; meleset sebesar faktor efisiensi jika kernel sungguhan kurang dari itu
Pass encoder	2 × params FLOPs/token	Model embedding dan cross-encoder; satu query butuh max(komputasi, baca weight fp16)
Node pencarian	50 GB/s	Asumsi: CPU mengalirkan vector dari RAM. Kalau angka ini separuhnya, waktu pencarian jadi dua kali lipat
Overhead IVF	8 B id · fp32 centroids	Per vector dan per list; tanpa kompresi seperti product quantization
Data contoh	2,000 × 16-d, 12 clusters	Memakai seed; 50 query; k-means berjalan 8 iterasi
Model reranker	noise 0.05 → 0.015	Disimulasikan: noise skor tahap pertama dan cross-encoder pada data contoh
Harga	$2.00/GPU-jam	Tarif contoh yang sama dengan Merancang Serving LLM; atur di langkah terakhir
Headroom untuk lonjakan	1.3×	GPU cadangan untuk puncak traffic, seperti di Merancang Serving LLM
Tidak dimodelkan	antrean, jaringan, overhead DB	Latency mengasumsikan antrean kosong; biaya node pencarian tidak dihitung dalam biaya per query

Turunkan Re-index setiap sampai catatan index usang hilang. GPU-detik per query adalah embedding query + rerank + prefill + token jawaban × langkah decode ÷ batch decode, karena tiap langkah decode melayani seluruh batch sekaligus. Biaya per query adalah angka itu dikali harga GPU per detik. Node pencarian berjalan di CPU, dan biayanya tidak dihitung. Tiap catatan menyebut slider yang mengendalikannya, jadi kamu bisa menukar satu kegagalan dengan kegagalan lain.

Bagaimana cara menentukan ukuran sistem RAG?

Retrieval-augmented generation (RAG) menjawab pertanyaan dengan mencari bagian teks yang relevan di kumpulan dokumen, lalu memberikannya ke model bahasa sebagai bagian dari prompt. Sistem RAG terdiri dari dua pipeline. Pipeline offline memecah dokumen menjadi chunk, mengubah tiap chunk menjadi embedding vector, dan menyimpan vector itu di index. Pipeline online meng-embed tiap pertanyaan, mencari di index, bisa juga melakukan rerank pada hasilnya, lalu menghasilkan jawaban.

Studi kasus ini menentukan ukuran kedua pipeline untuk 50.000 dokumen berisi sekitar 1.500 token dan 20 query per detik, dengan anggaran 2 detik dan target biaya $0,002 per query. Generation memakai model 7B, GPU ilustratif 80 GB, serta model prefill dan decode yang sama dengan studi kasus Merancang Serving LLM, jadi keduanya konsisten. Langkah pencarian menjalankan index inverted file (IVF) sungguhan atas 2.000 vector di browser dan mengukur recall-nya.

Ide utama

Sistem RAG terdiri dari pipeline ingest offline (chunk, embed, index) dan pipeline query online (embed, search, rerank, prefill, decode).
Ukuran chunk menukar presisi dengan kelengkapan: chunk kecil bisa membelah jawaban, chunk besar menjaganya utuh tetapi menenggelamkannya di antara teks lain.
Memori index adalah chunk × dimensi × byte per nilai, jadi vector int8 hanya butuh seperempat memori fp32.
Index IVF membandingkan query dengan n_list centroid dan n_probe list, bukan dengan semua vector, dengan bayaran sebagian recall yang harus diukur.
Setiap chunk yang diambil memperpanjang prompt, sehingga menambah waktu prefill dan bisa melebihi context window model.
Dengan generator 7B, menulis jawaban mengambil sebagian besar latency dan biaya, sedangkan retrieval hanya beberapa milidetik.

Pertanyaan umum

Apa yang mendominasi latency RAG?

Generation. Pada desain bawaan, meng-embed pertanyaan, mencari di 200.000 vector, dan melakukan rerank pada 15 kandidat totalnya sekitar 7 ms. Prefill prompt 2.790 token butuh 125 ms, dan decode jawaban 150 token butuh 1,46 s. Jawaban yang lebih pendek, atau lebih sedikit jawaban yang di-decode bersamaan per GPU, jauh lebih mengubah total waktu daripada index yang lebih cepat.

Berapa memori yang dibutuhkan vector index?

Kalikan jumlah chunk dengan dimensi embedding dan byte per nilai, lalu tambahkan overhead index-nya. 200.000 chunk berisi 768 nilai fp32 butuh 614 MB, dan IVF menambahkan id 8 byte per vector dan centroid-nya, di sini sekitar 1,8 MB. Menyimpan nilai int8 memangkas vector menjadi 154 MB, biasanya dengan sedikit penurunan akurasi.

Berapa ukuran chunk yang baik untuk RAG?

Cukup besar untuk memuat jawaban biasa secara utuh, dengan sedikit overlap agar jawaban di dekat batas tidak terpotong, dan cukup kecil agar jawaban mengisi porsi besar dari chunk. Beberapa ratus token adalah titik awal yang umum. Ukur recall dengan pertanyaan berlabel dari dokumenmu sendiri, karena ukuran terbaik bergantung pada cara dokumen itu ditulis.

Apakah reranker sepadan dengan latency-nya?

Sering kali ya, karena biayanya kecil dibanding generation. Cross-encoder 110 juta parameter yang menilai 15 kandidat berisi 512 token butuh sekitar 6 ms pada GPU ilustratif. Dalam simulasi studi kasus ini, ia menaikkan recall@5 dari 0,69 menjadi 0,85, tetapi peningkatan itu adalah asumsi simulasi; ukur pada datamu sendiri sebelum mengandalkannya.

Penjelasan terkait

Retrieval-Augmented Generation · Mendasarkan output model bahasa pada dokumen yang diambil untuk mengurangi halusinasi
Embedding · Mengubah kata dan kategori menjadi vector
Chunking dan Reranking untuk RAG · Memecah dokumen dan mengurutkan ulang hasil retrieval RAG
Vector Search dan HNSW · Mencari embedding terdekat dengan cepat memakai HNSW
K-Means Clustering · Pengelompokan unsupervised berdasarkan jarak ke centroid
KV Cache · Kenapa LLM menyimpan key dan value di cache, dan berapa biayanya

Referensi

Terakhir diperbarui 2 November 2026