Habr AI montre comment ajouter mémoire et contexte à un chat LLM en Python avec Ollama et LiteLLM

Un simple chat en console avec un LLM cesse d'être un vrai chat si le modèle ne voit que la question en cours. Dans la nouvelle partie du guide pratique consacré à Python, Ollama et LiteLLM, l'auteur présente l'étape la plus importante après l'intégration de base : ajouter l'historique des messages et transformer une chaîne de requêtes distinctes en un dialogue cohérent, doté de contexte.

Le problème de la version précédente tenait à ce qu'à chaque tour, le programme n'envoyait au modèle que l'instruction système et la dernière réplique de l'utilisateur. Pour un humain, cette limite passe presque inaperçue, jusqu'à l'arrivée de questions dépendantes comme « raccourcis-le » ou « ajoute-lui de la pratique ». Sans les messages précédents, le modèle ne sait pas à quoi renvoient les pronoms et les précisions ; il peut donc répondre au hasard ou perdre le fil de la conversation. C'est précisément ce qui distingue un appel ponctuel au modèle d'une interface de dialogue.

L'analyse souligne un point que les discussions sur les LLM simplifient souvent : le modèle n'a aucune mémoire cachée à long terme entre les appels. Dans un tel chat, la mémoire n'est créée ni par Ollama ni par LiteLLM, mais par l'application, qui conserve la conversation et la renvoie au modèle à chaque nouvelle requête. L'exemple pédagogique utilise une simple liste Python, `conversation_history`, dans laquelle les messages portant les rôles user et assistant sont ajoutés tour à tour. Le system prompt, lui, n'est pas stocké dans l'historique : il est ajouté séparément à chaque construction de la requête.

Sur le plan architectural, le changement paraît modeste, mais il transforme radicalement le comportement du programme. La fonction d'envoi accepte désormais non seulement le `user_message` courant, mais aussi l'historique. La liste `messages` est ensuite construite dans un ordre strict : system, puis toutes les répliques passées, puis la nouvelle question de l'utilisateur. Après la réponse du modèle, l'application enregistre les deux côtés de l'échange, la question et la réponse. Ce n'est pas un détail décoratif : si seules les répliques de l'utilisateur sont consignées, la requête suivante sera incomplète, car le modèle verra qu'une question a été posée, mais pas la réponse qu'il y a lui-même apportée.

La limitation de l'historique est traitée à part. L'exemple introduit la constante `MAX_HISTORY_MESSAGES = 6`, et la fonction utilitaire `trim_history` ne conserve que les six derniers messages, soit les trois derniers échanges. Pour un prototype local, c'est un compromis pragmatique : l'historique ne grossit pas indéfiniment, les requêtes ne gonflent pas et le modèle reçoit toujours le contexte le plus proche. L'exemple montre bien que, dans les applications LLM, la mémoire oblige toujours à arbitrer entre qualité de réponse, latence et coût ou charge, même avec un modèle local.

L'article s'appuie sur une configuration locale fondée sur Ollama, LiteLLM et le modèle `qwen2.5:3b`. Cette pile convient à l'apprentissage, car elle permet de monter un chat fonctionnel sans API externe et sans infrastructure complexe. Les exemples montrent clairement comment la réaction du système change une fois l'historique ajouté : la demande « parle-moi davantage du deuxième » renvoie correctement à la liste précédente, et la phrase « raccourcis-le » n'est plus traitée comme une commande abstraite isolée. Autrement dit, le modèle ne devient pas plus intelligent de lui-même, mais l'application lui fournit le contexte qui se perdait auparavant.

Les limites de cette version sont elles aussi énoncées sans détour. Tout l'historique n'existe que dans la mémoire vive de l'exécution en cours : si l'on ferme le script, le dialogue disparaît. C'est suffisant pour une CLI pédagogique, mais un bot Telegram, un service web ou un assistant client exigera un stockage persistant, au minimum dans un fichier, SQLite ou une base de données complète. Les étapes suivantes incluent généralement aussi le résumé des longs dialogues, le filtrage des répliques non pertinentes et une gestion plus souple de la fenêtre de contexte.

La principale leçon de cette partie est très terre à terre, et donc utile : la mémoire d'un chat LLM n'est pas une fonction magique du modèle, mais une responsabilité ordinaire du code qui l'entoure. Quelques lignes avec `conversation_history`, le bon ordre de `messages` et une simple limite de taille de l'historique suffisent à transformer un script de démonstration en base d'un assistant plus réaliste. Pour les développeurs, c'est un bon exemple : la valeur d'une interface de chat naît souvent moins du choix du modèle que du soin avec lequel l'application rassemble et transmet le contexte de la conversation.