What Machine Learning Consulting Actually Covers

The work spans data, models, and the production engineering that connects them. Most failing ML systems do not fail because the model architecture was wrong; they fail because the data pipeline corrupted silently, the feature store drifted from training to serving, the evaluation harness missed a regression, the labeling guidance produced inconsistent labels, or the deployment process turned a 24-hour model update into a six-week project. A good ML consultant works on whichever layer is the actual bottleneck, which is rarely the part the team is currently arguing about.

• Data pipeline architecture: ETL, ELT, streaming, batch, change data capture, schema evolution, idempotency, backfill
• Feature store design and operation: online-offline parity, point-in-time correctness, freshness, governance
• Labeled dataset strategy: annotation pipelines, inter-annotator agreement, active learning, label drift detection
• Model selection: classical ML (gradient boosting, linear models), deep learning, foundation-model fine-tunes, hybrid LLM-plus-ML systems
• Evaluation discipline: holdout strategy, time-based splits, fairness metrics, regression testing, A/B test design
• MLOps tooling: training pipelines, model registry, deployment, monitoring, retraining triggers, rollback
• Drift and monitoring: feature drift, label drift, concept drift, prediction drift, the differences and the responses to each
• Production decisioning: real-time vs batch, latency budgets, fallback policies, cost-per-prediction instrumentation
• Hybrid systems: LLM and traditional ML stitched together, with the LLM handling natural language and the ML handling structured prediction

When You Need an ML Consultant, Not Just More Engineers

The signal is rarely a missing technology. It is a missing system. The team has data scientists who can build a notebook model and engineers who can ship a service, but nobody who has run a production ML system through three years of model decay, schema changes, and on-call. The gap shows up as silent failure: production metrics that drift while dashboards stay green, retraining that breaks because a feature changed two months ago, evaluation that no longer reflects real customer behavior.

• A production model has degraded but nobody can tell whether it is data drift, feature pipeline corruption, or a code change
• Training and serving have diverged because the feature store does not enforce point-in-time correctness
• The team is shipping models from notebooks because the deployment pipeline is half-built
• Labeling guidance is inconsistent, inter-annotator agreement is unmeasured, and model quality is capped by label quality
• Retraining is a six-week project because the pipeline was built around a single training run
• A new ML use case is being scoped and the team is debating build vs buy across a vendor list nobody has pressure-tested
• A regulator, auditor, or insurer is asking for model documentation the team cannot produce
• An LLM feature is shipping but the existing ML systems (ranking, classification, scoring) are tangled with it and nobody owns the integration
• A new senior ML hire is being recruited and the company needs interim leadership during the 4-6 month search

Data Pipeline Architecture, the Foundation Most Teams Skip

Every ML failure eventually traces back to the data pipeline. The model is downstream of the pipeline; if the pipeline lies, the model lies. Good ML consulting starts at the pipeline because investments in model architecture are wasted when the data layer is unreliable. In 2026, the practical default stack mixes batch (dbt, Spark, BigQuery, Snowflake) with streaming (Kafka, Flink, Pulsar) and change data capture, with strong contracts between producers and consumers.

• Schema contracts: producers and consumers agree on schemas, breaking changes are versioned, schema-on-read is a tax that compounds
• Idempotency: every transform is replayable without side effects, backfill is a normal operation not an emergency
• Streaming vs batch: choose by freshness requirement and per-event cost, mix where the workload demands it
• Change data capture: Debezium, Fivetran, native CDC from Postgres, MySQL, MongoDB, used for both analytics and ML feature freshness
• Data quality tests: Great Expectations, Soda, dbt tests, custom checks, wired to alerts the team actually responds to
• Lineage: end-to-end lineage from source to model so a bad prediction can be traced to its data origin
• Cost discipline: warehouse query cost, streaming infrastructure cost, storage tiers, all instrumented per use case
• Governance: PII tagging, access policies, audit logs, classifications aligned to the company's data governance posture

Feature Stores: When You Need One and When You Do Not

Feature stores are oversold. Most companies that bought one before they needed it have a half-used Tecton, Feast, or Hopsworks deployment that the team works around. Feature stores earn their keep when there are multiple models sharing features, when online-offline parity is a real failure surface, or when point-in-time correctness has bitten the team. They are wasted when one model has bespoke features and the team is small.

• Online-offline parity is the core value: the feature seen in training is the feature seen in serving, full stop
• Point-in-time correctness: training samples reflect what was known at the time of the label, not present-day values
• Feature reuse: when 5+ models share features, a feature store pays back; with one model, it usually does not
• Self-hosted (Feast on Redis or DynamoDB, Hopsworks) vs managed (Tecton, Databricks Feature Store, Vertex AI) is a contract and operational decision
• Streaming features: real-time aggregations need different infra than batch features; many feature stores are weak on this
• Embedding features: vector embeddings as features are now standard, blurring the line between vector stores and feature stores
• Governance: feature ownership, deprecation policy, documentation requirements
• A simple alternative: shared SQL-backed feature views with strict point-in-time queries can replace a feature store at small scale

Labeling Strategy and Dataset Quality

Model quality is capped by label quality. Teams that have not measured inter-annotator agreement are guessing about model performance. Teams that pay a label vendor without spec discipline get inconsistent labels that no model architecture can recover from. Good labeling is a system: clear guidance, regular calibration, active learning, drift detection on labels themselves, and continuous feedback from production back into the labeling pipeline.

