Petits modèles de langage ou outils traditionnels

Dans les opérations marketing, « traditionnel » signifie généralement l’un de ces éléments.

• Règles de mots-clés et de phrases : si un terme de recherche contient « gratuit » ou « emplois », marquez-le comme non pertinent.
• Expressions régulières : extraction de numéros de commande, numéros de téléphone ou valeurs UTM à partir de texte.
• Logique de tableur : VLOOKUP, chaînes IF et tableaux croisés dynamiques pour la catégorisation.
• Apprentissage automatique classique : régression logistique ou arbres de décision entraînés sur des données étiquetées.
• Travail manuel : une personne étiquetant des avis, triant des prospects ou nettoyant une exportation CRM.

Chacun a ses forces. Les règles sont transparentes et instantanées. Les regex sont exactes pour des modèles bien définis. Le travail manuel gère le jugement.

Variation linguistique

Les clients disent la même chose de cent façons. Une liste de règles pour « plainte concernant la livraison » ne couvre jamais « le colis n’est toujours pas arrivé » ou les variantes en turc avec des fautes de frappe. Un petit modèle gère cette variation sans une liste croissante d’exceptions.

De nombreuses catégories avec des bords flous

Trier des milliers d’articles de blog par sujet, ou des termes de recherche par groupe d’intention, implique un jugement sur les bords. Les règles se cassent ; un modèle avec quelques exemples s’en sort mieux.

Entrée multilingue

Un modèle peut étiqueter des avis en turc, anglais et allemand avec le même prompt, alors que les règles nécessiteraient des listes séparées par langue.

Champs non structurés mixtes

Les titres de poste en texte libre, les noms d’entreprise ou les réponses à « comment avez-vous entendu parler de nous » varient à l’infini. Les normaliser à la main est fastidieux et avec des formules, c’est fragile.

• Modèles exacts : les adresses e-mail, les numéros de TVA, les dates et les URL sont mieux extraits avec des regex ; un modèle peut les « corriger ».
• Calculs : les totaux, les moyennes et le rythme budgétaire appartiennent aux formules ou au code, pas aux modèles de langage.
• Règles de conformité : lorsqu’une décision doit être explicable étape par étape, comme l’exclusion de certains publics, une règle écrite est plus claire.
• Très petits volumes : si dix éléments arrivent par semaine, une personne est plus rapide que de construire un pipeline.
• Catégories stables et simples : si « contient le nom de la marque » décide correctement de l’étiquette, il n’y a aucune raison d’ajouter un modèle.

Exécutez les deux approches sur le même échantillon étiqueté avant de décider. Une méthode pratique :

• Collectez 300 éléments réels ou plus et demandez à un spécialiste de les étiqueter.
• Appliquez les règles ou processus actuels et enregistrez l’accord avec les étiquettes.
• Exécutez un petit modèle avec un prompt court et quelques exemples ; enregistrez l’accord.
• Vérifiez où chaque approche échoue ; les erreurs diffèrent souvent.
• Comparez le coût total : temps de configuration, coût de fonctionnement, temps de révision et maintenance.

Si les règles sont déjà presque toujours en accord avec le spécialiste, gardez-les. Si le modèle fonctionne clairement mieux sur les cas les plus importants, changez ou combinez-les.

Mettez les règles rapides et bon marché en premier et n’envoyez que les éléments peu clairs au modèle. Pour les termes de recherche, une règle peut marquer instantanément les termes de marque exacts et les mots non pertinents connus ; le modèle gère la longue traîne. Pour le routage des prospects, les règles capturent les clients existants par domaine e-mail ; le modèle lit le message en texte libre pour le reste.

Cela réduit les coûts, maintient un comportement prévisible pour les cas courants et limite le nombre d’éléments où une erreur de modèle peut se produire. Les sorties de modèle à faible confiance peuvent ensuite aller dans une file d’attente humaine.

Les modèles ont besoin d’être surveillés. Les entrées changent : nouveaux produits, nouveau jargon, nouveaux concurrents. Un modèle qui était d’accord avec les spécialistes en mars peut dériver en septembre. Les règles dérivent aussi, mais leurs échecs sont plus faciles à repérer. Prévoyez du temps pour une vérification mensuelle par rapport à des échantillons frais.

Il existe également un risque de dépendance. Si vous dépendez d’un modèle d’API, un fournisseur peut le retirer ou le modifier. Gardez les prompts, les exemples et les ensembles de test stockés, afin que le passage à un autre modèle soit un nouveau test, pas une reconstruction.

Avant les modèles de langage, les équipes entraînaient des classificateurs tels que la régression logistique ou les arbres boostés par gradient sur des données étiquetées. Ceux-ci fonctionnent toujours bien lorsque vous avez des milliers d’exemples étiquetés, un ensemble stable de catégories et des entrées structurées, comme la prédiction de la qualité des prospects à partir de champs de formulaire et de firmographies. Ils sont bon marché à exécuter et faciles à surveiller. Les petits modèles de langage sont plus utiles lorsque les entrées sont en texte libre et que les données étiquetées sont rares, car quelques exemples dans un prompt peuvent remplacer un ensemble d’entraînement complet.