Habr AI explica por qué los LLM no calculan, no aprenden en la conversación y dependen de herramientas

Un artículo de Habr AI aborda el mito popular de que un chatbot moderno ya es, por sí solo, una inteligencia universal. La tesis central del autor es sencilla: un LLM base, por su naturaleza, solo sabe trabajar con texto: recibe una petición en texto y genera una respuesta en texto. Todo lo demás, lo que el usuario percibe como «capacidades mágicas» del modelo, suele venir de herramientas externas, integraciones y orquestación. Por eso las mismas interfaces pueden dibujar imágenes, buscar en internet y calcular números, aunque el modelo de lenguaje no se convierta por ello en artista, buscador ni calculadora.

El primer error es la sensación de que un LLM «lo sabe hacer todo». Si se le pide crear una imagen, genera una petición para un modelo de generación independiente. Si se habla con él por voz, en la cadena participan el reconocimiento de voz y la síntesis de voz.

Si hace falta un cálculo exacto, el resultado fiable suele aparecer solo después de llamar a un intérprete de código o a otra herramienta de cálculo. Sin estos añadidos, el LLM se apoya en la reproducción probabilística de patrones aprendidos en el entrenamiento: puede resolver correctamente un ejemplo sencillo, pero se equivoca con facilidad con números largos, fórmulas y tareas de alta precisión. De ahí se desprende un límite práctico importante: la fortaleza del modelo no son las matemáticas como tales, sino describir la tarea en texto y elegir la herramienta adecuada.

El segundo mito es que el modelo aprende durante la conversación. El autor recuerda que inferencia y entrenamiento son dos procesos distintos. Cuando el usuario escribe una petición, el modelo genera tokens uno tras otro a partir de pesos ya fijados, y esos pesos no cambian en ese momento.

Por tanto, un LLM concreto en una sesión concreta no «memoriza la lección» ni se vuelve más listo por una corrección del usuario. Es cierto que los proveedores pueden usar después conversaciones anonimizadas para entrenar versiones futuras, pero eso es un ciclo de ajuste aparte, no una autoactualización mágica en el chat. De ahí se deduce otra conclusión: la memoria sobre el usuario entre conversaciones normalmente no es entrenamiento del modelo, sino contexto guardado que se vuelve a incorporar a la petición.

A continuación, el artículo explica brevemente de qué consta un LLM público. En su base está el transformer, que ve todo el contexto disponible a la vez y construye la respuesta como una secuencia de tokens probables, manteniendo la coherencia general del texto gracias a plantillas aprendidas. Encima actúa el RLHF, un ajuste al formato de asistente, la cortesía, el seguimiento de instrucciones y las restricciones de seguridad.

Pero el RLHF no convierte al modelo en una máquina lógica ni corrige sus debilidades fundamentales. Por eso los modelos de lenguaje funcionan bien en el análisis de texto, el resumen, el cambio de estilo, las instrucciones paso a paso, el trabajo con formatos como JSON y la elección de herramientas. Son débiles en cálculos exactos, en el procesamiento de tablas grandes, en mantener enormes volúmenes de datos en el contexto y en conocer el estado actual del mundo después de la fecha de entrenamiento.

A ello se suman la naturaleza probabilística de la respuesta, la sensibilidad a la redacción del prompt y el riesgo de alucinaciones.

Para que un LLM sea útil en producción, se construye a su alrededor una capa adicional. Para el conocimiento estático se usa RAG: los documentos se dividen en fragmentos, ante una consulta se buscan los trozos semánticamente cercanos y el modelo recibe solo el contexto relevante. Para datos dinámicos y acciones se aplica function calling: el LLM decide cuándo recurrir a una API, una base de datos, una calculadora o una simulación, mientras que el orquestador valida las llamadas, añade las respuestas de las herramientas al historial y gestiona todo el ciclo. Ese mismo orquestador se encarga de la memoria del diálogo, los prompts del sistema, la comprobación del formato de salida y el lanzamiento de subagentes.

Sobre esta base surgen conceptos más sonoros: agentes de IA, empleados digitales, copilots y gemelos digitales. En esencia, no son una magia aparte, sino combinaciones de LLM, bases de conocimiento, API, automatización y motores de cálculo clásicos. Esto significa que ya no basta con hablar de «inteligencia artificial» sin distinguir las tecnologías. Si una empresa necesita un cálculo exacto, una automatización estricta o una previsión sobre datos estructurados, un LLM por sí solo no basta. Si necesita trabajar con correos, documentos, instrucciones, búsqueda de conocimiento y una interfaz conversacional para un sistema complejo, el LLM sí supone un impulso notable.

La mirada sobria del artículo es útil precisamente porque elimina expectativas excesivas: no hay que atribuir superpoderes al modelo de lenguaje, pero tampoco conviene subestimarlo como interfaz y coordinador de otras herramientas.