DEV Community: Priyanka-Chettri

You Typed a Prompt. What Happens Next?

Priyanka-Chettri — Thu, 27 Aug 2026 11:38:42 +0000

You open a chat window and type:

The mole on my face may need a biopsy. Explain this simply.

Then you press Send.

A few moments later, an answer begins appearing on your screen.

What happened between those two moments?

The model did not search a dictionary for the meaning of every word. It did not read the prompt exactly as a person would. It also did not write the complete answer internally and reveal it all at once.

Instead, your prompt went through a pipeline:

messages → tokens → embeddings → Transformer layers
         → logits → probabilities → one new token
         → repeat until finished

Let us follow this one prompt through that journey.

Before we begin: training has already happened

Everything in this article happens during inference—the stage where an already-trained model responds to an input.

The model’s weights, embedding matrix, attention projections, and output matrix were learned earlier during training. They normally remain fixed while your request is being answered.

Your prompt affects temporary calculations inside the model. It does not immediately retrain the model or permanently rewrite its weights.

With that out of the way, let us press Send.

Step 1: Your prompt joins the conversation

You see only the message you typed, but a chat application usually manages a list of messages with roles:

System: You are a helpful assistant.
User: The mole on my face may need a biopsy. Explain this simply.
Assistant:

If this is an ongoing conversation, earlier messages may also be included. An application may additionally provide retrieved documents, tool results, or other instructions.

The model does not intrinsically understand JavaScript-like objects containing role and content. Before inference, a chat template converts the messages into one sequence, using special control tokens to identify message boundaries and roles.

A simplified sequence might resemble:

<system>
You are a helpful assistant.
</system>
<user>
The mole on my face may need a biopsy. Explain this simply.
</user>
<assistant>

The exact control tokens differ between model families. Hugging Face’s chat-template documentation makes the central point clearly: even a chat model ultimately receives and continues a sequence of tokens.

The final <assistant> marker tells a chat-tuned model that an assistant response should come next.

Step 2: The tokenizer breaks the sequence into tokens

The model cannot process the raw string directly. A tokenizer converts it into smaller text units called tokens.

Tokens are not always complete words. Depending on the tokenizer, the sequence might be divided approximately like this:

The | mole | on | my | face | may | need | a | bio | psy | .
Explain | this | simply | .

That split is only illustrative. A real tokenizer may split the same text differently.

Tokens can represent:

complete words;
parts of words;
punctuation;
spaces or space-prefixed pieces;
bytes or characters;
special control markers.

Every token belongs to the tokenizer’s fixed vocabulary and has an integer ID:

"The"     → 791
"mole"    → 17342
"face"    → 3234
"biopsy"  → 48291

These numbers are illustrative too.

The vocabulary is not a dictionary. It does not store definitions such as:

mole → a mark on the skin

It stores a mapping closer to:

text piece → token ID

Subword methods such as BPE, WordPiece, and Unigram allow a limited vocabulary to represent a much larger range of text. The Hugging Face tokenizer guide compares these approaches.

At the end of this step, the application has a sequence of IDs:

[system-token, 1639, 389, ..., user-token, 791, 17342, ..., assistant-token]

The token IDs themselves do not contain useful semantic meaning. They are indexes telling the model which rows to retrieve next.

Step 3: Token IDs become embeddings

Inside the model is a learned table called the embedding matrix.

It contains one starting vector for every vocabulary token:

Token	Starting embedding
`mole`	`[0.18, -0.42, 0.71, ...]`
`face`	`[-0.14, 0.63, 0.27, ...]`
`biopsy`	`[0.51, 0.09, -0.32, ...]`

If the vocabulary contains V tokens and the model’s hidden size is d, the embedding matrix has the shape:

V × d

For example, a model could have 50,000 vocabulary tokens and vectors containing 4,096 values.

When the tokenizer produces the ID for mole, the model retrieves the corresponding row from this table.

token "mole"
      ↓
token ID
      ↓
row in embedding matrix
      ↓
starting vector

This is why it is called an embedding: a discrete token is placed into a continuous, high-dimensional numerical space.

But `mole` can have several meanings

The embedding matrix still contains only one starting vector for the token mole, even though the word can mean:

an animal;
a mark on the skin;
a spy.

That stored vector is only the starting point. Context will be incorporated as the sequence passes through the Transformer.

The stored row itself is not rewritten for this prompt. The model creates new temporary hidden states during the forward pass.

Step 4: The model adds positional information

The sequences below contain the same words but do not mean the same thing:

dog bites man
man bites dog

The model therefore needs information about where each token occurs.

Different Transformer families represent position differently. The original Transformer added sinusoidal positional encodings, while later models may use learned, relative, or rotary position techniques.

The exact technique is less important for this mental model than its purpose:

Every token enters the Transformer with information about both its identity and its position.

Step 5: The prompt enters the prefill phase

Inference for a decoder-only LLM is often easier to understand as two phases:

Prefill: process the prompt that already exists.
Decode: generate new tokens one at a time.

During prefill, the model processes the prompt tokens through all its Transformer layers. Because all prompt tokens are already known, their calculations can be performed largely in parallel.

However, the model still uses a causal mask. A position may use only itself and earlier positions.

Position 1 can see: 1
Position 2 can see: 1, 2
Position 3 can see: 1, 2, 3
...
Final prompt position can see: the complete prompt before it

