BuildEvo: LLM-Driven Energy Forecasting

• BuildEvo is an evolutionary framework that integrates LLMs to automatically generate transparent, physics-grounded Python heuristics for energy consumption forecasting.
• It employs a structured five-phase loop—initialization, evaluation, selection, crossover/mutation, and reflection—that combines physical insights with search diversity to balance accuracy with interpretability.
• The framework demonstrates strong cross-building generalization on datasets like BDG2, offering interpretable forecasting rules that outperform opaque models in reliability and trustworthiness.

BuildEvo is a framework for automatically discovering and refining transparent, physically-informed heuristics for building energy-consumption forecasting by embedding a LLM into an evolutionary loop (Lin et al., 16 Jul 2025). In the cited literature, the name also appears in two adjacent but distinct senses: as a blueprint for constructing robust, long-horizon agentic evolutionary systems derived from AEvo (Zhang et al., 13 May 2026), and as an open-ended Minecraft-building generator that combines CPPN-NEAT with a continuously adapting latent novelty metric (Barthet et al., 2022). The best-defined usage, however, is the forecasting framework: it takes historical energy consumption, exogenous features, and building metadata as input, and returns a small set of human-readable Python heuristics that balance predictive accuracy with physical interpretability.

1. Definition and problem setting

BuildEvo for energy forecasting was introduced against a specific methodological tension: traditional heuristics often lack precision, while advanced models can be opaque and can struggle with generalization by neglecting physical principles (Lin et al., 16 Jul 2025). Its stated objective is therefore not merely point forecasting, but the automated design of robust, physically grounded heuristics whose logic remains directly inspectable.

The workflow operates on three input classes. The first is historical energy consumption, denoted in the paper as $C_b^{1:T_{\text{obs}}}$. The second is exogenous features $X_b^{1:T_{\text{obs}}}$, including weather and calendar variables. The third is building metadata, such as floor area, primary space usage, and envelope parameters. The output is not a trained latent model or opaque parameter tensor, but executable Python code implementing forecasting rules.

This design choice places BuildEvo between manual rule engineering and conventional end-to-end ML. A plausible implication is that the framework treats forecasting heuristics themselves as the search object, rather than treating heuristic structure as fixed and learning only coefficients. That distinction is central to its reported emphasis on trustworthiness, deployment ease, and cross-building generalization.

2. Evolutionary architecture and LLM integration

At a high level, BuildEvo instantiates an evolutionary-LLM loop with five explicit stages: initialization, evaluation, selection and elitism, crossover or mutation, and repetition until convergence or budget exhaustion (Lin et al., 16 Jul 2025). During initialization, an LLM generates an initial population of $N$ Python-coded heuristics $h_i$. During evaluation, each heuristic is executed on training data to compute a fitness score $J(h_i)$, with RMSE given as an example objective. Selection and elitism preserve top performers while also retaining random candidates for variation. Offspring generation is then driven by crossover and mutation operations guided by reflective feedback and archive-based sampling.

The LLM in the reported implementation is Google Gemini 2.0 Flash. Its role is not generic free-form reasoning, but that of a “genetic operator.” Prompts describe the forecasting task specification, examples of existing heuristics or code snippets, and reflective feedback about which physical components helped or hurt performance. In crossover, the model is instructed to merge parent functions while preserving their best physical rules. In mutation, it is instructed to refine a heuristic by adjusting coefficients or introducing weather dependence consistent with heat-balance principles.

Two mechanisms are especially salient. The first is the Physical Insights Feedback Loop (PIFL), which feeds physical utility signals back to the LLM. The second is Cross-Generation Elite Sampling (CGES), which draws from an archive of historical elites to maintain diversity. Together, these mechanisms make the search neither a standard EA over fixed strings nor an unconstrained code-synthesis loop. Instead, BuildEvo evolves executable heuristics under structured feedback about both predictive performance and physical plausibility.

3. Heuristic form, feature encoding, and physics-guided constraints

The evolved forecasting rules are summarized by the paper in the form

$$\hat C_b(t) = h(\mathbf{x}_b(t);\boldsymbol\alpha) = \alpha_0 + \sum_{k=1}^{p}\alpha_k\,f_k\bigl(x_{b,k}(t)\bigr) + \sum_{k,\ell}\alpha_{k\ell}\,f_{k\ell}\bigl(x_{b,k}(t),x_{b,\ell}(t)\bigr),$$

where $x_{b,k}(t)$ may be a building feature, a weather variable, or a schedule feature; $f_k(\cdot)$ are simple functions such as identity, square, and ReLU; $f_{k\ell}(\cdot)$ capture pairwise interactions; and $\boldsymbol\alpha$ are scalar coefficients discovered or tuned via the evolutionary process (Lin et al., 16 Jul 2025).

