Skip to content

PATTERN Cited by 1 source

Trip Classification

Trip classification is the pattern of running each trip (or trip-segment) through a classifier that assigns it to a discrete category, and then selecting a category-specific downstream model / ETA surface / route-scoring policy based on the classification output. The classifier is the load-bearing artifact: without it, the category-specific surfaces can be neither trained (no clean per-class labels) nor served (no runtime signal to pick a surface).

The pattern shows up when a single homogeneous model under-fits because the population is bi- or multi-modal on an observable but latent-at-inference-time axis. Rather than try to absorb the axis into the base model's features, you split the surface along that axis and condition on the classifier output at both training time (for label assignment) and serving time (for surface selection).

Canonical instance — Google Maps HOV-specific ETAs (2025-06-30)

Google Maps needed to serve ETAs and route options that account for HOV-lane speed advantages. The announced architecture, at the level of detail the raw exposes:

  1. Classifier: a "classification system to determine HOV trips from non-HOV trips".
  2. Training-time role: produce per-trip labels so an HOV-specific ETA surface can be trained on only HOV trips, without contamination by non-HOV trip times on the same road segments.
  3. Serving-time role: at ETA-query time, classify the trip and route it to the right ETA surface; drivers opting into HOV routes see the HOV ETA rather than a lane-agnostic one.
  4. Motivation signal: HOV vs. general lane speed gap is material — Utah Salt Lake Valley 68.18 mph vs. 58.60 mph (~16%) — large enough that a single lane-agnostic ETA biases both HOV and non-HOV predictions (Source: sources/2025-06-30-google-hov-specific-etas-google-maps).

When the pattern fits

  • Latent-at-inference axis dominates residual error. If your single-model residuals cluster by some category (lane type, trip purpose, vehicle class, rider tier), classification-first splitting often beats adding another feature to the base model.
  • Category count is small and stable. Two (HOV / non-HOV) or a handful (driving / cycling / transit / walking) keeps the per-surface training-data budget manageable.
  • Per-surface evaluation / rollout matters. Separate surfaces are separately evaluable, separately ramp-able, and separately rollback-able — useful for staged launches.

When it doesn't

  • Too many categories. If the classifier output space is large and sparse, per-surface data budgets collapse and a single model conditioned on category features wins.
  • Category boundary is fuzzy or classifier accuracy is poor. Misclassifications now flip the user to the wrong ETA surface instead of just perturbing a single model's features.

Seen in

Last updated · 200 distilled / 1,178 read