RAG, Fine-Tuning, RLHF/DPO, Evals, Inference, Agents

These six terms are the toolkit an AI PM must know cold: RAG, fine tuning, RLHF and DPO, evals, inference, and agents. The mistake most make is treating them as vocabulary to recite. They are tools. Interviewers test whether you reach for the right one and can justify it over alternatives. Let us put each in its proper place. Here is our frame.

For each tool, we cover what it is, when to use it, the tradeoff, and how it shows up in a product decision. By the end, you will have a menu. When asked to design an AI system, you will know exactly which tool the problem requires. First is RAG, or retrieval augmented generation. Instead of answering from training data, you retrieve relevant documents, drop them into the prompt, and ask the model to answer using them.

The pipeline is straightforward. Chunk your documents, embed each chunk into a vector, and embed the question at query time. Find the top K similar chunks, add them to the prompt, and generate a cited answer. Use RAG when answers must be grounded in specific, current, or private data the base model lacks, like company documents, live prices, or user files.

It is also essential when you need citations. The tradeoff is freshness, grounding, and citations. You update knowledge by changing documents rather than retraining. The cost is system complexity. You need an embedding model, a vector store, and a retrieval step that can fail, adding latency. Answer quality is capped by retrieval quality. If it pulls the wrong chunk, the model confidently answers from it.

For a product decision, designing a system for moderators to check misinformation against policy is a RAG problem. Ground every verdict in a cited policy passage. If retrieval confidence drops, route it to a human. RAG is the default answer for stopping hallucinations on proprietary data. Second is fine tuning. You continue training a base model on your examples so its weights shift toward your task, format, or style.

The model looks nothing up at runtime. The behaviour is baked in. Use it when you need a consistent format, tone, or narrow skill that prompting cannot reliably achieve, and you have hundreds or thousands of good examples. Classic uses include enforcing a strict JSON shape, matching a house writing style, or handling specialised classification. The tradeoff is reliable behaviour, often allowing a smaller, cheaper model to do a narrow job well.

But it is static. It bakes in knowledge from your training data, so it goes stale and requires retraining to update. It needs labelled examples, can cause the model to forget other abilities, and cannot cite sources. Fine tuning teaches behaviour, not fresh facts. The product decision often falls into the classic interview trap of choosing between RAG and fine tuning.

The clean answer is RAG for changing knowledge that needs citing, and fine tuning for stable behaviour, format, and style. They are not rivals. Real systems often use both, with a fine tuned model that also retrieves. Third is RLHF and DPO, the preference alignment pair. Both make model outputs match human preferences rather than just predicting likely text. RLHF is reinforcement learning from human feedback.

Humans rank outputs, you train a separate reward model on those rankings, then use reinforcement learning to push the model toward high rewards. DPO is direct preference optimisation. It shares the same goal but skips the reward model, optimising directly on preferred versus rejected pairs, making it simpler and more stable to train. When do you use this? Mostly, you do not, at least not as a PM.

This is a research and training concern, not a per feature configuration. But you must know it because it explains why chat models are helpful and polite instead of just autocompleting. Interviewers will also test your familiarity with RLHF and DPO. The tradeoff is that alignment makes models more helpful, harmless, and better at following instructions. This costs a heavy human labelling pipeline for RLHF.

DPO offers a simpler pipeline but the same dependence on good preference data. Over align, and you get a model that refuses harmless requests or sounds hedged and bland. For the product decision, you rarely run RLHF yourself, but you own the quality bar on preference data and feel the results. If your model is too cautious or eager, that is an alignment outcome.

The fix lives in preference and eval data, not a prompt tweak. Knowing DPO drops the separate reward model used in RLHF signals real AI depth in a technical round. Fourth is evals. Evals systematically measure if the model is actually good, rather than relying on vibes. There are two layers. Offline evals use a fixed golden set of inputs with known good outputs or scoring rules.

You run these before shipping to measure accuracy, faithfulness, and format compliance. Online metrics track real user behaviour in production, covering task success, thumbs up rates, and retention. Use evals always, and early. The most common failure story in behavioural interviews is shipping without an eval set and failing to notice when a prompt change made things worse. An eval set turns a vague feeling into a concrete metric, showing faithfulness improved from 82 percent to 91 percent on the golden set.

