Search Algorithm Portfolio¶
Workflow — instantiates Landscape-Aware Search Strategy Design
Runs or stages multiple search tactics, each matched to a different landscape hypothesis, then reallocates effort based on observed performance.
When you genuinely don't know what terrain you are searching, betting everything on one tactic is a gamble on a hypothesis you can't yet confirm. The Search Algorithm Portfolio hedges instead: it runs or stages several distinct search tactics — a local climber, a broad explorer, an annealer, a restart protocol — each matched to a different hypothesis about the landscape, then shifts effort toward whichever is actually performing. The one idea that makes it this mechanism and not a single tactic is that it manages a set of competing tactics as a portfolio with dynamic allocation: the object it tunes is the mix of strategies and how budget flows among them, not any one strategy's internal moves. It is the meta-level workflow that turns uncertainty about terrain into a spread bet with feedback.
Example¶
An airline is solving a monthly crew-scheduling problem — assigning thousands of pilots and flight attendants to flights under a thicket of rest rules and cost objectives. The operations-research team knows from experience that no single solver dominates: on some months the problem yields to a fast local-search heuristic, on others only a restart-heavy metaheuristic or a longer branch-and-bound run finds the good regions. Rather than guess, they run a portfolio: three solvers launched together on the same instance, each embodying a different assumption about the month's landscape, with a shared clock. Early progress is watched, and after the first stretch the budget is reallocated — the two solvers that stalled are throttled back and the one still finding improvements gets the freed compute. The month's best schedule comes from a solver that, going in, no one would have confidently picked first.
How it works¶
- Enumerate tactics tied to hypotheses — each candidate solver or search regime encodes a specific guess about the terrain (smooth, rugged, multi-basin, bounded).
- Allocate an initial budget across the set, in parallel or staged.
- Watch performance and reallocate — shift effort toward tactics that are improving and starve those that have stalled.
- Retire and refresh — kill clearly losing tactics, and add one if the observed terrain suggests a hypothesis the portfolio doesn't yet cover.
Tuning parameters¶
- Portfolio composition — which tactics are included; a diverse set hedges more terrain but spreads budget thinner across each.
- Initial allocation — how compute is split at the start; even splits are neutral, weighted splits front-load a favored hypothesis.
- Reallocation aggressiveness — how fast budget chases the current leader; aggressive shifts exploit a winner early but can abandon a slow-starting tactic prematurely.
- Parallel vs. staged — whether tactics run concurrently or in sequence; parallel gets answers faster, staged is cheaper when tactics can be ruled out one at a time.
- Retire threshold — how far behind a tactic must fall before it is cut.
When it helps, and when it misleads¶
It is most valuable exactly when terrain is uncertain and the tactics available have complementary strengths, so no single choice is safe — the portfolio converts "pick the right algorithm" into "let performance pick it."[n1] Its failure mode is overhead and correlated blind spots: running many tactics costs real budget, and if every tactic in the set shares the same weakness, the portfolio inherits it and its diversity is an illusion. The classic misuse is padding the portfolio with tactics for comfort rather than because each answers a distinct terrain hypothesis. The guarding discipline is to compose the portfolio for genuine diversity — each member justified by a different landscape assumption — and to reallocate on evidence of performance, not on which tactic is most familiar.
How it implements the components¶
search_regime_selection_rule— instead of choosing one regime up front, it runs several and lets observed performance select the winner, the selection rule made dynamic.exploration_exploitation_balance— reallocating budget across tactics is an explore/exploit decision at the portfolio level: keep sampling laggards or pour effort into the leader.strategy_switch_trigger— its reallocation and retirement thresholds are the explicit triggers for shifting effort between strategies.feature_hypothesis_map— the set of tactics is a portfolio of terrain hypotheses, and which one wins is itself evidence about the landscape's shape.
It does not itself fit a surrogate_model — that is Response Surface Model — nor lay out the diverse landscape_probe_plan reconnaissance of Coarse Landscape Sampling; the portfolio orchestrates tactics rather than being one.
Related¶
- Instantiates: Landscape-Aware Search Strategy Design — supplies the meta-level workflow that hedges across search regimes under terrain uncertainty.
- Consumes: Optimization Trace Dashboard — its per-tactic performance signals are what drive reallocation and retirement.
- Sibling mechanisms: Annealing or Perturbation Schedule · Coarse Landscape Sampling · Gradient or Directional Probe · Objective Surface Sketch · Optimization Trace Dashboard · Parameter Sweep and Sensitivity Grid · Random Restart Plan · Response Surface Model
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Search Algorithm Portfolio operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it runs or stages multiple search tactics, each matched to a different landscape hypothesis, then reallocates effort based on observed performance.
Independent corroboration: The frozen evidence defines Search Algorithm Portfolio as 'Runs or stages multiple search tactics, each matched to a different landscape hypothesis, then reallocates effort based on observed performance', so its operative form is Control, Automation & Runtime.
Nearest alternative: Analysis, Modeling & Optimization — Search Algorithm Portfolio includes features of an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Selecting among complementary algorithms by instance characteristics is the computer-science algorithm-selection and portfolio problem. Rice formalized algorithm selection and ICAPS applies portfolios to planning; operations research contributes optimization criteria rather than the primary computational lineage.
Related originating lineages:
- Futurism & Strategic Foresight — Strategic foresight, scenario planning, and anticipatory governance supplies a parallel or contributing lineage for the mechanism's defining operation: runs or stages multiple search tactics, each matched to a different landscape hypothesis, then reallocates effort based on observed performance.
- Mathematics — Mathematical modeling, proof, and abstract-structure practice supplies a parallel or contributing lineage for the mechanism's defining operation: runs or stages multiple search tactics, each matched to a different landscape hypothesis, then reallocates effort based on observed performance.
- Operations Research — Adaptive allocation materially reallocates effort by observed performance.
- Statistics & Experimental Design — statistics_experimental_design contributes measurement, perturbation design, inference, and uncertainty analysis to this mechanism's defining operation—Runs or stages multiple search tactics, each matched to a different landscape hypothesis, then reallocates effort based on observed performance—without displacing the selected primary historical lineage.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus operations_research). Authoritative or primary research supports computer_science as the best historical origin: Selecting among complementary algorithms by instance characteristics is the computer-science algorithm-selection and portfolio problem. Rice formalized algorithm selection and ICAPS applies portfolios to planning; operations research contributes optimization criteria rather than the primary computational lineage. The cited Rice, The Algorithm Selection Problem; ICAPS, Planning Portfolio Methods directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=convergent records the lineage relationship, while domain_reach=specialized records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Algorithm portfolios (Gomes & Selman) run several solvers in parallel or interleaved and keep the first to succeed; the SATzilla approach extends this by selecting solvers per instance. Both exploit the fact that solver performance varies wildly across problem instances — the same complementarity this workflow relies on. ↩