Gaurav Sen

20 AI Concepts Explained in 40 Minutes

Watch on YouTube · Gaurav Sen · Transcript fetched 2026-09-02

20 AI Concepts Explained in 40 Minutes

Artificial intelligence has developed its own vocabulary, and engineers building AI-powered applications hear new terms almost every week. This article walks through the twenty concepts that matter most — from large language models and attention to agents and quantization — following the explainer by Gaurav Sen (GKCS) for engineers. If you need to communicate clearly with teammates and stakeholders, evaluate AI products, or prepare for deeper study, these definitions with their concrete examples and honest caveats will give you a solid mental map of the field.

Table of Contents

  1. Large Language Models
  2. Tokenization
  3. Vectors
  4. Attention
  5. Self-Supervised Learning
  6. Transformers
  7. Fine-Tuning
  8. Few-Shot Prompting
  9. Retrieval-Augmented Generation
  10. Vector Databases
  11. Model Context Protocol
  12. Context Engineering
  13. Agents
  14. Reinforcement Learning and RLHF
  15. Chain of Thought
  16. Reasoning Models
  17. Multimodal Models
  18. Small Language Models and Foundation Models
  19. Distillation
  20. Quantization

1. Large Language Models

A large language model (LLM) is a neural network trained to predict the next token of an input sequence. Give it the beginning of a phrase and it produces the most plausible continuation, one token at a time.

The classic example: pass the query "All that glitters" into an LLM, and it predicts the next token "is," then "not," then "gold" — returning the complete proverb "All that glitters is not gold" to the user. The output looks like the model understands poetry, but mechanically the model is only ever completing a sequence.

Two parts of that definition deserve unpacking, and the video returns to both: what a neural network is (a large collection of numerical weights that map input to output), and what training means (adjusting those weights so predictions get better). Both ideas come up again and again across the other nineteen terms, so the definition is worth holding onto.

2. Tokenization

Before an LLM can predict anything, it must process the input text, and the first step of that processing is tokenization: breaking the text into discrete tokens, the smallest pieces from which the model can derive meaning.

Take "All that glitters." The model splits it into tokens — "all," a space character, "that," and so on. But you might reasonably ask: why not just split on spaces and be done with it? Because humans do not talk that way. Natural language carries meaning inside words, not just between them, and the model is trying to process natural language the way humans use it.

Consider words like shimmers, murmurs, and flickers. They share a suffix — the final "-s" — which tells the model that the action is being performed by the subject of the sentence. Similarly, eating, dancing, and singing all end in "-ing," a token that signals the action is ongoing. If the model splits words into stems and meaningful suffixes, it can recognize these grammatical patterns and generalize them to words it has never seen. The end result of tokenization is that any input text is broken into tokens the model can work with — an essential step toward the LLM's core goal of understanding human language well enough to speak it well.

3. Vectors

Tokens tell the model what to focus on; vectors carry what the tokens mean. If the model can map words into a two-dimensional — or, more realistically, an n-dimensional — space such that words close in meaning land close together, then meaning itself has been converted into a coordinate. That coordinate is the word's vector.

This mapping, called vectorization, clusters similar words together: synonyms and related terms sit near one another, while words with opposite meanings sit far apart. Once an LLM knows the vectors of the vocabulary, it knows the inherent meaning of the words in the English language, and it knows how to break any input into tokens whose meaning it can look up. Words that are similar end up close to each other in the space, and with those meanings in hand the model can construct sentences effectively.

Vectors set up the next problem: a word's spelling is fixed, but its meaning is not. Resolving that ambiguity turned out to be the challenge that changed the entire industry.

4. Attention

Here is the problem vectors alone cannot solve. When you say "a tasty apple," you mean the fruit you can eat. When you say "Apple's revenue," you mean the company. When you say "the apple of my eye," you mean a person you have affection for. The spelling of "apple" is identical in all three cases, so the word's meaning cannot come from the word itself — it has to come from the words around it, which supply the context.

