PROSuite

Research · Expert system

An expert system built from a plain-language description

Expert systems used to take months of modelling. In VVL, it is enough to describe the domain, the reference profiles and the decision rule, as you would explain them to a new colleague. The system derives an ontology, profiles and rules from it, then creates a new instruction of the language that decides on each case.

How it is built

Construction happens once, with two language-model calls. The first produces the domain ontology: the main class, its attributes and the reference profiles, represented as abstract objects that encode their characteristic properties. The second translates the decision rule into inference rules: each case receives the label of the profile it matches best, according to a degree of satisfaction.

  1. Plain-language description
  2. Ontology and profiles
  3. Decision rules
  4. New instruction

After that, every case submitted as free text always follows the same path: the language model extracts its fields, the facts are recorded in the ontology, then the rules decide. When the extracted values exactly match the profiles, the decision needs no extra call; otherwise, comparisons of meaning are settled by Jev or by the language model, and cached. The expert can be saved, reloaded in another session, and consulted automatically by the universal resolver.

Business examples

Credit: assessing a customer application

Three risk profiles and a decision rule, described in a few lines. The resulting expert is called Scoring and is used like any other instruction.

[expert "
  Domaine evaluation risque credit. Dossier client avec nom, revenu,
  score_credit (eleve/moyen/faible), anciennete (longue/moyenne/recente),
  decision. Profils BonRisque (score_credit eleve, anciennete longue),
  RisqueModere (score_credit moyen, anciennete moyenne),
  RisqueEleve (score_credit faible, anciennete recente).
  decision : 'approuve' si BonRisque, 'a_etudier' si RisqueModere,
  'refuse' si RisqueEleve, sinon 'a_etudier'.
" "Scoring"]

[Scoring "Alice, revenu 4500, score eleve, anciennete longue"]   # approuve
[Scoring "Bob, revenu 2800, score moyen, anciennete moyenne"]    # a_etudier
[Scoring "Carol, revenu 1800, score faible, anciennete recente"] # refuse

Documented results: approved, to be reviewed, refused.

Customer support: priority and category of a ticket

The same expert can produce several decisions. Here, each ticket receives a priority and a category.

[expert "
  Domaine support SaaS. Ticket avec titre, description, type_probleme
  (panne_majeure/bug/question), impact_utilisateurs (eleve/moyen/faible),
  urgence_business (critique/haute/basse), priorite, categorie.
  Profils Critique (panne_majeure, impact eleve, urgence critique),
  Important (bug, impact moyen), Routine (question), Mineur (impact faible).
  La priorite est : 'P0' si Critique, 'P1' si Important, 'P2' si Routine,
  'P3' si Mineur, sinon 'P2'.
  La categorie est : 'incident' si Critique ou Important, 'demande'
  si Routine, 'low_prio' si Mineur, sinon 'demande'.
" "TicketTriager"]

[TicketTriager "Production en panne complete, panne_majeure, impact eleve, urgence critique"]
# Ticket[priorite="P0", categorie="incident"]

Accounting: classifying cash flows

A chartered accountant describes how to place each bank transaction in the cash-flow statement: operating, investing, financing. The expert then classifies real transactions, including a compound transaction that produces two lines.

$_desc = "Classification d un flux de tresorerie d entreprise ...
Attribut de sortie:
- cycle (exploitation/investissement/capitaux_propres/endettement/placement_financier): ...
Regles:
Vente comptant ou encaissement client = cycle exploitation, ligne recette_exploitation, agregat ETE.
Acquisition machine, immobilisation, brevet = cycle investissement, ligne investissement, agregat FTD.
..."
[expert $_desc "FluxTreso"]
[FluxTreso "Acquisition presse hydraulique 145 000 EUR"]   # investissement / investissement / FTD

Documented case study: twelve real transactions classified; one ambiguous case, corporate tax, is flagged for review.

Reusing the expert: saving and the resolver

The expert is saved in the workspace and reloaded in another session. Once registered, the universal resolver hands it the questions that fall within its domain.

[workspace go demo]
[expert:save "Scoring"]
# dans une nouvelle session :
[workspace go demo]
[expert:load "Scoring"]
[Scoring "Eve, revenu 5000, score_credit eleve, anciennete longue"]
$r = [§§? "Évalue le dossier de Alice Dubois, revenu 4500, score élevé, ancienneté longue"]
$r.value           # {..., 'decision': 'approuve'}

What it guarantees, and its limits

  • The decision is made by written, readable rules, which can be reviewed, changed and saved.
  • Each case is first transcribed into an ontology: the extracted fields are visible and can be checked.
  • Each case costs one language-model call for extraction; building the expert costs two.
  • An expert covers one main class, and every expected decision must be named in the description.

Apply this work to your processes?

The diagnosis starts from how you actually work and identifies the decisions that can be entrusted to AI.

Get my assessment