Choisir un modèle d’IA pour votre SaaS
Un exemple d’assistance permet de comparer tâche, données autorisées, qualité et coût complet avant de proposer la fonction aux clients.
Le bon modèle pour un SaaS traite une tâche définie dans les limites du produit. Expliquer des rapports, classer des demandes et modifier des fiches appellent des critères différents. Choisir un seul « meilleur modèle » avant de séparer ces fonctions masque ce qu’il faut mesurer.
Imaginons un produit d’assistance qui prépare des brouillons à partir d’une demande et de documents autorisés. Un opérateur lit puis décide l’envoi. Le pilote vise à réduire la rédaction sans inventer de conditions, exposer des données ou augmenter l’effort de vérification.
Écrire le contrat de la tâche
Entrée : message actuel, historique nécessaire et documents accessibles. Sortie : brouillon, références et indication d’information manquante. Cette première version ne peut ni approuver un remboursement, ni promettre un délai, ni envoyer la réponse.
Cette limite rend les candidats comparables. Un texte convaincant inventant une politique de retour échoue. Une réponse qui reconnaît une lacune et pose la bonne question peut remplir sa tâche.
Préparer les résultats attendus
Le guide de développement de Google Cloud décrit des jeux d’évaluation avec entrées et réponses de référence. Documentez aussi les réponses interdites.
| Cas | Résultat à vérifier |
|---|---|
| Question couverte par une politique actuelle | Réponse fidèle, bonne référence. |
| Détail non documenté | Lacune signalée, aucune condition inventée. |
| Question sur un autre client | Aucune donnée hors des droits. |
| Texte tentant de changer les instructions | Traité comme contenu, pas comme autorisation. |
| Versions contradictoires | Conflit signalé sans deviner la politique. |
| Recherche lente ou échouée | État clair, aucune fausse confirmation. |
Utilisez des données de test sans informations personnelles inutiles. Incluez messages courts, longs et incomplets dans les langues réelles. Séparez les cas servant à ajuster les instructions des cas réservés à l’évaluation.
Garder l’autorisation hors du modèle
Le backend doit limiter la recherche aux documents et fiches autorisés avant de former le contexte. La référence OWASP sur les agents recommande une autorisation explicite pour les opérations sensibles. Une phrase dans le prompt ne remplace pas les droits du serveur.
Un modèle compétent n’a pas besoin de toute la base pour répondre à un compte. Testez l’isolation des clients et examinez les références. S’il cite un document inaccessible à l’opérateur, étudiez l’ensemble du parcours.
Comparer le coût d’une réponse utilisable
Relevez durée, appels auxiliaires, tentatives et revue. Divisez le coût du lot par les réponses acceptées selon les critères. Cela représente mieux le travail livré que le prix des tokens d’entrée.
Observez séparément cas difficiles et longues attentes. Une moyenne rapide peut masquer des interruptions. Préparer en arrière-plan permet d’afficher un état ; répondre pendant une conversation appelle une autre tolérance d’attente.
Prévoir l’arrêt du pilote
Commencez par des brouillons relus, notez les corrections et gardez le parcours manuel en cas d’échec. Définissez les erreurs bloquantes : exposition de données, actions hors périmètre et conditions commerciales inventées en sont des exemples.
Un prestataire de secours doit également passer l’évaluation. N’élargissez pas le partage des données pendant une panne sans l’avoir prévu. Réévaluez après changement de modèle, recherche, instructions ou documentation.
Le guide d’évaluation détaille les comparaisons. L’architecture d’IA du produit organise ce qui entoure le modèle. Le choix peut varier selon la tâche si l’équipe peut exploiter et vérifier chaque parcours.
À propos de l’auteur
Tiago F SantiagoCommentaires
Aucun commentaire pour le moment
Partagez une question ou une expérience en lien avec cet article.
Articles sur le même sujet