The moment you hear "tasty," you know the sentence is about food. Humans derive meaning this way, and attention is the mechanism that lets a large language model do the same. The model looks at the nearby words in a sentence, computes contextual vectors for them, and uses them to adjust the vector of the ambiguous word. So the vector for "apple" combined with the vector for "revenue" — not by simple addition, but through the attention operation — gets pushed toward the company cluster, where Google, Meta, and Microsoft live. Combine "apple" with "tasty" instead, and attention pushes the vector toward the fruit cluster: banana, chiku, guava. For an ambiguous token you end up with an ambiguous vector, but adding the context from nearby words disambiguates it.

Attention was introduced in a landmark 2017 paper, but it stayed largely academic until 2022, when a consumer-facing chatbot built on the architecture reached the general public and made LLMs famous. The quality of the responses exceeded anything seen before, because the model could derive contextual meaning and construct sentences the way humans do.

5. Self-Supervised Learning

Attention explains how an LLM processes input, but how do you train a model to predict the next token in the first place? The breakthrough that made this scalable is self-supervised learning, which became popular after the same 2017 paper. Instead of telling the model exactly what to do for every input, you rely on the structure of the input data itself — the data structure makes clear what the model should predict.

The video demonstrates with two tricks played on the viewer. First, an on-screen countdown — 1, 2, 3, 4, 5 — with one number blanked out. Everyone can guess the hidden number is 1, because the sequence has inherent structure. Second, a face on screen with the eye region blanked; viewers correctly guess that the eyes are looking upward. In both cases, a section of the input can be predicted even when it is missing, which means the input itself carries the answer.

The alternative would be supervised learning, where a human must label every example: "if the input is 'All that glitters,' the model should predict 'is not gold'"; "if the input is 'Et tu,' the output should be 'Brute.'" That is expensive. Self-supervised learning instead takes text that already exists in the world — scraped from the internet, say — and creates multiple challenges from it with no human involvement. From a single sentence like "Et tu, Brute," the model gets three puzzles running in parallel: predict the token after "Et," predict the token after "Et tu," and predict the token after "Et tu, Brute." If the model guesses "tu" correctly, the weights do not need to change; if it guesses "Caesar" instead of "Brute," it is penalized, the loss rises, and the neural network's weights are updated. Guess wrong after the full phrase, and you are told the correct continuation was a comma or an end-of-sentence marker.

This may seem like a small thing, but it is an architectural decision that makes LLMs genuinely scalable. Most AI models now move toward self-supervised learning: image models blank out patches of an image and try to predict them, which teaches the underlying structure and inherent meaning of those patches — terms in the case of text, pixels in the case of images, and in the case of video, how objects move.

6. Transformers

A common confusion is to treat "transformer" and "large language model" as the same thing. They are not. An LLM is the thing that predicts the next token given an input sequence; a transformer is one specific algorithm, one specific method for doing that prediction.

The transformer architecture works like this: input tokens pass through an attention block, whose outputs are forwarded to a feedforward neural network, producing a set of output vectors. Those vectors pass into another attention layer, then another feedforward network, and so on, stacked many layers deep — sometimes twelve layers, sometimes more, and in recent GPT architectures, hundreds. Each layer does something different. The first attention layer disambiguates terms using context. Later layers find more complex relationships — sarcasm, implications. In the sentence "A crane was hunting a crab," the first layer determines that "crane" is the bird and not the construction machine; a deeper layer infers that the crab is fearful and the crane is hungry. The repeated manipulation of meaning continues until the model is confident enough to generate an output token.

The insight of the architecture is to extract all the meaning available from the input tokens and manipulate it again and again until the next word can be predicted well. It helps to think of the relationship as a car and an engine:

A large language model is the product — you can think of it as a car — and the transformer is the engine.

The engine is replaceable. A new architecture could come along that does away with the transformer and other sequence models — a diffusion model, for example, that constructs text. The product (the LLM) stays the same even when the internal algorithm changes.

7. Fine-Tuning

An LLM is trained to predict the next token of an input sequence, but which next token? A model that helps doctors explain a patient's diagnosis should continue in medical jargon; a model trained for financial operations should think in financial terms. The next token a model produces is not always the general-purpose one — sometimes you need it to behave in a specific way.

The process works in two stages. First you train a base model in a self-supervised fashion on large amounts of text. Then you take that model and run it through a series of curated questions and answers. That second step is fine-tuning.

