Fine-tuning, RAG ou prompt : l'arbitrage de gouvernance des données
Il y a trois façons de donner votre domaine à un modèle généraliste. Vous pouvez le fine-tuner, en cuisant vos données dans les poids. Vous pouvez faire de la recherche documentaire, en allant chercher vos données à l'exécution et en les donnant au modèle comme contexte. Ou vous pouvez prompter, en décrivant votre domaine dans les instructions à chaque appel. La plupart des équipes choisissent sur la capacité et le coût : lequel rend le modèle le plus précis, pour le moins d'argent et d'effort.
Sauf que dans une entreprise réglementée, ce sont les questions secondaires. La première est de savoir où vos données réglementées finissent par vivre, parce que ce seul fait décide si vous pouvez auditer le système, supprimer les données d'une personne sur demande, et mettre à jour votre connaissance métier sans projet de réentraînement. Le choix entre fine-tuning, RAG et prompting est une décision de gouvernance des données déguisée en ingénierie. Choisissez sur la seule précision et vous pouvez vous enfermer dans une architecture où une demande d'effacement de routine implique de réentraîner un modèle.
La bonne manière de choisir est d'arrêter de demander quelle technique est la plus capable et de commencer à demander où chacune place vos données réglementées, et ce que cet emplacement coûte quand un régulateur, un client ou votre propre processus de changement se manifeste.
Où vivent les données : cuites, récupérées ou en contexte
Les trois approches diffèrent sur un axe qui gouverne tout le reste : la persistance et l'emplacement de vos données réglementées par rapport au modèle.
Le fine-tuning cuit les données dans les poids. Vous prenez des exemples de votre domaine, contenant souvent de vrais enregistrements, et vous entraînez le modèle dessus. Après l'entraînement, cette information est diffusée à travers des milliards de paramètres. Ce n'est plus un document que l'on peut pointer. C'est un résidu statistique réparti dans le modèle, et le modèle peut le reproduire dans une sortie sans jamais l'avoir « récupéré », parce qu'il n'a jamais été stocké comme une chose récupérable. C'est la forme d'enseignement la plus intime, et la moins réversible.
Le RAG garde les données dans un stockage que le modèle lit à l'exécution. Votre contenu réglementé reste dans une base ou un index qui vous appartient. Au moment de la requête, le morceau pertinent est récupéré et placé dans la fenêtre de contexte, utilisé pour cette seule réponse, puis disparu du point de vue du modèle. Les poids du modèle ne changent jamais. Les données vivent là où vous les avez mises, sous vos contrôles d'accès, et le modèle les emprunte brièvement.
Le prompting place les données dans l'instruction, en contexte, à chaque appel. Rien ne persiste. La connaissance métier est décrite ou fournie dans le prompt, utilisée pour cette seule inférence, puis jetée. C'est l'option la plus transitoire : le modèle apprend votre domaine le temps d'un appel d'API et l'oublie complètement ensuite.
Même objectif, trois profils de gouvernance des données radicalement différents. Le reste de la décision découle de cette seule distinction.
Auditabilité et droit à l'effacement : les questions qu'un régulateur posera vraiment
Deux obligations exposent la différence nettement, et toutes deux sont de routine dans une maison réglementée.
Prenez l'auditabilité. Un régulateur demande : quelles informations le système a-t-il utilisées pour arriver à cette décision, et pouvez-vous me les montrer ? Avec le RAG, la réponse est propre. Vous avez récupéré ces documents précis, à cette version d'index, et la décision en a été dérivée ; la piste de preuves nomme les sources. Avec le prompting, c'est tout aussi propre : le contexte a été assemblé à partir de ces entrées, les voici. Avec un modèle fine-tuné, la réponse honnête est inconfortable. La décision s'est appuyée sur une connaissance diffusée dans les poids pendant l'entraînement, et vous ne pouvez pas pointer l'enregistrement précis qui l'a façonnée. Vous pouvez décrire le jeu d'entraînement ; vous ne pouvez pas remonter d'une sortie précise à une entrée précise. Pour un processus où chaque décision a besoin d'une base inspectable, c'est un problème structurel, pas une lacune documentaire.
Prenez maintenant le droit à l'effacement. Une personne exerce son droit à la suppression de ses données. Si son enregistrement était dans un stockage RAG, vous le supprimez et il disparaît des récupérations futures, immédiatement et de façon prouvable. S'il n'a jamais été que dans des prompts, il n'a jamais persisté ; il n'y a rien à effacer. Mais si ses données ont été cuites dans un modèle fine-tuné, les supprimer est réellement difficile. L'information est enchevêtrée dans les poids, et il n'existe pas d'opération propre pour retirer la contribution d'une seule personne, sinon réentraîner sans elle, ou appliquer des techniques de désapprentissage machine encore immatures et difficiles à prouver à un superviseur. Un droit que vous devez honorer en quelques jours peut heurter un modèle que vous réentraînez en quelques semaines.
Ni l'un ni l'autre ne rend le fine-tuning mauvais. Ils en font un engagement dont le coût complet n'apparaît que plus tard, exactement au moment où une organisation réglementée peut le moins se permettre une surprise.
Coût de mise à jour : à quelle vitesse votre connaissance métier peut-elle changer ?
Il y a un troisième axe pratique, celui qui mord opérationnellement plutôt que juridiquement : combien coûte le changement de ce que le modèle sait ?
La connaissance métier dans une activité réglementée n'est pas statique. Une politique est révisée, un seuil bouge, une règle est remplacée. La façon dont chaque approche absorbe ce changement diffère d'ordres de grandeur. Mettre à jour un corpus RAG est une opération documentaire : remplacer la source, réindexer, fini, et le changement est actif dès la requête suivante. Mettre à jour un prompt est une édition de texte et un redéploiement de l'instruction. Mettre à jour une connaissance qui vit dans des poids fine-tunés veut dire un nouvel entraînement, une revalidation et une release contrôlée d'une nouvelle version de modèle. Les deux premiers sont des heures. Le troisième est un projet.
C'est là que l'obsolescence devient un risque de gouvernance plutôt qu'un désagrément. Si votre connaissance réglementée change plus vite que vous ne pouvez réentraîner, un modèle fine-tuné qui encode cette connaissance dérive hors conformité entre deux entraînements, et rien dans son comportement ne l'annonce. Le RAG et le prompting gardent le contenu réglementé et mouvant dans une couche que vous pouvez mettre à jour à la vitesse à laquelle les règles changent réellement.
Un cadre de décision pour une équipe réglementée
Rien de tout cela ne se réduit à « utilisez toujours le RAG ». Cela se réduit à faire correspondre la technique à ce que sont les données et à la façon dont elles se comportent.
Le cadre qui tient devant un comité des risques consiste à séparer deux choses dont le modèle a besoin. Il a besoin de compétences, la compétence générale et stable pour lire un document, suivre un format, raisonner sur une tâche structurée. Et il a besoin de faits, le contenu spécifique, changeant et souvent réglementé sur lequel il raisonne. Mettez les deux à des endroits différents.
Le fine-tuning est défendable pour enseigner des compétences durables et non sensibles : un style maison, un schéma de sortie, un motif de raisonnement qui ne change pas et ne porte aucune donnée personnelle. C'est un mauvais endroit pour des faits, et un endroit dangereux pour des faits réglementés, précisément à cause de l'auditabilité, de l'effacement et du coût de mise à jour. Les faits réglementés appartiennent au RAG, où ils restent inspectables, supprimables et à jour, sous un contrôle d'accès appliqué au moment de la récupération. Et le prompting porte le contexte transitoire, appel par appel, qui ne persiste pas et n'a pas à persister. La plupart des systèmes réglementés robustes utilisent les trois délibérément, avec une règle claire sur quel type d'information a le droit de vivre où, plutôt que de saisir celui qui paraissait le plus précis en démo.
La question à trancher avant de choisir une technique n'est donc pas « quelle approche rend le modèle le plus précis ? ». C'est : quelles données réglementées cette approche nous ferait-elle stocker, où vivraient-elles, et pouvons-nous les auditer, les supprimer et les mettre à jour à la vitesse qu'exigent nos obligations ? Répondez d'abord, et la précision devient un choix que vous faites à l'intérieur d'une conception sûre, au lieu d'être la raison pour laquelle vous vous êtes retrouvé dans une conception dangereuse.
Si vous voulez cartographier quelle partie de votre connaissance métier appartient aux poids, à la recherche documentaire ou au prompt, prenez rendez-vous et apportez-nous le processus qui contient le plus de données réglementées.