You are shipping a search page that mixes four result panels: Companies, People, Jobs and Posts. Each vertical already returns its own ranked list, but nobody has decided which panel goes on top. There are zero logged clicks because the page has never existed. Training a model is impossible: there is no label to learn from yet.

A heuristic is the right first move. Write a small scoring function per panel, something like score = 0.5 * intent_match + 0.3 * user_affinity + 0.2 * result_quality. Intent match comes from the query classifier you already have (a query like “software engineer jobs in Austin” scores high for Jobs). User affinity is a simple count of which panel this member clicked most in the last 30 days, or a default if they are new. Result quality is the top result’s relevance score from the vertical, normalised to 0 to 1. Sort panels by score and render.

The value of this step is not accuracy. It is three things: you can launch this week, product managers can reason about and override the weights, and you start logging impressions and clicks with the exact features the eventual model will need. Add a small amount of randomisation, for example swapping adjacent panels 5 percent of the time, so the logs are not hopelessly biased toward whatever the rule already puts first.

After four to six weeks you will have enough labelled data (panel shown at position, panel clicked or not) to train a GBDT classifier on the same three features plus a dozen more. The heuristic then becomes your baseline to beat, and you can retire it with a clean A/B test rather than a leap of faith.

A new marketplace is being hit by bot sign-ups. The team wants a fraud model, but the fraud team has only manually reviewed forty accounts and the patterns are still shifting week to week. Building a supervised classifier on forty examples would be worse than useless: it would overfit to the exact bots you happened to catch.

Instead, codify what the reviewers already know into rules. Block if the email domain is on a disposable-email list. Flag for review if more than five accounts were created from the same IP in an hour. Flag if the display name contains a URL. Score each account by summing rule hits with hand-chosen weights, and route anything above a threshold to the review queue.

These rules are transparent, which matters for a trust and safety team that has to explain decisions to legitimate users who get caught. They can be adjusted in minutes when a new bot pattern appears. Crucially, every rule hit and every reviewer decision gets logged, which turns the review queue into a labelling pipeline.

The moment to move on is when the rules start fighting each other: when you have thirty rules, several with exceptions to other rules, and nobody can predict what a change will do. At that point you typically have thousands of reviewed accounts, and a GBDT classifier trained on the same rule features plus raw account attributes will outperform the hand-tuned weights while keeping most of the explainability through feature importance.

A fitness app wants to send one push notification per day and has three candidate messages: a streak reminder, a friend-activity update, and a new-workout announcement. The product team has strong opinions about which is appropriate when, but no experiment has ever run.

Encode the opinions as an ordered decision list. If the user has an active streak that expires today, send the streak reminder. Otherwise, if a friend completed a workout in the last 24 hours, send the friend update. Otherwise send the workout announcement, but never more than once a week. Add a global cap of one notification per day and a quiet-hours window.

This is a policy, and it is good enough to launch. More importantly it defines the action space and the reward you will later need for a contextual bandit: the actions are the three messages, the context is streak status and friend activity, and the reward is whether the user opened the app within two hours. Because the rule is deterministic, though, you will only ever observe rewards for the message the rule chose, so add a small exploration rate of around 10 percent where a random eligible message is sent instead.

After a few weeks the logs support offline evaluation of a bandit policy, and you can promote the bandit once it beats the rule in a held-out replay. The heuristic did not just buy time; it produced the exact logged data a learned policy needs.

A retailer needs to predict how many units of each product a regional warehouse will ship next week so it can set reorder quantities. The history is a clean weekly table: units shipped, week of year, whether a promotion ran, average price that week, and units shipped in the previous four weeks.

Linear regression fits this well because the drivers are mostly additive. A promotion adds roughly a fixed lift, a price cut of 10 percent adds a roughly proportional lift, and last week’s demand is the strongest single predictor. Fit units = b0 + b1 * last_week + b2 * promo + b3 * log(price) + seasonal terms, where the seasonal terms are a few sine and cosine features of the week number. Using the log of price and the log of units turns multiplicative effects into additive ones, which is the standard trick for making a linear model fit a naturally multiplicative process.

The output is easy to defend to a planning team: the coefficient on promo literally says how many extra units a promotion is worth, with a confidence interval. Residual plots will tell you quickly whether the linear form is adequate. If residuals fan out at high volume, a log target fixes it; if there is a clear seasonal wobble left over, add more Fourier terms.

Move to GBDT if the error analysis shows threshold effects, for example demand collapsing entirely when a product is out of stock at a competitor, or interactions like promotions working only in certain regions. Until then the linear model is faster to retrain, easier to monitor, and produces prediction intervals for free.

An API team wants to predict the latency of a request before it runs, so a load balancer can route heavy requests to a dedicated pool. The available features are payload size in kilobytes, number of items in the request, whether the user’s data is cached, and the current queue depth on the target host.

Latency here is close to linear in the obvious ways: each additional item costs a roughly constant amount of processing, each kilobyte costs a roughly constant amount of parsing, and queue depth adds a roughly constant wait per queued request. A linear regression on these four features, with an interaction term for items multiplied by not-cached (because uncached items are the expensive ones), explains most of the variance and is trivially cheap to evaluate inside the router itself.

The coefficients become operational knowledge. If the coefficient on payload size is 0.8 milliseconds per kilobyte, engineers immediately know what a compression change is worth. If the coefficient on queue depth jumps after a deploy, that is a regression worth investigating.

Watch for heavy tails. Latency distributions are usually skewed, so fit on the log of latency or use quantile regression if you care about the 95th percentile rather than the mean. And if the relationship stops being linear, for example because latency explodes past a memory threshold, a tree model will capture the cliff that a straight line cannot.

A dealership wants a quick estimate of resale value for trade-ins. The data is a few thousand past sales with make, model, year, mileage, condition grade, and sale price.

After one-hot encoding make and model and taking the log of price, a linear regression captures the main structure: value depreciates a roughly constant percentage per year and per ten thousand miles, and each condition grade shifts the price by a fixed multiplier. The log transform is essential, because depreciation is multiplicative, not additive: a car does not lose a fixed number of dollars per year, it loses a fixed fraction.

The model is explainable to the sales floor. A salesperson can say that this model year loses about 12 percent per year and that the difference between good and excellent condition is worth about 8 percent. Regularise with ridge or lasso so that rare make-model combinations with only a handful of sales do not get wild coefficients.

Limits show up in the residuals. Collector models that appreciate rather than depreciate, or vehicles with a known recall that crater in value, will be systematically mispriced by a linear model because the effect depends on a specific interaction the model cannot express without you hand-building it. If those cases matter commercially, a GBDT will find the interactions automatically. For a first version and for most of the inventory, the linear model is accurate enough and far easier to keep honest.

A streaming service wants to identify subscribers likely to cancel in the next 30 days so a retention team can reach out. Features per subscriber include days since last login, hours watched in the past four weeks, number of profiles, plan tier, whether a payment recently failed, and tenure in months.

