Fatos

Founder of #DataScienceInitiative. #ML / #MLOps / #AI / #Data @Microsoft. Prev. Cloud Architect @Oracle. Opinions are my own.

[Microsoft Research @MSFTResearch]

AI agents are writing more code. How can developers ensure that code is correct?

Microsoft Research’s Proof-Driven Development (PDD) Kit explores a more rigorous approach: it translates a developer’s intent into a formal specification, then uses formal verification to prove that generated code meets it.

PDD Kit works with Verus for Rust and is integrated with @GitHubNext’s Chopin, bringing formal methods into an AI-assisted development workflow for teams.

See the work in action at @github Universe, Oct. 28–29, 2026.

[Fatos @bytebiscuit]

How Jev works:

[Fatos @bytebiscuit]

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.

[Fatos @bytebiscuit]

Part 5: How RAPTOR RAG works:

RAPTOR RAG is built for the bigger picture.

Instead of retrieving isolated chunks, RAPTOR organises knowledge into a hierarchy:

Chunks → Clusters → Summaries → Tree

This lets RAG retrieve at different levels of detail, from a specific fact to a broader theme spanning multiple documents.

🌳 Search across levels
🔗 Connect information across chunks
📚 Better for long, complex documents
🎯 Retrieve at the right level of detail

Think of it as RAG that can see both the leaves and the tree.

[Fatos @bytebiscuit]

Part 0:

Summary of 8 RAG techniques

[Fatos @bytebiscuit]

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.

[Fatos @bytebiscuit]

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.

[Fatos @bytebiscuit]

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.

[Fatos @bytebiscuit]

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.