• Annotation guidelines: written, versioned, with worked examples for ambiguous cases
• Inter-annotator agreement: measured per task, published, used to decide when to retrain annotators
• Vendor strategy: Scale AI, Surge, Labelbox, Sama, in-house, or hybrid, chosen by sensitivity and volume
• Active learning: prioritize uncertain examples for labeling rather than random sampling
• Label drift detection: production sample relabeled regularly to detect schema or guidance drift
• Synthetic labels: LLM-generated labels for high-volume coarse tasks, validated against human labels
• Production feedback loop: ambiguous or wrong predictions surfaced back into labeling
• Bias and fairness audits: subgroup label quality measured, not just overall

MLOps in 2026: What Actually Matters

MLOps as a category has matured. The MLOps market reached $4.39 billion in 2026 with a 45.8% CAGR projected through 2034. Tooling has consolidated around a handful of opinionated stacks: managed (Databricks, Vertex AI, SageMaker), cloud-native open-source (Kubeflow, MLflow on Kubernetes), and lightweight ergonomic (Modal, Weights and Biases, ZenML, Metaflow). The choice matters less than the discipline. A team with weak discipline and the most expensive stack still ships unreliable models.

• Training pipeline: declarative, reproducible, parameterized, runnable on a local dev box and on production infra
• Model registry: every model artifact is tagged with training data version, code version, evaluation metrics, and approval status
• Deployment: canary, shadow, blue-green, with automatic rollback on regression metrics
• Monitoring: prediction drift, feature drift, label drift, latency, cost-per-prediction, all visualized and alerted
• Retraining: triggered by drift or schedule, with a documented decision rule for promotion to production
• Experiment tracking: Weights and Biases, MLflow, Neptune, all integrated with the training pipeline so experiments are reproducible
• CI for ML: model evaluation runs on every change to training code or features, blocking merges that regress the harness
• Observability: Arize, Fiddler, WhyLabs, Evidently for production ML monitoring, integrated with the team's general observability stack
• Most MLOps platforms are production-ready in 2-3 months when the team is disciplined; longer when the team is being trained alongside the build

Hybrid LLM-and-ML Systems, the Default in 2026

The dominant production AI pattern in 2026 is a hybrid: an LLM handles natural-language understanding, generation, and orchestration, while traditional ML handles ranking, classification, scoring, forecasting, and anomaly detection. The two halves are stitched together with retrieval, tool use, and structured outputs. Teams that treat AI as purely an LLM problem leave value on the table; teams that treat AI as purely an ML problem miss the leverage of foundation models. The ML consultant's job in 2026 includes designing this seam.

• LLM as orchestrator, ML as specialist: the LLM routes a query, calls an ML model as a tool, formats the response
• LLM-augmented training data: structured labels generated by an LLM, validated against human labels, used to train cheaper specialist models
• Embedding features as inputs to traditional ML models: dense representations of text, images, or behavior as feature columns
• Ranking and recommendation systems augmented with LLM-generated explanations, query expansion, or candidate generation
• Hybrid retrieval combining vector embeddings, BM25, and trained classifiers
• Fraud, churn, and anomaly detection still dominated by gradient boosting and trained classifiers; LLMs handle the human-readable layer
• Computer vision and speech still dominated by specialist models, with LLMs handling the natural-language layer
• Cost arithmetic: LLM inference is expensive at volume, so push as much as possible to cheaper specialist models with the LLM only on the irreducible language layer

Engagement Shapes and Pricing in 2026

ML engagements come in three common shapes: a focused diagnostic on a specific failure mode, a project-scoped delivery, or a multi-month retainer. The rates below reflect what a senior independent ML practitioner with significant production experience charges in 2026.

• US hourly: $200-$450/hr for senior ML specialists, $250-$350/hr is the realistic median
• US day rate: $2,000-$4,500/day, with $2,500-$4,000 standard for hands-on ML work
• US monthly retainer (2-3 days/week): $25,000-$55,000
• UK day rate: GBP 1,000-1,800/day in London, GBP 800-1,200 outside it
• EU day rate: EUR 1,200-2,400/day in major hubs
• 2-4 week ML diagnostic engagement: $15K-$50K fixed fee, producing a system audit, drift analysis, and remediation plan
• 6-16 week ML delivery engagement: $50K-$250K, producing a shipped pipeline, model, or MLOps platform component
• Full MLOps platform build benchmark from industry surveys: $200K-$600K over 3-6 months
• Interim head of ML: $40K-$80K per month at 4-5 days per week during a 3-6 month leadership search
• Red flag: under $150/hr is a junior data scientist; over $1,000/hr without specific specialism is selling brand

Red Flags When Hiring an ML Consultant

The market is split between practitioners who have been on-call for production ML systems and practitioners whose ML experience is Kaggle and a notebook. The signal is whether they can describe a recent production incident in detail and what the postmortem changed.

• Cannot describe a production ML incident they were involved in resolving
• Treats model architecture as the most important lever rather than the data pipeline and evaluation harness
• Has no opinion on the build vs buy question for feature stores at the company's scale
• Cannot whiteboard online-offline parity and point-in-time correctness
• Quotes evaluation as "we use accuracy" without engaging holdout strategy, time-based splits, fairness metrics, or A/B test design
• Treats labeling as a vendor purchase rather than a system with guidelines, agreement metrics, and feedback loops
• Resells a specific MLOps platform with undisclosed commercial relationship
• Has no opinion on the LLM-plus-ML hybrid pattern and treats them as separate worlds
• Cannot quote, at the order-of-magnitude level, the cost of running a model serving 10 RPS, 100 RPS, 1000 RPS on standard infra
• Has never participated in a production rollback of a model that was performing worse than the previous version

FAQ