Differentiable Optimisation Layers

Ordinarily, a neural network and an optimiser are two separate stages bolted together: the network predicts expected returns, then a portfolio optimiser takes those predictions and solves for weights — completely blind to how its predictions actually get used downstream. A differentiable optimisation layer removes that separation. It makes the optimisation solver itself a layer inside the network, one whose output can be backpropagated through, so the network's predictions can be trained specifically to produce good portfolios, not just accurate-looking numbers that happen to feed a portfolio solver.

An analogy: training an archer versus training a wind-gauge reader

Imagine training someone to read a wind gauge accurately, then handing that reading to a separate person who aims the bow — versus training the archer directly on where the arrow actually lands, letting them absorb wind-reading and aiming into one skill honed against the only thing that matters, hitting the target. A standard "predict, then optimise" pipeline is like the first setup: the prediction step is graded on its own accuracy, disconnected from the final outcome. A differentiable optimisation layer lets the whole pipeline be graded on the final outcome directly, the way the archer is.

Making a solver differentiable

The technical challenge is that a typical optimisation solver — feed it a problem, get back a solution — is not, by default, a function you can take a gradient through; it involves loops, conditionals, and iterative search that ordinary backpropagation can't see through cleanly. Differentiable optimisation layers solve this using the implicit function theorem: at the optimal solution, the problem's optimality conditions (the KKT conditions) hold as an equation relating inputs to the solution, and differentiating that equation implicitly gives you the gradient of the solution with respect to the inputs — without needing to unroll the solver's internal iterations step by step. In plain English: instead of tracking every step the solver took to get to its answer, you use the fact that "this is the point where the optimality conditions are satisfied" to work out directly how the answer would shift if the inputs shifted slightly.

Worked example: a toy mean-variance layer

Consider a simplified portfolio layer that solves $\min_w \, w^\top \Sigma w - w^\top \hat\mu$ subject to weights summing to 1, where $\hat\mu$ is the network's predicted expected returns and $\Sigma$ is a fixed covariance matrix. In a standard pipeline, the network predicting $\hat\mu$ is trained only to minimize prediction error against realized returns (say, mean squared error), with no idea that its predictions will later be squeezed through a mean-variance solver. With a differentiable layer, the same network is instead trained to minimize the realized portfolio's actual variance-adjusted loss after the optimiser has converted $\hat\mu$ into weights $w^*$ — so if two assets have prediction errors of similar size but one asset's error would move the resulting portfolio weights far more (say, because it's a low-covariance asset the optimiser wants to lever up), the network learns to be more careful about exactly that asset's prediction, because the training signal now reflects the downstream consequence, not just the raw prediction error.

What this means in practice

Differentiable optimisation layers matter wherever the final quality metric is downstream of a solver — portfolio weights, hedge ratios, resource allocations — and where you'd rather train the whole pipeline against that final metric than against an intermediate proxy like prediction accuracy. They come at a real engineering cost: implementing and differentiating through a solver is substantially harder than calling an off-the-shelf optimiser after training, and the technique is really only worth adopting when the gap between "accurate predictions" and "good downstream decisions" is large enough to matter.