Comment décidez-vous si un problème appelle vraiment une fonctionnalité IA ou quelque chose de plus simple ?

Demandez-vous si la tâche tolère l'erreur. Si une erreur est peu coûteuse à repérer et peu coûteuse à annuler, une fonctionnalité probabiliste marche bien ; si l'erreur est silencieuse ou coûteuse, de meilleures règles et de meilleurs choix par défaut l'emportent. Vérifiez ensuite que les données existent et que les utilisateurs n'évitent pas déjà le parcours, parce qu'ajouter un modèle à un parcours que personne n'ouvre ne fait que ralentir un parcours inutilisé.

La question que je pose en premier, c'est ce qui se passe quand c'est faux, parce que ça détermine tout. Si l'utilisateur voit l'erreur immédiatement et peut l'annuler sans frais, un modèle convient très bien, et c'est pour ça que la rédaction et le résumé marchent si bien. Si l'erreur est silencieuse ou coûteuse, comme quelque chose qui change un chiffre sur lequel un client est facturé, je préfère des règles et un choix par défaut bien meilleur. La deuxième question, c'est de savoir si la tâche sous-jacente est même désirée. J'ai vu beaucoup d'efforts partir dans l'ajout d'intelligence à un parcours que les gens évitaient déjà, ce qui ne produit qu'une version plus maligne de quelque chose que personne n'ouvre. Et troisièmement, les données doivent exister. Si le modèle a besoin d'un contexte qui vit dans trois systèmes auxquels on n'a pas accès, la réponse honnête est que c'est d'abord un projet d'intégrations. Ensuite je cadre la plus petite version qui teste si les gens font seulement confiance à la sortie.