This creates an important correction to a common explanation.

Does the `mole` token look ahead at `face` and change its meaning?

Not in a decoder-only model if face appears after mole.

At the mole position, causal attention prevents the model from seeing future tokens such as face and biopsy. Its hidden state is not later rewritten by those future words.

Instead, later positions can see mole:

"mole" position   → can see "The mole"
"face" position   → can see "The mole on my face"
"biopsy" position → can see everything before and including "biopsy"
final position     → can see the complete prompt

The final prompt position therefore contains a representation built from the entire preceding prompt. That is the position used to predict the first response token.

In an encoder-only model such as BERT, attention can be bidirectional, so the mole position itself can attend to words on both sides. That is not how causal attention in a GPT-style decoder works.

Step 6: Attention lets positions retrieve relevant context

Every Transformer layer creates three projections from each current hidden state:

Query: what information is this position looking for?
Key: what kind of information does this position offer?
Value: what information should this position contribute if selected?

The model compares a query with the keys of the visible positions. After scaling, masking, and softmax, those comparisons become attention weights. The output is a weighted combination of the value vectors.

The original Transformer expresses this as:

Attention(Q, K, V) = softmax(QKᵀ / √dk) V

This mechanism comes from Attention Is All You Need.

For the final prompt position, different attention heads may retrieve information connected to:

mole, face, and biopsy for the topic;
explain for the requested action;
simply for the desired style;
earlier system instructions for the expected behaviour.

Attention does not search through every token in the model’s vocabulary. It operates over the token representations in the available sequence.

It is also not literal, permanent memory. A better description is:

Attention is a context-dependent information-routing mechanism.

Step 7: The representations pass through many layers

A Transformer layer contains more than attention. A simplified decoder block includes:

hidden states
    ↓
normalization
    ↓
masked self-attention
    ↓
residual connection
    ↓
normalization
    ↓
feed-forward network / MLP
    ↓
residual connection

The precise ordering varies between model architectures.

Attention moves and combines information across token positions. The feed-forward network performs additional learned processing at each position. Residual connections preserve information across deep stacks, and normalization helps keep computation stable.

This block is repeated many times.

Therefore, a token position does not have only one vector throughout the model. It has:

starting embedding
      ↓
hidden state after layer 1
      ↓
hidden state after layer 2
      ↓
...
      ↓
final hidden state

These hidden states exist temporarily for this inference request. Hugging Face models can expose the initial embedding output and the hidden states produced by individual layers, as shown in the GPT-2 model documentation.

Step 8: The last prompt position becomes the prediction point

After prefill passes through the final Transformer layer, the model has a final hidden state for every prompt position.

The important one for generation is the final input position—often the last token of an assistant-generation marker added by the chat template.

Why that position?

Because in a causal model it can access everything before it:

system instructions
+ conversation history
+ the current user prompt
+ the fact that an assistant response should begin

Its final hidden vector is a compressed, context-dependent representation used to answer:

Given everything before this point, which token should come next?

The model does not need to turn this vector into a human-readable summary first. It sends it directly to the output layer.

Step 9: The unembedding matrix produces logits

At the beginning, the embedding matrix performed this operation:

token ID → hidden-sized vector

Now the model needs the opposite direction:

final hidden vector → one score for every vocabulary token

A learned output projection performs this operation:

logits = final hidden state × output matrix + bias

This output projection is often called the:

language-model head;
LM head;
output projection;
or informally, the unembedding matrix.

If the hidden size is d and vocabulary size is V, its conceptual shape is:

d × V

Some models reuse the transpose of the input embedding matrix here. This is called weight tying. Other models use separate parameters.

For our prompt, the output might contain illustrative scores like:

Candidate next token	Logit
`It`	9.1
`A`	8.4
`This`	7.9
`Banana`	-3.2

A logit is a raw, unnormalized score. It is not yet a probability.

The output layer produces a score for every vocabulary token. This is the first point in this journey where the complete output vocabulary is considered at once.

Step 10: Logits become a probability distribution

Before selecting a token, the inference system may adjust the logits. The precise implementation varies, but temperature and repetition penalties are commonly applied before or as part of building the sampling distribution.

Temperature

Temperature controls how sharp the probability distribution becomes:

lower temperature makes high-scoring tokens more dominant;
higher temperature gives lower-scoring alternatives more opportunity.

Temperature does not add knowledge or creativity to the model. It changes the randomness of token selection.

Presence and frequency penalties

Some APIs expose repetition controls:

a presence penalty reacts to whether a token has appeared;
a frequency penalty reacts to how often it has appeared.

These controls normally make repetition less likely. They do not guarantee that a previous token will never appear again, and they do not update the model’s training data.

Softmax transforms logits into a probability distribution that adds up to 1:

Candidate	Illustrative probability
`It`	52%
`A`	27%
`This`	17%
Other tokens	4%

Step 11: A decoding strategy chooses one token

The system now chooses a token according to its decoding strategy.

Greedy decoding selects the highest-probability token.
Sampling selects from a probability distribution instead of always taking the maximum.

Two common sampling controls limit the candidate set:

Top-k keeps the k highest-probability candidates.
Top-p keeps the smallest group of candidates whose cumulative probability reaches a threshold.

After filtering, the remaining probabilities are normalized for sampling. Exact processing order and formulas are implementation-specific. Hugging Face documents temperature, top-k, and top-p in its text-generation guide.

