Catégorie : IA/ML

  • Ingénierie IA pratique : livrer des fonctionnalités LLM qui tiennent

    Ingénierie IA pratique : livrer des fonctionnalités LLM qui tiennent

    Il y a un grand fossé entre une démo qui marche devant un public et une fonctionnalité qui survit à de vrais utilisateurs pendant un mois. J’ai livré quelques fonctionnalités LLM, et presque tout ce que j’ai appris à la dure vit dans ce fossé.

    La démo, c’est les 80 % faciles

    Brancher un modèle et obtenir une bonne réponse prend un après-midi. Le reste, c’est tout ce qui arrive quand l’entrée est bizarre, que le modèle se trompe avec assurance, ou que l’utilisateur demande une chose jamais testée. Cette partie prend les trois semaines restantes, et c’est elle qui décide si quelqu’un continue à utiliser le produit.

    Alors prévoyez-la. Réservez plus de temps à l’évaluation et aux garde-fous qu’au chemin heureux, car le chemin heureux se construit presque tout seul.

    RAG : le difficile, c’est la recherche, pas la génération

    La plupart des fonctionnalités LLM utiles ont besoin de vos données, pas seulement de l’entraînement du modèle. La génération augmentée par la recherche est la réponse standard : trouver les passages pertinents, les mettre dans le prompt, laisser le modèle répondre à partir d’eux. Simple à décrire, délicat à réussir.

    La qualité d’un système RAG, c’est presque entièrement la qualité de sa recherche. Si vous récupérez les mauvais passages, aucune astuce de prompt ne vous sauve. Passez votre temps sur la stratégie de découpage, sur le fait de savoir si vous avez vraiment besoin d’embeddings ou si une recherche par mots-clés suffit pour vos données, et sur la mesure : le contexte récupéré contient-il la réponse, avant même de regarder la génération.

    Un conseil concret : journalisez les passages récupérés pour chaque requête en développement. La moitié de mes bugs RAG étaient évidents dès que je voyais ce que la recherche tirait vraiment.

    On n’améliore pas ce qu’on ne mesure pas

    « Ça a l’air mieux » n’est pas une métrique. Avant de régler quoi que ce soit, constituez un petit jeu d’évaluation : trente à cinquante entrées réelles avec les bonnes sorties connues. Lancez-le à chaque changement. Ça semble excessif jusqu’au jour où un ajustement de prompt « qui améliorait évidemment les choses » casse discrètement un tiers de vos cas.

    Les évaluations n’ont pas besoin d’être sophistiquées. Un tableur d’entrées, de comportements attendus et d’un succès/échec vérifié à l’œil vaut mieux qu’aucune évaluation. Automatisez plus tard, une fois que vous savez ce que vous mesurez.

    Traitez la sortie du modèle comme non fiable

    C’est la leçon qui rejoint la sécurité. La sortie d’un modèle n’est que du texte, et si vous l’injectez dans une requête de base, une commande shell ou un autre système, elle peut faire des dégâts comme une entrée utilisateur. Si un agent lit du contenu non fiable, ce contenu peut porter des instructions, le problème d’injection de prompt que j’aborde dans l’IA agentique en cybersécurité.

    Validez les sorties structurées contre un schéma. Ne passez jamais du texte brut du modèle dans quoi que ce soit qui s’exécute. L’état d’esprit « l’entrée est hostile » de ma checklist de sécurité s’applique directement à ce qui sort du modèle, pas seulement à ce qui entre.

    Coût et latence sont des décisions produit

    Le plus gros modèle est rarement le bon choix par défaut. Un modèle plus petit qui répond en 400 millisecondes bat souvent un plus gros qui prend quatre secondes, car l’utilisateur ressent la latence tout de suite et juge la qualité lentement. Mettez en cache agressivement. Routez les requêtes faciles vers des modèles bon marché et gardez le coûteux pour les cas difficiles.

    Choisissez votre niveau de modèle exprès. Je pars du modèle le plus capable pendant le développement, puis je descends une fois que je sais quels appels ont vraiment besoin de puissance.

    Où cela vous mène

    Livrer des fonctionnalités IA, c’est surtout de l’ingénierie normale avec une composante probabiliste greffée. Le modèle est la partie amusante et la plus petite. La recherche, l’évaluation, la validation et la plomberie autour, c’est le vrai travail. Si vous construisez le système autour de zéro, les patterns de l’architecture full-stack moderne sont là où le modèle doit réellement vivre.