LLM Function Calling for Energy Diagnostics

The Explainability Assistant increases intent-parsing accuracy for energy diagnostics to 94%, replacing the 76.8% accuracy of constrained grammars found in legacy tools. This system moves away from static, dashboard-based interfaces in favor of conversational control. It functions by injecting a JSON schema of available diagnostic tools into the system prompt of an LLM. The model is instructed to output a JSON payload structured to match the schema whenever a user's intent maps to a tool signature. This approach allows users to query complex systems using natural language rather than navigating fixed menu hierarchies. Traditional legacy tools often relied on brittle, pre-defined rules that frequently failed when user intent fell outside of a narrow syntactic range. The Explainability Assistant treats intent mapping as a classification and extraction task, allowing for more flexible interaction with backend regression models. By serving as a translation layer, the LLM converts abstract questions into the precise API calls required by diagnostic systems. Consider a facility manager asking why energy consumption spiked during a specific period. The LLM translates this request into a structured call, such as feature_importance(start_time="14:00", end_time="18:00"). The system operates by identifying the relevant function from the schema and extracting the necessary time values to populate the parameters. This mechanism relies on the model's ability to ground specific natural language terms into the format required by the diagnostic backend. The primary challenge remains the potential for model hallucination when queries contain ambiguous constraints. While schema-based prompt injection provides the structure, it does not guarantee the logical validity of the extracted parameters. For instance, a user might request a diagnostic for a time window that is chronologically inverted or outside of the available data range. The model might successfully generate a JSON object that satisfies the structural schema—a string for the start and end times—but the resulting API call would be logically nonsensical. Developers must therefore implement a guardrail layer that performs a semantic check against the actual system state before execution. This ensures that the generated parameters, while syntactically correct according to the JSON schema, are also factually feasible for the underlying energy model. This validation step is essential, as the model's performance is inherently bounded by the specificity and clarity of the definitions provided in the prompt. If the model fails to populate a required field or generates values that violate business logic, the system must be capable of rejecting the call and prompting the user for clarification. The effectiveness of this system depends on how well the developer translates diagnostic capabilities into machine-readable descriptions that the model can interpret.