Please let's dispel the myth that taking AI applications to production is just an LLM call away. As this picture shows it is much more complicated than that and often this is overlooked.

Part 3: How Rerank RAG works Rerank RAG is about quality over quantity. Retrieval finds the most similar documents. But the most similar documents aren’t always the most relevant. That’s where reranking comes in. Query → Retrieve Top-K → Rerank → Best Context → LLM The idea is simple: 🔎 Retrieve broadly for recall 🎯 Rerank for precision 🧠 Give the LLM only the best context Instead of stuffing more documents into the context window, reranking helps decide which documents actually deserve to be there. Better ranking → cleaner context → better answers.

Part 2: How HyDe (Hypothethical Document Embeddings) works HyDE RAG changes what you search with. Instead of embedding the user’s question directly, HyDE first generates a hypothetical answer and uses that to find relevant documents. User Query → Hypothetical Answer → Embed → Retrieve → Grounded Answer Why? The language in a question can be very different from the language used in your knowledge base. HyDE tries to bridge that semantic gap. Think of it as: “Imagine what the answer might look like, then find documents that look like it.” The hypothetical answer doesn’t need to be correct. It just needs to improve retrieval. Smarter retrieval → better context → better RAG.

Part 1: How Hybrid RAG works: Hybrid RAG is what happens when you stop asking one retrieval method to do everything. Vector search is great at finding semantic similarity. Keyword search is great at finding exact matches. Hybrid RAG combines both. Think: Vector search → “Find things that mean the same thing” Keyword/BM25 → “Find this exact term, ID, product name or phrase” Hybrid retrieval → combine the candidates Reranker → decide what actually matters LLM → generate from the best context This becomes especially useful in enterprise RAG, where your data contains a mix of natural language, acronyms, technical terms, policy names, product codes and identifiers. Semantic search alone can miss the exact match. Keyword search alone can miss the meaning. Hybrid RAG gives you both. Better retrieval usually means better generation.

One of the easiest ways to make an Agentic AI system more expensive is to keep adding agents. More agents means more handoffs, more context passing, more model calls, more latency and more failure points. I tend to think about orchestration as a complexity ladder: 1. Single agent + bounded toolset - best starting point for most workloads. Challenges: - Too many tools can still overwhelm the agent - Tool selection gets harder as the toolset grows - Poorly scoped tool descriptions add unnecessary context 2. Single agent + deterministic workflow steps - useful when parts of the process do not need model reasoning. Challenges: - You need to decide what should be deterministic vs model-driven - Too much hard-coded logic can make the workflow rigid - State management starts to matter as the workflow grows 3. Planner + specialist agents - makes sense when there are genuinely different areas of expertise or execution. Challenges: - Every handoff adds tokens and latency - Context has to be passed between agents - Planner mistakes can cascade into the rest of the workflow - Debugging becomes harder because failures can happen across multiple boundaries 4. Peer multi-agent systems - useful for problems that genuinely benefit from agents collaborating, debating or working independently. Challenges: - Highest coordination overhead - Agents can repeat the same work - Conversations can loop unnecessarily - Token consumption can grow very quickly The more complex the agent topology, the harder it becomes to understand why the system reached a particular outcome. There are also some fairly simple optimisation patterns that help: parallelise independent tool calls, summarise large tool outputs, keep tool descriptions minimal, cache repeatable results and put limits on loops and token consumption. The important bit for me is this: Start with the smallest topology that reliably solves the problem, then add complexity when the workload gives you a reason to.