Le Context Engine est-il réellement un moteur de scoring ?
Réflexion d’architecture — Le Context Engine est-il réellement un moteur de scoring ?
Au fil de nos échanges, nous avons progressivement fait évoluer notre vision du Context Engine.
Au départ, nous cherchions à définir un moteur de pertinence.
Puis un moteur de classement.
Puis un moteur de composition.
Aujourd’hui, nous avons le sentiment que nous cherchions peut-être le mauvais objet depuis le début.
Nous aimerions avoir ton avis sur cette réflexion.
⸻
Notre constat
Depuis plusieurs documents, une même question revient systématiquement.
Comment calculer l’utilité contextuelle ?
Cette question est revenue plusieurs fois sous différentes formes :
- comment calculer la pertinence ?
- comment produire un classement ?
- comment allouer les catégories ?
- comment composer le mur ?
À chaque fois, nous cherchions implicitement une formule.
Mais nous commençons à penser que cette formule n’existe tout simplement pas.
⸻
Une observation
Prenons un exemple.
Imaginons un maire ou un agent communal qui doit sélectionner les informations importantes du jour.
Que fait-il réellement ?
Il ne calcule pas un score.
Il raisonne.
Il élimine.
Il compare.
Il arbitre.
Il applique des règles.
Il prend progressivement une décision.
Autrement dit, son raisonnement ressemble davantage à un système expert qu’à un moteur de scoring.
⸻
Ce que nous imaginons désormais
Nous ne pensons plus que le cœur du Context Engine soit un calcul.
Nous pensons que le cœur du moteur est un processus de décision.
Par exemple : Contexte
↓
Filtrage
↓
Validation
↓
Classification
↓
Application des règles métier
↓
Arbitrages
↓
Composition
↓
Cards Dans cette approche, il n’existe pas de formule unique de pertinence.
Il existe une succession de décisions.
⸻
Quelques exemples
Exemple 1
SI
- l’information est expirée
ALORS
- elle est éliminée.
⸻
Exemple 2
SI
- une alerte est active
ALORS
- elle est conservée.
⸻
Exemple 3
SI
- cinq publications proviennent du même acteur
ALORS
- limiter leur représentation dans le mur.
⸻
Exemple 4
SI
- deux événements similaires sont présents
ALORS
- conserver celui ayant la portée la plus importante.
⸻
Aucun de ces exemples ne nécessite un score.
Ils reposent sur des règles explicites.
⸻
Une analogie
Nous faisons un parallèle avec un expert humain.
Un expert ne raisonne généralement pas sous la forme : score = 0,35 × contexte + 0,25 × relation + 0,15 × fraîcheur ... Il raisonne plutôt comme ceci :
- cette information est-elle encore valide ?
- est-elle importante ?
- concerne-t-elle cet utilisateur ?
- est-elle redondante ?
- apporte-t-elle réellement quelque chose au mur ?
Son raisonnement est une succession de décisions.
Pas une fonction mathématique unique.
⸻
Une conséquence
Nous nous demandons donc si le terme même de “calcul de l’utilité contextuelle” est finalement trompeur.
Peut-être que le moteur ne calcule jamais une utilité.
Peut-être qu’il prend simplement une suite de décisions déterministes.
L’utilité émergerait alors naturellement de ces décisions.
⸻
Une autre conséquence
Nous avions initialement imaginé un “Context Engine”.
Nous nous demandons aujourd’hui si ce Context Engine n’est finalement qu’un orchestrateur.
Le véritable moteur serait alors un Decision Engine, composé :
- de règles métier ;
- d’heuristiques ;
- d’arbitrages ;
- de contraintes ;
- d’exceptions.
Le Context Engine fournirait simplement le contexte de départ.
⸻
Notre question
Partages-tu cette vision ?
Penses-tu qu’un moteur destiné à représenter intelligemment un territoire doive être conçu comme :
- un moteur de scoring produisant une note de pertinence,
ou plutôt comme :
- un système expert déterministe appliquant successivement des règles, des contraintes et des arbitrages jusqu’à produire un mur cohérent ?
Autrement dit :
Le problème fondamental est-il vraiment de calculer un score, ou est-il de modéliser un raisonnement ?
Nous avons le sentiment que cette distinction change profondément l’architecture du moteur et nous aimerions connaître ton analyse critique avant de poursuivre sa conception.