Consider the question "Who is the president of the USA?" The model might answer directly — or it might say, "I would like to know that too," which is a failure mode. The model should either give a direct answer or confess that it does not know. Refusals are also bad, because models are trained to be helpful. So fine-tuning penalizes responses that are plausible and not strictly wrong but undesirable, and the model's internal weights are updated until it reliably answers as expected. For medical diagnosis, the weights adapt until the model speaks in medical jargon; for another domain, the same procedure teaches the vocabulary and tone of that domain. One base model can be fine-tuned by many different companies, each running it through its own question-answer sets to serve its own customers' queries.

8. Few-Shot Prompting

Fine-tuning changes the model; few-shot prompting changes the request. The idea is simple: before you send a plain, vanilla query to a large language model, you augment it with examples of how it should respond.

Suppose the customer query is "Where is my parcel?" You do not send that sentence alone. Your server also sends a handful of example query–response pairs showing the model the kind of answer you want, so the model can take them into context and shape its response accordingly. This all happens at inference time, in production, while the user waits — no training, no weight updates.

The quality of the response goes up noticeably. Few-shot prompting is essentially example prompting: examples in the prompt. It is one of the cheapest and most reliable ways to steer an LLM's output format and tone.

9. Retrieval-Augmented Generation

Few-shot prompting supplies examples of how to respond, but where does the model get the information it needs? When a customer hits your API, your server can fetch the documents that are relevant to the query — company policies, terms and conditions for placing an order, and more — and send them to the LLM in real time, alongside the examples and the user's original query. The examples teach the format of a good response; the documents provide company-specific context; the query carries the user's actual intent. With all three, the large language model tends to give very high-quality responses.

This is retrieval-augmented generation (RAG): you retrieve the relevant context, augment the query with it, and then generate the response. The field is moving so quickly that commentators already say "RAG is dead" — but the underlying pattern remains central to building grounded applications.

Where do the documents come from, and how does the server know which ones match a query? Ask a graph database company like Neo4j and you will be told to store everything in a graph database; ask a database vendor and you will be told to use a vector database; others will say to keep everything in memory or cache. The choice of how you fetch documents matters less than the pattern itself. In practice it is usually a vector database, because finding relevant documents there is just a similarity search. Once the documents are retrieved they are passed to the LLM, which converts them internally into vectors and generates the response.

10. Vector Databases

A vector database is what you use to find relevant documents for an incoming query, and it works because vectors capture semantic meaning.

Take a customer request: "I am upset with your payment system. I expect a refund." A human reads that and understands the user's feeling instantly. But which documents should the system search? Your company policy may never contain the word "upset." It may, however, contain documents about what to do when a user gives a low rating or drops off. How does the system know that "upset" is close in meaning to "low rating" or "drop-off"? Through vectors: documents containing similar words are stored close to each other in the vector space, so the distance between the query vector for "upset" and documents about low ratings is small. Those documents get fetched, and their content is added to the LLM's context along with the original user query and a system prompt.

The documents are stored in a vector database precisely because it makes these similarity searches efficient, using algorithms such as hierarchical navigable small world (HNSW) graphs. To the application engineer, the vector database is mostly a black box: store documents in it, and when a query arrives, quickly retrieve the ones closest to it.

11. Model Context Protocol

Vector databases handle context that lives inside your system — internal documents, policies, knowledge. But what if the context the model needs exists outside your system entirely? That challenge is met by the Model Context Protocol (MCP), a standardized protocol, a way of communicating — transferring context into a model from the outside world.

Here is the flow. A user's query reaches your server, which runs an MCP client. The client forwards the query to the LLM. The LLM decides that it needs external tools or databases to answer well, and the client learns of this and connects to external MCP servers. Think of an MCP server as a wrapper around another company's database: one airline's MCP server can give flight details for that airline; another server wraps a second airline's data. Real-time flight information comes back and is forwarded to the LLM, which now has the user query, whatever internal context your vector database contributed, and live data from external servers — all of it available for decision-making.

The LLM might then decide: book flight number IndiGo 1020. That decision triggers another API call through the MCP server to actually make the booking. The final response travels back to the MCP client, which forwards it to the user — resulting in a happy customer. Notice what changed: the user no longer has to take the recipe the model gives and execute it themselves. The entire recipe can be executed by the MCP client on their behalf. This makes LLMs dramatically more powerful, which is why MCP has gained popularity so quickly.

