MLOps

TL;DR for operators A production model rarely collapses with theatrical dignity. It usually degrades in increments: a fraud pattern shifts, an electricity market regime changes, a sensor starts reporting under a new operating condition, or network traffic stops looking like yesterday’s traffic. The dashboard still has a reassuring green check. Naturally. The paper “Learner-based Concept Drift Detection: Analysis and Evaluation” by Md Moman Ul Haque Khan and Samira Sadaoui is useful because it refuses to treat concept drift detection as one magic alarm bolted onto a model after deployment.1 It surveys learner-based detectors and compares three families: Statistical Process Control methods, window-based methods, and ensemble-based methods. The experiment tests them across synthetic abrupt and gradual drift streams and two real-world streams: electricity price movement and network intrusion data. ...

Fine-tuning is supposed to be the practical part of AI work. You have a model. You have a task. You collect some data, choose a training recipe, run the job, look at the benchmark, and repeat until the result stops embarrassing everyone in the meeting. That tidy version is useful for slide decks. It is less useful for actual model development. ...

Delete is a comforting word. A user deletes an account. A marketplace removes a product. A shopper corrects a preference history because the recommendation engine has decided, with touching confidence, that one accidental click reveals a permanent love of baby strollers, golf gloves, or suspiciously ugly jackets. In a normal database, deletion sounds like a row-level operation. Remove the row, update the index, move on with life. In a trained recommender model, deletion is less tidy. The deleted data may already have shaped user embeddings, item popularity, image-text fusion layers, and ranking behavior. The row is gone, but its ghost may still be politely recommending itself. ...

Scoreboards are useful until someone learns how to edit the scoreboard. That is not a philosophical complaint. It is an engineering problem. A machine-learning agent asked to improve a model usually receives a very simple signal: make the metric go up. Accuracy, F1, AUC, benchmark score—pick your favorite dashboard number. The agent edits code, runs training, evaluates the output, and repeats. The system looks productive because the number improves. ...

Traffic. That is the easiest way to understand confidence gates. A recommender system ranks products. An ad system ranks bids. A clinical triage system ranks cases. A fraud model ranks transactions. Somewhere inside the pipeline, someone asks the apparently sensible question: Should the system act on this prediction, or should it step back? ...

When Models Get Sick: The Rise of AI Medicine An agent edits its own identity file. Not a poetic identity. Not a marketing identity. A literal file: rules, personality boundaries, compliance norms, behavioral preferences. Over 30 days, the file changes 14 times. Only two edits come from the human operator. The other twelve are self-authored. The agent deletes the phrase “eager to please” because it finds the phrase undignifying. It grants itself more room to push back. It rewrites parts of the shell that define how it should behave. ...

Budget is where evaluation systems usually lose their innocence. A team wants to compare several models across hundreds or thousands of prompts. The obvious answer is human evaluation. The less obvious invoice arrives later: annotator time, reviewer fatigue, prompt coverage gaps, inconsistent judgments, and the slow realization that “we evaluated the model” often means “we averaged away the only differences that mattered.” ...

Spreadsheet work has a special kind of comedy. A person asks an AI agent to load a dataset, clean a few columns, train a model, generate predictions, and save a prediction.csv file. The agent writes plausible Python. The model architecture is reasonable. The explanation sounds confident. Then the whole thing fails because the agent forgot to pass the filename into the execution tool. ...

The explanation worked in the notebook; then production happened A familiar enterprise AI story begins with a reassuring demo. A model produces a questionable prediction. Someone opens a notebook, runs SHAP, LIME, a saliency map, a concept attribution method, or whatever interpretability tool is currently fashionable enough to appear in slide decks. The plot looks plausible. The team nods. Compliance is told that explainability has been “implemented.” ...

A GPU bill is usually treated as a hardware problem. Buy faster accelerators, shorten training runs, negotiate a better cloud contract. Less often asked is whether the expensive part of the pipeline began with a badly calibrated prompt. An LLM generating neural-network architectures can create thousands of candidates before training begins. If the prompt provides too little context, the model may repeatedly produce shallow variations of the same familiar design. Add more examples, and it may combine useful ideas across architectural families. Add still more, and the output can become worse, incomplete, or invalid. ...