Logistic regression is the right baseline. The outcome is binary, you have tens of thousands of labelled months of history, and the retention team needs to understand why someone was flagged. After standardising the numeric features, the fitted coefficients read directly as risk factors: a failed payment might multiply the odds of churn by four, each additional week without a login multiplies it by 1.5, and long tenure protects.

The probabilities are well calibrated out of the box, which matters because the retention team has a budget and needs to target, say, the top 5 percent by risk with expected churn above 40 percent. A calibrated model lets you set that threshold and predict how many people will actually churn in the targeted group.

Engineer a few interactions by hand where domain knowledge says they exist, such as failed payment combined with low usage, which is far riskier than either alone. If you find yourself adding many such terms, or if a quick GBDT on the same features beats the logistic model by a wide margin on held-out AUC, that is the signal that nonlinearity matters and it is time to switch. Even then, keep the logistic model as the interpretable shadow model that explains the decisions.

An ads team is launching a new placement and needs a pCTR model within a week to feed the auction. They have a few hundred thousand impressions from a soft launch with roughly a 1 percent click rate.

Logistic regression with hashed sparse features is the classic starting point for exactly this situation. Encode advertiser ID, creative ID, placement position, user country, device type, and hour of day as one-hot sparse features, add a handful of crosses that experience says matter (advertiser by country, creative by device), hash them into a few million buckets, and train with L2 regularisation and stochastic gradient descent. This trains in minutes, serves in microseconds, and produces calibrated probabilities that the auction can multiply by bid to get expected value.

Calibration is the reason this model is chosen over alternatives. An auction that overestimates CTR by 20 percent overcharges advertisers and misallocates inventory. Logistic regression’s probabilities are naturally calibrated on the training distribution, and a simple isotonic correction on a holdout fixes residual drift.

The weaknesses are known. The model cannot discover crosses you did not specify, and with sparse IDs it struggles with new advertisers. The standard progression is logistic regression first, then a GBDT once you have engineered dense features like historical CTR per advertiser, then a neural model with embeddings when data volume is in the hundreds of millions and the marginal gain justifies the serving cost.

A lender needs a credit approval model that regulators can audit and that can generate an adverse-action reason for every declined applicant. Features include income, debt-to-income ratio, credit history length, number of recent inquiries, and delinquency count.

Logistic regression is often mandatory in this setting, and for good reason. Every coefficient is a documented, signed effect. If the debt-to-income coefficient is negative, the model can never approve someone more because their debt went up, which is a monotonicity guarantee a black-box model cannot offer without extra constraints. When an applicant is declined, the top contributing features by coefficient times value become the adverse-action reasons the law requires.

Build it carefully. Bin continuous features into a small number of intervals using weight-of-evidence encoding so that a nonlinear relationship such as risk rising sharply above a threshold can be represented within a linear model. Check variance inflation to catch collinear features that would make coefficients unstable and unexplainable. Validate calibration by decile so that a predicted 5 percent default rate really is 5 percent.

A GBDT with monotonic constraints may squeeze out more AUC, and many lenders run one as a challenger. But the logistic scorecard remains the champion in most regulated portfolios because a two-point AUC gain rarely outweighs the audit and explainability costs of a model whose decisions cannot be traced to a signed weight.

A hospital wants a simple protocol nurses can follow at intake to flag patients who need a doctor within 15 minutes. Historical intake records include heart rate, blood pressure, oxygen saturation, temperature, age, and whether the patient was later admitted to intensive care.

A decision tree, deliberately limited to a depth of three or four, produces exactly the artefact the hospital needs: a printable flowchart. The tree might learn that oxygen saturation below 92 percent is the first split, then heart rate above 120 within that branch, then age above 70. Each leaf carries a probability of intensive care admission, which becomes the urgency category.

Nurses can apply the flowchart without a computer, the clinical lead can review every threshold and veto ones that look wrong, and the model can be printed on a laminated card. That is a level of transparency no ensemble provides, and in a clinical setting it is worth more than a few points of accuracy.

The trade-off is instability. Retraining on next year’s data could produce a tree with different splits, which would confuse staff. Fix the tree once it is reviewed and only retrain deliberately. If accuracy matters more than the flowchart, for example for a backend alerting system rather than a bedside protocol, a random forest or GBDT on the same features will be more accurate and more stable, and you can still extract approximate rules from it for documentation.

A telecom wants a clear, defensible rule for which customers get a free device upgrade. The marketing team has run the offer to a random sample and observed who accepted and stayed for the required 24 months versus who accepted and churned early.

A shallow decision tree turns that experiment into policy. It may find that customers with tenure above 18 months and a plan value above 50 dollars a month have a 78 percent retention rate after the offer, while customers with tenure below six months retain at only 31 percent regardless of plan. Those leaves become the eligibility rule, and the rule can be written into the CRM as a handful of if statements.

The reason to prefer a tree over logistic regression here is that eligibility rules are naturally threshold-based. Marketing does not want to communicate that eligibility increases smoothly with tenure; they want to say that customers with 18 months or more qualify. A tree finds the thresholds from data rather than by guesswork, and its structure maps directly onto the way the business will express the rule.

Cap the depth and set a minimum leaf size of a few hundred customers so the rule stays simple and the retention estimate in each leaf is trustworthy. When the business later wants a personalised probability rather than a yes-or-no rule, move to a GBDT that uses the same features.

A platform team wants to understand which factors predict continuous integration failures so they can give developers guidance. Each build is logged with the number of files changed, whether tests were modified, the time of day, the branch age in days, whether dependencies changed, and the result.

A decision tree is chosen for the insight rather than the prediction. Trained on a few months of builds, the tree might reveal that dependency changes are the dominant split, and that within builds with no dependency changes the next most important factor is branch age above ten days, presumably because stale branches conflict with main. Each path through the tree is a story the team can act on: rebase more often, isolate dependency bumps into their own pull requests.

This is a case where the model is used as an analysis tool. The team reads the tree, writes documentation, and may never deploy it. A random forest would predict failures better, but its output would be feature importances rather than legible paths, which is less useful for the goal of explaining behaviour to developers.

The standard caution applies: a single tree can change substantially with a different sample of builds. Train several trees on bootstrap samples and check that the top splits agree before treating them as findings. If they do not agree, the signal is weaker than the tree makes it look.

A manufacturer has sensor readings from a few hundred machines: vibration, temperature, power draw, and age, sampled hourly, plus maintenance records showing when each machine failed. They want an early warning model and have one week to build it.

Random forest is the pragmatic choice. It handles the mix of scales without preprocessing, is largely immune to a few noisy sensors, and needs almost no hyperparameter tuning: a few hundred trees with default settings will get you within a few points of a carefully tuned GBDT. Build features as rolling statistics over the previous 24 hours (mean, max, standard deviation of each sensor) and label each hour as positive if a failure occurred within the following 48 hours.

The out-of-bag error estimate gives you a validation score for free, which is helpful when data is limited and you would rather not hold out machines. Feature importances tell the maintenance team which sensors are worth watching, and partial dependence plots show the temperature at which risk starts climbing.

