Huawei HCIA-AI common mistakes
Huawei HCIA-AI · Understand the traps and how to avoid them.
Treating the Huawei AI strategy layer as marketing trivia and skipping the full-stack naming (Ascend chips, CANN, MindSpore, ModelArts, Atlas hardware), then being unable to map a product to its layer when a scenario question asks which component handles training, inference, or deployment.
Candidates assume strategy questions are unscored filler or pure memorization of slogans, so they don't build the layer-to-product mental model, and they confuse overlapping names (Atlas vs Ascend, CANN vs MindSpore) under time pressure.
What to do instead
Build a one-page layer map: chip (Ascend 310/910) → compute framework (CANN) → AI framework (MindSpore) → platform (ModelArts) → hardware products (Atlas servers, edge, modules). For each product write one sentence on its role and one typical deployment scenario, then self-test by covering the map and naming the layer for a random product.
Answering 'what is AI/ML/DL' questions by intuition rather than using the nested-set relationship, and mislabeling rule-based or expert-system examples as machine learning because they 'look smart'.
The taxonomy seems too basic to study, and everyday usage blurs AI, ML, and DL, so candidates pick the broadest or most impressive-sounding label instead of the technically correct one.
What to do instead
Memorize the strict nesting AI ⊃ ML ⊃ DL and the defining criterion for ML: performance improves from data rather than hand-coded rules. Drill with 15 short scenarios and force yourself to justify each label in one sentence ('learns parameters from data' vs 'follows fixed rules').
Confusing supervised, unsupervised, and reinforcement learning when the question describes the data rather than the algorithm name, e.g., calling clustering supervised because labels exist in the dataset description, or calling regression classification because the output is numeric.
Candidates memorize algorithm names without the label/objective criterion, and exam stems often embed distractors (a labeled dataset used for evaluation, or a continuous target) that trigger the wrong association.
What to do instead
Anchor every answer on two questions: are training labels provided, and is the target discrete or continuous? Then classify. Practice by rewriting each scenario into a one-line 'input → label? → target type' note before choosing, and keep a table pairing each algorithm with its required data type.
Mixing up overfitting and underfitting symptoms and their remedies, for example recommending more training epochs or a larger model for overfitting, or applying dropout when the model performs poorly on both training and test sets.
The two failure directions feel symmetric in memory, and candidates remember remedies as a list without attaching each to the training-vs-validation error pattern that identifies it.
What to do instead
Learn the diagnostic signature: high training error plus high validation error means underfitting; low training error plus high validation error means overfitting. Attach remedies to each signature (more capacity/features/epochs vs regularization, dropout, early stopping, more data, simpler model), then classify 10 described curves before answering.
Choosing accuracy as the evaluation metric for imbalanced classification problems, or confusing precision and recall when the question describes the cost of false positives versus false negatives.
Accuracy is the default metric candidates reach for, and precision/recall definitions are easily swapped because both are phrased as 'correct positives over something'.
What to do instead
Fix the definitions with the denominator: precision = TP/(TP+FP), recall = TP/(TP+FN). Tie each to a business cost (spam filter cares about false positives; disease screening cares about false negatives). For imbalanced data, prefer precision, recall, F1, or AUC and be able to say why accuracy misleads.
Treating activation functions as interchangeable and being unable to state why nonlinearity is required, or asserting that sigmoid in hidden layers is the standard modern choice for deep networks.
Activation functions are memorized as formulas without their gradient behavior, so candidates cannot connect vanishing gradients to the choice of sigmoid/tanh versus ReLU in deep stacks.
What to do instead
For each of sigmoid, tanh, ReLU, and softmax, write the output range, the typical layer it belongs to (hidden vs output), and its gradient weakness. Then answer the conceptual question explicitly: without a nonlinear activation, stacked layers collapse into a single linear transform.
Confusing the roles of forward propagation, backpropagation, and the optimizer, e.g., saying backpropagation updates weights directly or that the loss function performs the parameter update.
Textbook descriptions compress the training loop into one sentence, so the chain-rule gradient computation and the optimizer's update step blur into a single remembered phrase.
What to do instead
Write the training loop as four separate steps: forward pass produces output, loss function measures error, backpropagation computes gradients via the chain rule, optimizer (SGD/Adam) applies the update using the learning rate. Recite the loop and label which component owns each step until the boundaries are automatic.
Assuming TensorFlow and MindSpore code are structurally identical, so questions about MindSpore's execution modes, context configuration, or device management get answered with TensorFlow habits (eager-first default, tf.device placement).
Candidates learn one framework deeply and pattern-match the other, missing that MindSpore uses explicit context setup for device and graph/eager mode and has its own tensor and nn APIs.
What to do instead
Write a minimal training script in both frameworks side by side: data loading, model definition, loss, optimizer, and training step. Highlight where MindSpore requires context configuration and where TensorFlow relies on default eager execution. Memorize the MindSpore equivalents of the TensorFlow calls you use most.
Mixing up CANN's role with MindSpore's, or describing Ascend 310 and 910 as interchangeable, leading to wrong answers on which component compiles/optimizes operators for Ascend hardware versus which provides the high-level model development API.
The stack has adjacent layers with overlapping-sounding purposes, and candidates learn the acronyms without the boundary between compute-architecture enablement and model-development framework.
What to do instead
State each layer's job in one line: CANN enables and optimizes operators on Ascend hardware; MindSpore is the model development and training framework; Atlas packages Ascend into servers, edge, and module form factors. Also record that 310 targets inference/edge and 910 targets training, then quiz yourself on 'which layer does X' for a dozen tasks.
Answering deployment and hardware-selection scenarios by picking the most powerful option rather than matching the workload, e.g., recommending a training-class device for a low-power edge inference task, or ignoring the role of model conversion and operator support when moving a trained model to Ascend.
Candidates equate 'best accuracy/performance' with 'correct answer' and skip the constraints embedded in the scenario (power, latency, cost, existing framework), and they underestimate the conversion and operator-compatibility step in real deployments.
What to do instead
For every scenario, extract constraints first (training vs inference, cloud vs edge, latency, power, framework of origin), then map to the matching product tier. Memorize the deployment pipeline: train, convert/export model, verify operator support on the target, quantize/optimize, deploy and serve. Practice by writing the constraint list before reading the answer options.