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

Un simple chat de console avec un LLM cesse d'être un vrai chat si le modèle ne voit que la question actuelle. Dans une nouvelle partie du guide pratique Python avec Ollama et LiteLLM, l'auteur montre l'étape la plus importante après l'intégration de base : comment ajouter un historique de messages et transformer une chaîne de requêtes séparées en un dialogue cohérent avec contexte. Le problème de la version précédente était qu'à chaque tour, le programme envoyait au modèle uniquement l'instruction système et une nouvelle réponse de l'utilisateur.

Pour un humain, cela semble une limitation presque imperceptible jusqu'à ce que des questions dépendantes apparaissent comme "rends-le plus court" ou "ajoute-y de la pratique". Sans messages précédents, le modèle ne sait pas à quoi se réfèrent les pronoms et les clarifications, et peut donc répondre aléatoirement ou perdre le fil de la conversation. C'est exactement ce qui distingue un appel unique du modèle d'une interface de dialogue.

L'analyse souligne une idée importante qui est souvent simplifiée dans les discussions sur les LLM : le modèle n'a pas de mémoire cachée à long terme entre les appels. La mémoire dans un tel chat n'est pas créée par Ollama ou LiteLLM lui-même, mais par l'application qui stocke la conversation et l'envoie à nouveau au modèle à chaque nouvelle requête. Dans l'exemple pédagogique, on utilise une simple liste Python conversation_history pour cela, où les messages avec les rôles user et assistant sont enregistrés tour à tour.

L'invite système n'est pas stockée dans l'historique, mais ajoutée séparément chaque fois que la requête est construite. Architecturalement, le changement semble mineur, mais change radicalement le comportement du programme. La fonction d'envoi de requête prend maintenant non seulement le user_message actuel, mais aussi l'historique.

Puis une liste de messages est formée dans un ordre strict : system, puis toutes les répliques précédentes, puis la nouvelle question de l'utilisateur. Après la réponse du modèle, l'application sauvegarde les deux côtés de l'échange — à la fois la question et la réponse. Ce n'est pas un détail décoratif : si vous n'enregistrez que les réponses de l'utilisateur, la requête suivante sera incomplète car le modèle verra que la question a déjà été posée mais ne verra pas comment il a répondu lui-même.

Séparément, la limitation de l'historique est également discutée. Dans l'exemple, une constante MAX_HISTORY_MESSAGES = 6 est introduite, et une fonction auxiliaire trim_history ne conserve que les six derniers messages, c'est-à-dire les trois derniers échanges de répliques. Pour un prototype local, c'est un compromis pratique : l'historique ne croît pas indéfiniment, les requêtes ne gonflent pas, et le modèle obtient toujours le contexte le plus proche.

C'est une bonne façon de montrer que la mémoire dans les applications LLM doit toujours équilibrer entre la qualité de la réponse, la latence et le coût ou la charge, même pour un modèle local. L'article utilise une configuration locale basée sur Ollama, LiteLLM et le modèle qwen2.5:3b.

Cette pile est pratique pour l'apprentissage car elle permet de construire un chat fonctionnel sans API externe et sans infrastructure complexe. Dans les exemples, vous pouvez clairement voir comment la réaction du système change après l'ajout de l'historique : la requête "parle-moi plus sur le deuxième" se réfère maintenant correctement à la liste précédente, et la phrase "rends-le plus court" n'est plus perçue comme une commande abstraite séparée. C'est-à-dire que le modèle ne devient pas plus intelligent en soi, mais l'application lui donne le contexte qui se perdait auparavant.

Dans le même temps, les limitations de cette version sont également nommées directement. Tout l'historique est stocké uniquement dans la RAM de l'exécution actuelle : si vous fermez le script, le dialogue disparaît. Pour un CLI pédagogique, c'est suffisant, mais pour un bot Telegram, un service web ou un assistant client, un stockage permanent serait nécessaire — au moins dans un fichier, SQLite ou une base de données complète.

Les étapes suivantes incluent généralement aussi la résumé des longs dialogues, le filtrage des répliques non pertinentes et une gestion plus flexible de la fenêtre de contexte. La conclusion principale de cette partie est très pragmatique et donc utile : la mémoire dans un chat LLM n'est pas une fonction magique séparée du modèle, mais la responsabilité ordinaire du code qui l'entoure. Quelques lignes seulement avec conversation_history, l'ordre correct des messages et une simple limite de taille d'historique transforment déjà le script de démonstration en fondation pour un assistant plus réaliste.

Pour les développeurs, c'est un bon exemple de la façon dont la valeur d'une interface de chat est souvent née non pas dans le choix du modèle lui-même, mais dans la façon dont l'application recueille et transmet soigneusement le contexte de la conversation.