The feature encoding is explicitly physical. Floor area $X_b^{1:T_{\text{obs}}}$0 enters as a multiplier for base-load. Primary space usage, encoded one-hot, triggers occupancy-driven terms. Envelope U-value $X_b^{1:T_{\text{obs}}}$1 appears in heat-loss computations. Exogenous variables include outdoor temperature $X_b^{1:T_{\text{obs}}}$2, humidity $X_b^{1:T_{\text{obs}}}$3, solar irradiation $X_b^{1:T_{\text{obs}}}$4, and temporal terms such as $X_b^{1:T_{\text{obs}}}$5, $X_b^{1:T_{\text{obs}}}$6, and day-of-week flags. The PIFL scores fragments such as

$X_b^{1:T_{\text{obs}}}$7

and returns that utility signal to the LLM.

Physical plausibility is enforced through soft constraints. The coefficient on $X_b^{1:T_{\text{obs}}}$8 is constrained to be non-negative under heat-balance linearization, and occupancy-driven terms $X_b^{1:T_{\text{obs}}}$9 must respect $N$0. These checks are incorporated into fitness evaluation via regularization penalties rather than by hard rejection. The reported fitness metrics are RMSE, MAE, and MAPE, and the paper gives a regularized objective of the form

$N$1

A common misconception is that BuildEvo is simply prompting an LLM to write arbitrary forecasting code. The stated formulation shows otherwise: the search space is bounded by explicit feature semantics, physically meaningful term templates, and sign or magnitude constraints encoded in evaluation.

4. Search dynamics, reflection, and prompt engineering

The paper presents the BuildEvo loop as a code-level evolutionary procedure:

$$\hat C_b(t) = h(\mathbf{x}_b(t);\boldsymbol\alpha) = \alpha_0 + \sum_{k=1}^{p}\alpha_k\,f_k\bigl(x_{b,k}(t)\bigr) + \sum_{k,\ell}\alpha_{k\ell}\,f_{k\ell}\bigl(x_{b,k}(t),x_{b,\ell}(t)\bigr),$$3

This loop makes reflection a first-class search operator rather than a post hoc analysis step (Lin et al., 16 Jul 2025). “Short-term” reflection compares current top performers to identify beneficial code patterns, while “long-term” reflection accumulates historical insights from the archive. The archive is not merely elitist storage; through CGES it becomes a diversity-maintaining reservoir from which mutation draws.

Prompt engineering is correspondingly operationalized. The initialization template asks for Python functions that predict next-hour energy consumption from history, exogenous variables, and metadata, while explicitly requesting building physics, heat-balance, occupancy schedules, and comments. The crossover template instructs the model to merge strengths such as weather normalization and envelope heat-loss while ensuring non-negative UA coefficients. The mutation template directs the model to introduce an occupancy term $N$2 with $N$3 and to adjust weather coefficients by $N$4.

This arrangement differs from generic program synthesis in two ways. First, offspring generation is conditioned on evolutionary state, archive content, and reflective summaries. Second, the generated artifacts are intended to remain interpretable at the granularity of individual code terms.

5. Experimental validation, interpretability, and generalization

The reported experiments use the Building Data Genome Project 2 (BDG2), with 240 real buildings spanning mixed residential and commercial types, an 80/20 temporal split per building, and cross-building generalization experiments that train on one usage type and test on another (Lin et al., 16 Jul 2025). Baselines include LR, SVR, RF, LSTM, Informer, and PSO-Informer.

The main table reports MAPE / RMSE / MAE on five cross-building tasks. For the task “To College Class.,” BuildEvo w/ PIFL attains $N$5, compared with $N$6 for PSO-Informer and $N$7 for BuildEvo w/o PIFL. For “To Public Serv.-R,” BuildEvo w/ PIFL attains $N$8, compared with $N$9 for PSO-Informer and $h_i$0 for BuildEvo w/o PIFL. The accompanying ablation states that removing the Physical Insights Feedback Loop yields an approximately $h_i$1 relative drop in RMSE improvement, while removing CGES lowers diversity and slows convergence.

Interpretability is treated as an empirical property of the outputs, not as a rhetorical claim. The resulting heuristics are plain Python functions with comments, and terms such as “base-load = 0.05*A_b” remain directly visible. Coefficients can be traced back to physical meanings including U-value and occupancy multipliers. This is materially different from post hoc attribution on opaque models.

Generalization is evaluated in both cross-building and climate-transfer settings. The paper reports that BuildEvo’s heuristics degrade gracefully on cross-building tests such as office $h_i$2 dormitory and often outperform deep models by $h_i$3–$h_i$4 MAPE. It further reports that training on temperate-zone buildings and testing on hot/arid zones retains low error because of explicit weather-interaction terms. These results underpin the paper’s claim of state-of-the-art benchmark performance while preserving transparent prediction logic.

6. Other systems and blueprints using the name

The term “BuildEvo” is not unique to the energy-forecasting framework. In the provided literature it also denotes a blueprint for an agentic evolutionary system based on “Harnessing Agentic Evolution,” and a Minecraft-building generator based on open-ended novelty search (Zhang et al., 13 May 2026, Barthet et al., 2022).

Usage of the name	Core mechanism	Source
Building energy forecasting	LLM-driven evolution of Python heuristics with PIFL and CGES	(Lin et al., 16 Jul 2025)
Agentic evolutionary blueprint	Harnessed meta-editing of a procedure or agent context	(Zhang et al., 13 May 2026)
Minecraft building generation	CPPN-NEAT with latent-space novelty and autoencoder retraining	(Barthet et al., 2022)

