AI Skill Report Card
Integrating and Scaling ML Models
YAML--- name: integrating-and-scaling-ml-models description: Guides embedding AI/ML capabilities (vision, speech, NLP, OCR) into applications, from problem definition through on-device optimization and production-scale deployment. Use when adding "smart" features to an app, deciding between on-device and cloud inference, optimizing model performance for mobile/edge constraints, or building the full lifecycle pipeline from raw data to a monitored production model. --- # Integrating and Scaling ML Models
Quick Start14 / 15
Given a request like "add handwriting OCR to this app," work through the pipeline end-to-end rather than jumping straight to a model:
1. Define objective (SMART): "Extract text from photographed documents,
>90% word accuracy, <500ms latency, works offline."
2. Choose deployment target: on-device (offline, low-latency, limited compute)
vs. cloud (heavy compute, needs connectivity, easier to update).
3. Pick/build model: e.g., PaddleOCR for text detection + region proposal,
then a quantized TFLite model for text recognition.
4. Optimize for target device: quantize (int8), prune, or distill the model
to cut size/power without meaningful accuracy loss.
5. Wrap in a pipeline: image in -> detection -> recognition -> structured
JSON out, with a hard latency budget per stage.
6. Ship, then monitor: track real-world accuracy and drift; plan retraining.
Example output contract for OCR:
JSON{ "document_id": "abc123", "text_blocks": [ {"bbox": [x, y, w, h], "text": "Invoice #4471", "confidence": 0.94} ], "processing_ms": 412 }
Recommendation▾
Add a third example showing a failure/bad outcome scenario (e.g., a case where quantization alone wasn't enough or monitoring was skipped and drift occurred) to satisfy 'both good and bad outcomes'.
Workflow14 / 15
Progress checklist for any AI/ML integration task:
- [ ] 1. Problem Definition & Data Readiness
- [ ] 2. Experimentation & Training (or model selection, if using pre-built)
- [ ] 3. On-Device / Runtime Optimization
- [ ] 4. Productionization & Scaling
- [ ] 5. Monitoring & Retraining Plan
1. Problem Definition and Data Readiness
- Write a SMART objective: Specific, Measurable, Achievable, Relevant, Time-bound (e.g., "reduce OCR word error rate from 12% to <5% within one sprint").
- Identify data sources: existing app logs, IoT sensors, public datasets, user-submitted samples.
- Preprocess: normalize inputs (image resizing, audio resampling, text tokenization), handle missing/corrupt samples, run quick EDA (class balance, outliers, quality distribution) before committing to a model.
2. Experimentation and Training
- Engineer features only if training a custom model; if using a pre-trained model, skip to selection criteria.
- Model selection criteria, in priority order: accuracy on representative data → inference latency → model size → licensing/cost.
- Split data (train/val/test, e.g. 70/15/15). Tune hyperparameters against the validation set only; report final numbers on the untouched test set.
3. On-Device / Runtime Optimization
- Convert the trained model to a mobile-friendly format (TFLite, Core ML, ONNX Runtime Mobile).
- Apply quantization (float32 → int8/float16) as the default first optimization — usually 2-4x size reduction with minimal accuracy loss.
- Apply pruning or distillation only if quantization alone doesn't meet the latency/size budget.
- Benchmark on actual target hardware (not just desktop/emulator) for latency, memory, and battery draw.
- Decide hybrid fallback: run on-device by default, fall back to cloud for cases exceeding on-device model confidence thresholds.
4. Productionization and Scaling
- Containerize training and serving code (Docker) so results are reproducible across environments.
- Build a pipeline (e.g., Vertex AI Pipelines, Kubeflow) to automate retraining and versioned artifact storage in cloud storage (GCS/S3).
- Deploy behind a scalable serving layer (Vertex AI Endpoints, SageMaker, TF Serving) with autoscaling configured for expected traffic peaks, not just averages.
5. Continuous Monitoring
- Track prediction confidence distributions and input data distributions over time to catch drift.
- Set concrete retrain triggers: e.g., accuracy drop >3% over rolling 2-week window, or drift score exceeds threshold.
- Version every deployed model and keep rollback to the previous stable version fast.
Recommendation▾
Include concrete numeric benchmarks or a decision table for on-device vs cloud tradeoffs to strengthen the completeness section.
Examples15 / 20
Example 1: On-device feature recognition Input: "Add object recognition to a camera app; must work offline, run on mid-range Android phones." Output:
- Objective: ">85% top-5 accuracy on common household objects, <200ms inference, <15MB model."
- Model: MobileNetV3 pre-trained, fine-tuned on target object classes, converted to TFLite, int8 quantized.
- Deployment: bundled with app (no cloud dependency), NNAPI/GPU delegate enabled for hardware acceleration.
- Monitoring: log low-confidence predictions (anonymized) for periodic review and future fine-tuning batches.
Example 2: Handwriting OCR pipeline Input: A blurry photo of a handwritten document. Process: PaddleOCR detects text block regions → quantized TFLite recognition model converts each region to text. Output: A JSON file of detected text blocks with bounding boxes and confidence scores, delivered in under 500ms, usable offline.
Recommendation▾
Consider adding a brief troubleshooting/FAQ subsection for common integration errors (e.g., quantization accuracy collapse, ONNX conversion failures) to round out edge case coverage.
Best Practices
- Always state the objective in measurable terms before picking a model or architecture.
- Default to the smallest/cheapest model that clears the accuracy bar — optimize down from a working baseline, not up from nothing.
- Quantize first; only prune/distill if quantization doesn't hit the target.
- Design the fallback path (on-device → cloud) explicitly rather than assuming one mode covers all cases.
- Treat monitoring and retraining as part of the deliverable, not an afterthought — define drift/accuracy thresholds at launch time.
- Benchmark on real target hardware; emulator/desktop numbers are misleading for latency and battery.
Common Pitfalls
- Choosing a model based on published benchmark accuracy without testing on the actual target data distribution.
- Skipping containerization, leading to "works on my machine" deployment failures.
- Deploying without autoscaling configured for peak load, causing outages under real traffic.
- Treating on-device deployment as "just export to TFLite" without validating latency/battery on low-end devices.
- No monitoring plan post-launch — model silently degrades as real-world data drifts from training data.
- Over-optimizing (aggressive pruning/distillation) before establishing whether quantization alone already meets requirements.