d'items (offres d'emploi), visant à trouver un compromis entre l'intérêt des articles recommandés et une diversité suffisante des recommandations au niveau de la population (par opposition à la sérendipité en recommandation [15], qui vise la diversité des items recommandés au niveau individuel). Les questions scientifiques abordées dans l'article concernent donc : i) la définition d'un indicateur mesurant la qualité de recommandations en termes de congestion; ii) la mise au point d'un algorithme visant à limiter cette congestion; iii) l'évaluation du compromis entre l'indicateur de performance de recommandation usuel qu'est le recall et la congestion.

La contribution de l'article est triple. Tout d'abord, l'évitement de la congestion est formalisé dans le cadre du transport optimal (section 3). Deuxièmement, l'algorithme RECTO proposé pour résoudre ce problème est agnosique quant à la distribution des données (par opposition aux conditions requises dans [16, 17, 10, 7]) et moins exigeant computationnellement que les approches d'optimisation combinatoire, par exemple [26]. Troisièmement, les mérites de RECTO sont démontrés expérimentalement sur i) un benchmark public dans le domaine du marché matrimonial, utilisé pour l'évaluation comparative avec [16]; ii) un vaste jeu de données propriétaire relatif au marché du travail<fnref n="1" />, et fournissent des leçons inattendues sur les interactions des indicateurs de recall et de congestion.

## 2 Notations et État de l'art

Cette section présente le problème de recommandation réciproque, renvoyant le lecteur à [18] pour un état de l'art plus complet, et discute quelques travaux connexes. Le cadre du transport optimal [9, 21] est ensuite brièvement introduit.

**Notations.** Soit $n$ (respectivement $m$) le nombre d'utilisateurs (resp. d'items), avec $x_i$ (resp. $y_j$) la description du $i$-ème utilisateur (resp. du $j$-ème item). La matrice collaborative booléenne $M_{i,j}$ est telle que $M_{i,j} = 1$ si et seulement si l'utilisateur $i$ a sélectionné l'item $j$.

**Position du problème.** Un système de recommandation prend généralement une fonction de score $\phi$ telle que la matrice définie à partir de $\phi_{i,j} = \phi(x_i, y_j)$ soit proche de la matrice collaborative $M$ (en termes d'erreur quadratique moyenne ou de divergence de Kullback-Leibler), éventuellement pénalisée par un terme de régularisation [1]. Sans perte de généralité, on suppose par la suite que les items recommandés au $i$-ème utilisateur sont ordonnés par ordre croissant de $\phi_{i,j}$.

Dans les problèmes de recommandation réciproque [18], l'item $j$ est soumis à une contrainte de capacité $n_j$ : seuls les $n_j$ meilleurs utilisateurs sélectionnant cet item peuvent être servis. De nouveaux objectifs d'optimisation et des algorithmes spécifiques doivent être définis pour tenir compte de ces contraintes.

**Travaux connexes.** Une première approche de recommandation réciproque, [12], apprend une fonction de score $\phi$ comme solution d'un problème d'optimisation contraint.

[26] considère la recommandation réciproque comme un problème d'optimisation multi-objectif (NP-difficile), introduisant la satisfaction des contraintes de capacité comme un objectif supplémentaire ; l'optimisation est réalisée en utilisant une approche gloutonne. Dans [2], un modèle auxiliaire prédit la popularité attendue d'un item ; la recommandation est réparée au niveau individuel, en décalant vers le haut ou vers le bas les items recommandés à un utilisateur donné en fonction de leur popularité globale prévue. Dans le contexte de sites de rencontre, [6], s'inspirant de modèles économiques décentralisés, construisent une fonction d'utilité reflétant l'intérêt de $x_i$ pour $y_j$ et réciproquement; ils utilisent une approche de transport optimal (voir ci-dessous) pour calculer les recommandations finale à partir du score d'utilité.

**Transport optimal computationnel.** Le transport optimal (OT) vise à faire correspondre une certaine distribution (continue ou discrète) $\mu$ à une autre distribution $\nu$. Dans la suite de l'article, $\mu$ (respectivement $\nu$) désigne la distribution discrète uniforme sur l'ensemble des $n$ utilisateurs (resp. sur l'ensemble des $m$ items). En notant $\Gamma(\mu, \nu)$ l'ensemble des mesures telles que leurs marginales par rapport au premier et deuxième argument sont respectivement $\mu$ et $\nu$, et en définissant $C_{i,j}$ comme le coût de la correspondance de $i$ à $j$, le problème du transport optimal est de trouver une distribution jointe $\gamma^* \in \Gamma(\mu, \nu)$ telle que :

$$ \gamma^*(C) \in \arg \min_{\gamma \in \Gamma(\mu, \nu)} \sum_{i=1}^{n} \sum_{j=1}^{m} \gamma_{i,j} C_{i,j} \quad (1) $$

Une relaxation de ce problème d'optimisation, proposée par [9], y ajoute un terme entropique :

$$ \gamma^*(C, \varepsilon) \in \arg \min_{\gamma \in \Gamma(\mu, \nu)} \sum_{i=1}^{n} \sum_{j=1}^{m} \gamma_{i,j} (C_{i,j} + \varepsilon \log(\gamma_{i,j})) \quad (2) $$

avec $\varepsilon$ le poids donné à la régularisation. La solution optimale de l'équation (2) prend la forme $\gamma_{i,j} = \alpha_i \exp(-C_{i,j}/\varepsilon) \beta_j$, où $\alpha$ et $\beta$ reflètent les contraintes sur les marginales de $\gamma$.

**Discussion** Les principales approches de recommandation basées sur l'OT supposent que la matrice collaborative observée $M$ est générée comme optimum d'un plan d'OT basé sur un coût d'appariement $C$ à estimer [7, 11, 16, 17] : elles apprennent $C$ à partir des données d'entraînement et utilisent le modèle de coût estimé pour construire des appariements sur de nouvelles données.

Dans le contexte du marché du travail, il est cependant discutable de considérer que les appariements réels (i.e. la matrice collaborative observée $M$) doivent être vus comme la solution d'un plan de transport optimal : par construction, $M$ est le résultat d'un processus décentralisé tandis que la solution d'OT résulte d'un processus centralisé (les deux ne coincident que sous de fortes hypothèses). En conséquence, l'approche proposée est structurée en deux phases : l'apprentissage de la fonction de coût d'appariement $C$ à partir de $M$ (sans supposer que $M$ soit une solution d'un problème d'OT), et l'utilisation de $C$ dans un problème d'OT.

<footnote n="1">1. Fourni par Pôle emploi.</footnote>
## 3 Présentation de RECTO

Soit $\phi_{i,j} \in \mathbb{R}$ le score de recommandation de l'item $j$ pour l'utilisateur $i$, et définissons l'indicateur booléen $1_{i \to j,k,\phi}$ comme valant 1 si $j$ figure parmi les $k$ meilleures recommandations pour $i$ d'après $\phi$. L'indice $\phi$ sera omis par la suite lorsque le contexte ne présente pas d'ambiguïté.

**Critères de performance.** En plus de l'indicateur standard qu'est le Recall@k, qui mesure la fraction d'utilisateurs pour lesquels l'item préféré est classé parmi les $k$ meilleures recommandations,

$$ \text{Recall@k}(\phi) = \frac{1}{n} \sum_{i=1}^{n} \sum_{j=1}^{m} M_{i,j} \cdot 1_{i \to j,k} \quad (3) $$

nous définissons la notion de part de marché de l'item $MS_{\ell}(j)$, correspondant à la fraction d'utilisateurs $i$ pour lesquels $j$ figure parmi les $\ell$ meilleurs articles recommandés à $i$ (avec $\ell < m$):

$$ MS_{\ell}(j) = \frac{1}{n \times \ell} \sum_{i=1}^{n} 1_{i \to j, \ell} $$

Nous définissons la congestion comme moins l'entropie des parts de marché : plus les recommandations sont réparties uniformément sur tous items, plus leurs parts de marché sont similaires, moins la congestion est importante.

$$ \text{Congestion@}\ell(\phi) := \sum_{j=1}^{m} MS_{\ell}(j) \log (MS_{\ell}(j)) \quad (4) $$

Cet indicateur de congestion est normalisé sur $[-1, 0]$ en le divisant par $\log(m)$; l'évitement parfait de la congestion est obtenu pour des parts de marché égales des items, avec $-1$ comme valeur correspondante de l'indicateur.

**Utilisation du Transport Optimal.** Comme indiqué précédemment, le transport optimal s'applique sur une matrice de coûts $C_{i,j}$ dépendant du score de recommandation appris $\phi_{i,j}$. L'apprentissage de bout en bout de $C_{i,j}$ sera considéré dans des travaux ultérieurs. Nous considérons ici $C_{i,j} = g(\phi_{i,j})$, où $g$ est une fonction scalaire monotone, considérée comme un hyperparamètre de l'approche, telle que le coût $C_{i,j}$ de transporter $i$ vers $j$ augmente avec $\phi_{i,j}$ (c'est-à-dire que la pertinence de la recommandation de $j$ à $j$ diminue). $\phi_{i,j}$ est plafonné au score du millième élément recommandé à chaque $i$ par $\phi$, noté $\phi_i^{(1000)}$ ($\phi_{i,j} \leftarrow \max(\phi_{i,j}, \phi_i^{(1000)})$ dans la suite).

Quatre fonctions $g$ ont été considérées, respectivement linéaires, exponentielles de $\phi_{i,j}$, basées sur le rang, ou de type NDCG [3].

Pour une comparaison équitable des résultats obtenus avec le même poids de régularisation entropique $\varepsilon$, les $C_{i,j}$ sont normalisés de sorte que $\sum_{i,j} C_{i,j} = 1$.

**L'algorithme RECTO.** RECTO est un processus en 2 étapes : i) apprentissage d'une fonction de score $\phi$; ii) résolution du problème de transport optimal défini à partir de $C_{ij} = g(\phi_{i,j})$.

**RECTO : 1. Apprentissage de $\phi$.** Les deux approches d'apprentissage de $\phi$ considérées sont XGBOOST et des réseaux de neurones (NN). XGBOOST est un système de recommandation basé sur des arbres boostés utilisé par de nombreux algorithmes de l'état de l'art [24], qui peut être efficacement entraîné en sous-échantillonnant agressivement les paires négatives $(i, j)$, au détriment d'un passage à l'échelle plus limité dû à l'utilisation de variables croisées telles que la distance. NN utilise un réseau de neurones profond, dont l'architecture est adaptée aux spécifications du domaine (par exemple, en considérant des sous-modules dédiés aux informations géographiques ou aux compétences). Les descriptions de l'utilisateur $x_i$ et de l'item $y_j$ sont respectivement projetés dans des espaces latents, notés $z_{x,i}$ et $z_{y,j}$, et leur adéquation $\phi_{i,j}$ est paramétrée comme $z_{x,i}^T A z_{y,j}$ avec $A$ une matrice [4]. Les projections et la matrice $A$ sont apprises de manière end-to-end en utilisant une perte "triplet" [25]. Formellement, en supposant que chaque utilisateur de l'entraînement $i$ est associé à un seul item $j$, on peut réordonner les colonnes de la matrice de telle sorte que l'utilisateur $i$ soit associé à l'item $i$, et l'objectif d'apprentissage est alors :

$$ \text{Minimiser} \quad \sum_{i=1}^{n} \sum_{j=1, j \neq i}^{m} (\phi_{i,i} - \phi_{i,j} + \eta) + \quad (5) $$

avec $A+ = \max(0, A)$ et $\eta > 0$. En pratique, un échantillonnage négatif est utilisé pour faire face au nombre de paires négatives. Les hyperparamètres de XGBOOST et NN sont détaillés en annexe B.

**RECTO : 2. Transport optimal.** En fonction du poids de régularisation $\varepsilon$ et de la fonction $g$ (avec $C_{ij} = g(\phi_{i,j})$), la distribution discrète $\gamma$ est entraînée en optimisant l'équation (2). Remarquons que l'extension de l'approche au cas général de recommandation réciproque (e.g. où plusieurs postes peuvent être ouverts pour l'offre d'emploi $j$) est immédiate en rendant $\nu_j$ proportionnelle à la contrainte de capacité de l'item $j$.

Enfin, pour déterminer la recommandation finale, RECTO procède de manière déterministe, en classant les $j$ articles recommandés à l'utilisateur $i$ par ordre décroissant par rapport à $\gamma_{i,j}$.

## 4 Validation expérimentale

Cette section présente la validation expérimentale de l'approche, réalisée sur deux jeux de données : des données publiques sur le marché matrimonial (notées MAR), utilisées par [16], pour une comparaison avec l'état de l'art; et un ensemble de données propriétaires (notées JOB) fournies par Pôle emploi.

Le premier objectif des expériences est d'évaluer l'efficacité de l'approche proposée en termes de compromis entre le recall et la congestion. Le second objectif est d'étudier comment les résultats dépendent des hyperparamètres de l'approche - $\phi$ appris avec XGBOOST ou NN; poids de régularisation entropique $\varepsilon$ variant entre $10^{-2}, \dots, 10^2$; coût de transport $C_{ij}$ défini comme $g(\phi_{ij})$ avec $g$ variant entre $\{\text{Id, Exp, Ndcg, Rank}\}$.
## 3 Présentation de RECTO

Soit $\phi_{i,j} \in \mathbb{R}$ le score de recommandation de l'item $j$ pour l'utilisateur $i$, et définissons l'indicateur booléen $1_{i \to j, k, \phi}$ comme valant 1 si $j$ figure parmi les $k$ meilleures recommandations pour $i$ d'après $\phi$. L'indice $\phi$ sera omis par la suite lorsque le contexte ne présente pas d'ambiguïté.

**Critères de performance.** En plus de l'indicateur standard qu'est le Recall@k, qui mesure la fraction d'utilisateurs pour lesquels l'item préféré est classé parmi les $k$ meilleures recommandations,

$$ \text{Recall@k}(\phi) = \frac{1}{n} \sum_{i=1}^{n} \sum_{j=1}^{m} M_{i,j} \mathbb{1}_{i \to j, k} \quad (3) $$

nous définissons la notion de part de marché de l'item $MS_{\ell}(j)$, correspondant à la fraction d'utilisateurs $i$ pour lesquels $j$ figure parmi les $\ell$ meilleurs articles recommandés à $i$ (avec $\ell < m$):

$$ MS_{\ell}(j) = \frac{1}{n \times \ell} \sum_{i=1}^{n} 1_{i \to j, \ell} $$

Nous définissons la congestion comme moins l'entropie des parts de marché : plus les recommandations sont réparties uniformément sur tous items, plus leurs parts de marché sont similaires, moins la congestion est importante.

$$ \text{Congestion@}\ell(\phi) := \sum_{j=1}^{m} MS_{\ell}(j) \log (MS_{\ell}(j)) \quad (4) $$

Cet indicateur de congestion est normalisé sur $[-1, 0]$ en le divisant par $\log(m)$; l'évitement parfait de la congestion est obtenu pour des parts de marché égales des items, avec $-1$ comme valeur correspondante de l'indicateur.

**Utilisation du Transport Optimal.** Comme indiqué précédemment, le transport optimal s'applique sur une matrice de coûts $C_{i,j}$ dépendant du score de recommandation appris $\phi_{i,j}$. L'apprentissage de bout en bout de $C_{i,j}$ sera considéré dans des travaux ultérieurs. Nous considérons ici $C_{i,j} = g(\phi_{i,j})$, où $g$ est une fonction scalaire monotone, considérée comme un hyperparamètre de l'approche, telle que le coût $C_{i,j}$ de transporter $i$ vers $j$ augmente avec $\phi_{i,j}$ (c'est-à-dire que la pertinence de la recommandation de $j$ à $j$ diminue). $\phi_{i,j}$ est plafonné au score du millième élément recommandé à chaque $i$ par $\phi$, noté $\phi_i^{(1000)}$ ($\phi_{i,j} \leftarrow \max(\phi_{i,j}, \phi_i^{(1000)})$ dans la suite).

Quatre fonctions $g$ ont été considérées, respectivement linéaires, exponentielles de $\phi_{i,j}$, basées sur le rang, ou de type NDCG [3].

Pour une comparaison équitable des résultats obtenus avec le même poids de régularisation entropique $\varepsilon$, les $C_{i,j}$ sont normalisés de sorte que $\sum_{i,j} C_{i,j} = 1$.

**L'algorithme** RECTO. RECTO est un processus en 2 étapes : i) apprentissage d'une fonction de score $\phi$; ii) résolution du problème de transport optimal défini à partir de $C_{ij} = g(\phi_{i,j})$.

**RECTO : 1.** **Apprentissage de $\phi$.** Les deux approches d'apprentissage de $\phi$ considérées sont XGBOOST et des réseaux de neurones (NN). XGBOOST est un système de recommandation basé sur des arbres boostés utilisé par de nombreux algorithmes de l'état de l'art [24], qui peut être efficacement entraîné en sous-échantillonnant agressivement les paires négatives $(i, j)$, au détriment d'un passage à l'échelle plus limité dû à l'utilisation de variables croisées telles que la distance. NN utilise un réseau de neurones profond, dont l'architecture est adaptée aux spécifications du domaine (par exemple, en considérant des sous-modules dédiés aux informations géographiques ou aux compétences). Les descriptions de l'utilisateur $x_i$ et de l'item $y_j$ sont respectivement projetés dans des espaces latents, notés $z_{x,i}$ et $z_{y,j}$, et leur adéquation $\phi_{i,j}$ est paramétrée comme $z_{x,i}^T A z_{y,j}$ avec $A$ une matrice [4]. Les projections et la matrice $A$ sont apprises de manière end-to-end en utilisant une perte "triplet" [25]. Formellement, en supposant que chaque utilisateur de l'entraînement $i$ est associé à un seul item $j$, on peut réordonner les colonnes de la matrice de telle sorte que l'utilisateur $i$ soit associé à l'item $i$, et l'objectif d'apprentissage est alors :

$$ \text{Minimiser} \quad \sum_{i=1}^{n} \sum_{j=1, j \neq i}^{m} (\phi_{i,i} - \phi_{i,j} + \eta) + \quad (5) $$

avec $A^+ = \max(0, A)$ et $\eta > 0$. En pratique, un échantillonnage négatif est utilisé pour faire face au nombre de paires négatives. Les hyperparamètres de XGBOOST et NN sont détaillés en annexe B.

**RECTO : 2. Transport optimal.** En fonction du poids de régularisation $\varepsilon$ et de la fonction $g$ (avec $C_{ij} = g(\phi_{i,j})$), la distribution discrète $\gamma$ est entraînée en optimisant l'équation (2). Remarquons que l'extension de l'approche au cas général de recommandation réciproque (e.g. où plusieurs postes peuvent être ouverts pour l'offre d'emploi $j$) est immédiate en rendant $\nu_j$ proportionnelle à la contrainte de capacité de l'item $j$.

Enfin, pour déterminer la recommandation finale, RECTO procède de manière déterministe, en classant les $j$ articles recommandés à l'utilisateur $i$ par ordre décroissant par rapport à $\gamma_{i,j}$.

## 4 Validation expérimentale

Cette section présente la validation expérimentale de l'approche, réalisée sur deux jeux de données : des données publiques sur le marché matrimonial (notées MAR), utilisées par [16], pour une comparaison avec l'état de l'art; et un ensemble de données propriétaires (notées JOB) fournies par Pôle emploi.

Le premier objectif des expériences est d'évaluer l'efficacité de l'approche proposée en termes de compromis entre le recall et la congestion. Le second objectif est d'étudier comment les résultats dépendent des hyperparamètres de l'approche - $\phi$ appris avec XGBOOST ou NN; poids de régularisation entropique $\varepsilon$ variant entre $10^{-2}, \dots, 10^2$; coût de transport $C_{ij}$ défini comme $g(\phi_{ij})$ avec $g$ variant entre $\{\text{Id, Exp, Ndcg, Rank}\}$.
Sept indicateurs de performance sont associés à chaque hyperparamètre : recall@k avec $k = 1, 10, 100$, congestion@k avec $k = 1, 10$, et coverage@k avec $k = 1, 10$, indiquant la fraction d'éléments impliqués dans la recommandation top-k d'au moins un utilisateur. D'autres indicateurs de performance sont présentés et discutés dans l'an-nexe C.

## 4.1 Données MAR

**Description des données** Les données comprennent 2 475 hommes et 2 475 femmes, répartis en 50 groupes. Chaque individu est décrit par 11 caractéristiques principalement orinales. L'appariement 1 à 1 est décrit au niveau individuel et les données comprennent également la matrice collaborative $M_{c,c'}$, qui indique la fraction d'appariements entre les hommes du groupe $c$ et les femmes du groupe $c'$.

**Benchmarks.** Les résultats de référence sur MAR sont ceux de RIOT [16], utilisant une factorisation basée sur SVD et itemKNN [8]. Les indicateurs de performance comprennent le RMSE et le MAE entre la matrice collaborative $M$ au niveau des groupes et la matrice de recommandation estimée, mesurée à l'aide d'une validation croisée à 5 plis. RECTO est également évalué au niveau individuel, à l'aide des indicateurs de performance définis en section 4.

**Resultats.** Les tableaux 1 et 2 affichent respectivement les résultats obtenus sur MAR au niveau du groupe 2 et au niveau individuel.

Au niveau des groupes, $\gamma^{XGB}$ obtient de légèrement meilleurs résultats (de manière statistiquement significative) par rapport à RIOT en termes de RMSE ($8,89 \pm 0,11$ contre $8,98 \pm 0,17$) et de MAE ($5,80 \pm 0,13$ contre $5,79 \pm 0,12$). $\gamma^{NN}$ est également légèrement meilleur que RIOT. Les autres algorithmes de référence (aléatoire, PMF, SVD et itemKNN) sont aussi dominés.

Au niveau individuel, XGBOOST est significativement plus performant que NN en termes de recall et de congestion pour toutes les valeurs de $k$ considérées.

$\gamma^{XGB}$ améliore la congestion au détriment du recall : l'amélioration de la congestion (de -.84 à -.98) est obtenue en diminuant le recall@10 (de 28.4% à 23.7% pour la combinaison d'hyperparamètres $g = Id, \varepsilon = 10^{-2}$).

Pour $\gamma^{NN}$, la congestion peut être considérablement amélioré (de -.84 à -.98, pour $g = Id, \varepsilon = 10^{-2}$) tout en pré-servant le recall@10 (environ 15.4%).

Les indicateurs de recall et de congestion ne sont toutefois pas nécessairement antagonistes dans le problème de MAR : par construction, la matrice collaborative recherchée est une permutation. La principale difficulté de ce problème de recommandation semble donc provenir de la petite taille du jeu de données et de la description peu détaillée des individus.

## 4.2 Données JOB

**Description des données** L'ensemble d'entraînement comprend environ 1 650 000 demandeurs d'emploi, 477 000 offres d'emploi et 43 000 appariements (contrats signés) en Ile de France au cours de la période février-octobre 2018. La description $x_i$ (respectivement $y_j$) d'un demandeur d'emploi (resp. d'une offre d'emploi) se trouve dans $\mathbb{R}^{448}$ (resp. $\mathbb{R}^{582}$). La fonction $\phi$ est apprise sur l'ensemble d'apprentissage; le plan de transport optimal $\gamma$ est calculé sur l'ensemble de test restreint au secteur d'emploi de la logistique pour des raisons de passage à l'échelle : il comprend 110 000 demandeurs d'emploi, 14 200 annonces d'emploi et 450 embauches en nov. 2018.

**Résultats.** Le tableau 3 résume les résultats, avec trois entseignements principaux. Premièrement, NN est dominé par XGBOOST sur les trois indicateurs de performance : recall, coverage et congestion; en outre, le moindre recall de NN (4 % de perte de recall@100) s'accompagne d'un coverage beaucoup plus faible (7 % de perte de coverage@1). Cette contre-performance est imputée à l'architecture du réseau neuronal (des expériences en cours suggèrent que l'ajout d'un second réseau n'utilisant que le Top 1000 de NN en entrée permet à NN de rattraper son retard). Deuxièmement, la coverage (@1 et @10) augmente de façon monotone et le recall (@1, @10, @100) diminue de façon monotone lorsque $\varepsilon$ passe de 1 à 0,01, ce qui laisse peu d'espoir de pouvoir combiner un bon coverage avec un recall décent. Il est plus encourageant de constater que la congestion@1 peut être améliorée de manière significative (de -0,62 à -0,78) au prix d'une perte de recall modérée (le recall@10 passe de 62% à 56%) pour $g = Id, \varepsilon = 0,1$.

