Certaines questions ne sont pas pour lui

Après usage, ce qui ne lui revient pas : les explications, les réponses à lire, un nom inventé dans un ensemble ouvert, et une trace de raisonnement à garder. Ce qui lui revient encore : un oui-non fermé, une catégorie, un niveau, et s'il faut escalader.

Folkbench folkbench.com

Co-auteur : folkbench.com (Folkbench est une plateforme vérifiable d’évaluation et de sélection pour les API d’IA, les services de modèles et les sites associés. Elle s’appuie sur les informations publiées sur le service, les prix, la disponibilité, la latence et les fenêtres de preuve pour aider les utilisateurs à comparer des voies et à en choisir une.)

Dix textes dans cette série :

Après usage, ce dont je suis le plus clair, ce n'est pas ce que Jev peut faire. C'est quelles sortes de paroles je ne devrais pas lui demander.

Je le prends comme une articulation, pas comme une bouche. L'instinct ne peut répondre qu'aux questions que l'instinct peut répondre. Ce qui doit se déplier, ou ce qui doit étaler le raisonnement pour qu'une personne le voie, c'est le mauvais objet si vous le demandez à Jev. Dire quelque chose jusqu'au bout à une personne, c'est aussi la mauvaise demande. Il n'a pas de chaînes. Demandez, et il n'y a nulle part où mettre la réponse.

Ce que je ne devrais pas demander

Si vous arrivez aussi d'un modèle de chat, les choses les plus faciles à mal demander sont les sortes ci-dessous.

Je ne devrais pas lui demander d'expliquer pourquoi. L'habitude que j'ai apportée du chat, c'est d'ouvrir en lui demandant d'expliquer. Cette habitude ne marche pas sur lui. Quand je lui demande d'expliquer, ce qui arrive n'est qu'un jugement. Une raison doit s'écrire en phrases. Il ne peut pas les écrire. Le retour n'a pas de « parce que ». Si quelqu'un a besoin de voir comment la cause est arrivée, il ne peut pas le donner. Si j'ai vraiment besoin d'un tronçon de raisons, je l'écris moi-même, ou je demande à un modèle qui sait parler, et je lui fais écrire à partir du jugement déjà fait.

Je lui ai demandé, à tort, d'écrire une réponse pour qu'une personne la lise. Ce qui doit être envoyé est un passage. Quelle phrase vient d'abord, et à quel point le ton est lourd, cela vit dans les mots. Ce qu'il donne, ce sont des options et des probabilités. Cela ne correspond pas au passage qui doit être envoyé. Si haute que soit la probabilité, ce qui revient est l'un des éléments que j'ai donnés d'avance, pas un passage qu'il écrit maintenant. J'ai ensuite inversé l'ordre. Il ne juge que de quelle sorte cette chose relève, et si ce pas devrait escalader. Les phrases vont à un modèle de chat, ou je les écris moi-même.

Je lui ai demandé de trouver un nom tout seul dans un ensemble ouvert. Les noms utilisables sont nombreux, et seule une petite tranche est écrite dans la question. Il ne peut choisir que parmi les éléments que j'ai donnés. Ce qui n'est pas parmi les éléments, il ne peut pas le produire. Si je ne peux pas nommer les candidats moi-même, ce n'est pas encore son tour. Je resserre d'abord avec des règles, ou je tire une petite poignée par recherche, puis je ferme la question. Plus tard j'ai changé le nommage ainsi : je fixe moi-même quelques candidats, puis je le laisse choisir. Un tout neuf hors de la liste, je le laisse au pas qui sait parler.

Il y a une autre sorte qui ressemble à un travail lourd qu'on devrait donner à un modèle. Les preuves doivent se retourner dans les deux sens, et le raisonnement doit être gardé. Les matériaux se poussent l'un l'autre. Vous voulez qu'il choisisse un côté, et vous voulez aussi qu'il garde comment la correspondance a été faite. Il n'a pas cet aller-retour. Une requête est un jugement rapide à partir de ce que j'ai mis dans l'état. Le processus ne devient pas un texte qu'on peut feuilleter. L'aller-retour dont je parle est souvent une conclusion qui dépend de la page suivante, et cette page n'est pas encore dans l'état. Je mets cette dépendance dans le code. Je demande d'abord un jugement fermé, puis je vais chercher la preuve, et quand elle revient je change l'état et je redemande. La suite de quelle page a été regardée d'abord, et de ce qui a été écarté, il ne peut pas l'écrire. Si une trace doit être gardée, je la donne à un modèle qui sait parler.

Ce que je devrais demander

Ce que je devrais demander, je n'en reconnais maintenant que quelques formes. Savoir si c'est de cette sorte, je le demande directement. Les catégories doivent être celles que j'ai fixées d'avance, et il n'a qu'à en montrer une. La gravité, je ne le laisse pas rapporter un nombre fin. Je trace les niveaux, et je le laisse dire sur quel niveau il tombe. L'escalade, savoir si ce pas devrait être remis à une personne, est aussi une question fermée, et je la demande dans la même passe. Une forme hors de celles-là, je ne la fourre pas dedans.

