Knowledge Boundary Probing and Demand-Guided Intervention for LLM-Based Power System Code Generation

Small AI models often fail at power grid tasks not because they can't think, but because they forget specific technical commands. This research identifies that the primary bottleneck in power-system code generation is not a lack of reasoning. Instead, it is "API-knowledge boundaries"—errors like hallucinated function names, misused parameters, or mishandled result tables in specialized simulation libraries. By identifying exactly what a model doesn't know and injecting the correct documentation at the right time, the authors show we can allow smaller, private, on-premise models to perform as accurately as expensive, cloud-based APIs.

The Problem

In the energy sector, utilities and research labs rarely use hosted, closed-source APIs. They require on-premise serving for data confidentiality, regulatory compliance, and reproducibility. The standard fallback is deploying open-weight LLMs (models whose weights are publicly available) on-premise. However, the industry consensus has been that small-to-mid-size models are too unreliable for complex power-system analysis.

The authors argue this view misses the actual failure mode. As shown in, the problem isn't necessarily a lack of logical capacity.

Rather, the model hits a "knowledge boundary" where it fails to correctly invoke the domain-specific library (pandapower). These first-pass failures are dominated by API-driven non-execution. This means the model hallucinates a function name or misconfigures a parameter. Simply scaling up the model size is an inefficient way to solve a problem that is essentially a documentation retrieval and precision issue.

How It Works

The proposed solution is a deployment-time reliability workflow. It requires no fine-tuning or modification of model weights. It consists of three interconnected components :

1. L0–L3 Probing: Before deployment, the system runs a hierarchical probing procedure. It tests the model across four layers of competence: Recognition (L0), Recall (L1), Comprehension (L2), and Application (L3). This process converts the API specification into a per-model "risk profile" $\rho_M(f)$. This profile quantifies exactly where a model's knowledge breaks down for any given function $f$ .

2. Demand-Guided Probing: At inference time (the stage where the model generates a response), a query-side demand estimator predicts which API functions a natural-language query is likely to require. This ensures the system targets the specific tools needed for the task.
3. Boundary-Aware Intervention: This is a two-phase loop. In the Proactive Phase, the system intercepts the prompt. It injects only the specific documentation layers that the model's risk profile suggests it lacks. In the Reactive Phase, if the code fails during execution, a router analyzes the error. It distinguishes between code-syntax errors and value-mismatch errors (where the code runs but the result is numerically incorrect). It then injects targeted "boundary cards" or API contracts to guide a repair attempt .

Numbers

The results are significant enough to change the math for on-premise deployment. The authors report that the intervention lifts the accuracy of every evaluated open-weight model ($\ge$7B parameters) and every commercial API by 32 to 56 percentage points.

Crucially for engineers managing hardware budgets, the method enables a "workload-aware" deployment strategy. The paper finds that mid-size open-weight models in the 70B–120B range match the accuracy of the four tested mid-tier commercial APIs .

For example, Llama-3.1-70B and GPT-OSS-120B fall inside the mid-tier API accuracy range. Furthermore, the proactive injection is highly efficient regarding context window management (the amount of text a model can process at once). The authors demonstrate that this method reaches the accuracy ceiling of a "full-context" dump while using only 41% of the prompt-token cost . This saves over 2,000 tokens per item. This represents a massive saving in both latency and compute overhead per successful generation.

What's Missing

While the results are compelling, there are several gaps. First, the benchmark is currently limited to the pandapower library. Moving to other backends like MATPOWER or OpenDSS would require regenerating the entire API contract and probe suite.

Second, the paper focuses almost exclusively on accuracy-side improvements. It does not report on hardware-dependent metrics such as tail latency (the delay experienced by the slowest requests) or total energy consumption. For a utility, knowing the accuracy is vital. However, knowing the impact on the inference server's P99 latency is equally critical. Finally, the effectiveness of the demand predictor relies on a "transductive adaptation" assumption. This assumes you have access to an unlabeled corpus of target-domain queries to refine the ranker before deployment.

Should You Prototype This

Yes, if you are tasked with deploying LLMs in a privacy-constrained environment. The core insight is that API hallucinations are a solvable deployment-time problem. You don't need to spend weeks fine-tuning a 405B model. You can potentially get "API-grade" performance out of a 70B model on your own hardware.

The code for the PowerCodeBench benchmark is reportedly available at https://github.com/huiwxing/PowerCodeBench. If your workflow involves heavy use of versioned scientific libraries, this is a more efficient path to reliability than brute-force scaling.

Figures from the paper