L'option $g = ndcg$ a peu d'effets (légèrement positifs) pour $\varepsilon = 1$ et des effets fortement négatifs pour $\varepsilon = .1$ ou .01.

Il est surprenant de constater qu'en diminuant $\varepsilon$, on obtient une meilleure congestion (plus faible) au prix d'un moins bon recall. Cet effet est inattendu car plus $\varepsilon$ est élevé, plus le plan de transport $\gamma$ est uniforme (toutes choses étant égales par ailleurs) et plus la congestion semblerait devoir être faible. Une interprétation possible (étayée par des expériences complémentaires présentées dans l'annexe A) est que tous les indicateurs de performance dépendent de l'ordre induit par $\gamma$, par opposition aux valeurs réelles de $\gamma_{i,j}$. Bien que la variance de $\gamma_{i,j}$ diminue à mesure que $\varepsilon$ augmente, le phénomène du "winner takes all" persiste, c'est-à-dire que les premières recommandations de tous les utilisateurs ne couvrent qu'un maigre 13% à 20% des offres.

Les temps de calcul (tableau 4) pour XGBOOST (environ 2 heures) et NN (environ 30 mn) restent relativement limités. Le temps associé au calcul du transport optimal augmente à mesure que $\varepsilon$ diminue, jusqu'à environ 10 mn pour $\varepsilon = .01$ (voir aussi [22]). La majorité du temps de calcul est consacrée au calcul des recommandations avec XGBOOST et $\gamma^{XGB}$, du fait de la nécessité de calculer les $\phi_{ij}$ pour toutes les paires $i-j$.

<footnote n="2">2. La différence avec [16] s'explique par le fait qu'un bug a été trouvé (et corrigé) dans le code public pour RIOT et les autres algorithmes utilisés par [16], au niveau de la division de l'erreur par le nombre de plis dans chaque itération. Le classement final des algorithmes n'est pas affecté par la correction du bug.</footnote>
Sept indicateurs de performance sont associés à chaque hyperparamètre : recall@k avec $k = 1, 10, 100$, congestion@k avec $k = 1, 10$, et coverage@k avec $k = 1, 10$, indiquant la fraction d'éléments impliqués dans la recommandation top-k d'au moins un utilisateur. D'autres indicateurs de performance sont présentés et discutés dans l'an-nexe C.

## 4.1 Données MAR

**Description des données** Les données comprennent 2 475 hommes et 2 475 femmes, répartis en 50 groupes. Chaque individu est décrit par 11 caractéristiques principalement orinales. L'appariement 1 à 1 est décrit au niveau individuel et les données comprennent également la matrice collaborative $M_{c,c'}$, qui indique la fraction d'appariements entre les hommes du groupe c et les femmes du groupe $c'$.

**Benchmarks.** Les résultats de référence sur MAR sont ceux de RIOT [16], utilisant une factorisation basée sur SVD et itemKNN [8]. Les indicateurs de performance comprennent le RMSE et le MAE entre la matrice collaborative $M$ au niveau des groupes et la matrice de recommandation estimée, mesurée à l'aide d'une validation croisée à 5 plis. RECTO est également évalué au niveau individuel, à l'aide des indicateurs de performance définis en section 4.

**Resultats.** Les tableaux 1 et 2 affichent respectivement les résultats obtenus sur MAR au niveau du groupe 2 et au niveau individuel.

Au niveau des groupes, $\gamma^{XGB}$ obtient de légèrement meilleurs résultats (de manière statistiquement significative) par rapport à RIOT en termes de RMSE (8,89±0,11 contre 8,98±0,17) et de MAE (5,80±0,13 contre 5,79±0,12). $\gamma^{NN}$ est également légèrement meilleur que RIOT. Les autres algorithmes de référence (aléatoire, PMF, SVD et itemKNN) sont aussi dominés.

Au niveau individuel, XGBOOST est significativement plus performant que NN en termes de recall et de congestion pour toutes les valeurs de $k$ considérées.

$\gamma^{XGB}$ améliore la congestion au détriment du recall : l'amélioration de la congestion (de -.84 à -.98) est obtenue en diminuant le recall@10 (de 28.4% à 23.7% pour la combinaison d'hyperparamètres $g = Id, \varepsilon = 10^{-2}$).

Pour $\gamma^{NN}$, la congestion peut être considérablement amélioré (de -.84 à -.98, pour $g = Id, \varepsilon = 10^{-2}$) tout en pré-servant le recall@10 (environ 15.4%).

Les indicateurs de recall et de congestion ne sont toutefois pas nécessairement antagonistes dans le problème de MAR : par construction, la matrice collaborative recherchée est une permutation. La principale difficulté de ce problème de recommandation semble donc provenir de la petite taille du jeu de données et de la description peu détaillée des individus.

## 4.2 Données JOB

**Description des données** L'ensemble d'entraînement comprend environ 1 650 000 demandeurs d'emploi, 477 000 offres d'emploi et 43 000 appariements (contrats signés) en Ile de France au cours de la période février-octobre 2018. La description $x_i$ (respectivement $y_j$) d'un demandeur d'emploi (resp. d'une offre d'emploi) se trouve dans $\mathbb{R}^{448}$ (resp. $\mathbb{R}^{582}$). La fonction $\phi$ est apprise sur l'ensemble d'apprentissage; le plan de transport optimal $\gamma$ est calculé sur l'ensemble de test restreint au secteur d'emploi de la logistique pour des raisons de passage à l'échelle : il comprend 110 000 demandeurs d'emploi, 14 200 annonces d'emploi et 450 embauches en nov. 2018.

**Résultats.** Le tableau 3 résume les résultats, avec trois enseignements principaux. Premièrement, NN est dominé par XGBOOST sur les trois indicateurs de performance : recall, coverage et congestion; en outre, le moindre recall de NN (4 % de perte de recall@100) s'accompagne d'un coverage beaucoup plus faible (7 % de perte de coverage@1). Cette contre-performance est imputée à l'architecture du réseau neuronal (des expériences en cours suggèrent que l'ajout d'un second réseau n'utilisant que le Top 1000 de NN en entrée permet à NN de rattraper son retard). Deuxièmement, la coverage (@1 et @10) augmente de façon monotone et le recall (@1, @10, @100) diminue de façon monotone lorsque $\varepsilon$ passe de 1 à 0,01, ce qui laisse peu d'espoir de pouvoir combiner un bon coverage avec un recall décent. Il est plus encourageant de constater que la congestion@1 peut être améliorée de manière significative (de -0,62 à -0,78) au prix d'une perte de recall modérée (le recall@10 passe de 62% à 56%) pour $g = Id, \varepsilon = 0,1$.

L'option $g = ndcg$ a peu d'effets (légèrement positifs) pour $\varepsilon = .1$ et des effets fortement négatifs pour $\varepsilon = .1$ ou .01.

Il est surprenant de constater qu'en diminuant $\varepsilon$, on obtient une meilleure congestion (plus faible) au prix d'un moins bon recall. Cet effet est inattendu car plus $\varepsilon$ est élevé, plus le plan de transport $\gamma$ est uniforme (toutes choses étant égales par ailleurs) et plus la congestion semblerait devoir être faible. Une interprétation possible (étayée par des expériences complémentaires présentées dans l'annexe A) est que tous les indicateurs de performance dépendent de l'ordre induit par $\gamma$, par opposition aux valeurs réelles de $\gamma_{i,j}$. Bien que la variance de $\gamma_{i,j}$ diminue à mesure que $\varepsilon$ augmente, le phénomène du "winner takes all" persiste, c'est-à-dire que les premières recommandations de tous les utilisateurs ne couvrent qu'un maigre 13% à 20% des offres.

Les temps de calcul (tableau 4) pour XGBOOST (environ 2 heures) et NN (environ 30 mn) restent relativement limités. Le temps associé au calcul du transport optimal augmente à mesure que $\varepsilon$ diminue, jusqu'à environ 10 mn pour $\varepsilon = .01$ (voir aussi [22]). La majorité du temps de calcul est consacrée au calcul des recommandations avec XGBOOST et $\gamma^{XGB}$, du fait de la nécessité de calculer les $\phi_{ij}$ pour toutes les paires $i-j$.

<footnote n="2">2. La différence avec [16] s'explique par le fait qu'un bug a été trouvé (et corrigé) dans le code public pour RIOT et les autres algorithmes utilisés par [16], au niveau de la division de l'erreur par le nombre de plis dans chaque itération. Le classement final des algorithmes n'est pas affecté par la correction du bug.</footnote>
<table><caption>TABLE 1 – Résultats sur MAR au niveau des groupes; moyenne et écart-type de la RMSE et de la MAE par rapport à la matrice collaborative M. Les résultats pour RECTO correspondent à g = Id+, ε = 1.</caption><thead><tr><th></th><th>Random</th><th>PMF</th><th>SVD</th><th>itemKNN</th><th>RIOT</th><th>γ<sup>NN</sup></th><th>γ<sup>XGB</sup></th></tr></thead><tbody><tr><th>RMSE</th><td>10.71±0.13</td><td>446.6±9.86</td><td>441.4±11.2</td><td>9.36±0.12</td><td>9.12±0.12</td><td>8.98±0.17</td><td>8.89±0.11</td></tr><tr><th>MAE</th><td>7.22±0.06</td><td>251.3±6.00</td><td>249.2±5.71</td><td>6.30±0.03</td><td>5.98±0.10</td><td>5.80±0.13</td><td>5.79±0.12</td></tr></tbody></table>

<table><caption>TABLE 2 – Résultats sur MAR au niveau individuel : Recall, Coverage et Congestion.</caption><thead><tr><th rowspan="2"></th><th rowspan="2">Algorithm</th><th colspan="2">Recall (%)</th><th colspan="2">Coverage (%)</th><th colspan="2">Congestion</th></tr><tr><th>@1</th><th>@10</th><th>@1</th><th>@10</th><th>@1</th><th>@10</th></tr></thead><tbody><tr><td></td><td>φ Random</td><td>0.16</td><td>2.27</td><td>63.32</td><td>100</td><td>-0.90</td><td>-0.98</td></tr><tr><td rowspan="7">RECTO-XGB</td><td>φ XGBOOST</td><td>7.93</td><td>27.88</td><td>48.55</td><td>98.69</td><td>-0.84</td><td>-0.94</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 1.0</td><td>8.05</td><td>28.41</td><td>49.77</td><td>99.18</td><td>-0.85</td><td>-0.95</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.1</td><td>8.01</td><td>27.02</td><td>72.73</td><td>100</td><td>-0.93</td><td>-0.95</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.01</td><td>6.47</td><td>23.77</td><td>96.05</td><td>100</td><td>-0.98</td><td>-0.84</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 1.0</td><td>7.93</td><td>28.2</td><td>48.55</td><td>99.02</td><td>-0.84</td><td>-0.95</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.1</td><td>8.10</td><td>25.72</td><td>59.42</td><td>100</td><td>-0.89</td><td>-0.93</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.01</td><td>6.06</td><td>19.49</td><td>94.26</td><td>100</td><td>-0.98</td><td>-0.73</td></tr><tr><td rowspan="7">RECTO-NN</td><td>φ NN</td><td>3.82</td><td>15.50</td><td>46.27</td><td>98.00</td><td>-0.83</td><td>-0.93</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 1.0</td><td>2.84</td><td>14.32</td><td>38.86</td><td>92.47</td><td>-0.80</td><td>-0.90</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.1</td><td>3.94</td><td>15.46</td><td>70.12</td><td>100</td><td>-0.92</td><td>-0.98</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.01</td><td>3.78</td><td>15.46</td><td>93.48</td><td>100</td><td>-0.98</td><td>-0.95</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 1.0</td><td>3.82</td><td>15.63</td><td>46.27</td><td>98.73</td><td>-0.83</td><td>-0.94</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.1</td><td>4.23</td><td>13.87</td><td>57.99</td><td>99.91</td><td>-0.88</td><td>-0.93</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.01</td><td>2.89</td><td>11.60</td><td>93.44</td><td>100</td><td>-0.98</td><td>-0.72</td></tr></tbody></table>

<table><caption>TABLE 3 – Résultats sur JOB : Recall, Coverage et Congestion.</caption><thead><tr><th rowspan="2"></th><th rowspan="2">Algorithm</th><th colspan="3">Recall (%)</th><th colspan="2">Coverage (%)</th><th colspan="2">Congestion</th></tr><tr><th>@1</th><th>@10</th><th>@100</th><th>@1</th><th>@10</th><th>@1</th><th>@10</th></tr></thead><tbody><tr><td></td><td>φ Random</td><td>0</td><td>0.21</td><td>0.65</td><td>99.95</td><td>100</td><td>-0.99</td><td>-0.99</td></tr><tr><td rowspan="7">RECTO-XGB</td><td>φ XGB</td><td>9.62</td><td>31.40</td><td>61.59</td><td>12.94</td><td>25.16</td><td>-0.62</td><td>-0.64</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 1.0</td><td>4.81</td><td>21.99</td><td>57.87</td><td>21.61</td><td>31.76</td><td>-0.74</td><td>-0.75</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.1</td><td>2.18</td><td>15.31</td><td>56.01</td><td>27.54</td><td>41.24</td><td>-0.78</td><td>-0.81</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.01</td><td>4.37</td><td>20.45</td><td>43.21</td><td>46.75</td><td>57.61</td><td>-0.85</td><td>-0.79</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 1.0</td><td>9.62</td><td>31.61</td><td>62.36</td><td>12.96</td><td>26.14</td><td>-0.62</td><td>-0.67</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.1</td><td>8.97</td><td>25.38</td><td>46.06</td><td>14.69</td><td>30.84</td><td>-0.67</td><td>-0.74</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.01</td><td>5.03</td><td>14.00</td><td>18.81</td><td>36.81</td><td>57.52</td><td>-0.82</td><td>-0.81</td></tr><tr><td rowspan="7">RECTO-NN</td><td>φ NN</td><td>5.68</td><td>28.66</td><td>57.98</td><td>6.02</td><td>17.78</td><td>-0.46</td><td>-0.49</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 1.0</td><td>6.78</td><td>26.14</td><td>60.39</td><td>11.99</td><td>26.30</td><td>-0.62</td><td>-0.65</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.1</td><td>2.40</td><td>19.03</td><td>50.43</td><td>28.23</td><td>40.16</td><td>-0.80</td><td>-0.79</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.01</td><td>3.93</td><td>16.30</td><td>27.89</td><td>53.38</td><td>62.35</td><td>-0.83</td><td>-0.70</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 1.0</td><td>5.68</td><td>27.46</td><td>59.08</td><td>6.02</td><td>19.75</td><td>-0.46</td><td>-0.55</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.1</td><td>5.25</td><td>23.3</td><td>49.01</td><td>8.85</td><td>26.40</td><td>-0.53</td><td>-0.65</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.01</td><td>1.53</td><td>12.36</td><td>24.28</td><td>35.41</td><td>51.56</td><td>-0.81</td><td>-0.81</td></tr></tbody></table>
<table><caption>TABLE 1 – Résultats sur MAR au niveau des groupes; moyenne et écart-type de la RMSE et de la MAE par rapport à la matrice collaborative M. Les résultats pour RECTO correspondent à g = Id+, ε = 1.</caption><thead><tr><th></th><th>Random</th><th>PMF</th><th>SVD</th><th>itemKNN</th><th>RIOT</th><th>γ<sup>NN</sup></th><th>γ<sup>XGB</sup></th></tr></thead><tbody><tr><th>RMSE</th><td>10.71±0.13</td><td>446.6±9.86</td><td>441.4±11.2</td><td>9.36±0.12</td><td>9.12±0.12</td><td>8.98±0.17</td><td>8.89±0.11</td></tr><tr><th>MAE</th><td>7.22±0.06</td><td>251.3±6.00</td><td>249.2±5.71</td><td>6.30±0.03</td><td>5.98±0.10</td><td>5.80±0.13</td><td>5.79±0.12</td></tr></tbody></table>

<table><caption>TABLE 2 – Résultats sur MAR au niveau individuel : Recall, Coverage et Congestion.</caption><thead><tr><th rowspan="2"></th><th rowspan="2">Algorithm</th><th colspan="2">Recall (%)</th><th colspan="2">Coverage (%)</th><th colspan="2">Congestion</th></tr><tr><th>@1</th><th>@10</th><th>@1</th><th>@10</th><th>@1</th><th>@10</th></tr></thead><tbody><tr><td></td><td>φ Random</td><td>0.16</td><td>2.27</td><td>63.32</td><td>100</td><td>-0.90</td><td>-0.98</td></tr><tr><td rowspan="7">RECTO-XGB</td><td>φ XGBOOST</td><td>7.93</td><td>27.88</td><td>48.55</td><td>98.69</td><td>-0.84</td><td>-0.94</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 1.0</td><td>8.05</td><td>28.41</td><td>49.77</td><td>99.18</td><td>-0.85</td><td>-0.95</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.1</td><td>8.01</td><td>27.02</td><td>72.73</td><td>100</td><td>-0.93</td><td>-0.95</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.01</td><td>6.47</td><td>23.77</td><td>96.05</td><td>100</td><td>-0.98</td><td>-0.84</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 1.0</td><td>7.93</td><td>28.2</td><td>48.55</td><td>99.02</td><td>-0.84</td><td>-0.95</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.1</td><td>8.10</td><td>25.72</td><td>59.42</td><td>100</td><td>-0.89</td><td>-0.93</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.01</td><td>6.06</td><td>19.49</td><td>94.26</td><td>100</td><td>-0.98</td><td>-0.73</td></tr><tr><td rowspan="7">RECTO-NN</td><td>φ NN</td><td>3.82</td><td>15.50</td><td>46.27</td><td>98.00</td><td>-0.83</td><td>-0.93</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 1.0</td><td>2.84</td><td>14.32</td><td>38.86</td><td>92.47</td><td>-0.80</td><td>-0.90</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.1</td><td>3.94</td><td>15.46</td><td>70.12</td><td>100</td><td>-0.92</td><td>-0.98</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.01</td><td>3.78</td><td>15.46</td><td>93.48</td><td>100</td><td>-0.98</td><td>-0.95</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 1.0</td><td>3.82</td><td>15.63</td><td>46.27</td><td>98.73</td><td>-0.83</td><td>-0.94</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.1</td><td>4.23</td><td>13.87</td><td>57.99</td><td>99.91</td><td>-0.88</td><td>-0.93</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.01</td><td>2.89</td><td>11.60</td><td>93.44</td><td>100</td><td>-0.98</td><td>-0.72</td></tr></tbody></table>

<table><caption>TABLE 3 – Résultats sur JOB : Recall, Coverage et Congestion.</caption><thead><tr><th rowspan="2"></th><th rowspan="2">Algorithm</th><th colspan="3">Recall (%)</th><th colspan="2">Coverage (%)</th><th colspan="2">Congestion</th></tr><tr><th>@1</th><th>@10</th><th>@100</th><th>@1</th><th>@10</th><th>@1</th><th>@10</th></tr></thead><tbody><tr><td></td><td>φ Random</td><td>0</td><td>0.21</td><td>0.65</td><td>99.95</td><td>100</td><td>-0.99</td><td>-0.99</td></tr><tr><td rowspan="7">RECTO-XGB</td><td>φ XGB</td><td>9.62</td><td>31.40</td><td>61.59</td><td>12.94</td><td>25.16</td><td>-0.62</td><td>-0.64</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 1.0</td><td>4.81</td><td>21.99</td><td>57.87</td><td>21.61</td><td>31.76</td><td>-0.74</td><td>-0.75</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.1</td><td>2.18</td><td>15.31</td><td>56.01</td><td>27.54</td><td>41.24</td><td>-0.78</td><td>-0.81</td></tr><tr><td>γ<sup>XGB</sup>,g = Id+,ε = 0.01</td><td>4.37</td><td>20.45</td><td>43.21</td><td>46.75</td><td>57.61</td><td>-0.85</td><td>-0.79</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 1.0</td><td>9.62</td><td>31.61</td><td>62.36</td><td>12.96</td><td>26.14</td><td>-0.62</td><td>-0.67</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.1</td><td>8.97</td><td>25.38</td><td>46.06</td><td>14.69</td><td>30.84</td><td>-0.67</td><td>-0.74</td></tr><tr><td>γ<sup>XGB</sup>,g = ndcg,ε = 0.01</td><td>5.03</td><td>14.00</td><td>18.81</td><td>36.81</td><td>57.52</td><td>-0.82</td><td>-0.81</td></tr><tr><td rowspan="7">RECTO-NN</td><td>φ NN</td><td>5.68</td><td>28.66</td><td>57.98</td><td>6.02</td><td>17.78</td><td>-0.46</td><td>-0.49</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 1.0</td><td>6.78</td><td>26.14</td><td>60.39</td><td>11.99</td><td>26.30</td><td>-0.62</td><td>-0.65</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.1</td><td>2.40</td><td>19.03</td><td>50.43</td><td>28.23</td><td>40.16</td><td>-0.80</td><td>-0.79</td></tr><tr><td>γ<sup>NN</sup>,g = Id+,ε = 0.01</td><td>3.93</td><td>16.30</td><td>27.89</td><td>53.38</td><td>62.35</td><td>-0.83</td><td>-0.70</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 1.0</td><td>5.68</td><td>27.46</td><td>59.08</td><td>6.02</td><td>19.75</td><td>-0.46</td><td>-0.55</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.1</td><td>5.25</td><td>23.3</td><td>49.01</td><td>8.85</td><td>26.40</td><td>-0.53</td><td>-0.65</td></tr><tr><td>γ<sup>NN</sup>,g = ndcg,ε = 0.01</td><td>1.53</td><td>12.36</td><td>24.28</td><td>35.41</td><td>51.56</td><td>-0.81</td><td>-0.81</td></tr></tbody></table>
<table><caption>TABLE 4 – Temps de calcul en secondes sur JOB (moyenne sur toutes les options g). NN a été entraîné sur un serveur équipé de 2 processeurs Intel Xeon Silver 4214 2,2 GHz, de 192Go de RAM et d'un GPU Tesla T4. XGBOOST est entraîné sur un serveur DELL PowerEdge R640 avec 2X Intel Xeon Gold 6130 2.10GHz CPUs (2 × 16 cores) et 384Go RAM. Le plan de transport optimal est calculé sur le DELL avec les mêmes ressources que pour XGBOOST.</caption><thead><tr><th rowspan="2">Temps de calcul</th><th colspan="2">φ</th><th colspan="3">γ<sup>XGB</sup></th><th colspan="3">γ<sup>NN</sup></th></tr><tr><th>XGBoost</th><th>NN</th><th>ε = 0.01</th><th>ε = 0.1</th><th>ε = 1</th><th>ε = 0.01</th><th>ε = 0.1</th><th>ε = 1</th></tr></thead><tbody><tr><td>Total</td><td>104,340</td><td>4,104</td><td>104,778</td><td>104,394</td><td>104,385</td><td>4,611</td><td>4,156</td><td>4,148</td></tr><tr><td>(incl. Appr./OT)</td><td>(7,454/-)</td><td>(2,039/-)</td><td>(7,454/438)</td><td>(7,454/54)</td><td>(7,454/45)</td><td>(2,039/507)</td><td>(2,039/52)</td><td>(2,039/44)</td></tr></tbody></table>

# 5 Conclusion et Perspectives

Dans la lignée de l'IA éthique [14], cet article vise à préve-
nir les effets indésirables des systèmes de recommandation
de bien rivaux, notamment dans le domaine du marché du
travail. En effet, si certaines offres d'emploi sont recom-
mandées à de nombreux demandeurs d'emploi, un phéno-
mène de congestion est observé au niveau global, entraînant
un gaspillage de temps et d'autres effets préjudiciables pour
les demandeurs d'emploi comme pour les recruteurs.

L'approche proposée s'inspire du transport optimal, avec
l'idée de "transporter" globalement la population des de-
mandeurs d'emploi sur la population des offres d'emploi,
en visant un recall décent avec une faible congestion. La
question clé devient alors la définition du coût de transport.
Dans cet article, le coût de transport est basé sur un score
de recommandation appris de façon classique (sans prendre
en compte la congestion). Les leçons surprenantes tirées
de l'application de l'approche sur un vaste jeu de données
issu du monde réel sont que le coût de transport et la ré-
gularisation du transport (utilisée pour garantir le passage à
l'échelle de l'OT) interagissent de manière subtile. En par-
ticulier, une forte régularisation (qui devrait normalement
donner un plan de transport uniforme) dégrade considéra-
blement le recall, tout en n'améliorant pas la congestion.

Ce travail ouvre deux perspectives principales. Du côté al-
gorithmique, des travaux futurs se pencheront sur l'appren-
tissage de bout en bout du plan de recommandation, en te-
nant compte à la fois du recall et du coverage. Un objectif
intermédiaire est d'apprendre la fonction g utilisée pour dé-
finir les coûts de transport à partir de la fonction de score.

Une autre perspective, dans le cadre du marché du travail
ou des rencontres matrimoniales, consisterait à estimer les
caractéristiques structurelles du comportement individuel,
telles que l'aversion au risque ou à la concurrence. Ces ca-
ractéristiques pourraient à leur tour être incorporées aux re-
commandations, permettant de prendre en compte le niveau
de congestion acceptable pour différents types d'individus
dans la définition d'une stratégie globale évitant la conges-
tion.

Plus fondamentalement, la construction d'un "système de
recommandation d'emploi équitable" devrait être considé-
rée comme l'apprentissage d'un modèle prescriptif (suivez
cette politique pour atteindre les objectifs souhaités), plu-
tôt que d'un modèle prédictif (suivez cette politique car
elle estime avec précision les préférences des utilisateurs)
[13, 20, 23]. Les mérites et les limites d'un tel modèle pres-
criptif nécessiteront des expériences fondées sur la métho-

