Choisir entre RAG ou fine tuning revient à déterminer ce que votre assistant doit faire. Le RAG, abréviation de retrieval-augmented generation, fournit des sources pertinentes lorsque le modèle répond ; le fine tuning consiste à poursuivre l’entraînement d’un modèle sur des exemples. Commencez par tester une consigne claire, ou prompt. Utilisez ensuite le résultat pour décider s’il faut examiner le manque de sources, l’irrégularité des sorties ou les deux avant de commander des travaux supplémentaires.
Un fournisseur propose d’entraîner un système d’IA pour votre entreprise, tandis qu’un autre propose une base de connaissances interrogeable. Ces descriptions ne définissent ni la tâche que le système final doit accomplir ni ce qui constituerait un échec. Nous commençons par consigner cette tâche par écrit. Vous disposez ainsi d’un élément concret pour comparer les propositions à leur arrivée.
Que changent le RAG et le fine tuning ?
Le RAG modifie les éléments fournis pour produire une réponse ; le fine tuning modifie le modèle par l’entraînement. Le guide d’OpenAI sur la précision distingue le manque de contexte d’un comportement irrégulier. C’est une distinction initiale utile pour un acheteur, à condition de laisser une place aux besoins qui se recoupent. Un assistant fondé sur des documents peut aussi devoir rédiger ses réponses de manière cohérente.
Selon l’explication d’Amazon Bedrock sur les bases de connaissances, la recherche sélectionne les éléments pertinents et les inclut dans l’entrée de génération. Pour un assistant censé répondre à des questions sur une politique de retour, demandez à voir quel passage approuvé étaye la réponse. Une référence de source doit encore être comparée au contenu de la réponse.
Le fine tuning utilise des exemples pour poursuivre l’entraînement d’un modèle sur la manière de répondre. Le guide d’OpenAI le présente comme une option pour améliorer le comportement sur une tâche. Prenez une note de transmission souhaitée, avec une structure convenue : le fournisseur a besoin d’exemples de notes acceptables et des entrées utilisées pour les produire. Ce livrable diffère d’un dossier de documents de politique interne.
Aucune des deux étiquettes ne vous indique si la démonstration satisfait vos exigences. Demandez au fournisseur de préciser ce que modifie le composant proposé, de montrer les éléments qu’il utilise et d’expliquer comment vous vérifierez le résultat. Maintenez la discussion centrée sur le travail que vous achetez réellement.
Commencez par une tâche et une démonstration simple
Décrivez l’entrée et la sortie acceptable avant de choisir une approche. Le guide d’Anthropic sur les prompts commence par des critères de réussite clairs, un test fondé sur des exemples et une première version du prompt. Nous suivons cet ordre pour préparer un cahier des charges d’achat : rédigez la consigne, fournissez les éléments approuvés et examinez ce que peut faire la configuration proposée la plus simple. Il s’agit de notre méthode d’évaluation suggérée, pas d’une évaluation comparative réellement menée.
Pour illustrer le cas d’un assistant de gestion des retours, l’entrée pourrait être la question d’un client et la politique applicable. Une réponse acceptable ne répond qu’à partir de ce que cette politique permet d’affirmer et transmet les exceptions à une personne. Pour illustrer une transmission commerciale, l’entrée pourrait être une demande et un format de note approuvé. La sortie doit préserver le sens de la demande et laisser les informations manquantes non renseignées.
Demandez au responsable du processus de définir ce qui rend chaque sortie acceptable. Incluez une demande que l’assistant devrait refuser ou transmettre. Utilisez des éléments que vous êtes autorisé à partager, après avoir supprimé les données personnelles inutiles. Une démonstration qui dépend d’informations que vous ne pouvez pas fournir ne constitue pas encore une proposition réalisable.
Si vous disposez déjà d’un assistant qui donne des réponses peu fiables, consultez le guide distinct pour vérifier pourquoi l’IA donne de mauvaises réponses avant de décider quoi commander.
Choisissez le prochain test selon l’écart restant
Appuyez-vous sur l’échec observé pour choisir le prochain test. AWS recommande de commencer par la recherche pour les questions qui font référence à des documents personnalisés et souligne la difficulté de maintenir l’entraînement en phase avec des éléments qui changent fréquemment. AWS permet aussi de combiner recherche et fine tuning. Le tableau ci-dessous suggère un prochain test pour l’écart constaté lors de votre démonstration.
| Ce qui manque encore à la démonstration | Ce qu’il faut tester ensuite |
|---|---|
| Des informations provenant de documents approuvés et évolutifs | Une recherche qui fournit les éléments actuels pertinents |
| Une sortie reproductible qui reste irrégulière après des consignes et des exemples plus clairs | Un entraînement sur des exemples acceptés, si le modèle choisi le permet |
| Des sources et une réponse plus cohérente | Une configuration combinée, avec une vérification pour chaque exigence |
Lorsque la démonstration la plus simple satisfait déjà les exigences, conservez cette option dans la comparaison. Demandez quel problème supplémentaire résoudrait l’entraînement ou le système de recherche proposé. Le choix peut aussi rester ouvert pendant que vous préparez les entrées manquantes.
AWS indique que le fine tuning n’est pas disponible pour tous les modèles. Demandez au fournisseur de nommer le prestataire et le modèle, d’expliquer où et comment le système fonctionnera, et de confirmer la prise en charge actuelle de l’entraînement et du déploiement proposés.
Qui assure la maintenance après le lancement ?
Comparez les responsabilités que chaque proposition laisse à votre équipe. Pour la recherche, nommez la personne qui approuve les documents sources et vérifie que les mises à jour parviennent à l’assistant. Pour l’entraînement, nommez la personne qui prépare les exemples acceptés et examine les modifications ultérieures. Consignez qui accorde les accès, qui gère les défaillances et comment le personnel revient au processus manuel lorsque le système ne convient pas.
Nous intégrons ces questions à la planification de la mise en oeuvre de l’IA avant de choisir les composants. Un cahier des charges utile consigne :
- La tâche, les entrées autorisées et la sortie attendue.
- Les sources faisant autorité, leur responsable et leur processus de mise à jour.
- Des exemples de travail acceptable et d’omissions ou d’ajouts inacceptables.
- Les conditions de refus d’une demande ou de transmission à une personne.
- Les vérifications d’acceptation, le responsable de la vérification et les éléments à remettre.
Pour un travail portant sur une commande active ou une fiche de contact, demandez comment le système proposé obtiendra la fiche actuelle autorisée. Intégrez cette exigence à la partie intégration CRM du cahier des charges. Une proposition visant à entraîner le système sur des fiches exportées doit toujours expliquer comment seront gérées les modifications ultérieures.
Demandez où seront stockés les documents, les copies interrogeables, les exemples et les sorties, qui pourra y accéder et comment leur suppression sera gérée. Consignez les réponses pour le déploiement réel. Ne considérez le nom d’aucune architecture comme une décision concernant l’hébergement ou les autorisations.
Vérifiez la proposition sur des demandes inédites
Écartez les demandes de test des éléments utilisés pour configurer ou entraîner le système proposé. Demandez à chaque fournisseur de traiter ces demandes selon les mêmes critères d’acceptation. Faites examiner par le responsable du processus les sorties, les entrées qui ont servi à les produire et les corrections nécessaires. Cela vérifie la proposition sur votre tâche, sans prouver ses performances sur toutes les futures demandes.
- Conservez une référence. Enregistrez ce que produisent le processus manuel et le prompt le plus simple, avec leurs entrées et les notes d’examen.
- Vérifiez une mise à jour de source. Modifiez un document de test approuvé et répétez la question concernée. Demandez au fournisseur de montrer quelle version a été utilisée et comment la mise à jour lui est parvenue.
- Vérifiez les règles de sortie. Reformulez une demande et omettez certaines informations. Vérifiez si la note conserve la structure requise sans inventer de détail.
- Testez l’accès et le périmètre. Essayez une demande hors du périmètre convenu et un utilisateur qui ne devrait pas recevoir un document restreint. Examinez le refus ou la transmission réellement produit.
- Consignez le travail que votre équipe doit continuer à effectuer. Notez les corrections, le temps d’examen et la personne chargée de maintenir les éléments. Comparez-les à la référence avant d’étendre le travail.
Lorsqu’une vérification échoue, consignez l’exigence non satisfaite et demandez une démonstration révisée. Ne payez pas pour une approche plus élaborée au seul motif que son nom paraît plus performant. Acceptez le périmètre que vous pouvez vérifier, ou confiez encore la tâche à des personnes pendant la résolution des conditions manquantes.
Notre intervention
Nous commençons par rédiger ensemble la tâche, les données autorisées et les vérifications d’acceptation. Nous comparons ensuite les approches proposées à ce cahier des charges et précisons qui assurera la maintenance des sources, des exemples et de l’évaluation. Une première étape utile consiste à rédiger une demande réelle et à approuver un exemple du résultat dont vous avez besoin.
