AIT common mistakes
AIT · Understand the traps and how to avoid them.
Treating 'AI' as synonymous with 'machine learning', so questions asking which subfield handles planning, search, or knowledge representation get answered with ML techniques.
Most real-world exposure to AI is through ML products, so the broader classical-AI taxonomy (search, planning, reasoning, robotics, NLP, vision) is never learned as a map.
What to do instead
Build a one-page taxonomy of AI subfields with a defining task for each, and practice sorting sample problems (route finding, theorem proving, image classification, translation) into the right subfield.
Confusing the terms narrow/general/superintelligent AI with the learning paradigms supervised/unsupervised/reinforcement, answering a 'type of AI' question with a 'type of learning' answer.
Both sets are introduced with similar vocabulary and lists, and the labels overlap in casual speech.
What to do instead
Make a two-column table: capability scope (narrow, general, super) vs. learning paradigm (supervised, unsupervised, self-supervised, reinforcement), and write one concrete example per cell.
Mixing up classification and regression, or choosing an accuracy metric for a regression task (or accuracy for a heavily imbalanced classification task).
Candidates memorize algorithm names without linking each to its output type and its standard evaluation metric.
What to do instead
For each algorithm on the syllabus, write output type (discrete label vs. continuous value), typical loss, and default metric; then drill metric-selection questions on imbalanced and regression scenarios.
Treating training data, validation data, and test data as interchangeable, and concluding that poor test performance should be fixed by tuning on the test set.
The purpose of each split is understood as a memorized rule rather than as protection against optimistic bias.
What to do instead
State the role of each split in one sentence (fit, tune/select, unbiased estimate) and practice identifying the correct split to use in scenarios describing hyperparameter choice, model comparison, and final reporting.
Assuming a deeper or larger neural network always performs better, and diagnosing underfitting versus overfitting backwards.
Capacity concepts are learned as slogans; the direction of the train-vs-validation gap is not interpreted carefully.
What to do instead
Use the gap rule explicitly: high training error and high validation error means underfitting (increase capacity, train longer, reduce regularization); low training error with high validation error means overfitting (regularize, augment, get more data).
Describing backpropagation as a separate learning algorithm that adjusts weights by itself, rather than as gradient computation combined with an optimizer update.
Textbook diagrams collapse forward pass, loss, backprop, and optimizer step into one arrow, so the division of labour is lost.
What to do instead
Write out the four-step loop (forward pass, compute loss, backpropagate gradients, optimizer updates weights) and identify which step each exam scenario is asking about.
Confusing tokenization, embeddings, and attention: claiming embeddings are the model's output text, or that attention is a database lookup of stored answers.
These components appear together in transformer diagrams, and the pipeline order is rarely tested during study.
What to do instead
Draw the pipeline in order (raw text, tokens, token IDs, embeddings, attention/transformer layers, output probabilities, decoded text) and label what each stage produces.
Explaining hallucination as the model 'lying' or retrieving a wrong stored fact, instead of next-token prediction producing fluent but unsupported content.
Anthropomorphic framing of LLM behaviour is common in popular coverage.
What to do instead
Practice phrasing the mechanism in terms of probabilistic generation without a guaranteed fact-check step, and pair it with mitigations (retrieval grounding, citations, human review, uncertainty signalling).
Treating fairness, transparency, and accountability as optional 'nice-to-haves' appended after deployment, rather than as requirements that shape problem framing, data collection, and monitoring.
Ethics content is often skimmed as a list of principles without being connected to lifecycle stages.
What to do instead
Map each principle (fairness, explainability, accountability, privacy, safety) to at least one concrete lifecycle action and one failure it prevents, then answer scenario questions by locating the lifecycle stage first.
Assuming a model that passed pre-deployment testing needs no post-deployment monitoring, ignoring data drift, concept drift, and feedback loops.
Deployment is imagined as a finish line, and drift is treated as an advanced topic rather than a routine operational risk.
What to do instead
Memorize the operational trio (input drift, concept drift, feedback loops) with one example each, and tie them to monitoring practices such as performance dashboards, alert thresholds, and scheduled retraining or rollback plans.