12. Context Engineering

Put all of the recent techniques together and you get context engineering, a term most working engineers have heard. It is an umbrella over much of what this video covers: few-shot prompting (adding examples), retrieval-augmented generation (pulling relevant documents from a vector database to add context to a query), and MCP (reaching external servers and performing actions). As engineers build these systems, two new challenges emerge: user preferences and context summarization.

The first challenge is that different users have different preferences, and the context should reflect them. The second is scale — you cannot keep sending every message ever exchanged. A common solution is a sliding window: the last hundred chats are sent verbatim to the LLM, while everything older is summarized into about five sentences, capping the input size. Other techniques focus on keywords, or send just the most recent chat together with a summary of the entire earlier history. Documents get the same treatment: summarize first, then send. Summarization can be delegated to a cheap small language model or a distilled model, reserving the expensive large model for the final generation over the compact, high-value context.

This is the key difference from prompt engineering. Prompt engineering concerns a single, stateless prompt: whenever you ask the LLM to behave in a particular way, the same system prompt is applied. Context engineering is long-term and dynamic — it evolves according to the user's declared preferences and the previous chat history, adapting what the model sees over time.

13. Agents

The most long-term construct in the AI space right now is the agent: a long-running process — think of a server that receives API calls — with many capabilities. An agent can query an LLM, query external systems, and query other agents, all to meet the user's requirements. Where an MCP client executes a single recipe, an agent keeps working over time.

Consider a travel agent built this way. It can look into booking flights, book hotels, and even manage your email while you are away. When it spots a window of opportunity — flights have suddenly become cheap — it goes ahead and makes the booking according to your preferences, no prompting required. All of this is managed by the agent autonomously over an extended period.

14. Reinforcement Learning and RLHF

Reinforcement learning is one of the most hyped terms in the space, and at heart it is a way to train models to behave in a particular way. Give a model a user query and let it generate two responses. Anyone who has used a chat product has seen this pattern: both answers are shown, and a human picks the better one. The chosen response gets a plus one; the other gets a minus one.

To see why that simple signal works, think in vector space. The query maps to a coordinate, a vector in n-dimensional space. From that starting point the model generates tokens, and each token is a step through the space — the response is a path. When a response earns a plus one, every step along its path earns positive credit; you have found a nice path and you always want to follow it. When a response is bad, its path wanders into a region where the tokens receive negative scores. (Real implementations may also discount rewards along the way, but the intuition stands.) Do this enough times and you build up a landscape of the vector space: negative regions you do not want to enter, neutral regions, and positive regions — the more positive a region, the more you want to steer generation toward it. Generating a response becomes a kind of hill-climbing, optimizing the path the LLM takes. Since the human chose the better response, the expectation is that the final result will make the end user happy — and the model is trained to do exactly that.

This is reinforcement learning with human feedback (RLHF): the human's plus-one or minus-one is feedback that reinforces good outputs. It is an extremely powerful technique and it exists in nature. Pavlov's dog is the classic case: ring a bell, give the dog food, and repeat; eventually the dog salivates at the bell alone, because it expects food. Its behavior has been reinforced.

Powerful as it is, reinforcement learning is not sufficient to model human intelligence. Take a fair coin that keeps coming up heads — heads, heads, heads, heads. An RL agent observes the real world and decides based on outcomes: predicting heads keeps getting reinforced, predicting tails gets punished, so it keeps predicting heads. But a human who is told the coin is fair says 50/50, because they carry an internal representation — a mental model of how a fair coin's physics works. Reinforcement learning cannot build such mental models; it can only infer from outcomes which path is more likely to be beneficial. Humans are not limited to outcome-based learning, and that deeper understanding of how things work is a real advantage. Even so, reinforcement learning remains a powerful technique that genuinely makes models smarter.

15. Chain of Thought

Chain of thought is a simple concept with an outsize effect. During training, the model is shown problems solved step by step, with the thought process made explicit. The expectation is that a model trained to break problems into steps will apply the same habit to new problems with different parameters: because it has been trained to reason step by step, it will reason through anything.

