Avi Chawla

@_avichawla

How to make RAG 32x memory efficient (explained with code)!

How Perplexity, Azure, HubSpot, and many others use binary quantization to make RAG 32x memory efficient (explained with code)!

There’s a simple technique that’s commonly used in the industry that makes RAG ~32x memory efficient!

Perplexity uses it in its search index

Azure uses it in its search pipeline

HubSpot uses it in its AI assistant

To learn this, we’ll build a RAG system that queries 36M+ vectors in <30ms.

And the technique that will power it is called Binary Quantization.

Tech stack:

Llama Index for orchestration (open-source)

Milvus as the vector DB (open-source)

Kimi-K2 as the LLM hosted on Groq (hosted)

Image unavailable

Here's the workflow:

Image unavailable

Ingest documents and generate binary embeddings.

Create a binary vector index and store embeddings in the vector DB.

Retrieve top-k similar documents to the user's query.

LLM generates a response based on additional context.

Let's implement this!

1) Load data

We ingest our documents using LlamaIndex's directory reader tool. It can read various data formats, including Markdown, PDFs, Word documents, PowerPoint decks, images, audio, and video.

We are using a simple PDF directory reader here for explainability, but in practice, your ingestion pipeline will likely pull from multiple data sources with varied formats and preprocessing steps.

2) Generate Binary Embeddings

Next, we generate text embeddings (in float32) and convert them to binary vectors, resulting in a 32x reduction in memory and storage.

This is called binary quantization.

3) Vector indexing

After our binary quantization is done, we store and index the vectors in a Milvus vector database for efficient retrieval.

Indexes are specialized data structures that help optimize the performance of data retrieval operations.

4) Retrieval

In the retrieval stage, we:

Embed the user query and apply binary quantization to it.

Use Hamming distance as the search metric to compare binary vectors.

Retrieve the top 5 most similar chunks.

Add the retrieved chunks to the context.

This is the implementation:

5) Generation

Moving on, we build a generation pipeline using the Kimi-K2 instruct model, served on the fastest AI inference by Groq.

We specify both the query and the retrieved context in a prompt template and pass it to the LLM.

Finally, we wrap this up in a Streamlit interface!

To assess the scale and inference speed, we test the setup over the PubMed dataset (36M+ vectors).

Here's a demo:

Image unavailable

Our app:

queried 36M+ vectors in <30ms.

generated a response in <1s.

Done!

We just built the fastest RAG stack leveraging BQ for efficient retrieval and

using ultra-fast serverless deployment of our AI workflow.

The code is available here: https://github.com/patchy631/ai-engineering-hub/tree/main/fastest-rag-milvus-groq

Here's the workflow again for your reference 👇

Image unavailable

One thing to note here is that binary quantization makes the vector search layer incredibly efficient. But in production, retrieval is rarely just a vector lookup.

Real-world agents pull context from Slack, GitHub, Jira, databases, and docs simultaneously. That means auth, sync, query routing, permissions, and reranking all become first-class concerns alongside the embedding search itself.

So think of BQ as one powerful piece of the retrieval infrastructure, not the whole story. The faster and leaner you make your vector layer, the more room you have to invest in everything else that makes retrieval actually work at scale.

I covered what that full retrieval infrastructure looks like in a recent post, breaking down how companies like Google and Microsoft actually give context to their production agents.

Read below:

That's a wrap!

If you enjoyed this tutorial:

Find me → @_avichawla

Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.

X Article