Random forest is also naturally cautious: because it averages many trees, its probability estimates are smoothed and it rarely produces extreme, overconfident predictions, which is appropriate when a false alarm triggers a costly inspection. Once the pipeline is proven, a GBDT with tuned learning rate will usually improve precision at the same recall, and that is the natural second iteration.

A data science team has assembled 1,200 candidate features for a customer lifetime value model, drawn from clickstream, purchase history, support tickets, and demographic tables. Before committing to a serving pipeline, they need to know which features are worth the engineering cost.

A random forest is the standard feature screening tool because it is fast to train on wide data, does not care about scaling or monotonicity, and produces two useful importance measures. Impurity-based importance is cheap but biased toward high-cardinality features; permutation importance on a holdout is slower but honest. Run both, keep features that rank in the top 100 on permutation importance, and drop the rest.

The forest also surfaces redundancy. If two features are highly correlated, the forest splits its importance between them, and dropping one usually costs nothing. Group correlated features, keep the cheapest one to compute in production, and you have cut the pipeline from 1,200 features to under 100 with a small accuracy loss.

The screening model is not the final model. Its job is to reduce the space so that a properly tuned GBDT can be trained and deployed on features that are actually available at serving time. This two-stage approach avoids the common failure where a team builds an elaborate model on features that turn out to be unavailable or too slow to compute in production.

An environmental agency has a few thousand hand-labelled pixels from satellite imagery, each with reflectance values in ten spectral bands, and wants to classify a whole region into water, forest, cropland, and urban.

Random forest has been the workhorse for this exact problem for two decades. The classes are separated by nonlinear combinations of bands (vegetation indices are ratios of bands, which trees approximate well), the training set is small, and the labels are somewhat noisy because pixel boundaries are fuzzy. A random forest with a few hundred trees handles all of this, trains in seconds, and gives per-class probability maps that highlight uncertain regions for further labelling.

Compared with a convolutional network, the forest needs orders of magnitude less labelled data and no GPU. Compared with a single decision tree, it is far more stable and does not fragment the map into noisy speckle. It also gracefully handles the case where some bands are missing due to cloud cover, if you impute or route missing values.

The forest ignores spatial context; each pixel is classified independently. When labelled data grows into the hundreds of thousands and the agency wants to distinguish subtle classes like crop types that depend on texture and neighbourhood, a convolutional model becomes worthwhile. Until then the forest delivers most of the accuracy for a fraction of the effort.

After launching with a heuristic, a search team has six weeks of logs showing which of four panels (Companies, People, Jobs, Posts) was shown at which position and whether it was clicked. The goal is a model that predicts click probability per panel per query, so the panels can be ordered by predicted click.

GBDT is the natural first learned model because the inputs are entirely structured: intent classifier confidence per vertical, the user’s historical click share per panel, number of results the vertical returned, freshness of the top result, aggregate relevance score, time of day, and device. Only four candidates are ranked per query, so scoring cost is negligible and the complexity of a neural model is unjustified.

Train a binary classifier on (query, panel, position) rows with the click label. Include position as a feature during training so the model learns position bias, then set position to a constant at serving time so every panel is scored as if it were at the top. This is the standard trick for debiasing click logs without a full counterfactual framework.

Evaluate offline with AUC and, more importantly, with the click-through rate at position one under the new ordering on a held-out week. Ship behind an A/B test against the heuristic. When the classifier is stable, the next step is LambdaMART, which optimises the ordering within each query directly rather than treating each panel independently.

A payments company processes millions of transactions a day and has a fraud rate near 0.2 percent, with chargebacks arriving weeks later as labels. Each transaction carries amount, merchant category, country, device fingerprint age, velocity counts (transactions in the last hour, day, week from this card), distance from the last transaction, and whether the shipping and billing addresses match.

GBDT dominates this problem. Fraud is defined by interactions and thresholds: an unusually large amount at a new merchant category from a device first seen an hour ago is suspicious, while any one of those alone is not. Trees find these combinations automatically. Class imbalance is handled by scale_pos_weight or by focal-style reweighting, and evaluation is precision at a fixed recall, because the review team can only handle so many alerts.

Serving latency is a hard constraint, typically under 50 milliseconds. A LightGBM model with a few hundred trees of depth eight scores in under a millisecond, which leaves the budget for feature lookups. Feature importance and SHAP values give analysts a per-transaction explanation, which is needed both for reviewer efficiency and for disputing false declines.

Neural models enter when the team wants to use raw sequences of the card’s recent transactions rather than hand-built velocity features, or to embed merchant names. Even then, the GBDT usually stays in the stack, consuming the neural embeddings as additional features, because its accuracy on the structured signals is so hard to beat.

A fintech lender wants better default prediction than its logistic scorecard but still needs to guarantee that risk never decreases as debt-to-income rises or as delinquencies increase. They have several hundred thousand historical loans with outcomes.

Modern GBDT libraries support monotonic constraints per feature. Declare debt-to-income and delinquency count as monotonically increasing in risk, and income and credit history length as monotonically decreasing. The model is then free to learn nonlinear shapes and interactions among the remaining features while honouring the constraints regulators care about. In practice this recovers most of the accuracy gain over the scorecard while keeping the explainability story intact.

Feature engineering still matters. Ratios such as payment-to-income, trend features such as change in utilisation over six months, and counts of recent inquiries are the kinds of features that boosted trees exploit well. Use early stopping on a time-based holdout rather than random cross-validation, because credit outcomes drift with the economy and a random split will make the model look better than it will perform on next year’s applicants.

For explanation, compute SHAP values per applicant and map the top negative contributors to adverse-action reason codes. Validate that the reasons are stable and sensible; a model that cites an odd feature as the main reason for a decline will not survive a compliance review even if its AUC is excellent.

A job search engine retrieves about 200 candidate postings per query using keyword matching and a two-tower model. The final ordering is what users see, and it needs to place the best matches in the top ten. Logged data includes which postings were shown, at what position, and which were clicked or applied to.

LambdaMART is built for this. Group the training rows by query, assign graded relevance (apply = 3, click = 1, skipped = 0), and train a boosted ranker that optimises NDCG directly. Features per query-posting pair include BM25 text score, two-tower similarity, title match, location distance, salary fit relative to the user’s stated range, posting age, company popularity, and the user’s historical apply rate for this company or title.

The reason to use a ranking objective rather than a pointwise classifier is that only the relative order within a query matters. A classifier wastes capacity getting absolute probabilities right across queries; the ranker spends all of it on pairwise order, which is what NDCG measures. In practice this yields a consistent gain of several NDCG points over a pointwise GBDT on the same features.

Handle position bias by either including position as a feature and zeroing it at serving time, or by estimating position propensities and using inverse-propensity weights in training. Evaluate offline on NDCG at 10 by query, and online with apply rate. The reranker runs after retrieval, so its latency budget is comfortable, but keep the feature computation cheap since it runs 200 times per query.

A retailer’s category page shows 60 products from a catalogue of a few thousand in that category. Business rules already filter out-of-stock items. The task is to order the 60 so that shoppers find what they want, measured by add-to-cart rate.