Suppose the selected token is:

It

The model has generated exactly one token—not the full answer.

Step 12: The selected token is appended

The sequence now looks conceptually like this:

<system> ... </system>
<user> The mole on my face may need a biopsy. Explain this simply. </user>
<assistant> It

Now the model must predict the token after It.

The generated token receives its embedding and positional information, passes through the Transformer layers, produces another final hidden state, and is projected into a new set of vocabulary logits.

Perhaps the next token is means:

It → means

Then the model runs again:

It → means → your → doctor → wants → ...

This is why decoder-only generation is autoregressive: every generated token becomes part of the input used to generate the following token.

Step 13: The KV cache prevents wasteful repetition

If the model recalculated every earlier prompt token from scratch after generating each new token, generation would be extremely wasteful.

Attention uses key and value vectors for previous positions. During prefill, the system stores those vectors in a KV cache.

During decoding:

Generate "It"
  → reuse cached K/V for the prompt
  → store K/V for "It"

Generate "means"
  → reuse cached K/V for prompt + "It"
  → store K/V for "means"

The model still calculates the new token’s query, key, value, and subsequent layer operations. It simply avoids recalculating the stored keys and values for the previous sequence.

The cache therefore trades memory for speed. It grows as more tokens are stored, although sliding-window and other attention designs may limit that growth.

A KV cache does not automatically give the model a larger context window. It makes generation within the supported context more efficient. Hugging Face’s KV-cache guide describes this reuse and the available speed-versus-memory strategies.

Step 14: Tokens are decoded and streamed to your screen

The model generates token IDs. The tokenizer’s decoding process converts those IDs back into readable text.

[2181, 3445, 701, ...]
        ↓
"It means your..."

Applications often stream decoded text as tokens or small groups of tokens become available. That is why you see the response appear gradually instead of waiting for the entire paragraph.

Tokenizer decoding should not be confused with a Transformer decoder. The names are similar, but they refer to different operations:

tokenizer decoding: token IDs → text;
Transformer decoder: causally processes token representations and generates subsequent tokens.

Step 15: The model eventually stops

The generation loop continues until a stopping condition occurs. Common conditions include:

the model generates an end-of-sequence or end-of-message token;
the system encounters a configured stop sequence;
the maximum output-token limit is reached;
the application stops generation for another reason.

The final generated sequence is decoded, and you see the completed response.

Where does the context window fit?

Everything sent to the model must fit within its supported context budget. Depending on the application, that can include:

system instructions
+ conversation history
+ retrieved documents
+ tool results
+ current prompt
+ generated response

The context window is not permanent memory. It is the amount of tokenized information available to the model for this inference sequence.

If information is not present in the current context—and is not recovered by an external retrieval or memory system—the model cannot directly attend to it.

The context window also should not be confused with the KV cache:

Concept	Purpose
Context window	Limits how much tokenized sequence the model can process
KV cache	Stores previous attention keys and values to speed up decoding

What did not happen?

Several tempting explanations are slightly wrong.

The model did not fetch definitions from a dictionary

The tokenizer vocabulary maps text pieces to IDs. Learned meaning is distributed across embeddings and the model’s other parameters.

The model did not permanently modify the `mole` embedding

It retrieved the stored starting embedding and created temporary hidden states while processing this request.

In a decoder-only model, `mole` did not look ahead at `face`

Causal attention blocks future positions. Later positions combined the earlier mole token with face, biopsy, and the rest of the prompt.

Attention did not compare the prompt against the complete vocabulary

Attention combined visible sequence representations. The LM head later produced logits for the full output vocabulary.

The model did not generate the complete answer in one operation

It generated one token, appended it, and repeated the process.

The KV cache did not increase the context window

It reused earlier key and value tensors so they did not need to be recomputed.

The model did not train itself on your message while answering

Ordinary inference uses fixed trained parameters. Your message influences temporary activations and the current output.

The entire journey in one view

1. You press Send.

2. The application assembles the conversation:
   system instructions + history + current prompt + assistant marker

3. A chat template converts the messages into one model-specific sequence.

4. The tokenizer converts text pieces into token IDs.

5. The embedding matrix converts every ID into a starting vector.

6. Positional information tells the model where each token occurs.

7. During prefill, causal Transformer layers process the prompt and build
   temporary hidden states and a KV cache.

8. The final prompt position contains information gathered from the complete
   preceding prompt.

9. The LM head / unembedding matrix converts that final hidden state into
   one logit for every vocabulary token.

10. Temperature or repetition controls may adjust the logits, and softmax
    converts them into probabilities.

11. A decoding strategy may filter the candidates and selects one token.

12. The new token is appended to the sequence.

13. During decoding, cached keys and values are reused while one new token is
    processed at a time.

14. The tokenizer converts generated token IDs back into text, which may be
    streamed to your screen.

15. Generation ends when a stopping condition is reached.

The shortest accurate explanation is:

When you send a prompt, an LLM converts it into token vectors, processes those vectors through causally masked Transformer layers, uses the final prompt position to score every possible next token, selects one, appends it, and repeats—reusing cached attention information—until the response is complete.

Sources and further reading

Whenever the terminology becomes overwhelming, return to this smaller loop:

prompt → tokens → temporary representations → next-token probabilities
       → selected token → repeat

That loop is the heart of decoder-only LLM inference.

