Pourquoi la plupart des agents ne sont que des organigrammes déguisés, et ce qu'il faut construire à la place. J'ai écrit la majeure partie de cela dans un aéroport il y a plusieurs mois, puis je l'ai laissé en brouillons. Le bruit n'a fait qu'augmenter depuis, donc voici le texte.
Quelques mois auparavant, en revenant d'un atelier avec un client, nous discutions de l'étendue de ce qui constitue l'IA agente, et chacun de nous a cité des exemples tirés de son expérience. Il y a eu une discussion sur pourquoi l'automatisation ne peut pas résoudre cela et comment la plupart des cas d'utilisation de l'IA agente ne sont rien d'autre que de l'automatisation glorifiée. La question était : « Donnez-moi un cas d'utilisation réel pour un agent.
Pas une démonstration. Pas de l'automatisation. Un réel.
Parce que tout ce que j'ai vu jusqu'à présent, je pourrais le construire avec un moteur de workflow et un appel à un modèle. » Nous avions tous participé à des conversations sur l'IA agente pendant des mois à ce stade. Nous avions conçu ces systèmes. Nous les avions présentés.
Et pourtant, assis là avec un thé et vingt minutes à disposition, nous avons dû réfléchir suffisamment longtemps pour proposer un exemple qui résisterait à trente secondes d'examen. Cela m'a suffisamment contrarié pour l'écrire. Le test auquel j'ai pensé en premier Mon instinct était de définir l'IA agente par la forme du travail.
La tâche nécessite-t-elle que le système prenne des décisions en cours d'exécution qui n'auraient pas pu être anticipées au départ ? Si oui, c'est un agent. Si non, c'est de l'automatisation. J'ai pensé à un exemple tiré de la maintenance aéronautique, car c'est là que j'ai passé les six derniers mois.
Un avion A320 atterrit avec un avertissement ECAM, DÉFAILLANCE DU PACK D'AIR 1. Ce que fait l'automatisation : elle déclenche une liste de contrôle, prévient l'ingénieur de garde, peut-être extrait la référence du MEL. Terminé.
Ce que fait l'apprentissage automatique traditionnel : il prédit la probabilité de défaillance d'un composant à partir des modèles de défauts historiques, produit un score de confiance. L'ingénieur décide toujours. Ce que je pense qu'un agent ferait : il commencerait avec le message ECAM (un message dans les systèmes de cockpit de l'avion), interrogerait le CFDS (système centralisé d'affichage des défauts) pour obtenir l'historique des défauts et constaterait que le pack 1 a généré le même défaut trois fois en six semaines.
Cela change la donne, donc il consulterait le TSM (manuel de dépannage) pour identifier quatre causes racines potentielles. Ensuite, il vérifierait dans AMOS (une base de données utilisée dans l'aéronautique partout dans le monde) la disponibilité des pièces et constaterait que deux de ces quatre nécessitent une vanne de régulation de débit, qui n'est pas disponible à cette station. Ensuite, il vérifierait lesquelles de ces causes peuvent être reportées selon la MEL (liste minimale d'équipement, le minimum dont un avion a besoin pour être apte au vol), constaterait qu'une d'entre elles peut être reportée sous la catégorie C (l'une des nombreuses catégories) pendant dix jours, examinerait les dix prochaines rotations de l'avion pour comprendre le coût opérationnel du report, et rédigerait une recommandation : reporter sous la catégorie C, commander la vanne de régulation de débit (FCV) pour une arrivée avant le huitième jour, et signaler pour une inspection approfondie lors du prochain créneau de maintenance de base.
Personne n'avait programmé à l'avance cet arbre de décision. Le plan est né du processus plutôt que de le précéder. Je n'étais toujours pas convaincu par moi-même.
Et en y réfléchissant, je crois que j'avais raison. Pourquoi cet exemple échoue Parce que vous pouvez dessiner cet organigramme. CFDS, puis TSM, puis AMOS, puis MEL, puis les rotations.
C'est un organigramme complexe avec des branches, mais un ingénieur compétent aurait pu le spécifier à l'avance. La complexité n'est pas la même chose que l'ouverture. Un arbre avec deux cents branches reste un arbre.
C'est l'erreur que font presque tous les pitch decks d'IA agente, y compris le mien. Nous présentons quelque chose d'intricate et nous attendons que cette intricate soit évidente comme étant agente. Ce n'est pas le cas.
L'intricate n'est qu'un organigramme plus grand, et les organigrammes ont déjà une technologie, et elle est moins chère, plus rapide et bien plus fiable que tout LLM que vous placeriez dans cet emplacement. Alors, où se situe réellement la frontière ? Inconnus connus contre inconnus inconnus Voici la distinction que j'ai établie, et elle est plus étroite que ce que la plupart des personnes sur ce marché sont prêts à admettre. L'automatisation gère les inconnus connus.
Vous ne savez pas si la pièce est en stock, mais vous savez que le stock est quelque chose que vous devez vérifier. Les agents gèrent les inconnus inconnus. Vous ne savez pas ce que vous devez vérifier, et vous ne le découvrirez qu'en regardant.
Prenez un u...
Source: Towards Data Science · Résumé par HeadlinesBriefing