I used to treat my RAG pipeline like a black box. Embeddings went in, answers came out, and somewhere in between my cloud bill grew. Like most developers I spoke with, I assumed the dense vector models were the villains. They sounded expensive. Converting a thousand pages into high-dimensional floats felt like heavy manufacturing, so I treated it with corresponding caution. I even built a caching layer specifically to avoid re-embedding data I had already processed. I was proud of that optimization. Then I opened the invoice and did the math.
I was optimizing the wrong thing entirely.
The Embedding Trap
Here is the number that broke my assumptions: embedding a 1,000-page document costs roughly eighteen cents. That is not a typo. For less than the price of a cup of coffee in most cities, you can vectorize an entire book. More importantly, that cost hits once, at ingestion. After the initial pass, those vectors sit in storage and wait. They do not rack up metered fees every time a user opens your application. They are a capital expense, not a recurring drain.
Yet the myth persists. Part of the confusion is structural. The ingestion pipeline is where engineers spend their early energy. You write the chunker, you fight with the tokenizer, you watch progress bars crawl across your terminal. That visible effort creates an illusion of proportion. It feels like the expensive part because it is the labor-intensive part. But labor and cost are not the same, and in RAG they are often inversely related.
Three Very Different Bills
Once I separated costs by stage instead of lumping them together, the picture cleared up. A RAG system runs on three distinct economic models, and understanding the difference is essential if you want to keep your budget sane.
Embeddings are a one-time manufacturing cost. You pay to transform documents into vectors, and then you are done. If your documents are static, this line item barely appears in your monthly bill.
Vector databases are infrastructure rent. You pay to keep the system alive around the clock. You pay for the SSDs holding millions of chunks, for the CPU cores maintaining indexes, and for the network that delivers sub-100-millisecond searches. This cost is real, and it scales with data volume, but it is generally predictable. It behaves like a gym membership. Whether you query once or ten thousand times, the base infrastructure cost stays roughly the same.
Large language models are consumption taxes. Every single user question triggers a bill. Every token that leaves your retrieval layer and enters the prompt costs money. Every reasoning step, every formatting instruction, every citation you ask the model to generate adds microscopic weight. But those microcharges multiply by session count, and session counts trend upward. This is where latency compounds with spending. A slow query is not just annoying for the user; it is actively burning cash while the user waits.
These are not variations of the same problem. They are three separate problems. You cannot solve a query-time spending problem by making ingestion cheaper. That is like tuning your car's engine to save money on parking.
Where the Money Actually Goes
If you are running a production RAG application, pull up your cost explorer and filter by usage type. I am willing to bet that your embedding job is a flat line once per day, while your LLM endpoint looks like a heartbeat that spikes with traffic. That pattern tells the whole story. Your vectors sleep; your model wakes up every time a user has a question.
The realization changed how I prioritize engineering work. I stopped asking how to make ingestion cheaper and started asking how to make each question cheaper. That shift sounds obvious, but most teams still operate on hunches. They build elaborate deduplication logic for the embedding stage and then feed bloated, unfocused context windows to the LLM without a second thought. They are polishing the floor while the roof leaks.
How to Cut Costs Without Breaking Your Pipeline
Saving money in a RAG system requires matching the tactic to the cost model. Here is what actually works.
Deduplicate Before You Process
Hầu hết các cơ sở tri thức của tổ chức đều vận hành chậm chạp. Các chính sách, sổ tay, tệp PDF nghiên cứu và các báo cáo lưu trữ thường nằm yên không được chạm tới trong nhiều tháng. Trong nhiều quy trình (pipeline), khoảng 80% tài liệu nguồn vẫn giữ nguyên giữa các lần nạp dữ liệu (ingestion). Mặc dù vậy, rất nhiều hệ thống lại xóa toàn bộ kho dữ liệu và xây dựng lại chỉ mục từ đầu theo định kỳ. Đừng làm như vậy. Hãy xây dựng một "cổng kiểm soát" tại điểm đầu vào của pipeline. Băm (hash) các tệp tin đến. So sánh dấu thời gian sửa đổi lần cuối (last-modified timestamps). Nếu một tài liệu không thay đổi, hãy bỏ qua nó hoàn toàn. Việc xử lý lại các tệp tĩnh là một sự lãng phí thuần túy. Nó tiêu tốn tài nguyên tính toán, làm mòn ổ SSD một cách không cần thiết và khiến nhật ký nạp dữ liệu (ingestion logs) bị phình to bởi các hoạt động ảo.
Trong thực tế, hãy lưu trữ một bản kê khai (manifest) nhẹ nhàng để ánh xạ đường dẫn tệp với các mã kiểm tra (checksums). Khi bộ lập lịch (scheduler) khởi chạy, hãy để nó kiểm tra bản kê khai trước. Chỉ những tệp thay đổi (chiếm thiểu số) mới nên được đưa qua bộ chia nhỏ (chunker).
Vá tài liệu, đừng thay thế chúng
Khi một tài liệu thay đổi, hãy cưỡng lại bản năng coi nó như một tệp hoàn toàn mới. Một bản đặc tả kỹ thuật dài 50 trang có thể chỉ cần chỉnh sửa hai đoạn văn ở phần bốn. Nếu pipeline của bạn thay thế toàn bộ tệp, bạn sẽ phải chia nhỏ (re-chunk) và nhúng lại (re-embed) 49 trang vẫn còn hoàn hảo một cách vô ích.
Thay vào đó, hãy so sánh phiên bản mới với phiên bản cũ. Xác định phần chênh lệch (delta). Sau đó, chỉ chia nhỏ và nhúng lại những phần đã thay đổi. Sử dụng siêu dữ liệu (metadata) như số trang, ID phần, mỏ neo tiêu đề (header anchors) hoặc phạm vi đoạn văn để theo dõi các ranh giới. Nếu chiến lược chia nhỏ (chunking) của bạn tôn trọng cấu trúc tài liệu, việc này sẽ rất đơn giản. Nếu không, việc sửa lại bộ chia nhỏ (chunker) là một khoản đầu tư tốt hơn so với việc mua một cụm suy luận (inference cluster) lớn hơn. Chi phí kỹ thuật để duy trì một pipeline có khả năng nhận biết sự khác biệt (diff-aware) sẽ được bù đắp chỉ trong vài tuần khi số lượng tài liệu của bạn tăng lên.
Đối đầu trực diện với các chi phí định kỳ
Vì các lệnh gọi LLM chạy trên mỗi truy vấn, việc cắt giảm dù chỉ vài token hoặc lưu bộ nhớ đệm (cache) cho một vài phản hồi cũng mang lại lợi nhuận cực lớn. Hãy bắt đầu với prompt caching. Nếu một người dùng hỏi về chính sách hoàn tiền và một người khác hỏi cùng một câu đó mười phút sau, không có lý do gì phải gọi mô hình hai lần. Hãy lưu trữ các cặp truy vấn-phản hồi gần đây bằng cách khớp độ tương đồng ngữ nghĩa (semantic similarity matching). Khi một câu hỏi mới nằm trong ngưỡng tương đồng với một câu đã được lưu trong cache, hãy trả về câu trả lời đã lưu trực tiếp. Không tốn token, không tốn tiền.
Tiếp theo, hãy xem xét kỹ chất lượng truy xuất (retrieval). Một bộ truy xuất cẩu thả sẽ buộc LLM phải "mò kim đáy bể". Nếu bạn nhồi nhét vào prompt 20 đoạn (chunks) không liên quan chỉ vì ngưỡng cắt top-k quá lỏng lẻo, bạn đang trả tiền để mô hình đọc những thông tin rác. Hãy thắt chặt việc truy xuất. Giảm bớt top-k. Nén các đoạn (chunks) trước khi gửi chúng đi. Loại bỏ các phần chân trang (footer) và đầu trang (header) rập khuôn trong quá trình nạp dữ liệu để chúng không bao giờ chạm tới prompt. Mỗi token bạn loại bỏ khỏi cửa sổ ngữ cảnh (context window) là một phần nhỏ của một cent được tiết kiệm, và những phần nhỏ đó sẽ tích lũy qua hàng ngàn truy vấn hàng ngày.
Truy xuất tốt hơn cũng giúp cải thiện độ trễ (latency), vốn là một dạng chi phí khác. Người dùng sẽ rời bỏ các giao diện chậm chạp. Một câu trả lời nhanh hơn vừa rẻ hơn để tạo ra, vừa tốt hơn cho việc giữ chân người dùng.
Bài học thực sự
Đừng tối ưu hóa những gì bạn cảm thấy đắt đỏ, hãy bắt đầu tối ưu hóa những gì hóa đơn của bạn chỉ ra là đắt đỏ. Hãy đo lường từng giai đoạn một cách độc lập. Bạn có thể sẽ thấy rằng embeddings là phần rẻ, lưu trữ vector (vector storage) là phần ổn định, còn suy luận LLM (LLM inference) mới là phần gây thất thoát tiền bạc. Hãy tập trung năng lượng vào hiệu quả tại thời điểm truy vấn, các bản cập nhật lũy tiến và việc loại bỏ trùng lặp một cách chính xác (surgical deduplication). Hãy xây dựng cho câu hỏi thứ một nghìn của người dùng, chứ không phải cho lần tải lên tài liệu thứ năm mươi. Điểm nghẽn hiếm khi nằm ở nơi mà bạn nghĩ.
Nguồn: Where Does RAG Actually Cost You Money? I Decided to Stop Guessing
Tham gia thảo luận tại cộng đồng học tập GyaanSetu AI.