dologie des essais contrôlés randomisés [19].

# Remerciements

Cette recherche a été soutenue par l'institut convergences DATAIA dans le cadre du "Programme d'Investissement d'Avenir" (ANR-17-CONV-0003) géré par l'Institut Poly-technique de Paris et l'Université Paris-Saclay.

# Références

[1] Charu C Aggarwal. Recommender systems, volume 1. Springer, 2016.

[2] Fedor Borisyuk, Liang Zhang, and Krishnaram Ken-thapadi. Lijar: A system for job application redistribu-tion towards efficient career marketplace. In *Proceedings of the 23rd ACM SIGKDD*, pages 1397–1406. ACM, 2017.

[3] Chris Burges, Tal Shaked, Erin Renshaw, Ari Lazier, Matt Deeds, Nicole Hamilton, and Greg Hullender. Learning to rank using gradient descent. In *Proceedings of the 22nd international conference on Machine learning*, pages 89–96, 2005.

[4] Gal Chechik, Uri Shalit, Varun Sharma, and Samy Bengio. An online algorithm for large scale image similarity learning. *Advances in Neural Information Processing Systems*, 22 :306–314, 2009.

[5] Kuan-Ming Chen, Yu-Wei Hsieh, and Ming-Jen Lin. Prediction and congestion in two-sided markets : Economist versus machine matchmakers. SSRN Electronic Journal, 2019.

[6] Kuan-Ming Chen, Yu-Wei Hsieh, and Ming-Jen Lin. Reducing recommendation inequality via two-sided matching : A field experiment of online dating. SSRN Electronic Journal, 01 2020.

[7] Pierre-André Chiappori and Bernard Salanié. The econometrics of matching models. *Journal of Economic Literature*, 54(3) :832–61, 2016.

[8] Paolo Cremonesi, Yehuda Koren, and Roberto Turrin. Performance of recommender algorithms on top-n re-recommandation tasks. In *Proceedings of the Fourth ACM Conference on Recommender Systems, RecSys '10*, page 3946, New York, NY, USA, 2010. Association for Computing Machinery.

[9] Marco Cuturi. Sinkhorn distances : Lightspeed computation of optimal transport. In *Advances in Neural Information Processing Systems*, page 22922300, 2013.
<table><caption>TABLE 4 – Temps de calcul en secondes sur JOB (moyenne sur toutes les options g). NN a été entraîné sur un serveur équipé de 2 processeurs Intel Xeon Silver 4214 2,2 GHz, de 192Go de RAM et d'un GPU Tesla T4. XGBOOST est entraîné sur un serveur DELL PowerEdge R640 avec 2X Intel Xeon Gold 6130 2.10GHz CPUs (2 × 16 cores) et 384Go RAM. Le plan de transport optimal est calculé sur le DELL avec les mêmes ressources que pour XGBOOST.</caption><thead><tr><th rowspan="2">Temps de calcul</th><th colspan="2">φ</th><th colspan="3">γ<sup>XGB</sup></th><th colspan="3">γ<sup>NN</sup></th></tr><tr><th>XGBoost</th><th>NN</th><th>ε = 0.01</th><th>ε = 0.1</th><th>ε = 1</th><th>ε = 0.01</th><th>ε = 0.1</th><th>ε = 1</th></tr></thead><tbody><tr><th>Total</th><td>104,340</td><td>4,104</td><td>104,778</td><td>104,394</td><td>104,385</td><td>4,611</td><td>4,156</td><td>4,148</td></tr><tr><th>(incl. Appr./OT)</th><td>(7,454/-)</td><td>(2,039/-)</td><td>(7,454/438)</td><td>(7,454/54)</td><td>(7,454/45)</td><td>(2,039/507)</td><td>(2,039/52)</td><td>(2,039/44)</td></tr></tbody></table>

# 5 Conclusion et Perspectives

Dans la lignée de l'IA éthique [14], cet article vise à préve-
nir les effets indésirables des systèmes de recommandation
de bien rivaux, notamment dans le domaine du marché du
travail. En effet, si certaines offres d'emploi sont recom-
mandées à de nombreux demandeurs d'emploi, un phéno-
mène de congestion est observé au niveau global, entraînant
un gaspillage de temps et d'autres effets préjudiciables pour
les demandeurs d'emploi comme pour les recruteurs.

L'approche proposée s'inspire du transport optimal, avec
l'idée de "transporter" globalement la population des de-
mandeurs d'emploi sur la population des offres d'emploi,
en visant un recall décent avec une faible congestion. La
question clé devient alors la définition du coût de transport.
Dans cet article, le coût de transport est basé sur un score
de recommandation appris de façon classique (sans prendre
en compte la congestion). Les leçons surprenantes tirées
de l'application de l'approche sur un vaste jeu de données
issu du monde réel sont que le coût de transport et la ré-
gularisation du transport (utilisée pour garantir le passage à
l'échelle de l'OT) interagissent de manière subtile. En par-
ticulier, une forte régularisation (qui devrait normalement
donner un plan de transport uniforme) dégrade considéra-
blement le recall, tout en n'améliorant pas la congestion.

Ce travail ouvre deux perspectives principales. Du côté al-
gorithmique, des travaux futurs se pencheront sur l'appren-
tissage de bout en bout du plan de recommandation, en te-
nant compte à la fois du recall et du coverage. Un objectif
intermédiaire est d'apprendre la fonction g utilisée pour dé-
finir les coûts de transport à partir de la fonction de score.

Une autre perspective, dans le cadre du marché du travail
ou des rencontres matrimoniales, consisterait à estimer les
caractéristiques structurelles du comportement individuel,
telles que l'aversion au risque ou à la concurrence. Ces ca-
ractéristiques pourraient à leur tour être incorporées aux re-
commandations, permettant de prendre en compte le niveau
de congestion acceptable pour différents types d'individus
dans la définition d'une stratégie globale évitant la conges-
tion.

Plus fondamentalement, la construction d'un "système de
recommandation d'emploi équitable" devrait être considé-
rée comme l'apprentissage d'un modèle prescriptif (suivez
cette politique pour atteindre les objectifs souhaités), plu-
tôt que d'un modèle prédictif (suivez cette politique car
elle estime avec précision les préférences des utilisateurs)
[13, 20, 23]. Les mérites et les limites d'un tel modèle pres-
criptif nécessiteront des expériences fondées sur la métho-

dologie des essais contrôlés randomisés [19].

# Remerciements

Cette recherche a été soutenue par l'institut convergences DATAIA dans le cadre du "Programme d'Investissement d'Avenir" (ANR-17-CONV-0003) géré par l'Institut Poly-technique de Paris et l'Université Paris-Saclay.

# Références

[1] Charu C Aggarwal. Recommender systems, volume 1. Springer, 2016.

[2] Fedor Borisyuk, Liang Zhang, and Krishnaram Ken-thapadi. Lijar: A system for job application redistribu-tion towards efficient career marketplace. In *Proceedings of the 23rd ACM SIGKDD*, pages 1397–1406. ACM, 2017.

[3] Chris Burges, Tal Shaked, Erin Renshaw, Ari Lazier, Matt Deeds, Nicole Hamilton, and Greg Hullender. Learning to rank using gradient descent. In *Proceedings of the 22nd international conference on Machine learning*, pages 89–96, 2005.

[4] Gal Chechik, Uri Shalit, Varun Sharma, and Samy Bengio. An online algorithm for large scale image similarity learning. *Advances in Neural Information Processing Systems*, 22 :306–314, 2009.

[5] Kuan-Ming Chen, Yu-Wei Hsieh, and Ming-Jen Lin. Prediction and congestion in two-sided markets : Economist versus machine matchmakers. SSRN Electronic Journal, 2019.

[6] Kuan-Ming Chen, Yu-Wei Hsieh, and Ming-Jen Lin. Reducing recommendation inequality via two-sided matching : A field experiment of online dating. SSRN Electronic Journal, 01 2020.

[7] Pierre-André Chiappori and Bernard Salanié. The econometrics of matching models. *Journal of Economic Literature*, 54(3) :832–61, 2016.

[8] Paolo Cremonesi, Yehuda Koren, and Roberto Turrin. Performance of recommender algorithms on top-n re- commendation tasks. In *Proceedings of the Fourth ACM Conference on Recommender Systems, RecSys '10*, page 3946, New York, NY, USA, 2010. Association for Computing Machinery.

[9] Marco Cuturi. Sinkhorn distances : Lightspeed computation of optimal transport. In *Advances in Neural Information Processing Systems*, page 22922300, 2013.
[10] Alfred Galichon. *Optimal transport methods in economics*. Princeton University Press, 2018.

[11] Alfred Galichon and Bernard Salanié. Cupids invisible hand: Social surplus and identification in matching models. *Available at SSRN 1804623*, 2020.

[12] Stanislao Gualdi, Matús Medo, and Yi-Cheng Zhang. Crowd avoidance and diversity in socio-economic systems and recommendation. *CoRR*, abs/1301.1887, 2013.

[13] Guido W Imbens and Donald B Rubin. *Causal inference in statistics, social, and biomedical sciences*. Cambridge University Press, 2015.

[14] Jon Kleinberg, Jens Ludwig, Sendhil Mullainathan, and Ashesh Rambachan. Algorithmic fairness. In *Aea papers and proceedings*, volume 108, pages 22–27, 2018.

[15] Matevž Kunaver and Tomaž Požrl. Diversity in recommender systems—a survey. *Knowledge-Based Systems*, 123:154–162, 2017.

[16] Ruilin Li, Xiaojing Ye, Haomin Zhou, and Hongyuan Zha. Learning to match via inverse optimal transport. *J. Mach. Learn. Res.*, 20(80):1–37, 2019.

[17] Ruishan Liu, Akshay Balsubramani, and James Zou. Learning transport cost from subset correspondence. *arXiv preprint arXiv:1909.13203*, 2019.

[18] Ivan Palomares, Carlos Porcel, Luiz Pizzato, Ido Guy, and Enrique Herrera-Viedma. Reciprocal recommendation systems: Analysis of state-of-art literature, challenges and opportunities towards social recommendation. *arXiv preprint arXiv:2007.16120*, 2020.

[19] W. Pearce and S. Raman. The new randomised controlled trials (RCT) movement in public policy: challenges of epistemic governance. *Policy Sci*, 47:387402, 2014.

[20] Jonas Peters, Dominik Janzing, and Bernhard Schölkopf. *Elements of causal inference: foundations and learning algorithms*. MIT press, 2017.

[21] Gabriel Peyré and Marco Cuturi. Computational optimal transport. *Foundations and Trends® in Machine Learning*, 11(5-6):355–607, 2019.

[22] Bernhard Schmitzer. Stabilized sparse scaling algorithms for entropy regularized transport problems. *arXiv preprint arXiv:1610.06519*, 2019.

[23] Flavian Vasile and Stephen Bonner. Causal embeddings for recommendation: An extended abstract. In *IJCAI-19*, pages 6236–6240. International Joint Conferences on Artificial Intelligence Organization, 7 2019.

[24] Maksims Volkovs, Guang Wei Yu, and Tomi Poutanen. Content-based neighbor models for cold start in recommender systems. In *Proceedings of the Recommender Systems Challenge 2017 - RecSys Challenge* 17. ACM Press, 2017.

[25] Kilian Q Weinberger and Lawrence K Saul. Distance metric learning for large margin nearest neighbor classification. *J. Mach. Learn. Res.*, 10(2), 2009.

[26] Bin Xia, Junjie Yin, Jian Xu, and Yun Li. We-rec: A fairness-aware reciprocal recommendation based on walrasian equilibrium. *Knowledge-Based Systems*, 182, 08 2019.

# Appendices

## Annexe A : Une régularisation entropique plus élevée peut ne pas réduire la congestion

D’après [21] (prop. 4.1), lorsque le poids $\varepsilon$ du terme de régularisation entropique tend vers $\infty$, la solution $\gamma$ du problème de transport optimal régularisé tend vers une distribution uniforme. Lorsque $\varepsilon \to 0$, en revanche, la solution converge vers le plan de transport optimal avec entropie maximale. De manière informelle, augmenter $\varepsilon$ conduit à des solutions $\gamma$ moins parcimonieuse.

Cependant, de manière inattendue, l’utilisation de $\gamma$ pour un processus de recommandation par classement n’implique pas nécessairement qu’un $\gamma$ plus uniforme entraîne moins de congestion.

Ce phénomène peut être analysé en simulation. 1 000 matrices de coût $C$ de taille $n = 30$, $m = 10$ sont générées indépendamment, avec $C_{ij} \sim U(\frac{j}{m}, \frac{j}{m}+1)$ (les items étant ordonnés par attractivité croissante). Les plans de transport $\gamma$ avec marges uniformes par rapport aux utilisateurs et aux items sont ensuite calculés à l’aide de l’algorithme de Sinkhorn et un poids de régularisation entropique $\varepsilon = 100$ et $\varepsilon = 0,01$. La moyenne et l’écart type sur les 1 000 exécutions de la congestion obtenue après les classements issu ces plans indiquent que la congestion est significativement plus élevée pour la valeur de $\varepsilon$ la plus élevée :

<table><thead><tr><td>ε</td><td>moyenne de congestion@ 1</td><td>écart-type</td></tr></thead><tbody><tr><td>100</td><td>-0.940521</td><td>0.029445</td></tr><tr><td>0.01</td><td>-0.996059</td><td>0.003586</td></tr></tbody></table>

Les figures 1, 2, 3 et 4 illustrent ce phénomène sur une seule simulation représentative. Les valeurs de $\gamma_{ij}$ sont plus uniformes lorsque $\varepsilon = 100$ que lorsque $\varepsilon = 0,01$, mais le classement par ligne conduit à une répartition plus inégale des recommandations vers les différentes offres.

Dans l’ensemble, une régularisation entropique plus élevée a un impact indéterminé sur la congestion et peut même l’augmenter en pratique. Le choix de $\varepsilon$ doit donc être basé sur un ensemble de validation, ainsi que sur des critères numériques pour la convergence de l’algorithme de Sinkhorn. On peut noter que l’utilisation de valeurs extrêmement faibles de $\varepsilon$ avec une implémentation naïve de l’algorithme de Sinkhorn peut avoir des conséquences néfastes sur la stabilité numérique ainsi que sur la vitesse de convergence, bien que des alternatives aient été développées, par exemple dans [22].
[10] Alfred Galichon. *Optimal transport methods in economics*. Princeton University Press, 2018.

[11] Alfred Galichon and Bernard Salanié. Cupids invisible hand: Social surplus and identification in matching models. *Available at SSRN 1804623*, 2020.

[12] Stanislao Gualdi, Matús Medo, and Yi-Cheng Zhang. Crowd avoidance and diversity in socio-economic systems and recommendation. *CoRR*, abs/1301.1887, 2013.

[13] Guido W Imbens and Donald B Rubin. *Causal inference in statistics, social, and biomedical sciences*. Cambridge University Press, 2015.

[14] Jon Kleinberg, Jens Ludwig, Sendhil Mullainathan, and Ashesh Rambachan. Algorithmic fairness. In *Aea papers and proceedings*, volume 108, pages 22–27, 2018.

[15] Matevž Kunaver and Tomaž Požrl. Diversity in recommender systems—a survey. *Knowledge-Based Systems*, 123:154–162, 2017.

[16] Ruilin Li, Xiaojing Ye, Haomin Zhou, and Hongyuan Zha. Learning to match via inverse optimal transport. *J. Mach. Learn. Res.*, 20(80):1–37, 2019.

[17] Ruishan Liu, Akshay Balsubramani, and James Zou. Learning transport cost from subset correspondence. *arXiv preprint arXiv:1909.13203*, 2019.

[18] Ivan Palomares, Carlos Porcel, Luiz Pizzato, Ido Guy, and Enrique Herrera-Viedma. Reciprocal recommendation systems: Analysis of state-of-art literature, challenges and opportunities towards social recommendation. *arXiv preprint arXiv:2007.16120*, 2020.

[19] W. Pearce and S. Raman. The new randomised controlled trials (RCT) movement in public policy: challenges of epistemic governance. *Policy Sci*, 47:387402, 2014.

[20] Jonas Peters, Dominik Janzing, and Bernhard Schölkopf. *Elements of causal inference: foundations and learning algorithms*. MIT press, 2017.

[21] Gabriel Peyré and Marco Cuturi. Computational optimal transport. *Foundations and Trends® in Machine Learning*, 11(5-6):355–607, 2019.

[22] Bernhard Schmitzer. Stabilized sparse scaling algorithms for entropy regularized transport problems. *arXiv preprint arXiv:1610.06519*, 2019.

[23] Flavian Vasile and Stephen Bonner. Causal embeddings for recommendation: An extended abstract. In *IJCAI-19*, pages 6236–6240. International Joint Conferences on Artificial Intelligence Organization, 7 2019.

[24] Maksims Volkovs, Guang Wei Yu, and Tomi Poutanen. Content-based neighbor models for cold start in recommender systems. In *Proceedings of the Recommender Systems Challenge 2017 - RecSys Challenge* 17. ACM Press, 2017.

[25] Kilian Q Weinberger and Lawrence K Saul. Distance metric learning for large margin nearest neighbor classification. *J. Mach. Learn. Res.*, 10(2), 2009.

[26] Bin Xia, Junjie Yin, Jian Xu, and Yun Li. We-rec: A fairness-aware reciprocal recommendation based on walrasian equilibrium. *Knowledge-Based Systems*, 182, 08 2019.

# Appendices

## Annexe A : Une régularisation entropique plus élevée peut ne pas réduire la congestion

D’après [21] (prop. 4.1), lorsque le poids $\epsilon$ du terme de régularisation entropique tend vers $\infty$, la solution $\gamma$ du problème de transport optimal régularisé tend vers une distribution uniforme. Lorsque $\epsilon \to 0$, en revanche, la solution converge vers le plan de transport optimal avec entropie maximale. De manière informelle, augmenter $\epsilon$ conduit à des solutions $\gamma$ moins parcimonieuse.

Cependant, de manière inattendue, l’utilisation de $\gamma$ pour un processus de recommandation par classement n’implique pas nécessairement qu’un $\gamma$ plus uniforme entraîne moins de congestion.

Ce phénomène peut être analysé en simulation. 1 000 matrices de coût $C$ de taille $n = 30$, $m = 10$ sont générées indépendamment, avec $C_{ij} \sim U(\frac{j}{m}, \frac{j}{m}+1)$ (les items étant ordonnés par attractivité croissante). Les plans de transport $\gamma$ avec marges uniformes par rapport aux utilisateurs et aux items sont ensuite calculés à l’aide de l’algorithme de Sinkhorn et un poids de régularisation entropique $\epsilon = 100$ et $\epsilon = 0,01$. La moyenne et l’écart type sur les 1 000 exécutions de la congestion obtenue après les classements issu ces plans indiquent que la congestion est significativement plus élevée pour la valeur de $\epsilon$ la plus élevée :

<table><thead><tr><td>ε</td><td>moyenne de congestion@ 1</td><td>écart-type</td></tr></thead><tbody><tr><td>100</td><td>-0.940521</td><td>0.029445</td></tr><tr><td>0.01</td><td>-0.996059</td><td>0.003586</td></tr></tbody></table>

Les figures 1, 2, 3 et 4 illustrent ce phénomène sur une seule simulation représentative. Les valeurs de $\gamma_{ij}$ sont plus uniformes lorsque $\epsilon = 100$ que lorsque $\epsilon = 0,01$, mais le classement par ligne conduit à une répartition plus inégale des recommandations vers les différentes offres.

Dans l’ensemble, une régularisation entropique plus élevée a un impact indéterminé sur la congestion et peut même l’augmenter en pratique. Le choix de $\epsilon$ doit donc être basé sur un ensemble de validation, ainsi que sur des critères numériques pour la convergence de l’algorithme de Sinkhorn. On peut noter que l’utilisation de valeurs extrêmement faibles de $\epsilon$ avec une implémentation naïve de l’algorithme de Sinkhorn peut avoir des conséquences néfastes sur la stabilité numérique ainsi que sur la vitesse de convergence, bien que des alternatives aient été développées, par exemple dans [22].
<figure><img src="image_49.png" /><figcaption>TABLE 7 – NN : Hyperparamètres pour MAR</figcaption></figure>

<table><tr><td>Couche 1</td><td>tanh, dim. 300</td></tr><tr><td>Embedding</td><td>tanh, dim. 300</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.001</td></tr><tr><td>Epochs</td><td>300</td></tr><tr><td>Taille de batch</td><td>64</td></tr><tr><td>Ratio d'échantillonnage négatif (par epoch)</td><td>10</td></tr></table>

## Annexe B : Hyperparamètres

Cette annexe détaille les hyperparamètres utilisés pour entraîner XGBOOST et NN sur les deux jeux de données.

### XGBOOST

Sur MAR, XGBOOST est utilisé avec ses paramètres par défaut, à l'exception du nombre d'arbres, fixé à 200. Une perte logistique est utilisée et le taux d'échantillonnage négatif est fixé à 50 (Tableau 5).

<table><caption>TABLE 5 – XGBOOST Hyperparamètres pour MAR</caption><tr><td>Nombre d'arbres</td><td>200</td></tr><tr><td>Fonction de perte</td><td>Logistique</td></tr><tr><td>Ratio d'échantillonnage négatif</td><td>50</td></tr></table>

Sur JOB, XGBOOST est utilisé avec les hyperparamètres indiqués dans le tableau 6. Les autres hyperparamètres sont fixés à leur valeur par défaut.

<table><caption>TABLE 6 – XGBOOST Hyperparamètres pour JOB</caption><tr><td>col_sample_bytree</td><td>0.6</td></tr><tr><td>eta</td><td>0.075</td></tr><tr><td>gamma</td><td>0.85</td></tr><tr><td>max_depth</td><td>12</td></tr><tr><td>min_child_weight</td><td>1</td></tr><tr><td>subsample</td><td>0.9</td></tr><tr><td>Nombre d'arbres</td><td>400</td></tr><tr><td>Fonction de perte</td><td>Logistique</td></tr><tr><td>Ratio pour l'échantillonnage négatif</td><td>50</td></tr></table>

### NN

Le paramètre de marge $\eta$ dans la fonction de perte est fixé à 1 dans toutes les expériences.

Sur MAR, NN est utilisé avec les hyperparamètres du Tableau 7. Dans chaque batch, 10 paires négatives sont sélectionnées uniformément pour chaque positive.

Sur JOB, le modèle NN utilise une architecture définie pour le marché de l'emploi, avec trois modules neuronaux. Le

premier module "géographique" prend les coordonnées latitude et longitude standardisées d'une commune, et produit une représentation de dimension 50 en utilisant deux couches cachées de taille 100 et des fonctions d'activation tanh. Le module est entraîné pendant 100 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial de $10^{-4}$. Les exemples négatifs sont choisis en prenant des items plus éloignés (géographiquement) que l'item positif. Le deuxième module "compétences" prend les compétences standardisées et les réduit à une représentation de dimension 100 avec une couche cachée de taille 200 et une fonction d'activation RELU. La matrice de similarité est diagonale, et le module est entraîné pendant 100 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial $10^{-4}$. Le troisième module "autre" prend les autres variables, avec une couche cachée de taille 500 et produit une représentation de dimension 200. Le module est entraîné pendant 100 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial $10^{-4}$. L'architecture d'ensemble est initialisée en utilisant les poids pré-entraînés des trois modules précédents, et la matrice de similarité A est contrainte d'être diagonale par blocs. Le module est ensuite entraîné pendant 35 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial $10^{-4}$, en utilisant des exemples négatifs choisis uniformément. Les autres hyperparamètres sont détaillés dans la Table 6.

