Explainability Assistant parses 94% of queries, beating TalkToModel's 76.8%

The people who run buildings rarely get to ask their forecasting models a question. They get a dashboard: a feature-importance chart, a row of controls built for someone who already knows which knob to turn. For a facility manager trying to work out why Tuesday's load forecast came in high, that chart is not an explanation. The same complaint follows explainable AI into other operational settings, as in explainable RL for air traffic control.

A paper submitted to arXiv on 10 September 2026 argues the interface itself has been the problem, and that the fix came from an unexpected place. The Explainability Assistant, which the authors describe as open source, lets operators interrogate an energy consumption model in ordinary language. It reports 94% intent-parsing accuracy, against 76.8% for TalkToModel, an earlier conversational XAI system constrained by hand-written grammars.

The seventeen-point spread is not the interesting part. The architecture behind it is: TalkToModel recognised a fixed set of phrasings, while the Explainability Assistant routes questions through the function-calling capabilities of modern large language models. According to the paper, that lets the system support flexible natural language and adapt to different ML problem types without task-specific fine-tuning.

Hand-written grammars were the bottleneck

A custom grammar is a bet that you can predict how people will phrase a question. You write patterns for the word why, for what-if questions, for requests to explain one prediction, and then an operator asks something the patterns never anticipated. The grammar misses. The operator rephrases, slightly differently. The interface feels broken even when the model behind it is working correctly.

Function calling sidesteps that by letting the model decide which tool a question maps to, rather than matching it against a list. The paper treats this as the central architectural choice, and the 76.8% to 94% gap is the evidence attached to it. Those seventeen points separate a system that understands most of what it is asked from one that understands nearly all of it.

There is a second claim in the abstract worth pulling apart. Because the interface is not fine-tuned for a specific task, the paper says it adapts across ML problem types. One conversational layer could sit in front of a genetic-programming-based symbolic regressor or another model without being rebuilt. The evaluation is set in the energy domain, but the architectural argument does not depend on it.

What the headline number does not cover

Read that table and it looks like a clean win, which is roughly how the abstract presents it. Intent-parsing accuracy measures whether the system worked out what the user wanted. It says nothing about whether the explanation that followed was correct, complete, or useful to the person reading it. That gap between executing the task and reaching a good outcome runs through AI evaluation, where agents can run flawless statistics and still draw the wrong conclusions.

The paper does report a comparative evaluation run with energy domain specialists, contrasting the assistant against a traditional XAI dashboard. The results are described as improved usability and consistent task accuracy, and all the experts preferred the conversational interface for practical use.

Unanimous preference is a real signal, and an underspecified one. The material available does not say how many specialists took part, how many tasks each completed, or whether task accuracy was scored against a fixed rubric. Preference in interface studies tends to favour whatever feels faster and more responsive, which a chatbot usually does. Human raters do not always confirm the improvements a system claims for itself, as PsychoAgent's evaluation showed. Whether the operators reached better conclusions is a different measurement, and one the abstract does not report.

The dependency the paper does not discuss

An explanation layer built on function calling inherits the properties of the model underneath it. Every question carries a per-query cost and some latency, and whoever hosts that model can update or retire it without asking anyone. The authors call the system open source, but the material provided does not specify which model it calls or whether that model runs locally or through a hosted API. For a campus facilities team or a utility deciding whether to put this in front of staff, that detail is likely to decide the deployment.

Where the next evaluation has to go

The contribution here is narrower than a chatbot that explains a forecast, and more useful than it sounds. A conversational XAI layer can now be assembled without a bespoke parser, which removes one of the main engineering costs that kept these interfaces out of facilities software. That cost used to mean hiring a team to write and maintain a grammar. It now means wiring up a function-calling model.

What has not gotten easier is the part after parsing. An operator who asks why a model predicted high consumption wants an answer they can act on: shift a schedule or check a sensor. Knowing the right procedure and applying it are different problems, a split visible in financial benchmarks where models recite formulas they cannot apply. Recognising the question correctly is a prerequisite for that, not a substitute for it. Whether the explanation on the other side changes what the operator does next is the question this paper raises and leaves open.