Learning adjusts a model using examples
In traditional programming, people often specify the rules directly. Machine learning uses training data and optimization to adjust parameters so a model performs a task better. Parameters and new inputs then shape the result.
Learning patterns doesn't make every answer correct. The range, quality, and biases of training data affect performance. Evaluation should include examples not used for training.
A cat-and-dog classifier must work on new photographs, not just recognize the pictures it trained on.
Take this with you · Evaluate models on real tasks and unseen examples.
Layers of adjustable calculations
Neural networks consist of layers of numerical operations with adjustable parameters, not biological neurons. Training changes those parameters to improve an objective. Different architectures suit different tasks.
“Early layers see edges, later ones see shapes” is a useful intuition in some settings, not a universal explanation. For now, understand that inputs pass through multiple transformations.
An image passes through computations and produces category scores. A score is a model output, not an unquestionable fact.
Take this with you · Think of a neural network as a trainable computational structure, not a tiny human brain.
Language models process and generate tokens
Language models represent text as tokens and generate output in context. A token may be a word, part of a word, or another text fragment. It is not always one English word or one Chinese character.
Training and later adjustments develop language and other patterns. A model has not read every page on the internet, and expert-sounding language doesn't guarantee factual accuracy.
Different tokenizers may split the same phrase differently. Character counts alone cannot precisely tell you whether material fits a model's context window.
Take this with you · Understand tokens as processing units; use the relevant tokenizer for exact counts.
From your message to inference and tools
Using a model to produce a result is called inference. An application gathers your input and context, calls a model locally or through a network interface, and presents the result. This is different from training the model.
An application can provide search, file reading, or execution tools. Their results become information the model can use. Available tools depend on the application and permissions, not just the model's name.
“I changed the file” in a reply is not the same as an actual file diff. Tool actions and inspectable artifacts establish what happened.
Take this with you · Separate generated claims from actions that tools actually performed.
Context limits and plausible mistakes
A model can handle a limited context at once. Applications may truncate, summarize, or retrieve older information. A long conversation doesn't guarantee that every detail remains visible verbatim. Keep crucial background in a concise, maintained project note.
Models can produce plausible but incorrect content, often called hallucination. Search and other tools can provide evidence but don't guarantee correctness. Check sources for important claims and run and test code.
If an earlier “local storage only” constraint is missing from a later cloud-based proposal, inspect the effective context rather than only saying “you forgot.”
Take this with you · Provide key constraints explicitly and verify important results independently.
What fits inside a context window?
Add messages to a limited window, watch an old constraint leave, then make it visible again through a pinned project note.
Add messages and watch whether the earliest constraint stays visible.
Cards are not actual tokens. This uses simple first-in-first-out removal; real applications may summarize or retrieve context.
AI confidently says the code runs, but you haven't seen execution evidence. What next?
Choose an answer before reading the explanation.
Write a short project handoff that lets a new conversation continue your list project.
Think first, then uncover help as needed. Later chapters expect more complete descriptions and clearer checks.
Bring this chapter's context to your AI. Going deeper is optional; you can keep reading without it.
Explain training and inference using practice exercises and exams, including where the analogy fails.
One approach you can make your own
I'm learning computers and AI-assisted programming from scratch. In this chapter I learned: AI：Distinguish training from inference when using a model；Understand tokens, context windows, and tools；Explain why fluent answers still need verification Explain training and inference using practice exercises and exams, including where the analogy fails. Check my understanding first. Explain one small question at a time with a concrete example and the limits of any analogy. Ask a scenario question, then adapt to my answer. Distinguish facts, guesses, and uncertainty; suggest hands-on ways to check. Confirm the version before giving tool-specific advice, and don't invent features or references.
Complete this chapter
Mark the sections as read, finish the experiment, and pass the scenario check to record completion. You can visit the next chapter at any time.
Read the original references
This is an introduction. These official resources help you check details and explore further.
Google · Introduction to large language modelsNow put your understanding into practice: choose useful context, clear tasks, and explicit boundaries.