## Annexe C : Résultats complets

La figure 5 présente les résultats de toutes les méthodes dans le plan 2D recall@10, congestion@10. La figure 6 présente des courbes de Lorenz pour illustrer la qualité de recommandation. Enfin, le tableau 4 présente les temps de calcul pour chaque méthode. Les temps d'entraînement pour XGBOOST et NN sont limités à respectivement 2 heures et 30 minutes. Le temps du transport optimal augmente avec la diminution de $\epsilon$ jusqu'à environ 10 minutes pour $\epsilon = 0,01$. Le coût le plus important vient du calcul des recommandations avec XGBOOST et $\gamma^{XGB}$ en raison de la nécessité de calculer des variables d'adéquation jointe pour toutes les paires (utilisateur, item).
<figure><img src="image_49.png" /><figcaption>FIGURE 1 – Coûts bruts</figcaption></figure>

## Annexe B : Hyperparamètres

Cette annexe détaille les hyperparamètres utilisés pour entraîner XGBOOST et NN sur les deux jeux de données.

### XGBOOST

Sur MAR, XGBOOST est utilisé avec ses paramètres par défaut, à l'exception du nombre d'arbres, fixé à 200. Une perte logistique est utilisée et le taux d'échantillonnage négatif est fixé à 50 (Tableau 5).

<table><caption>TABLE 5 – XGBOOST Hyperparamètres pour MAR</caption><tr><td>Nombre d'arbres</td><td>200</td></tr><tr><td>Fonction de perte</td><td>Logistique</td></tr><tr><td>Ratio d'échantillonnage négatif</td><td>50</td></tr></table>

Sur JOB, XGBOOST est utilisé avec les hyperparamètres indiqués dans le tableau 6. Les autres hyperparamètres sont fixés à leur valeur par défaut.

<table><caption>TABLE 6 – XGBOOST Hyperparamètres pour JOB</caption><tr><td>col_sample_bytree</td><td>0.6</td></tr><tr><td>eta</td><td>0.075</td></tr><tr><td>gamma</td><td>0.85</td></tr><tr><td>max_depth</td><td>12</td></tr><tr><td>min_child_weight</td><td>1</td></tr><tr><td>subsample</td><td>0.9</td></tr><tr><td>Nombre d'arbres</td><td>400</td></tr><tr><td>Fonction de perte</td><td>Logistique</td></tr><tr><td>Ratio pour l'échantillonnage négatif</td><td>50</td></tr></table>

### NN

Le paramètre de marge $\eta$ dans la fonction de perte est fixé à 1 dans toutes les expériences.

Sur MAR, NN est utilisé avec les hyperparamètres du Tableau 7. Dans chaque batch, 10 paires négatives sont sélectionnées uniformément pour chaque positive.

Sur JOB, le modèle NN utilise une architecture définie pour le marché de l'emploi, avec trois modules neuronaux. Le

<table><caption>TABLE 7 – NN : Hyperparamètres pour MAR</caption><tr><td>Couche 1</td><td>tanh, dim. 300</td></tr><tr><td>Embedding</td><td>tanh, dim. 300</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.001</td></tr><tr><td>Epochs</td><td>300</td></tr><tr><td>Taille de batch</td><td>64</td></tr><tr><td>Ratio d'échantillogange négatif (par epoch)</td><td>10</td></tr></table>

premier module "géographique" prend les coordonnées latitude et longitude standardisées d'une commune, et produit une représentation de dimension 50 en utilisant deux couches cachées de taille 100 et des fonctions d'activation tanh. Le module est entraîné pendant 100 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial de $10^{-4}$. Les exemples négatifs sont choisis en prenant des items plus éloignés (géographiquement) que l'item positif. Le deuxième module "compétences" prend les compétences standardisées et les réduit à une représentation de dimension 100 avec une couche cachée de taille 200 et une fonction d'activation RELU. La matrice de similarité est diagonale, et le module est entraîné pendant 100 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial $10^{-4}$. Le troisième module "autre" prend les autres variables, avec une couche cachée de taille 500 et produit une représentation de dimension 200. Le module est entraîné pendant 100 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial $10^{-4}$. L'architecture d'ensemble est initialisée en utilisant les poids pré-entraînés des trois modules précédents, et la matrice de similarité A est contrainte d'être diagonale par blocs. Le module est ensuite entraîné pendant 35 epochs avec l'algorithme d'optimisation Adam et un taux d'apprentissage initial $10^{-4}$, en utilisant des exemples négatifs choisis uniformément. Les autres hyperparamètres sont détaillés dans la Table 6.

## Annexe C : Résultats complets

La figure 5 présente les résultats de toutes les méthodes dans le plan 2D recall@10, congestion@10. La figure 6 présente des courbes de Lorenz pour illustrer la qualité de recommandation. Enfin, le tableau 4 présente les temps de calcul pour chaque méthode. Les temps d'entraînement pour XGBOOST et NN sont limités à respectivement 2 heures et 30 minutes. Le temps du transport optimal augmente avec la diminution de $\epsilon$ jusqu'à environ 10 minutes pour $\epsilon = 0,01$. Le coût le plus important vient du calcul des recommandations avec XGBOOST et $\gamma^{XGB}$ en raison de la nécessité de calculer des variables d'adéquation jointe pour toutes les paires (utilisateur, item).
<figure><img src="image_50.png" /><figcaption>FIGURE 3 – $\epsilon$ = 0.1</figcaption></figure>

<figure><img src="image_51.png" /><figcaption>FIGURE 4 – $\epsilon$ = 0.01</figcaption></figure>

<figure><img src="image_52.png" /></figure>
<figure><img src="image_50.png" /><figcaption>FIGURE 3 – $\epsilon$ = 0.1</figcaption></figure>

<figure><img src="image_51.png" /><figcaption>FIGURE 4 – $\epsilon$ = 0.01</figcaption></figure>

<figure><img src="image_52.png" /></figure>
<figure><img src="image_53.png" /><figcaption>FIGURE 6 – Courbes de Lorenz calculées sur les recommandations du Top10</figcaption></figure>

<table><caption>TABLE 8 – Hyperparamètres - NN (JOB)</caption><tbody><tr><td colspan="2">Sous-module géographique</td></tr><tr><td>Couche 1</td><td>tanh, dim. 100</td></tr><tr><td>Couche 2</td><td>tanh, dim. 100</td></tr><tr><td>Embedding</td><td>tanh, dim. 50</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001</td></tr><tr><td>Epochs</td><td>100</td></tr><tr><td>Taille de batch</td><td>32</td></tr><tr><td colspan="2">Sous-module compétences</td></tr><tr><td>Couche 1</td><td>ReLU, dim. 200</td></tr><tr><td>Embedding</td><td>tanh, size = 100</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001</td></tr><tr><td>Epochs</td><td>100</td></tr><tr><td>Taille de batch</td><td>32</td></tr><tr><td colspan="2">Module "général"</td></tr><tr><td>Couche 1</td><td>ReLU, dim. 500</td></tr><tr><td>Embedding</td><td>tanh, dim. 200</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001</td></tr><tr><td>Epochs</td><td>100</td></tr><tr><td>Taille de batch</td><td>256</td></tr><tr><td colspan="2">Apprentissage à chaud</td></tr><tr><td>Structure bloc-diagonale</td><td>Oui</td></tr><tr><td>Epochs</td><td>10 / 25</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001 / 0.00001</td></tr><tr><td>Taille de batch</td><td>256</td></tr></tbody></table>

<figure><img src="image_54.png" /><figcaption>(a) XGB sur le jeu de données JOB</figcaption></figure>

<figure><img src="image_55.png" /><figcaption>(b) NN sur le jeu de données JOB</figcaption></figure>
<figure><img src="image_53.png" /><figcaption>FIGURE 6 – Courbes de Lorenz calculées sur les recommandations du Top10</figcaption></figure>

<table><caption>TABLE 8 – Hyperparamètres - NN (JOB)</caption><tbody><tr><td colspan="2">Sous-module géographique</td></tr><tr><td>Couche 1</td><td>tanh, dim. 100</td></tr><tr><td>Couche 2</td><td>tanh, dim. 100</td></tr><tr><td>Embedding</td><td>tanh, dim. 50</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001</td></tr><tr><td>Epochs</td><td>100</td></tr><tr><td>Taille de batch</td><td>32</td></tr><tr><td colspan="2">Sous-module compétences</td></tr><tr><td>Couche 1</td><td>ReLU, dim. 200</td></tr><tr><td>Embedding</td><td>tanh, size = 100</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001</td></tr><tr><td>Epochs</td><td>100</td></tr><tr><td>Taille de batch</td><td>32</td></tr><tr><td colspan="2">Module "général"</td></tr><tr><td>Couche 1</td><td>ReLU, dim. 500</td></tr><tr><td>Embedding</td><td>tanh, dim. 200</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001</td></tr><tr><td>Epochs</td><td>100</td></tr><tr><td>Taille de batch</td><td>256</td></tr><tr><td colspan="2">Apprentissage à chaud</td></tr><tr><td>Structure bloc-diagonale</td><td>Oui</td></tr><tr><td>Epochs</td><td>10 / 25</td></tr><tr><td>Algorithme d'apprentissage</td><td>Adam</td></tr><tr><td>Taux d'apprentissage</td><td>0.0001 / 0.00001</td></tr><tr><td>Taille de batch</td><td>256</td></tr></tbody></table>

<figure><img src="image_54.png" /><figcaption>(a) XGB sur le jeu de données JOB</figcaption></figure>

<figure><img src="image_55.png" /><figcaption>(b) NN sur le jeu de données JOB</figcaption></figure>
# Segmentation de phases de dialogue dans des retranscriptions de
conversations de centres d'appels

Guillaume Dubuisson Duplessis, Manon Richard, Anne-Laure Guénet

EDF Commerce, Direction des Systèmes d'Information et du Numérique (DSIN),
CSC datascience & IA, 420 rue Estienne d'Orves, 92700 Colombes

{guillaume.dubuisson-duplessis, anne-laure.guenet}@edf.fr

## Résumé

La segmentation de phases de dialogue dans les retranscriptions de conversations de centres d'appels est cruciale pour leur exploitation opérationnelle. Cet article présente une approche d'apprentissage automatique supervisée qui nécessite une charge d'annotation manuelle raisonnable pour la segmentation. Cette approche est basée sur une ingénierie des caractéristiques qui prend en compte la nature conversationnelle des données. Les résultats de l'étude fournissent des enseignements clés et amènent une discussion sur la définition même des phases de dialogue.

## Mots-clés

TALN, segmentation de phase de dialogue, retranscription

## Abstract

The task of dialogue phase segmentation in call center conversation transcriptions is a crucial step for operational purposes. This research presents a supervised machine learning approach that requires a reasonable amount of manual annotation for segmentation and is based on feature engineering that takes into account the conversational nature of the data. The study describes key insights, including a discussion on the very definition of dialogue phases.

## Keywords

NLP, dialogue segmentation, retranscription

# 1 Introduction

Les appels téléphoniques représentent la majeure partie des contacts de la relation client sur le marché des clients particuliers d'un acteur comme « Électricité de France » (EDF). Les retranscriptions automatiques peuvent nourrir de nombreux cas d'usage [2] comme, par exemple, l'optimisation des appels (aide à la professionnalisation, optimisation du discours des conseillers, optimisation des temps de traitements) et la vérification de la qualité des conversations en fonction de standards établis.

L'exploitation des retranscriptions de conversations de centres d'appels à des fins opérationnelles se fonde généralement sur une tâche clé : la segmentation en phases de dialogue. Le Tableau 1 présente un exemple d'enchaînement de deux phases de dialogue dans un appel de mise

<table><caption>TABLE 1 – Un exemple de segmentation de phases de dialogue dans des retranscriptions d'appel téléphonique illustrant l'enchaînement de la phase de signature électronique et la phase de date de mise en service. Il contient sept unités inter-pausales (UIP). CC=« conseiller client », C=« client ».</caption><tr><td>CC :</td><td>1</td><td>oui d'accord vous pouvez vous connecter sur votre boîte mail on va créer ensemble votre espace client</td></tr><tr><td></td><td>2</td><td>on va faire une signature dématérialiser de vos contrats donc pas besoin d'imprimer et de scanner d'accord</td></tr><tr><td>C :</td><td>3</td><td>oui</td></tr><tr><td>CC :</td><td>4</td><td>quand tout sera signé je pourrai vous envoyer les documents pour votre bailleur d'accord</td></tr><tr><td>C :</td><td>5</td><td>d'accord ok</td></tr><tr><td>...</td><td></td><td>...</td></tr><tr><td>CC :</td><td>6</td><td>ensuite pour la date de mise en service</td></tr><tr><td>C :</td><td>7</td><td>oui j'aurais voulu savoir si c'est possible d'avoir l'électricité dès jeudi</td></tr></table>

en service. La tâche de segmentation vise à reconstruire automatiquement les phases de dialogue à partir des retranscriptions. Un dialogue est un objet structuré [4] impliquant des structures locales comme la paire adjacente [11] et des structures plus étendues comme la structure dite « intentionnelle » liée à la tâche sous-jacente [6]. L'expression « phase de dialogue » peut référer à ces structures plus ou moins étendues. Dans ces travaux, nous nous focalisons sur des dialogues orientés par une tâche sous-jacente de mise en service d'un contrat de fourniture d'énergie. Par phase de dialogue, nous référons aux étapes suivies par le conseiller pour mener à bien une mise en service. Schématiquement, les appels suivent une structure enchaînant les étapes suivantes : salutations, description de la demande, description du logement, localisation du logement, choix des offres et services, mise en place du paiement, signature électronique des contrats, rendez-vous technicien et clôture de l'appel. Ces travaux se focalisent sur l'extraction de la phase de signature électronique des contrats à des fins analytiques en vue de mieux connaître celle-ci (temps passé, sujets abordés par le conseiller et le client) et d'identifier des leviers d'op-
# Segmentation de phases de dialogue dans des retranscriptions de
conversations de centres d'appels

Guillaume Dubuisson Duplessis, Manon Richard, Anne-Laure Guénet

EDF Commerce, Direction des Systèmes d'Information et du Numérique (DSIN),
CSC datascience & IA, 420 rue Estienne d'Orves, 92700 Colombes

{guillaume.dubuisson-duplessis, anne-laure.guenet}@edf.fr

## Résumé

La segmentation de phases de dialogue dans les retranscriptions de conversations de centres d'appels est cruciale pour leur exploitation opérationnelle. Cet article présente une approche d'apprentissage automatique supervisée qui nécessite une charge d'annotation manuelle raisonnable pour la segmentation. Cette approche est basée sur une ingénierie des caractéristiques qui prend en compte la nature conversationnelle des données. Les résultats de l'étude fournissent des enseignements clés et amènent une discussion sur la définition même des phases de dialogue.

## Mots-clés

TALN, segmentation de phase de dialogue, retranscription

## Abstract

The task of dialogue phase segmentation in call center conversation transcriptions is a crucial step for operational purposes. This research presents a supervised machine learning approach that requires a reasonable amount of manual annotation for segmentation and is based on feature engineering that takes into account the conversational nature of the data. The study describes key insights, including a discussion on the very definition of dialogue phases.

## Keywords

NLP, dialogue segmentation, retranscription

# 1 Introduction

Les appels téléphoniques représentent la majeure partie des contacts de la relation client sur le marché des clients particuliers d'un acteur comme « Électricité de France » (EDF). Les retranscriptions automatiques peuvent nourrir de nombreux cas d'usage [2] comme, par exemple, l'optimisation des appels (aide à la professionnalisation, optimisation du discours des conseillers, optimisation des temps de traitements) et la vérification de la qualité des conversations en fonction de standards établis.

L'exploitation des retranscriptions de conversations de centres d'appels à des fins opérationnelles se fonde généralement sur une tâche clé : la segmentation en phases de dialogue. Le Tableau 1 présente un exemple d'enchaînement de deux phases de dialogue dans un appel de mise

<table><caption>TABLE 1 – Un exemple de segmentation de phases de dialogue dans des retranscriptions d'appel téléphonique illustrant l'enchaînement de la phase de signature électronique et la phase de date de mise en service. Il contient sept unités inter-pausales (UIP). CC=« conseiller client », C=« client ».</caption><tr><td>CC :</td><td>1</td><td>oui d'accord vous pouvez vous connecter sur votre boîte mail on va créer ensemble votre espace client</td></tr><tr><td></td><td>2</td><td>on va faire une signature dématérialiser de vos contrats donc pas besoin d'imprimer et de scanner d'accord</td></tr><tr><td>C :</td><td>3</td><td>oui</td></tr><tr><td>CC :</td><td>4</td><td>quand tout sera signé je pourrai vous envoyer les documents pour votre bailleur d'accord</td></tr><tr><td>C :</td><td>5</td><td>d'accord ok</td></tr><tr><td>...</td><td></td><td>...</td></tr><tr><td>CC :</td><td>6</td><td>ensuite pour la date de mise en service</td></tr><tr><td>C :</td><td>7</td><td>oui j'aurais voulu savoir si c'est possible d'avoir l'électricité dès jeudi</td></tr></table>

en service. La tâche de segmentation vise à reconstruire automatiquement les phases de dialogue à partir des retranscriptions. Un dialogue est un objet structuré [4] impliquant des structures locales comme la paire adjacente [11] et des structures plus étendues comme la structure dite « intentionnelle » liée à la tâche sous-jacente [6]. L'expression « phase de dialogue » peut référer à ces structures plus ou moins étendues. Dans ces travaux, nous nous focalisons sur des dialogues orientés par une tâche sous-jacente de mise en service d'un contrat de fourniture d'énergie. Par phase de dialogue, nous référons aux étapes suivies par le conseiller pour mener à bien une mise en service. Schématiquement, les appels suivent une structure enchaînant les étapes suivantes : salutations, description de la demande, description du logement, localisation du logement, choix des offres et services, mise en place du paiement, signature électronique des contrats, rendez-vous technicien et clôture de l'appel. Ces travaux se focalisent sur l'extraction de la phase de signature électronique des contrats à des fins analytiques en vue de mieux connaître celle-ci (temps passé, sujets abordés par le conseiller et le client) et d'identifier des leviers d'op-
timisation via l'analyse des phases anormalement longues. Les contributions de ces travaux sont multiples. Tout d'abord, nous nous intéressons à la tâche de segmentation de retranscriptions d'appels, peu traitée par manque de corpus disponible mais pourtant clé pour l'exploitation de ces données riches [2, 12]. Ensuite, nous présentons une approche d'apprentissage automatique supervisée opérationnelle nécessitant une charge d'annotation manuelle raisonnable. Elle est fondée sur une ingénierie des caractéristiques prenant en compte la nature conversationnelle des données. Enfin, nous présentons les principaux enseignements parmi lesquels une discussion sur la définition même des phases de dialogue.

La suite de l'article se découpe en trois parties. La Section 2 pointe les travaux connexes les plus saillants. La Section 3 forme le cœur de l'article. Elle présente l'approche proposée pour la segmentation de phases de dialogue, les données d'apprentissage utilisées, les principales expérimentations réalisées et discute les résultats obtenus. Enfin, la Section 4 clôt cet article en soulignant les principales conclusions et en identifiant quelques perspectives prometteuses.

## 2 Travaux connexes

La segmentation en phases de dialogue de retranscriptions de conversations de centres d'appels est une tâche clé permettant l'exploitation des retranscriptions à de nombreuses fins opérationnelles [2]. Compte-tenu du coût important en termes d'annotation de données et de l'indisponibilité de données visant cette tâche, la plupart des approches de segmentation de phases de dialogue se base sur une approche non-supervisée fondée sur une hypothèse de cohérence lexicale et sémantique [7, 1]. Ces approches ont des performances plutôt modestes et limitées pour un usage opérationnel visant à calculer des indicateurs précis sur des phases. Des travaux récents visent à améliorer les performances de ces approches non-supervisées en apprenant automatiquement des modèles évaluant la cohérence d'une paire d'énoncés [12]. Ces travaux combinent les apports de l'apprentissage par transfert via un modèle BERT [3] à la relative facilité de construction d'un corpus d'apprentissage pour entraîner un modèle évaluant la cohérence d'une paire d'énoncés. Nos travaux se positionnent dans un contexte opérationnel de minimisation de l'utilisation de la donnée. Ils se fondent sur une tâche de classification de texte employant des caractéristiques conversationnelles hétérogènes permettant un niveau de performance satisfaisant.

# 3 Approche proposée

## 3.1 Vision globale

Afin de détecter une phase dans un appel, la retranscription n'est pas traitée comme un bloc, mais est découpée en unité inter-pausales (UIP). Une UIP est une unité de parole ne contenant pas de pause et provenant d'un seul interlocuteur (cf. Tableau 1). Une retranscription est donc découpée en une multitude d'UIP. La tâche revient alors à une classification binaire : une UIP appartient-elle ou non à la phase d'intérêt ? (cf. Figure 1) Ce découpage permet d'avoir une plus

<figure><img src="image_56.png" /><figcaption>FIGURE 1 – Reformulation du problème de segmentation de phases de dialogue en une tâche de classification au niveau des unités inter-pausales (UIP).</figcaption></figure>

grande volumétrie pour la modélisation. Une fois la classification réalisée, chaque UIP a une prédiction – dans ou hors de la phase – mais il peut parfois manquer de continuité dans la prédiction. Il est alors nécessaire de reconstruire la phase, par exemple en exploitant la densité de prédiction.

## 3.2 Description du corpus d'apprentissage

Le corpus est composé de 700 retranscriptions d'appels téléphoniques récoltées dans le cadre d'appels de mise en service. Dans ces données, un appel a une durée moyenne de 23min. Les retranscriptions sont donc de taille conséquente : en moyenne un appel comporte 960 UIP. En vertu du règlement général sur la protection des données (RGPD), les retranscriptions ont été désidentifiées et ne comportent aucune donnée à caractère personnel telles que des noms, prénoms, adresses, numéros [5]. Les données à caractère personnel sont substituées par le type de l'entité (e.g., "je suis monsieur [person] je vous appelle pour mon logement situé à [localisation]"). Les retranscriptions ne font apparaître aucune ponctuation et peuvent comporter des erreurs de retranscription.

Afin de détecter les phases de signature électronique dans les appels, une annotation des retranscriptions a été réalisée sur les 700 retranscriptions par deux personnes, ce qui représente une charge opérationnelle acceptable dans le cadre du projet. L'annotation a consisté à noter le début et la fin de la phase. Le corpus a ensuite été découpé en 3 sous-échantillons : un échantillon *train* composé de 420 appels (257K UIP) qui représente 60% des annotations, un échantillon *dev* (20%) composé de 140 appels (85K UIP) et un échantillon *test* (20%) de 140 appels (90K UIP).

## 3.3 Expérimentations autour de la classification des unités inter-pausales

### 3.3.1 Métriques d'évaluation considérées

La phase de signature électronique ne représente qu'une phase mineure dans une retranscription d'appel. L'échantillon est déséquilibré : 15% des UIP font partie de cette phase. Afin de mesurer les performances du modèle de classification, nous avons utilisé la métrique MCC (Matthews Correlation Coefficient) afin de prendre en compte ce déséquilibre. D'autres métriques ont également été visualisées à titre indicatif : la précision, le rappel et l'accuracy.

### 3.3.2 Choix de modélisation

**Caractéristiques considérées** Afin de prédire si une UIP fait partie de la phase considérée ou non, plusieurs variables ont été intégrées dans le modèle. Certaines décrivent direc-
timisation via l'analyse des phases anormalement longues. Les contributions de ces travaux sont multiples. Tout d'abord, nous nous intéressons à la tâche de segmentation de retranscriptions d'appels, peu traitée par manque de corpus disponible mais pourtant clé pour l'exploitation de ces données riches [2, 12]. Ensuite, nous présentons une approche d'apprentissage automatique supervisée opérationnelle nécessitant une charge d'annotation manuelle raisonnable. Elle est fondée sur une ingénierie des caractéristiques prenant en compte la nature conversationnelle des données. Enfin, nous présentons les principaux enseignements parmi lesquels une discussion sur la définition même des phases de dialogue.

La suite de l'article se découpe en trois parties. La Section 2 pointe les travaux connexes les plus saillants. La Section 3 forme le cœur de l'article. Elle présente l'approche proposée pour la segmentation de phases de dialogue, les données d'apprentissage utilisées, les principales expérimentations réalisées et discute les résultats obtenus. Enfin, la Section 4 clôt cet article en soulignant les principales conclusions et en identifiant quelques perspectives prometteuses.

