Habr AI muestra cómo añadir memoria y contexto a un chat LLM en Python con Ollama y LiteLLM

Un chat de consola sencillo con un LLM deja de ser un chat de verdad si el modelo solo ve la pregunta actual. En la nueva entrega de la guía práctica sobre Python, Ollama y LiteLLM, el autor muestra el paso más importante tras la integración básica: cómo añadir el historial de mensajes y convertir una cadena de peticiones sueltas en un diálogo coherente con contexto.

El problema de la versión anterior era que, en cada turno, el programa enviaba al modelo solo la instrucción del sistema y el último mensaje del usuario. Para una persona, esta limitación casi pasa inadvertida hasta que aparecen preguntas dependientes como «hazlo más corto» o «añádele práctica». Sin los mensajes previos, el modelo no sabe a qué se refieren los pronombres ni las aclaraciones, y por eso puede responder al azar o perder el hilo de la conversación. Eso es justo lo que distingue una llamada puntual al modelo de una interfaz conversacional.

El análisis subraya una idea que a menudo se simplifica al hablar de LLM: el modelo no tiene una memoria oculta a largo plazo entre llamadas. La memoria de un chat así no la crea Ollama ni LiteLLM, sino la aplicación, que guarda la conversación y la reenvía al modelo en cada nueva petición. El ejemplo didáctico usa una lista normal de Python, `conversation_history`, donde se añaden por turnos los mensajes con los roles user y assistant. El system prompt no se guarda en el historial, sino que se añade por separado cada vez que se construye la petición.

En términos de arquitectura el cambio parece pequeño, pero modifica radicalmente el comportamiento del programa. La función que envía la petición ahora acepta no solo el `user_message` actual, sino también el historial. Después se forma la lista `messages` en un orden estricto: system, luego todas las intervenciones pasadas y por último la nueva pregunta del usuario. Cuando el modelo responde, la aplicación guarda ambos lados del intercambio: la pregunta y la respuesta. No es un detalle decorativo: si solo se registran los mensajes del usuario, la siguiente petición quedará incompleta, porque el modelo verá que se hizo una pregunta, pero no cómo respondió él mismo.

También se analiza por separado el límite del historial. El ejemplo introduce la constante `MAX_HISTORY_MESSAGES = 6`, y la función auxiliar `trim_history` conserva solo los últimos seis mensajes, es decir, los tres últimos intercambios. Para un prototipo local es un compromiso práctico: el historial no crece sin fin, las peticiones no se inflan y el modelo sigue recibiendo el contexto más cercano. Sirve para ilustrar que, en las aplicaciones LLM, la memoria siempre exige equilibrar calidad de respuesta, latencia y coste o carga, incluso con un modelo local.

El artículo usa una configuración local basada en Ollama, LiteLLM y el modelo `qwen2.5:3b`. Esta pila es cómoda para aprender porque permite montar un chat funcional sin API externa y sin infraestructura compleja. Los ejemplos muestran bien cómo cambia la reacción del sistema al añadir el historial: la petición «cuéntame más sobre el segundo» empieza a referirse correctamente a la lista anterior, y la frase «hazlo más corto» deja de interpretarse como una orden abstracta aislada. Es decir, el modelo no se vuelve más inteligente por sí solo, pero la aplicación le da el contexto que antes se perdía.

Las limitaciones de esta versión también se señalan sin rodeos. Todo el historial vive solo en la memoria RAM de la ejecución actual: si se cierra el script, el diálogo desaparece. Para una CLI didáctica basta, pero un bot de Telegram, un servicio web o un asistente de cliente necesitarán almacenamiento persistente, al menos en un archivo, SQLite o una base de datos completa. Los siguientes pasos suelen incluir también el resumen de diálogos largos, el filtrado de mensajes irrelevantes y una gestión más flexible de la ventana de contexto.

La conclusión principal de esta entrega es muy terrenal y, por eso, útil: la memoria en un chat LLM no es una función mágica independiente del modelo, sino una responsabilidad corriente del código que lo rodea. Unas pocas líneas con `conversation_history`, el orden correcto de `messages` y un límite sencillo al tamaño del historial bastan para convertir un script de demostración en la base de un asistente más realista. Para los desarrolladores es un buen ejemplo de que el valor de una interfaz de chat a menudo no nace de la elección del modelo, sino de lo cuidadosamente que la aplicación reúne y transmite el contexto de la conversación.