La frontiera di Pareto spiegata a chi programma: scegliere tra due obiettivi in conflitto

Capita spesso, programmando, di dover scegliere tra opzioni che sono migliori l'una dell'altra su una metrica e peggiori su un'altra: una libreria più veloce ma con un bundle più pesante, un database più scalabile ma più complesso da gestire, un modello AI più economico ma meno preciso. Quando le metriche vanno in direzioni opposte, non esiste un "il migliore" in assoluto: dipende da quanto pesi l'una rispetto all'altra, e quel peso spesso non lo conosci con certezza finché non hai già scelto.

L'economista Vilfredo Pareto, più di un secolo fa, propose un modo per affrontare esattamente questo tipo di scelta senza dover decidere in anticipo quanto vale ogni metrica. L'idea è semplice: invece di cercare "la" scelta migliore, elimina prima tutte le scelte che sono oggettivamente peggiori di un'altra su ogni dimensione — quelle che in gergo si dicono "dominate" — e lavora solo su ciò che resta.

Un'opzione A domina un'opzione B se A è uguale o migliore di B su ogni metrica, e strettamente migliore su almeno una. Se hai due librerie con le stesse dimensioni del bundle ma una è più veloce, la più lenta è dominata: non c'è alcun motivo, in nessuno scenario, per preferirla. Le opzioni che nessuna riesce a dominare formano la cosiddetta frontiera di Pareto: sono le uniche che meritano di entrare nella tua valutazione finale, perché ciascuna vince su qualcosa rispetto a tutte le altre.

Il punto centrale è che la frontiera non ti dice quale scegliere — quello dipende dalle tue priorità, dal contesto del progetto, da vincoli che magari non sono nemmeno rappresentati nei numeri — ma ti garantisce di scartare solo le opzioni che nessuno sceglierebbe mai in nessuna circostanza, e di concentrare la discussione (con te stesso o col team) solo su un sottoinsieme piccolo e già filtrato. Su una lista di trenta opzioni, spesso la frontiera ne contiene cinque o sei: un risparmio enorme di tempo decisionale.

Calcolare la frontiera di Pareto è un esercizio di programmazione utile di per sé, oltre che uno strumento pratico. Ecco una funzione che, data una lista di opzioni con due metriche dove valori più bassi sono migliori (ad esempio costo e latenza), restituisce solo quelle non dominate:

function paretoFront(options) {
  // Each option: { name, cost, latency } — lower is better for both.
  return options.filter((candidate) => {
    return !options.some((other) => {
      if (other === candidate) return false;
      const notWorse =
        other.cost <= candidate.cost && other.latency <= candidate.latency;
      const strictlyBetter =
        other.cost < candidate.cost || other.latency < candidate.latency;
      return notWorse && strictlyBetter; // "other" dominates "candidate"
    });
  });
}

const llmOptions = [
  { name: "model-a-mini", cost: 0.1, latency: 200 },
  { name: "model-b-fast", cost: 0.3, latency: 90 },
  { name: "model-c-pro", cost: 0.8, latency: 250 }, // dominated by model-b-fast
  { name: "model-d-balanced", cost: 0.4, latency: 150 },
];

console.log(paretoFront(llmOptions).map((o) => o.name));
// -> ["model-a-mini", "model-b-fast", "model-d-balanced"]

model-c-pro sparisce dalla lista perché model-b-fast costa meno ed è anche più veloce: nessuno sceglierebbe mai model-c-pro avendo a disposizione l'altro. Le tre opzioni rimaste, invece, richiedono davvero una decisione: dipende se per il tuo caso d'uso conta di più risparmiare o rispondere in fretta. La stessa funzione si applica a qualunque confronto a due metriche: piani di hosting per prezzo e uptime, dipendenze npm per dimensione e velocità, algoritmi di sort per tempo e memoria.