## 2 Travaux connexes

La segmentation en phases de dialogue de retranscriptions de conversations de centres d'appels est une tâche clé permettant l'exploitation des retranscriptions à de nombreuses fins opérationnelles [2]. Compte-tenu du coût important en termes d'annotation de données et de l'indisponibilité de données visant cette tâche, la plupart des approches de segmentation de phases de dialogue se base sur une approche non-supervisée fondée sur une hypothèse de cohérence lexicale et sémantique [7, 1]. Ces approches ont des performances plutôt modestes et limitées pour un usage opérationnel visant à calculer des indicateurs précis sur des phases. Des travaux récents visent à améliorer les performances de ces approches non-supervisées en apprenant automatiquement des modèles évaluant la cohérence d'une paire d'énoncés [12]. Ces travaux combinent les apports de l'apprentissage par transfert via un modèle BERT [3] à la relative facilité de construction d'un corpus d'apprentissage pour entraîner un modèle évaluant la cohérence d'une paire d'énoncés. Nos travaux se positionnent dans un contexte opérationnel de minimisation de l'utilisation de la donnée. Ils se fondent sur une tâche de classification de texte employant des caractéristiques conversationnelles hétérogènes permettant un niveau de performance satisfaisant.

# 3 Approche proposée

## 3.1 Vision globale

Afin de détecter une phase dans un appel, la retranscription n'est pas traitée comme un bloc, mais est découpée en unité inter-pausales (UIP). Une UIP est une unité de parole ne contenant pas de pause et provenant d'un seul interlocuteur (cf. Tableau 1). Une retranscription est donc découpée en une multitude d'UIP. La tâche revient alors à une classification binaire : une UIP appartient-elle ou non à la phase d'intérêt ? (cf. Figure 1) Ce découpage permet d'avoir une plus

<figure><img src="image_56.png" /><figcaption>FIGURE 1 – Reformulation du problème de segmentation de phases de dialogue en une tâche de classification au niveau des unités inter-pausales (UIP).</figcaption></figure>

grande volumétrie pour la modélisation. Une fois la classification réalisée, chaque UIP a une prédiction – dans ou hors de la phase – mais il peut parfois manquer de continuité dans la prédiction. Il est alors nécessaire de reconstruire la phase, par exemple en exploitant la densité de prédiction.

## 3.2 Description du corpus d'apprentissage

Le corpus est composé de 700 retranscriptions d'appels téléphoniques récoltées dans le cadre d'appels de mise en service. Dans ces données, un appel a une durée moyenne de 23min. Les retranscriptions sont donc de taille conséquente : en moyenne un appel comporte 960 UIP. En vertu du règlement général sur la protection des données (RGPD), les retranscriptions ont été désidentifiées et ne comportent aucune donnée à caractère personnel telles que des noms, prénoms, adresses, numéros [5]. Les données à caractère personnel sont substituées par le type de l'entité (e.g., "je suis monsieur [person] je vous appelle pour mon logement situé à [localisation]"). Les retranscriptions ne font apparaître aucune ponctuation et peuvent comporter des erreurs de retranscription.

Afin de détecter les phases de signature électronique dans les appels, une annotation des retranscriptions a été réalisée sur les 700 retranscriptions par deux personnes, ce qui représente une charge opérationnelle acceptable dans le cadre du projet. L'annotation a consisté à noter le début et la fin de la phase. Le corpus a ensuite été découpé en 3 sous-échantillons : un échantillon *train* composé de 420 appels (257K UIP) qui représente 60% des annotations, un échantillon *dev* (20%) composé de 140 appels (85K UIP) et un échantillon *test* (20%) de 140 appels (90K UIP).

## 3.3 Expérimentations autour de la classification des unités inter-pausales

### 3.3.1 Métriques d'évaluation considérées

La phase de signature électronique ne représente qu'une phase mineure dans une retranscription d'appel. L'échantillon est déséquilibré : 15% des UIP font partie de cette phase. Afin de mesurer les performances du modèle de classification, nous avons utilisé la métrique MCC (*Matthews Correlation Coefficient*) afin de prendre en compte ce déséquilibre. D'autres métriques ont également été visualisées à titre indicatif : la précision, le rappel et l'accuracy.

### 3.3.2 Choix de modélisation

**Caractéristiques considérées** Afin de prédire si une UIP fait partie de la phase considérée ou non, plusieurs variables ont été intégrées dans le modèle. Certaines décrivent direc-
tement l'UIP comme le texte de l'UIP, l'interlocuteur de l'UIP (soit « client » soit « conseiller »), la durée de l'UIP, la position de l'UIP dans l'appel (entre 0 – début – et 1 – fin – de la conversation). D'autres concernent le contexte dans lequel l'UIP a été mentionnée. Dans une fenêtre de *T* UIP avant et après – taille à définir – la durée des blancs (qui peut marquer un changement de phase dans le dialogue) ainsi que les UIP avant et après (ce qui a été dit par le client et conseiller dans une fenêtre de *T* UIP avant ou après) sont intégrées en variables supplémentaires dans le modèle. Ainsi, six caractéristiques structurées (interlocuteur, durée, position dans l'appel, durée des blancs avant et après l'UIP) et deux caractéristiques non-structurées (texte de l'UIP et contexte avant/après) sont intégrées en variables explicatives du modèle.

**Vectorisations considérées pour les données texte** À partir de l'ensemble de ces variables explicatives, nous avons construit un modèle de classification binaire. Afin de traiter les données textuelles, nous avons testé différentes vectorisations. Dans un premier temps, nous avons privilégié un TF-IDF, puis nous avons réduit le nombre de variables du TF-IDF en le combinant à une SVD (*Singular Value Decomposition*). Enfin, nous avons testé GloVe [10] en dimension 100, modèle pré-entraîné sur des UIP de retranscriptions. La représentation au niveau du document est obtenue par mean ou max pooling. Les données ont certaines spécificités : 50% des UIP ont entre 1-2 tokens uniquement et le mot le plus utilisé apparaît uniquement dans 19% des UIP contrairement à un corpus commun où le mot le plus utilisé comme un mot vide apparaît généralement dans plus de 95% des documents. Les hyperparamètres du TF-IDF sont à adapter à cette particularité. En outre, nous n'avons pas utilisé de modèles comme CamemBERT [9] ou FlaubERT [8] pour des raisons de tractabilité sur des conversations qui sont longues. De plus, les résultats rapportés pour le modèle CamemBERT indiquent des performances moindres sur des données de retranscription [9].

**Classifieurs considérés** Nous avons considéré plusieurs classificateurs : une régression logistique, un SVM (*Support Vector Machine*) avec kernel linéaire et un perceptron multi-couche (MLP) non-linéaire avec une couche cachée de taille 100. Les conversations étant des documents de taille très grande, les classificateurs de type réseau de neurons récurrents n'ont pas été testés pour des raisons de temps d'entraînement. Au cours de nos essais de modélisation, le perceptron multi-couche a produit de meilleures performances que la régression logistique et le SVM avec kernel linéaire. Dans la suite, nous ne reportons que les résultats basés sur les MLP.

## 3.4 Résultats

Un premier modèle *baseline* a été construit sans prise en compte du contexte de l'UIP. Il est représenté en première ligne du Tableau 2 et est le modèle qui a donné les meilleures performances sans le contexte. Plusieurs essais de modélisation successifs ont permis d'itérer et de constater quelle variable, quelle vectorisation, quel type de modèle impactent les résultats de la classification. Il en ressort

<table><caption>TABLE 2 – Performances des modèles en fonction de plusieurs approches de vectorisation du contexte et de la taille du contexte considérée en nombre d'UIP avant et après. *T* = taille du contexte. *N* = nombre de caractéristiques.</caption><thead><tr><th>Vectorisation</th><th><em>T</em></th><th><em>N</em></th><th>MCC CV5</th><th>MCC dev</th></tr></thead><tbody><tr><td>–</td><td>–</td><td>106</td><td>0.454</td><td>0.461</td></tr><tr><td>TF-IDF + SVD</td><td>3</td><td>306</td><td>0.631</td><td>0.656</td></tr><tr><td>GloVe</td><td>3</td><td>206</td><td>0.667</td><td>0.704</td></tr><tr><td>TF-IDF + SVD</td><td>6</td><td>306</td><td>0.7</td><td><strong>0.736</strong></td></tr><tr><td>GloVe</td><td>6</td><td>206</td><td><strong>0.719</strong></td><td>0.732</td></tr></tbody></table>

tout d'abord que la prise en compte des variables structurées en plus du texte – telles que la position de l'UIP dans la conversation – augmentent sensiblement la performance du modèle. La vectorisation de l'UIP basée sur le modèle GloVe préentraîné fonctionne mieux qu'une vectorisation basée sur TF-IDF et d'autant plus avec du *mean pooling*.

Une fois la *baseline* fixée, le contexte a été rajouté dans la modélisation. Les résultats sont retranscrits dans le tableau 2 et permettent de dégager des enseignements clés. Tout d'abord, le contexte apporte énormément d'information au modèle, en particulier une fenêtre *T* de taille 6. A noter que différencier le contexte avant du contexte après ne nous a pas apporté de gains de performance. De nouveau, la vectorisation du contexte basée sur notre modèle GloVe préentraîné fonctionne mieux qu'une vectorisation basée sur TF-IDF et a l'avantage de limiter le nombre de caractéristiques nécessaires pour une bonne classification. Nous avons également constaté que les UIP sont moins bien prédites lorsqu'elles sont au bord de la phase de signature électronique (mais la vérité terrain contient aussi des erreurs sur les bords).

Pour les besoins opérationnels de notre projet, nous avons retenu le modèle basé sur une vectorisation GloVe du contexte de taille 6 (dernière ligne du Tableau 2). Nous avons vérifié la bonne généralisation de ce modèle sur la partie "test" de notre corpus (MCC=0.736 / accuracy=0.94).

## 3.5 Reconstruction des phases de dialogue

La reconstruction de la phase de dialogue se fonde sur les prédictions d'appartenance à la phase au niveau des UIP. L'algorithme de reconstruction utilise une fenêtre glissante qui considère le nombre d'UIP prédites comme appartenant à la phase dans la fenêtre pour déterminer la phase de dialogue. Cela permet d'éliminer des UIP isolées faussement détectées comme faisant partie de la phase de signature électronique. Les paramètres qui nous ont donné les résultats les plus satisfaisants sont une taille de fenêtre de 10 UIP et une nombre minimum de voisins prédits dans la phase à 4. Nous avons mesuré la performance de la reconstruction de phase via l'indice de Jaccard (correspondant au calcul de l'intersection entre la phase prédite divisée par l'union de la phase de référence avec celle prédite). L'indice de Jaccard médian est de 0.73. 75% des appels ont un indice de Jaccard entre 0.5 et 0.87.
tement l'UIP comme le texte de l'UIP, l'interlocuteur de l'UIP (soit « client » soit « conseiller »), la durée de l'UIP, la position de l'UIP dans l'appel (entre 0 – début – et 1 – fin – de la conversation). D'autres concernent le contexte dans lequel l'UIP a été mentionnée. Dans une fenêtre de *T* UIP avant et après – taille à définir – la durée des blancs (qui peut marquer un changement de phase dans le dialogue) ainsi que les UIP avant et après (ce qui a été dit par le client et conseiller dans une fenêtre de *T* UIP avant ou après) sont intégrées en variables supplémentaires dans le modèle. Ainsi, six caractéristiques structurées (interlocuteur, durée, position dans l'appel, durée des blancs avant et après l'UIP) et deux caractéristiques non-structurées (texte de l'UIP et contexte avant/après) sont intégrées en variables explicatives du modèle.

**Vectorisations considérées pour les données texte** À partir de l'ensemble de ces variables explicatives, nous avons construit un modèle de classification binaire. Afin de traiter les données textuelles, nous avons testé différentes vectorisations. Dans un premier temps, nous avons privilégié un TF-IDF, puis nous avons réduit le nombre de variables du TF-IDF en le combinant à une SVD (Singular Value Decomposition). Enfin, nous avons testé GloVe [10] en dimension 100, modèle pré-entraîné sur des UIP de retranscriptions. La représentation au niveau du document est obtenue par mean ou max pooling. Les données ont certaines spécificités : 50% des UIP ont entre 1-2 tokens uniquement et le mot le plus utilisé apparaît uniquement dans 19% des UIP contrairement à un corpus commun où le mot le plus utilisé comme un mot vide apparaît généralement dans plus de 95% des documents. Les hyperparamètres du TF-IDF sont à adapter à cette particularité. En outre, nous n'avons pas utilisé de modèles comme CamemBERT [9] ou Flaubert [8] pour des raisons de tractabilité sur des conversations qui sont longues. De plus, les résultats rapportés pour le modèle CamemBERT indiquent des performances moindres sur des données de retranscription [9].

**Classifieurs considérés** Nous avons considéré plusieurs classificateurs : une régression logistique, un SVM (Support Vector Machine) avec kernel linéaire et un perceptron multi-couche (MLP) non-linéaire avec une couche cachée de taille 100. Les conversations étant des documents de taille très grande, les classificateurs de type réseau de neurons récurrents n'ont pas été testés pour des raisons de temps d'entraînement. Au cours de nos essais de modélisation, le perceptron multi-couche a produit de meilleures performances que la régression logistique et le SVM avec kernel linéaire. Dans la suite, nous ne reportons que les résultats basés sur les MLP.

## 3.4 Résultats

Un premier modèle *baseline* a été construit sans prise en compte du contexte de l'UIP. Il est représenté en première ligne du Tableau 2 et est le modèle qui a donné les meilleures performances sans le contexte. Plusieurs essais de modélisation successifs ont permis d'itérer et de constater quelle variable, quelle vectorisation, quel type de modèle impactent les résultats de la classification. Il en ressort

<table><caption>TABLE 2 – Performances des modèles en fonction de plusieurs approches de vectorisation du contexte et de la taille du contexte considérée en nombre d'UIP avant et après. *T* = taille du contexte. *N* = nombre de caractéristiques.</caption><thead><tr><th>Vectorisation</th><th><em>T</em></th><th><em>N</em></th><th>MCC CV5</th><th>MCC dev</th></tr></thead><tbody><tr><td>–</td><td>–</td><td>106</td><td>0.454</td><td>0.461</td></tr><tr><td>TF-IDF + SVD</td><td>3</td><td>306</td><td>0.631</td><td>0.656</td></tr><tr><td>GloVe</td><td>3</td><td>206</td><td>0.667</td><td>0.704</td></tr><tr><td>TF-IDF + SVD</td><td>6</td><td>306</td><td>0.7</td><td><strong>0.736</strong></td></tr><tr><td>GloVe</td><td>6</td><td>206</td><td><strong>0.719</strong></td><td>0.732</td></tr></tbody></table>

tout d'abord que la prise en compte des variables structurées en plus du texte – telles que la position de l'UIP dans la conversation – augmentent sensiblement la performance du modèle. La vectorisation de l'UIP basée sur le modèle GloVe préentraîné fonctionne mieux qu'une vectorisation basée sur TF-IDF et d'autant plus avec du mean pooling.

Une fois la *baseline* fixée, le contexte a été rajouté dans la modélisation. Les résultats sont retranscrits dans le tableau 2 et permettent de dégager des enseignements clés. Tout d'abord, le contexte apporte énormément d'information au modèle, en particulier une fenêtre *T* de taille 6. A noter que différencier le contexte avant du contexte après ne nous a pas apporté de gains de performance. De nouveau, la vectorisation du contexte basée sur notre modèle GloVe préentraîné fonctionne mieux qu'une vectorisation basée sur TF-IDF et a l'avantage de limiter le nombre de caractéristiques nécessaires pour une bonne classification. Nous avons également constaté que les UIP sont moins bien prédites lorsqu'elles sont au bord de la phase de signature électronique (mais la vérité terrain contient aussi des erreurs sur les bords).

Pour les besoins opérationnels de notre projet, nous avons retenu le modèle basé sur une vectorisation GloVe du contexte de taille 6 (dernière ligne du Tableau 2). Nous avons vérifié la bonne généralisation de ce modèle sur la partie "test" de notre corpus (MCC=0.736 / accuracy=0.94).

## 3.5 Reconstruction des phases de dialogue

La reconstruction de la phase de dialogue se fonde sur les prédictions d'appartenance à la phase au niveau des UIP. L'algorithme de reconstruction utilise une fenêtre glissante qui considère le nombre d'UIP prédites comme appartenant à la phase dans la fenêtre pour déterminer la phase de dialogue. Cela permet d'éliminer des UIP isolées faussement détectées comme faisant partie de la phase de signature électronique. Les paramètres qui nous ont donné les résultats les plus satisfaisants sont une taille de fenêtre de 10 UIP et une nombre minimum de voisins prédits dans la phase à 4. Nous avons mesuré la performance de la reconstruction de phase via l'indice de Jaccard (correspondant au calcul de l'intersection entre la phase prédite divisée par l'union de la phase de référence avec celle prédite). L'indice de Jaccard médian est de 0.73. 75% des appels ont un indice de Jaccard entre 0.5 et 0.87.
## 3.6 Discussion

Cette approche opérationnelle a la particularité de découper le problème en deux tâches (classification des UIP, reconstruction de la phase). Avec un nombre restreint d'annotations, la modélisation a donné des résultats stables sur les échantillons de *dev* et *test* via la prise en compte de caractéristiques conversationnelles hétérogènes.

L'une des difficultés dans la segmentation de phase de dialogue et qui a pu complexifier la reconstruction des phases réside dans deux particularités inhérentes aux phases de dialogue. La première est la présence de sous-dialogues incidents qui peuvent s'immiscer au sein de la phase [4] (e.g., « ok attendez je voulais savoir si je suis sur le principe des heures creuses heures pleines »). La seconde est la présence de phases mêlées (e.g., « donc pendant que vous êtes en train de valider je vais en profiter pour vous donner les conseils en matière d'économie d'énergie »). Dans ces deux cas, la phase segmentée n'est plus unifiée, mais séparée en deux ou plusieurs sous-phases. Cela présente un défi aussi bien de formalisation de la tâche de segmentation que technique pour de futurs travaux.

## 4 Conclusion et perspectives

Cet article a présenté une approche par apprentissage automatique pour la segmentation d'une phase de dialogue dans de réelles retranscriptions d'appels en centres d'appels ; approche plus générique, rigoureuse, réplicable et maintenable qu'une conception de règles spécifiques. Cette approche supervisée se base sur un corpus d'apprentissage de petite taille et des caractéristiques conversationnelles adaptées à cette tâche. Ces travaux se sont limités à une méthode de reconstruction d'une phase très simple à partir des prédictions au niveau des UIP. Une suite directe vise à améliorer cette méthode de reconstruction de phases. Une autre direction est d'étudier l'adaptation des modèles d'apprentissage profond pour segmenter des phases dans des séquences d'UIP pouvant être très longues. Enfin, une direction intéressante est d'explorer l'opérationnalité d'approches nécessitant pas ou peu de supervision manuelle [12].

## Remerciements

Nous remercions chaleureusement toutes les personnes qui sont intervenues de près ou de loin sur ce projet : Gilles Pouëssel, Mélanie Cazes, Laura Rouhier, Sonia Audheon, Marie Hervé, François Raynaud.

## Références

[1] Laurent Bozzi, Philippe Suignard, and Claire Waast-Richard. Segmentation et classification non supervisée de conversations téléphoniques automatiquement retranscrites. In *Actes de la 16ème conférence sur le Traitement Automatique des Langues Naturelles. Articles courts*, pages 331–336, 2009.

[2] Chloé Clavel, Gilles Adda, Frederik Cailliau, Martine Garnier-Rizet, Ariane Cavet, Géraldine Chapuis, Sandrine Courcinous, Charlotte Danesi, Anne-Laure

Daquo, Myrtille Deldossi, et al. Spontaneous speech and opinion detection : mining call-centre transcripts. *Language resources and evaluation*, 47(4) :1089–1125, 2013.

[3] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT : Pre-training of deep bidirectional transformers for language understanding. In *Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics : Human Language Technologies*, pages 4171–4186, 2019.

[4] Guillaume Dubuisson Duplessis. Modèle de comportement communicatif conventionnel pour un agent en interaction avec des humains : Approche par jeux de dialogue. PhD thesis, INSA de Rouen, 2014.

[5] Guillaume Dubuisson Duplessis, Elliot Bartholme, Sofiane Kerroua, Mathilde Poulain, Ahès Roulier, and Anne-Laure Guénet. Désidentification de données texte produites dans un cadre de relation client. In *Actes de la 27ème conférence Traitement Automatique des Langues Naturelles (TALN) – démonstrations*, pages 10–13, 2020.

[6] Barbara J Grosz and Candace L Sidner. Attention, intentions, and the structure of discourse. *Computational linguistics*, 12(3) :175–204, 1986.

[7] Marti A. Hearst. Text tiling : Segmenting text into multi-paragraph subtopic passages. *Computational Linguistics*, 23(1) :33–64, 1997.

[8] Hang Le, Loïc Vial, Jibril Frej, Vincent Segonne, Maximin Coavoux, Benjamin Lecouteux, Alexandre Allauzen, Benoît Crabbé, Laurent Besacier, and Di-dier Schwab. Flaubert : Unsupervised language model pre-training for french. In *Proceedings of the 12th International Conference on Language Resources and Evaluation (LREC 2020)*, 2020.

[9] Louis Martin, Benjamin Muller, Pedro Javier Ortiz Suárez, Yoann Dupont, Laurent Romary, Éric Villemonte de la Clergerie, Djamé Seddah, and Benoît Sargot. Camembert : a tasty french language model. In *Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics*, 2020.

[10] Jeffrey Pennington, Richard Socher, and Christopher D. Manning. Glove : Global vectors for word representation. In *Empirical Methods in Natural Language Processing (EMNLP)*, pages 1532–1543, 2014.

[11] Emanuel A Schegloff and Harvey Sacks. Opening up closings. 1973.

[12] Linzi Xing and Giuseppe Carenini. Improving unsupervised dialogue topic segmentation with utterance-pair coherence scoring. In *Proceedings of the 22nd Annual Meeting of the Special Interest Group on Discourse and Dialogue*, pages 167–177, 2021.
## 3.6 Discussion

Cette approche opérationnelle a la particularité de découper le problème en deux tâches (classification des UIP, reconstruction de la phase). Avec un nombre restreint d'annotations, la modélisation a donné des résultats stables sur les échantillons de *dev* et *test* via la prise en compte de caractéristiques conversationnelles hétérogènes.

L'une des difficultés dans la segmentation de phase de dialogue et qui a pu complexifier la reconstruction des phases réside dans deux particularités inhérentes aux phases de dialogue. La première est la présence de sous-dialogues incidents qui peuvent s'immiscer au sein de la phase [4] (e.g., « ok attendez je voulais savoir si je suis sur le principe des heures creuses heures pleines »). La seconde est la présence de phases mêlées (e.g., « donc pendant que vous êtes en train de valider je vais en profiter pour vous donner les conseils en matière d'économie d'énergie »). Dans ces deux cas, la phase segmentée n'est plus unifiée, mais séparée en deux ou plusieurs sous-phases. Cela présente un défi aussi bien de formalisation de la tâche de segmentation que technique pour de futurs travaux.

## 4 Conclusion et perspectives

Cet article a présenté une approche par apprentissage automatique pour la segmentation d'une phase de dialogue dans de réelles retranscriptions d'appels en centres d'appels ; approche plus générique, rigoureuse, réplicable et maintenable qu'une conception de règles spécifiques. Cette approche supervisée se base sur un corpus d'apprentissage de petite taille et des caractéristiques conversationnelles adaptées à cette tâche. Ces travaux se sont limités à une méthode de reconstruction d'une phase très simple à partir des prédictions au niveau des UIP. Une suite directe vise à améliorer cette méthode de reconstruction de phases. Une autre direction est d'étudier l'adaptation des modèles d'apprentissage profond pour segmenter des phases dans des séquences d'UIP pouvant être très longues. Enfin, une direction intéressante est d'explorer l'opérationnalité d'approches nécessitant pas ou peu de supervision manuelle [12].

## Remerciements

Nous remercions chaleureusement toutes les personnes qui sont intervenues de près ou de loin sur ce projet : Gilles Pouëssel, Mélanie Cazes, Laura Rouhier, Sonia Audheon, Marie Hervé, François Raynaud.

## Références

[1] Laurent Bozzi, Philippe Suignard, and Claire Waast-Richard. Segmentation et classification non supervisée de conversations téléphoniques automatiquement retranscrites. In *Actes de la 16ème conférence sur le Traitement Automatique des Langues Naturelles. Articles courts*, pages 331–336, 2009.

