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

Un simple chat de consola con un LLM deja de ser un verdadero chat si el modelo solo ve la pregunta actual. En una nueva parte de la guía práctica de Python con Ollama y LiteLLM, el autor muestra el paso más importante después de la integración básica: cómo añadir historial de mensajes y convertir una cadena de solicitudes separadas 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 una respuesta nueva del usuario.

Para un humano, esto se ve como una limitación casi imperceptible hasta que aparecen preguntas dependientes como "hazlo más corto" o "añádele práctica". Sin mensajes anteriores, el modelo no sabe a qué se refieren los pronombres y aclaraciones, y por tanto puede responder al azar o perder el hilo de la conversación. Esto es exactamente lo que distingue una llamada única al modelo de una interfaz de diálogo.

El análisis subraya una idea importante que a menudo se simplifica en las discusiones sobre LLM: el modelo no tiene memoria oculta de largo plazo entre llamadas. La memoria en tal chat no la crea Ollama ni LiteLLM en sí, sino la aplicación que almacena la conversación y la envía al modelo de nuevo en cada nueva solicitud. En el ejemplo educativo se utiliza una simple lista de Python conversation_history para esto, donde se registran mensajes con roles de usuario y asistente por turno.

El prompt del sistema no se almacena en el historial, sino que se añade por separado cada vez que se monta la solicitud. Arquitectónicamente, el cambio parece pequeño, pero cambia radicalmente el comportamiento del programa. La función de envío de solicitud ahora toma no solo el user_message actual, sino también el historial.

Entonces se forma una lista de messages en orden estricto: system, luego todas las respuestas anteriores, luego la nueva pregunta del usuario. Después de la respuesta del modelo, la aplicación guarda ambos lados del intercambio — tanto la pregunta como la respuesta. Esto no es un detalle decorativo: si solo se registran respuestas del usuario, la siguiente solicitud será incompleta porque el modelo verá que la pregunta ya se formuló pero no verá cómo ella misma la respondió.

Por separado se discute también la limitación del historial. En el ejemplo se introduce una constante MAX_HISTORY_MESSAGES = 6, y una función auxiliar trim_history mantiene solo los últimos seis mensajes, es decir, los últimos tres intercambios de réplicas. Para un prototipo local, este es un compromiso práctico: el historial no crece infinitamente, las solicitudes no se inflan, y el modelo aún obtiene el contexto más cercano.

Esta es una buena forma de mostrar que la memoria en aplicaciones LLM siempre debe equilibrarse entre la calidad de la respuesta, la latencia y el costo o carga, incluso cuando se trata de un modelo local. El artículo utiliza una configuración local basada en Ollama, LiteLLM y el modelo qwen2.5:3b.

Este stack es conveniente para el aprendizaje porque permite construir un chat funcional sin API externa y sin infraestructura compleja. En los ejemplos se ve claramente cómo cambia la reacción del sistema después de añadir historial: la solicitud "cuéntame más sobre el segundo" ahora se refiere correctamente a la lista anterior, y la frase "hazlo más corto" ya no se percibe como un comando abstracto separado. Es decir, el modelo no se vuelve más inteligente por sí mismo, pero la aplicación le da el contexto que antes simplemente se perdía.

Al mismo tiempo, las limitaciones de esta versión también se mencionan directamente. Todo el historial se almacena solo en la RAM de la ejecución actual: si cierras el script, el diálogo desaparece. Para un CLI educativo, esto es suficiente, pero para un bot de Telegram, servicio web o asistente cliente, se necesitaría almacenamiento permanente — al menos en un archivo, SQLite o base de datos completa.

Los siguientes pasos generalmente incluyen también la summarización de diálogos largos, el filtrado de réplicas irrelevantes y una gestión más flexible de la ventana de contexto. La conclusión principal de esta parte es muy práctica y por tanto útil: la memoria en un chat LLM no es una función mágica separada del modelo, sino la responsabilidad común del código a su alrededor. Solo algunas líneas con conversation_history, el orden correcto de messages y un simple límite de tamaño del historial ya convierten el script de demostración en la base para un asistente más realista.

Para los desarrolladores, este es un buen ejemplo de cómo el valor de una interfaz de chat frecuentemente nace no en la elección del modelo en sí, sino en cómo cuidadosamente la aplicación recopila y transmite el contexto de la conversación.