A GBDT ranker trained with a listwise or pairwise objective is the standard here. Each row is a (session, product) pair inside a group defined by the page view. Features include the product’s conversion rate over the last 30 days, price relative to the category median, rating and review count, whether the shopper has viewed this brand before, margin, and recency of listing. The label is the shopper’s action: purchase, add to cart, click, or nothing.

The ranker learns that a shopper who has previously browsed premium brands responds well to higher-priced items while first-time visitors respond to bestsellers. This kind of interaction is precisely what trees capture and what a simple sort by popularity misses.

Two practical issues arise. First, the ranking objective optimises for clicks, but the business also wants margin and diversity, so a policy layer reorders the top results to enforce constraints such as no more than three products from one brand in the first row. Second, popular items get more clicks because they are shown first, creating a feedback loop; mitigate it by injecting a small random exploration slice and by training on data from that slice with higher weight.

An ad system has a pCTR model and a bid per advertiser. Naively, expected value is bid times pCTR and you sort by it. But a pure sort ignores the fact that the auction outcome depends on the whole slate: the ads shown together compete, and user experience depends on relevance, not just revenue.

A LambdaMART reranker takes the auction’s top 50 by naive expected value and reorders them with a richer objective. Features include the pCTR score, bid, a relevance score between the ad text and the query, the advertiser’s landing page quality score, the user’s recent ad fatigue, and historical dwell time on this advertiser’s landing page. The label combines click with a downstream quality signal such as conversion or lack of a quick bounce, graded 0 to 3.

Training a ranker on this label lets the system trade a little short-term revenue for relevance in a principled way, and the model is fully explainable in feature-importance terms, which matters when advertisers ask why their ad was placed lower despite a higher bid.

This is a moderate-scale reranking problem, exactly the sweet spot for boosted rankers: dozens of candidates, dense engineered features, and a need to run in single-digit milliseconds. A neural reranker would only be justified if raw ad text and query text needed to be modelled jointly, in which case a cross-encoder score can simply be added as another feature to the LambdaMART model rather than replacing it.

A video platform needs to pick a few hundred candidate videos for each user’s home feed from a catalogue of 100 million. Scoring every video with a ranking model per user is impossible. Retrieval has to reduce the candidate set to a manageable size in a few milliseconds.

A two-tower model solves this. The user tower takes the user’s watch history (as a sequence of video IDs mapped to embeddings), demographic features, and time of day, and outputs a 128-dimensional vector. The item tower takes the video’s ID, category, creator, and title embedding and outputs a vector of the same size. Train so that the dot product of user and watched-video vectors is high relative to random videos, using in-batch negatives and a sampled softmax loss.

Because the two towers are independent, all 100 million item vectors are computed offline and loaded into an approximate nearest neighbour index. At serving time, only the user vector is computed, and the index returns the top 500 by dot product in a couple of milliseconds. That is the whole reason for the architecture: separation buys scale.

The trade-off is that the model cannot look at a user and an item together while scoring, so it cannot learn subtle interactions like a user who loves cooking videos but only from a specific creator. That is left to the reranker downstream. Common improvements include hard negative mining, training on both clicks and long watches, and using multiple user vectors to represent diverse interests.

An enterprise has two million internal documents and wants search that understands meaning, so a query for “how do I expense a client dinner” finds the policy titled “Meal reimbursement guidelines” even though no words overlap.

A two-tower text model, typically a bi-encoder fine-tuned from a pretrained transformer, is the standard approach. The document tower encodes each document (or each passage) into a vector once, offline. The query tower encodes the query at search time. Train the pair on query-document relevance data using contrastive loss: relevant pairs should be close, and random or hard negative documents should be far. If there is no click data yet, start with a public pretrained embedding model and fine-tune once clicks accumulate.

Passage vectors go into a vector index. At query time, embed the query and retrieve the top 100 passages by cosine similarity, combine with a keyword retriever such as BM25 for exact matches on product names and IDs, and pass the union to a reranker.

The bi-encoder is fast because query and document never interact during scoring. That is also its limit: it can miss fine-grained matches such as negation or specific numerical constraints. A cross-encoder reranker on the top 100 fixes that at acceptable cost. Keep the keyword retriever in the stack; semantic retrieval alone tends to fail on rare identifiers and jargon that the embedding model has never seen.

A professional network wants to suggest connections. There are hundreds of millions of members, so the system must first generate a few thousand candidates per member before a ranker decides which to show.

A two-tower model generates candidates using member profiles and graph features. The member tower encodes industry, title, company, school, location, and an aggregate of existing connections’ embeddings. Because both sides are members, the two towers can share weights, which halves the parameters and lets the model learn a single embedding space where members likely to connect are close. Train on historical connection events with in-batch negatives, weighting recent connections more heavily.

All member embeddings are refreshed nightly and indexed. At request time the member’s vector queries the index and returns the top few thousand. This runs alongside graph-based heuristics such as friends-of-friends, which remain strong for people with dense networks; the two-tower model shines for newer members whose graph is sparse but whose profile reveals who they are likely to know.

Evaluation is recall at K on held-out connections: what fraction of actual new connections appeared in the candidate set. The downstream ranker takes care of precision. Watch for popularity bias, where a handful of very well-connected members dominate every candidate list; correct with a sampling adjustment during training or a popularity penalty at retrieval time.

An ad platform has logged billions of impressions. Its GBDT model plateaued, and the team wants to use raw ID features such as user ID, ad ID, and page ID, which have millions of unique values and cannot be encoded as dense features without losing information.

A deep neural network with embedding tables is the standard solution at this scale. Each high-cardinality ID gets an embedding table, each embedding is looked up and concatenated with the dense features (CTR history, counts, time features), and a multilayer perceptron with a few layers of a few hundred units learns the interactions. Architectures such as Wide and Deep or DeepFM add explicit pairwise interaction terms that help when data is sparse.

The gain over GBDT comes from the embeddings. An ad ID embedding learns what kind of ad it is from click patterns alone, without anyone writing features for it, and the network learns which users respond to which kinds of ads. With enough data this usually adds meaningful lift over the best tree model.

The costs are real. Training needs GPUs and careful handling of embedding sizes to avoid blowing up memory; serving needs an embedding lookup service; calibration drifts and needs an explicit correction layer; and explanations are limited to attributions that are much fuzzier than a tree’s splits. A common pattern is to keep the GBDT as a shadow model for explanation and monitoring while the network serves traffic.

A marketplace ranker needs to predict three related outcomes: whether a shopper clicks a product, adds it to the cart, and purchases it. Purchases are rare, so a standalone purchase model has too few positives to learn well. Clicks are common but only loosely correlated with buying.

A multitask neural network shares a trunk across the three tasks and has three small heads. Inputs include product and shopper embeddings, price, category, and behavioural counts. Because the trunk learns representations from the plentiful click labels, the purchase head benefits from that shared structure and predicts far better than a purchase-only model. Architectures such as MMoE (Multi-gate Mixture of Experts) let each task weight the shared representations differently, which reduces the risk that the tasks interfere.

