Hablar con un modelo (LLM): la teoría y la primera llamada al SDK

En «Del ruido de la IA a un método» contaba cómo la IA se metió en mi día a día, tanto en el trabajo como por mi cuenta. Decía que iba a escribir más, sobre todo contenido técnico. Este es el primero: cómo funciona un modelo de lenguaje por dentro, y cómo se le habla desde código por primera vez.

Qué es y de qué está hecho un modelo

Este artículo es una buena introducción general a cómo funcionan los LLM, si quieres una vista de conjunto antes de entrar en el detalle de cada pieza.

Un modelo de lenguaje es, por dentro, una red neuronal: una red de nodos ("neuronas") organizados en capas, donde cada conexión entre dos neuronas lleva asociado un número — su peso — que decide cuánto "cuenta" la señal que pasa por ahí. Cada neurona combina las señales que le llegan teniendo en cuenta el peso de cada conexión, añade un valor propio — su sesgo — y aplica una función que determina la activación que pasa a la siguiente capa. 3Blue1Brown tiene un excelente artículo introductorio a toda la teoría de redes neuronales, con sus vídeos y el ejemplo clásico de reconocer dígitos escritos a mano.

Los pesos y los sesgos juntos son los parámetros del modelo. No son datos de entrada ni cambian entre una llamada y otra: se fijan durante el entrenamiento — el proceso de ajustarlos poco a poco, repitiendo millones de ejemplos hasta que las predicciones del modelo mejoran — y a partir de ahí quedan grabados, como el conocimiento del modelo. 3Blue1Brown entra en el detalle de cómo funciona ese ajuste. Una vez desplegado, el modelo utiliza esos parámetros sin modificarlos en cada respuesta, aunque sus creadores pueden volver a entrenarlo o ajustarlo en versiones posteriores. Cuando un nombre de modelo lleva un número grande detrás — 70B, 400B — ese número son sus parámetros: cuántos pesos y sesgos tiene toda la red en conjunto. Más parámetros no es automáticamente "mejor", pero sí es más capacidad para representar patrones complejos.

Esto por sí solo no basta para un modelo de lenguaje: hace falta además una forma de convertir texto en algo que una red neuronal pueda procesar, y una arquitectura concreta — el transformer — que permite a la red tener en cuenta el contexto de una frase entera, no solo palabra por palabra. La misma serie de 3Blue1Brown sigue por ahí, explicando cómo esos mismos pesos y sesgos se usan dentro de un LLM.

De texto a números: tokens y embeddings

Esos pesos y sesgos de los que hablaba arriba solo operan sobre números — una red neuronal no entiende texto directamente. Hay modelos que procesan también imagen, audio o vídeo (multimodales), pero aquí me centro en texto, que es lo que uso en el ejemplo de más abajo con Gemini.

Lo primero que pasa con una entrada de texto es que se divide en tokens: fragmentos de texto, no necesariamente palabras completas. Una palabra como "infeliz" podría dividirse en varios tokens, por ejemplo "in" y "feliz", aunque la división exacta depende del tokenizador. No es una regla gramatical: el criterio es estadístico, qué fragmentos de un vocabulario de tamaño fijo aparecen juntos muy a menudo en el idioma.

Cada token tiene asociado un vector —una lista de cientos o miles de números— almacenado en lo que se llama la embedding matrix: una tabla con una fila por cada token del vocabulario. Ese vector es la representación numérica inicial del token. Durante el entrenamiento, sus componentes se ajustan para que el modelo aprenda patrones de uso y relaciones entre los tokens. Como resultado, los vectores pueden reflejar similitudes lingüísticas o semánticas, aunque no constituyen una representación perfecta del significado. No es un paso de "agrupar por significado" aparte: es una consecuencia de cómo se entrena la red. 3Blue1Brown dedica un capítulo de su serie a esto mismo dentro de un LLM, con la embedding matrix y los vectores explicados de forma visual.

Un matiz importante: ese vector inicial es estático, el mismo para un token sin importar la frase en la que aparezca. "Banco" tiene idéntico vector tanto si hablas de dinero como de sentarte. El contexto lo añaden las capas siguientes de la red, no la embedding matrix.

