Dans un épisode récent de President Curtis, le Président se débat pour ouvrir une porte à deux occasions séparées. Ces portes ne fonctionnent pas à cause d'obstacles sur le chemin : un corps initialement, puis environ un milliard de dollars d'or. Dans les deux cas, face à la frustration, le personnage marmonne "la chose stupide déteste." Ce n'est pas un modèle raisonnable de portes ! Les portes ne devraient pas "détester" de manière inexplicable ! J'ai trouvé ces moments outrageusement hilarants¹ mais peut-être que mon cerveau stupide déteste simplement.

Jev : Fabriquer plus de portes qui détestent L'Internet est en ébullition à propos de Jev, un modèle d'IA développé par Type Safe AI, qui renvoie des valeurs typées avec des estimations de probabilités. Les choses importantes à propos de Jev sont, autant que je puisse le dire : c'est rapide et bon marché, vous pouvez rapidement vous construire dessus, c'est rapide, et c'est bon marché. Je suis pas particulièrement bon pour comprendre quelle technologie sera adoptée. Je comprends toujours² Slack. Attendez. Est-ce que vous devez toujours faire la partie difficile ? Peut-être que mon problème est de m'attendre à ce que les produits fonctionnent. Personne n'acheteur cela n'est en train d'évaluer. Ils posent simplement des questions opaques à Jev et reçoivent des réponses opaques.

Charitablement, cela leur permet de cocher la case "IA-powered" et d'expédier avant vendredi, et quand cela casse la logique en aval, ils peuvent toujours hausser les épaux et dire "eh bien, l'IA fait des erreurs." Budgets d'erreurs ? Modes d'échec ? Jeux de tests ? Tout cela peut être traité plus tard. L'utilisateur peut découvrir le taux d'échec ! Vous avez déjà expédié !

Fausse confiance "Oh," le bouc émissaire répondant à mon post répond, "vous n'avez pas considéré le fait que Jev vous donne des scores de confiance !" Qu'est-ce que vous allez faire avec ? Pour faire quelque chose de raisonnable avec des scores de confiance, vous devez avoir à la fois une compréhension de la calibration de ces scores de confiance et un modèle pour les coûts de l'incertitude.

Du côté calibration : la copie publicitaire principale de Jev est principalement sur la façon dont ils scorent sur divers benchmarks, mais pas sur la façon dont leurs scores de confiance sont calibrés. Il y a un livre de recettes sur l'utilisation des scores de confiance pour monter un arbre de classification mais cela n'est pas fondamental sur la qualité des scores de confiance. À tout le moins, les gens utilisent les scores de confiance de manière cargo cult. À pire, les gens les utilisent comme une excuse pour l'échec de l'API. Le modèle n'était que 73% confiant ! Cela signifie que mon budget d'erreur est de 27% !

Redevabilité Quand un bouton casse sur un site web, j'ai un modèle de ce qui aurait dû se passer. Quelque part un contrat a été rompu. Mon DNS est cassé. Quelqu'un a expédié de la merde qui a des erreurs de syntaxe Java Script le long de certains chemins. Un handler a jeté une exception qui n'était pas attendue. Je n'ai peut-être pas accès à déboguer un simple HTTP 500, mais je m'attends à ce qu'il y ait quelqu'un dont le travail est de comprendre pourquoi l'endpoint est 500. La propriété est bien définie bien que³ opaque.

Pour de nombreux utilisateurs, l'expérience est en gros simplement "la chose stupide déteste." Le logiciel semble déjà capricieux ; plus d'échecs changent simplement le taux de frustration. Il semble qu'il n'y a pas de grande perte à supprimer la possibilité de suivre un échec vers une cause concrète. Les choses détestent parfois simplement. Cela mène à la normalisation de l'inexplicable.

Ma peur n'est pas que plus de choses échecs quand les choses sont accélérées par le développement LLM. Elles le feront. Elles l'ont fait. C'est le prix de construire choses de manière novatrice. Ma peur est que "parfois ça déteste simplement" devienne de plus en plus l'aboutissement accepté des investigations. C'est triste car le développement accéléré par LLM peut en effet nous aider à résoudre ces problèmes. Il y a de nombreux workflows QA automatisés qui ne sont pas écrits à cause du manque de temps d'ingénierie. L'évaluation qui vous ferait remplacer (ou justifier l'utilisation de) Jev peut être à quelques prompts près.

La tragédie de l'ingénierie logicielle aujourd'hui est que nous sommes en train de concevoir des systèmes où ni l'utilisateur ni le concept semblent avoir d'intérêt à vérifier s'il y a un corps derrière la porte. Nous juste...