The final ranking score combines the three predicted probabilities, for example as expected revenue, and the weights can be tuned by the business without retraining. This is a real advantage over training three separate GBDTs: one model, one serving path, and a natural way to transfer signal from common to rare outcomes.

Start this only after a single-task GBDT exists and its ceiling is understood. If purchase data is truly tiny, multitask learning helps but cannot conjure signal; the click model may still dominate the combined score. Evaluate each head separately on its own held-out set, and watch for one task’s loss dominating the shared gradient.

A food delivery service wants to estimate delivery time at order placement. Tabular features such as distance, time of day, restaurant’s recent preparation times, and courier availability are strong, but the team also wants to use the restaurant ID and the dish IDs in the order, of which there are hundreds of thousands, and the free-text order notes.

A neural model handles the mix naturally. Restaurant and dish IDs become embeddings that learn, for example, that certain dishes are slow to prepare. The order note is encoded by a small pretrained text encoder into a vector. These concatenate with the dense features and feed an MLP that outputs a predicted time and, using a quantile or Gaussian output layer, an uncertainty band, which the app can display as a range.

Compared with a GBDT, the network’s advantage is entirely in the embeddings and the text. If you strip those out, the GBDT will match or beat it on the dense features alone. So the decision hinges on whether error analysis shows that a meaningful fraction of large errors come from specific restaurants or dishes that dense features cannot distinguish. If it does, the network earns its complexity.

A hybrid is common: train the neural model, extract its restaurant and dish embeddings, and feed those as features to the GBDT. This often captures most of the gain while keeping the tree model’s robustness and easier monitoring.

A search engine needs to decide whether a query is looking for a person, a company, a job, or a piece of content. Queries are short, ambiguous, and full of paraphrases: “senior pm at stripe”, “stripe product manager openings”, and “who leads product at stripe” look similar on the surface but have different intents.

A fine-tuned transformer encoder is the right tool because intent depends on the context of the whole phrase, not on individual keywords. Start from a pretrained encoder, add a classification head, and fine-tune on a few tens of thousands of labelled queries. Labels can come from a mix of human annotation and weak supervision from which vertical users ultimately clicked. The model learns that “openings” signals jobs while “who leads” signals people, even when the surrounding words are identical.

Serving is the main concern. A full-size encoder may be too slow for a query path with a tight latency budget, so distil it into a smaller model or a six-layer variant, cache results for frequent queries, and quantise. A well-distilled model runs in a few milliseconds on CPU.

Before doing any of this, check the baseline. A logistic regression on character n-grams often gets surprisingly far on intent classification. The transformer is justified when the confusions that remain are semantic, as in the paraphrase examples above, rather than lexical. The intent confidence it produces then becomes a key structured feature for the downstream panel ranker.

A support team receives thousands of tickets a day and wants to group ones describing the same problem so an agent can resolve them together and so trends surface quickly. Tickets describing the same issue use very different words: “app crashes when I upload a photo” and “sending pictures closes the application” should be grouped.

Encode each ticket with a sentence-transformer, a transformer encoder trained so that paraphrases produce nearby vectors. Off-the-shelf models work reasonably well; fine-tuning on a few thousand pairs of tickets that agents marked as duplicates improves precision substantially. Compute cosine similarity between new tickets and recent ones, and link any pair above a tuned threshold.

The encoder captures meaning that keyword matching cannot: it knows “crash” and “closes the application” are related and that “photo” and “picture” are the same thing. It is also robust to typos and to the wide range of writing styles in customer messages.

Clustering the vectors with a density-based method reveals emerging issues, which is the trend detection the team wanted. Explainability is weak, so surface the most similar existing ticket alongside each suggestion so the agent can verify quickly. Keep a simple exact-match layer on error codes and product names in front of the encoder; the embedding model can blur specifics that a support workflow needs to keep distinct.

A retail site wants to predict what a shopper will engage with next based on the sequence of the last 50 items they viewed. Order matters: viewing running shoes, then socks, then a water bottle tells a different story than the same three items in a different order, and a recent view matters more than one from a week ago.

A transformer encoder over the item sequence, in the style of SASRec or BERT4Rec, is the modern standard. Each item ID maps to an embedding, positional encodings capture order and recency, and self-attention lets the model weigh which past items are relevant to the current context. The training objective is to predict the next item, or to recover masked items in the sequence. The output vector serves as the user representation for retrieval and ranking.

The improvement over a bag-of-items approach, which just averages item embeddings, is largest for users with clear sessions of intent. The attention mechanism learns to focus on the current session while still using long-term history when the session is short.

Sequence models need substantial data, on the order of millions of sessions, to outperform simpler approaches. They are also expensive to serve if the user vector must be recomputed on every request; a common compromise is to update the user vector at the end of each session or every few events. Start with a GBDT on aggregate behavioural features and move here only when analysis shows that session order is where the missing signal lives.

A customer support assistant retrieves 50 candidate passages from a knowledge base for each user question using a bi-encoder, then sends the best few to a language model to compose an answer. If the top passages are wrong, the answer is wrong, so the quality of the final ordering matters far more than retrieval speed.

A cross-encoder is the right tool for the final ordering. It concatenates the question and each candidate passage into a single input, runs them through a transformer, and outputs a relevance score. Because the model attends across both texts jointly, it can tell that a passage about “refund processing time” answers “how long until I get my money back” and that a passage mentioning refunds in passing does not. A bi-encoder, which embeds question and passage separately, is far weaker at these distinctions.

Fine-tune on question-passage pairs with relevance labels, using hard negatives from the bi-encoder’s own top results so the reranker learns to correct precisely the mistakes the retriever makes. Public pretrained rerankers are a strong starting point.

Cost is 50 forward passes per query, which is acceptable for a support assistant with a latency budget of a few hundred milliseconds but would not work for scoring a million candidates. The pattern is always retrieve broadly and cheaply, then rerank narrowly and expensively. Measure the improvement by whether the correct passage lands in the top three, since that is what the answer generator actually consumes.

A search engine has a strong LambdaMART ranker over engineered features, but error analysis shows that its worst failures are semantic: results that match many keywords but do not answer the query. The team wants to fix the top of the results page without rebuilding the pipeline.

Add a cross-encoder stage over the top 20 to 30 results from LambdaMART. The cross-encoder reads the query and each result’s title and snippet together and scores relevance. Its score can be used in two ways: as a new feature fed back into LambdaMART, which is the cheaper option and the usual first step, or as the final ranking signal for the top slots, blended with the tree model’s score.

Train on human relevance judgements if they exist, since click data alone is noisy for fine-grained relevance. Judgement sets of a few tens of thousands of query-result pairs are typical. Distil the model to something that runs in a few milliseconds per pair, and cache scores for popular queries.

Evaluate on NDCG at 3 and at 5, because the cross-encoder’s job is the very top of the page. Expect a measurable gain on long, natural-language queries and little change on navigational queries where the tree model was already right. Keep the cross-encoder strictly downstream: it should never be asked to score more than a few dozen candidates per query, and the retrieval and structured ranking layers remain responsible for getting the right candidates into that set.

