DeepLearning.AI's RAG course with Zain Hasan: what FDEs should study and what to skim

DeepLearning.AI’s RAG course runs about 26 hours across five modules. Yet the module rated most highly by one learner who earned the certificate comes last: production.

For an FDE, that ordering is both an advantage and a trap. The advantage is that a solid retrieval foundation is in place before operations come up. The trap is that if you work through it in sequence without knowing what you need, you may give up before reaching the part that is worth the most.

The course is called “Retrieval Augmented Generation (RAG)” and is available on the DeepLearning.AI site (listed as updated on 23 July 2026) and on Coursera. Every module has programming assignments that build, one by one, the core components of a RAG system.

Connecting an LLM to a customer’s own documents is everyday FDE work. Pick the right parts to study closely and you will know enough to discuss design decisions with the customer in the working session itself.

Who teaches it, and how realistic is the practice?

Zain Hasan is an AI/ML developer relations engineer at Together AI and also teaches at the University of Toronto. As a result, the course leans towards building rather than theory.

A typical lab is a chatbot for a fictional clothing store: it starts on a proprietary LLM and later moves to an open-source model from Together AI. While doing this lab, note which parts of the pipeline have to change when the model changes, because that is the situation an FDE faces when a customer changes requirements midway.

The final programming assignment, “Improving the ChatBot”, deals with production concerns such as constantly changing prices and logging interactions for monitoring. These are exactly the kinds of problems that make a polished demo start giving wrong answers once it meets real data.

What to study closely, and what to skim

The right order depends on your search background. If you have worked on search or already know vector databases, move quickly through the retrieval modules and stop only for the exercises.

If not, do not skip them. The model can only write from what retrieval hands it, so weak search makes the generation step that follows very hard to rescue. Module 3, on vector databases, is where the learner mentioned above says they learned a lot.

Module 4, on text generation, is worth revisiting even if you already know LLMs well. According to the same learner, it goes into detail on LLM sampling strategies in RAG, something this learner believes few people understand.

Module 5 is devoted entirely to production: monitoring, evaluation, latency, security and the trade-off between cost and quality. That is almost exactly the list of questions customers will put to you, so whichever group you are in, read this module’s syllabus early.

Hybrid retrieval is not a garnish

One lab compares three retrieval methods: semantic search, BM25 and Reciprocal Rank Fusion, which merges rankings from several search methods. It is worth doing carefully because it answers a very practical question: when is one search method not enough?

Picture a manufacturing customer whose maintenance documents are full of part codes such as “SKU-4471”. Embeddings are good at capturing meaning but tend to miss exact strings like that; BM25 is the reverse.

So the first thing to do at a customer is to collect real user questions and count how many contain codes, proper names or serial numbers. If that share is high, combining the two methods should be the default, not an optimisation saved for later.

Cost starts with retrieval quality

The cost-versus-quality trade-off in module 5 is easier to grasp with some back-of-the-envelope maths. Suppose each question retrieves 20 passages of 500 tokens each: the context is already 10,000 tokens. Cut that to 5 passages and it drops to 2,500 tokens, which is cheaper and faster.

The condition is that those 5 passages really are the best ones. The more precise retrieval is, the fewer tokens you can send without losing quality.

At a customer, put two numbers on the table from the very first design session: how many tokens each question costs, and within how many seconds it must be answered. Once both are clear, the discussion becomes far more concrete than an argument over which model to pick.

Knowing where the system breaks

The learner who completed the certificate considers module 5 the most valuable part, mainly because it teaches a specific set of observability tools. This is the skill that separates an FDE from someone who only builds demos.

If the logs show that the right passage was never retrieved, changing the prompt is pointless; you have to fix retrieval. If the right passage was in the context and the answer is still wrong, only then is it time to look at the prompt, the sampling settings or the model.

A certificate is not proof

The same learner also points out the weaknesses: the notebook grading is fairly rigid and the multiple-choice quizzes are not difficult. So do not treat passing the assignments as a sign that you have mastered the material.

Stronger proof is a small project: RAG over a public document set, with a comparison of semantic search against a combination with BM25, a log of every query, and a table recording latency, token cost and the share of correct answers.

When you read the job description for an FDE role, look for mentions of hybrid search, vector databases or observability. If they are there, that project is what goes on your CV and what you talk about in the interview.

Someone who finishes all five modules will know what RAG is. Someone who studies the final module closely and measures their own system will know where to look when a customer calls to say the answers are wrong.