[2] Chloé Clavel, Gilles Adda, Frederik Cailliau, Martine Garnier-Rizet, Ariane Cavet, Géraldine Chapuis, Sandrine Courcinous, Charlotte Danesi, Anne-Laure

Daquo, Myrtille Deldossi, et al. Spontaneous speech and opinion detection : mining call-centre transcripts. *Language resources and evaluation*, 47(4) :1089–1125, 2013.

[3] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT : Pre-training of deep bidirectional transformers for language understanding. In *Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics : Human Language Technologies*, pages 4171–4186, 2019.

[4] Guillaume Dubuisson Duplessis. Modèle de comportement communicatif conventionnel pour un agent en interaction avec des humains : Approche par jeux de dialogue. PhD thesis, INSA de Rouen, 2014.

[5] Guillaume Dubuisson Duplessis, Elliot Bartholme, Sofiane Kerroua, Mathilde Poulain, Ahès Roulier, and Anne-Laure Guénet. Désidentification de données texte produites dans un cadre de relation client. In *Actes de la 27ème conférence Traitement Automatique des Langues Naturelles (TALN) – démonstrations*, pages 10–13, 2020.

[6] Barbara J Grosz and Candace L Sidner. Attention, intentions, and the structure of discourse. *Computational linguistics*, 12(3) :175–204, 1986.

[7] Marti A. Hearst. Text tiling : Segmenting text into multi-paragraph subtopic passages. *Computational Linguistics*, 23(1) :33–64, 1997.

[8] Hang Le, Loïc Vial, Jibril Frej, Vincent Segonne, Maximin Coavoux, Benjamin Lecouteux, Alexandre Allauzen, Benoît Crabbé, Laurent Besacier, and Di-dier Schwab. Flaubert : Unsupervised language model pre-training for french. In *Proceedings of the 12th International Conference on Language Resources and Evaluation (LREC 2020)*, 2020.

[9] Louis Martin, Benjamin Muller, Pedro Javier Ortiz Suárez, Yoann Dupont, Laurent Romary, Éric Villemonte de la Clergerie, Djamé Seddah, and Benoît Sagot. Camembert : a tasty french language model. In *Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics*, 2020.

[10] Jeffrey Pennington, Richard Socher, and Christopher D. Manning. Glove : Global vectors for word representation. In *Empirical Methods in Natural Language Processing (EMNLP)*, pages 1532–1543, 2014.

[11] Emanuel A Schegloff and Harvey Sacks. Opening up closings. 1973.

[12] Linzi Xing and Giuseppe Carenini. Improving unsupervised dialogue topic segmentation with utterance-pair coherence scoring. In *Proceedings of the 22nd Annual Meeting of the Special Interest Group on Discourse and Dialogue*, pages 167–177, 2021.
# Démonstration : exploration sémantique de données texte de la relation client

Guillaume Dubuisson Duplessis, François Bullier, Anne-Laure Guénet

EDF Commerce, Direction des Systèmes d'Information et du Numérique (DSIN),
CSC datascience & IA, 420 rue Estienne d'Orves, 92700 Colombes

{guillaume.dubuisson-duplessis, anne-laure.guenet}@edf.fr

## Résumé

L'exploration des données texte est une tâche-clé non-supervisée préliminaire à l'exploitation de ces données dans les cas d'usage opérationnels. Cet article décrit l'outil *nemo* (« Neural sEMantic explOration ») récemment développé en interne à EDF Commerce pour servir nos besoins opérationnels et qui a déjà été utilisé dans une dizaine de cas d'usage. *nemo* facilite grandement l'exploration sémantique, rendant la tâche beaucoup plus aisée.

## Mots-clés

TALN, exploration de données texte, plongement vectoriel de documents

## Abstract

Text data exploration is a crucial unsupervised task that needs to be performed prior to utilizing the data for operational purposes. This article describes *nemo* (« Neural sEMantic explOration »), which has recently been developed internally at EDF Commerce to meet our operational needs and has already been used in around ten use cases. *nemo* enables semantic text data exploration, greatly facilitating the exploration task.

## Keywords

NLP, text data exploration, sentence embedding

## 1 Introduction

La relation client au sein d'EDF Commerce génère chaque mois des millions de données texte aussi bien de la part des clients (e.g., e-mails, réponses libres à des questionnaires de satisfaction) que de la part des conseillers (e.g., commentaires de contact). Ces données majoritairement en français sont riches. Elles offrent un large panel de structures allant d'expressions libres et spontanées à des formes contraintes comme des formulaires. Elles présentent également une grande diversité en ce qui concerne le respect de l'orthographe, de la syntaxe et du niveau de langue. Ces données sont utilisées pour répondre au mieux aux attentes de nos clients en suivant le cadre réglementaire du « règlement général sur la protection des données » (RGPD) [3]. En outre, elles sont exploitées dans de nombreux cas d'usage visant à optimiser la relation client (e.g., sur le canal e-mail [4]).

L'exploration des données texte est une tâche-clé non-supervisée préliminaire à l'exploitation de ces données dans les cas d'usage opérationnels. Cette exploration vise à mieux connaître les données en faisant ressortir les principaux sujets abordés dans un corpus. Elle permet la création de plans d'annotation pertinents en alignant le contenu des données texte aux besoins « métier » et le développement de solutions techniques basées sur l'apprentissage supervisé. Les techniques exploratoires font également partie intégrante de la boîte à outils de l'ingénieur de la donnée pour mener à bien ses projets. Par exemple, des techniques d'extraction de paraphrases se révèlent particulièrement utiles pour augmenter des données dans un contexte où l'annotation manuelle est coûteuse, ou pour aider à la modélisation linguistique. Cet article décrit l'outil *nemo* (« Neural sEMantic explOration ») récemment développé en interne à EDF Commerce pour servir nos besoins opérationnels et qui a déjà été utilisé dans une dizaine de cas d'usage. *nemo* permet une exploration sémantique des données texte plus efficace, améliorant considérablement la qualité des résultats obtenus. Il intègre des fonctionnalités utiles pour un cadre opérationnel et des modèles spécialisés sur les données de la relation client d'EDF Commerce.

La Section 2 positionne *nemo* par rapport aux travaux existants. La Section 3 expose les fonctionnalités centrales de *nemo* ainsi que ses avantages et limites. La Section 4 aborde la création de modèles spécialisés au domaine de la relation client d'EDF et souligne l'intérêt de ces modèles pour l'exploration de données dans un cadre opérationnel. Enfin, la Section 5 conclut cet article et indique les principales perspectives de ces travaux.

## 2 Travaux connexes

La découverte de structures et de thèmes dans des données texte est une tâche traitée de longue date par la communauté du traitement automatique de la langue naturelle. A cette fin, certaines approches sont bien établies parmi lesquelles la « Latent Dirichlet Allocation » (LDA) [1] et la méthode de Reinert popularisée par l'outil Iramuteq [12]. Ces approches sont fondamentalement limitées par leur dépendance à une représentation du texte sous forme de « sac de mots » qui échoue à capturer la richesse sémantique derrière les mots et *in fine* à représenter fidèlement un document.
# Démonstration : exploration sémantique de données texte de la relation client

Guillaume Dubuisson Duplessis, François Bullier, Anne-Laure Guénet

EDF Commerce, Direction des Systèmes d'Information et du Numérique (DSIN),
CSC datascience & IA, 420 rue Estienne d'Orves, 92700 Colombes

{guillaume.dubuisson-duplessis, anne-laure.guenet}@edf.fr

## Résumé

L'exploration des données texte est une tâche-clé non-supervisée préliminaire à l'exploitation de ces données dans les cas d'usage opérationnels. Cet article décrit l'outil *nemo* (« Neural sEMantic explOration ») récemment développé en interne à EDF Commerce pour servir nos besoins opérationnels et qui a déjà été utilisé dans une dizaine de cas d'usage. *nemo* facilite grandement l'exploration sémantique, rendant la tâche beaucoup plus aisée.

## Mots-clés

TALN, exploration de données texte, plongement vectoriel de documents

## Abstract

Text data exploration is a crucial unsupervised task that needs to be performed prior to utilizing the data for operational purposes. This article describes *nemo* (« Neural sEMantic explOration »), which has recently been developed internally at EDF Commerce to meet our operational needs and has already been used in around ten use cases. *nemo* enables semantic text data exploration, greatly facilitating the exploration task.

## Keywords

NLP, text data exploration, sentence embedding

## 1 Introduction

La relation client au sein d'EDF Commerce génère chaque mois des millions de données texte aussi bien de la part des clients (e.g., e-mails, réponses libres à des questionnaires de satisfaction) que de la part des conseillers (e.g., commentaires de contact). Ces données majoritairement en français sont riches. Elles offrent un large panel de structures allant d'expressions libres et spontanées à des formes contraintes comme des formulaires. Elles présentent également une grande diversité en ce qui concerne le respect de l'orthographe, de la syntaxe et du niveau de langue. Ces données sont utilisées pour répondre au mieux aux attentes de nos clients en suivant le cadre réglementaire du « règlement général sur la protection des données » (RGPD) [3]. En outre, elles sont exploitées dans de nombreux cas d'usage visant à optimiser la relation client (e.g., sur le canal e-mail [4]).

L'exploration des données texte est une tâche-clé non-supervisée préliminaire à l'exploitation de ces données dans les cas d'usage opérationnels. Cette exploration vise à mieux connaître les données en faisant ressortir les principaux sujets abordés dans un corpus. Elle permet la création de plans d'annotation pertinents en alignant le contenu des données texte aux besoins « métier » et le développement de solutions techniques basées sur l'apprentissage supervisé. Les techniques exploratoires font également partie intégrante de la boîte à outils de l'ingénieur de la donnée pour mener à bien ses projets. Par exemple, des techniques d'extraction de paraphrases se révèlent particulièrement utiles pour augmenter des données dans un contexte où l'annotation manuelle est coûteuse, ou pour aider à la modélisation linguistique. Cet article décrit l'outil *nemo* (« Neural sEMantic explOration ») récemment développé en interne à EDF Commerce pour servir nos besoins opérationnels et qui a déjà été utilisé dans une dizaine de cas d'usage. *nemo* permet une exploration sémantique des données texte plus efficace, améliorant considérablement la qualité des résultats obtenus. Il intègre des fonctionnalités utiles pour un cadre opérationnel et des modèles spécialisés sur les données de la relation client d'EDF Commerce.

La Section 2 positionne *nemo* par rapport aux travaux existants. La Section 3 expose les fonctionnalités centrales de *nemo* ainsi que ses avantages et limites. La Section 4 aborde la création de modèles spécialisés au domaine de la relation client d'EDF et souligne l'intérêt de ces modèles pour l'exploration de données dans un cadre opérationnel. Enfin, la Section 5 conclut cet article et indique les principales perspectives de ces travaux.

## 2 Travaux connexes

La découverte de structures et de thèmes dans des données texte est une tâche traitée de longue date par la communauté du traitement automatique de la langue naturelle. A cette fin, certaines approches sont bien établies parmi lesquelles la « Latent Dirichlet Allocation » (LDA) [1] et la méthode de Reinert popularisée par l'outil Iramuteq [12]. Ces approches sont fondamentalement limitées par leur dépendance à une représentation du texte sous forme de « sac de mots » qui échoue à capturer la richesse sémantique derrière les mots et *in fine* à représenter fidèlement un document.
ment texte. Pour faire face à cette limite, de nouvelles représentations du texte sémantiquement plus riches ont vu le jour sous la forme de plongements vectoriels de mots non-contextualisés (e.g., word2vec [10], GloVe [11]) et contextualisés fondés sur l'architecture transformer [2, 8, 7]. Sentence-BERT (SBERT) utilise ingénieusement ces derniers pour générer des plongements vectoriels de bonne qualité au niveau du document [13].

Notre outil nemo revisite l'exploration de texte à l'heure de ces représentations sémantiquement plus riches. Il exploite les modèles pré-entraînés fournis par SBERT et met à disposition de nos utilisateurs des modèles spécialisés sur le domaine de la relation client EDF. A l'heure où nous écrivons cet article, BERTopic [5] poursuit un objectif similaire à celui de nemo et évolue rapidement. nemo se distingue par ses fonctionnalités de descriptions d'un cluster (hiérarchie, extraction de mots-clés, extraction de prototypes), ses modèles spécialisés et son utilisation éprouvée au sein de nombreux cas d'usage opérationnels.

# 3 Présentation de l'outil nemo

nemo (« Neural sEMantic explOration ») est une librairie Python utilisable dans des notebooks Jupyter facilitant l'exploration sémantique des données texte à EDF. nemo propose sur une représentation dense des documents basée sur les sentence-embeddings [13] et permet d'encoder simplement un corpus via un appel de fonction. Par défaut, nemo propose l'utilisation du modèle paraphrase-multilingual-mpnet-base-v2¹.

## 3.1 Fonctionnalités proposées par nemo

### 3.1.1 Clustering

nemo fournit plusieurs approches de clustering à ses utilisateurs. Deux approches sont plus fréquemment utilisées. La première est HDBSCAN [9] qui fonde le clustering sur la densité des points. Cette approche a l'avantage d'extraire les clusters les plus denses mais elle exclut de nombreux documents. Lorsque l'exhaustivité est requise pour un cas d'usage, les utilisateurs se tournent le plus souvent vers un clustering hiérarchique plus classique. Cette approche a le double avantage d'inclure l'ensemble des documents et d'offrir une vision hiérachique des clusters via un dendrogramme.

### 3.1.2 Visualisation et exploration de données

nemo simplifie la découverte d'un corpus de données texte en offrant une visualisation interactive de documents regroupés par similarité sémantique. La Figure 1 montre une impression écran de la visualisation du clustering d'un corpus de données et de la possibilité de l'explorer interactivement. Chaque point représente un document tandis que chaque couleur représente un cluster préalablement calculé.

<figure><img src="image_57.png" /><figcaption>FIGURE 1 – Visualisation d'un corpus de données texte avec nemo. Le survol d'un point permet d'afficher le texte du document. Les couleurs représentent des clusters calculés avec HDBSCAN.</figcaption></figure>

### 3.1.3 Descriptions des clusters

nemo facilite la description des clusters sur deux niveaux. Le premier niveau est celui des mots-clés. nemo permet l'extraction des mots-clés pertinents d'un cluster via plusieurs approches au choix basées sur le TF-IDF, le cTF-IDF [5], le chi2 [12] ou encore via des graphes de mots proposés par la librairie gowpy<fnref n="2" />. Le second niveau est celui des documents. nemo permet l'extraction de parangons – les documents représentatifs – pour chaque cluster via l'algorithme ProtoDash [6].

### 3.1.4 Recherche sémantique

Enfin, nemo permet de rechercher des documents sémantiquement proches dans l'ensemble du corpus. Cette fonctionnalité est particulièrement pratique pour l'extraction de paraphrases afin d'augmenter des données ou pour aider la modélisation linguistique. Par exemple, la recherche de documents similaires à l'énoncé « je n'ai plus de courant » retourne des paraphrases telles que « on est en panne d'électricite » ou « j'ai tout sauf l'électricite ».

## 3.2 Discussion sur les fonctionnalités

nemo a l'avantage de fournir des résultats pertinents rapidement. Un gain de temps appréciable provient du prétraitement minimal des textes comparativement aux approches classiques. La pertinence des résultats est nettement améliorée dans nos cas d'usage grâce aux représentations sémantiques fournies par les sentence-embeddings.
Une limite concerne la taille des documents. Plus un document est grand, plus il y a de thèmes qui peuvent y être abordés. Il est souvent nécessaire de découper ces documents pour améliorer les résultats de l'analyse. Une autre contrainte concerne le fait que les modèles librement disponibles atteignent leur limite sur des domaines spécifiques comme la relation client d'EDF. Cela motive un travail de spécialisation de modèles.

<footnote n="1">1. La carte de ce modèle est disponible à cet URL : https://huggingface.co/sentence-transformers/ paraphrase-multilingual-mpnet-base-v2</footnote>

<footnote n="2">2. La librairie gowpy est disponible à cet URL : https://github.com/GuillaumeDD/gowpy</footnote>
ment texte. Pour faire face à cette limite, de nouvelles représentations du texte sémantiquement plus riches ont vu le jour sous la forme de plongements vectoriels de mots non-contextualisés (e.g., word2vec [10], GloVe [11]) et contextualisés fondés sur l'architecture transformer [2, 8, 7]. Sentence-BERT (SBERT) utilise ingénieusement ces derniers pour générer des plongements vectoriels de bonne qualité au niveau du document [13].

Notre outil nemo revisite l'exploration de texte à l'heure de ces représentations sémantiquement plus riches. Il exploite les modèles pré-entraînés fournis par SBERT et met à disposition de nos utilisateurs des modèles spécialisés sur le domaine de la relation client EDF. A l'heure où nous écrivons cet article, BERTopic [5] poursuit un objectif similaire à celui de nemo et évolue rapidement. nemo se distingue par ses fonctionnalités de descriptions d'un cluster (hiérarchie, extraction de mots-clés, extraction de prototypes), ses modèles spécialisés et son utilisation éprouvée au sein de nombreux cas d'usage opérationnels.

# 3 Présentation de l'outil nemo

nemo (« Neural sEMantic explOration ») est une librairie Python utilisable dans des notebooks Jupyter facilitant l'exploration sémantique des données texte à EDF. nemo propose sur une représentation dense des documents basée sur les sentence-embeddings [13] et permet d'encoder simplement un corpus via un appel de fonction. Par défaut, nemo propose l'utilisation du modèle paraphrase-multilingual-mpnet-base-v2¹.

## 3.1 Fonctionnalités proposées par nemo

### 3.1.1 Clustering

nemo fournit plusieurs approches de clustering à ses utilisateurs. Deux approches sont plus fréquemment utilisées. La première est HDBSCAN [9] qui fonde le clustering sur la densité des points. Cette approche a l'avantage d'extraire les clusters les plus denses mais elle exclut de nombreux documents. Lorsque l'exhaustivité est requise pour un cas d'usage, les utilisateurs se tournent le plus souvent vers un clustering hiérarchique plus classique. Cette approche a le double avantage d'inclure l'ensemble des documents et d'offrir une vision hiérachique des clusters via un dendrogramme.

### 3.1.2 Visualisation et exploration de données

nemo simplifie la découverte d'un corpus de données texte en offrant une visualisation interactive de documents regroupés par similarité sémantique. La Figure 1 montre une impression écran de la visualisation du clustering d'un corpus de données et de la possibilité de l'explorer interactivement. Chaque point représente un document tandis que chaque couleur représente un cluster préalablement calculé.

<figure><img src="image_57.png" /><figcaption>FIGURE 1 – Visualisation d'un corpus de données texte avec nemo. Le survol d'un point permet d'afficher le texte du document. Les couleurs représentent des clusters calculés avec HDBSCAN.</figcaption></figure>

### 3.1.3 Descriptions des clusters

nemo facilite la description des clusters sur deux niveaux. Le premier niveau est celui des mots-clés. nemo permet l'extraction des mots-clés pertinents d'un cluster via plusieurs approches au choix basées sur le TF-IDF, le cTF-IDF [5], le chi2 [12] ou encore via des graphes de mots proposés par la librairie gowpy<fnref n="2" />. Le second niveau est celui des documents. nemo permet l'extraction de parangons – les documents représentatifs – pour chaque cluster via l'algorithme ProtoDash [6].

### 3.1.4 Recherche sémantique

Enfin, nemo permet de rechercher des documents sémantiquement proches dans l'ensemble du corpus. Cette fonctionnalité est particulièrement pratique pour l'extraction de paraphrases afin d'augmenter des données ou pour aider la modélisation linguistique. Par exemple, la recherche de documents similaires à l'énoncé « je n'ai plus de courant » retourne des paraphrases telles que « on est en panne d'électricite » ou « j'ai tout sauf l'électricite ».

## 3.2 Discussion sur les fonctionnalités

nemo a l'avantage de fournir des résultats pertinents rapidement. Un gain de temps appréciable provient du prétraitement minimal des textes comparativement aux approches classiques. La pertinence des résultats est nettement améliorée dans nos cas d'usage grâce aux représentations sémantiques fournies par les sentence-embeddings.

Une limite concerne la taille des documents. Plus un document est grand, plus il y a de thèmes qui peuvent y être abordés. Il est souvent nécessaire de découper ces documents pour améliorer les résultats de l'analyse. Une autre contrainte concerne le fait que les modèles librement disponibles atteignent leur limite sur des domaines spécifiques comme la relation client d'EDF. Cela motive un travail de spécialisation de modèles.

<footnote n="1">1. La carte de ce modèle est disponible à cet URL : https://huggingface.co/sentence-transformers/ paraphrase-multilingual-mpnet-base-v2</footnote>

<footnote n="2">2. La librairie gowpy est disponible à cet URL : https://github.com/GuillaumeDD/gowpy</footnote>
# 4 Spécialisation au domaine de la relation client d'EDF

## 4.1 Objectif et démarche

La spécialisation des modèles de sentence-embeddings vise à encoder la sémantique du domaine de la relation client EDF qui manque aux modèles pré-entraînés librement disponibles (sans pour autant oublier la sémantique « générale »). Un modèle spécialisé doit, par exemple, capturer la relation de synonymie entre les expressions « PDL », « PRM » et « point référence mesure » qui font référence au point de livraison de l'énergie au client dans les données texte d'EDF. La démarche de spécialisation est la suivante. Premièrement, nous avons construit semi-automatiquement un jeu de données de paraphrases spécialisées pour la relation client d'EDF Commerce (Section 4.2). Ce jeu de données est ensuite utilisé pour spécialiser le modèle de paraphrases librement disponible paraphrase-multilingualmpnet-base-v2. Enfin, les modèles de paraphrases spécialisés sont validés sur plusieurs tâches proxy pour vérifier leur qualité (cf. Section 4.3).

## 4.2 Construction du jeu de données de paraphrases

