Disclosure: This article was generated with AI and reviewed against the source transcript and the primary documentation linked below.
A hypothetical sensor-classification project produces an impressive accuracy score. An engineer opens the missed examples and discovers that recordings from the same session appear on both sides of the evaluation. The score no longer answers the question the team intended to ask.
The useful contribution was knowing where to look when the result seemed too easy.
Aleks Gornik’s video on electrical engineering and AI connects mathematical training, application knowledge, physical systems, and infrastructure constraints. His claims about which discipline will dominate are opinions. The practical lesson I draw is to begin an AI project with a domain error that you are qualified to investigate.
That gives the project a more useful purpose than demonstrating that you can call a model.
Describe a failure in the original task
Suppose the project concerns classifying sounds from a small authorized collection of machine recordings. Before selecting a model, write down what someone would do with the classification and which mistakes would matter.
A missed unusual sound and an unnecessary inspection are different outcomes. Their significance depends on the actual use case. In this example, the classifier is a research exercise, not equipment-control software or a validated diagnostic system.
The domain description should identify the recording conditions, what a label represents, and which uncertainties remain unresolved. A label inherited from a filename deserves different confidence from a label supported by a documented inspection.
This work makes the later result interpretable. Without it, a numerical score can measure consistency with labels whose meaning nobody has established.
Inspect how the data was produced
List the steps between the physical event and the stored record. In the hypothetical example, those steps include recording, segmentation, labeling, and feature preparation.
Ask where related samples might share information. Several excerpts from one recording can contain the same background conditions. Depending on the intended evaluation, separating individual excerpts may fail to test performance on genuinely new recording sessions.
The appropriate split follows the intended question. A project about new equipment, new environments, or later sessions needs evidence aligned with that scope. Describe the scope explicitly rather than treating a convenient split as universally correct.
Scikit-learn’s guidance on common pitfalls warns about data leakage and inconsistent preprocessing. Its examples provide a useful check on evaluation design, while the particulars of this sensor project still require their own review.
Build an error notebook
For each inspected mistake, save the record identifier, expected label, observed output, relevant conditions, and the explanation you are considering. Mark explanations as hypotheses until an additional check supports them.
One error might expose a label problem. Another might suggest that the chosen representation loses information. A third might remain unexplained. Keeping these cases distinct prevents every failure from becoming a request for a larger model.
Include successful cases that should have been difficult. They can reveal accidental shortcuts just as mistakes can reveal limitations.
The notebook should make a later experiment reproducible. Record what changed and which existing cases were used to guide that change. Preserve a separate evaluation suited to the question you still need to answer.
Show what your expertise changed
A portfolio description becomes more credible when it explains a concrete judgment. Describe the questionable evaluation you found, the reason it was questionable, the change you made, and the limits of the resulting evidence.
If the revised result is weaker, report that. A more realistic measurement can be a better engineering contribution than a larger number produced by an unsuitable test.
The video’s broad comparison between engineering concepts and AI should encourage investigation, not an assumption that distinct fields are interchangeable. Familiar mathematics is a starting advantage only when it helps answer the project’s actual question.
Choose one small problem where you can inspect the underlying records and explain a failure in ordinary domain language. Build the demonstration around that explanation and the evidence needed to test it.