Python for AI & Machine Learning
Begin with one hand-checkable AI decision and run every required result in Python’s standard library. Add scientific libraries, neural frameworks, hosted models, vector stores, and production services only after the underlying data, numerical, evaluation, authority, and recovery claim is clear and separately verified.
Your first AI decision: question, baseline, data, and run identity
Objective Run one four-row routing baseline, calculate its accuracy by hand, and bind the result to exact input bytes.
Core explanation
An AI project begins with a decision, not a library import. Name the user outcome, the action taken from a prediction, the cost of errors, and a simple non-model baseline before training anything. The first program routes every ticket to general and compares that rule with four fixed labels. Two labels are general, so the learner can calculate accuracy as two divided by four before running Python. Exact input bytes receive a SHA-256 fingerprint, and the manifest records a Python 3.9-compatible runtime boundary. This proves one deterministic local baseline and data identity. It does not prove that the tiny rows represent future users, that accuracy is the right decision metric, or that any scientific package, trained model, provider, accelerator, service, or production system ran.
Begin with four rows, not an installation wall
The required baseline has four fixed labels and one always-general rule. Predict two matches before running Python, then inspect the exact data fingerprint and standard-library scope.
Representative data, decision costs, scientific packages, trained models, providers, accelerators, serving, and production remain separately evidenced adapters.
Separate the interpreter, project, data, configuration, and artifacts
A Python program runs inside one interpreter process. That process has a Python version, an executable path, an import search path, installed distributions, environment variables, current directory, locale, and operating-system libraries. These are inputs to the result even though they do not appear in a function signature. An isolated virtual environment gives a project its own installed distributions, but it does not automatically freeze data, configuration or system libraries. Invoke tooling through the intended interpreter, for example `python -m pip`, and record `sys.executable` when diagnosing a mismatch. The import name used in code can differ from the distribution name installed by a package manager, so verify both the imported module location and distribution metadata instead of assuming that a successful import proves the expected build is active.
Organize a learning project so each kind of state has one role. Importable transformations and training code belong under source control; tests describe executable contracts; configuration is explicit data; raw snapshots are immutable inputs; and generated models, reports and caches live in run-specific artifact directories. A notebook is useful for exploring a question, but its hidden cell order and mutable global namespace make it a poor sole definition of a pipeline. Restart the kernel and run from the first cell to expose accidental state, then move reusable logic into functions callable from a clean process. Never overwrite the raw input during cleaning. If a later result looks surprising, preserving the original bytes lets the learner distinguish a changed parser from changed source data.
Lock dependencies as a complete runtime contract
A direct dependency such as NumPy brings transitive dependencies and may resolve to different versions on different dates or platforms. A project declaration expresses what versions are acceptable for development; a lock artifact records the exact resolution selected for a supported environment. Record the Python implementation and version, lockfile digest, platform and accelerator constraints, because the same package version can use different wheels, compiled libraries or numerical kernels. Recreate environments from the declaration and lock rather than copying a long-lived directory whose history is unknown. A version pin alone is not enough if a mutable download, unrecorded system package or runtime-selected model file can change underneath it.
Diagnose environment failures from facts in dependency order. First confirm the executable and Python version, then inspect the imported module path and version, then compare the installed dependency graph and lock digest, and finally check native-library and device information relevant to the failure. “Works in the IDE” often means the IDE selected a different interpreter; “works after reinstalling” destroys evidence about which dependency was wrong. Preserve the failing manifest before changing anything and reproduce in a fresh environment. Keep registry credentials, API keys and private indexes outside manifests and source control. Record only their configured identity or provider class where useful, because reproducibility never justifies copying a secret into an artifact.
Understand what seeds can and cannot reproduce
A pseudo-random generator produces a deterministic sequence from its internal state. Setting a seed chooses a starting state; it does not create one universal random stream for an entire application. Python, NumPy, data loaders and machine-learning frameworks can each own separate generators, and libraries may create child streams for parallel workers. Pass generator objects explicitly where APIs support them and derive documented child seeds when independent streams are required. Data order is also part of the computation: adding one random draw, changing worker count or reading files in a different order can shift every later result even when the initial seed is unchanged.
Some numerical operations are nondeterministic because parallel reductions can occur in a different order, accelerator kernels use atomic updates, or a library selects a different implementation for new hardware. Floating-point addition is not perfectly associative, so these order changes can grow during training. Distinguish three claims: the procedure can be rerun from retained inputs, repeated runs produce statistically compatible quality, and the output bytes are identical. Most AI experiments require the first two; exact bytes may be impossible or unnecessarily expensive. Record deterministic settings, device and known exceptions, test metrics within justified tolerances or intervals, and investigate changes larger than the expected run-to-run variation.
Create a run manifest before work and verify it from a clean process
Treat a run as a transformation from immutable identified inputs to validated outputs. Before training, canonicalize configuration and record source revision, clean or patched source state, Python version, dependency-lock digest, dataset and split fingerprints, feature contract, random-stream policy and relevant hardware. Generate one run identity and write artifacts beneath a new directory; do not reuse “latest” as durable identity. Metrics, logs, checkpoints and the final model are outputs attached to that identity. Publish a completion marker only after required files validate and their hashes are recorded, so a crashed directory cannot masquerade as a successful model candidate.
Verification begins in an empty process or newly created environment, not in the notebook that produced the result. Rebuild or locate input snapshots by digest, run the documented entry point, load the artifact through its public interface, and compare contract predictions plus declared statistical metrics. If reproduction fails, compare manifests from the outside inward: data bytes and partition identity, configuration, code, environment, device, random streams, then algorithmic output. A timestamp difference is harmless when excluded from semantic identity; a different test partition is not. Keep the last accepted artifact intact while diagnosing a candidate, and document whether the result achieved procedural, statistical or exact-byte reproduction rather than using the word “reproducible” without a testable meaning.