From Instance Selection to Fixed-Pool Data Recipe Search for Supervised Fine-Tuning
Abstract: Supervised fine-tuning (SFT) data selection is commonly formulated as instance ranking: score each example and retain a top-$k$ subset. However, effective SFT training subsets are often produced through ordered curation recipes, where filtering, mixing, and deduplication operators jointly shape the final data distribution. We formulate this problem as fixed-pool data recipe search: given a raw instruction pool and a library of grounded operators, the goal is to discover an executable recipe that constructs a high-quality selected subset under a limited budget of full SFT evaluations, without generating, rewriting, or augmenting training samples. We introduce AutoSelection, a two-layer solver that decouples fixed-pool materialization based on cached task-, data-, and model-side signals from expensive full evaluation, using warmup probes, realized subset states, local recipe edits, Gaussian-process-assisted ranking, and stagnation-triggered reseeding. Experiments on a 90K instruction pool show that AutoSelection achieves the strongest in-distribution reasoning average across three base models, outperforming full-data training, random recipe search, random top-$k$, and single-operator selectors. Additional Out-of-distribution graph-reasoning results, search-stability analyses, structural ablations, and 1.5B-to-7B transfer checks further show that recipe structure matters beyond individual selection operators. Code is available at https://github.com/w253/AutoSelection.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Practical Applications
Immediate Applications
The paperโs fixed-pool โdata recipe searchโ reframes SFT data curation as an executable, auditable workflow. Below are applications practitioners can deploy now, leveraging the operator library, caching, warmup, state vectors, ranking, and reseeding introduced in AutoSelection.
Before the list: These applications assume you can canonicalize a fixed raw pool, compute per-sample cached signals once, and afford a limited number of SFT evaluations (e.g., 10โ20) per search.
- Industry MLOps: recipe-driven SFT data curation (software, finance, healthcare)
- What to do now:
- Replace ad-hoc top-k filtering with recipe search that composes filtering, mixing, and deduplication operators to select an SFT subset under fixed budgets.
- Use warmup (low/medium/high retention probes) to choose the right data scale early; then locally refine around the best recipe with stagnation-triggered reseeding.
- Fit a lightweight GP surrogate on recipe encodings and use state vectors (task-, data-, model-side statistics) as a pre-screening telemetry to avoid risky candidates before spending a full evaluation.
- Tools/workflows that can be built immediately:
- โData recipe registryโ and manifests (YAML/JSON): ordered operator sequences with parameters and seeds, treated as versioned assets alongside code.
- โRecipe dashboardโ with state-vector telemetry: track retained-size, diversity, redundancy, difficulty, varentropy, and activation-drift of realized subsets before SFT.
- CI for data: run a small suite of warmup probes and a budgeted search (e.g., B=15) on each model/version bump; record the incumbent recipe and selected subset.
- Assumptions/dependencies:
- Access to stable sample IDs; canonicalization and cached metrics are computed once over the fixed pool.
- Evaluation suite is representative of the product KPI; otherwise the search objective can misalign with production goals.
- Operator implementations exist for your data (e.g., SemDedup, MONA-like relevance, N-gram diversity, varentropy).
- Cost-efficient model scaling via cross-scale transfer (software, finance)
- What to do now:
- Search for recipes using a small model (1โ3B) and transfer the best selected subset to fine-tune a larger model (e.g., 7B), leveraging the positive cross-scale correlation shown.
- Tools/workflows:
- โPre-vetting pipelineโ: automate 1โ3B search runs and promote top-N selected subsets to larger models; measure Spearman correlations and track stability.
- Assumptions/dependencies:
- Transfer is approximate; maintain sanity checks on the large model since rank preservation is not guaranteed (ฯโ0.82 in the paperโs check).
- Regulated-data SFT in compliance-first environments (healthcare, finance, enterprise)
- What to do now:
- Adopt fixed-pool recipes when data movement and augmentation are restricted. Use deduplication and diversity operators to reduce redundancy and bias without generating new samples.
- Tools/workflows:
- โRecipe audit trailโ: store operator choices, thresholds, and seeds for compliance reviews; attach to model cards and data cards.
- โLicense/consent-aware filtersโ added as operators (e.g., source-based exclusion, PHI heuristics) in the same recipe.
- Assumptions/dependencies:
- Legal right to process the pool; operators must include PII/PHI safeguards if required.
- Fixed-pool boundary is suitable when policy forbids synthetic augmentation.
- EdTech SFT with curricular balance (education)
- What to do now:
- Use state vectors to maintain difficulty coverage and topic diversity across math, reasoning, and language tasks; run warmup across retention levels to find the smallest high-quality subset that meets accuracy targets.
- Tools/workflows:
- โCurriculum-aware recipe templatesโ that combine diversity (N-gram/action-object) with task-relevance operators and SemDedup to minimize redundancy.
- Assumptions/dependencies:
- Availability of per-domain relevance signals (MONA-like) or taggable subsets; alignment of evaluation benchmarks with target curricula.
- Research methodology and reproducibility (academia)
- What to do now:
- Publish recipes (not just final datasets) to enable ablations on operator ordering and composition; replicate paper-style structural ablations with matched seeds to quantify the โordering effect.โ
- Tools/workflows:
- โRecipeHubโ for sharing baseline recipes and structural variants; โRecipe Linterโ for invalid operator sequences or extreme parameter choices.
- Assumptions/dependencies:
- Community adoption of canonicalized pools and stable IDs to make results comparable.
- Data observability and pre-SFT screening (software, platform teams)
- What to do now:
- Use realized subset state vectors as a โdataset healthโ panel to detect undesirable shifts (e.g., too small, too redundant, too easy/hard) before fine-tuning.
- Tools/workflows:
- Integrations with MLflow/Weights & Biases: log recipe structure, state vectors, GP scores, and SFT outcomes; enable quick regression detection when recipes change.
- Assumptions/dependencies:
- Calibrated and interpretable cached metrics; teams should set guardrails (min/max retention, diversity floors).
- OOD-oriented SFT subset search for specialized tasks (software, scientific computing)
- What to do now:
- Include OOD tasks in the evaluation suite (e.g., graph reasoning) to steer recipe search toward generalizable subsets while staying in-distribution competitive.
- Tools/workflows:
- Multi-objective ranking in the Ranker that combines ID average and OOD performance; store Pareto-front recipes in the registry.
- Assumptions/dependencies:
- Access to OOD benchmarks; careful weighting to avoid overfitting to any single suite.
- Vendor and marketplace services
- What to do now:
- Offer โrecipe search as a serviceโ for client data pools: deliver an auditable recipe plus the selected subset as artifacts; optionally include transfer checks across model sizes.
- Tools/workflows:
- Packaged AutoSelection runners with configurable operator catalogs and compute budgets; automated reporting with comparisons to full-data and single-operator baselines.
- Assumptions/dependencies:
- Client permissions for canonicalization and evaluation; secure handling of data pools and logs.
Long-Term Applications
The following applications will benefit from additional research, scaling, or engineering beyond the paperโs current fixed-pool, budgeted-evaluation setting.
Before the list: These assume better multi-fidelity proxies, larger operator libraries (domain-specific), broader evaluations, and tighter integration with governance and production systems.
- Multi-fidelity and proxy-driven search at scale (software, energy-aware compute)
- Vision:
- Replace some full SFT runs with cheaper proxies (e.g., linear probes, partial-epoch SFT, learning-to-predict y(r) from recipe/state features) and resource schedulers (Hyperband/BOHB-like) to scale budgeted search to larger models.
- Potential tools:
- โProxy Ensembleโ services that predict recipe utility; carbon/latency-aware search planners.
- Dependencies:
- Validated proxy metrics that correlate with final quality across tasks and scales.
- Domain-specialized operator libraries and learned operators (healthcare, finance, robotics)
- Vision:
- Extend beyond generic relevance/diversity/dedup operators to include domain checkers (e.g., ICD/CPT coverage in healthcare, risk-taxonomy coverage in finance, instruction granularity for robotics).
- Learn operator thresholds/structures from meta-data or historical runs.
- Potential tools:
- โOperator SDKsโ with pluggable domain signals; meta-learning for operator parameterization.
- Dependencies:
- High-quality domain labels and metadata; privacy-preserving implementations where needed.
- Continuous recipe optimization in production (software platforms)
- Vision:
- Run recipe search as a continuous process with online A/B testing and drift detection; reseed when performance plateaus, automatically proposing edits as data distributions change.
- Potential tools:
- โRecipeOpsโ layer in MLOps stacks; automatic reseeding policies tied to online KPIs.
- Dependencies:
- Safe deployment gates, shadow evaluations, and rollback strategies.
- Governance standards and certification for data recipes (policy, compliance)
- Vision:
- Standardize recipe manifests and state-vector reporting as part of model cards; regulators assess โdata governance maturityโ via recipe transparency and dedup/consent evidence.
- Potential tools:
- โRecipe Provenance Ledgerโ analogous to data lineage; third-party audits; ISO-style certifications.
- Dependencies:
- Community consensus on schemas and metrics; legal recognition and guidance.
- Agentic co-pilots for end-to-end data workflows (software, enterprise)
- Vision:
- Combine recipe search with LLM agents that propose edits, repair invalid sequences, and negotiate trade-offs (ID vs OOD vs cost). Move beyond fixed-pool to hybrid workflows with controlled augmentation and rewriting.
- Potential tools:
- โData Curation Copilotโ that interacts with recipe history, cached signals, and business constraints.
- Dependencies:
- Guardrails to avoid spurious augmentations; attribution of gains to fixed-pool vs generated data.
- Marketplaces for reusable โrecipes as IPโ (industry ecosystem)
- Vision:
- Share/sell audited recipes that reliably improve certain capability profiles (e.g., math-heavy, retrieval-heavy), portable across model families and sizes.
- Potential tools:
- Recipe scoring and reputation systems; compatibility checkers (operator availability, pool descriptors).
- Dependencies:
- Interoperable canonicalization standards; privacy-safe recipe sharing.
- Fairness, safety, and risk control via recipe-level constraints (policy, responsible AI)
- Vision:
- Encode fairness/safety constraints as operators (toxicity filters, demographic coverage balancing) and enforce them during search; monitor risk via expanded state vectors.
- Potential tools:
- Constraint-aware Rankers and feasibility checks; โrisk-aware warmupโ probing sensitive regimes.
- Dependencies:
- Reliable sensitive-attribute proxies or consented labels; agreement on fairness metrics.
- Visual IDEs and โRecipeLintโ for data-program engineering (developer tooling)
- Vision:
- A visual editor to compose, validate, and simulate recipes; static analysis to catch brittle sequences (e.g., conflicting filters, over-aggressive dedup).
- Potential tools:
- IDE plugins, simulators that show expected state-vector shifts per operator change, and impact forecasts with uncertainty bounds.
- Dependencies:
- Robust operator semantics and metadata; recipe vectorization for explainability.
- Cross-modal and multi-task extension (multimodal assistants, robotics)
- Vision:
- Extend fixed-pool recipe search to multimodal SFT pools (text+vision/audio) and multi-task objectives (weighting mixtures), optimizing for diverse deployment contexts.
- Potential tools:
- Operator sets for modality balance, caption quality, alignment difficulty; multi-objective search backends.
- Dependencies:
- Modality-specific cached signals; compatible evaluation suites.
- Carbon- and budget-aware governance (energy, sustainability)
- Vision:
- Integrate compute cost, carbon intensity, and wall-clock constraints into ranking and reseeding; optimize recipes for โaccuracy-per-dollarโ or โaccuracy-per-kgCO2.โ
- Potential tools:
- Emissions-aware schedulers; cost dashboards linked to recipe steps and warmup regimes.
- Dependencies:
- Accurate cost/emission telemetry; organization-level targets.
Notes on feasibility across all applications:
- Compute: Even with Bโ15 evaluations, SFT on mid-sized models requires GPUs and disciplined scheduling.
- Data rights: Fixed-pool recipes do not eliminate licensing/consent obligations; operators should respect data source constraints.
- Objective alignment: Choose evaluation suites that reflect deployment tasks; otherwise the recipe will optimize the wrong target.
- Generalization: OOD gains were shown on graph reasoning; broader OOD validation is advisable before high-stakes use.
Collections
Sign up for free to add this paper to one or more collections.