Cómo se llega a una respuesta

Esos vectores estáticos atraviesan muchas capas de atención — el mecanismo central del transformer — que van mezclando la información de unos tokens con otros según cuánto se relacionen entre sí dentro de la frase. Es ahí donde el vector de "banco" deja de ser el mismo siempre y empieza a depender del resto de la frase: se vuelve contextual.

Al final de todas esas capas llega a la language modelling head: una última capa que convierte ese resultado en una puntuación para cada token posible del vocabulario — que puede tener cientos de miles de entradas —, y esas puntuaciones se convierten en probabilidades. Algo como "el token 'gato' tiene un 2% de probabilidad de ser el siguiente, 'perro' un 15%, 'el' casi un 0%".

Se elige uno de esos tokens — normalmente el más probable, con algo de margen controlado — y se añade a la secuencia. Después se repite todo el proceso para elegir el siguiente. Por eso un LLM genera texto token a token, no de una vez: cada nuevo token se predice mirando todos los anteriores. Toda la potencia de un LLM sale de hacer bien, una y otra vez, esa única tarea: predecir el siguiente token.

El puente: de LLM a usar un SDK

Toda esta red neuronal — los parámetros, la embedding matrix, las capas de atención — vive entrenada y alojada en servidores de empresas como Google, Anthropic, OpenAI o DeepSeek: son demasiado grandes y caras de entrenar y ejecutar para tenerlas en un portátil (aparte quedan los modelos locales, más pequeños, para otro artículo).

De forma resumida, esas empresas publican una API para poder pedirle algo al modelo desde fuera, y para usarla hay dos caminos:

• Hacer la petición a esa API directamente y a mano — con fetch, curl, lo que sea.
• Usar el SDK del fabricante: una librería que construye esa misma petición por ti — la autenticación, el formato JSON, leer la respuesta.

Es justo lo que vamos a hacer más abajo con @google/genai: una llamada a aiClient.interactions.create(...) en vez de montar un fetch() manual.

La primera llamada real

Esto es lo mínimo imprescindible para tener el SDK funcionando — una sola llamada de ida y vuelta al modelo, sin nada más. Uso Gemini, de Google, siguiendo su guía oficial de inicio.

1. API key: la credencial que identifica tus peticiones ante la API de Google. Se crea en aistudio.google.com/apikey, botón "Create API key".

2. Entorno: Google ofrece el SDK también en Python, pero uso Node por preferencia personal — con "type": "module" en el package.json para poder usar import.

3. SDK: npm install @google/genai.

4. El script (main.js):

   import { GoogleGenAI } from "@google/genai";
   
   // Importamos la api KEY de Google GenAI desde las variables de entorno
   const apiKey = process.env.GEMINI_API_KEY;
   
   // Creamos una instancia del cliente de Google GenAI
   const aiClient = new GoogleGenAI({
       apiKey: apiKey,
   });
   
   // Creamos una interacción con el modelo
   const interaction = await aiClient.interactions.create({
       model: "gemini-3.5-flash-lite",
       input: "Hola, ¿qué modelo gratis me recomiendas para practicar los inicios de un SDK de inteligencia artificial?",
   });
   
   console.log(interaction.output_text);
   

5. Ejecución: node main.js.

Y con eso, ya hay una respuesta real del modelo en la terminal — tal cual la devolvió esa ejecución concreta, sin verificar: las cifras y comparaciones que incluye no son datos contrastados, son parte de lo que el modelo generó, y es justo lo que la sección siguiente pone en duda.

El mejor modelo actualmente para empezar a programar con un SDK, que combina **gratuidad real, facilidad de uso y un rendimiento de gama alta**, es:

### 1. El Ganador Indiscutible: **Google Gemini 1.5 Flash** (vía Google AI Studio)

Es la mejor opción para principiantes por las siguientes razones:

*   **Es 100% gratis para desarrolladores:** Con **Google AI Studio**, te dan acceso a una clave de API sin pedirte tarjeta de crédito. Su capa gratuita te permite hasta 15 peticiones por minuto (RPM) y un millón de tokens por minuto, lo cual es más que suficiente para aprender y hacer proyectos personales.
*   **Rendimiento sobresaliente:** Aunque se llama "Flash" (diseñado para ser rápido y ligero), supera a GPT-3.5 y compite de cerca con GPT-4o en muchas tareas.
*   **Multimodal nativo:** Con el mismo SDK gratuito puedes enviarle texto, imágenes, audio, vídeo y PDFs.

