{"id":"2040326889928356122","url":"https://x.com/_avichawla/status/2040326889928356122","text":"","author":{"name":"Avi Chawla","username":"_avichawla","avatarUrl":"https://pbs.twimg.com/profile_images/1868297128801390593/Ovl677JQ_200x200.jpg"},"createdAt":"Sat Apr 04 07:13:32 +0000 2026","engagement":{"replies":12,"retweets":131,"likes":835,"views":629083},"article":{"title":"How to make RAG 32x memory efficient (explained with code)!","previewText":"How Perplexity, Azure, HubSpot, and many others use binary quantization to make RAG 32x memory efficient (explained with code)!\n \nThere’s a simple technique that’s commonly used in the industry that","coverImageUrl":"https://pbs.twimg.com/media/HFCyFOmbQAEeJEv.jpg","content":"How Perplexity, Azure, HubSpot, and many others use binary quantization to make RAG 32x memory efficient (explained with code)!\n\nThere’s a simple technique that’s commonly used in the industry that makes RAG ~32x memory efficient!\n\n- Perplexity uses it in its search index\n\n- Azure uses it in its search pipeline\n\n- HubSpot uses it in its AI assistant\n\nTo learn this, we’ll build a RAG system that queries 36M+ vectors in <30ms.\n\nAnd the technique that will power it is called Binary Quantization.\n\nTech stack:\n\n- Llama Index for orchestration (open-source)\n\n- Milvus as the vector DB (open-source)\n\n- Kimi-K2 as the LLM hosted on Groq (hosted)\n\nHere's the workflow:\n\n- Ingest documents and generate binary embeddings.\n\n- Create a binary vector index and store embeddings in the vector DB.\n\n- Retrieve top-k similar documents to the user's query.\n\n- LLM generates a response based on additional context.\n\nLet's implement this!\n\n## 1) Load data\n\nWe 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.\n\nWe 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.\n\n## 2) Generate Binary Embeddings\n\nNext, we generate text embeddings (in float32) and convert them to binary vectors, resulting in a 32x reduction in memory and storage.\n\nThis is called binary quantization.\n\n## 3) Vector indexing\n\nAfter our binary quantization is done, we store and index the vectors in a Milvus vector database for efficient retrieval.\n\nIndexes are specialized data structures that help optimize the performance of data retrieval operations.\n\n## 4) Retrieval\n\nIn the retrieval stage, we:\n\n- Embed the user query and apply binary quantization to it.\n\n- Use Hamming distance as the search metric to compare binary vectors.\n\n- Retrieve the top 5 most similar chunks.\n\n- Add the retrieved chunks to the context.\n\nThis is the implementation:\n\n## 5) Generation\n\nMoving on, we build a generation pipeline using the Kimi-K2 instruct model, served on the fastest AI inference by Groq.\n\nWe specify both the query and the retrieved context in a prompt template and pass it to the LLM.\n\nFinally, we wrap this up in a Streamlit interface!\n\nTo assess the scale and inference speed, we test the setup over the PubMed dataset (36M+ vectors).\n\nHere's a demo:\n\nOur app:\n\n- queried 36M+ vectors in <30ms.\n\n- generated a response in <1s.\n\nDone!\n\nWe just built the fastest RAG stack leveraging BQ for efficient retrieval and\n\nusing ultra-fast serverless deployment of our AI workflow.\n\nThe code is available here: https://github.com/patchy631/ai-engineering-hub/tree/main/fastest-rag-milvus-groq\n\nHere's the workflow again for your reference 👇\n\nOne 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.\n\nReal-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.\n\nSo 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.\n\nI 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. \n\nRead below:\n\nThat's a wrap!\n\nIf you enjoyed this tutorial:\n\nFind me →  @_avichawla\n\nEvery day, I share tutorials and insights on DS, ML, LLMs, and RAGs."}}