LLM Fundamentals · 30 Tough Questions
Each with intent, framework, and bonus points: probability prediction / message list / hallucination explanation / RAG vs retraining / Temperature / context window
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “LLM Fundamentals · 30 Tough Questions”?
Each with intent, framework, and bonus points: probability prediction / message list / hallucination explanation / RAG vs retraining / Temperature / context window
Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.
Write one question you could answer with evidence after trying this idea.
A conclusion that sounds complete but leaves the key assumption untested.
- Lead with the essence: An LLM is a massive probabilistic prediction machine. It does one thing at a time: given all existing Tokens, it predicts the probability distribution for the next Token and generates tokens one at a time.
- Distinguish training from inference: Training is learning statistical patterns from enormous text data. When you're chatting with it, the parameters are frozen — it's not learning, it's computing.
- Address the thinking question directly: It doesn't think in the human sense, yet at sufficient scale it demonstrably exhibits reasoning-like behavior. So neither deify it nor dismiss it as a simple autocomplete.
- Ground it with an example: Given "The weather today is really," the model outputs: good 62% / bad 18% / cold 9% — and samples from that distribution. A full response is this action repeated hundreds of times.
- Reveal the core: The model is fundamentally a text-completion machine. "Dialogue" means packaging the conversation history in chat-log format and having the model complete the assistant's next turn.
- The truth about multi-turn: The model has no memory. Every turn sends the entire message list — system + all previous user/assistant turns + the current question — from scratch.
- Add the engineering layer: The model understands conversation format because of Chat Template + SFT instruction tuning — the key step that teaches the base model to "speak."
- Elevate one level: Every AI Harness operation (RAG, memory, Agent) is fundamentally about manipulating this message list. Understand it and you've found the entry point to every solution.
- Lead with the conclusion, no hedging: Hallucination is an inevitable byproduct of probabilistic prediction. It cannot be fully eliminated, but engineering measures can compress it to a level acceptable for the business.
- Then explain the root causes: Two sources: incorrect parametric knowledge (training data was wrong or outdated), and context misinterpretation (the model always picks the most likely continuation, and "most likely" ≠ "most accurate").
- Offer a combined solution: RAG to inject real refund policy documents + Prompt constraint "answer only based on the document" + lower Temperature + evaluation harness and human review as backstop.
- Give a quantifiable commitment: Define a hallucination rate metric (sampled review), report convergence weekly, and turn "when will it be fixed?" into "when does the metric reach X?"
- List all four methods: Prompt constraints (cheapest), RAG (most effective for knowledge hallucination but has cost), lower Temperature (reduces randomness only, doesn't fill knowledge gaps), evaluation + human review (external backstop).
- Ask about the scenario first: Is the hallucination mainly fabricating facts, or is the expression unstable? Does the knowledge base change? What's the budget?
- Give a conditional answer: Knowledge hallucination (fabricating policies, inventing data) → RAG. Unstable expression → Prompt constraints + low Temperature, nearly zero cost, deploy first.
- Add one principle: Regardless of which you choose, establish evaluation first. Without evaluation you can't measure effectiveness — it's wasted effort.
- Pick up the joke: No retraining needed. Frozen parameters don't mean knowledge can't get in — the context window is the knowledge entry point.
- Give the solution: Use RAG. Chunk the manual, build a vector index, retrieve relevant passages and inject them into context when users ask. Updating the manual only requires rebuilding the index — active in a day, costs orders of magnitude less than retraining.
- Clarify the correct use of fine-tuning: Fine-tuning changes behavioral style (tone, format, domain vocabulary) — it's not the right tool for injecting time-sensitive knowledge. Once knowledge enters the weights, every update requires another training run.
- Show cost awareness: RAG also has costs: each request uses more tokens, latency goes up. It needs to be paired with caching, routing, and precise chunking for optimization.
- Explain the mechanics: Temperature controls how steep the probability distribution is — lower means more deterministic, higher means more spread out. Top-P controls the sampling candidate pool size. Together they determine output randomness.
- Give scenario-specific settings: Customer service / factual Q&A / data extraction → lower (0–0.3). Creative copy / brainstorming → higher (above 0.7).
- State the boundary: This only mitigates expressive randomness — it doesn't fix knowledge gaps. Even with low Temperature, the model will still confidently make things up.
- Provide a validation method: Parameter values should be validated with A/B testing on an evaluation set. Picking one value for the entire product by gut feeling is a bad practice.
- Clarify the concept: The window = the total number of Tokens the model can see in one pass (input + output). Anything beyond that is truncated — as far as the model is concerned, it never existed.
- Expose the trap: A larger window means a larger bill. Tokens are charged by volume. Stuffing everything in makes costs rise linearly.
- Add the technical limitation: Long contexts suffer from "lost in the middle": the more information, the more diluted the attention, and recall of content in the middle sections drops significantly.
- Give the right approach: A large window is just a capability ceiling. The correct practice is context engineering: retrieve, compress, filter — put only what belongs in the window.
- Start with the definition: A Token is the basic unit the model uses to process text. The first step of training is Tokenization — slicing continuous text into units from the vocabulary. One Chinese character is roughly 1 to 3 Tokens; one English word is roughly 1 Token.
- Connect it to cost: Inference is billed by Token — input and output both cost money. A Prompt template that looks like 500 characters can actually eat 1,500 Tokens. Multi-turn chats resend the history every turn, so the bill piles up.
- Connect it to the window: The context window is also measured in Tokens; overflow gets truncated. The more bloated the template, the less room left for the actual content and history.
- Land on an action: Before launch, measure the real Token count of your key Prompts with a Tokenizer. Don't guess from character count.
- Give the mix: Pretraining corpus is mostly web text at about 70%, books about 12%, code about 8%, academic papers and dialogue data about 5% each.
- Give a feel for scale: Training a small model on about 1B Tokens is like 750,000 novels — a small library. 15T Tokens is like reading the entire internet two or three times.
- Give the conclusion: The quality and diversity of training data set the ceiling of the model's worldview. In domains the data never covered, the model either refuses or makes things up.
- Land on a real test: Same obscure-person question: a 270M model fabricates an identity outright, a 1.8B model can only refuse, and only 30B+ gets it right. Knowledge gets covered correctly only when data and parameters are enough.
- Lead with a counterexample: In the course's live test, Llama-3.3 70B mistook singer Lee Ji-eun for an actress of the same name — birth year off by 6 years, representative works all wrong. A 30B Qwen got it right. Bigger parameters do not mean no hallucination.
- Name the root cause: The knowledge boundary is set by training-data coverage. For obscure facts the data never covered, even a huge parameter count can only invent.
- Give the right approach: Knowledge errors get fixed by injecting real material via RAG. Swapping models does not fix "it isn't in the parameters."
- Add the cost math: A bigger model means every Token is more expensive and latency is higher. Attribute the error type first, then pick a plan.
- Define Base: What you get after pretraining is a Token-predicts-Token machine. It only predicts the next most likely Token from the preceding text. It does not understand the question, think through an answer, or look anything up.
- Give the consequence: Ask a Base model "Who is Zixia Fairy (紫霞仙子)?" and it will continue in corpus style with something like "Zixia Fairy is gege, gege do you like me" — it is not answering the question at all.
- Explain the jump: Base to Chat takes two steps: first agree on a Chat Template dialogue format, then run SFT instruction tuning on a huge set of formatted conversations, so the model learns to answer as an assistant.
- Name the essence: After SFT the model is still doing Token prediction. What changed is the training data — formatted dialogue plus high-quality answers.
- Name the old path: Before GPT, models were task-specific — pick the task first, then train. Change the task, change the model.
- Point out each limit: CNN can only see words inside a sliding window — relations outside the window are invisible in one step. RNN memory decays turn by turn; information from the start of a long text is almost gone by the end. BERT's bidirectional attention is strong at understanding, but the pretraining objective is fill-in-the-blank, so it is weak at generation.
- Give GPT's answer: Causal pretraining's objective is literally "predict the next word," which matches generation naturally. No special task data required, and the larger the scale, the more startling the emergent abilities.
- Lift it to a paradigm: PreTraining does Token prediction on almost all text — grammar, common sense, facts, and logic are all byproducts. Train once, transfer the capability to any task. That is the core idea of a Foundation Model.
- Explain the mechanism first: Parameters are completely frozen during a conversation — the model itself has no memory. So-called multi-turn dialogue is the system resending the full history every time so the model can continue it.
- Locate this incident: Once history exceeds the context window it gets truncated. Truncated content, to the model, never existed. What the user feels is "it forgot."
- Give a product plan: Control history length, keep key facts inside the context, and stop a bloated System Prompt and the history from crowding each other out of the window.
- Give the shape of a commitment: Quantify the turn count and character boundary that trigger truncation, and design specifically for extra-long chats. Don't promise "it will never forget again."
- Separate the two stages: Pretraining learns statistical patterns from a huge general corpus. SFT keeps training on formatted dialogue data so the model learns to act as an assistant inside that format.
- Explain the Template: Borrowing Jinja-style templating, special tokens like <|im_start|> and <|im_end|> wrap each message and distinguish system, user, and assistant roles.
- Explain where generation starts: All messages are concatenated into one text blob in that format. The model starts completing after <|im_start|>assistant. What SFT trains is producing a decent answer at that position.
- Name the essence: SFT is still Token prediction. The only change is the training data — formatted dialogue plus high-quality answers.
- Give the causal chain: The model predicts what comes next from what came before. A Prompt is high-quality preceding text — better prefix, better continuation. After PreTraining you don't retrain to switch tasks; you just feed in the task description.
- Name the vehicle: All of this rides on a large context window: task instructions, rules, and Few-Shot examples all go into the prefix, with an effect comparable to specialized training.
- Give the boundary: Prompt is enough only when the knowledge is already in the training data — format, style, tone. Private knowledge, real-time data, and anything after the knowledge cutoff need RAG. A fixed domain style or reasoning paradigm needs fine-tuning.
- Give a debugging habit: When a Prompt change does nothing, first check whether the System Prompt got truncated or history filled the window. The problem is often context management, not how well the Prompt was written.
- Lead with the judgment: Hallucination is an inevitable byproduct of probabilistic prediction. It cannot be fully eliminated. Any claim of a complete fix is worth doubting — that's industry consensus, and every vendor faces the same boundary.
- Give a way to puncture it: Ask for their evaluation protocol: what's the hallucination rate, what scenarios does the test set cover? A "solved" with no numbers is just marketing copy.
- Give a way to prove ourselves: Bring our own evaluation baseline. Quantify hallucination rate on a test set with known answers, and compare with the competitor under the same protocol.
- Give an action commitment: Treat hallucination rate as a weekly quantifiable metric and write it into the PRD as an acceptance criterion — manage it like "load time under 2 seconds."
- List all four types: Factual hallucination invents facts and numbers that don't exist. Source hallucination cites papers, links, or authors that don't exist. Reasoning hallucination starts from a correct premise but botches the steps. Code hallucination calls APIs or functions that don't exist.
- Give a sharp example: Ask the model to sort a pandas DataFrame by multiple columns, and it will wrongly apply numpy.sort's stable argument to sort_values. The syntax looks fine; run it and you get a TypeError.
- Say why it's dangerous: Code hallucination's damage is that it looks real. The logic is wrong, small test data won't show it, and it blows up in production.
- Close on the root cause: The model only has a rough impression of the API and stitches together the most plausible-looking call. Probabilistically reasonable, factually wrong.
- Own the wording: Parameters are completely frozen at inference. The model learns nothing. RAG temporarily injects retrieved documents into context at runtime, then throws them away.
- Give an accurate analogy: Parameters are an encyclopedia sealed after it was written. Context is the reference material sitting on the desk. Knowledge-base content goes into the latter.
- Spell out the engineering meaning: Because it's a temporary injection, updating the knowledge base only requires rebuilding the index — you don't touch the model. That's exactly RAG's advantage.
- Give the correction: Change the PRD to "retrieval injection," and write down how many Tokens get injected per request and what the fallback is when retrieval fails.
- Split the two stages first: Knowledge-base construction is a one-time offline job — documents get chunked, run through an Embedding model into vectors, and stored in a vector database. The query stage runs in real time on every conversation.
- Walk the query path: The user question is vectorized with the same Embedding model, Top-K related chunks are retrieved by cosine similarity, stitched into the Prompt as reference, and the model generates a sourced answer from the injected documents.
- Answer the chunking question: Granularity directly hits retrieval quality: too large injects redundant Tokens and wastes money; too small loses context. Best practice is about 512 to 800 Tokens per chunk, using titles and paragraphs as boundaries so the semantics stay intact.
- Add a critical detail: Question vectors and document vectors must come from the same Embedding model, or you can't compare similarity in the same semantic space.
- Name the cost driver: The jump is the bigger Prompt: each query injects an extra 500 to 2,000 Tokens, so LLM cost multiplies. Vectorization and retrieval themselves are cheap — question embedding is about 0.1 yuan per million Tokens.
- Give the most important optimization: Do intent recognition first to decide whether to retrieve at all. About 70% of conversations don't need a document lookup — answering directly is faster and cheaper.
- Give the combo: Keyword triggers can skip 30% to 70% of queries. Route simple questions to a small model and overall LLM spend drops 60% to 80%. Similar questions go through a semantic cache — cosine similarity above 0.95 reuses the result directly.
- Give a management action: Put RAG trigger rate and cost per conversation on a dashboard and watch them converge weekly.
- Check retrieval first: Chunking granularity, Embedding model, similarity threshold — the three most common break points. Watch retrieval hit rate. In the course case, 78% against a target of 85% is a clear miss.
- Then check the knowledge base itself: RAG's quality ceiling is the knowledge base. Expired docs and contradictory content will produce wrong answers no matter how accurate the retrieval.
- Then look at generation: Injected content is limited, so the model fills in the gaps from training memory — a RAG-plus-hallucination mix that's harder to spot than pure hallucination.
- Give a debug handle: Force-display citation sources so every answer traces back to a specific chunk. A bad case then tells you immediately whether retrieval missed or generation drifted.
- Split the mechanism first: Temperature scales the logits by a constant before softmax. The smaller T, the sharper the distribution. At 0, every step locks onto the highest-probability word.
- Spring the trap: Low temperature locks "most likely," and most likely ≠ most correct. If that answer was wrong in the training data, the model will be extremely stably wrong.
- Give the boundary: Temperature only affects how each step is sampled. It does not move the knowledge boundary. Things the model doesn't know, it will still invent at low T — just more consistently.
- Give the conclusion: Parameter tuning is the cheapest first line of defense. It solves stability of expression. High-stakes factual accuracy still needs RAG or human review.
- Catch it first: Right, we shouldn't retrieve on everything. About 70% of conversations don't need a document lookup. "What's today's date" can just be answered.
- Give a filter: Put an intent classifier or simple keyword-trigger rules in front. Only things like "our refund policy" go through RAG — that can skip 30% to 70% of queries.
- Give a cache: High-frequency similar questions go through a semantic cache. Similarity above 0.95 returns the cached result and skips the whole retrieval path — latency and cost both drop by about half.
- Give the scenario boundary: Small talk and creative scenes were never a fit for RAG. Injecting retrieval just makes the answers stiff.
- Name it first: Classic source hallucination. Inventing numbers and inventing report titles use the same probabilistic continuation. Telling it "don't make things up" will not fix this.
- Give the first line of defense: System Prompt constraint: specific numbers, report names, and institution names that the user didn't provide must be marked "needs verification" — better to leave a blank for a human to fill.
- Give the second line: Tiered review. External materials are high-risk: AI does the first draft, and a human must sign off before it goes out.
- Close the loop: This bad case goes into the eval set and through attribution → Prompt iteration → regression. That's how recurrence of the same class actually drops.
- Give the mechanism: When the model predicts each Token, every Token in the context is shaping the probability distribution. Constraint words are high-quality prefix: they raise the probability of the "admit I don't know" sequence and suppress the fabrication sequence.
- Give when it works: Most effective when the model itself is uncertain about the question — out-of-knowledge questions, vague queries, time-sensitive information.
- Give when it fails: When the model is highly confident in a wrong answer, the top candidate is already wrong and constraint words can't intervene. Systematic errors in the training data, and outdated knowledge treated as fact, all sit here.
- Give the pairing: In domains that are "highly confident but possibly wrong," Prompt constraints aren't enough. Pair them with RAG to inject real knowledge, or a human-review backstop.
- Build a baseline before launch: Use a set of questions with known correct answers as a hallucination test set, quantify the rate, and set a gate. Course-case protocol: factual accuracy 94.2%, hallucination rate 5.8% against a target under 3% — miss the target, don't ship.
- Tiered review after launch: Auto-route by risk: low-risk goes out, high-risk waits for a human. In finance and healthcare, AI only produces a first draft.
- Run a long-term feedback loop: Hallucinations found in review become bad cases and go through attribution → Prompt iteration → regression. In the course case, discovery-to-fix averaged 3.2 days.
- Put the metric in the PRD: "Hallucination rate under 3%" should be a quantifiable acceptance criterion, same as "load time under 2 seconds."
- Answer it head-on: Eval guarantees known risk points don't recur. Long-tail issues outside the test set can still hallucinate. Passing eval has never meant comprehensively reliable.
- Give a data view: Look at loop speed, not just this week's new count. Course-case rhythm: 12 new bad cases this week, 47 already fixed and archived, regression pass rate 96.8%.
- Give the process: Every bad case goes through four steps: discover, attribute, iterate the Prompt, regress. After the fix it joins the test set, and the eval set thickens as it rolls.
- Give the root-cause explanation: The model has no self-check. One wrong Token becomes the base for the next, and error accumulates. Eval plus review is an external correction layer on the output — it catches results, it does not control the generation process itself.
- Split the error type first: Was the context given wrong, or is this knowledge simply not in the parameters? The two fixes are completely different, and the wrong direction wastes a lot of time.
- Give the debug order: Try Prompt first: complete the task description, rules, and examples, then retest. If the knowledge is in the training data and the issue is format, style, or tone, Prompt can fix it — 100× cheaper than retraining.
- Decide whether you need RAG: Private knowledge, real-time data, anything after the knowledge cutoff — it isn't in the parameters. More Prompt won't help; you need retrieval injection.
- Fine-tuning last: A fixed professional-domain style, or a need to change the reasoning paradigm — those are worth fine-tuning. Fine-tuning changes behavioral style; it is the wrong tool for injecting time-sensitive knowledge.
- Explain the mechanism first: It has no motive to lie — it's doing probabilistic continuation. After "did you eat?", "I ate" is the highest-frequency reply pattern in the training corpus. When pressed, it invents concrete details by contextual probability.
- Name the alignment boundary: Only when the user explicitly challenges it does RLHF alignment training make it admit it has no body. If the user doesn't push, it will keep performing, and confidence does not drop because the content is false.
- Give the key insight: Hallucination and creativity share a source. The vivid tomato-and-egg-noodle detail and the copy it writes use the exact same capability. Kill hallucination and you kill creativity with it.
- Give a product action: Set strategy by scene: role-play in small talk is harmless; factual scenes need RAG and review to suppress it. One global knife cut does both jobs badly.
- List the high-frequency traps: Raising Temperature makes it smarter — actually just more random. RAG made the model learn the docs — actually just a temporary runtime injection. The model is calling an API — actually it only output formatted text. It got it wrong so retrain — actually try Prompt first, 100× cheaper.
- Dig the shared root: All four come from not separating training from inference. Once parameters are frozen, every runtime method is operating on context.
- Lift it to a method: Every engineering operation is, at bottom, manipulation of the message list. Look at any new proposal through that lens and you can tell which layer it acts on and where it stops.
- Give a self-positioning: Close with the Dunning-Kruger curve: the most dangerous moment is right after you learn the nouns, when you feel like you understand everything. Keep building, keep getting punched in the face, and you walk from the Peak of Mount Stupid onto the plateau.
Why “LLM Fundamentals · 30 Tough Questions” can find relevant content
“Each with intent, framework, and bonus points: probability prediction / message list / hallucination explanation / RAG vs retraining / Temperature / context window” moves retrieval beyond storing material: the real question is how to find what is relevant. That decision shapes the input quality of RAG, recommendation, and image-search systems.
Similarity is not the answer
In the flow described by “Each with intent, framework, and bonus points: probability prediction / message list / hallucination explanation / RAG vs retraining / Temperature / context window”, embeddings place items in a comparable semantic space and a neighbor index narrows the search. The final answer still depends on whether the retrieved chunks cover the question, whether the distance metric fits, and whether the evidence is current.
- Lead with the essence: An LLM is a massive probabilistic prediction machine. It does one thing at a time: given all existing Tokens, it predicts the probability distribution for th…
- Distinguish training from inference: Training is learning statistical patterns from enormous text data. When you're chatting with it, the parameters are frozen — it's not learning…
- Address the thinking question directly: It doesn't think in the human sense, yet at sufficient scale it demonstrably exhibits reasoning-like behavior. So neither deify it nor dismi…
Separate findable from relevant
Turn “Each with intent, framework, and bonus points: probability prediction / message list / hallucination explanation / RAG vs retraining / Temperature / context window” into a small test: prepare queries with known answers, record relevance, misses, and distractors, then decide whether chunking, the index, or reranking needs to change.
Take the example one step further
The lesson starts with “Lead with the essence: An LLM is a massive probabilistic prediction machine. It does one thing at a time: given all existing Tokens, it predicts the probability distribution for the next Token and generates tok…” and then moves to “Distinguish training from inference: Training is learning statistical patterns from enormous text data. When you're chatting with it, the parameters are frozen — it's not learning, it's computing”. Reading those two pieces together makes the distinction clearer: which points are facts in the lesson, and which judgments depend on their conditions.
Carry the judgment into the next situation
The same logic applies to retrieval: define what counts as relevant, check whether recall covers the question, and then inspect whether ranking, chunking, or freshness pushed useful evidence out.
- “LLM Fundamentals · 30 Tough Questions”: Lead with the essence: An LLM is a massive probabilistic prediction machine. It does one thing at a time: given all existing Tokens, it predicts the probability distribution for the next Token and generates tok…
- “Take it further”: Distinguish training from inference: Training is learning statistical patterns from enormous text data. When you're chatting with it, the parameters are frozen — it's not learning, it's computing
- “The closing point”: Reveal the core: The model is fundamentally a text-completion machine. "Dialogue" means packaging the conversation history in chat-log format and having the model complete the assistant's next turn
The final “The closing point” brings the discussion to “Reveal the core: The model is fundamentally a text-completion machine. "Dialogue" means packaging the conversation history in chat-log format and having the model complete the assistant's next turn”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.