From Neural Networks to LLMs: The Mental Model I Was Missing

Priyanka-Chettri — Sun, 16 Aug 2026 11:30:08 +0000

Before jumping into APIs, RAG, agents, and AI applications, I wanted to understand what actually happens inside an LLM.

I kept coming across terms like neural networks, deep learning, Transformers, attention, tokens, embeddings, BERT, GPT, and causal language modeling — but they all felt like disconnected pieces.

I could understand each concept individually, but I didn't have a clear picture of how they all connected.

So I decided to step back and build the mental model from the ground up.

This article is my attempt to connect those pieces.

1. Starting With Neural Networks

Before understanding LLMs, it helps to understand where they come from.

A neural network is a machine learning model that learns patterns from data.

For example, suppose we want to recognize handwritten digits.

We could give a neural network thousands of images of handwritten digits:

Images of handwritten digits
            ↓
      Neural Network
            ↓
     Learned patterns
            ↓
        Prediction

Instead of manually programming rules such as:

"If the image has this curve and this line, it must be a 3."

we allow the neural network to learn those patterns from examples.

The things the network learns are stored in its parameters, primarily weights and biases.

As we increase the number of layers in a neural network, we enter the world of deep learning.

Machine Learning
       ↓
Neural Networks
       ↓
Deep Learning

Different neural network architectures became useful for different types of problems.

For example:

CNNs became popular for image-related tasks.
RNNs and LSTMs were commonly used for sequential data such as language.
Transformers later became extremely important for language and many other sequence-based tasks.

But language has a special challenge.

Context matters

Consider:

"The animal didn't cross the road because it was tired."

To understand what "it" refers to, we need to understand its relationship with the other words in the sentence.

This is where things like attention become important.

And this eventually leads us to Transformers.

2. Why Did Transformers Come Into the Picture?

Before Transformers, RNNs and LSTMs were commonly used for language-related tasks.

They processed sequences step by step.

For example:

I → love → machine → learning

This sequential processing created some challenges.

One major problem was that it made training difficult to parallelize efficiently.

It could also become difficult to capture relationships between tokens that were far apart in a long sequence.

Then, in 2017, researchers introduced the Transformer architecture in the paper:

"Attention Is All You Need"

The original Transformer was designed for machine translation.

The basic architecture looked like this:

English sentence
       ↓
    Encoder
       ↓
Contextual representation
       ↓
    Decoder
       ↓
French sentence

For example:

"I love cats"
      ↓
   Transformer
      ↓
"J'aime les chats"

The key idea that made Transformers different was attention.

Instead of processing a sequence strictly one step at a time, the Transformer could use attention to determine relationships between different tokens.

This made it much better suited to capturing context and also allowed much more parallel computation during training.

3. Attention: The Key Idea

At a high level, attention answers:

"When I'm processing this token, which other tokens should I pay attention to?"

Consider:

"The animal didn't cross the road because it was tired."

When processing "it", the model needs to determine which other tokens are relevant.

Conceptually:

The animal didn't cross the road because it was tired.
                                      ↑
                                     "it"

The model can assign different levels of importance to different tokens.

This is called self-attention, because tokens in the sequence attend to other tokens in the same sequence.

I initially thought attention was something separate from the Transformer.

It isn't.

Attention is one of the core mechanisms inside a Transformer.

For now, the mental model I use is:

Current token
     ↓
Look at other relevant tokens
     ↓
Combine useful information
     ↓
Create a contextual representation

The mathematical details — Query, Key, Value, attention scores, and matrix multiplication — deserve their own article.

4. The Original Transformer: Encoder + Decoder

The original Transformer architecture contained two major components:

Input
  ↓
Encoder
  ↓
Representation
  ↓
Decoder
  ↓
Output

A useful beginner mental model is:

Encoder → processes and represents the input

Decoder → generates the output

For translation:

English
   ↓
Encoder
   ↓
Representation
   ↓
Decoder
   ↓
French

This architecture was designed around a very natural problem:

Take one sequence and transform it into another sequence.

For example:

English → French
Article → Summary
Question → Answer

But later, researchers realized that we don't always need both parts.

This led to different Transformer architectures.

5. Different Transformer Architectures

This was one of the things I initially found confusing.

If BERT, GPT, T5, and BART are all based on Transformers, why are they different?

The answer is:

Transformer is an architecture, not one specific model.

Different models can use different parts of the Transformer architecture.

A simple mental model is:

                         Transformer
                              │
              ┌───────────────┼───────────────┐
              ↓               ↓               ↓
        Encoder-only     Decoder-only    Encoder-decoder
              ↓               ↓               ↓
            BERT              GPT          T5 / BART

Let's look at each one.

5.1 Encoder-only Models

An encoder-only model uses the encoder part of the Transformer.

The encoder processes the input and creates contextual representations.

The most famous example is BERT.

BERT was trained using Masked Language Modeling.

For example:

The cat is [MASK] on the mat.

The model tries to predict the missing token.

Because the encoder can use context from both sides of the masked token, it can build a bidirectional representation.

This makes encoder-only models useful for tasks such as:

Text classification
Sentiment analysis
Named Entity Recognition
Search understanding
Information extraction
Some question-answering tasks

The simple mental model:

Encoder-only → understand/represent text

5.2 Decoder-only Models

A decoder-only model uses the decoder part of the Transformer.

