The problem: the model produced a number, but the business is still waiting for an answer

A quantitative forecast rarely arrives alone. It comes with dozens of features, factor weights, intervals, baselines and charts. For a specialist, this is normal working material. For a client, manager or reviewer, it can look like a box of components delivered without a useful manual.

Italian fintech SME Axyon AI faced exactly this bottleneck. Its models already generated forecasts and interpretable features for investment analytics, but producing clear and consistent explanations remained a manual task. Analysts spent time writing commentaries and justifications, while compliance teams needed text that could be reviewed, documented and communicated.

The tempting requirement is “ask an LLM to explain the numbers nicely.” This is one of those moments when “nicely” should be removed from the specification. The business needs an auditable translation from structured evidence into plain language, not a creative-writing club attached to a forecast model.

What the Axyon AI project did

According to the published FFplus case study, Axyon AI and UNIMORE–AImageLab developed a specialised financial language module. Its inputs included:

  • forecast signals;
  • SHAP values and other feature attributions;
  • asset metadata;
  • market context;
  • structured outputs from quantitative models.

The team benchmarked 15 open and commercial models through a unified evaluation pipeline. Selected mid-sized open-weight models were then fine-tuned with parameter-efficient methods including LoRA, mixed precision and memory optimisation. Experiments consumed 48,000 EuroHPC GPU-hours, and the resulting prototype was integrated into Axyon IRIS.

FFplus reports up to a 55% improvement in explanation quality over base models and estimates savings of roughly one FTE-month per client per year. These are participant-reported case results, not a universal guarantee. The public page does not fully disclose the evaluation set or every scoring detail, so the percentages should not be copied into another company's business case without a local pilot.

Why SHAP alone is not a finished explanation

SHAP describes how features contributed to a particular model output relative to a baseline. It is a useful technical signal, but it is not a management-ready explanation and does not establish causality.

A system may show that one indicator increased a forecast while another reduced it. The recipient still needs to understand:

  • which period and object were analysed;
  • how fresh the underlying data is;
  • whether the effect is large compared with normal variation;
  • whether signals conflict;
  • what limitations apply to the model;
  • who reviewed and approved the final wording.

If a raw attribution table is simply passed to an LLM, the model will happily add a coherent story. Sometimes it is too coherent: three numbers meet, get married and explain quarterly revenue. The language model should format evidence, not invent relationships between the facts it receives.

A practical architecture: narrator, not a second forecaster

For an SME deployment, the system can be separated into five layers.

1. The numerical source of truth

Forecasting, scoring or classification remains in the original model or analytics service. Factor attributions, confidence intervals and technical metrics are calculated there as well. The LLM should not recompute results by intuition or reverse the sign of an effect to make a sentence flow better.

2. The explanation contract

Between analytics and the LLM, use a machine-verifiable object such as strict-schema JSON containing:

  • model identifier and version;
  • calculation timestamp;
  • final output and units;
  • baseline value;
  • leading positive and negative factors;
  • magnitude of each contribution;
  • uncertainty interval;
  • data-quality warnings;
  • allowed formulations and mandatory caveats.

This contract makes the input reproducible. When a number changes, the team can distinguish a change in the analytical source from a change in wording.

3. A local language narrator

For recurring short explanations, a mid-sized model running in a protected environment is often sufficient. It does not need access to the entire corporate knowledge base. It needs the authorised structured package, controlled templates and a terminology dictionary.

Local deployment is especially relevant when the explanation includes customer positions, personal data, commercial indicators or internal risk assessments. “Local” does not mean “unmanaged”: the service still needs request logging, model versioning, access controls and a separate evaluation pipeline.

4. A deterministic validator

After generation, software should extract every number and factual claim from the text and compare them with the contract. Minimum checks include:

  • no number appears unless it was present in the input;
  • factor signs and ranking are unchanged;
  • percentages and measurement units match;
  • required caveats are present;
  • prohibited causal language has not appeared;
  • the calculation version is preserved in the audit log.

If validation fails, the text should not enter an endless self-repair conversation. It should be regenerated with a precise failure reason or routed to a human reviewer.

5. Human approval

In financial, HR, credit and other sensitive workflows, the final narrative should remain a draft until an authorised employee approves it. The interface is better designed as a review card than a generic chatbot: source result, factors, data version, draft, comments and approval action should be visible together.

Measuring quality without holding a writing contest

“It sounds convincing” is a dangerous metric because polished language can hide an error. The evaluation set should measure independent properties.

  • **Numerical faithfulness:** every value and direction matches the source.
  • **Coverage:** mandatory factors and limitations are included.
  • **No unsupported conclusions:** the text contains no causality, advice or facts absent from the input.
  • **Role fit:** the explanation is appropriate for the analyst, client or manager who will read it.
  • **Stability:** the same input does not produce contradictory conclusions.
  • **Editing effort:** minutes and corrections required before approval.

NIST notes that explanations should be tailored to a user's role, knowledge and skill. One universal paragraph for engineers, clients and reviewers saves space only in the mock-up; in production, every audience will request a different version anyway.

Economics: measure removed manual work, not token volume

In the Axyon case, value came from reducing the labour surrounding a predictive model rather than replacing the model itself. A local business case needs four inputs:

  • explanations produced per month;
  • average manual writing and review time;
  • hourly cost of the analyst or domain expert;
  • share of drafts accepted after minimal editing.

Subtract integration, evaluation-set creation, compute, maintenance and mandatory review. A local model is not economical because its “tokens are free.” It becomes attractive when demand is stable, data is sensitive and the server is doing useful work at a reasonable utilisation rate.

A pilot can start with one report type and 100–300 historical examples. First measure human time and semantic error frequency, then compare a fixed template, an untuned LLM and the selected local model. A large GPU cluster is not required at the beginning: the case used HPC for development and model selection, not as a prerequisite for every production explanation.

Limitations that are easy to forget

SHAP and similar methods explain model behaviour, not the mechanics of the real world. A strong feature contribution does not prove that the feature caused the event. A language layer can make this mistake more persuasive, so causal verbs should be restricted through rules and tests.

The second risk is stale context. A faithful explanation of yesterday's forecast may become irrelevant after the data changes. Store model, feature and source-calculation versions with every narrative.

The third risk is simulated auditability. A polished paragraph without the structured input cannot be reproduced. The audit trail should retain the explanation contract, validator results, human edits and final approved version—not merely the prompt.

The next step

Choose one recurring report in which an expert repeatedly translates numbers into plain language: demand forecasting, quality deviation, application scoring, downtime analysis or price explanation. Define the input schema, five prohibited claim types and acceptance criteria. Run a shadow pilot without sending generated text to customers.

If the system reduces editing time, preserves every number and communicates limitations honestly, connect it to the workflow gradually. If it only makes the report longer, the robot intern has brought another stack of paper—but now the team knows which limit to set.