Deep Learning Applications

01Purpose and scope

• This manual supports the course Deep Learning Applications. It describes how practitioners move a neural network from a business or research question to a working system that makes useful predictions on data it has not seen before. The focus is on the practical work: framing the problem, preparing data, choosing and training architectures, judging results, and keeping a model reliable after release.
• The scope covers supervised learning for images, text, audio, and tabular data, along with transfer learning and fine-tuning of pretrained models. It does not cover the mathematical derivation of backpropagation or the design of new architectures from first principles, although both appear in the course material. Reinforcement learning and generative systems receive only brief mention because their evaluation and safety practices differ enough to warrant separate treatment.
• Deep learning is a poor fit for some problems. A small table of clean numeric records with a known formula, or a task where a rule set is easy to audit, often gives better results with less cost. Part of the job is recognizing those cases early and saying so to the people paying for the work.
• This guidance does not replace qualified professional judgment, approved internal procedures, or required authorization. In medicine, finance, employment, public safety, and similar fields, a model may be subject to licensing, validation, or oversight requirements that vary by jurisdiction. Check the current requirements with the responsible authority and your organization's governance group before any model influences a decision about a person.

02Core principles

• Start with the decision, not the model. A useful framing names the action a prediction will trigger, the people who take that action, and the cost of each kind of error. A fraud model that flags one in a thousand transactions for manual review has a very different tolerance for false positives than a model that blocks payments automatically.
• Treat data as the main design surface. Most failures trace back to labels, sampling, or drift between training and production data rather than to the architecture. Spend time confirming where each record came from, how labels were assigned, and who was excluded from the collection process.
• Prefer the simplest model that meets the requirement. A pretrained convolutional network fine-tuned on a few thousand labeled images is often sufficient for a defect detection line. A larger model may add a fraction of a point of accuracy while increasing latency, memory use, and the effort needed to explain its behavior.
• Measure what the decision needs. Overall accuracy hides problems when classes are imbalanced. Choose metrics that reflect the cost of mistakes, and report them separately for groups that matter to the application, such as patient age bands, device types, or dialects.
• Plan for change from the start. Inputs shift, sensors get replaced, user behavior adapts to the model, and labels get revised. A deployment without monitoring and a retraining path is an unfinished deployment.

03Planning and preparation

• Begin with a short problem statement that names the input, the output, the decision the output supports, and the acceptable error profile. Write down what a good result looks like in plain terms before anyone opens a notebook. Agree on a baseline, which may be a heuristic, a logistic regression, or the current human process. A deep learning model should beat that baseline by a margin that justifies its added cost.
• Inventory the data. Record the source systems, the time span covered, the collection method, known gaps, and the license or consent terms that apply. For personal data, identify the legal basis for processing and any retention limits. Where rules depend on jurisdiction, such as the EU General Data Protection Regulation or state privacy laws in the United States, consult the current text from the relevant regulator or your legal team.
• Estimate compute and time. Training a model from scratch on a large image set can take days on a multi-GPU node, while fine-tuning a small pretrained model may finish in under an hour on a single card. Confirm access to hardware, storage, and the labeling budget before committing to a schedule.
• Assign roles early. A typical team includes a domain expert who defines correct labels, a data engineer who builds pipelines, a modeling lead who selects architectures and training methods, an evaluator who owns the test protocol, and a platform engineer who handles serving. In small teams one person may hold several roles, but the evaluation role should stay separate from the training role where possible.
• Select tools and standards that fit the environment. Common frameworks include PyTorch and TensorFlow, with experiment tracking through tools such as MLflow or Weights and Biases. For risk management, the NIST AI Risk Management Framework and ISO/IEC 23894 give useful vocabulary and structure, though neither prescribes a specific model design. Choose tools your organization can support after the project team moves on.

04Recommended workflow

1. 1
   : Define the task and the acceptance criteria. Write the input and output formats, the decision the output feeds, the minimum acceptable performance on named slices of the data, and the maximum latency. Get sign-off from the people who will own the decision, not only from the team building the model.
2. 2
   : Build the dataset and a fixed split. Separate training, validation, and test sets before any exploratory modeling. For time-dependent data, split by time so that the test set represents the future. For patient or customer data, split by person or account so that one individual does not appear in both training and test sets.
3. 3
   : Establish the baseline. Train the simplest reasonable model and record its results on the validation set. Keep the baseline in the experiment log so later improvements can be compared fairly. If the baseline already meets the acceptance criteria, document that and stop to consider whether deep learning is needed.
4. 4
   : Choose an architecture and a starting point. For images, a pretrained backbone such as a ResNet or EfficientNet variant is a common start. For text, a pretrained transformer encoder is typical for classification and extraction. For tabular data, gradient boosted trees often remain competitive, so compare them honestly before adopting a neural network.
5. 5
   : Train with disciplined experiments. Change one major factor at a time, such as learning rate, augmentation, or unfreezing depth. Log the seed, code version, data version, and hardware for every run. Use early stopping on the validation set, and watch for overfitting by comparing training and validation loss curves.
6. 6
   : Evaluate on the held-out test set once per candidate. Compute the agreed metrics, plus per-slice results, calibration curves, and a sample of errors reviewed by a domain expert. Do not tune on the test set. If the test set is used repeatedly, it becomes a second validation set and its results lose their value as an estimate of real performance.
7. 7
   : Package and deploy under a staged plan. Export the model to a serving format, measure latency and memory on target hardware, and run the model in shadow mode alongside the existing process. Move to limited rollout only after shadow results match the offline evaluation within the agreed tolerance. Keep a rollback path that the operations team has tested.
8. 8
   : Monitor and retrain on a schedule and on triggers. Track input distributions, prediction distributions, and when available, outcome labels. Define thresholds that trigger investigation, and document each retraining decision with the reason for it.

