Optimization

Budget meetings have a familiar rhythm. Someone brings the spreadsheet. Someone brings the map. Someone else brings the sentence that ruins the spreadsheet: “This district looks inefficient on paper, but the roads are worse than the data says.” Classical optimization knows what to do with numbers. It does not naturally know what to do with that sentence. In public health planning, infrastructure rollout, retail site selection, and ESG investment, those sentences are often where the real institutional knowledge lives. Unfortunately, once the sentence enters the room, the algorithm usually leaves through the back door. Or worse, the organization pretends the sentence has been “encoded” into a weight, because apparently all human judgment becomes rigorous once it is multiplied by 0.37. ...

Probe, Then Commit: Why Solver Tuning Finally Grew Up Planning is where business software goes to meet reality. A factory needs a schedule. A logistics team needs routes. A utility company needs network decisions. A hospital needs staff allocation. The model is elegant, the constraints are clear, and then the solver quietly asks the question nobody put in the PowerPoint: ...

Tables have a talent for pretending to be tidy. A customer table may have fifty columns. A transaction table may have a hundred. A log table may contain derived fields, timestamps, status codes, copied identifiers, normalized labels, and a few columns that nobody remembers creating but everybody is afraid to delete. Then a data profiling tool arrives, dutifully discovers functional dependencies, and returns several hundred thousand “valid” relationships. ...

Seats are not just seats. For an airline, a seat can be sold as a cheap restricted fare, a flexible economy fare, or not sold at all. A passenger who cannot buy one fare may upgrade, switch flights, or disappear into a competitor’s booking funnel. Multiply that across routes, departure times, fare classes, demand segments, aircraft capacity, and network balance rules, and the innocent phrase “optimize ticket sales” becomes a fairly effective trap for language models. ...

Speed is the polite word. Cost is the less polite one. Every production LLM system eventually meets the same boring villain: the target model must generate tokens one after another, and each forward pass is expensive. Speculative decoding was supposed to soften that problem. Let a cheaper draft model run ahead, ask the expensive model to verify the draft, and accept several tokens per target-model call when the draft is good enough. Simple. Elegant. Almost suspiciously useful. ...

Science usually fails in a boring way. Not with explosions. Not with a robot dramatically discovering penicillin 2.0 while violins swell in the background. More often, a research workflow fails because somebody optimized the wrong thing a little too efficiently. A molecule scores well but is chemically ugly. A nanobody looks good under one predictor but fails to bind. A DNA enhancer activates the target cell line but also lights up the wrong tissue. A separation process reaches high purity by adding pointless unit operations, because the reward function forgot to punish industrial nonsense. The optimizer did its job. Unfortunately, the job description was incomplete. ...

Traffic. A planner wants to test whether a new signal policy will reduce congestion near a hospital. A logistics operator wants to know whether a revised delivery schedule will overload a district during the evening peak. A city team wants to compare two neighborhoods, two time windows, and two control strategies before anyone touches asphalt, paint, or public patience. ...

Training runs rarely fail with cinematic drama. They do not burst into flames. They simply become expensive, slow, and faintly embarrassing. A fine-tuning job starts with promise, the loss descends, then progress flattens. Another run behaves well for 200 steps, then becomes jumpy after a data shard changes. A third run is rescued by lowering the learning rate, except nobody knows whether the rescue came too early, too late, or by accident. Eventually, the team does what teams do: try cosine decay again, because at least cosine looks mathematically respectable while doing whatever it was going to do anyway. ...

Robots do not move through warehouses as clean little dots on a grid. They rotate. They accelerate. They wait behind other robots. They lose time in corners. They obey controllers, not PowerPoint arrows. This is the small operational fact that makes a large amount of path-planning optimism look slightly overdressed. Multi-Agent Path Finding, or MAPF, usually asks a neat question: given many agents, each with a start and goal location, can we find collision-free paths for all of them? In the standard version, the world is a graph, time advances in discrete steps, and each robot either moves to a neighboring vertex or waits. It is elegant, measurable, and algorithmically productive. It is also not how a differential-drive robot actually behaves when squeezed through a congested warehouse aisle. ...

A solver can lose time in a very boring place: deciding which internal bookkeeping trick to use. That sounds too small to matter. Business people usually expect optimization performance to come from grand architecture, better mathematical modeling, expensive hardware, or some heroic AI layer sprinkled on top. Researchers know better, though not always loudly enough. Sometimes the expensive part is not the model. It is the tiny repeated decision made millions of times while the solver tries to keep the model logically alive. ...