Mouad Elbaz 🚀

A common misconception is that retrieval starts when the user asks a question. It actually starts much earlier. Every decision you make during ingestion—chunking strategy, embedding model, metadata, indexing—directly affects retrieval quality later. A strong query pipeline can't fully compensate for a weak ingestion pipeline.

Every RAG system has two pipelines. Understanding the difference is key to building production-ready applications. 📥 Ingestion Pipeline (Offline) This is where your knowledge base is prepared. A typical ingestion process looks like this: 📄 Documents ↓ 🧹 Cleaning & Parsing ↓ ✂️ Chunking ↓ 🧠 Embedding Generation ↓ 🗄️ Store in a Vector Database ↓ 🏷️ Save Metadata & Build Indexes This pipeline usually runs once (or whenever new documents are added). Its goal is to make your data searchable. 🔍 Query Pipeline (Online) This runs every time a user asks a question. ❓User Query ↓ 🧠 Embed the Query ↓ 🔍 Retrieve Relevant Chunks ↓ 🎯 Re-rank Results ↓ 📦 Build Context ↓ 🤖 LLM Generates the Answer This pipeline determines whether your users receive accurate, grounded responses—or hallucinations. One insight that changed how I think about RAG: The ingestion pipeline prepares knowledge. The query pipeline finds it. Both are equally important. 💬 Which pipeline has caused you more headaches: Ingestion or Query? #AI #RAG #LLM #InformationRetrieval #MachineLearning #NLP #DataEngineering

I'll start. 👋 Hi, I'm Mouad from Morocco 🇲🇦 I'm building AI products with a focus on RAG systems, AI agents, and developer tools. My goal is to connect with people who love building, sharing ideas, and solving real problems. If our interests align, maybe we can build something together. 🤝

I'm trying to surround myself with people who are building, not just talking. If you're working on AI, SaaS, startups, or open source, let's connect. No pitches. Just sharing ideas, learning, and helping each other grow. 🤝

I find myself using cURL much more than Postman when building APIs. Reasons: ✅ Fast ✅ Scriptable ✅ Easy to version in documentation ✅ Works everywhere (local, CI/CD, servers) Curious—what does your API testing workflow look like?

Am I the only one who prefers cURL over Postman for API testing? There's something satisfying about keeping requests in the terminal: curl -X POST ... Fast. Reproducible. Easy to save in scripts. Easy to share. Maybe I'm old school. 😄 What's your go-to? • cURL • Postman • Bruno • Insomnia • HTTPie

Spent 40 minutes debugging a FastAPI endpoint. I checked the database. I checked the embeddings. I checked the vector search. I checked the API. The bug? A missing comma between function arguments. 😅 Sometimes the smallest typo takes the longest to find. Every developer has a story like this. What's the smallest bug that's ever cost you hours?

Yeah, I agree—the embedding model is often the biggest factor in retrieval quality. That said, once you're operating at production scale, infrastructure starts to matter too. If your embedding model is compute-intensive and you're handling large volumes of data, choosing the right vector database becomes important for horizontal scaling, filtering, indexing, and query latency. That's one of the reasons I like Qdrant for production RAG systems.

@MouadEl_AI The part most tutorials skip is that your embedding model choice matters more than your vector DB choice. Switching from a generic model to a domain-specific one improved our retrieval by 40% without touching the DB at all. What embedding models are people using in prod?

Many people think a Vector Database is just a place to store embeddings. It's much more than that. A Vector Database is designed to store, index, and search embeddings efficiently. The workflow is simple: 📄 Documents ↓ 🧠 Embedding Model ↓ 📐 Vector Embeddings ↓ 🗄️ Vector Database ↓ 🔍 Similarity Search ↓ 🤖 LLM Unlike a traditional SQL database, you don't search for an exact value. You search for the nearest vectors—the documents that are most semantically similar to your query. A production vector database typically provides: ✅ Approximate Nearest Neighbor (ANN) search ✅ Metadata filtering ✅ CRUD operations ✅ Persistence ✅ Horizontal scaling ✅ High-performance indexing (HNSW, IVF, PQ) Popular choices include: • Qdrant • Pinecone • Milvus • Weaviate • Chroma (great for prototyping) But here's an important point: A Vector Database doesn't improve your embeddings. It makes searching millions—or even billions—of embeddings fast enough for production. The quality of your RAG system still depends on: • Good chunking • Strong embedding models • Retrieval strategy • Re-ranking • Evaluation The vector database is the infrastructure that brings it all together. 💬 Which vector database are you using today, and why did you choose it? #AI #RAG #VectorDatabase #LLM #MachineLearning #DataEngineering #SemanticSearch #InformationRetrieval

One thing I appreciate about Qdrant is that it isn't just a vector store. Features like: • Metadata filtering • Hybrid Search (BM25 + Dense) • Sparse vectors • Multi-vector support • Quantization • Fast HNSW indexing make it well-suited for production RAG systems. What feature has been the biggest win for you?

Why is Qdrant becoming one of the most popular vector databases for RAG? When building a RAG system, storing embeddings isn't enough. You also need to retrieve the right documents quickly and efficiently. That's where Qdrant shines. It combines high-performance vector search with production-ready features like: 🚀 HNSW indexing for fast Approximate Nearest Neighbor (ANN) search 🏷️ Metadata filtering to narrow results by categories, users, dates, or any custom fields 🔄 Real-time CRUD operations without rebuilding the entire index 💾 Persistent storage so your vectors survive restarts 📈 Horizontal scaling for growing datasets One feature I particularly like is payload filtering. Instead of searching your entire vector collection, you can first filter by metadata, then perform semantic search. For example: Search only documents where department = "HR" and language = "English". This reduces search space and often improves retrieval quality. That's why Qdrant is a strong choice for: ✅ RAG applications ✅ Semantic search ✅ AI assistants ✅ Recommendation systems ✅ Enterprise search 💬 If you're using a vector database, what made you choose Qdrant over Pinecone, Milvus, Weaviate, or another option? #AI #RAG #Qdrant #VectorDatabase #SemanticSearch #MachineLearning #LLM #DataEngineering

@nasir_fashion Mostly Qdrant. Easy to set up, great documentation, and metadata filtering is a game changer for real-world RAG systems.

@MouadEl_AI Qdrant mostly. Simple setup, good docs, and metadata filtering helps a lot in real RAG apps.

@saen_dev Great point. Distance metrics are often overlooked. In my RAG experiments, cosine similarity combined with HNSW has given the best balance between retrieval quality and latency. I'm curious how others decide when IVF becomes the better choice.

@MouadEl_AI The part most teams skip is choosing the right distance metric for their data. Cosine similarity works for text but falls apart with sparse features. What indexing strategy are you using at scale, HNSW or IVF?

One common misconception: FAISS is not a vector database. FAISS is a similarity search library. A vector database builds on top of that by adding: • Persistence • Metadata filtering • APIs • Replication • Scalability • Multi-tenant support That's why many production systems use databases like Qdrant, Milvus, or Weaviate, while FAISS is often used for research and local applications.