The most famous example is GPT.

GPT stands for:

Generative Pre-trained Transformer

GPT is trained primarily using causal language modeling.

Its objective is:

Predict the next token using the previous tokens.

For example:

The cat is
       ↓
    sleeping

Then:

The cat is sleeping
                  ↓
              next token

The model keeps generating one token at a time.

This is why GPT is naturally suited to text generation.

The simple mental model:

Decoder-only → generate text

5.3 Encoder-decoder Models

Encoder-decoder models use both parts.

The encoder processes the input.

The decoder generates the output.

For example, in summarization:

Article
   ↓
Encoder
   ↓
Representation
   ↓
Decoder
   ↓
Summary

Or translation:

English
   ↓
Encoder
   ↓
Representation
   ↓
Decoder
   ↓
French

Examples include T5 and BART.

The simple mental model:

Encoder-decoder → transform one sequence into another

6. BERT vs GPT vs T5 vs BART

This is the simplest table I use to remember them:

Model	Architecture	Simple mental model
BERT	Encoder-only	Understand / represent
GPT	Decoder-only	Generate
T5	Encoder-decoder	Input → Output
BART	Encoder-decoder	Understand → Generate

The important thing to remember is:

They are different ways of using the Transformer architecture.

7. What Is an LLM?

Now we can finally talk about Large Language Models.

LLM stands for:

Large Language Model

Let's break down the name.

Large

"Large" generally refers to the enormous number of learned parameters.

Parameters are numerical values learned during training, primarily:

Weights
Biases

Modern language models can have billions of parameters.

Language

The model is trained on large amounts of language data and learns patterns and relationships in that data.

Model

It is ultimately a neural network that has learned these patterns through its parameters.

So:

LLM
│
├── Large
│     └── Many learned parameters
│
├── Language
│     └── Learns patterns from language
│
└── Model
      └── Neural network

8. GPT as an LLM

GPT-style models are generally large decoder-only Transformer models.

They are trained primarily using causal language modeling.

The basic objective is surprisingly simple:

Predict the next token based on the previous context.

Suppose the training data contains:

The sky is blue.

The model learns to predict:

The
 ↓
sky

Then:

The sky
 ↓
is

Then:

The sky is
 ↓
blue

This happens across enormous amounts of training data.

During training:

Input context
     ↓
Predict next token
     ↓
Compare with actual token
     ↓
Calculate error
     ↓
Update parameters
     ↓
Repeat

Over time, the model becomes better at predicting the next token.

9. How Can Next-token Prediction Do So Many Things?

This was one of the most interesting things for me to understand.

If GPT is fundamentally trained to predict the next token, how can it:

Answer questions?
Translate languages?
Summarize articles?
Write code?
Write poems?
Explain concepts?
Have conversations?

The answer is largely context.

The model doesn't necessarily need a separate mechanism for every task.

The prompt provides context about what kind of continuation is expected.

For example:

Translate to French:

I love cats.

The context tells the model that the expected continuation is a translation.

Or:

Summarize this article:

[article]

Now the expected continuation is a summary.

Or:

Write a Python function that sorts a list.

Now the expected continuation is code.

The underlying mechanism is still:

Context
   ↓
Predict next token
   ↓
Add token to context
   ↓
Predict next token
   ↓
Add token to context
   ↓
Repeat

This is one of the most important mental models I have taken away:

A relatively simple training objective — next-token prediction — can result in a model capable of many different language tasks.

10. Where Do Tokens Come In?

At this point, another question naturally appears:

If the model predicts tokens, does it actually process words directly?

No.

The model needs to convert our text into numerical representations that a neural network can process.

This starts with tokenization.

For example:

"I love programming"

might become something conceptually like:

["I", " love", " programming"]

The exact tokens depend on the tokenizer.

A token can be:

A complete word
Part of a word
Punctuation
A space combined with text
Other pieces of text

So:

A token is not necessarily a word.

The token is then mapped to a numerical ID:

Text
 ↓
Tokens
 ↓
Token IDs

11. Where Do Embeddings Come In?

The Transformer doesn't directly work with the token ID as a meaningful representation.

The token ID is essentially an index.

The model needs a richer numerical representation.

This is where embeddings come in.

Conceptually:

"cat"
  ↓
Token
  ↓
Token ID
  ↓
Embedding
  ↓
[0.21, -0.42, 0.17, ...]

An embedding is a vector containing many numerical values.

For example, if an embedding has 4,096 dimensions:

[0.21, -0.42, 0.17, ..., 0.31]

it simply means that the vector contains 4,096 numbers.

These numbers allow the Transformer to perform mathematical operations on the representation of the token.

At this point, our mental model becomes:

Text
 ↓
Tokenization
 ↓
Tokens
 ↓
Token IDs
 ↓
Embeddings
 ↓
Transformer

I'll go much deeper into tokenization and embeddings in the next article.

12. The Big Picture

After connecting all these concepts, this is the mental map I currently have:

                    Neural Networks
                           ↓
                     Deep Learning
                           ↓
                     Sequence Models
                           ↓
                      Transformers
                           ↓
                        Attention
                           ↓
              Transformer Architectures
                           ↓
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
     Encoder-only     Decoder-only    Encoder-decoder
          ↓                ↓                ↓
        BERT              GPT           T5 / BART
                           ↓
                          LLMs

