Historique des conversations
Une longue conversation finit par se heurter à un mur : la fenêtre de contexte du modèle. Tout ce qui figure sur cette page existe à cause de ce mur, et ce qui est intéressant, c’est ce qui est jeté, ce qui est conservé et ce qui peut être récupéré.
Quatre façons de récupérer du contexte
Section intitulée “Quatre façons de récupérer du contexte”Ce ne sont pas tant des solutions de rechange qu’une échelle, du mécanisme le moins coûteux au plus coûteux.
| Mécanisme | Coût | Conserve | Perd |
|---|---|---|---|
| Élision | Rien | Chaque mot du récit | Les anciens résultats d’outils sans événement notable |
| Retrait des images | Rien | Le texte qui les entoure | Les anciennes captures d’écran |
| Instantanés | Rien | Chaque mot, sous forme de pixels | La lisibilité pour un modèle sans vision |
| Résumé | Un appel au modèle | Un récit | Les détails qu’il n’a pas retenus |
L’élision et le retrait s’exécutent en premier parce qu’ils sont gratuits et sans perte de la façon qui compte : ils éliminent du volume que personne n’allait relire.
Pourquoi le résumé est la solution de dernier recours
Section intitulée “Pourquoi le résumé est la solution de dernier recours”Le résumé est le seul des quatre qui consomme un appel au modèle et le seul qui décide à votre place de ce qui comptait. Les deux sont de vrais coûts. L’appel est le plus intéressant, à cause du moment où il se produit.
Le compactage s’exécute habituellement avant d’atteindre le mur, selon un seuil. Mais il s’exécute aussi de façon réactive, après que le fournisseur a lui-même rejeté une requête parce qu’elle était trop grosse — l’estimation heuristique avait sous-estimé ce que le fournisseur a réellement mesuré. Dans cette situation, un compacteur de résumé doit faire une requête pour réduire le contexte, et la requête qu’il fait est celle qui vient de dépasser la limite.
Instantanés
Section intitulée “Instantanés”Le compactage par instantanés rend l’historique jeté sur des pages denses de glyphes en pixels et le renvoie sous forme d’images.
Le principe repose sur une particularité de facturation : un modèle de vision facture une image à un tarif forfaitaire ou proportionnel à sa surface, sans aucun rapport avec le nombre de caractères qu’elle contient. Douze mille caractères de conversation jetée coûtent l’équivalent en jetons de texte de douze mille caractères. Les mêmes caractères rendus sur une seule page coûtent une image.
Ce qui le rend utile plutôt que simplement ingénieux, c’est qu’il ne nécessite aucun appel au modèle, aucune clé et aucun accès réseau. C’est la seule stratégie qui est toujours disponible pendant la récupération après un dépassement.
La forme de la reconstruction est la suivante : tête intégrale, milieu imagé, queue intégrale. La tête contient la tâche et les contraintes auxquelles tout ce qui suit se rapporte ; la queue est l’endroit où se trouve le travail en cours. Le milieu est ce qui est relu le moins souvent et qui coûte le plus cher.
Les instantanés sont rendus de nouveau à partir du texte source conservé à chaque passe, jamais à partir des pixels de la passe précédente. Imager une image dégrade les glyphes d’une génération par compactage, jusqu’à ce que plus rien ne puisse les lire.
Ce à partir de quoi une exécution reprend réellement
Section intitulée “Ce à partir de quoi une exécution reprend réellement”Historiquement, chaque exécution du harnais partait d’un historique vide et reconstruisait la continuité à partir d’un bloc <context> dans le prompt — un résumé de la conversation plutôt que la conversation elle-même. Trois conséquences en découlaient :
- La reprise était un récit refait. Le modèle ne voyait jamais son propre raisonnement antérieur ni les octets réels renvoyés par ses outils, seulement une description de ceux-ci.
- Le retour en arrière mourait avec le processus. Un
checkpointest un index dans la liste des messages en direct, donc un redémarrage faisait perdre toutes les étiquettes que le modèle avait définies. - La nouvelle tentative ne pouvait pas distinguer « rien à réessayer » de « rien de chargé ». Après un redémarrage, le tour échoué disparaît de l’état en direct dans les deux cas.
Ces trois problèmes sont réglés par la persistance de la transcription. Celle-ci est enregistrée à chaque frontière de tour et jamais au milieu d’un tour : un historique capturé entre un appel d’outil et son résultat est un historique qu’aucun fournisseur n’acceptera, donc un plantage à cet instant restaure le tour précédent plutôt qu’un demi-tour qui ne peut pas être rejoué.
Une exécution reprise est réduite à ses messages les plus récents, en coupant à une frontière qui n’est pas un résultat d’outil orphelin — un résultat dont l’appel a été supprimé constitue une requête que les fournisseurs rejettent carrément, et une transcription qui ne peut pas être envoyée est pire qu’une transcription courte.
L’arbre de session
Section intitulée “L’arbre de session”Chaque message consigne celui dont il découle, et chaque conversation nomme sa pointe de branche actuelle. Cette seule décision constitue toute la fonctionnalité.
Créer une branche n’écrit rien. Cela déplace le pointeur. Le chemin que vous avez quitté est toujours là, donc y revenir est un autre déplacement de pointeur plutôt qu’une restauration — et modifier un prompt pour le réexécuter cesse de vous coûter la réponse à laquelle vous vous compariez.
Sans cela, toute forme de retour en arrière doit masquer ou supprimer des messages, et le masquage est un mensonge que le prochain lecteur ne peut pas percer.
Branche ou bifurcation
Section intitulée “Branche ou bifurcation”| Branche | Bifurcation | |
|---|---|---|
| Ce qui se passe | Le pointeur se déplace | Le chemin est copié |
| Où cela mène | La même conversation | Une nouvelle conversation |
| Coût | Rien | Une copie de la branche |
Une bifurcation copie avec de nouveaux identifiants plutôt qu’en partageant des lignes. Deux conversations qui partageraient des lignes se montreraient mutuellement leurs messages ultérieurs, ce qui est la seule chose qu’une bifurcation ne doit pas faire.
Le retour en arrière emprunte le même pointeur
Section intitulée “Le retour en arrière emprunte le même pointeur”La paire checkpoint / rewind d’une exécution marque une frontière de tour propre et y revient après une exploration, en conservant un condensé. Comme les points de contrôle sont conservés avec la transcription, une étiquette définie par le modèle avant un redémarrage aboutit toujours là où elle a été définie. Un point de contrôle dont la cible n’a pas survécu à une réduction est abandonné, et non ramené de force — revenir « à l’étiquette » et aboutir ailleurs est exactement l’échec qu’une étiquette existe pour prévenir.
Voir aussi
Section intitulée “Voir aussi”- Créer une branche de conversation — le navigateur d’arbre, la bifurcation et l’exportation
- Contexte des outils et cache de prompts — l’autre moitié de ce qui remplit une fenêtre de contexte
- Commandes slash —
/compact,/shake,/context,/tree