La construction d'un jeu de données de paraphrases spécialisé à EDF Commerce n'a pas été faite de zéro pour des raisons de coûts d'annotation manuelle, mais via l'utilisation de jeux de données existants anonymisés. En vertu du règlement général sur la protection des données (RGPD), les données texte sont désidentifiées et ne comportent aucune donnée à caractère personnel telle que des noms, pré-noms, adresses, numéros [3]. Les données à caractère personnel sont substituées par le type de l'entité (e.g., "Je suis [person] et je vous appelle pour obtenir la facture de mon logement situé à [localisation]"). Nous avons utilisé des jeux de données annotés en étiquettes thématiques couvrant plusieurs types de données comme des emails ou des énoncés adressés à des chatbots. Ces types représentent des documents de taille variée allant de quelques mots à plusieurs paragraphes. Les étiquettes sont de granularité diverse allant d'étiquettes fines (e.g., intention dans le cadre d'un NLU de chatbot), moyennes (e.g., « contrat »), à grosses (e.g., « réclamation »). Nous avons spécifié manuellement la similarité en fonction des étiquettes attribuées aux documents. Schématiquement, une paire positive est formée par des documents ayant les mêmes étiquettes (similarité strictement supérieure à 0 et inférieure ou égale à 1), et une paire négative est formée par des documents dans des étiquettes opposées (similarité à 0). Nous avons assimilés les documents avec les mêmes étiquettes fines à des paraphrases parfaites (similarité à 1). La similarité est diminuée pour des étiquettes à grain plus large. Pour chaque étiquette, nous avons équilibré le nombre de paires positives et négatives. Lors de nos différentes expérimentations, nous avons noté l'importance des paires fortement opposées (appelées « hard negatives » en anglais). Il s'agit de documents ayant les mêmes mots mais des sens différents comme « je n'ai

plus de courant » et « je ne suis pas au courant ». Nous avons spécifié manuellement les étiquettes fortement opposées et nous avons utilisé une technique de minage basée sur BM25 [14] pour créer des paires négatives de documents fortement opposés.

## 4.3 Entraînement et sélection des modèles

La spécialisation des modèles a nécessité plusieurs itérations en faisant varier les données d'entraînement (plussieurs shémas de similarité sémantique entre étiquettes, différentes façons de miner des « hard negatives ») et le nombre de paires utilisées pour adapter le modèle. Le fine-tuning a utilisé des hyperparamètres standards, à savoir un taux apprentissage de 1e⁻⁵, un nombre d'epochs de 2, et une taille de batch de 4. Nous avons validé la qualité des modèles sur trois tâches proxy : clustering (via le score de silhouette), classification (via la métrique F1) et en similarité sémantique (via la corrélation). Les meilleurs modèles obtenus sont ceux basés sur un schéma de pondération présent en compte le grain des étiquettes dans les paires d'apprentissage (i.e. utilisant l'ensemble de l'échelle de 0 à 1) et en intégrant des « hard negatives » minés avec BM25. Nous avons conservé plusieurs modèles allant d'une spécialisation légère (100 paires par étiquette) à une spécialisation prononcée (1500 paires par étiquette). L'utilisateur de nemo a la main pour choisir le degré de spécialisation en fonction des données de son cas d'usage.

## 4.4 Apport des modèles spécialisés

L'apport attendu des modèles spécialisés est l'amélioration de l'exploration de données texte sur le domaine de la relation client. La Figure 2 illustre l'impact positif des modèles de sentence-embeddings spécialisés sur la tâche de clustering et de visualisation des données en 2D. Sur cet exemple d'utilisation des modèles spécialisés sur un nouveau jeu de données non-utilisé pour la spécialisation, on voit apparaître un nuage de documents avec des clusters plus marqués et plus homogènes d'un point de vue sémantique. Cet apport se confirme sur d'autres cas d'usage.

# 5 Conclusion et perspectives

Cet article a présenté nemo, un outil d'exploration sémantique de données texte de la relation client d'EDF qui simplifie et accélère considérablement la phase exploratoire de nos projets. Les perspectives incluent l'ajout d'indicateurs pour qualifier la pertinence sémantique des clusters, une meilleure prise en compte des documents longs et ultimement le rapprochement des phases d'exploration de texte et de modélisation.

# Remerciements

Nous remercions chaleureusement toutes les personnes qui sont intervenues de près ou de loin sur ce projet : Sofiane Kerroua, Mathilde Poulain, Mathilde Jeuland, Kamar Kraibi, Irène Truche, Aurore Hamimi, Philippe Very, Moudrad Miled, Subhi Issa, Oualid Akhsass, Marwen Touzi, Florent Mely, Maëlle Voisinet, Amandine Bessou, Laetitia Leroux, Laura Rouhier, Sonia Audheon, Marie Hervé,
# 4 Spécialisation au domaine de la relation client d'EDF

## 4.1 Objectif et démarche

La spécialisation des modèles de sentence-embeddings vise à encoder la sémantique du domaine de la relation client EDF qui manque aux modèles pré-entraînés librement disponibles (sans pour autant oublier la sémantique « générale »). Un modèle spécialisé doit, par exemple, capturer la relation de synonymie entre les expressions « PDL », « PRM » et « point référence mesure » qui font référence au point de livraison de l'énergie au client dans les données texte d'EDF. La démarche de spécialisation est la suivante. Premièrement, nous avons construit semi-automatiquement un jeu de données de paraphrases spécialisées pour la relation client d'EDF Commerce (Section 4.2). Ce jeu de données est ensuite utilisé pour spécialiser le modèle de paraphrases librement disponible paraphrase-multilingual-mpnet-base-v2. Enfin, les modèles de paraphrases spécialisés sont validés sur plusieurs tâches proxy pour vérifier leur qualité (cf. Section 4.3).

## 4.2 Construction du jeu de données de paraphrases

La construction d'un jeu de données de paraphrases spécialisé à EDF Commerce n'a pas été faite de zéro pour des raisons de coûts d'annotation manuelle, mais via l'utilisation de jeux de données existants anonymisés. En vertu du règlement général sur la protection des données (RGPD), les données texte sont désidentifiées et ne comportent aucune donnée à caractère personnel telle que des noms, prénoms, adresses, numéros [3]. Les données à caractère personnel sont substituées par le type de l'entité (e.g., "Je suis [person] et je vous appelle pour obtenir la facture de mon logement situé à [localisation]"). Nous avons utilisé des jeux de données annotés en étiquettes thématiques couvrant plusieurs types de données comme des emails ou des énoncés adressés à des chatbots. Ces types représentent des documents de taille variée allant de quelques mots à plusieurs paragraphes. Les étiquettes sont de granularité diverse allant d'étiquettes fines (e.g., intention dans le cadre d'un NLU de chatbot), moyennes (e.g., « contrat »), à grosses (e.g., « réclamation »). Nous avons spécifié manuellement la similarité en fonction des étiquettes attribuées aux documents. Schématiquement, une paire positive est formée par des documents ayant les mêmes étiquettes (similarité strictement supérieure à 0 et inférieure ou égale à 1), et une paire négative est formée par des documents dans des étiquettes opposées (similarité à 0). Nous avons assimilés les documents avec les mêmes étiquettes fines à des paraphrases parfaites (similarité à 1). La similarité est diminuée pour des étiquettes à grain plus large. Pour chaque étiquette, nous avons équilibré le nombre de paires positives et négatives. Lors de nos différentes expérimentations, nous avons noté l'importance des paires fortement opposées (appelées « hard negatives » en anglais). Il s'agit de documents ayant les mêmes mots mais des sens différents comme « je n'ai

plus de courant » et « je ne suis pas au courant ». Nous avons spécifié manuellement les étiquettes fortement opposées et nous avons utilisé une technique de minage basée sur BM25 [14] pour créer des paires négatives de documents fortement opposés.

## 4.3 Entraînement et sélection des modèles

La spécialisation des modèles a nécessité plusieurs itérations en faisant varier les données d'entraînement (plussieurs shémas de similarité sémantique entre étiquettes, différentes façons de miner des « hard negatives ») et le nombre de paires utilisées pour adapter le modèle. Le fine-tuning a utilisé des hyperparamètres standards, à savoir un taux apprentissage de 1e⁻⁵, un nombre d'epochs de 2, et une taille de batch de 4. Nous avons validé la qualité des modèles sur trois tâches proxy : clustering (via le score de silhouette), classification (via la métrique F1) et en similarité sémantique (via la corrélation). Les meilleurs modèles obtenus sont ceux basés sur un schéma de pondération présent en compte le grain des étiquettes dans les paires d'apprentissage (i.e. utilisant l'ensemble de l'échelle de 0 à 1) et en intégrant des « hard negatives » minés avec BM25. Nous avons conservé plusieurs modèles allant d'une spécialisation légère (100 paires par étiquette) à une spécialisation prononcée (1500 paires par étiquette). L'utilisateur de nemo a la main pour choisir le degré de spécialisation en fonction des données de son cas d'usage.

## 4.4 Apport des modèles spécialisés

L'apport attendu des modèles spécialisés est l'amélioration de l'exploration de données texte sur le domaine de la relation client. La Figure 2 illustre l'impact positif des modèles de sentence-embeddings spécialisés sur la tâche de clustering et de visualisation des données en 2D. Sur cet exemple d'utilisation des modèles spécialisés sur un nouveau jeu de données non-utilisé pour la spécialisation, on voit apparaître un nuage de documents avec des clusters plus marqués et plus homogènes d'un point de vue sémantique. Cet apport se confirme sur d'autres cas d'usage.

# 5 Conclusion et perspectives

Cet article a présenté nemo, un outil d'exploration sémantique de données texte de la relation client d'EDF qui simplifie et accélère considérablement la phase exploratoire de nos projets. Les perspectives incluent l'ajout d'indicateurs pour qualifier la pertinence sémantique des clusters, une meilleure prise en compte des documents longs et ultimement le rapprochement des phases d'exploration de texte et de modélisation.

## Remerciements

Nous remercions chaleureusement toutes les personnes qui sont intervenues de près ou de loin sur ce projet : Sofiane Kerroua, Mathilde Poulain, Mathilde Jeuland, Kamar Kraibi, Irène Truche, Aurore Hamimi, Philippe Very, Moudrad Miled, Subhi Issa, Oualid Akhsass, Marwen Touzi, Florent Mely, Maëlle Voisinet, Amandine Bessou, Laetitia Leroux, Laura Rouhier, Sonia Audheon, Marie Hervé,
<figure><img src="image_58.png" /><figcaption>FIGURE 2 – Comparaison du modèle open-source paraphrase-multilingual-mpnet-base-v2 (à gauche) et d'un modèle spécialisé pour les données EDF Commerce (à droite) sur un jeu de données interne de retranscriptions d'un serveur vocal interactif (SVI) en langue naturelle. Aucune donnée du SVI n'a été utilisée pour la spécialisation. La couleur des points représente des classes attribuées manuellement (vérité terrain).</figcaption></figure>

François Raynaud.

Références

[1] David M Blei, Andrew Y Ng, and Michael I Jordan. Latent dirichlet allocation. *Journal of machine Learning research*, 3(Jan) :993–1022, 2003.

[2] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT: Pre-training of deep bi-directional transformers for language understanding. In *Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies*, pages 4171–4186, 2019.

[3] Guillaume Dubuisson Duplessis, Elliot Bartholme, Sofiane Kerroua, Mathilde Poulain, Ahès Roulier, and Anne-Laure Guénet. Désidentification de données texte produites dans un cadre de relation client. In *Actes de la 27ème conférence Traitement Automatique des Langues Naturelles (TALN) – démonstrations*, pages 10–13, 2020.

[4] Guillaume Dubuisson Duplessis, Sofiane Kerroua, Ludivine Kuznik, and Anne-Laure Guénet. Cameli@ : analyses automatiques d'e-mails pour améliorer la relation client. In *Actes de la Conférence sur le Traitement Automatique des Langues Naturelles (TALN) PFIA 2019. Volume IV : Démonstrations*, pages 623–626, 2019.

[5] Maarten Grootendorst. Bertopic : Neural topic modeling with a class-based tf-idf procedure. *arXiv pre-print arXiv:2203.05794*, 2022.

[6] Karthik S Gurumoorthy, Amit Dhurandhar, Guillermo Cecchi, and Charu Aggarwal. Efficient data representation by selecting prototypes with importance weights. In *2019 IEEE International Conference on Data Mining (ICDM)*, pages 260–269. IEEE, 2019.

[7] Hang Le, Loïc Vial, Jibril Frej, Vincent Segonne, Maximin Coavoux, Benjamin Lecouteux, Alexandre

Allauzen, Benoît Crabbé, Laurent Besacier, and Di-
dier Schwab. Flaubert : Unsupervised language mo-
del pre-training for french. In *Proceedings of the 12th
International Conference on Language Resources and
Evaluation (LREC 2020)*, 2020.

[8] Louis Martin, Benjamin Muller, Pedro Javier Ortiz Suárez, Yoann Dupont, Laurent Romary, Éric Villemonte de la Clergerie, Djamé Seddah, and Benoît Sagot. Camembert : a tasty french language model. In *Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics*, 2020.

[9] Leland McInnes, John Healy, and Steve Astels. hdbscan : Hierarchical density based clustering. *J. Open Source Softw.*, 2(11) :205, 2017.

[10] Tomas Mikolov, Ilya Sutskever, Kai Chen, Greg S Corrado, and Jeff Dean. Distributed representations of words and phrases and their compositionality. *Advances in neural information processing systems*, 26, 2013.

[11] Jeffrey Pennington, Richard Socher, and Christopher D. Manning. Glove : Global vectors for word representation. In *Empirical Methods in Natural Language Processing (EMNLP)*, pages 1532–1543, 2014.

[12] Pierre Ratinaud and Pascal Marchand. Application de la méthode alceste à de “gros” corpus et stabilité des “mondes lexicaux” : analyse du “cablegate” avec iramuteq. *Actes des 11ème Journées internationales d’Analyse statistique des Données Textuelles*, pages 835–844, 2012.

[13] Nils Reimers and Iryna Gurevych. Sentence-bert : Sentence embeddings using siamese bert-networks. In *Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics*, 11 2019.

[14] Stephen Robertson, Hugo Zaragoza, et al. The probabilistic relevance framework : Bm25 and beyond. *Foundations and Trends® in Information Retrieval*, 3(4) :333–389, 2009.
<figure><img src="image_58.png" /><figcaption>FIGURE 2 – Comparaison du modèle open-source paraphrase-multilingual-mpnet-base-v2 (à gauche) et d'un modèle spécialisé pour les données EDF Commerce (à droite) sur un jeu de données interne de retranscriptions d'un serveur vocal interactif (SVI) en langue naturelle. Aucune donnée du SVI n'a été utilisée pour la spécialisation. La couleur des points représente des classes attribuées manuellement (vérité terrain).</figcaption></figure>

François Raynaud.

Références

[1] David M Blei, Andrew Y Ng, and Michael I Jordan. Latent dirichlet allocation. *Journal of machine Learning research*, 3(Jan) :993–1022, 2003.

[2] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT: Pre-training of deep bi-directional transformers for language understanding. In *Proceedings of the 2019 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies*, pages 4171–4186, 2019.

[3] Guillaume Dubuisson Duplessis, Elliot Bartholme, Sofiane Kerroua, Mathilde Poulain, Ahès Roulier, and Anne-Laure Guénet. Désidentification de données texte produites dans un cadre de relation client. In *Actes de la 27ème conférence Traitement Automatique des Langues Naturelles (TALN) – démonstrations*, pages 10–13, 2020.

[4] Guillaume Dubuisson Duplessis, Sofiane Kerroua, Ludivine Kuznik, and Anne-Laure Guénet. Cameli@ : analyses automatiques d'e-mails pour améliorer la relation client. In *Actes de la Conférence sur le Traitement Automatique des Langues Naturelles (TALN) PFIA 2019. Volume IV : Démonstrations*, pages 623–626, 2019.

[5] Maarten Grootendorst. Bertopic : Neural topic modeling with a class-based tf-idf procedure. *arXiv pre-print arXiv:2203.05794*, 2022.

[6] Karthik S Gurumoorthy, Amit Dhurandhar, Guillermo Cecchi, and Charu Aggarwal. Efficient data representation by selecting prototypes with importance weights. In *2019 IEEE International Conference on Data Mining (ICDM)*, pages 260–269. IEEE, 2019.

[7] Hang Le, Loïc Vial, Jibril Frej, Vincent Segonne, Maximin Coavoux, Benjamin Lecouteux, Alexandre

Allauzen, Benoît Crabbé, Laurent Besacier, and Di-
dier Schwab. Flaubert : Unsupervised language mo-
del pre-training for french. In *Proceedings of the 12th
International Conference on Language Resources and
Evaluation (LREC 2020)*, 2020.

[8] Louis Martin, Benjamin Muller, Pedro Javier Ortiz Suárez, Yoann Dupont, Laurent Romary, Éric Villemonte de la Clergerie, Djamé Seddah, and Benoît Sagot. Camembert : a tasty french language model. In *Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics*, 2020.

[9] Leland McInnes, John Healy, and Steve Astels. hdbscan : Hierarchical density based clustering. *J. Open Source Softw.*, 2(11) :205, 2017.

[10] Tomas Mikolov, Ilya Sutskever, Kai Chen, Greg S Corrado, and Jeff Dean. Distributed representations of words and phrases and their compositionality. *Advances in neural information processing systems*, 26, 2013.

[11] Jeffrey Pennington, Richard Socher, and Christopher D. Manning. Glove : Global vectors for word representation. In *Empirical Methods in Natural Language Processing (EMNLP)*, pages 1532–1543, 2014.

[12] Pierre Ratinaud and Pascal Marchand. Application de la méthode alceste à de “gros” corpus et stabilité des “mondes lexicaux” : analyse du “cablegate” avec iramuteq. *Actes des 11ème Journées internationales d’Analyse statistique des Données Textuelles*, pages 835–844, 2012.

[13] Nils Reimers and Iryna Gurevych. Sentence-bert : Sentence embeddings using siamese bert-networks. In *Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics*, 11 2019.

[14] Stephen Robertson, Hugo Zaragoza, et al. The probabilistic relevance framework : Bm25 and beyond. *Foundations and Trends® in Information Retrieval*, 3(4) :333–389, 2009.
Session 6 : Système à base de règles
Session 6 : Système à base de règles
# Hybridation opérationnelle des logiques OWL2 et ASP pour améliorer l'expressivité déclarative

X. Goblet¹, C. Rey², A. Collange¹,²

¹ Jeolis Solutions, Clermont-Ferrand, France

² LIMOS, Université Clermont Auvergne, Aubière, France

xavier.goblet@lojelis.com, christophe.rey@uca.fr, adrien.collange@uca.fr

## Résumé

Dans le cadre d'un outil de recommandation d'activités dédié à l'éducation thérapeutique du patient, nous avons proposé la solution ORALOoS combinant OWL2 + SWRL, augmentée du module Python Owlready. L'usage de code impératif permet de pallier certaines limitations d'expressivité, comme l'absence de négation dans les règles SWRL. Cependant, il contrebalance fortement le caractère déclaratif de l'approche permis par OWL2. Tout en pré servant cette caractéristique, nous présentons une solution pour remplacer règles SWRL et code impératif par un programme en Answer Set Programming. Cette idée n'est pas nouvelle mais peu de travaux ont abouti à des solutions réellement opérationnelles dans un contexte industriel. Notre proposition est abordée en deux étapes : 1) utilisation du solveur Hexlite qui donne de bons résultats en termes d'expressivité déclarative mais reste difficile à mettre en œuvre, et 2) développement d'une nouvelle librairie opérationnelle, hybridant OWL2 et ASP avec des fonctionnalités similaires à Hexlite mais d'un usage facilité.

## Mots-clés

Hybridation de langages logiques, OWL2, ASP, Module Owlready, Système Clingo.

## Abstract

As part of an activity recommendation tool dedicated to therapeutic patient education, we proposed the ORALOoS solution combining OWL2 + SWRL, augmented with the Python Owlready module. The use of the imperative code makes it possible to overcome certain limitations of expressiveness, such as the absence of negation in the SWRL rules. However, it strongly counterbalances the declarative character of the approach allowed by OWL2. While preserving this characteristic, we present a solution to replace the SWRL rules and the imperative code by a program in Answer Set Programming. This idea is not new, but few studies have led to truly operational solutions in an industrial context. Our proposal is suggested in two steps : 1) use of the Hexlite solver which gives good results in terms of declarative expressiveness but remains difficult to operate with, and 2) development of a new operational library, hybridizing OWL2 and ASP with features similar to Hexlite but easy to use.

## Keywords

Hybridization of logical languages, OWL2, ASP, Owlready Framework, Clingo System.

## 1 Introduction

Dans le cadre d'un outil de recommandation d'activités dédié à l'éducation thérapeutique du patient, nous avons proposé la solution ORALOoS combinant une ontologie OWL2 et des règles SWRL, augmentée du module Python Owlready [13] pour pallier les limitations comme l'absence de négation dans SWRL et de traitements dynamiques en OWL2. Dans l'optique d'apporter une solution complète déclarative, nous proposons de combiner (hybrider) un langage logique avancé (ASP) avec les logiques de description (OWL2). Les premiers travaux dans ce domaine remontent à une trentaine d'années. De nombreux résultats théoriques ont été obtenus et quelques solutions opérationnelles ont vu le jour. En particulier, Hexlite a été proposé récemment et étendu pour offrir une interaction bidirectionnelle entre un programme ASP étendu et une ontologie OWL2 via l'API Java OWLAPI [23]. Nous avons donc, dans un premier temps, testé Hexlite pour notre contexte applicatif. Si les résultats sont bons (remplacement de SWRL + code impératif), des difficultés de mise en œuvre d'Hexlite apparaissent. Ainsi, dans un second temps, nous proposons une nouvelle librairie hybridant ASP et OWL2, similaire à OWLAPI Hexlite mais exclusivement à partir des fonctionnalités natives du système ASP Clingo et du module Python Owlready pour l'interface OWL2.

Le papier est organisé comme suit : la section 2 présente notre contexte applicatif ORALOoS, ainsi qu'un état de l'art des travaux combinant la programmation logique avec les logiques de description. La section 3 présente notre utilisation de la proposition récente HexLite pour ORALOoS et les limites de cette approche. La section 4 présente notre librairie alternative : Exialis, son application spécifique pour ORALOoS ainsi que sa généralisation. La section 5 conclut et évoque les perspectives.
# Hybridation opérationnelle des logiques OWL2 et ASP pour améliorer l'expressivité déclarative

X. Goblet¹, C. Rey², A. Collange¹,²

¹ Jeolis Solutions, Clermont-Ferrand, France

² LIMOS, Université Clermont Auvergne, Aubière, France

xavier.goblet@lojelis.com, christophe.rey@uca.fr, adrien.collange@uca.fr

## Résumé

Dans le cadre d'un outil de recommandation d'activités dédié à l'éducation thérapeutique du patient, nous avons proposé la solution ORALOoS combinant OWL2 + SWRL, augmentée du module Python Owlready. L'usage de code impératif permet de pallier certaines limitations d'expressivité, comme l'absence de négation dans les règles SWRL. Cependant, il contrebalance fortement le caractère déclaratif de l'approche permis par OWL2. Tout en pré servant cette caractéristique, nous présentons une solution pour remplacer règles SWRL et code impératif par un programme en Answer Set Programming. Cette idée n'est pas nouvelle mais peu de travaux ont abouti à des solutions réellement opérationnelles dans un contexte industriel. Notre proposition est abordée en deux étapes : 1) utilisation du solveur Hexlite qui donne de bons résultats en termes d'expressivité déclarative mais reste difficile à mettre en œuvre, et 2) développement d'une nouvelle librairie opérationnelle, hybridant OWL2 et ASP avec des fonctionnalités similaires à Hexlite mais d'un usage facilité.

## Mots-clés

Hybridation de langages logiques, OWL2, ASP, Module Owlready, Système Clingo.

## Abstract

As part of an activity recommendation tool dedicated to therapeutic patient education, we proposed the ORALOoS solution combining OWL2 + SWRL, augmented with the Python Owlready module. The use of the imperative code makes it possible to overcome certain limitations of expressiveness, such as the absence of negation in the SWRL rules. However, it strongly counterbalances the declarative character of the approach allowed by OWL2. While preserving this characteristic, we present a solution to replace the SWRL rules and the imperative code by a program in Answer Set Programming. This idea is not new, but few studies have led to truly operational solutions in an industrial context. Our proposal is suggested in two steps : 1) use of the Hexlite solver which gives good results in terms of declarative expressiveness but remains difficult to operate with, and 2) development of a new operational library, hybridizing OWL2 and ASP with features similar to Hexlite

but easy to use.

## Keywords

Hybridization of logical languages, OWL2, ASP, Owlready Framework, Clingo System.

## 1 Introduction

Dans le cadre d'un outil de recommandation d'activités dédié à l'éducation thérapeutique du patient, nous avons proposé la solution ORALOoS combinant une ontologie OWL2 et des règles SWRL, augmentée du module Python Owlready [13] pour pallier les limitations comme l'absence de négation dans SWRL et de traitements dynamiques en OWL2. Dans l'optique d'apporter une solution complète déclarative, nous proposons de combiner (hybrider) un langage logique avancé (ASP) avec les logiques de description (OWL2). Les premiers travaux dans ce domaine remontent à une trentaine d'années. De nombreux résultats théoriques ont été obtenus et quelques solutions opérationnelles ont vu le jour. En particulier, Hexlite a été proposé récemment et étendu pour offrir une interaction bidirectionnelle entre un programme ASP étendu et une ontologie OWL2 via l'API Java OWLAPI [23]. Nous avons donc, dans un premier temps, testé Hexlite pour notre contexte applicatif. Si les résultats sont bons (remplacement de SWRL + code impératif), des difficultés de mise en œuvre d'Hexlite apparaissent. Ainsi, dans un second temps, nous proposons une nouvelle librairie hybridant ASP et OWL2, similaire à OWLAPI Hexlite mais exclusivement à partir des fonctionnalités natives du système ASP Clingo et du module Python Owlready pour l'interface OWL2.

Le papier est organisé comme suit : la section 2 présente notre contexte applicatif ORALOoS, ainsi qu'un état de l'art des travaux combinant la programmation logique avec les logiques de description. La section 3 présente notre utilisation de la proposition récente HexLite pour ORALOoS et les limites de cette approche. La section 4 présente notre librairie alternative : Exialis, son application spécifique pour ORALOoS ainsi que sa généralisation. La section 5 conclut et évoque les perspectives.
# 2 Travaux antérieurs

## 2.1 Le contexte applicatif ORALOoS

Dans le cadre d'applications de suivi de patients à distance, nous posons la question "Comment motiver et engager des patients envers une application numérique de suivi médical, qui plus est sur un temps long ?". C'est particulièrement vrai dans les protocoles d'Education Thérapeuthique du Patient (ETP), mais aussi en suivi de maladies chroniques, en pré ou post chirurgie ambulatoire où la motivation du patient à utiliser très fréquemment l'application reste primordiale. Encore faut-il que les interactions proposées soient engagantes; un simple échange de SMS, une lecture de pages web, etc. ne sont pas suffisantes. Nous avons donc proposé un outil de recommandation d'activités (ORALOoS) [13] permettant de :