And if I zoom into a GPT-style LLM:

User Prompt
     ↓
Tokenization
     ↓
Token IDs
     ↓
Embeddings
     ↓
Transformer Blocks
     ↓
Attention
     ↓
Contextual Representation
     ↓
Next-token prediction
     ↓
Generated token
     ↓
Repeat

This finally gave me the map I was missing.

I don't need to know every mathematical detail yet.

I first need to know where each concept belongs.

13. What Happens When I Actually Ask an LLM a Question?

Now comes the question I'm most interested in:

What actually happens inside an LLM when I type a prompt?

Suppose I ask:

What is the capital of India?

At a very high level, the process looks something like:

"What is the capital of India?"
             ↓
        Tokenization
             ↓
         Token IDs
             ↓
         Embeddings
             ↓
   Positional Information
             ↓
     Transformer Blocks
             ↓
         Attention
             ↓
 Contextual Representation
             ↓
        Output Scores
             ↓
          Softmax
             ↓
 Probability Distribution
             ↓
        Next Token
             ↓
           Repeat

And this is where I want to go next.

14. What's Next?

Now that I have the high-level map, I want to open up the black box.

In the next article, I'll start from the beginning of the inference process:

Prompt
  ↓
Tokenization
  ↓
Token IDs
  ↓
Embeddings
  ↓
Positional information
  ↓
Transformer
  ↓
Attention
  ↓
Hidden states
  ↓
Unembedding
  ↓
Logits
  ↓
Softmax
  ↓
Probability distribution
  ↓
Next token

I'll break down each step and answer questions like:

What exactly is a token?
What does an embedding represent?
What does "4,096-dimensional embedding" actually mean?
How does positional information work?
How does self-attention calculate which tokens are relevant?
What are Query, Key, and Value?
What is a hidden state?
What is the unembedding matrix?
How does the model turn its final representation into scores for every possible next token?
What exactly does softmax do?
Where does temperature come into the picture?
How does the model finally choose the next token?

The goal is not to start with mathematics.

The goal is to first build an intuitive mental model and then introduce the mathematics once the pieces make sense.

Final Takeaway

If I had to summarize everything I've learned so far in one sentence:

An LLM like GPT is a large neural network built using the Transformer architecture, trained on language to predict the next token, and capable of many language tasks because of the patterns and representations it learns from enormous amounts of data.

The biggest thing that changed for me was realizing that all these terms aren't isolated concepts.

They fit together:

Neural Networks
      ↓
Deep Learning
      ↓
Transformers
      ↓
Attention
      ↓
Encoder / Decoder Architectures
      ↓
GPT
      ↓
LLMs
      ↓
Tokens
      ↓
Embeddings
      ↓
Transformer Processing
      ↓
Next-token Prediction
      ↓
Generated Text

Now that I have the map, I'm ready to understand what's actually happening inside the box.

Before I Built with AI, I Wanted to Understand What Was Underneath

Priyanka-Chettri — Sun, 09 Aug 2026 13:58:48 +0000

As I started learning Applied AI, I realized I didn't want to jump straight into LLM APIs, RAG, agents, and prompting without understanding what was underneath.

So I went back to the basics.

From Machine Learning to Deep Learning

Traditional machine learning often relied on humans to decide which features were important.

For example, for digit recognition, we might manually identify:

edges
curves
strokes
shapes

Neural networks changed this approach.

Instead of manually defining all the features, a neural network can learn useful representations from the data.

A simple network looks like:

Input → Hidden Layers → Output

Each neuron uses weights and biases, and during training the model adjusts these parameters to reduce its error.

The cost function tells us how wrong the prediction is.

Backpropagation helps determine how each parameter contributed to that error, and gradient descent updates the parameters in a direction that reduces the cost.

Why Deep Learning?

When we stack many layers, we get deep neural networks.

The interesting part is that different layers can learn increasingly complex representations:

Pixels → Edges → Shapes → Parts → Object

This ability to automatically learn representations from raw data became one of the major strengths of deep learning.

From Deep Learning to Generative AI

A neural network doesn't have to be supervised. It can be trained using supervised, unsupervised, self-supervised, or reinforcement learning.

Modern AI heavily relies on self-supervised learning.

For example:

"The capital of France is ___"

Target → Paris

The text itself provides the training target. This makes it possible to learn from enormous amounts of data without manually labeling everything.

Then came Transformers, which introduced the idea of attention—allowing models to learn relationships between different parts of a sequence efficiently.

Large Transformers trained on massive datasets became foundation models.

When these models are trained to work with language at enormous scale, we get Large Language Models (LLMs).

And when models can use what they've learned to generate new text, code, images, audio, or video, we call it Generative AI.

The Mental Model

This isn't a perfectly linear hierarchy, but this is the mental map that helped me:

Machine Learning
↓
Neural Networks
↓
Deep Learning
↓
Transformers
↓
Self-Supervised Learning
↓
Foundation Models
↓
LLMs
↓
Generative AI

The goal isn't to become an ML researcher before becoming an Applied AI Engineer.

For me, the goal is simpler:

Understand what problem each concept solved, so that when I build on top of AI models, I know what I'm actually building on.

That's the foundation I'm starting my Applied AI journey with.

The React Pattern That Changed How I Build Reusable Components

Priyanka-Chettri — Thu, 09 Oct 2025 10:33:07 +0000

