Utilisation de l'API OpenAI pour la vérification des adresses logistiques en Europe : nous avons économisé 32 % des coûts de main-d'œuvre et avons également évité deux erreurs fatales.

La grande promotion de la semaine noire s'est terminée la semaine dernière, et lors de la réunion de révision de notre équipe technique, nous avons constaté que le taux d'acceptation de la vérification automatique des adresses a augmenté de 41 % par rapport à l'année dernière. Cette année, il suffit de conserver seulement un des trois employés à temps partiel qui s'occupaient précédemment des adresses anormales.

Mais personne ne veut parler du problème avec l'erreur 429 qui est survenu le mois dernier – pendant les trois heures les plus chargées du premier jour de la grande promotion,13 % des demandes d'analyse d'adresses sont directement rejetées.Le système de support client a explosé, et le groupe d’opération a failli venir renverser nos tables.

Pour ceux qui n’y ont jamais touché, disons les choses clairement : qu’est-ce que l’API OpenAI, au juste ?

Il suffit de ne pas entraîner soi-même de grands modèles, mais d'appeler directement les interfaces des modèles déjà entraînés par OpenAI tels que GPT-4o ou GPT-3.5-turbo, d'envoyer une demande et de recevoir le résultat en retour. Le paiement se fait en fonction du nombre de tokens utilisés. La version qui prend en charge jusqu'à 128 000 contextes par demande est maintenant entièrement disponible.

Les raisons pour lesquelles nous l'avons choisi étaient très simples : les formats des adresses dans les différents pays européens étaient trop désorganisés. Les codes postaux au Royaume-Uni étaient complètement différents de ceux en Allemagne, et il y avait également de nombreux erreurs de orthographe dans différentes langues. La base de règles que nous avions créée nous-mêmes avait été mise à jour 8 fois en six mois, mais elle continuait à manquer de précision. En utilisant une API pour l'analyse sémantique, dès que nous fournissions le bon « prompt », le taux de précision atteignait directement plus de 96 %.

Nous avons réellement obtenu 3 avantages concrets, sans rien de fictif.

• Il n'a pas été nécessaire de former une équipe d'algorithmes pour ajuster les modèles spécifiquement ; en une semaine, les trois services back-end ont réussi à connecter les interfaces. Au cours du premier mois de mise en service, cela a permis d'économiser 32 % des coûts de main-d'œuvre des trois employés à temps partiel précédents.
• Les erreurs de orthographe et les adresses abrégées qui ne pouvaient pas être détectées par la base de règles précédente peuvent maintenant être corrigées automatiquement dans plus de 90 % des cas. Par conséquent, le taux de retours des commandes dues à des adresses saisies incorrectement par les utilisateurs a diminué de 28 %.
• Il est possible d'accepter une entrée mixte en plusieurs langues : les adresses saisies par des utilisateurs polonais en polonais ou par des utilisateurs espagnols en espagnol peuvent être directement envoyées à l'interface sans nécessiter de adaptation locale, et seront automatiquement converties en un format logistique standard.

Ne regardons pas que les avantages : nous avons failli y laisser la vie à cause de ces deux erreurs.

Le premier problème est la limitation de débit par modèle par défaut. Auparavant, nous n’utilisions que GPT-4o-mini, et la limitation de débit par minute préétablie suffisait normalement. Cependant, le jour d’une grande promotion, le nombre de demandes a triplé, ce qui a directement déclenché la limitation de débit. 13 % des demandes ont reçu le code d’erreur 429. Pour résoudre ce problème, nous avons ajouté une logique de dégradation, redirigeant les demandes hors période de pointe vers GPT-3.5-turbo, ce qui a permis de résoudre le problème.

Le deuxième problème est la mauvaise identification des adresses sensibles. Une fois, un utilisateur a saisi une adresse contenant des mots liés à des “bases militaires”, qui a été immédiatement bloquée par le système de vérification du contenu de l’API. Nous n’avons pas mis en place de mécanisme de récupération en cas d’échec, ce qui a entraîné le blocage de la commande pendant 2 jours. Le client a alors laissé un commentaire négatif.

À qui cela est destiné ? Vraiment, ne gaspillez pas votre argent.

Si, comme nous, vous êtes impliqué dans des activités impliquant le traitement sémantique multilingue et que vous devez créer des règles sans cesse, comme la vérification d'adresses, les réponses automatiques aux questions des utilisateurs ou la génération de contenu en plusieurs langues, et que votre équipe n'a pas d'équipe spécialisée en algorithmes, alors utiliser les API d'OpenAI est beaucoup plus avantageux que de développer vos propres modèles.

Mais si vous travaillez avec des données critiques qui ne doivent absolument pas quitter le domaine, comme le traitement de données financières essentielles, l'analyse de données de confidentialité médicale, ou dans des scénarios simples où le volume de demandes est particulièrement stable et les règles sont claires, alors ne vous embêtez pas avec cela. Écrire vos propres règles ou déployer de petits modèles localement peut être moins coûteux et plus sûr.

Voici trois conseils pour ceux qui utilisent l'outil pour la première fois, basés sur nos propres erreurs et les leçons que nous avons tirées.

• Ne vous contentez pas d'un seul modèle ; préparez au moins deux modèles de niveaux différents en cas de dégradation des performances. Utilisez le modèle le plus précis pour les demandes de haute importance, et le modèle moins coûteux pour les demandes moins prioritaires ou pendant les périodes de pointe. Cela peut vous permettre d'économiser au moins 40 % des coûts et d'éviter les problèmes de congestion dues à la limitation de capacité d'un seul modèle.
• Toutes les demandes doivent faire l'objet d'une répétition des tentatives (retry) et d'une logique de sauvegarde (fallback). Les cas d'interception de la vérification du contenu, de limitation du débit (throttling) et de timeout doivent être prévus à l'avance, afin de ne pas devoir gérer manuellement les problèmes qu'après que l'interface ait déjà cessé de fonctionner.
• Il n’est pas nécessaire d’utiliser dès le début le modèle le plus avancé ; commencez plutôt avec le modèle le moins coûteux, GPT-3.5-turbo, pour voir les résultats. Si les résultats ne sont pas satisfaisants, vous pourrez ensuite passer à un modèle plus performant. Pour la plupart des scénarios simples, un modèle plus petit est tout à fait adapté.

Pour terminer, voici deux questions que beaucoup de gens posent fréquemment.

Question : Y aura-t-il un retard important lors des appels depuis l'Europe ?
Nous utilisons le nœud de Francfort, et la plupart des requêtes sont traitées en moins de 15 millisecondes. Seuls quelques pour cent d'entre elles peuvent soudainement prendre plus de 200 millisecondes. L'ajout d'une cache peut résoudre ce problème sans affecter le fonctionnement de l'application.

Question : Est-il possible que les résultats de l'analyse soient incorrects ?
Oui, nous transférons maintenant les résultats dont le degré de confiance est inférieur à 80% à l'examen manuel. Avec cette nouvelle règle en place, le taux d'erreurs peut être considéré comme négligeable.