- Gamifier l'ETP en proposant un contenu ludique comme des mini jeux (quizz, défis personnels, etc.).

- Personnaliser le parcours de chaque patient en se basant sur ses succès ou échecs rencontrés lors des activités et lui proposer une progression adaptée.

Les sections suivantes 2.1.1 et 2.1.2 reprennent les éléments de [13] pour en expliciter les limites.

### 2.1.1 Éléments fonctionnels

Pour maintenir la motivation d'un utilisateur, le premier principe fondateur d'ORALOoS, issu des sciences psychologiques (motivation intrinsèque, théorie du flow, zone proximale de développement...) est de proposer un large espace d'activités ludiques (appelées défis dans la suite). Chaque défi concerne un domaine de compétences à déployer par l'utilisateur lorsqu'il l'exécute. Les experts du domaine définissent aussi pour chaque défi un niveau de difficulté [2]. Enfin, l'activation d'un défi peut être conditionnée par un contexte spécifique à l'utilisateur (par exemple, c'est un enfant) ou à son parcours (il a lu une fiche conseil), etc.

Il semble aussi évident que, pour chaque utilisateur, l'exploration de cette espace d'activités ne peut se faire de façon aléatoire et il doit être guidé selon les principes :

- d'une recommandation d'un ou plusieurs prochains défis en tenant compte de son retour immédiat (feedback),

- d'une pédagogie béhavioriste (conditionnement par renforcement) : en cas de succès pour l'activité courante, lui proposer une activité de difficulté un peu supérieure et inversement en cas d'échec [12].

### 2.1.2 Éléments technologiques

**Modélisation statique OWL2.** La figure 1 donne un aperçu graphique (pseudo diagramme de classes UML) d'une ontologie applicative conçue avec ORALOoS dédiée à la prévention de l'obésité infantile. Nous retrouvons les principaux concepts définis dans la section précédente sous forme de classes, d'attributs et de relations :

- La classe Challenge conceptualise les défis avec ses attributs hasLevel, hasDomain, ... qui modélise des propriétés de donnée (DP) OWL. Les conditions

d'activation d'un défi sont définies comme une propriété objet (OP) OWL par la relation hasCondition<fnref n="1" />.

- Un utilisateur est défini par la classe Person qui possède une propriété DP hasAge. Lorsque que l'on asserte (instance) un individu dans l'ontologie avec son âge, un raisonnement terminologique permet de le classifier en Enfant ou Adulte. Le concept Person est aussi en relation avec les défis par les deux propriétés non fonctionnelles fails* et succeeds* qui mémorisent alors les défis déjà rencontrés par l'utilisateur et que l'on interdit de rejouer (relation forbids*).

- Le concept Condition est spécialisé en deux sous-classes : ClassCond qui exprime une caractéristique intrinsèque d'un individu de l'ontologie; par exemple : EnfantCond ou AdulteCond. RelationCond est la définition d'une condition qui exprime une relation entre deux concepts de l'ontologie. Par exemple, un défi peut être conditionné (SuccessCond) à la réussite d'un ou plusieurs autres défis pré-requis.

- Le retour utilisateur est défini par la classe FeedBack et est spécifique à une personne par la relation fonctionnelle concernsPerson et un défi courant par concernsChallenge. Faisant suite à l'évaluation, tout feedback porte aussi les prochains défis candidats dans la relation usable*, eux-mêmes partitionnés dans des relations non fonctionnelles xxxLevel. En appliquant un raisonnement OWL, en fonction de l'attribut DP hasSuccess, le feedback est spécialisé en PositiveFB ou NegativeFB.

**Modélisation dynamique SWRL.** La figure 2 présente les règles logiques SWRL pour la mise en oeuvre d'une pédagogie béhavioriste définie en section 2.1.1; avec l'ajout d'une règle palier R3 qui propose des défis de difficulté similaire au défi évalué (limite l'effet "montagnes russes" si on applique successivement R1 ou R2).

SWRL est aussi une proposition<fnref n="2" /> W3C pour spécifier des règles logiques dans les ontologies en introduisant la notion de variables ?x dans les prédicats. Ces prédicats viennent d'une ontologie ou bien sont prédéfinis (préfixés par swrlb) et sont enchaînés par un ET logique uniquement. Les inconvénients principaux de SWRL sont l'absence de négation explicite dans les règles, ainsi que l'impossibilité d'utiliser des prédicats plus complexes (termes fonctionnels, par exemple); ce qui nécessite d'implémenter le prédicat usable() avec un code impératif comme le montre la section suivante.

**Owlready2.** C'est un module Python permettant la manipulation (création, lecture, modification et suppression) d'ont

<footnote n="1">1. Le caractère "*" spécifie que la relation OP est non fonctionnelle; i.e. qu'un même individu/instance Challenge peut être associé plusieurs individus Condition. Une propriété OP ou DP fonctionnelle OWL équivaut à une relation 1..1 en UML.</footnote>

<footnote n="2">2. A la différence d'OWL et OWL2, SWRL n'a jamais été promu au rang de standard W3C pour le Web Sémantique. Par contre, il reste utilisable dans des raisonneurs comme HermiT ou Pellet.</footnote>
# 2 Travaux antérieurs

## 2.1 Le contexte applicatif ORALOoS

Dans le cadre d'applications de suivi de patients à distance, nous posons la question "Comment motiver et engager des patients envers une application numérique de suivi médical, qui plus est sur un temps long ?". C'est particulièrement vrai dans les protocoles d'Education Thérapeuthique du Patient (ETP), mais aussi en suivi de maladies chroniques, en pré ou post chirurgie ambulatoire où la motivation du patient à utiliser très fréquemment l'application reste primordiale. Encore faut-il que les interactions proposées soient engagantes; un simple échange de SMS, une lecture de pages web, etc. ne sont pas suffisantes. Nous avons donc proposé un outil de recommandation d'activités (ORALOoS) [13] permettant de :

- Gamifier l'ETP en proposant un contenu ludique comme des mini jeux (quizz, défis personnels, etc.).

- Personnaliser le parcours de chaque patient en se basant sur ses succès ou échecs rencontrés lors des activités et lui proposer une progression adaptée.

Les sections suivantes 2.1.1 et 2.1.2 reprennent les éléments de [13] pour en expliciter les limites.

### 2.1.1 Éléments fonctionnels

Pour maintenir la motivation d'un utilisateur, le premier principe fondateur d'ORALOoS, issu des sciences psychologiques (motivation intrinsèque, théorie du flow, zone proximale de développement...) est de proposer un large espace d'activités ludiques (appelées défis dans la suite). Chaque défi concerne un domaine de compétences à déployer par l'utilisateur lorsqu'il l'exécute. Les experts du domaine définissent aussi pour chaque défi un niveau de difficulté [2]. Enfin, l'activation d'un défi peut être conditionnée par un contexte spécifique à l'utilisateur (par exemple, c'est un enfant) ou à son parcours (il a lu une fiche conseil), etc.

Il semble aussi évident que, pour chaque utilisateur, l'exploration de cette espace d'activités ne peut se faire de façon aléatoire et il doit être guidé selon les principes :

- d'une recommandation d'un ou plusieurs prochains défis en tenant compte de son retour immédiat (feedback),

- d'une pédagogie béhavioriste (conditionnement par renforcement) : en cas de succès pour l'activité courante, lui proposer une activité de difficulté un peu supérieure et inversement en cas d'échec [12].

### 2.1.2 Éléments technologiques

**Modélisation statique OWL2.** La figure 1 donne un aperçu graphique (pseudo diagramme de classes UML) d'une ontologie applicative conçue avec ORALOoS dédiée à la prévention de l'obésité infantile. Nous retrouvons les principaux concepts définis dans la section précédente sous forme de classes, d'attributs et de relations :

- La classe Challenge conceptualise les défis avec ses attributs hasLevel, hasDomain, ... qui modélise des propriétés de donnée (DP) OWL. Les conditions

d'activation d'un défi sont définies comme une propriété objet (OP) OWL par la relation hasCondition<fnref n="1" />.

- Un utilisateur est défini par la classe Person qui possède une propriété DP hasAge. Lorsque que l'on asserte (instance) un individu dans l'ontologie avec son âge, un raisonnement terminologique permet de le classifier en Enfant ou Adulte. Le concept Person est aussi en relation avec les défis par les deux propriétés non fonctionnelles fails* et succeeds* qui mémorisent alors les défis déjà rencontrés par l'utilisateur et que l'on interdit de rejouer (relation forbids*).

- Le concept Condition est spécialisé en deux sous-classes : ClassCond qui exprime une caractéristique intrinsèque d'un individu de l'ontologie; par exemple : EnfantCond ou AdulteCond. RelationCond est la définition d'une condition qui exprime une relation entre deux concepts de l'ontologie. Par exemple, un défi peut être conditionné (SuccessCond) à la réussite d'un ou plusieurs autres défis pré-requis.

- Le retour utilisateur est défini par la classe FeedBack et est spécifique à une personne par la relation fonctionnelle concernsPerson et un défi courant par concernsChallenge. Faisant suite à l'évaluation, tout feedback porte aussi les prochains défis candidats dans la relation usable*, eux-mêmes partitionnés dans des relations non fonctionnelles xxxLevel. En appliquant un raisonnement OWL, en fonction de l'attribut DP hasSuccess, le feedback est spécialisé en PositiveFB ou NegativeFB.

**Modélisation dynamique SWRL.** La figure 2 présente les règles logiques SWRL pour la mise en oeuvre d'une pédagogie béhavioriste définie en section 2.1.1; avec l'ajout d'une règle palier R3 qui propose des défis de difficulté similaire au défi évalué (limite l'effet "montagnes russes" si on applique successivement R1 ou R2).

SWRL est aussi une proposition<fnref n="2" /> W3C pour spécifier des règles logiques dans les ontologies en introduisant la notion de variables ?x dans les prédicats. Ces prédicats viennent d'une ontologie ou bien sont prédéfinis (préfixés par swrlb) et sont enchaînés par un ET logique uniquement. Les inconvénients principaux de SWRL sont l'absence de négation explicite dans les règles, ainsi que l'impossibilité d'utiliser des prédicats plus complexes (termes fonctionnels, par exemple); ce qui nécessite d'implémenter le prédicat usable() avec un code impératif comme le montre la section suivante.

**Owlready2.** C'est un module Python permettant la manipulation (création, lecture, modification et suppression) d'ont

<footnote n="1">1. Le caractère "*" spécifie que la relation OP est non fonctionnelle ; i.e. qu'un même individu/instance Challenge peut être associé plusieurs individus Condition. Une propriété OP ou DP fonctionnelle OWL équivaut à une relation 1..1 en UML.</footnote>

<footnote n="2">2. A la différence d'OWL et OWL2, SWRL n'a jamais été promu au rang de standard W3C pour le Web Sémantique. Par contre, il reste utilisable dans des raisonneurs comme HermiT ou Pellet.</footnote>
<figure><img src="image_59.png" /><figcaption>FIGURE 1 – Extrait de l'ontologie applicative ETP Proximité Obésité.</figcaption></figure>

R1: Feedback(?fb) ^ concernsChallenge(?fb, ?ch) ^ hasLevel(?ch, ?lv) ^ usable(?fb, ?nch)
^ hasLevel(?nch, ?nlv) ^ swrlb:greaterThan(?nlv, ?lv) ^ hasSuccess(?fb, true) -> reinforceLevel(?fb, ?nch)

R2: Feedback(?fb) ^ concernsChallenge(?fb, ?ch) ^ hasLevel(?ch, ?lv) ^ usable(?fb, ?nch)
^ hasLevel(?nch, ?nlv) ^ swrlb:lessThan(?nlv, ?lv) ^ hasSuccess(?fb, false) -> remedyLevel(?fb, ?nch)

R3: Feedback(?fb) ^ concernsChallenge(?fb, ?ch) ^ hasLevel(?ch, ?lv) ^ usable(?fb, ?nch)
^ hasLevel(?nch, ?lv) -> sameLevel(?fb, ?nch)

<caption>FIGURE 2 – Règles SWRL.</caption>

tologies au format OWL2 [15]. A la différence d'API en
Java comme OWLAPI, Owlready réifie les éléments d'une
ontologie sous la forme d'objets, de classes et de méthodes
de la programmation orientée objet, ce qui constitue une
approche simple et puissante. Ce module inclut nativement
une base de données graphe (appelée quadstore) stockant
des triplets RDF associés à des identifiants d'ontologies,
ainsi que les raisonneurs HermiT et Pellet permettant de
faire des raisonnements par classification (terminologique)
et aussi SWRL. Avec Owlready, les classes OWL sont des
classes Python que l'on peut étendre en définissant des mé-
thodes objet associées. C'est ce code impératif qui nous
permet de pallier les limitations d'OWL2 et SWRL dans
le traitement d'un feedback et des conditions

Avec Owlready, les classes OWL sont des classes objet Python comme les autres; cela permet tout simplement d'étendre les concepts ontologiques en y incluant des méthodes. Pour ORALoOS, nous l'utilisons pour compléter les classes OWL2 Feedback, ClassCond et RelationCond avec des méthodes preFilter() et execute() respectivement.

- Feedback.prefilter() : les paramètres d'entrée de cette méthode sont l'utilisateur courant et le défi courant portés par les relations "concerns" de l'unité FeedBack. La première étape est de chercher dans l'ontologie tous les défis de même domaine que le défi courant. Ensuite, on élimine de cet ensemble

le défi courant lui-même et les défis déjà joués par
l'utilisateur en utilisant sa relation forbids. Enfin,
parmi tous ces défis potentiellement candidats, on
garde uniquement les défis dont les conditions sont
vérifiées pour ajouter les relations usable au feed-
back. Après l'exécution de cette méthode, il suffit
de lancer un raisonnement Owlready pour déclen-
cher les règles SWRL qui calculent les prochains
défis recommandables définis ontologiquement par
les OP reinforceLevel, remedyLevel et sameLevel
et classer le feedback en FB+ ou FB-.

- ClassCond.execute() : Cette méthode utilise les définitions ontologiques hasSubject, hasVerb et hasObject de la classe Condition (cf. 1. Avec comme spécificité qu'une ClassCond a toujours comme verbe : "is_a", on vérifie que le sujet de la condition est bien du type/classe défini dans l'objet.

- RelationCond.execute() : vérifie dans l'ontologie qu'il existe bien la relation (propriété objet) spécifiée par hasVerb entre les deux individus hasSubject et hasObject de la condition.

## 2.2 Combiner les ontologies avec la programmation logique et réciproquement

Au sein du domaine de la représentation des connaissances
et des raisonnements (KRR), la question de l'intégration de
<figure><img src="image_59.png" /><figcaption>FIGURE 1 – Extrait de l'ontologie applicative ETP Proximité Obésité.</figcaption></figure>

R1: Feedback(?fb) ^ concernsChallenge(?fb, ?ch) ^ hasLevel(?ch, ?lv) ^ usable(?fb, ?nch)
^ hasLevel(?nch, ?nlv) ^ swrlb:greaterThan(?nlv, ?lv) ^ hasSuccess(?fb, true) -> reinforceLevel(?fb, ?nch)

R2: Feedback(?fb) ^ concernsChallenge(?fb, ?ch) ^ hasLevel(?ch, ?lv) ^ usable(?fb, ?nch)
^ hasLevel(?nch, ?nlv) ^ swrlb:lessThan(?nlv, ?lv) ^ hasSuccess(?fb, false) -> remedyLevel(?fb, ?nch)

R3: Feedback(?fb) ^ concernsChallenge(?fb, ?ch) ^ hasLevel(?ch, ?lv) ^ usable(?fb, ?nch)
^ hasLevel(?nch, ?lv) -> sameLevel(?fb, ?nch)

<caption>FIGURE 2 – Règles SWRL.</caption>

tologies au format OWL2 [15]. A la différence d'API en
Java comme OWLAPI, Owlready réifie les éléments d'une
ontologie sous la forme d'objets, de classes et de méthodes
de la programmation orientée objet, ce qui constitue une
approche simple et puissante. Ce module inclut nativement
une base de données graphe (appelée quadstore) stockant
des triplets RDF associés à des identifiants d'ontologies,
ainsi que les raisonneurs HermiT et Pellet permettant de
faire des raisonnements par classification (terminologique)
et aussi SWRL. Avec Owlready, les classes OWL sont des
classes Python que l'on peut étendre en définissant des mé-
thodes objet associées. C'est ce code impératif qui nous
permet de pallier les limitations d'OWL2 et SWRL dans
le traitement d'un feedback et des conditions

Avec Owlready, les classes OWL sont des classes objet Python comme les autres; cela permet tout simplement d'étendre les concepts ontologiques en y incluant des méthodes. Pour ORALoOS, nous l'utilisons pour compléter les classes OWL2 Feedback, ClassCond et RelationCond avec des méthodes preFilter() et execute() respectivement.

- Feedback.prefilter() : les paramètres d'entrée de cette méthode sont l'utilisateur courant et le défi courant portés par les relations "concerns" de l'unité FeedBack. La première étape est de chercher dans l'ontologie tous les défis de même domaine que le défi courant. Ensuite, on élimine de cet ensemble

le défi courant lui-même et les défis déjà joués par
l'utilisateur en utilisant sa relation forbids. Enfin,
parmi tous ces défis potentiellement candidats, on
garde uniquement les défis dont les conditions sont
vérifiées pour ajouter les relations usable au feed-
back. Après l'exécution de cette méthode, il suffit
de lancer un raisonnement Owlready pour déclen-
cher les règles SWRL qui calculent les prochains
défis recommandables définis ontologiquement par
les OP reinforceLevel, remedyLevel et sameLevel
et classer le feedback en FB+ ou FB-.

- ClassCond.execute() : Cette méthode utilise les définitions ontologiques hasSubject, hasVerb et hasObject de la classe Condition (cf. 1. Avec comme spécificité qu'une ClassCond a toujours comme verbe : "is_a", on vérifie que le sujet de la condition est bien du type/classe défini dans l'objet.

- RelationCond.execute() : vérifie dans l'ontologie qu'il existe bien la relation (propriété objet) spécifiée par hasVerb entre les deux individus hasSubject et hasObject de la condition.

## 2.2 Combiner les ontologies avec la programmation logique et réciproquement

Au sein du domaine de la représentation des connaissances
et des raisonnements (KRR), la question de l'intégration de
la programmation logique (PL) avec les logiques de descriptions (LD) est étudiée depuis plus de 30 ans. L'objectif est de profiter des atouts des deux approches, et de pallier leurs inconvénients respectifs, tout en conservant la décidabilité et l'efficacité des raisonnements associés. Le tableau 1 présente un résumé des avantages et inconvénients de la LP et des LD.

Dans cette problématique, on peut classer les approches existantes en deux catégories : celles proposant une intégration de type fusion, qui consistent à n'exécuter qu'un seul raisonnement sur les connaissances modélisées sous forme de règles et d'axiomes ontologiques, et celles proposant une intégration de type API, qui consistent à faire diologuer deux raisonneurs (un pour les règles et l'autre pour les axiomes ontologiques) via des interfaces fonctionnant comme des API.

**Hybridation par fusion.** Ces approches "sur étagère" permettent à l'utilisateur (ingénieur des connaissances) l'usage d'un seul raisonnement; ce qui a comme avantage de lui simplifier le travail en se concentrant sur la modélisation des connaissances et n'a très peu, voire aucun code anexe supplémentaire à créer pour exécuter le raisonnement. La contrepartie est que les systèmes associés sont moins flexibles et qu'il est souvent difficile voire impossible de les étendre afin de construire un raisonneur personnalisé. Par ailleurs, comme l'explique bien [19], l'intégration de type fusion est un vrai défi dès lors que l'on veut assurer la décidabilité du raisonnement et son efficacité, et que l'on veut définir une sémantique rigoureuse qui ne soit pas limitante par rapport aux sémantiques respectives des règles et des axiomes ontologiques, c'est-à-dire qui permette un enrichissement réciproque des connaissances et qui gère de manière claire l'interaction entre les hypothèses du monde ouvert et du monde fermé (qui sont respectivement les hypothèses des LD et de la PL).

Un des premiers travaux d'intégration de type fusion est décrit dans [16], où les auteurs proposent de combiner des clauses de Horn sans fonction avec des ontologies exprimées avec la LD ALCN*. Le formalisme obtenu, appelé CARIN, est utilisé pour permettre la médiation entre des requêtes d'utilisateurs et des sources de données hétérogènes. Le raisonnement associé, appelé "expansion de requêtes", utilise conjointement les règles et axiomes ontologiques pour réécrire la requête donnée en entrée en requêtes exécutables sur les sources. Cependant, les auteurs montrent que même avec deux formalismes séparément décidables, la fusion peut être indécidable. Plus récemment, [19] propose le formalisme MKNF+, basé sur la logique de la connaissance minimale et la négation par échec fini (logic of minimal knowledge and negation as failure). Les auteurs proposent des contraintes nécessaires à la décidabilité, des algorithmes de raisonnement pour vérifier si un atome clos est vrai dans tous les modèles de la base de connaissance, et des bornes pour la complexité de ce raisonnement. Ils montrent comment MKNF+ permet de raisonner avec des axiomes ontologiques et des programmes ASP, en permettant de choisir de raisonner en monde ou-

vert ou fermé pour chaque prédicat utilisé. Au niveau théorique, ce travail apparaît comme un cadre commun possible pour d'autres approches comme DL+log [20], disjunctive dl-programs [18], dl-programs [7], ou encore pour des approches basées sur différentes logiques du premier ordre, comme la logique auto-épistémique [5], un langage de requête du premier ordre orienté logiques de description [3], et la logique des défauts [1]. Tous les détails sont donnés dans [19]. On peut enfin citer le système DLog [17] qui est un raisonneur pour les LD basé sur l'inférence prolog. Cela permet un traitement bien plus efficace des raisonnements assertionnels impliquant de très grands ensembles de données.

**Hybridation par API.** Les approches d'intégration de type API sont des approches plus personnalisables. Le principe est que l'utilisateur modélise son problème avec un langage de PL et que sa résolution utilise en plus une ontologie du domaine en LD pour enrichir l'inférence. La personnalisation tient en ce que l'utilisateur a une certaine latitude pour choisir le raisonneur LD (et donc le raisonnement et la LD sous-jacents), alors que le raisonneur PL est le programme principal. Les deux raisonneurs communiquent en général dans les deux sens via une interface qui s'utilise comme une API. Les raisonnements sur les règles de PL et sur les connaissances ontologiques, dites "externes", peuvent être entrelacés, mais les raisonnements restent séparés. L'utilisateur peut avoir à programmer lui-même quelques scripts permettant la communication entre les raisonneurs, mais cela ne requiert pas d'être spécialiste des langages de KRR sous-jacents.

Ces dernières années, les approches de type API ont principalement utilisé ASP<fnref n="3" /> en tant que formalisme de PL. En particulier, les systèmes DLVHEX et HEXLite [6–8,21,22] implémentent le langage HEX<fnref n="4" />, qui augmente les programmes ASP avec des atomes externes<fnref n="5" /> afin de les enrichir avec plusieurs types d'informations externes. Ces dernières peuvent être des informations stockées (comme des données de sources externes ou des connaissances stockées dans des ontologies), mais aussi des informations calculées (comme des données issues de requêtes et des connaissances issues de raisonnements). Par ailleurs ces atomes externes permettent aussi l'envoi de données aux sources externes, leur permettant d'effectuer leurs calculs. Ainsi, le

<footnote n="3">3. Answer Set Programming est un langage logique complet permettant un raisonnement non monotone, l'usage de négations (par défaut et classique/forte), conjunctions, disjonctions entre clauses et l'ajout de contraintes. Le principe de raisonnement standard ASP se déroule toujours en deux étapes : 1) ground qui consiste à instancier les variables et 2) solve qui résout ce programme transformé en propositions par un algorithme SAT. Les solveurs ASP à l'état de l'art académique et industriel sont les systèmes Clingo (https://potassco.org/) et DLV (https://www.dlvsystem.it/dlvsite/).</footnote>

<footnote n="4">4. Higher-order logic with EXternal atoms. L'implémentation de référence est le solveur dlvhex dont le langage principal est C++ (http://www.kr.tuwien.ac.at/research/systems/dlvhex/). Hexlite est une implémentation légère en Python [22] d'un fragment de HEX et utilise Clingo comme backend ASP.</footnote>

<footnote n="5">5. L'ajout d'atomes externes nécessitent toujours une extension syntaxique + sémantique d'ASP, ainsi qu'une couche additionnelle de préprocessing pour insérer ces atomes externes dans les étapes ground+solve.</footnote>