The result is a response built from a series of deductions or inferences, and its quality is usually much higher than a direct, one-shot answer. This resembles few-shot prompting — the model has examples to follow and quality improves — but the key difference is the step-by-step breakdown, and crucially, the model can add new steps as it sees fit. Trained on so much data, it may insert additional reasoning steps as a problem gets harder. This behavior has been observed in practice with DeepSeek: make the problem harder and the model takes more steps; make it easy and it takes fewer.

16. Reasoning Models

A model that can reason — that can look at a problem and figure out how to solve it step by step — is a reasoning model, sometimes abbreviated as an LRM (large reasoning model). Chain of thought is one technique these models use, but not the only one. There is also tree of thought, which explores multiple lines of reasoning in parallel, graph of thought, and tool use — calling external tools to strengthen the reasoning. What defines the category is the capability, not the algorithm: given a problem, the model decides how to decompose and solve it. Well-known examples include DeepSeek's reasoning models and OpenAI's o1 and o3 series.

17. Multimodal Models

Most large language models operate on text, but a growing class of models accepts and creates other modalities. Multimodal models can analyze an image — counting the apples in a photograph, say — or modify an image to create a new one, and the same applies to video.

The applications are enormous. Large language models already changed marketing for textual content; social media is now full of LLM-generated copy. Images will keep getting better, and video could be an even bigger deal: if celebrities can generate video advertisements through these models, the cost expectations for creating video will drop. This is already happening to some extent, though the quality of the models is not yet very good.

There is also a surprising quality benefit. Multimodal training — any kind of input mode combined with text — tends to produce models that perform better than models trained on text alone. Train a model on words like "cat" and "feline," then also show it images of cats, and the model's output quality improves, because it has a deeper understanding of the meaning of objects, not just their names.

18. Small Language Models and Foundation Models

Where is the field heading? Increasingly, toward smaller, more company-specific models — small language models (SLMs) and domain-specific foundation models. The drivers are control and privacy: companies want control over what their models generate, and they want to keep their data close rather than exposing it to a third-party company.

The size difference is stark. A small language model may have 3 million to 300 million parameters — a compact neural network with few connections and weights — while a large language model ranges from 3 billion to 300 billion parameters. The smaller models are trained on less data, and that data can be company-specific or task-specific. A bot trained only on customer queries, complaint handling, and sales technique is likely to perform decently well as an expert at sales — but it probably cannot give you a detailed weather analysis. For most companies, that tradeoff does not matter; for NASA, the priorities are reversed. NASA would rather build a foundation model that predicts the weather well and never bothers with sales. So companies are training smaller models on their proprietary data to get reasonably good, cheap responses for specific use cases.

19. Distillation

The process by which small language models are usually built is distillation, a teacher–student arrangement. You take a large language model — the teacher — and pass it some input. In parallel, you send the same input to a small language model — the student — with its far fewer parameters. Both try to predict the output. If the student's output matches the teacher's, it is doing well and no weights change. If it is not doing well, the student's internal weights are updated — all within its limited budget of 3 to 300 million parameters.

What you are doing is condensing the complex teacher network into the most reasonable representation that fits in the student, such that performance stays acceptable while costs drop significantly. During production inference, the distilled model responds much faster than the large one and is easier to host.

20. Quantization

The last term worth knowing is quantization, a technique aimed at the weights themselves. Every weight in a neural network is a number — say, a 32-bit number. What if you could condense that information into 8 bits? Roughly 75% of the memory taken up by the weights is expected to be saved.

The savings do not map one-to-one, for two reasons. Quantization is usually applied to the weights of the feedforward networks while the attention mechanism remains in full precision, and the training cost is unchanged: you first train a genuinely good model with no quantization, and only once it is completely trained do you quantize it. Quantization therefore does not reduce the cost of training; it reduces the inference cost — the cost of running the model in production.

That completes the set of twenty terms that engineers in the AI space actually use, and knowing them helps you communicate with any other engineer or team member. No single video can fully unpack every subject — the attention mechanism alone could occupy a much longer course — but these are the words you should know, and most of them recur in depth in any serious study of how these models work. The payoff is clarity: once you truly understand the terms, much of the hype and nonsense circulating in the AI space becomes recognizable for what it is.

Key Takeaways

Source

Diagrams