05Quality checks, risk controls and compliance

• Check the data before the model. Look for duplicate records across splits, label noise on a random sample, missing values that correlate with the target, and proxies for protected attributes such as postal code standing in for race or income. Document each check and its result. A short data sheet that accompanies the dataset is often enough to prevent confusion later.
• Test for robustness. Evaluate the model on images with altered brightness, on text with typos, or on audio with background noise, depending on the application. Record how performance degrades. If a small change in lighting causes a large drop in accuracy, the deployment conditions need to be controlled or the training data needs to be broadened.
• Assess fairness and subgroup performance with metrics chosen before the analysis. Equal false positive rates, equal false negative rates, and calibration within groups cannot all hold at once when base rates differ, so the team must decide which tradeoff matches the application and explain that decision in writing. Involve people who understand the affected population in that decision.
• Control access and change. Restrict who can modify training data, promote a model to production, or change a threshold. Keep model versions immutable and linked to the code and data that produced them. Require review for changes that affect decisions about people.
• Plan for human oversight. For high-impact uses, define when a person reviews a prediction, what information the reviewer sees, and how overrides are recorded. A model that produces a score with no explanation of its reliability invites automatic acceptance, which is a known failure pattern in automated decision systems.
• Map obligations to the setting. Medical software may require regulatory clearance before clinical use. Credit and employment decisions may trigger adverse action notice or anti-discrimination requirements. Automated decision rules in some jurisdictions give individuals rights to explanation or review. Confirm the current obligations with qualified counsel, the relevant regulator, and your compliance function. Nothing in this manual establishes compliance on its own.

06Collaboration and documentation

• Write a model card for every model that leaves the experiment stage. The card should state the intended use, the training data sources and their known limits, the evaluation protocol, the metrics with confidence intervals, the slices where performance is weaker, and the conditions under which the model should not be used. Keep it short enough that operations staff will read it.
• Maintain an experiment log that links each run to its configuration, data version, and results. Teams that rely on memory or on file names like final_v3_new end up unable to reproduce their own best model. A shared tracker, even a simple one, saves time when someone asks why a threshold was chosen.
• Hold regular reviews between the domain expert, the modeling lead, and the operations owner. The domain expert catches label errors that the modeling team cannot see. The operations owner knows which failures generate support tickets and which go unnoticed. Schedule these reviews around milestones rather than calendar dates alone.
• Share results with decision makers in plain language. Replace phrases like AUC of 0.91 with statements about what fraction of real defects the line will catch and how many good parts it will reject. Include the cost of each error type using figures the business has provided, and state clearly where those figures are estimates.

07Measures and continuous improvement

• Track indicators at three levels. Offline measures include accuracy, precision, recall, calibration error, and per-slice results on the test set. Online measures include latency, throughput, error rates reported by users, override rates by human reviewers, and the share of predictions that fall in the uncertain band. Outcome measures link model use to the decision goal, such as reduced inspection time, fewer missed defects, or faster claim processing.
• Watch for drift with simple statistics first. Compare the distribution of key input features and the predicted class mix against the training period each week or each month, depending on volume. Population stability measures or a two-sample test on features can flag shifts, but a flagged shift is a reason to investigate, not an automatic reason to retrain.
• Set retraining rules that match the data. A model trained on slowly changing sensor data may need retraining quarterly, while a model that handles fast-moving social media text may need more frequent updates with stricter review. Every retrained model should go through the same evaluation and shadow process as the original, with a documented comparison to the current production model.
• Close the loop with labels. Build a process for collecting ground truth after decisions are made, including the cases where the model abstained or a human overrode it. Without those labels, monitoring can only detect input change, not performance change. Budget for the labeling work as part of ongoing operations.

08Common mistakes and how to prevent them

• Leakage between training and test data is the most common and most damaging mistake. It appears when features are computed using information from the future, when the same patient appears in multiple splits, or when preprocessing statistics are fit on the full dataset before splitting. Prevent it by building the split first and fitting all transformations only on the training partition.
• Reporting the best run instead of the typical run inflates results. Random seeds and small changes in hyperparameters can shift scores noticeably. Run several seeds for the final configuration and report the mean and spread.
• Overusing the test set during development causes optimistic estimates. Teams that check the test score after every change end up selecting models that happen to fit that particular sample. Keep a clean final test set and use validation data for all selection decisions.
• Deploying without a shadow period hides integration problems. Input formats, image orientation, timestamp time zones, and missing field handling often differ between development and production. Run the model against live inputs before it affects any decision.
• Ignoring the cost of inference leads to systems that cannot meet latency or budget limits. Measure inference time and memory on the production hardware early, and consider distillation, quantization, or a smaller architecture when the numbers do not fit.
• Treating a model as finished after launch causes silent decay. Assign an owner, schedule monitoring reviews, and set a date by which the model must be revalidated or retired. Models that nobody watches tend to fail quietly.

09Practical checklist

• Write the decision, the action it triggers, and the cost of each error type before modeling begins.
• Confirm the data source, consent or license terms, and any retention limits with the appropriate owner.
• Create train, validation, and test splits by person, account, or time as the application requires, before exploratory work.
• Build a simple baseline and record its results so later models have a fair comparison.
• Log seeds, code version, data version, hyperparameters, and hardware for every training run.
• Evaluate the final candidate once on the held-out test set with overall, per-slice, and calibration metrics.
• Review a sample of errors with a domain expert and record the patterns found.
• Run the model in shadow mode on live inputs and compare results with offline evaluation before any rollout.
• Publish a model card with intended use, limits, and conditions for non-use, and assign a named owner.
• Schedule drift monitoring, label collection, and a retraining or retirement review with dates and responsible people.

★Learning sources

• Micro Degree: Deep Learning Applications
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics