Skip to main content
Phase 4 makes EMEP measurable. You implement the systems that assess merged model quality, compare results against standardized benchmarks, and compute fitness scores that drive evolutionary search. Without rigorous evaluation, merge strategies cannot be ranked, and the EvolutionEngine in Phase 5 has no signal for optimization. This phase also adds Persian-language evaluation and safety checks to ensure EMEP serves diverse users responsibly.

Purpose

The purpose of Phase 4 is to close the feedback loop between merging and quality. Every merge produced in Phases 2 and 3 must be evaluated against task-specific benchmarks, general capability tests, and safety criteria. You build the EvaluationEngine for orchestrating assessment pipelines, the BenchmarkEngine for managing benchmark datasets and metrics, and the FitnessEngine for collapsing multi-dimensional results into scalar scores suitable for optimization. You also establish split enforcement so that training, validation, and test data never leak across evaluation stages.

Entry Criteria

  • Phase 3 exit criteria satisfied: all merge strategies (Linear, SLERP, Task Arithmetic, TIES, DARE, DARE+TIES, Franken-Merge) and merge validation are operational
  • Benchmark datasets identified and licensed for use
  • Evaluation metrics and scoring rubrics defined in Phase 0 research documentation
  • Compute resources provisioned for batch evaluation jobs
  • Persian-language test corpora and safety evaluation suites acquired

Exit Criteria

  • EvaluationEngine executes full evaluation pipelines: load merged model, run benchmarks, collect metrics, store results
  • BenchmarkEngine manages a catalog of registered benchmarks with versioning, configuration, and reproducibility metadata
  • FitnessEngine computes scalar fitness scores from multi-metric evaluation results using configurable aggregation functions
  • Benchmark catalog covers general capability, task-specific, Persian-language, and safety categories
  • Persian evaluation produces per-task and aggregate scores for Persian NLP tasks
  • Safety evaluation detects harmful outputs, bias, and policy violations with automated flagging
  • Split enforcement prevents data leakage by strictly separating training, validation, and test splits across all benchmarks
  • Evaluation results are persisted to ExperimentTracker with full provenance

Primary Components

Phase 4 implements and extends the following canonical components:
  • EvaluationEngine: the orchestrator for assessment pipelines. It loads a merged model from ArtifactStore, selects benchmarks from BenchmarkEngine, runs inference or fine-tuning evaluations, and persists results.
  • BenchmarkEngine: the catalog and execution layer for benchmarks. It registers datasets, metrics, and evaluation protocols. It enforces split discipline and reproducibility constraints.
  • FitnessEngine: the scoring layer that transforms benchmark outputs into scalar fitness values. It supports weighted combinations, Pareto frontiers, and custom aggregation functions.
Supporting components:
  • ExperimentTracker: receives evaluation logs, metrics, and artifact references for every evaluated merge
  • ArtifactStore: supplies merged checkpoints and stores evaluation reports
  • MergeEngine: produces the merged models that EvaluationEngine consumes

Deliverables

Dependencies

Phase 4 depends directly on Phase 3: Indirect dependencies:

Key Tasks

Track Phase 4 work in the project task registry: Typical Phase 4 tasks include:
  1. Implement EvaluationEngine pipeline: model loading, benchmark selection, execution, result collection
  2. Implement BenchmarkEngine with dataset registration, metric binding, and split tracking
  3. Implement FitnessEngine with weighted aggregation, normalization, and Pareto support
  4. Populate benchmark catalog with general capability tests (e.g., perplexity, MMLU subsets)
  5. Integrate Persian-language benchmarks: reading comprehension, sentiment, translation
  6. Integrate safety evaluation: toxicity classifiers, bias probes, policy rule sets
  7. Implement split enforcement with hash-based split integrity verification
  8. Connect EvaluationEngine to ExperimentTracker for automatic run logging
  9. Establish evaluation compute budgets and timeout policies
  10. Document benchmark selection guidance and fitness score interpretation

Risks

  • Benchmark contamination: Public benchmark data may appear in pre-training corpora, inflating scores. Mitigate by using held-out splits and novel task formulations where possible.
  • Evaluation cost: Full benchmark suites may require GPU-hours per merged model. Mitigate by tiering evaluation into quick sanity, standard, and deep modes.
  • Fitness function gaming: A narrow fitness function may drive evolution toward degenerate solutions. Mitigate by multi-objective fitness and diversity penalties.
  • Safety evaluation false negatives: Automated safety classifiers may miss subtle harms. Mitigate by combining automated and human-in-the-loop review for high-stakes deployments.
See the full risk register for tracked items and mitigations:

Quality Gate

Phase 4 is complete when the following checklist is fully satisfied:
  • EvaluationEngine executes a full pipeline end-to-end for every merge strategy from Phase 3
  • BenchmarkEngine catalogs at least one benchmark in each category: general, task-specific, Persian, safety
  • FitnessEngine produces deterministic scores for identical evaluation inputs
  • Split enforcement rejects any evaluation request that references a contaminated or overlapping split
  • Persian evaluation produces interpretable per-task and aggregate scores
  • Safety evaluation flags at least one known harmful output pattern in a controlled test
  • Evaluation results are queryable in ExperimentTracker by merge ID, strategy, and benchmark
  • Compute cost per evaluation is measured and documented for capacity planning

Roadmap Position

The diagram below shows Phase 4 as the measurement phase, converting merge outputs into comparable scores that feed the EvolutionEngine in Phase 5.