flowchart TD
    A["Input text: All that glitters is not gold"] --> B["Tokenization splits text into tokens"]
    B --> C["Each token maps to a vector in space"]
    C --> D["Meaning becomes a coordinate; similar words sit close"]
    D --> E["A single word stays ambiguous: 'apple'"]
    E --> F["Attention looks at the surrounding words"]
    F --> G["Context 'revenue' pushes 'apple' toward companies"]
    F --> H["Context 'tasty' pushes 'apple' toward fruits"]
    G --> I["The context-aware vector is now precise"]
    H --> I
    I --> J["The model predicts the next token"]
    J --> K["Output grows one token at a time"]
Source
flowchart TD
    A["Input text: All that glitters is not gold"] --> B["Tokenization splits text into tokens"]
    B --> C["Each token maps to a vector in space"]
    C --> D["Meaning becomes a coordinate; similar words sit close"]
    D --> E["A single word stays ambiguous: 'apple'"]
    E --> F["Attention looks at the surrounding words"]
    F --> G["Context 'revenue' pushes 'apple' toward companies"]
    F --> H["Context 'tasty' pushes 'apple' toward fruits"]
    G --> I["The context-aware vector is now precise"]
    H --> I
    I --> J["The model predicts the next token"]
    J --> K["Output grows one token at a time"]
1. From Text to Next Token: How an LLM Reads
flowchart TD
    A["Collect text that already exists on the web"] --> B["No human labels required"]
    B --> C["Blank out a piece of each input"]
    C --> D["Puzzle 1: predict the token after 'Et'"]
    C --> E["Puzzle 2: predict the token after 'Et tu'"]
    C --> F["Puzzle 3: predict the token after 'Et tu, Brute'"]
    D --> G["The model writes its best guess"]
    E --> G
    F --> G
    G --> H{"Is the guess correct?"}
    H -- "Yes" --> I["Weights stay unchanged"]
    H -- "No: loss rises" --> J["Weights update to lower the loss"]
    I --> K["The same weights improve across endless puzzles"]
    J --> K
Source
flowchart TD
    A["Collect text that already exists on the web"] --> B["No human labels required"]
    B --> C["Blank out a piece of each input"]
    C --> D["Puzzle 1: predict the token after 'Et'"]
    C --> E["Puzzle 2: predict the token after 'Et tu'"]
    C --> F["Puzzle 3: predict the token after 'Et tu, Brute'"]
    D --> G["The model writes its best guess"]
    E --> G
    F --> G
    G --> H{"Is the guess correct?"}
    H -- "Yes" --> I["Weights stay unchanged"]
    H -- "No: loss rises" --> J["Weights update to lower the loss"]
    I --> K["The same weights improve across endless puzzles"]
    J --> K
2. Self-Supervised Learning: Training Without Labels
flowchart TD
    A["Input tokens enter the stack"] --> B
    subgraph ENG["Transformer: the engine"]
        B["Attention layer: pull context from nearby words"] --> C["Feedforward layer: refine each vector"]
        C --> D["Another attention layer"]
        D --> E["Another feedforward layer"]
        E --> F["Many layers stacked on top of one another"]
    end
    B -. "Early layers" .-> S1["Disambiguate: 'crane' becomes the bird"]
    E -. "Later layers" .-> S2["Infer more: the crab is fearful"]
    F --> G["Meaning is manipulated again and again"]
    G --> H["The model is ready to emit the next token"]
    H --> I["The LLM is the car; the transformer is its engine"]
Source
flowchart TD
    A["Input tokens enter the stack"] --> B
    subgraph ENG["Transformer: the engine"]
        B["Attention layer: pull context from nearby words"] --> C["Feedforward layer: refine each vector"]
        C --> D["Another attention layer"]
        D --> E["Another feedforward layer"]
        E --> F["Many layers stacked on top of one another"]
    end
    B -. "Early layers" .-> S1["Disambiguate: 'crane' becomes the bird"]
    E -. "Later layers" .-> S2["Infer more: the crab is fearful"]
    F --> G["Meaning is manipulated again and again"]
    G --> H["The model is ready to emit the next token"]
    H --> I["The LLM is the car; the transformer is its engine"]