[...]

Cuando el modelo se equivoca sobre sí mismo

El modelo introdujo afirmaciones sobre sí mismo que no le había pedido verificar, y mezcló nombres de modelo desactualizados (gemini-1.5-flash, el que recomienda arriba) con el modelo real que estaba usando en esa misma llamada (gemini-3.5-flash-lite). Probé a usar ese nombre que había sugerido él mismo, y la API devolvió un error real:

NotFoundError: 404 Model 'gemini-1.5-flash' not found. Did you mean 'gemini-3.5-flash'?
Please verify the model name against the supported list: https://ai.google.dev/gemini-api/docs/models

Comprobé el nombre en la lista de modelos vigentes y en la de modelos retirados: no encontré el identificador en ninguna de las dos listas, así que no pude confirmar su disponibilidad. La API también rechazó la petición y sugirió otro nombre de modelo.

Esto es un caso concreto de lo que se conoce como alucinación: el modelo genera algo que suena plausible — un nombre de modelo con el formato correcto, de una familia que existe — pero que es falso. En este artículo se hace mención a eso: los LLM "pueden producir con total confianza información incorrecta o engañosa, sobre todo al preguntarles por hechos o temas poco frecuentes" — y un modelo hablando de sí mismo es exactamente ese caso. La fuente fiable no es la respuesta del chat, es la documentación oficial — y es el propio error de la API el que termina señalándola.

Otras compañías, otros SDKs

En el ejemplo de este artículo hemos usado Google (Gemini), pero no es la única que ofrece modelos y sus SDK. Las tres con más peso hoy en productos reales son Google, Anthropic (Claude) y OpenAI (GPT) — cada una con su propia API, su propio SDK y su propio catálogo de modelos vigentes.

Por detrás hay más: DeepSeek, china, que irrumpió en 2025 con modelos que compiten de cerca con los anteriores a mucho menor coste; Mistral, francesa, con peso real en el mercado europeo; xAI (Grok), de Elon Musk; y Meta, con su familia de modelos Llama.

Entre estas compañías hay una diferencia que no es solo de tamaño de empresa. Meta y DeepSeek publican modelos con pesos abiertos — ese fichero de parámetros del que hablaba al principio — que pueden descargarse y ejecutarse en hardware propio, sujetos a las condiciones de la licencia de cada versión de Llama o la de DeepSeek. Google también ofrece modelos de pesos abiertos, como Gemma, aunque sus modelos Gemini tienen pesos cerrados. Anthropic y OpenAI ofrecen sus principales modelos comerciales mediante servicios alojados, sin publicar sus pesos.

En cualquier caso, publicar los pesos no equivale a publicar todos los datos y procesos de entrenamiento ni implica necesariamente una licencia de código abierto. Son cuestiones distintas que conviene separar. Puedes ejecutar Llama, DeepSeek o Gemma en tu propio hardware, pero no puedes repetir el entrenamiento que los produjo: te falta el código y los datos que usaron, solo tienes el resultado final.

A continuación, algunos de los modelos más importantes de las compañías de arriba:

A fecha de este artículo (octubre de 2026). Cada compañía lanza modelos nuevos a menudo; los enlaces de arriba llevan al catálogo vigente de cada una, no a estos nombres concretos.

Lo que queda

De la teoría a una llamada real hay un salto, pero no tan grande como parecía desde fuera: unos pesos y sesgos entrenados, un texto convertido en vectores, y una predicción del siguiente token repetida una y otra vez. El SDK solo envuelve eso en una función.

Lo que no he tocado aquí: por qué elegí gemini-3.5-flash-lite y no otro modelo del catálogo de Gemini, cómo se construye una conversación con varios turnos en vez de una sola llamada, y RAG — que usa estos mismos embeddings para otra cosa, buscar información relevante antes de preguntarle nada al modelo. Material para próximos artículos.