Testez les outils d'IA avec du travail réel, pas avec des tâches de démonstration

Chaque essai d'un outil d'IA suit le même arc : la démo est éblouissante, l'essai gratuit est éblouissant, vous vous abonnez et, au cours de la troisième semaine, vous remarquez que vous l'utilisez moins que votre ancien flux de travail défectueux. L'écart entre les performances de la démonstration et l'utilité quotidienne est le modèle le plus fiable de cette industrie, et la solution est une discipline que j'applique désormais à chaque essai : n'évaluez jamais sur le matériel de l'outil, uniquement sur le vôtre.

Les tâches de démonstration sont du matériel préparé, et cela est vrai, que le fournisseur l'ait préparé ou que vous l'ayez préparé. Le PDF que vous téléchargez pour tester un résumé est généralement un document bien structuré que vous comprenez déjà, la photo pour l'outil image est le genre d'image qui fonctionne toujours, la réunion pour l'outil de transcription est celle en audio clair. Le vrai travail est plus compliqué à certains égards, en raison d'analyses épouvantables, de diaphonie, de demandes ambiguës, de jargon de domaine, et c'est dans ces domaines spécifiques que les outils diffèrent réellement. Un résumé qui brille sur du papier vierge peut s'effondrer sur le contrat de 90 pages rempli d'annexes dont vous avez réellement besoin d'être résumé d'ici jeudi.

Mon protocole d'essai est désormais figé : une vraie tâche, celle qui est posée sur mon bureau cette semaine, et l'outil la fait bout à bout ou elle ne réussit pas. Pas une version simplifiée de la tâche, pas la partie qui semble juste pour l'outil, le tout, y compris les entrées laides et le format de sortie que j'utiliserais réellement. La règle de la tâche entière détecte les échecs d'intégration qui manquent aux tests de fonctionnalité unique : l'outil de transcription qui a réussi l'audio mais n'a pas pu exporter là où mes notes sont enregistrées a échoué son essai sur un bouton d'exportation.

Ajoutez une tâche de sabotage par essai, car les outils sont optimisés pour ce qui est attendu. Donnez-lui le cas limite dont vous savez qu'il existe dans votre travail, la réunion en deux langues, le brief de conception avec des exigences contradictoires, le fichier de données avec la ligne brisée. Les outils qui échouent gracieusement, signalant ce qu’ils n’ont pas pu faire, valent plus que les outils qui échouent avec confiance, et la tâche de sabotage est le seul moyen de voir quel type vous achetez avant que l’abonnement ne le fasse à votre place au pire moment.

Le corollaire inconfortable : la plupart des outils échoueront à ce protocole, et c’est là le point. Sur la douzaine d'essais que j'ai effectués de cette façon, trois ont réussi et deux d'entre eux sont devenus des abonnements que je paie toujours. Les essais qui échouent ne sont pas du temps perdu, ce sont des frais de scolarité bon marché par rapport à l'alternative, une année à payer pour un outil qui gère votre vie de démonstration pendant que votre vrai travail se fait à l'ancienne. Le vrai travail est la seule référence qui compte, et il est toujours disponible.