While building components for a design system, I initially followed an existing pattern that was already in place- they all had a consistent pattern. I didn’t know what it was called, but I loved how scalable and flexible it felt.

Later, I realized… this approach had a name — the Compound Component Pattern

Let me explain with a simple example 👇

Imagine we have a Flyout Button that, when clicked, opens a menu with a list.

Now, in a typical setup, if we want the Flyout to appear over a specific component, we’d probably pass a prop like toggle from the parent and control it there.
That works — but what if we want to use this Flyout anywhere in the app, with any icon, and in multiple combinations?

That’s where the Compound Pattern comes into play.

🧩 How to Identify When to Use It

If there’s a shared state between two or more components, that shared state lives in the parent component
You want flexibility and reusability without passing props down multiple levels
You’d rather use React Context to manage state than prop drilling

Then you’re probably looking at a perfect use case for the Compound Design Pattern.

A component with compound pattern in action looks like this

<Flyout>
  <Flyout.Toggle>
    <Icon name="more" />
  </Flyout.Toggle>
  <Flyout.Menu>
    <Flyout.Item>Profile</Flyout.Item>
    <Flyout.Item>Settings</Flyout.Item>
    <Flyout.Item>Logout</Flyout.Item>
  </Flyout.Menu>
</Flyout>

Here, each sub-component (Toggle, Menu, Item) communicates through a shared context, not props.
This makes the component incredibly reusable, readable, and extensible — a win for design systems.

This pattern truly changed how I think about building components in React.
Once you start using the Compound Pattern, you realize it’s not just about cleaner code — it’s about creating a language for your UI.

𝐖𝐡𝐚𝐭 𝐛𝐮𝐢𝐥𝐝𝐢𝐧𝐠 𝐚 𝐬𝐢𝐦𝐩𝐥𝐞 𝐓𝐨-𝐃𝐨 𝐥𝐢𝐬𝐭 𝐢𝐧 𝐑𝐞𝐚𝐜𝐭 𝐜𝐚𝐧 𝐭𝐞𝐚𝐜𝐡 𝐲𝐨𝐮 𝐚𝐬 𝐚 𝐁𝐞𝐠𝐢𝐧𝐧𝐞𝐫🎯

Priyanka-Chettri — Sun, 29 Sep 2024 10:03:50 +0000

Creating a to-do in React appears simple. However, as you introduce add on features, it opens a whole new door to explore and understand concepts. Here's how this project can enhance your understanding.

✅ 𝐂𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭 𝐒𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞: Break tasks into manageable chunks with reusable components.
✅ 𝐏𝐫𝐨𝐩𝐬 & 𝐃𝐚𝐭𝐚 𝐅𝐥𝐨𝐰: Pass data seamlessly between parent and child components.
✅ 𝐂𝐨𝐧𝐝𝐢𝐭𝐢𝐨𝐧𝐚𝐥 𝐑𝐞𝐧𝐝𝐞𝐫𝐢𝐧𝐠: Show or render components based on a condition ( example of to do: If the edit mode is on then place an input field).
✅ 𝐄𝐯𝐞𝐧𝐭 𝐇𝐚𝐧𝐝𝐥𝐢𝐧𝐠 : Understand how to handle clicks, typing, and more. On delete button click how can you delete the to-do?
✅ 𝐑𝐞𝐚𝐜𝐭 𝐡𝐨𝐨𝐤𝐬: Understand when to use useState and useEffect.

Once you've built a basic to-do application, it's time to level up by adding features that make your app more robust and user-friendly.

✅ 𝐈𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭 𝐋𝐨𝐜𝐚𝐥 𝐒𝐭𝐨𝐫𝐚𝐠𝐞: With every change in the to-dos store the input into a local storage. Use useEffect to update the local storage.
✅ 𝐈𝐦𝐩𝐫𝐨𝐯𝐞 𝐒𝐭𝐚𝐭𝐞 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐰𝐢𝐭𝐡 𝐂𝐨𝐧𝐭𝐞𝐱𝐭 𝐀𝐏𝐈: To avoid prop drilling if any and manage state more effectively, implement the React Context API. Understanding Context API solidifies your base.
✅ 𝐎𝐩𝐭𝐢𝐦𝐢𝐬𝐞 𝐰𝐢𝐭𝐡 𝐑𝐞𝐚𝐜𝐭 𝐒𝐭𝐚𝐭𝐞 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐋𝐢𝐛𝐫𝐚𝐫𝐢𝐞𝐬: As your application grows, you might notice unnecessary re-renders, especially when working with multiple components and features. Libraries like Recoil, Redux, or Zustand can help manage state efficiently and prevent re-renders.

By adding these features, you're not only enhancing functionality but also learning critical concepts like local storage, context-based state management, and optimising rendering behaviour, which are essential for building scalable React applications.

Accent Colors for Checkboxes and Radios

Priyanka-Chettri — Wed, 05 Jun 2024 12:17:05 +0000

Utilize accent-* utilities to modify the accent color of elements, ideal for customizing the appearance of checkboxes and radio buttons by replacing the browser's default color.

Here, I have given accent color accent-pink-500, you can customize the color according to your need.This comes handy if you want to customize the look of your check boxes and radio buttons according to your theme.

The code for it is given below:

