Skip to content

ORCH-1.13: GEPA Reflective Prompt Optimizer

Overview

The GEPA (Genetic-Pareto) Reflective Prompt Optimizer introduces evolutionary learning mechanisms for RLM (Recursive Language Model) prompts within the agent-utilities ecosystem. By shifting away from sample-inefficient scalar rewards (like GRPO), GEPA utilizes natural language execution and evaluation traces to reflectively mutate and optimize prompts, while maintaining a Pareto frontier of candidate prompts to prevent local minima.

Schema Diversity Perturbation

A critical addition to GEPA is the Schema Diversity Sweep, which mitigates the risk of the model overfitting to static, hardcoded API schemas (e.g., rigid JSON shapes typical in enterprise integration).

How It Works

Within the GEPAOptimizer loop, when enable_schema_diversity=True is enabled, the system automatically injects recursive structural perturbations into the data payloads being evaluated. These perturbations include: 1. Key Nesting Variations: Wrapping data in transient intermediary dictionary keys. 2. Noise Injection: Inserting random, non-functional key-value pairs into the payload structure. 3. Casing Randomization: Toggling keys between snake_case, camelCase, and PascalCase.

By exposing the RLM to these structural mutations during the evaluation trajectory, GEPA ensures that the learned prompt strategies remain structurally robust and are generalized enough to handle real-world API schema drift.

Telemetry & Lineage Persistence

GEPA introduces two new KG node types to track evolutionary provenance across the optimization pipeline: - OptimizationTrajectoryNode: Captures the complete lineage of an evaluated prompt, including its thinker ID, the query hash, the reasoning summary, the specific accuracy score, and the LLM model utilized. - EvaluatorFeedbackNode: Links the raw execution trajectories to the scalar rewards and textual feedback generated by the reflection agent.

These nodes ensure that every evolutionary step is materialized in the Epistemic Graph, enabling the consolidated maintenance scheduler (_tick_evolution within _maintenance_scheduler_loop, knowledge_graph/core/engine_tasks.py) to track and report on optimization throughput dynamically.

Modernized Orchestration: GraphBuilder API

In conjunction with GEPA enhancements, the underlying graph execution topology has been modernized. The legacy manual Graph() instantiation logic in kg_graph_factory.py has been fully deprecated in favor of the GraphBuilder API from pydantic_graph.beta.

Key Lifecycle Changes

  1. Topological Materialization: Instead of appending nodes directly to an immutable graph instance, agents now add node classes to a dynamic GraphBuilder object.
  2. Strict Validation Bypassing: Due to dynamic swarm node instantiation from KG representations, the factory uses validate_graph_structure=False during builder finalization. This allows cyclical dependencies (inherent in GEPA and RLM back-and-forth loops) to materialize properly without failing the DAG topological checks.
  3. Isolated Engine Fallbacks: The pipeline accommodates stateless operations and unit testing via a defensive engine fallback template. If build_pydantic_graph_from_kg is invoked without a running graph engine, it automatically routes to a generic executor, preserving compatibility without failing due to uninitialized dependencies.