ChatGPT models have a fixed context window — they can only process a limited number of tokens at a time (a token is a small chunk of text: a word, part of a word, or punctuation). When a conversation is short, the model sees every message directly. Once the conversation gets very long, it's no longer practical to include every old message in full — so older history gets represented in a compressed form instead.
This is usually not exact compression like ZIP, where the original text can be perfectly restored. Instead, it is closer to semantic summarization. The system tries to preserve the important meaning — decisions, user preferences, project context, constraints, and repeated facts — while dropping low-value details such as typos, casual comments, repeated back-and-forth, or outdated intermediate decisions.
If a user had a long conversation about building a website called Nextforay, GitHub Pages, private repositories, Cloudflare Pages, DNS, and branding, the older history might be compressed into a short summary like:
This summary is much shorter than the full conversation, but it preserves the useful context needed for future answers.
Exact wording, code, YAML files, DNS records, legal text, or detailed numbers may be lost or simplified during summarization. That is why, for technical or high-precision tasks, it is better to paste the latest exact version again rather than rely on the model's memory of it.
- Recent messages — kept in high detail, close to raw
- Older messages — may be summarized, losing exact wording
- Long-term memory — may store stable facts or preferences useful across conversations
Not exactly. There are two different concepts here: attention inside the model and context compression before the model processes the input.
Inside the model, ChatGPT uses a transformer architecture, and transformers rely on self-attention. Self-attention helps the model decide which parts of the currently available context are most relevant when generating the next token. For example, if the user asks about making a GitHub repository private, the attention mechanism may focus more on words like "GitHub Pages," "private repo," "Cloudflare Pages," and "custom domain," while giving less importance to unrelated older topics.
Attention does not automatically mean the model is compressing the entire long conversation by itself. Attention works only over the tokens that are already present in the model's current context window. If the full conversation is too long, some preprocessing may happen before the model receives the input — older messages may be summarized, selected, or retrieved as relevant memory, and then that compressed information is inserted into the context.
Even though an LLM has billions of parameters, it still has a limited context window because parameters and context are two different things.
The billions of parameters store learned patterns — grammar, reasoning behavior, coding knowledge, facts, concepts. But they do not store your current conversation word-for-word. When you send a prompt, the model must process the actual input tokens currently given to it, and it can only attend to a fixed maximum number of tokens at once — the context window.
A simple analogy:
A person may know a lot, but they cannot hold an entire 500-page book perfectly in active attention at the same time.
Most transformer models use self-attention. In basic self-attention, every token compares itself with many other tokens in the context — so as context length grows, computation grows very fast.
Because tokens interact with other tokens:
This affects:
- GPU memory
- Latency
- Serving cost
- Energy usage
- Throughput
So context length is not only a model design issue — it is also an infrastructure and cost issue.
Even if we technically allow a huge context window, the model may not use all of it equally well. Long-context models can sometimes miss details buried deep inside the prompt, confuse older and newer information, or over-focus on irrelevant text. So bigger context helps, but it does not automatically mean perfect recall.
A model must be trained or adapted to handle long contexts well. You cannot always take a model trained mostly on shorter sequences and expect it to perform perfectly on very long documents. Long-context ability needs special architecture choices, positional encoding strategies, training data, and evaluation.
LLMs hallucinate because they are trained to predict the most likely next token, not to directly verify truth. A model does not "know" facts the way a database knows facts — it generates answers based on patterns learned from huge training data. At inference time, the objective is roughly:
The goal is to generate a likely and coherent answer — not automatically to check that answer against a trusted source. So if the model has incomplete, conflicting, outdated, or weak information, it may still generate a confident-looking answer.
- Training objective — LLMs are optimized for language prediction. They learn what answers usually look like, not always what is true.
- No built-in source of truth — unless connected to tools, documents, search, a database, or RAG, the model cannot verify fresh or exact facts.
- Knowledge gaps — if the model has not seen enough reliable examples about a topic, it fills gaps using plausible patterns.
- Conflicting training data — training data can contain outdated, duplicated, low-quality, or contradictory information; the model may blend them.
- Overconfidence from language fluency — LLMs are very good at producing fluent text; fluency can make wrong information look convincing.
- Prompt pressure — if the user asks for an answer even when information is missing, the model may try to be helpful instead of saying "I don't know."
- Long context issues — in long prompts the model may miss details, mix old and new information, or rely on the wrong part of the context.
Suppose you ask:
If the model has weak or outdated knowledge, it may generate something that follows a common API pattern:
This looks realistic, but it may not exist. That is hallucination: plausible but unsupported generation.
- Niche or low-coverage topics
- Recent information beyond the training cutoff
- Exact numbers, citations, and references
- API endpoints, library versions, SDK signatures
- Legal, medical, and financial specifics
- Long-context conversations where context is partially lost
- RAG — retrieve documents at query time and ground answers in source text
- Tool use / search — let the model call external APIs or databases for verifiable facts
- Citations — require the model to cite the source chunk it used; makes hallucination detectable
- Structured output + validation — constrain output schema; validate extracted values against source
- Confidence checks — ask the model to output confidence per claim; route low-confidence outputs to HITL
- Prompt instruction — explicitly instruct the model to say "I don't know" when evidence is insufficient
- Faithfulness eval — use NLI or LLM-as-judge to check whether each claim is supported by the retrieved context
An LLM is trained using a language modeling objective — mainly next-token prediction. Given a sequence of tokens, it learns to predict the most likely next token based on patterns in the training data.
The model learns that "New Delhi" is likely based on examples seen during training. It is not trained like a database that verifies facts. It learns statistical and semantic patterns from large-scale text, so it can generate fluent and useful answers — but also plausible-sounding incorrect ones.
A token is the basic unit of text that an LLM processes. A token can be a full word, part of a word, punctuation, whitespace, or a special symbol. A sentence like ChatGPT is useful. may split into tokens like:
Actual tokenization depends on the tokenizer. Models do not directly read characters or words — they read token IDs. Tokenization affects context length, cost, model performance, multilingual handling, code generation, and even simple tasks like counting letters.
- Context length — one word may become multiple tokens, so a "4K token" window may hold fewer than 4K words
- Cost — API pricing is per token, not per word; longer tokens = higher cost
- Multilingual handling — non-English text often tokenizes into more tokens per character, effectively shrinking the usable context for those languages
- Counting & spelling — the model may not see individual characters, which is why it can fail at tasks like "count the r's in strawberry"
- Code generation — symbols, indentation, and identifiers may each be separate tokens affecting how the model reasons about code structure
A token is a discrete text unit. An embedding is a numerical vector representation of that token. The model first converts text into tokens, then maps each token ID into an embedding vector. This vector captures learned information about the token's meaning and usage.
The embedding is usually a high-dimensional vector (hundreds or thousands of dimensions). Similar words or concepts often have embeddings that are geometrically closer in that space.
Self-attention allows each token to look at other tokens in the sequence and decide which ones are important for understanding the current token. Consider:
The word "it" refers to "trophy," not "suitcase." Self-attention helps the model connect "it" to the correct earlier word, even across many tokens. Instead of processing words only left-to-right like older sequence models, transformers use attention to compare tokens with every other token in the context.
Older RNNs and LSTMs process text sequentially, one token at a time. This makes training slow and makes it hard to capture relationships between distant words — information must travel through every intermediate step.
Transformers use self-attention, allowing tokens to compare directly across the full sequence. Training is parallel rather than sequential.
- Better long-range context — attention directly connects distant tokens; RNNs degrade over long sequences
- Parallel training — all tokens processed simultaneously; RNNs must compute step by step
- More scalable — larger transformers consistently improved with more data and compute; RNNs did not scale as predictably
- GPU/TPU fit — matrix multiplications used by attention map naturally to hardware accelerators
- Stronger performance — on translation, summarization, generation, and reasoning, transformers outperform RNN-based architectures at scale
In attention, every token is projected into three vectors:
A simple analogy is library search. Your search query is matched against book indexes (keys); strong matches return the book content (values).
For the word "it" in The cat sat because it was tired, the Query may look for the entity being described. The Key of "cat" matches strongly, so the model pulls the Value of "cat" to understand the sentence.
Multi-head attention runs several attention mechanisms in parallel, called attention heads. Each head can learn to focus on different types of relationships — one head might focus on grammar, another on subject-object relationships, another on long-distance references, another on positional patterns.
For Amit gave Rahul his laptop because he needed help, different heads may focus on:
Transformers process tokens in parallel and do not naturally understand word order. Unlike RNNs, they don't process tokens one after another. So without positional encoding, the model would treat these as equivalent:
Positional encoding adds information about each token's position to its embedding before the first layer, letting the model distinguish order.
- Sinusoidal (original paper) — fixed math formulas based on position and dimension; no training needed
- Learned positional embeddings — position embeddings treated as trainable parameters, learned during training
- Rotary Position Embedding (RoPE) — encodes position by rotating Q and K vectors; better for long contexts; used in LLaMA, Qwen, and many modern models
- ALiBi — adds a position-based bias to attention scores rather than the embeddings; generalizes to sequences longer than those seen in training
The large collection of text (web, books, code, conversations) used to train the model. After training, it is not stored in the model — only its influence on the weights remains.
The learned weights of the neural network. They store patterns learned from training data, but not as a searchable database — knowledge is distributed across millions or billions of weights. Not updated at inference time (unless fine-tuning).
The current input given to the model during inference: user prompt, conversation history, system instructions, retrieved documents, tool outputs. The model only "sees" what is in its current context window. It is temporary — cleared at the end of the session.
User-specific information saved externally (database, vector store) and retrieved into future conversations. Managed by the application, not the model itself. Allows personalization and recall across sessions without retraining.
Knowledge in an LLM is stored in its parameters — the learned weights of the neural network. But it is not stored like rows in a database. You cannot simply open the model and find:
Instead, knowledge is distributed across many weights and layers. The model learns patterns from training data and encodes those patterns as high-dimensional representations. This is why LLMs can generalize — they learn relationships, concepts, grammar, style, and reasoning patterns, not just facts.
Technically, an LLM predicts tokens based on learned statistical patterns. But because it is trained on huge amounts of language, code, reasoning examples, and world knowledge, it develops internal representations that can behave like understanding. It can summarize, translate, reason, write code, answer questions, and follow instructions.
However, it does not understand like a human. It has no lived experience, consciousness, goals, or direct grounding in the physical world — unless connected to tools, sensors, or external systems.
Not easily. Because knowledge is distributed across many parameters, removing one fact is difficult. The model does not store facts in a clean key-value format, so removing "Person X works at Company Y" may require changing weights that also encode many related things.
- Machine unlearning — attempts to remove training influence; still an active research area
- Model editing — techniques like ROME or MEMIT to directly patch specific facts in weights; imperfect and can break related knowledge
- Fine-tuning — fine-tune on examples that override the fact; can partially work but risks side effects
- Refusal tuning — train the model to refuse to answer questions about a specific topic
- Manage sensitive or changing facts in external memory, RAG, or access-controlled databases
- Add output filters or guardrails to block specific content before it reaches the user
- Avoid relying on model weights for facts that need to be updated or deleted — keep them external
The model generates output based on the probability distribution created by the full prompt. Even a small wording change can shift the model's interpretation, tone, reasoning path, or assumptions. For example:
Prompts act like soft instructions — they influence what the model attends to, what style it uses, and which learned patterns it activates. This sensitivity is strongest when the prompt is ambiguous, underspecified, or asks about complex topics.
LLMs process text as tokens, not as individual characters. A word like strawberry may be represented as one or a few subword tokens — not necessarily as separate letters. So when asked to count letters, the model predicts an answer based on learned patterns rather than performing exact symbolic counting.
The model may not "see" the individual r's at all. It generates a likely-sounding count based on pattern recognition rather than enumeration.
LLMs are trained primarily to predict language patterns, not to execute arithmetic algorithms. They may have seen many arithmetic examples during training, so they can answer common calculations — but for exact multi-step arithmetic they may make mistakes because they are generating likely tokens rather than running a calculator.
An LLM generates text token by token. At each step it predicts the next token. It stops when one of several conditions is met:
- The model predicts an end-of-sequence (EOS) token — a special token the model was trained to output when a response is complete
- It reaches the max token limit set by the caller or system
- It produces a stop sequence defined by the developer (e.g.,
"\n\nUser:"in a chat template) - The API or server cuts off the response due to infrastructure limits
Since the model generates one token at a time, it may fall into a loop where previously generated text makes similar next tokens more likely. If it starts a repeated pattern like This means... This means... This means..., the generated context itself reinforces that pattern.
Repetition also happens when the model is trying to be comprehensive but lacks new information — it rephrases the same idea multiple times.
- Repetition penalty — down-weight tokens that have already appeared in the output
- Stop sequences — halt generation when a known completion pattern is reached
- Better prompts — give the model a clear scope and length expectation
- Lower max tokens — prevents the model from padding when it has run out of content
- Improved instruction tuning — models fine-tuned for conciseness are less prone to filler loops
- Adjusted sampling — top-p / top-k sampling or temperature tuning can help break repetitive ruts
A model can only process a limited number of tokens at once. Long conversations are handled using a combination of context window management, summarization, retrieval, and memory. The simplified flow:
The model then uses attention over that final assembled context. The key point: the model does not always see the full conversation word-for-word. Long conversation handling is often lossy — exact old wording, code, and small details may be lost unless explicitly preserved.
Context compression means reducing older or longer conversation history into a shorter representation while trying to preserve the important meaning. It is not like ZIP compression — the original text cannot be perfectly restored. It is semantic compression, more like summarization.
A long conversation about GitHub Pages, private repos, Cloudflare Pages, DNS, and branding might compress to:
This saves context space while preserving useful information. However, it can lose exact code, exact wording, chronology, minor decisions, or technical details.