Je suis tombée sur un problème. Je confondais les souvenirs et le scoring de mémoire. Les souvenirs, ce sont les éléments issus des conversations. Le scoring de mémoire, c’est le calcul lié à ces souvenirs.
Je réalise maintenant qu’il me faut plus d’un schéma pour tout gérer, ce qui veut dire... place à une nouvelle séparation des responsabilités ! J’adore ça.
On réfléchit : un système de pondération, des résumés de résumés et des métriques sur l’importance de chaque souvenir. Suivre des choses comme l’évolution des personnages, les nouvelles compétences acquises, la catégorie d’information et la température émotionnelle de n’importe quel bloc d’éléments conversationnels enregistrés dans la base de données des souvenirs.
Le scoring à l’échelle de l’archive
Le système de scoring prend aussi en compte le contexte élagué et les sessions qui s’étendent sur plusieurs bases de données de sessions de contexte, lorsqu’il calcule le poids d’un groupe d’entrées.
Ça nous donne un contexte redondant bien nécessaire, que la machine peut utiliser pour pointer la pertinence de n’importe quel souvenir qui lui revient en tête.
Mais, pour l’instant en tout cas, ce sont deux processus différents qui s’en occupent, jusqu’à ce que je fasse tourner le nouveau serveur de commandes basé sur Node.js. C’est cohérent tant qu’on parle de contexte passé, et on en a plein.
J’appelle ça un « système de gestion d’identité ».
L’idée, c’est que cette combinaison d’outils crée essentiellement une identité persistante et évolutive pour vos agents, où ils maintiennent le contexte, les compétences et les blagues internes, à travers potentiellement des gigaoctets de conversations utilisateur/agent.
J’ai hâte de voir comment ça change le comportement de mon agent à mesure que le nouveau système devient opérationnel.
Par contre, si ces bases de données grossissent trop, je passerai probablement à Postgres ou MariaDB.