Un modèle qui répond quand il ne sait pas n’est pas une fonction. C’est une responsabilité au ton agréable. Sur les systèmes que je fais tourner, une question a le droit de revenir vide. Le comportement utile est une citation quand le passage est dans la bibliothèque, et un refus quand il n’y est pas.
D’abord la recherche, ensuite les mots
Le motif est ennuyeux exprès. Prenez la question. Trouvez les passages qui pourraient contenir la réponse. Notez-les. Si aucun ne soutient vraiment une affirmation, arrêtez. Si l’un le fait, montrez le passage à côté de la phrase qui l’a utilisé. La phrase n’est pas la source. Le passage est la source. Un lecteur qui ne peut pas ouvrir le passage ne peut pas faire confiance à la phrase, et on ne devrait pas le lui demander.
C’est ainsi que j’ai construit le système de formation que je fais tourner : les documents entrent, un plan vise une date, les réponses sont notées contre la source, la révision arrive avant que la matière soit oubliée. Une question sur un document devrait se comporter de la même façon. Ancrée, ou silencieuse. Deviner paraît utile dans une démo et coûte cher la première semaine où un client agit dessus.
| Ce qui est revenu | Ce que le système peut dire |
|---|---|
| Un passage qui soutient l’affirmation | La réponse, avec ce passage à côté. |
| Des passages qui sont seulement proches | Rien de ferme. Dites ce qui manque. |
| Aucun passage | Refusez. Ne comblez pas le trou avec une phrase probable. |
| Une extraction peu sûre | Pause pour une personne. Ne payez pas le modèle une deuxième fois pour réessayer à l’aveugle. |
La facture et le journal font partie de la conception
Un modèle dans le cloud voit des données. Avant cela, le flux de données est écrit : quel service, clé de qui, quel est le plafond mensuel. L’accord est explicite. Tout ce qui touche un client, un prix ou une commande attend une personne. L’appel est journalisé, parce que « l’assistant l’a dit » n’est pas une piste d’audit.
Je ne promets pas que cela place un site dans la boîte de réponses de quelqu’un d’autre. Le classement est une autre machine, avec des incitations que je ne contrôle pas. Ce que je contrôle, c’est si mon propre système invente.
La fluidité ne coûte rien. Le produit, c’est un passage que vous pouvez ouvrir.
Le seuil est une décision de produit
Quelqu’un doit choisir le point où « proche » devient « pas assez bon ». Je ne laisse pas cela à l’humeur du modèle. Un passage franchit une barre que je peux expliquer, ou la réponse est retenue. Je préfère expliquer un refus à un utilisateur qu’expliquer une étape inventée dans une procédure qu’il a suivie. La barre peut se régler après que vous avez vu de vraies questions. Elle ne doit pas commencer à zéro, là où une démo aime vivre, parce qu’une démo est notée sur la fréquence à laquelle elle dit quelque chose.
Quand un passage est incertain d’une autre façon, un extrait de faible confiance plutôt qu’une bibliothèque vide, je le mets en pause pour une personne au lieu de payer une autre tentative qui sonnera plus lisse. Plus lisse n’est pas plus vrai. Le journal garde la première tentative, pour que la personne voie ce qui a été retrouvé et ce qui a été écarté.
Les modèles sont entraînés à être utiles, ce qui veut dire qu’ils préfèrent finir le paragraphe. L’application doit être plus sèche que le modèle. Un seuil, une citation manquante, une recherche vide : chacun est une branche qui ne renvoie pas de réponse et note pourquoi. Si cette branche n’existe pas, le système finira par répondre à une question que la bibliothèque ne peut pas soutenir, et il aura l’air sûr.
La première fois que vous le voyez refuser, cela ressemble à un bug. C’est l’inverse. Le bug, c’est le paragraphe sûr de lui, sans endroit où cliquer.
