Learn
Start with the building blocks.
A few concepts to help you ask better questions and make more deliberate choices when working with AI.
01 / Language models
What is a token?
A tokenizer turns text into smaller units called tokens. A token may represent a whole word, part of a word, punctuation, or another piece of text. The exact split depends on the tokenizer and the input.
A language model works with numeric representations of these tokens. When it generates text, it predicts a next token from the preceding context, then continues from the extended sequence.
A simple illustration
Build something useful.
We could illustrate this as Build | something | useful | ., but an actual tokenizer may divide it differently. Spaces can also affect tokenization.
This is a conceptual example, not the output of a particular tokenizer.
Why it matters: context limits and usage measurements often count tokens rather than words. A word count is not an exact token count, especially across different languages.
02 / Local computing
What does local AI mean?
Local AI usually means running a model on your own device or infrastructure instead of sending each request to a hosted model service. For example, a laptop might run a downloaded model to help summarize a document.
The model still needs computing resources. Memory, model size, and hardware affect what can run and how quickly it responds. A smaller model may be easier to run, but you still need to test whether it handles your task well.
Follow the data.
Imagine a document summarizer with three steps: read a file, run the model, save a summary. To understand whether it stays local, check all three steps—and any search, logging, or external tools the application uses.
A local model alone does not guarantee that the entire application keeps data on the device.
Why it matters: local computing can give you more control over deployment and data flow. It also makes hardware, maintenance, and model evaluation part of the work.
03 / Testing ideas
How do you know it works?
Begin by defining what a good result means for your task. A summary might need to preserve key facts without adding claims. A classifier might need to choose the correct category, including for unusual examples.
Build a small test set with ordinary cases, difficult cases, and inputs where the right response is to acknowledge missing information. Keep some examples separate from the ones you use while improving the prototype.
Try a summary checklist.
- Are the important facts included?
- Does every claim have support in the source?
- Are names, dates, and numbers accurate?
- Does the result follow the requested length and format?
Use the same checklist to compare versions. Record failures as well as successes.
Why it matters: fluent output can still be wrong. Repeated tests, comparisons with a simple baseline, and feedback from intended users give you a better picture than one successful demonstration.
Turn a concept into an experiment.
Choose a small question, describe what success would look like, and explore a possible project direction.
Explore proposed directions ↗