Où le modèle NLI aide un assistant de réunion : trois essayages, deux échecs

Le développeur de l'assistant de réunion local Charoite, Charoiteai, a expliqué où le modèle NLI fonctionne et où il gêne. Testé à cinq endroits, deux ont survécu.

En juillet, il a fait passer un même compte-rendu de réunion quatre fois dans le modèle de synthèse automatique — il a obtenu 39 affirmations différentes, dont 32 n'apparaissaient que dans une seule exécution. Il voulait un outil capable de signaler où les exécutions se contredisent. Il a pris mDeBERTa-v3-base-xnli-multilingual-nli-2mil7 : multilingue, entraîné sur 2,7 millions de paires, poids de 1,1 Go au format ONNX, chargement en une seconde et demie.

Premier emplacement : les répétitions dans le fil en direct —

fonctionne tous les jours

Dans une réunion longue, le modèle de synthèse ne voit que 800 caractères de texte frais, donc il répète ce qui a déjà été dit avec d'autres mots. Le NLI attrape les doublons via une logique bidirectionnelle : c'est un doublon quand A découle de B et B découle de A simultanément. Une précision (seulement dans un sens : le budget est validé découle de le budget est validé jusqu'à la fin de l'année, mais pas l'inverse) reste dans le fil. Une contradiction ne passe dans aucun des deux sens.

Le schéma est simple : la nouvelle affirmation est comparée aux 16 précédentes via difflib avec un seuil de 0,3 (volontairement bas pour ne pas couper trop tôt). Celles qui passent vont dans le modèle dans les deux sens. Si les deux probabilités sont ≥ 0,8, l'affirmation est rejetée comme doublon, sinon elle reste. Le seuil est de 0,8, et non 0,75 par défaut, parce qu'une répétition est irritante, mais un fait nouveau perdu est pire. Chaque appel prend quelques dizaines de millisecondes, la plupart des paires n'atteignent même pas le modèle grâce au préfiltre.

C'est le seul endroit où le NLI fonctionne sans accroc depuis trois mois d'affilée. Pas parfait : lors de la réunion du 29 septembre, on est revenu sur le même sujet 5 fois en 8 minutes sans rien ajouter de nouveau. Le mécanisme est déjà en mémoire — prochaine tâche.

Deuxième emplacement : les contradictions dans les comptes-rendus — échec

Testé sur les archives : 14 réunions, 51 points de compte-rendu, 1192 paires à analyser. Sur les 76 paires passant le préfiltre, le modèle en a qualifié 30 de contradictoires. Presque toutes fausses. La raison tient à la longueur : un point de compte-rendu fait en moyenne 138 caractères, 69 % dépassent 120. Une phrase comme « Il est nécessaire d'initier un contact direct avec la personne responsable afin de clarifier les principes généraux de connexion, en contournant les étapes intermédiaires de validation » contient trois idées dans un seul paragraphe. Deux paragraphes quelconques partageront toujours un mot commun et quelque chose ressemblant à un conflit.

Une solution deux ordres de grandeur moins coûteuse : les affirmations courtes (jusqu'à 60 caractères) avec un objet nommé, les numéros et les dates sont vérifiés directement par recherche textuelle dans la transcription. Sur le même passage, une telle vérification a trouvé une invention sur dix affirmations : une mise en production prévue pour le 17/08, alors que le 17 août n'avait été mentionné ni en chiffres ni en mots.

Troisième emplacement : la révision nocturne des noyaux — désactivée

Les noyaux sont des sujets qui vivent plus longtemps qu'une seule réunion. Chaque noyau a son essence, sa chronique, ses personnes, ses décisions. Problème : le même sujet est appelé avec des mots différents. Exemple tiré d'un document d'architecture du dépôt : configurer l'accès à l'API et obtenir un jeton d'authentification — c'est le même travail, deux noyaux, deux chroniques incomplètes.

La révision fonctionnait en deux étapes : bge-m3 rassemblait les candidats (cosinus à partir de 0,55), puis le NLI jugeait leur essence dans les deux sens avec quatre résultats possibles : doublon (les deux sens au-dessus de 0,8 — candidat à la fusion) ; doublon possible (0,72–0,8 — marquage) ; inclusion (un sens au-dessus de 0,85, l'autre en dessous de 0,5 — sujet étroit dans un sujet large) ; frontière (les deux sens au-dessus de 0,45 — sujets voisins). Un noyau avec trois inclusions était considéré comme un hub et laissé intact.

En août, tout semblait bien aller : 284 noyaux actifs, 40186 paires, 1806 passant le préfiltre, révision en 6 minutes. En octobre, le nombre de noyaux dépassait 1000. La révision du 27 septembre a buté sur le plafond nocturne après 3,5 heures et a laissé 824 noyaux pour les nuits suivantes. Les dossiers (synthèses par sujet) ne se sont pas constitués du tout pendant huit nuits sur douze.

Il a examiné dix paires aléatoires avec un haut niveau de confiance que la révision se préparait à fusionner. Zéro vrai doublon parmi elles. Une seule douteuse.

Confiance des fausses paires : 0,93–1,00. L'explication : tous les noyaux n'ont pas leur propre essence. S'ils n'en ont pas, la révision récupère un statut générique du type « Discussion des exigences et des particularités ».

Deux sujets de travail différents avec le même statut générique — et le NLI dit : ces phrases découlent l'une de l'autre. Oui, elles en découlent, car c'est la même phrase. Le modèle a fait son travail correctement, mais c'est une erreur de données, pas de modèle.

239 marquages de doublons possibles s'étaient accumulés dans le graphe, zéro traité : personne n'ouvrait la note de service contenant les marquages.

Le 5 octobre, il a tout désactivé d'une ligne dans la configuration. La fusion automatique n'avait jamais été activée, mais désormais c'est clair : elle aurait collé des sujets de travail différents, et la suggestion en réunion aurait affiché le statut d'une tâche étrangère. La sauvegarde de la fusion vit une semaine, personne ne la consulte — en pratique, c'est irréversible.

Quatrième emplacement : le portail avant l'éclair — n'a pas aidé

Le bouton ⚡ (réponse rapide) se déclenche sur une question venant juste d'être posée à l'appel. Un filtre structurel trouve un candidat dans le fil, le modèle local rédige une réponse en quelques secondes. Mais parfois le candidat n'est pas une question : la personne a reposé la question, réfléchi à voix haute, ou interrompu sa phrase. Le modèle répond « je ne vois pas de question », temps perdu.

Il voulait, avant le modèle, un juge moins coûteux et sans fine-tuning : deux hypothèses affirmatives (les modèles fonctionnent moins bien avec des négations) : « L'interlocuteur pose une question et attend une réponse » et « L'interlocuteur reformule, réfléchit à voix haute ou interrompt sa phrase ». Cascade : confiant — il décide seul, incertain — il transmet au modèle.

En mode fantôme : le juge calculait en parallèle et ne décidait de rien, il écrivait seulement dans le journal. Quatre réunions, 117 répliques. Le modèle a répondu à 115, a refusé sur 2 — soit 1,7 %, le plafond de ce que le portail pouvait économiser même dans l'idéal.

Mais le NLI n'était pas idéal. Précision par rapport à la référence : 55,6 %, presque pile ou face. Mauvaise calibration, il est confiant nettement plus souvent qu'il n'a raison. Appel médian : 99 ms. Vérification des seuils :

| Seuil | Éliminé | Vide retiré | Questions perdues | |-------|----------|--------------|-------------------| | 0,60 | 31,6 % | 1 sur 2 | 31,3 % | | 0,70 | 17,9 % | 1 sur 2 | 17,4 % | | 0,80 | 9,4 % | 0 | 9,6 % | | 0,90 | 0 | 0 | 0 |

Quel que soit le seuil qui élimine réellement quelque chose, il perd de vraies questions des dizaines de fois plus souvent qu'il ne retire du vide. La règle de clôture avait été notée une semaine avant la mesure : si le vide représente moins de 15 %, clore le sujet. Résultat : 1,7 %. Le 6 octobre, le mode fantôme a été désactivé.

Ce qui a cassé

Le plus désagréable, c'est l'échec silencieux. Première fois : les modèles se trouvent à la racine des données, mais le code cherchait le modèle NLI à côté de lui-même, à la racine du code. Dans le dépôt du développeur, les deux racines coïncident, le défaut était invisible. Dans une installation où les données se trouvent ailleurs, le modèle n'était pas à ce chemin. Une règle était en place : pas de modèle sur le disque — déduplication désactivée. Aucune erreur, aucun avertissement, le fil se remettait simplement à répéter. Remarqué non pas via le fil, mais lors d'une revue. Arrivé deux fois. Désormais, le chemin est calculé au moment de l'appel.

Deuxième fois — dans la révision des noyaux, également deux fois de suite. Le juge se chargeait mais ne pouvait pas juger, et la révision considérait quand même l'exécution comme réussie : aucune paire trouvée, le marquage était déplacé, les noyaux récents sortaient totalement de la vérification. Un zéro signifiait pour la révision « non similaires » au lieu de « rien à juger ». Désormais, l'échec du juge est une exception, et non un zéro.