The tradeoff is that building and maintaining a good eval set costs real time. A golden set can go stale or miss edge cases. But without one, you are flying blind. You cannot safely change a prompt or swap a model because you cannot detect regressions. The product decision arises when asked how you evaluated your LLM or to whiteboard an eval framework.

The move is always the same. Separate offline evals, which use the golden set before shipping to catch regressions, from online metrics, which track real usage to catch what the golden set missed. Then add a human in the loop step to review uncertain cases. Fifth is inference. Inference is running the model to produce an output, as opposed to training it.

When a user sends a prompt and gets a response, that is an inference call. Along the request path, input is tokenised, requests are batched for GPU efficiency, and the model generates tokens sequentially. It reuses a KV cache to avoid recomputing earlier tokens, and tokens stream back to the user as produced. This is the system part you actually operate and pay for in production.

Every latency complaint and GPU bill is fundamentally an inference question. The tradeoff involves levers balancing cost, speed, and quality. Batching raises throughput but can add individual user latency. Quantisation uses lower precision weights to cut cost and speed up processing, with a small quality hit. Caching, both the KV cache within a request and prompt caches across requests, cuts cost and latency but adds complexity.

Streaming does not make generation faster overall, but feels faster because users see the first words sooner. For the product decision, building an LLM inference pipeline is a real interview question. The answer is the request path plus the levers. You tokenise, batch, use a KV cache, and stream, tuned with quantisation and caching. Inference solves both the feature is too slow and the feature is too expensive problems, so know the knobs even if you never turn them yourself.

Sixth is agents. An agent is an LLM that takes actions, not just producing text. You give it tools like search, a calculator, an API, or a database query, plus a goal and a loop. The model decides which tool to call, sees the result, decides the next step, and repeats until done or hitting a stop condition. Always name three parts: the job, the tools, and the stop conditions dictating when it must stop or hand off.

Use an agent when a task needs multiple steps, external information, or real world actions, and a single prompt will not suffice. Examples include booking items, researching across sources, or operating software. The tradeoff is that agents accomplish multistep tasks a single call cannot, but every step compounds error chances. They are slower and pricier due to many model calls per task.

Giving a model the ability to act raises the stakes of mistakes. An agent that spends money or sends emails needs permission scoping, confirmation on risky actions, and reversibility via an undo feature or action log. Product decisions like designing an AI agent for a streaming service, or designing safeguards for an AI acting on a user's behalf, are agent questions.

Always define the job, tools, and stop conditions. Then design guardrails. Confirm before costly or irreversible actions, log everything, and keep a human able to step in. An agent with no stop conditions is a demo, not a product. Let me slot all six into one system. You are building a bank customer support assistant. You use RAG to ground answers in current policy and product documents with citations, because those change and wrong answers are costly.

You fine tune a small model to classify incoming messages, because that behaviour is stable and a cheap model handles it reliably. You benefit from RLHF and DPO alignment baked into the base chat model, making it polite and instruction following. You build an eval set of past tickets with known good resolutions, run it before every prompt change, and route low confidence cases to a human.

You run inference with batching and caching to control latency and cost at scale. For tasks needing action, like checking a balance or opening a dispute, you use an agent with a strict tool list, a rule to confirm before moving money, and a full action log. One product, all six tools, each doing the right job. Here are a few myths to kill fast.

RAG and fine tuning are not competitors. They solve different problems, and real systems often use both. Fine tuning does not teach new facts. It teaches behaviour and format, and goes stale, so for fresh facts you retrieve. Evals are not a nice to have feature added later. They let you change things safely, so shipping without them is the most common failure story in this course.

An agent is not just a smarter chatbot. It takes actions, which is a different risk class requiring stop conditions, confirmation, and reversibility. We have six tools and six jobs. RAG grounds in changing data with citations. Fine tuning bakes in stable behaviour. RLHF and DPO align to human preference. Evals tell you if it is actually good. Inference is where you pay and tune speed.

Agents add tools and a loop, which is exactly why they need guardrails. Memorise this framework. When asked to design an AI system, run the menu. Ask if it is a grounding, behaviour, measurement, latency, cost, or multistep action problem. Name the right tool and the tradeoff. That is the AI depth signal they are scoring.