A recruiting product shows a recruiter the top candidates for an open role. Candidates are retrieved by skills and location, giving a few hundred, but the recruiter wants the top ten ordered by genuine fit, which depends on reading the resume against the job description: does this person’s experience actually match what the role asks for?

A cross-encoder over the (job description, resume summary) pair is the highest-quality way to judge that fit. Fed both texts jointly, the model learns that “led migration of monolith to microservices” is strong evidence for a role asking for “experience decomposing legacy systems”, even though the words differ. It can also learn negative signals, such as a candidate whose experience is in a different domain despite matching keywords.

Labels come from recruiter actions: candidates the recruiter contacted or advanced count as positive, candidates skipped after viewing count as negative. Thousands of labelled pairs suffice for fine-tuning from a pretrained reranker. Truncate resumes to the most recent few roles to fit the model’s input length.

Because fairness matters in hiring tools, audit the model for disparate outcomes by group and strip protected attributes and their proxies from the text before scoring. Explanations are limited, so pair the score with a highlighted list of matched skills from a simpler extraction step so recruiters can see why a candidate ranked well. Scoring a few hundred candidates per role at a few milliseconds each is well within budget for a tool used interactively.

A streaming service has millions of subscribers and tens of thousands of titles, with a dense history of who watched what and for how long. It wants a “recommended for you” row on the home screen.

Matrix factorisation, the classic collaborative filtering method, is a natural fit. Represent each user and each title as a low-dimensional vector, and train so that the dot product predicts whether the user watched the title, with implicit feedback weighting (watched to completion counts more than abandoned after five minutes). Alternating least squares or stochastic gradient descent trains on hundreds of millions of interactions in minutes on a single machine.

The model discovers taste dimensions from behaviour alone: nobody labels films as “slow-burn European drama”, but the factor model finds that the users who watch one tend to watch others and places them together. That is why collaborative filtering routinely beats metadata-based recommendations when interaction data is rich. The learned title vectors also produce good “because you watched” rows by nearest neighbour lookup.

The limits are cold start and popularity bias. A newly added title has no vector until people watch it, so new releases need a content-based fallback using genre, cast, and description embeddings. Very popular titles dominate unless the model is regularised or scores are debiased. In mature systems, matrix factorisation is the starting point that later grows into a two-tower model with side features, but the core idea, users and items in a shared space, carries through.

A music app wants to suggest the next tracks for a playlist and to build a weekly discovery mix. There are billions of plays across tens of millions of tracks, and listening behaviour is far more informative than genre tags, which are coarse and inconsistent.

Item-to-item collaborative filtering works well for playlist continuation. Compute, for each track, the tracks that most often appear in the same playlists or listening sessions, normalised so that ubiquitous hits do not dominate. Storing the top 50 neighbours per track makes serving a trivial lookup. For the discovery mix, factorise the user-track play matrix to get user taste vectors and score unheard tracks by similarity, then filter out anything too popular or too similar to what the user already knows, since discovery is the goal.

Implicit feedback needs care. A skip after ten seconds is a negative signal; a full play is positive; a play while the phone was in the pocket is noise. Weight interactions accordingly rather than treating every play as equal.

Cold start applies to new tracks, which get a content-based vector from audio features until plays accumulate, and to new users, who get onboarding prompts or a popularity-based mix. The system is explainable at the level of “because you listened to X”, which users find satisfying, even though the factor dimensions themselves have no names.

A marketplace sells hundreds of thousands of products, most of which sell a handful of units. Most shoppers make a purchase or two a year. The team wants product recommendations but the interaction matrix is extremely sparse.

This is the case where pure collaborative filtering struggles, and knowing that is the point of the example. With most products having fewer than ten buyers, the factor model has little to learn from, and recommendations will collapse to the few popular items. Before abandoning collaborative filtering entirely, three adjustments help: use richer implicit signals such as views and cart adds rather than purchases alone, which increases density tenfold; aggregate products into categories or brands and factorise at that level; and add side information such as category and price band into the model, turning it into a hybrid.

If even that is too sparse, content-based methods win. Embed product titles and images, and recommend by similarity to what the shopper viewed. That needs no interaction data at all and handles new products immediately.

The practical answer is usually a hybrid ranker: a GBDT or neural model that takes both the collaborative filtering score (where it exists) and content similarity as features and learns when to trust which. Collaborative filtering is a component that earns its place in proportion to how dense the interaction data is, and a sparse marketplace should not expect it to carry the system alone.

A retailer’s marketing team wants a handful of customer segments they can name and target differently. Each customer has recency of last purchase, purchase frequency, average order value, discount usage rate, and share of purchases in each of five categories.

K-means on these features, after scaling each to unit variance, is the standard first pass. Standardisation is not optional: without it, average order value in dollars would dominate the distance calculation and every other feature would be ignored. Try k from 3 to 8, look at the elbow in within-cluster variance and at silhouette scores, but ultimately choose the k whose clusters the marketing team can interpret and act on.

The output might be five groups: frequent high-value shoppers, discount-driven occasional buyers, lapsed customers who were once frequent, new customers with one order, and category specialists who only buy one thing. Each cluster centre is a profile the team can name, and assigning a new customer to a segment is a single nearest-centre lookup.

The clusters are not ground truth; they are a convenient partition. Rerunning with a different seed can shift boundaries, so fix the seed and version the model. If the marketing team later has an outcome to predict, such as response to a campaign, a supervised model on the same features will target better than segment membership. K-means is for understanding and communication, and it is excellent at that job.

A content team wants to know what topics people search for on their site so they can plan articles. They have a few million distinct queries with frequency counts but no categories.

Embed each query with a sentence encoder, then run k-means on the embeddings, weighted by query frequency so that common queries shape the centres. With k around 50 to 200, each cluster becomes a theme. Label each cluster by its most frequent queries and by the terms closest to its centre. The team ends up with a ranked list of themes with search volume, which is exactly the planning input they need.

K-means is chosen over more sophisticated clustering because it is fast on millions of points, produces a fixed number of groups that fit in a spreadsheet, and assigns every query to something. Density-based methods would leave many queries unassigned and produce an unpredictable number of clusters, which is worse for a planning exercise.

Two caveats matter. Embedding spaces are high dimensional, so cluster boundaries are fuzzy and some queries will land in surprising themes; inspect the largest clusters manually. And k-means assumes roughly equal-sized spherical clusters, so a giant “generic” cluster will form around vague queries; either remove very short queries first or run a second pass of k-means inside the giant cluster. Use the result as a map, not as a classifier.

An engineering team stores billions of 256-dimensional item embeddings and wants to cut memory and speed up similarity search. This is a case where k-means is used as an engineering primitive rather than an analysis tool.

Product quantisation splits each vector into subvectors, say eight subvectors of 32 dimensions, and runs k-means with 256 centres on each subvector space. Each subvector is then replaced by the index of its nearest centre, a single byte, so a 1,024-byte float vector becomes 8 bytes. Distances between a query and stored vectors are computed from precomputed distance tables between the query’s subvectors and the centres, which is fast and accurate enough for approximate nearest neighbour search.

