Alibaba ACA GenAI common mistakes
Alibaba ACA GenAI · Understand the traps and how to avoid them.
Treating Qwen model variants (e.g., base vs. chat/instruct vs. code vs. math-specialized, and small vs. large parameter sizes) as interchangeable and picking the largest or newest model for every scenario instead of matching model family to task.
Candidates memorize that Qwen is a model family and assume 'bigger is better', overlooking that instruction-tuned, code-specialized, and smaller models each fit different cost/latency/quality trade-offs.
What to do instead
Build a mental matrix: task type (chat, code, reasoning, multilingual) x deployment constraint (latency, cost, context length) -> recommended Qwen variant. Practice justifying a model choice for a stated scenario rather than defaulting to the flagship.
Confusing the roles of pretraining, fine-tuning (SFT), and alignment/RLHF stages, and mislabeling which stage produces instruction-following or safety behavior.
The pipeline stages blur together, and candidates attribute capabilities like instruction adherence to the wrong stage.
What to do instead
Map each stage to its outcome: pretraining -> base language knowledge; SFT -> instruction following; alignment -> safety/preference behavior. Answer stage questions by asking 'what behavior is being added?'
Conflating core generative-AI concepts such as tokenization, embeddings, context window, temperature/top-p, and hallucination, and applying the wrong lever when asked to change model behavior.
These terms appear together and candidates learn surface definitions without linking each parameter to an observable effect.
What to do instead
For each concept, write the input, the mechanism, and the observable effect. Practice scenario prompts like 'make output more deterministic' (lower temperature) or 'input exceeds limits' (context window/tokenization) and match to the correct control.
Treating Model Studio as a single monolithic tool and failing to distinguish its components (model/agent orchestration, prompt engineering, RAG/knowledge retrieval, plugin or tool calling, and application publishing) when asked which feature solves a given requirement.
The platform bundles many capabilities, so candidates pick a familiar-sounding feature instead of the one designed for the requirement.
What to do instead
Create a requirement-to-feature table: knowledge grounding -> retrieval augmentation; external actions -> tool/plugin calling; reusable behavior -> prompt/agent configuration. Map each scenario to exactly one capability.
Designing RAG flows without separating retrieval quality from generation quality, and assuming adding documents alone fixes wrong answers.
Candidates equate RAG with 'upload data', skipping chunking, indexing, and retrieval-relevance steps that determine whether the right context reaches the model.
What to do instead
Diagnose failures in order: is the correct passage retrieved (chunking/index/query)? Is it passed into the prompt (context assembly)? Does the model use it (prompt instruction)? Fix the failing layer, not just the corpus size.
Ignoring prompt/agent configuration details like system prompt scope, variable/parameter placeholders, and output format constraints, then blaming the model when the application misbehaves.
Candidates focus on the model choice and treat prompt configuration as trivial, missing how system instructions and structured output requirements shape responses.
What to do instead
Review every application scenario for the four prompt levers: role/system instruction, input variables, output format/schema, and constraints. Verify each is specified before concluding the model is at fault.
Confusing PAI's model development artifacts (training jobs, datasets, and registered models) with deployment/serving artifacts (online inference endpoints, resource specs), and answering as if training automatically serves the model.
The train-to-serve lifecycle spans distinct stages, and candidates collapse them into one step.
What to do instead
Memorize the lifecycle: data -> training job -> model artifact/registration -> deployment to an inference service -> endpoint invocation. For each question, identify which stage is being asked about before choosing an answer.
Mismatching compute/resource choices to workload (e.g., GPU type or instance sizing for training vs. inference, or assuming any instance can serve any model) and ignoring scaling/throughput considerations.
Candidates treat resource selection as a generic 'pick a GPU' decision without linking model size, latency, and concurrency to instance and scaling choices.
What to do instead
Tie resources to workload: training needs memory for gradients/optimizer state; inference needs memory for weights plus throughput for concurrency. Practice choosing instance and scaling settings for stated latency/cost targets.
Using Lingma as a generic chatbot and missing its coding-assistant capabilities (in-IDE code completion, code explanation, unit-test generation, and repository/enterprise context awareness) when asked which feature fits a developer workflow.
Candidates know Lingma as 'an AI assistant' and default to chat-style answers instead of mapping IDE-integrated coding tasks to the right capability.
What to do instead
List Lingma's developer-facing functions and match each to a workflow step: writing code -> completion; understanding code -> explanation; verifying -> test generation; enterprise consistency -> context/knowledge integration.
Overlooking enterprise-agent concerns such as data privacy/governance, permission scoping, and human-in-the-loop or tool-call safety when evaluating an agent design, and choosing the most autonomous option by default.
Candidates equate 'agentic' with 'fully automated' and treat governance as an afterthought rather than a design constraint.
What to do instead
For any agent scenario, check four things before selecting an answer: data boundary/governance, access permissions, tool-call validation, and human oversight for high-impact actions. Prefer designs that satisfy these over maximal autonomy.