Reprendre un système d'IA construit par quelqu'un d'autre

Reprendre un système d’IA hérité consiste à diagnostiquer, puis à corriger, un système conçu par une autre équipe, et l’ordre dans lequel on inspecte ses couches décide du temps qu’on y passe. Corpus d’abord, récupération ensuite, prompt en troisième, et jamais l’inverse.

Un système documentaire comporte cinq couches. Le corpus qu’on lui donne, la récupération qui sélectionne, le prompt qui cadre, le périmètre qui borne, et les coûts qui contraignent. Les problèmes remontent presque toujours des deux premières.

Le reste de cet article déroule ces cinq étapes dans l’ordre, puis les erreurs fréquentes et les livrables qui évitent que la reprise suivante reparte de zéro.

Ouvrir le prompt en premier est le réflexe naturel lors de la reprise d’un système d’IA, et la principale cause de reprise interminable. Le prompt est visible, lisible, modifiable : il attire l’attention alors qu’il est rarement la cause.

Modifier le prompt sans avoir vérifié les deux couches en amont produit un cycle familier : on corrige un cas, on en casse deux autres, on ajoute une règle, le prompt double de taille, et la cause initiale reste en place.

Devant une réponse fausse, la seule question utile est : l’information correcte figurait-elle dans ce qui a été fourni au modèle ? Si oui, le problème est dans le prompt ou le modèle. Si non, il est dans la recherche ou le corpus. Ce sont deux corrections opposées, et seule une trace des extraits envoyés permet de trancher.

Trois questions sur le corpus d’un système d’IA hérité expliquent la majorité de ses mauvaises réponses, et elles se posent sans lire une ligne de code. C’est l’étape un.

Combien de documents, et de quand datent-ils ? Un corpus indexé une fois il y a dix-huit mois répond sur des procédures abrogées, avec assurance et sans aucun signal.

Existe-t-il plusieurs versions d’un même document, et laquelle fait autorité ? C’est la question qui révèle le plus souvent la cause profonde. Si personne ne sait répondre, le système ne peut pas le savoir non plus.

Les droits d’accès sont-ils appliqués, et à quel moment ? S’ils sont appliqués après la recherche, ce n’est pas une protection.

Ces trois réponses situent le travail avant toute intervention technique. C’est le principe posé dans le corpus est le projet. Si le corpus est sain mais que les documents sont découpés au milieu des tableaux ou des listes, le problème se situe à la frontière avec l’étape suivante, comme l’explique découper un document, le choix qui décide de tout.

Un prompt système hérité contient presque toujours des règles ajoutées après incident, dont plus personne ne connaît la raison, et dont certaines se contredisent. C’est ce qu’on cherche à l’étape trois.

La méthode est simple : lire le prompt en entier, et pour chaque règle, se demander quel incident l’a produite. Les règles dont personne ne peut expliquer l’origine sont candidates au retrait, mesuré sur le jeu de tests.

Le cas le plus fréquent est la contradiction. Une règle demande de toujours citer la source, une autre ajoutée six mois plus tard demande d’être concis. Le modèle arbitre comme il peut, de façon instable.

Le second cas est la règle qui compense un défaut amont : « si tu ne trouves pas l’information, cherche dans les documents connexes ». Cette instruction masque un problème de récupération et produit des réponses fondées sur des documents non pertinents. Le cadre de réécriture figure dans écrire un prompt système qui tient six mois.

Deux questions closent le diagnostic d’un système d’IA hérité : que fait ce système quand il ne sait pas, et combien coûte-t-il par mois et par fonctionnalité. Elles sont presque toujours sans réponse.

Le comportement en cas de doute détermine la confiance des utilisateurs. Un système qui invente plutôt que de refuser produit des erreurs indétectables, et son abandon suit de quelques mois. Le principe est développé dans le refus de répondre est une fonctionnalité.

Le coût par fonctionnalité révèle les gaspillages. Sur les systèmes hérités que je reprends, il n’est presque jamais mesuré, et le premier relevé montre souvent qu’un petit nombre de postes concentre l’essentiel de la facture : c’est un repère de pratique, pas une loi, mais il oriente bien la recherche. Les postes à examiner sont détaillés dans le coût réel d’un système d’IA en production.

Ces deux questions se traitent après les trois premières, parce qu’elles supposent de savoir ce que le système fait réellement.

Les erreurs qui allongent la reprise d’un système d’IA viennent presque toutes d’une intervention trop rapide sur la couche la plus visible, avant d’avoir établi un point de référence. Elles se reconnaissent facilement.

• Réécrire le prompt dès le premier jour. On perd la trace de ce que faisait l’ancienne version, et on ne peut plus mesurer si l’on progresse.
• Changer de modèle pour régler un problème de corpus. Un meilleur modèle répond mieux sur de mauvais documents, ce qui rend l’erreur plus convaincante, pas plus rare.
• Réindexer tout le corpus sans trancher les versions concurrentes. Les doublons reviennent à l’identique dans le nouvel index.
• Corriger cas par cas les signalements des utilisateurs. Chaque correction isolée déplace le problème ; seul le jeu de tests montre l’effet global.
• Supprimer d’un bloc les règles inexpliquées. Le retrait se fait une règle à la fois, mesuré à chaque étape.

Quand l’équipe qui reprend n’a pas le recul nécessaire, un audit de système d’IA déroule ce diagnostic de l’extérieur et remet un ordre de priorité.

À la fin d’une reprise de système d’IA, un jeu de tests, une note d’une page sur le système et la liste datée des décisions prises évitent que la reprise suivante reparte de zéro. Ils coûtent une journée sur un chantier de plusieurs semaines.

Le jeu de tests est le plus important parce qu’il survit à l’équipe. Il permet à la personne suivante de modifier sans casser, ce qui est exactement ce qui manquait au départ.

La note d’une page décrit la finalité, les données, la décision servie et le dispositif de supervision. Elle sert à la conformité et, plus prosaïquement, à comprendre le système dans deux ans.

La liste des décisions, quel palier pour quelle tâche, quel seuil, quel comportement en cas de doute, à quelle date, est ce qui distingue un système entretenu d’un système accumulé. C’est la meilleure protection contre la dette décrite dans la dette technique d’un système d’IA.