K-means is ideal here because the goal is exactly what its objective minimises: the squared error between vectors and their assigned centres. Nothing needs to be interpretable and the clusters need not be meaningful, only compact. The same idea, with k=16 or 256 in RGB space, compresses images to indexed colour palettes.

The practical detail that matters is training the centres on a representative sample of the data, a few hundred thousand vectors, and retraining when the embedding model changes, since the centres are tied to the distribution. This use of k-means sits inside most large-scale vector databases and is a reminder that “unsupervised clustering” covers plumbing as well as insight.

A product research team ran a 120-question survey about customer attitudes and wants to summarise responses for a dashboard. Many questions are near-duplicates: “the app is easy to use” and “I can find what I need quickly” are answered almost identically by most people.

PCA finds the directions of greatest shared variation. Standardise the responses, compute the principal components, and inspect the loadings. Typically the first component is overall satisfaction, the second separates price sensitivity from feature demand, the third captures trust or reliability concerns. Three to five components often explain 60 to 80 percent of the variance in survey data of this kind, and each respondent’s scores on those components summarise 120 answers in a handful of numbers.

Those scores feed downstream analyses cleanly. Regressing retention on five component scores is far more stable than regressing it on 120 collinear questions, which would produce unstable, uninterpretable coefficients.

The classic caution is that components are mathematical, not conceptual. The second component might mix two ideas that the team would prefer to keep separate. Varimax rotation or a factor analysis model often yields more interpretable axes. And if the dashboard consumer needs to know what a score means, present the top-loading questions alongside it. PCA is a compression tool that happens to be interpretable sometimes, not an interpretability tool.

A wind farm streams 40 sensor channels per turbine: vibration at multiple points, temperatures, rotor speed, power output, wind speed. Many channels are highly correlated because they all respond to the same underlying conditions. The maintenance team wants to detect abnormal behaviour but raw thresholds on 40 channels fire constantly.

Fit PCA on data from healthy operation. The first few components capture the normal ways the sensors move together as wind changes. Project incoming data onto those components and reconstruct; the reconstruction error, the part of the signal that does not fit the normal correlation structure, is the anomaly score. A bearing that starts to fail causes vibration to rise while everything else stays normal, which breaks the learned correlation and produces a large residual, even though the raw vibration may still be inside its individual threshold.

This is a well-established industrial technique because it is linear, fast, and needs only healthy data to train. It catches a whole class of problems that univariate thresholds miss, and the residual per channel points to which sensor is misbehaving.

PCA assumes the normal relationships are linear. Turbines under very different regimes, such as low wind versus high wind, may need separate PCA models. When the relationships are strongly nonlinear, an autoencoder plays the same role with more flexibility, but it is harder to tune and to trust; start with PCA and move on only when residual analysis shows structured errors the linear model cannot capture.

A data scientist has trained a 64-dimensional user embedding for a recommender and wants to show stakeholders that the embedding captures real structure, for instance that users cluster by interest.

PCA to two dimensions is the fastest honest way to get a picture. Project a sample of a few thousand users onto the top two components, colour points by a known attribute such as most-purchased category, and plot. If the embedding is good, the colours will form visible regions. The plot takes seconds to produce and is deterministic, which matters when the same picture needs to appear in several decks.

Nonlinear methods such as t-SNE or UMAP produce prettier, more separated clusters and are often better for exploration. But they distort distances, are sensitive to parameters, and can manufacture clusters that are not in the data, so a PCA plot is the more trustworthy first look and a good sanity check for a nonlinear plot.

Two components of a 64-dimensional space usually explain only a modest share of the variance, so read the plot as a projection rather than a faithful map. If the two components explain 10 percent of the variance and the picture still shows structure, that is evidence of a strong embedding; if they explain 60 percent, the embedding may be wasting most of its dimensions. Report the explained variance next to the plot so the audience knows what they are looking at.

A new platform has account activity data (logins per day, countries seen, devices used, messages sent, failed password attempts, account age) but almost no confirmed abuse cases. The trust team wants a queue of unusual accounts to investigate.

Isolation forest fits this situation exactly. It builds many random trees that split on random features at random thresholds, and measures how few splits it takes to isolate each account. Normal accounts sit in dense regions and need many splits; an account that logged in from 14 countries in a day sits alone and is isolated in one or two splits. The average path length across trees becomes the anomaly score, with no labels required.

It trains in seconds on millions of rows, has essentially one parameter (the expected contamination rate, which just sets the threshold), and is robust to irrelevant features because random splits on them do not help isolate anything. That makes it a better default than distance-based methods, which fail when features have different scales or when there are many features.

Investigators need to know why an account was flagged. Compute, for each flagged account, which features contributed most to the short path length, or simply show the features that are furthest from their typical range. Every investigated case then becomes a label, and after a few thousand of them a supervised GBDT will outperform the isolation forest on the known abuse types. Keep the isolation forest running alongside to catch new patterns the supervised model has never seen.

A data platform ingests hundreds of daily batches from upstream systems. Occasionally a batch is corrupted: a column is all nulls, a currency conversion was skipped so amounts are 100 times too large, or a partial load produced half the usual row count. These slip through schema checks because the schema is technically valid.

Compute a profile vector per batch: row count, null rate per column, mean and standard deviation per numeric column, number of distinct values per categorical column, all relative to the trailing 30-day average. Train an isolation forest on the profiles of past batches that were later confirmed good. Score each new batch; if it lands in the top 1 percent of anomaly scores, hold it for review before it reaches downstream tables.

The isolation forest is a good fit because the profile has dozens of features and a corrupt batch is unusual in some unpredictable combination of them. Writing a rule per failure mode would never keep up. The forest catches the failure modes nobody anticipated, which are precisely the ones that cause outages.

False positives are cheap here, since holding a batch for an hour costs little, so tune the threshold toward recall. When a held batch is reviewed, log whether it was actually bad; over time that log tells you which profile features matter and whether a simpler rule would suffice for the common cases. Sequence-aware failures, such as a batch that is individually normal but arrives out of order, need a different tool.

An operations team monitors thousands of servers, each reporting CPU, memory, disk I/O, network throughput, request rate, and error rate every minute. Static thresholds generate noise because normal ranges differ by server role and time of day.

Train one isolation forest per server role on a rolling window of recent healthy minutes, using the six current metrics plus their change over the last five minutes. Score every new minute. A server whose CPU is high but whose request rate is also high looks normal, since that combination is common; a server whose CPU is high while request rate is near zero is isolated quickly and flagged. This multivariate view is what separates the isolation forest from per-metric alerts.

Retrain nightly so the model tracks gradual drift, and keep the contamination rate low so that the on-call engineer gets a handful of alerts rather than hundreds. Surface the two or three metrics that most contributed to the score with each alert, so the engineer knows where to look.

