Which practice is considered a standard dependency-management hygiene step for an AI engineering project?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Check this out — dependency messes wreck more demos than bad models sometimes. Here's the deal: you isolate each project in its own virtual environment, whether that's venv, conda, or another tool. Think of it like this: separate toolboxes for separate jobs so a wrench from Project A doesn't break Project B. You pin what you need, you don't dump the whole internet into site-packages, and you still use git so teammates get the same stack. If your boss walks in and says "why does my laptop train differently than prod," missing isolation is often the culprit. Exam trap answers will push "one giant file," "no version control," or "install everything." Don't take the bait. Isolated env, documented deps, reproducible runs. Got it? Keep rolling.
Full explanation below image
Full Explanation
Dependency management is a foundational AI engineering practice because modern stacks combine Python packages, CUDA-related wheels, data tools, and framework releases that change frequently and often conflict. The widely accepted baseline is to create an isolated environment per project—commonly with venv, virtualenv, conda, poetry, or similar tools—so installs do not pollute a shared global interpreter and so two projects can depend on different library versions safely.
Isolation pairs with explicit declaration of dependencies. Teams record packages and versions in files such as requirements.txt, environment.yml, pyproject.toml, or lock files, then recreate the environment on laptops, CI runners, and servers. Combined with source control, those files become part of the project history, enabling reviews, rollbacks, and consistent builds. Container images often wrap the same idea one layer higher by freezing OS packages and Python deps together for deployment.
The wrong options illustrate anti-patterns that show up in rushed student projects and poorly run teams. Collapsing all code into a single file does not solve version conflicts and makes testing and reuse harder; it is a code-organization problem, not a dependency solution. Refusing version control removes the primary mechanism for sharing and auditing dependency manifests and code together. Installing every library globally "just in case" maximizes conflict risk, slows installs, obscures true requirements, and makes environments unreproducible across machines.
Practical tips include pinning versions for production, regenerating lock files deliberately, separating dev and prod extras, documenting Python and CUDA baselines, and verifying installs in clean CI. For GPU work, record driver-compatible package builds carefully. When collaborating, prefer environment recreation from files over "it works on my machine" screenshots. Exam questions on this topic nearly always reward virtual (or equivalent isolated) environments and punish options that reject isolation, reject source control, or encourage indiscriminate global installs. That single habit—isolated, declared, versioned dependencies—prevents a large class of silent training and inference failures.