Saya dahulunya menganggap pipeline RAG saya seperti sebuah kotak hitam. Embedding dimasukkan, jawapan keluar, dan di suatu tempat di antaranya, bil awan saya semakin meningkat. Seperti kebanyakan pembangun yang saya temui, saya menganggap model vektor padat adalah punca masalahnya. Ia kedengaran mahal. Menukar seribu halaman kepada nombor apungan dimensi tinggi terasa seperti proses pembuatan berat, jadi saya menanganinya dengan penuh berhati-hati. Saya juga membina lapisan caching khusus untuk mengelakkan proses embedding semula data yang telah saya proses. Saya bangga dengan pengoptimuman tersebut. Kemudian saya membuka invois dan membuat pengiraan.
Saya mengoptimumkan perkara yang salah sepenuhnya.
Perangkap Embedding
Inilah angka yang memusnahkan andaian saya: melakukan embedding pada dokumen 1,000 halaman menelan kos kira-kira lapan belas sen. Itu bukan kesilapan taip. Dengan harga kurang daripada secawan kopi di kebanyakan bandar, anda boleh melakukan vektorisasi pada keseluruhan buku. Lebih penting lagi, kos itu hanya dikenakan sekali, semasa proses ingestion. Selepas fasa awal, vektor-vektor tersebut tersimpan dalam storan dan menunggu. Ia tidak mengumpul yuran bermeter setiap kali pengguna membuka aplikasi anda. Ia adalah perbelanjaan modal, bukan kebocoran berulang.
Namun, mitos ini tetap berterusan. Sebahagian daripada kekeliruan ini adalah bersifat struktural. Pipeline ingestion adalah tempat di mana jurutera menghabiskan tenaga awal mereka. Anda menulis chunker, anda bergelut dengan tokenizer, anda memerhatikan bar kemajuan bergerak perlahan di terminal anda. Usaha yang nyata itu mewujudkan ilusi perkadaran. Ia terasa seperti bahagian yang mahal kerana ia adalah bahagian yang intensif buruh. Tetapi buruh dan kos tidak sama, dan dalam RAG, ia sering kali berkaitan secara songsang.
Tiga Bil yang Sangat Berbeza
Sebaik sahaja saya mengasingkan kos mengikut peringkat dan bukannya menggabungkannya, gambaran sebenar menjadi jelas. Sebuah sistem RAG berjalan atas tiga model ekonomi yang berbeza, dan memahami perbezaannya adalah penting jika anda ingin mengekalkan bajet anda.
Embedding adalah kos pembuatan sekali sahaja. Anda membayar untuk menukar dokumen kepada vektor, dan kemudian tugas anda selesai. Jika dokumen anda adalah statik, item ini hampir tidak muncul dalam bil bulanan anda.
Pangkalan data vektor adalah sewaan infrastruktur. Anda membayar untuk memastikan sistem sentiasa aktif sepanjang masa. Anda membayar untuk SSD yang menyimpan berjuta-juta chunk, untuk teras CPU yang menyelenggara indeks, dan untuk rangkaian yang memberikan carian bawah 100 milisaat. Kos ini adalah nyata, dan ia berkembang mengikut volum data, tetapi ia secara amnya boleh diramal. Ia berfungsi seperti keahlian gim. Sama ada anda membuat pertanyaan sekali atau sepuluh ribu kali, kos infrastruktur asas kekal lebih kurang sama.
Model bahasa besar (LLM) adalah cukai penggunaan. Setiap satu soalan pengguna mencetuskan bil. Setiap token yang keluar dari lapisan retrieval anda dan masuk ke dalam prompt menelan kos. Setiap langkah penaakulan, setiap arahan format, setiap sitasi yang anda minta model jana menambah beban mikroskopik. Tetapi caj mikro tersebut berlipat ganda mengikut jumlah sesi, dan jumlah sesi cenderung meningkat. Di sinilah latensi bertambah buruk bersama perbelanjaan. Pertanyaan yang lambat bukan sahaja menjengkelkan pengguna; ia secara aktif membakar wang semasa pengguna menunggu.
Ini bukanlah variasi kepada masalah yang sama. Ia adalah tiga masalah yang berbeza. Anda tidak boleh menyelesaikan masalah perbelanjaan waktu pertanyaan dengan menjadikan proses ingestion lebih murah. Itu ibarat menala enjin kereta anda untuk menjimatkan wang tempat letak kereta.
Ke Mana Sebenarnya Wang Itu Pergi
Jika anda menjalankan aplikasi RAG pengeluaran, buka cost explorer anda dan tapis mengikut jenis penggunaan. Saya berani bertaruh bahawa tugasan embedding anda adalah garisan rata sekali sehari, manakala endpoint LLM anda kelihatan seperti denyutan jantung yang melonjak mengikut trafik. Corak itu menceritakan segalanya. Vektor anda tidur; model anda terjaga setiap kali pengguna mempunyai soalan.
Kesedaran ini mengubah cara saya mengutamakan kerja kejuruteraan. Saya berhenti bertanya bagaimana untuk menjadikan ingestion lebih murah dan mula bertanya bagaimana untuk menjadikan setiap pertanyaan lebih murah. Peralihan itu kedengaran jelas, tetapi kebanyakan pasukan masih beroperasi berdasarkan gerak hati. Mereka membina logik deduplikasi yang rumit untuk peringkat embedding dan kemudian menyuap tetingkap konteks yang kembung dan tidak fokus kepada LLM tanpa berfikir panjang. Mereka menggilap lantai sedangkan bumbung bocor.
Cara Mengurangkan Kos Tanpa Merosakkan Pipeline Anda
Menjimatkan wang dalam sistem RAG memerlukan penyelarasan taktik dengan model kos. Berikut adalah apa yang benar-benar berkesan.
Lakukan Deduplikasi Sebelum Anda Memproses
Kebanyakan pangkalan pengetahuan organisasi bergerak dengan perlahan. Polisi, buku panduan, PDF penyelidikan, dan laporan arkib dibiarkan tanpa disentuh selama berbulan-bulan. Dalam banyak saluran paip (pipeline), kira-kira lapan puluh peratus dokumen sumber kekal identikal antara larian pengambilan data. Walaupun begitu, banyak sistem membuang keseluruhan korpus dan membina semula indeks dari awal mengikut jadual. Jangan lakukan itu. Bina satu pintu gerbang pada pintu masuk saluran paip anda. Lakukan hash pada fail yang masuk. Bandingkan cap masa pengubahsuaian terakhir. Jika dokumen tidak berubah, langkau ia sepenuhnya. Memproses semula fail statik adalah pembaziran semata-mata. Ia memakan kos pengkomputeran, menghauskan SSD tanpa keperluan, dan menyebabkan log pengambilan anda membengkak dengan aktiviti palsu.
Secara praktikal, simpan satu manifes ringan yang memetakan laluan fail kepada checksum. Apabila penjadual (scheduler) diaktifkan, biarkan ia menyemak manifes terlebih dahulu. Hanya sebilangan kecil fail yang berubah sahaja yang sepatutnya melalui proses chunker.
Tampal Dokumen, Jangan Gantikannya
Apabila sesuatu dokumen berubah, tahan naluri untuk melayannya sebagai fail yang benar-benar baharu. Sebuah spesifikasi teknikal setebal lima puluh muka surat mungkin hanya menerima semakan dua perenggan dalam seksyen keempat. Jika saluran paip anda menggantikan keseluruhan fail, anda akan melakukan re-chunk dan re-embed pada empat puluh sembilan muka surat yang masih elok tanpa sebab.
Sebaliknya, bandingkan versi baharu dengan versi lama. Kenal pasti perbezaannya (delta). Kemudian, lakukan re-chunk dan re-embed hanya pada bahagian yang berubah. Gunakan metadata seperti nombor halaman, ID seksyen, sauh pengepala (header anchors), atau julat perenggan untuk menjejaki sempadan. Jika strategi chunking anda menghormati struktur dokumen, ini adalah mudah. Jika tidak, membaiki chunker anda adalah pelaburan yang lebih baik daripada membeli kluster inferens yang lebih besar. Kos kejuruteraan untuk menyelenggara saluran paip yang peka terhadap perbezaan (diff-aware) akan membiayai dirinya sendiri dalam masa beberapa minggu sebaik sahaja jumlah dokumen anda meningkat.
Tangani Kos Berulang Secara Terus
Memandangkan panggilan LLM dijalankan pada setiap pertanyaan, menjimatkan walaupun beberapa token atau menyimpan segelintir respons dalam cache akan memberikan pulangan yang besar. Mulakan dengan prompt caching. Jika seorang pengguna bertanya tentang polisi pemulangan wang anda dan pengguna lain bertanya perkara yang sama sepuluh minit kemudian, tidak ada sebab untuk memanggil model tersebut dua kali. Simpan pasangan pertanyaan-respons yang terkini dengan padanan keserupaan semantik. Apabila soalan baharu jatuh dalam ambang keserupaan dengan soalan yang telah disimpan, kembalikan jawapan yang disimpan secara terus. Tiada token dijana, tiada dolar dibelanjakan.
Seterusnya, teliti kualiti capaian (retrieval) anda. Retriever yang cuai memaksa LLM membaca timbunan jerami untuk mencari sebilah jarum. Jika anda memenuhkan prompt dengan dua puluh chunk yang tidak relevan kerana had top-k anda terlalu longgar, anda sebenarnya membayar model tersebut untuk membaca hingar (noise). Ketatkan capaian anda. Kecilkan top-k anda. Mampatkan chunk sebelum menghantarnya. Buang bahagian boilerplate seperti pengepala dan kaki dokumen semasa pengambilan supaya ia tidak sampai ke prompt. Setiap token yang anda buang daripada tetingkap konteks (context window) adalah penjimatan pecahan sen, dan pecahan tersebut akan terkumpul merentasi beribu-ribu pertanyaan harian.
Capaian yang lebih baik juga meningkatkan kependaman (latency), yang merupakan satu lagi bentuk kos. Pengguna akan meninggalkan antara muka yang perlahan. Jawapan yang lebih pantas adalah lebih murah untuk dihasilkan dan lebih baik untuk pengekalan pengguna.
Intipati Sebenar
Berhenti mengoptimumkan apa yang terasa mahal dan mula mengoptimumkan apa yang dinyatakan mahal dalam invois anda. Ukur setiap peringkat secara bebas. Anda berkemungkinan besar akan mendapati bahawa embeddings adalah bahagian yang murah, storan vektor adalah bahagian yang stabil, dan inferens LLM adalah bahagian yang menyebabkan kerugian besar. Fokuskan tenaga anda pada kecekapan waktu pertanyaan, kemas kini berperingkat, dan penyahduplikasian secara tepat (surgical deduplication). Bina untuk soalan pengguna yang ke-seribu, bukan untuk muat naik dokumen yang ke-lima puluh. Kekangan (bottleneck) jarang berlaku di tempat yang anda sangkakan.
Sumber: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Sertai perbincangan dalam GyaanSetu AI learning community.