3. The Transformer Stack: The Engine Inside the LLM
flowchart TD
    A["Customer query: Where is my parcel?"] --> B["Your server receives the query"]
    B --> C["Query is embedded into a vector"]
    C --> D["Similarity search runs over the vector DB"]
    D --> E["Closest documents are fetched: policies and terms"]
    C -. "Semantic match, not keywords" .-> N1["'Upset' sits close to 'low rating' documents"]
    E --> F["Documents join the prompt"]
    B --> G["Few-shot examples shape the response format"]
    F --> H["LLM receives query, examples, and documents"]
    G --> H
    H --> I["High-quality grounded answer"]
    I --> J["Response returns to the customer"]
Source
flowchart TD
    A["Customer query: Where is my parcel?"] --> B["Your server receives the query"]
    B --> C["Query is embedded into a vector"]
    C --> D["Similarity search runs over the vector DB"]
    D --> E["Closest documents are fetched: policies and terms"]
    C -. "Semantic match, not keywords" .-> N1["'Upset' sits close to 'low rating' documents"]
    E --> F["Documents join the prompt"]
    B --> G["Few-shot examples shape the response format"]
    F --> H["LLM receives query, examples, and documents"]
    G --> H
    H --> I["High-quality grounded answer"]
    I --> J["Response returns to the customer"]
4. RAG: Retrieving Context Before Generating
sequenceDiagram
    participant U as User
    participant S as Server with MCP client
    participant L as LLM
    participant M as MCP server
    participant A as Airline API

    U->>S: Ask to book a flight
    S->>L: Forward the user query
    L->>S: Decides external data is needed
    S->>M: Connect through the MCP client
    M->>A: Fetch real-time flight details
    A-->>M: Return flight data
    M-->>S: External context arrives
    S->>L: Send query with internal and live context
    L->>S: Decision: book flight IndiGo 1020
    S->>M: Call the booking API through MCP
    M->>A: Reserve the flight
    A-->>M: Booking confirmed
    M-->>S: Confirmation returned
    Note over U,S: The MCP client executes the whole recipe on behalf of the user
    S-->>U: Final response delivered
Source
sequenceDiagram
    participant U as User
    participant S as Server with MCP client
    participant L as LLM
    participant M as MCP server
    participant A as Airline API

    U->>S: Ask to book a flight
    S->>L: Forward the user query
    L->>S: Decides external data is needed
    S->>M: Connect through the MCP client
    M->>A: Fetch real-time flight details
    A-->>M: Return flight data
    M-->>S: External context arrives
    S->>L: Send query with internal and live context
    L->>S: Decision: book flight IndiGo 1020
    S->>M: Call the booking API through MCP
    M->>A: Reserve the flight
    A-->>M: Booking confirmed
    M-->>S: Confirmation returned
    Note over U,S: The MCP client executes the whole recipe on behalf of the user
    S-->>U: Final response delivered
5. MCP: From User Query to Completed Booking
flowchart TD
    A["User query arrives"] --> B["Model drafts response 1"]
    A --> C["Model drafts response 2"]
    B --> D["Human picks the better response"]
    C --> D
    D --> E["Chosen path is marked plus one"]
    D --> F["Other path is marked minus one"]
    E --> G["Every token step on the good path gains credit"]
    F --> H["Every token step on the bad path is penalized"]
    G --> I["The vector space is reshaped over many rounds"]
    H --> I
    I --> J["Positive, neutral, and negative regions emerge"]
    J --> K["Generation steers toward positive regions"]
    K --> L["RLHF: human feedback reinforces good outputs"]
    K -. "Limit" .-> M["RL infers from outcomes only; a fair coin stays 50/50 for humans"]
Source
flowchart TD
    A["User query arrives"] --> B["Model drafts response 1"]
    A --> C["Model drafts response 2"]
    B --> D["Human picks the better response"]
    C --> D
    D --> E["Chosen path is marked plus one"]
    D --> F["Other path is marked minus one"]
    E --> G["Every token step on the good path gains credit"]
    F --> H["Every token step on the bad path is penalized"]
    G --> I["The vector space is reshaped over many rounds"]
    H --> I
    I --> J["Positive, neutral, and negative regions emerge"]
    J --> K["Generation steers toward positive regions"]
    K --> L["RLHF: human feedback reinforces good outputs"]
    K -. "Limit" .-> M["RL infers from outcomes only; a fair coin stays 50/50 for humans"]
6. RLHF: Rewarding the Better Path