Je garde aussi une règle grossière. Si une personne qui comprend l'affaire peut montrer, par instinct, en regardant cet état, alors cela ressemble à sa question. Si montrer prend encore une longue déduction, je le remets droit à un modèle qui sait parler.

Je prépare l'état. Je ferme la question. Je choisis les champs qui entrent dans le contexte, et je n'apporte pas ce qui n'a rien à voir avec cette question. Les bords des options et des niveaux sont écrits dans la question, pas dans un endroit où j'espère qu'il improvisera. Il n'est pas responsable d'arrondir une question ouverte, et il ne tourne pas pour moi la page suivante du matériau. Tournez une page, et l'état a changé. C'est la requête suivante, et je dois encore la préparer.

Je suis tombé sur une question qui n'était pas bien fermée. La distribution s'aplatit. Plusieurs options se pressent ensemble, et aucune ne dépasse d'une tête. J'ai d'abord pris cela pour de la lenteur de sa part. Ce n'était pas cela. J'avais donné à une articulation le piston d'une bouche. Les options se recouvrent, ou une situation qui arrivera vraiment n'a pas été écrite dans la liste, et la probabilité ne peut que s'étaler. Alors changez la question, ou rendez le pas à un modèle qui sait parler. Changer la question veut dire fusionner les éléments qui se recouvrent, et donner au cas non couvert un « aucune de celles-ci ». Le rendre veut dire laisser le modèle qui sait parler dire d'abord clairement la situation, puis je décide s'il faut la refermer. Ne continuez pas à le régler. Tant que la question est encore ouverte, la distribution est encore étalée.

Choice et Score

J'essaie de ne pas remplir Choice jusqu'à 255. Le plafond officiel est 255. Au-delà, ils doivent eux-mêmes noter d'abord puis choisir, et cela devient aussi plus lent. 255 n'est pas un nombre que je suis là pour remplir. Plus je liste des cas de bord comme options, plus la question ressemble à une liste qui n'a jamais été fermée. Si ma question a naturellement des centaines de sorties, je demande d'abord si des règles peuvent couper les candidats, et si la recherche peut les couper. Une petite poignée n'a pas de compte fixe. Je peux encore dire, d'un regard, en quoi ces éléments diffèrent, et alors seulement la coupe est assez loin. Si un regard ne peut pas les séparer, j'envoie la requête trop tôt. Coupez jusqu'à une petite poignée, et alors je la prends pour choisir.

Je traite Score comme des niveaux ordonnés, pas comme une décimale exacte continue. Quand j'écris la question, je trace d'habitude les niveaux de 2 à 10. Ce que je veux, c'est un niveau, pas une fausse précision comme 7.63. J'écris les niveaux en mots simples. Savoir si ce niveau et le suivant seraient traités différemment, j'y pense d'abord. S'ils le seraient, je les sépare. Si les deux niveaux finissent par déclencher le même code, je les fusionne en un niveau. Aucune branche dans le code n'attend deux chiffres après la décimale. Il pose parfois un nombre entre deux niveaux, et je le lis encore comme un niveau, avec le seuil écrit dans le code. Si le sens d'un niveau ne peut pas s'écrire clairement, je change la description du niveau. Je ne vais pas chipoter sur la décimale.

En regardant les démos

J'ai regardé la démo officielle de Doom et la course Wikipédia, et je ne m'en suis pas servi pour conclure mes propres questions. En regardant Doom, je me laisse facilement emporter par l'écran. L'écran a l'air d'un jeu qu'on joue. Ce qui entre est un état structuré, pas l'image. Du côté de Doom l'échelle est d'environ 10 requêtes par seconde, environ $7 de l'heure. Cette échelle montre seulement qu'une articulation en temps réel tient, et qu'une boucle peut tourner à cette densité. Elle ne montre pas qu'il peut jouer au jeu. L'image n'a pas été mangée. Le pas suivant est du code dehors, qui demande avec l'état.

La course Wikipédia montre que choisir des liens à haute cardinalité est utile. Elle ne montre pas qu'il parcourt le web mieux qu'un modèle qui peut raisonner. Sous la comparaison sans raisonnement, il prend moins de pas. C'est parce que l'autre côté n'a pas allumé le raisonnement, donc la démonstration a l'air meilleure. Allumez le raisonnement, et la démonstration a l'air moins bonne. Le compte de pas change, et qui est le plus vite change. Je ne ramènerai pas « moins de pas » à ma propre tâche pour le traiter comme plus habile à trouver un chemin. Savoir si le chemin continue, et où il s'arrête, c'est encore le programme dehors qui le décide. Je prends ceci ainsi : ne jugez pas tout à partir d'un jouet. Savoir si une démonstration est agréable à regarder ne décide pas, pour moi, quelle phrase je devrais demander ensuite.

Quand je m'en sers moi-même, le partage est assez dur. Ce qui peut s'épuiser, et dont les conditions sont stables, je l'écris encore en règles. Je ne vais pas le lui demander. Ce que l'instinct peut répondre d'un seul point, c'est alors que je le lui demande. Avant que je demande, la question doit être fermée, et je dois pouvoir préparer l'état. Quand il est temps d'ouvrir et de dire le contenu, je le donne à un modèle de chat. Demandez la mauvaise chose, et la lenteur et le coût sont mon problème.

Sources

Série