# Building LLMs for Production: which chapters FDEs should read, and in what order

> An FDE heading into the field does not need all 400-plus pages, but should read the data preparation material before thinking about fine-tuning.

Original: https://fdetimes.net/en/books-courses/building-llms-for-production-fde-reading-order/

The major addition in the October 2024 update to a roughly 470-page book about LLMs turned out to be about data: an entirely new chapter on indexes, retrievers and data preparation.

That detail also suggests how to read *Building LLMs for Production*, the book published by Towards AI and co-authored by Louis-François Bouchard. If you are an FDE, study the customer's documents closely before discussing model choice, because RAG can only answer correctly when it finds the right passage.

So the question worth asking is not whether the book is good, but what to read before going into the field. The short answer: six sections, read in a different order from the table of contents.

## First, buy the right book

The book currently goes by two names. The first edition is *Building LLMs for Production*, with a subtitle naming prompting, fine-tuning and RAG. The second edition, on the Towards AI site, becomes *Building AI for Production*, with 12 chapters and a subtitle that names only fine-tuning and RAG.

If you own the older version, you need not buy it again just for Agents or Fine-Tuning. Towards AI's comparison table says those two chapters were mainly restructured, while Deployment goes deeper; that is the real reason to upgrade, along with the new data chapter if your copy lacks it.

The entry requirements are very low: Towards AI wrote the book for people who know nothing about AI or NLP, and Bouchard asks only for a little Python. If you have spent a few years in backend work, you can skim the LLM and NLP foundations and slow down when you meet an unfamiliar term.

Jerry Liu, co-founder and CEO of LlamaIndex, called it the most comprehensive textbook on applying LLMs at the time of his remark, but comprehensiveness is also the reason not to read it from front to back.

## A reading order tied to deployment progress

The chapter numbers below follow the second edition. The order and the right-hand column are advice for FDEs and do not come from the book.

The index and retriever chapter alone has no number, because its title comes from the October 2024 update and could not be matched to a chapter number in the second edition. Look for it by topic in the table of contents of the copy you have.

| Order | What to read | Work at the customer |
|---|---|---|
| 1 | Chapter V: RAG | Before arrival: understand the links in the chain and build a trial on public documents |
| 2 | Indexes, retrievers, data preparation | First session: ask for 50 real questions, handle messy documents, measure retrieval |
| 3 | Chapter IX: Advanced RAG | Fix the specific faults you have measured |
| 4 | Chapter XII: Deployment | Settle where the model runs, latency and cost |
| 5 | Chapter X: Agents | Expand once retrieval is reliable |
| 6 | Chapter XI: Fine-Tuning | Consider it when the steps above are not enough |

Putting Fine-Tuning last is an opinion, not a rule from the book. It consumes labelled data and maintenance effort, whereas faults in the early stages of a RAG project can often be fixed more cheaply on the data side. Agents come before it because many customers will ask about agents early, but an agent built on a poor retriever is only wrong faster.

## Build a RAG pipeline by hand once before using a framework

The update includes a step-by-step guide to building a basic RAG pipeline from scratch, and the book comes with ready-to-run Colab notebooks and code projects. Do not just skim this part. When your demo gives a wrong answer in front of a customer, you need to know which step is at fault, and someone who has assembled each link by hand finds it much faster.

A practical note: the ebook on the Towards AI site is interactive, not a downloadable PDF. Do not count on saving a file to read on your way to the customer.

## Measure the retriever before blaming the model

This is why the index and retriever chapter comes second. Imagine an insurance company hands you a store of PDF contracts and wants a chatbot to answer its employees' questions. You write 50 real questions with those employees, each paired with the passage containing the answer, then run the retriever on its own.

Suppose the retriever finds the right passage for only 30 questions. The other 20 have no correct basis for an answer, so whichever model you switch to, at most 30 of 50 questions, or 60%, can be answered from the right document.

With this number, the meeting no longer revolves around the model seeming not quite clever enough. People will discuss how to re-chunk and re-index the documents.

**Key point:** If the retriever does not find the right passage, no model, however good, can rescue the answer.

The first thing to do at a customer, then, is not to choose a model. Ask for 50 real questions and the people who can answer them, before writing the first line of RAG code against their data. Only once you know why those 20 questions fail does the Advanced RAG chapter become a list of remedies for the right illness.

## Calculate latency before making promises to the customer

The deployment section has been expanded with distillation, a technique for reducing inference cost and latency, along with a case study of Google's Gemma 2. The book also covers deploying LLMs on Together AI, Groq, Fireworks AI and Replicate. Any list of platforms ages quickly, so learn how to compare them rather than memorising names.

The calculation to make is simple. Suppose the customer needs an answer within 1.5 seconds, the retriever takes 300 milliseconds and the model takes 2 seconds: the total is 2.3 seconds, 800 milliseconds slower than required.

At that point you can change where the model runs, use a smaller model, or consider distillation if traffic is high enough to justify the effort. Do not commit to a response time with the customer before measuring these numbers on real infrastructure.

## Turn the book into evidence for job applications

Finishing a book proves nothing to a recruiter. If an FDE job description mentions RAG on customer data, review chapters V and IX; if it mentions production deployment or latency optimisation, review chapter XII.

On a CV, a small project with measurements is stronger than a line saying you read the book: which messy documents, how many questions out of how many the retriever got right before and after the fix, and what the measured latency was.

In interviews, be ready to explain why you have not fine-tuned yet. That answer shows you know when a technique is not yet worth doing.

The book runs to about 470 pages, but the first session at a customer may start with nothing more than a folder of PDFs and 50 questions. Anyone who prepares for that session will read the rest with much clearer questions in mind.

**Try this week:**

- Build a basic RAG pipeline following the book on a set of public documents, then write 50 questions with their correct passages to measure the retriever.
- Deploy an open-source LLM on a cloud platform and record the measured latency against a target you set yourself.
- Rewrite one line of your CV to this pattern: before and after fixing the retriever, how the rate of finding the right passage changed.

## Sources

- [The AI Engineer's toolkit | What's AI](https://www.louisbouchard.ai/book-towards-ai/)

- [Building LLMs for Production Gets a Massive Update](https://towardsai.com/p/machine-learning/building-llms-for-production-gets-a-massive-update)

- [Building AI for Production](https://towardsai.com/book)

- [Building LLMs for Production](https://towardsai.com/academy/building-llms-for-production/)