Modelo mental, resumen y autoevaluación

Qué aprenderás

• Un modelo mental técnicamente prudente de un LLM.
• Cómo conectar las 13 unidades anteriores.
• Cómo comprobar si podés explicar el recorrido sin antropomorfismos.

Modelo mental útil

Un LLM es un modelo generativo probabilístico condicionado por contexto, entrenado para trabajar con secuencias y capaz de producir comportamientos complejos, pero sin garantía automática de verdad. Una aplicación prepara instrucciones, mensajes, historial, documentos y resultados de herramientas; ese contexto se tokeniza y se transforma en representaciones numéricas. Una arquitectura como Transformer procesa esas representaciones con attention, capas y parámetros aprendidos. Después calcula probabilidades, selecciona un token siguiente y repite hasta producir una salida.

Esta descripción es más útil que estas cuatro ideas incompletas:

• Es una base de datos gigante. Los parámetros no son registros consultables.
• Es un buscador. Puede generar texto sin recuperar una fuente y una aplicación

puede agregar búsqueda por separado.

• Es una persona digital. No hay que atribuirle estados mentales humanos.
• Solo copia texto. Puede producir combinaciones y comportamientos complejos,

aunque eso no garantice verdad ni comprensión humana.

Mapa conceptual

Aplicación
   │
   ├── instrucciones del sistema/developer
   ├── usuario
   ├── historial seleccionado
   ├── documentos y datos
   └── resultados de herramientas
           ↓
        Contexto efectivo
           ↓
           Texto
           ↓
       Tokenización
           ↓
          Tokens
           ↓
  Representaciones numéricas + posición
           ↓
        Transformer
           ↓
  Attention + capas + parámetros
           ↓
       Probabilidades
           ↓
      Siguiente token
           ↓
       Nuevo contexto
           ↓
          Repetir
           ↓
        Respuesta
           ↓
  verificación, reglas y supervisión

El diagrama es una simplificación pedagógica: una implementación real puede agregar filtros, herramientas, distintos modelos, pasos de recuperación y validaciones en otros puntos.

La analogía transversal del profesional nuevo

Analogía simplificada: imaginemos que se incorpora a la empresa un profesional nuevo con conocimientos generales muy amplios. Puede ayudar con documentación, análisis o redacción, pero no conoce automáticamente el ERP, las tablas, los clientes, los procedimientos ni las reglas de negocio. Para una tarea concreta, la organización debe aportar contexto, documentación o RAG, tools, skills, reglas y permisos.

capacidades generales del LLM
        + contexto de la empresa
        + documentación/RAG
        + tools y skills
        + reglas y permisos
        ↓
asistente especializado para una tarea

La analogía no convierte al LLM en una persona, no le atribuye intención y no implica acceso automático a información interna. Funciona como puente hacia M3 Prompt Engineering y M4 Context Engineering: esos módulos enseñarán a diseñar mejor instrucciones y contexto, no a humanizar el modelo.

Autoevaluación razonada

1. ¿Un token es una palabra? No necesariamente. Es una unidad del

tokenizador; puede ser una palabra, un fragmento, un signo o parte de otra unidad según el modelo.

1. ¿Un token y un embedding son lo mismo? No. El token es una unidad de la

secuencia; el embedding es una representación numérica usada durante el procesamiento. Además, un embedding de búsqueda RAG no es necesariamente el embedding interno del LLM.

1. ¿Qué describe Transformer? Una arquitectura para transformar secuencias

mediante bloques que incluyen attention y otras operaciones. No es sinónimo de LLM ni de una aplicación de chat.

1. ¿Attention significa que el modelo presta atención consciente? No. Es un

mecanismo matemático para combinar representaciones de posiciones relacionadas.

1. ¿Los parámetros son documentos o registros? No. Son valores ajustados en

el entrenamiento que participan de transformaciones distribuidas; no forman una base de datos legible.

1. ¿Qué predice un LLM durante la generación? Una distribución de posibles

tokens siguientes condicionada por la secuencia y el contexto disponibles. Una respuesta completa aparece al repetir ese proceso.

1. ¿Qué diferencia hay entre input y output? Input es lo que la aplicación

envía al modelo; output es la secuencia generada. La aplicación puede validar, filtrar o usar ese output antes de mostrarlo o actuar.

1. ¿Qué pueden aportar system, developer y user? Pueden representar reglas

generales, instrucciones de aplicación y pedido de usuario, respectivamente, cuando una API distingue esos roles. Sus nombres y jerarquía no son idénticos para todos los proveedores.

1. ¿El historial de una conversación siempre se envía completo? No. Una

aplicación puede seleccionar, resumir o truncar historial para construir la llamada que entra en la ventana de contexto.

1. ¿Qué diferencia hay entre contexto explícito e implícito? El explícito

se aporta deliberadamente para la tarea; el implícito llega por historial, metadatos, reglas o datos agregados por la aplicación sin estar en el mensaje visible.

1. ¿Qué cambia el sampling? Cambia cómo se elige entre posibles tokens de

la distribución. Temperatura, top-p, top-k y seed tienen disponibilidad y efectos que dependen del modelo y la API; no son recetas universales.

1. ¿Ventana de contexto y memoria persistente son lo mismo? No. La ventana

limita una llamada; el historial puede almacenarse fuera de ella; la memoria persistente es una decisión de la aplicación para conservar información.

1. ¿Por qué un LLM puede equivocarse con una respuesta fluida? Porque

genera continuaciones plausibles y puede tener conocimiento incompleto, contexto insuficiente, ambigüedad, sesgos o errores en documentos y tools. Fluidez no es verificación.

1. ¿Un RAG garantiza verdad? No. Puede acercar documentos relevantes, pero

hay que verificar su procedencia, versión, permisos y correspondencia con la afirmación generada.

1. ¿Un LLM razona? Puede mostrar comportamientos que evaluamos como

razonamiento en tareas concretas, sin que eso implique que piensa o comprende como una persona. Conviene pedir planes y pasos verificables, y medir resultados.

1. ¿Cómo se elige entre modelos? Por la tarea y sus restricciones: calidad

necesaria, latencia, costo, privacidad, contexto, modalidad, especialización, disponibilidad e integración. El modelo más grande o de razonamiento no es siempre la mejor opción.

Checklist para cerrar el módulo

• Puedo explicar tokens sin igualarlos a palabras.
• Distingo embedding interno de embedding para búsqueda.
• Distingo arquitectura, modelo, chat y aplicación.
• Puedo describir la generación del siguiente token.
• Sé que el usuario no es necesariamente la única fuente del contexto.
• Distingo contexto, historial y memoria persistente.
• Verifico respuestas de riesgo con fuentes, tools o supervisión.
• Hablo de razonamiento sin atribuir una mente humana ni exigir cadenas privadas.
• Selecciono modelos por tarea y restricciones, no por tamaño o popularidad.

Fuentes

• Attention Is All You Need — Vaswani et al., arXiv — https://arxiv.org/abs/1706.03762 — consulta: 2026-10-03.
• Language Models are Few-Shot Learners — Brown et al., arXiv — https://arxiv.org/abs/2005.14165 — consulta: 2026-10-03.
• AI Risk Management Framework: Generative AI Profile — NIST — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence — consulta: 2026-10-03.

Seguir aprendiendo

• Módulo 3: Prompt Engineering, para diseñar instrucciones claras.
• Módulo 4: Context Engineering, para seleccionar contexto, fuentes y herramientas.
• Revisar M1 para conectar este modelo operativo con los fundamentos de IA.