L'équipe veut affiner un modèle ouvert plutôt qu'appeler une API hébergée. Comment trancheriez-vous ?

Décidez sur quatre axes : qualité sur votre tâche précise, coût à votre volume réel, exigences de latence et de contrôle, et contraintes de données ou de conformité. Commencez par l'API hébergée avec du prompting et de la récupération pour établir un niveau de qualité à moindre coût. Affinez quand vous avez une tâche stable avec de bonnes données étiquetées, un volume assez élevé pour que l'économie bascule, ou une obligation de garder les données dans votre propre environnement.

Je pousserais à répondre avec des chiffres plutôt qu'avec une préférence. D'abord, construire la référence hébergée : un bon prompt, de la récupération si la tâche a besoin de contexte, et un jeu d'évaluation. Cela prend en général quelques jours et nous dit quelle qualité est atteignable, et souvent c'est déjà suffisant, auquel cas l'affinage est une solution qui cherche un problème. Si la qualité manque vraiment, je me demande si l'écart porte sur la connaissance, ce que la récupération corrige, ou sur le comportement et le format, ce que l'affinage corrige. Puis l'économie. Le coût hébergé croît linéairement avec les tokens ; l'auto-hébergement est surtout un coût fixe d'accélérateur, donc il existe un volume de bascule, et je le calcule avec de vraies projections de trafic plutôt qu'avec des espoirs. En dessous de la bascule, l'auto-hébergement perd avant même d'avoir compté le temps d'un ingénieur. Le coût qu'on oublie, c'est la possession : le service, l'autoscaling, les mises à niveau, la réévaluation quand on change de modèle de base, quelqu'un d'astreinte. C'est un engagement permanent. Là où ça se décide tout seul, c'est la conformité. Si les données ne peuvent pas quitter notre environnement, la décision est déjà prise et la discussion porte seulement sur quel modèle ouvert, pas sur le principe.