Intégrations IA

Ce qui est inclus dans la prestation d'intégration de l'IA

Nous concevons et écrivons la couche logicielle qui relie les modèles de langage aux processus métier réels du client : traitement des demandes, analyse de documents, recherche dans la base de connaissances, classification des requêtes. D'abord, nous analysons où, dans le processus, du temps est perdu ou des erreurs surviennent, et nous décrivons quelles tâches précises confier au modèle et lesquelles laisser à l'humain. Ensuite, nous assemblons l'intégration : nous connectons le LLM via l'API, nous configurons le stockage des embeddings, nous écrivons la logique de routage et de traitement des réponses. Si le client dispose d'un équipement piloté, par exemple une ligne de découpe, un poste de soudage ou des engins d'entrepôt, c'est précisément son équipement qui découpe, soude et transporte, et nous, nous préparons le programme de pilotage, la transmission des ordres et la vérification du résultat. À l'arrivée, le client reçoit un circuit opérationnel, et non une expérimentation ponctuelle avec un chatbot.

Comment fonctionne l'intégration, au fond

Le modèle de langage, en lui-même, ne connaît pas le contexte de l'entreprise, c'est pourquoi la part essentielle du travail se situe autour de lui, et non en son sein. Les documents et les enregistrements du client sont découpés en fragments et traduits en embeddings, c'est-à-dire en vecteurs numériques, grâce auxquels le système trouve des correspondances de sens, et non de simples correspondances de mots. Lors de la requête de l'utilisateur, les fragments nécessaires sont remontés depuis le stockage vectoriel et transmis au modèle avec une instruction, pour que la réponse se construise sur les données de l'entreprise, et non sur les connaissances générales du modèle. Par-dessus s'exécute la logique : vérification du format de la réponse, restrictions, transmission du résultat au CRM, à la base ou au pilotage de l'équipement. Ce schéma réduit les inventions du modèle et rend le comportement prévisible.

D'où ont grandi les réseaux de neurones et l'IA

Le point de départ des réseaux de neurones appliqués, c'est 1958, lorsque Frank Rosenblatt a décrit le perceptron, le modèle le plus simple, qui apprenait à répartir les données en classes. Pendant des décennies, le développement a procédé par vagues, avec des périodes de déclin, jusqu'à ce qu'en 2017 un collectif de chercheurs de Google publie le travail « Attention Is All You Need » et l'architecture du transformeur, qui a renoncé au traitement séquentiel au profit du mécanisme d'attention. Sur cette architecture est sorti en 2018 le BERT de Google, et la gamme GPT d'OpenAI a porté l'approche jusqu'aux grands modèles génératifs. Il importe de voir que la percée n'a pas été donnée par le simple fait de l'IA, mais par une idée d'ingénierie concrète : le traitement des séquences dans leur ensemble. Nous nous appuyons sur cette lignée lorsque nous choisissons quel modèle intégrer dans le processus, et comment.

Pourquoi la précision du paramétrage est déterminante

Entre la démonstration d'un modèle et un système opérationnel se trouve précisément la partie logicielle, et le prix de l'erreur y est plus élevé qu'il n'y paraît. Un contexte mal assemblé, un prompt faible ou une recherche par embeddings mal configurée donnent une réponse plausible, mais fausse, qu'il est facile de laisser passer dans un flux de demandes. Dans les intégrations avec l'équipement du client, c'est doublement critique : la commande de pilotage doit être strictement dans la tolérance, sinon la machine exécutera une mauvaise trajectoire, c'est pourquoi nous passons la logique sur un environnement de test avant de la transmettre au matériel réel. La précision signifie ici la reproductibilité, le contrôle du format des données et le traitement des cas limites, et non une promesse abstraite. C'est pourquoi, dans l'intégration de l'IA, l'essentiel du travail va non pas à la connexion du modèle, mais à son habillage et à sa vérification.

Stack et outils de l'intégration de l'IA

La couche de base, c'est l'appel aux modèles de langage via l'API : des requêtes au LLM avec pilotage de la température, limitation de la longueur et instructions système, ce qui donne du texte en entrée et du texte en sortie pour une tâche précise. Pour la compréhension du sens, nous utilisons les embeddings et les stockages vectoriels, afin que le système cherche par signification, et non par correspondance exacte des formulations. Le code de liaison, nous l'écrivons dans les langages habituels du backend, le plus souvent Python et JavaScript, et nous intégrons les appels aux processus existants via les interfaces REST et l'échange de données au format JSON. L'intégration aux processus signifie la connexion au CRM, aux bases, aux files de tâches et, au besoin, aux contrôleurs de l'équipement du client, qui exécute physiquement le travail. La stack, nous la sélectionnons selon l'infrastructure du client, et non l'inverse.

Quand sont apparus les standards de référence

Les outils sur lesquels repose l'intégration moderne ont des dates concrètes, et non une histoire floue. Le style architectural REST, base de la plupart des interfaces web d'échange de données, a été décrit par Roy Fielding dans sa thèse de 2000 à l'université de Californie à Irvine. L'approche des embeddings sous sa forme actuelle a été posée par word2vec, publié par l'équipe de Tomáš Mikolov chez Google en 2013, qui a montré que les mots peuvent être représentés par des vecteurs denses conservant les liens de sens. L'accès aux grands modèles via une interface cloud est devenu massif le 11 juin 2020, lorsque OpenAI a ouvert l'API de GPT-3 selon le principe « texte en entrée — texte en sortie ». Ces trois piliers — le standard d'échange, les représentations vectorielles et l'API des modèles — forment le fondement de la prestation.

Pourquoi vous pouvez nous le confier

L'expérience cumulée de notre équipe de développement dépasse 45 ans dans l'IT, et cela signifie l'habitude de mener un système jusqu'à l'état où il fonctionne en charge, et pas seulement en démonstration. Nous procédons en ingénieurs : nous fixons les exigences, nous assemblons le circuit, nous le passons sur des données de test et des cas limites, et seulement après nous le mettons en mode production. Là où les intégrations de l'IA touchent à l'équipement, nous vérifions séparément les commandes de pilotage sur banc, parce qu'il est impossible autrement de répondre du résultat sur le matériel réel du client. Nous ne produisons pas de machines et nous n'imprimons pas de pièces nous-mêmes — nous écrivons le programme et configurons l'équipement déjà installé chez le client, et nous répondons de la justesse de cette partie. Cet ordre écarte le risque des erreurs silencieuses et rend le lancement contrôlé.