J'ai réfléchi un peu à l'apprentissage continu récemment, surtout en ce qui concerne les agents à long terme (et en réalisant quelques expériences avec MLX). Le statu quo de la compression des invites couplée avec des sous-agents récursifs est en fait remarquablement efficace. On dirait que nous pouvons aller assez loin avec ça. (Compression des invites = lorsque la fenêtre de contexte est presque pleine, le modèle génère un résumé plus court, puis recommence à zéro en utilisant le résumé. Sous-agents récursifs = décomposer les tâches en tâches plus petites pour gérer des fenêtres de contexte finies) Les sous-agents récursifs seront probablement toujours utiles. Mais la compression des invites semble être un peu un hack inefficace (bien que très efficace). Il y a deux autres alternatives que je connais : 1. le fine-tuning en ligne et 2. les techniques basées sur la mémoire. Fine-tuning en ligne : entraîner quelques adaptateurs LoRA sur les données que le modèle rencontre pendant le déploiement. Je suis moins optimiste à ce sujet en général. En dehors des défis d'ingénierie liés au déploiement de modèles/adaptateurs personnalisés pour chaque cas d'utilisation/utilisateur, il y a quelques problèmes fondamentaux : - Le fine-tuning en ligne est intrinsèquement instable. Si vous vous entraînez sur des données dans le domaine cible, vous pouvez détruire de manière catastrophique des capacités que vous ne ciblez pas. Une façon de contourner cela est de garder un ensemble de données mixte avec les nouvelles et les anciennes. Mais cela devient assez compliqué assez rapidement. - À quoi ressemblent même les données pour le fine-tuning en ligne ? Générer des paires Q/A basées sur le domaine cible pour entraîner le modèle ? Vous avez également le problème de prioriser les informations dans le mélange de données compte tenu de la capacité finie. Techniques basées sur la mémoire : essentiellement une politique pour garder une mémoire utile et jeter ce qui n'est pas nécessaire. Cela ressemble beaucoup plus à la façon dont les humains retiennent l'information : "utilisez-le ou perdez-le". Vous n'avez besoin que de quelques éléments pour que cela fonctionne : - Une politique d'éviction/retention. Quelque chose comme "garder une mémoire si elle a été accédée au moins une fois dans les 10 000 derniers tokens". - La politique doit être calculable efficacement. - Un endroit pour que le modèle stocke et accède à la mémoire à long terme. Peut-être qu'un cache KV peu accédé serait suffisant. Mais pour un accès efficace à une grande mémoire, une structure de données hiérarchique pourrait être meilleure.