The limitation is that the isolation forest treats each minute independently. It will miss a slow memory leak that rises a little every hour and stays within the normal band each minute, and it will not understand periodic patterns unless you add time-of-day features. For those cases a time-series model or a sequence model is the complement. Isolation forest is the cheap, broad net; the sequence model is the targeted one.

An editorial team writes three to five headline variants for each story. The homepage can only show one, and the goal is clicks. A classic A/B test would split traffic evenly for a day, but by then the story is old. The team wants to learn the best headline within the first hour and keep learning as the audience changes across the day.

A contextual bandit is designed for this. The actions are the headline variants, the context is what is known about the visitor (device, referrer, time of day, whether they are a subscriber), and the reward is a click within the session. Thompson sampling maintains a posterior over each variant’s click rate per context and samples from it to choose which to show, so better variants get more traffic quickly while weaker ones still get occasional exposure to confirm they are worse.

The key property is that the bandit learns from its own decisions. A supervised model trained on logged data would only ever see clicks on the headline the old policy chose, so it could never discover that a different headline works better for mobile readers. The bandit’s exploration produces the counterfactual data that makes learning possible.

Keep the context simple at first; a linear model over a handful of features per action is enough and easy to debug. Log the propensity, the probability with which each action was chosen, alongside every decision, because that is what makes offline evaluation of future policies possible. Rewards arrive within minutes, and headlines do not affect tomorrow’s behaviour, so the bandit’s single-step assumption holds.

A subscription service can offer at-risk customers one of four retention incentives: a free month, a 20 percent discount for three months, an upgrade to a premium tier, or no offer. Each costs a different amount and works for different people. A churn model says who is at risk; the question is what to do about it.

Frame it as a contextual bandit where the context is the customer’s features (tenure, usage, plan, churn score), the actions are the four offers, and the reward is retained revenue over the next 60 days minus the offer’s cost. This directly optimises the business objective rather than a proxy like acceptance rate, which would favour the most generous offer for everyone.

Because rewards take 60 days to observe, the bandit updates in delayed batches rather than in real time, which is fine as long as the customer population and the offer effects are stable over that horizon. Use an algorithm that handles delayed feedback, and start with a substantial exploration rate since the initial policy knows nothing.

The no-offer action is important. Many at-risk customers would have stayed anyway, and offering them a discount is pure cost. The bandit learns to reserve incentives for customers whose behaviour actually changes, which is the uplift a supervised model cannot estimate without an experiment. If the finance team imposes a monthly budget, add a constraint layer that scales down the probability of costly actions as spending approaches the cap.

A product team has five page layouts for its checkout flow and wants to serve the best one to each visitor. Layouts differ in where the buy button sits, whether reviews appear above the fold, and how many images show. Conversion depends on the visitor’s device, the product category, and whether they arrived from a search ad.

A contextual bandit with a small linear model per layout learns which layout converts for which context. Each visit, the model computes an expected conversion per layout, adds an exploration bonus based on how uncertain it is about that context, and chooses the highest. Conversion or abandonment arrives within minutes, so the model updates quickly.

Compared with running ten separate A/B tests for each device-category combination, the bandit pools information across contexts and shifts traffic toward winners automatically, reaching a good policy with a fraction of the sample size. Compared with a static personalisation model, it keeps adapting as seasonal traffic changes what works.

Two safety rails are essential. Cap how far the policy can move in a day so a bug in the reward logging cannot swing all traffic to a broken layout. And run a small holdout that always sees the original layout, so the team can measure the bandit’s total lift against a fixed baseline, which the bandit’s own metrics cannot provide. Layout choice does not affect the next visit, so a full reinforcement learning treatment is unnecessary.

A data centre operator wants to minimise energy used for cooling while keeping every rack within temperature limits. Actions are setpoints for chillers, pumps, and fans. The catch is that each action’s effect unfolds over an hour or more, and a cheap decision now, such as turning down cooling, can create an expensive emergency later.

This is a genuine reinforcement learning problem: sequential decisions, a state that evolves in response to actions, and a reward (energy saved) that must be traded against a delayed penalty (temperature violations). The standard path is to build a simulator from historical sensor data, train a policy in simulation using an algorithm that handles continuous actions, and deploy it with strict guardrails that override the policy whenever a temperature nears its limit.

A bandit would fail here because it treats each decision as independent and cannot represent that the current temperature is a consequence of the previous ten actions. A supervised model could predict temperature but not decide what to do about it across a horizon.

The reasons this succeeds are worth naming: an accurate simulator exists, the reward is well-defined and measured continuously, and a safety layer makes exploration survivable. Without those three, RL for control is usually not worth attempting. Even with them, the practical deployment is often the RL policy as an advisor with human sign-off, and full autonomy only after months of shadow operation. Well-executed projects report double-digit percentage energy reductions; poorly scoped ones burn months on simulator fidelity.

A content feed optimised by a click model has a problem: it learned to show sensational items that get clicks but leave users feeling worse, and they gradually visit less. Each recommendation affects not only the immediate click but the user’s future engagement. The team wants a policy that maximises engagement over weeks, not seconds.

Reinforcement learning is the right framing because the reward is cumulative and the action changes the future state (the user’s satisfaction and habits). In practice this is done with offline RL from logged data, since exploring freely on live users is unacceptable. The state is the user’s recent history, the action is the item shown, and the reward is a long-term signal such as return visits over the next week, discounted appropriately. Off-policy correction is needed because the logs were generated by the old click-maximising policy.

The gap between this and a bandit is the horizon. A bandit with a one-week reward would need to wait a week per decision to learn; RL propagates long-term value back through the sequence so that each step can be credited.

This is expensive and fragile. Off-policy estimates have high variance, small errors in the reward definition produce policies that game the metric, and evaluation requires long, careful A/B tests. Most teams get 80 percent of the benefit with a much simpler fix: add a predicted long-term satisfaction score, from a supervised model, as a term in the ranking objective. Attempt full RL only after that fails to close the gap.

A logistics company wants a robot arm to pick items of many shapes from bins. Each grasp is a sequence of motions, success is only known at the end when the item is or is not lifted, and a poor early motion (approaching from the wrong angle) dooms the attempt even if later motions are fine.

Reinforcement learning, specifically policies trained with a mix of simulation and real robot trials, is the established approach. The state is the camera image and joint positions, the action is the next motion, and the reward is a successful pick. Training in simulation with randomised object shapes and lighting produces a policy that transfers to the real robot, and a few thousand real attempts fine-tune it.

RL fits because the problem is inherently sequential and the credit assignment problem is real: the model has to learn that the approach angle chosen ten steps ago caused the failure. Supervised learning from human demonstrations (imitation learning) is a common and much cheaper starting point and is often used to initialise the RL policy, but it caps performance at the demonstrator’s skill and cannot recover from states the demonstrator never visited.

The practical requirements are the usual ones for RL: a simulator good enough that policies transfer, a reward that is measured automatically, and a physical safety layer so exploration cannot damage equipment. Teams that skip the simulator and try to learn on the real robot alone typically need hundreds of thousands of attempts, which is why simulation-first is the norm.