<div class="mx-auto my-auto border h-[100px] w-[300px] rounded-md flex justify-center items-center gap-4 shadow-lg">
<label class="font-semibold font-serif">Accent Color</label>
<input type="checkbox" class="accent-pink-500 " id="checkbox" >
</div>

Thanks for reading!

Unveiling the Magic of hover, focus and active variants in Tailwind CSS.

Priyanka-Chettri — Tue, 28 May 2024 07:43:15 +0000

💡𝐏𝐫𝐨 𝐓𝐢𝐩: Make your UI elements pop with Tailwind CSS! Use 𝐡𝐨𝐯𝐞𝐫, 𝐟𝐨𝐜𝐮𝐬, and 𝐚𝐜𝐭𝐢𝐯𝐞 variants to enhance user experience and engagement. Your designs will thank you!

Dive into this demo to see them in action!
Ready to give it a try? Check out the code below and start
experimenting! 👇

➡️ Snippet of "hover" variant applied to a button.

➡️ Snippet of a "focus" variant applied to a button

➡️ Snippet of an "active" variant applied to a button

Overcoming Tight Coupling In OOPs With Effective Solutions

Priyanka-Chettri — Mon, 08 Apr 2024 20:14:28 +0000

Familiar with "tight coupling" in OOPs? It's a common issue where classes become overly interdependent, making code changes cumbersome and error-prone. Imagine updating one class and having to revise multiple others due to tight dependencies.

This is how a tightly coupled code looks like:

Here, the direct instantiation of Engine class within the constructor of Car class creates a strong dependency between the two classes.

The problem encountered in the above code can be solved using Dependency injection in Spring and by promoting the use of Interfaces.

METHOD 1: Dependency injection using constructor injection

Problem ❌: Tight coupling occurs when one class directly instantiates another class, using the “new” keyword

Solution 💡: Use Dependency injection to pass dependency from external sources, highly used in Spring . In the below figure the engine object is being passed as the parameter to the constructor from an external source.

METHOD 2: Using interfaces

Problem ❌: Classes depending on concrete implements rather than interfaces, causes tightly coupled relationship between them. To say, if the type of engine to be used by a car is changed the whole code has to be re written again.

Solution 💡: Use interfaces instead of using concrete classes, this gives more flexibility to a code.

Follow Me for such contents!
Happy Learning :)

DEV Community: Priyanka-Chettri

You Typed a Prompt. What Happens Next?

Before we begin: training has already happened

Step 1: Your prompt joins the conversation

Step 2: The tokenizer breaks the sequence into tokens

Step 3: Token IDs become embeddings

But mole can have several meanings

Step 4: The model adds positional information

Step 5: The prompt enters the prefill phase

Does the mole token look ahead at face and change its meaning?

Step 6: Attention lets positions retrieve relevant context

Step 7: The representations pass through many layers

Step 8: The last prompt position becomes the prediction point

Step 9: The unembedding matrix produces logits

Step 10: Logits become a probability distribution

Temperature

Presence and frequency penalties

Step 11: A decoding strategy chooses one token

Step 12: The selected token is appended

Step 13: The KV cache prevents wasteful repetition

Step 14: Tokens are decoded and streamed to your screen

Step 15: The model eventually stops

Where does the context window fit?

What did not happen?

The model did not fetch definitions from a dictionary

The model did not permanently modify the mole embedding

In a decoder-only model, mole did not look ahead at face

Attention did not compare the prompt against the complete vocabulary

The model did not generate the complete answer in one operation

The KV cache did not increase the context window

The model did not train itself on your message while answering

The entire journey in one view

Sources and further reading

From Neural Networks to LLMs: The Mental Model I Was Missing

1. Starting With Neural Networks

Context matters

2. Why Did Transformers Come Into the Picture?

3. Attention: The Key Idea

4. The Original Transformer: Encoder + Decoder

5. Different Transformer Architectures

5.1 Encoder-only Models

5.2 Decoder-only Models

5.3 Encoder-decoder Models

6. BERT vs GPT vs T5 vs BART

7. What Is an LLM?

Large

Language

Model

8. GPT as an LLM

9. How Can Next-token Prediction Do So Many Things?

10. Where Do Tokens Come In?

11. Where Do Embeddings Come In?

12. The Big Picture

13. What Happens When I Actually Ask an LLM a Question?

14. What's Next?

Final Takeaway

Before I Built with AI, I Wanted to Understand What Was Underneath

The React Pattern That Changed How I Build Reusable Components

𝐖𝐡𝐚𝐭 𝐛𝐮𝐢𝐥𝐝𝐢𝐧𝐠 𝐚 𝐬𝐢𝐦𝐩𝐥𝐞 𝐓𝐨-𝐃𝐨 𝐥𝐢𝐬𝐭 𝐢𝐧 𝐑𝐞𝐚𝐜𝐭 𝐜𝐚𝐧 𝐭𝐞𝐚𝐜𝐡 𝐲𝐨𝐮 𝐚𝐬 𝐚 𝐁𝐞𝐠𝐢𝐧𝐧𝐞𝐫🎯

Accent Colors for Checkboxes and Radios

Unveiling the Magic of hover, focus and active variants in Tailwind CSS.

Overcoming Tight Coupling In OOPs With Effective Solutions

But `mole` can have several meanings

Does the `mole` token look ahead at `face` and change its meaning?

The model did not permanently modify the `mole` embedding

In a decoder-only model, `mole` did not look ahead at `face`