In the AEvo-derived blueprint, BuildEvo is formulated over an object space $h_i$5, round contexts $h_i$6, accumulated context $h_i$7, and an optimization mechanism $h_i$8 that can itself be edited by a meta-agent. The meta-agent observes a summary $h_i$9, emits an edit $J(h_i)$0, and updates the optimization mechanism via $J(h_i)$1. The architecture includes a Harnessed Workspace with CLI commands such as init, run-segment, inspect-history, and resume, and supports both procedure-based and agent-based instantiations. Reported gains include raising Terminal-Bench Avg@3 from approximately $J(h_i)$2 to $J(h_i)$3, ARC-AGI-2 from approximately $J(h_i)$4 to $J(h_i)$5, and a $J(h_i)$6 average improvement over the strongest fixed baseline.

In the Minecraft system, BuildEvo consists of ten independent populations of CPPNs evolved by CPPN-NEAT, repair and constraint modules that enforce connectivity and entrance feasibility, and a 3D autoencoder mapping repaired material lattices to a $J(h_i)$7-dimensional latent vector. Novelty is defined as the average Euclidean distance to $J(h_i)$8 nearest neighbors in latent space, with exploration and transformation alternating over $J(h_i)$9 rounds. Among the five autoencoder variants, FH-AE achieves the lowest average reconstruction error, NA-AE preserves phenotype diversity near static levels and yields a Pearson correlation of approximately $$\hat C_b(t) = h(\mathbf{x}_b(t);\boldsymbol\alpha) = \alpha_0 + \sum_{k=1}^{p}\alpha_k\,f_k\bigl(x_{b,k}(t)\bigr) + \sum_{k,\ell}\alpha_{k\ell}\,f_{k\ell}\bigl(x_{b,k}(t),x_{b,\ell}(t)\bigr),$$0 between latent distance and voxel-KL, while Random AE is reported as unusable with reconstruction errors around $$\hat C_b(t) = h(\mathbf{x}_b(t);\boldsymbol\alpha) = \alpha_0 + \sum_{k=1}^{p}\alpha_k\,f_k\bigl(x_{b,k}(t)\bigr) + \sum_{k,\ell}\alpha_{k\ell}\,f_{k\ell}\bigl(x_{b,k}(t),x_{b,\ell}(t)\bigr),$$1–$$\hat C_b(t) = h(\mathbf{x}_b(t);\boldsymbol\alpha) = \alpha_0 + \sum_{k=1}^{p}\alpha_k\,f_k\bigl(x_{b,k}(t)\bigr) + \sum_{k,\ell}\alpha_{k\ell}\,f_{k\ell}\bigl(x_{b,k}(t),x_{b,\ell}(t)\bigr),$$2.

A common source of confusion is therefore nomenclature rather than substance: the three systems share an evolutionary orientation, but they optimize different objects, use different feedback channels, and operate at different levels of abstraction.

7. Limitations, future directions, and broader evolutionary context

For building energy forecasting, the reported strengths are fully automated discovery of clear, physics-grounded heuristics without human-crafted rule sets, competitive accuracy with robust out-of-sample generalization, and transparent code output suitable for industrial building-management systems (Lin et al., 16 Jul 2025). The reported limitations are equally specific: heuristic expressivity is limited to relatively simple algebraic forms and pairwise interactions; highly nonlinear dynamics such as vapor-compression cycling may not be fully captured; LLM reliance can introduce latency and occasional code syntactic or semantic errors requiring human review; and scalability to very large search budgets may be constrained by API cost and repeated evaluation runtime.

The future directions listed for the forecasting framework extend the same design philosophy rather than replacing it. These include multi-objective evolution for energy versus peak-demand trade-offs, integration of more detailed lumped-parameter physics such as multi-node RC networks, transfer of the paradigm to district heating, battery storage scheduling, and renewable-inverter dispatch, and hybrid heuristics that embed small neural networks to model residual nonlinearities.

Within the broader EC tooling landscape, BuildEvo occupies a distinct position. ECLIPSE separates scientific design workflows into Individuals, Evaluators, and Evolvers, with explicit support for black-box simulators, asynchronous task queues, and high-cost evaluation regimes (Foreback et al., 8 Jan 2026). ELEA, by contrast, is a browser-based environment built on Blockly for assembling, executing, visualizing, and exporting evolutionary algorithms via drag-and-drop, with Web Workers for multi-threading and export to XML, JavaScript, CSV, and JSON (Wagner et al., 2023). This suggests that BuildEvo is best understood not as a general EC library, but as a domain-specialized evolutionary system in which the search objects are interpretable forecasting heuristics and the variation operators are mediated by an LLM under physical and reflective feedback.

Taken together, the BuildEvo label identifies a family resemblance rather than a single canonical architecture: evolutionary search is combined with structured representations, feedback-rich evaluation, and explicit mechanisms for preserving either interpretability, long-horizon adaptability, or open-ended novelty.