Conceptos de IA desde cero

Esta página es el glosario-con-el-que-pensar del resto de la documentación. Explica, desde primeros principios, las ideas de inteligencia artificial sobre las que se construye el Space. No necesitas background de machine learning — al terminar sabrás qué es un token, un embedding y una “ventana de contexto”, por qué importa la temperatura, cómo funciona la generación aumentada por recuperación, y qué convierte algo en un agente en lugar de un chatbot.

Cada sección cierra con una nota “En el Space” que ata el concepto a la página que lo usa.

Modelos de lenguaje grandes (LLMs)

Un modelo de lenguaje grande es un programa entrenado con una cantidad enorme de texto escrito que aprende a predecir el siguiente fragmento de texto dados todos los fragmentos escritos antes. Dado La capital de Francia es, un modelo asigna una probabilidad a la continuación más plausible — casi seguro París.

Dos cosas hacen que esto sea más que un autocompletado:

1. Escala. Entrenado con mucho más texto y con muchos más parámetros que un modelo de juguete, aprende gramática, hechos, patrones de razonamiento, lenguajes de programación e incluso estilo.
2. El baile del siguiente token, repetido. Para responder, se le da un prompt, produce un token, lo añade al prompt, predice el siguiente y continúa — cada paso condicionado por todos los anteriores. Ese bucle, repetido miles de veces, es como escribe un ensayo o una función.

Un modelo crudo es probabilístico: muestrea entre las continuaciones posibles en lugar de elegir solo la más probable. Ese azar es lo que hace que la salida parezca creativa, y también es por lo que obtienes una respuesta distinta si ejecutas el mismo prompt de nuevo.

Tu modelo solo tiene estado a través de su entrada. Tras el entrenamiento, el modelo no tiene memoria, no recuerda nada entre llamadas y no puede mirar nada por sí mismo. Todo lo que “sabe” para una respuesta debe estar escrito en la petición que envías — este único hecho explica casi toda la arquitectura de esta documentación (system prompts, memoria, embeddings, RAG, herramientas).

En el Space: Modelos y API keys te deja elegir qué modelo corre; el chat y el pipeline de agentes envían peticiones por ese mismo bucle token a token.

Tokens

Un token es la unidad de texto que un LLM lee y escribe — ni un carácter ni una palabra, sino un trocito de sub-palabra del vocabulario fijo del modelo. “Tokenizar” es partir el texto en esas piezas:

Texto	Tokenización aproximada
Hola mundo	[Hola] [ mundo]
increíble	a menudo [in] [creí] [ble]
café	[caf] [é] (los acentos pueden partirse o costar más)

A grandes rasgos, en inglés corren ~0,75 palabras por token en texto normal (unos 4 caracteres), pero varía por idioma y contenido. El código, la notación matemática y los alfabetos no latinos tienden a usar más tokens por “palabra”.

Por qué importan los tokens:

• Son la moneda del coste. Los proveedores facturan por token — normalmente un input (prompt) más barato y un output (completado) más caro.
• Limitan cuánto puede manejar el modelo a la vez. Un modelo con ventana de 128k puede leer, en una sola petición, aproximadamente el texto que cabe en 128k tokens.
• Dimensionan lo que se envía. Cuando el Space muestra “tokens estimados en contexto”, está calculando cuánto de la ventana del modelo consumirían tus mensajes y memoria actuales.

Las métricas de “tokens de razonamiento” se refieren a los tokens que el modelo gasta pensando antes de responder (ver Razonamiento).

En el Space: el dashboard de uso (/space/governance) informa de tokens prompt/completado/cacheados/razonamiento por petición; el catálogo de modelos muestra el precio por token.

La ventana de contexto y el “aprendizaje en contexto”

Un modelo procesa una cantidad fija de texto por petición, llamada su ventana de contexto (o longitud de contexto). Todo lo que quieras que el modelo “vea” para una respuesta — instrucciones del sistema, historial, memoria previa, documentos recuperados — debe caber dentro de esa ventana en esa petición.

No hay un almacenamiento a corto plazo aparte que crezca mientras chateas: una conversación es un prompt que crece. Cada respuesta del asistente no la recuerda el modelo; el cliente reenvía el historial acumulado (hasta un límite) para que el modelo parezca recordar. Esto se llama aprendizaje en contexto: el modelo aprende qué hacer no actualizándose a sí mismo, sino por lo que pones en el contexto.

Consecuencias:

• Las conversaciones largas acaban superando la ventana, así que la plataforma aplica un límite de contexto — conserva los mensajes más recientes y relevantes y descarta los antiguos.
• Por eso existen la memoria y la base de conocimiento: para comprimir lo relevante en algo que quepa en la ventana.

Piensa en la ventana como un escritorio. No puedes tener infinitos papeles — cuando se llena, tienes que decidir qué papeles se quedan encima. El límite de contexto y el RAG del Space son esa lógica de “qué se queda en el escritorio”.

En el Space: el ajuste global contextLimit y las herramientas de memoria/conocimiento existen precisamente porque la ventana es finita.

Parámetros de sampling: temperatura, top-p, top-k, penalizaciones

Cuando el modelo produce el siguiente token, calcula probabilidades sobre todo su vocabulario. Los parámetros de sampling moldean cuál de esos tokens se elige realmente — cuán “creativo” o cuán “determinista” es el modelo.

• Temperatura. Escala la distribución de probabilidad. Baja (p. ej. 0.1) hace que el modelo casi siempre elija el token más probable → respuestas centradas y deterministas. Alta (p. ej. 1+) aplana la distribución → salida más diversa, a veces sorprendente. 0.7 es un default habitual que equilibra coherencia y creatividad.
• Top-p (nucleus sampling). Solo considera el conjunto más pequeño de tokens cuya probabilidad combinada alcanza p. 1 significa sin recorte; 0.9 restringe la salida al 90% de masa de probabilidad.
• Top-k. Solo considera los k tokens más probables. k menor = más conservador. 0 normalmente significa desactivado.
• Penalizaciones de presencia / frecuencia. Reducen la probabilidad de tokens que ya han aparecido — frenando la repetición. La de presencia penaliza reaparecer sin importar el conteo; la de frecuencia penaliza proporcionalmente a cuánto se repiten.

Ninguno de estos es “marcar una casilla técnica” — son las perillas que deciden si el asistente responde seco, ofrece opciones o re-explica patrones. Por eso el mismo prompt puede dar resultados distintos: el sampling es estocástico.

En el Space: Ajustes globales expone temperatura, máx. tokens, top-p, top-k y penalizaciones de presencia/frecuencia, persistidas en synthhires:globalParams.

System prompt vs. user prompt

Una petición a un LLM suele llevar dos tipos de instrucciones:

• System prompt — las instrucciones permanentes que definen el rol y las reglas del asistente (tono, límites, qué herramientas puede usar, formato de salida). Va arriba y aplica en cada turno.
• User prompt / mensajes — la petición concreta y la conversación en curso.

La frontera es una decisión de diseño: el system prompt es donde la plataforma inyecta la identidad del agente (ver más abajo), y donde vive tu instrucción global (You are a helpful AI assistant…). Pon las reglas permanentes en el system prompt, la tarea actual en el mensaje de usuario.

En el Space: cada agente lleva un system prompt estructurado en XML (<identity><capabilities><tools><constraints>); tu instrucción global del sistema es un ajuste.

Embeddings y distancia semántica

Un embedding es un vector numérico (una lista de números) que representa el significado de un trozo de texto. El truco es geométrico: los textos con significado similar acaban en posiciones parecidas del espacio vectorial, así que puedes medir “cuánto de relacionados están dos cosas” calculando cuán de cerca están sus vectores (normalmente por similitud de coseno).

Texto	~Significado interpretado como
“gato”	cerca de “minino”, “felino”, lejos de “factura”
“política de devolución”	cerca de “política de reembolso”, lejos de “desplegar”

Los embeddings te dan búsqueda semántica: en lugar de comparar palabras clave, comparas significado. Busca “¿cómo devuelvo esta factura?” y un almacén de documentos sobre políticas de devolución aflorará aunque ninguna palabra de la consulta aparezca literal.

Por qué importa aquí: la búsqueda por subcadena falla con paráfrasis; los embeddings no se fijan en la redacción exacta, solo en tratar sobre lo mismo.

En el Space: la base de conocimiento parte cada documento en chunks, calcula un embedding por chunk y busca por el vector más cercano — ver la sección RAG más abajo y Memoria y conocimiento.

Chunking (troceado)

Chunking es partir un documento largo en piezas pequeñas y digeribles antes de embeberlo o dárselo al modelo. Como la ventana de contexto es finita y la búsqueda funciona trozo a trozo, un capítulo entero es inútil — el modelo no puede recuperar “la parte de los reembolsos” si está enterrada en diez mil tokens.

Un buen chunking respeta los límites naturales (párrafos, títulos, bloques de código) para que cada chunk sea una idea coherente, suficientemente pequeño para embeber bien y para caber en la ventana junto al resto del prompt.

En el Space: chunkDocument (src/lib/rag/vector.ts) parte las subidas en chunks que se embeden e indexan individualmente — la unidad que luego recuperas.

RAG (Generación aumentada por recuperación)

RAG es el patrón de aumentar la respuesta de un modelo con contexto recuperado que no vio en el entrenamiento. El generador no inventa los hechos de la nada — se le entrega material relevante de antemano y se le pide responder fundamentado en ello.

El flujo:

1. Ingesta — parte un documento en chunks y embebe cada uno.
2. Consulta — embebe la pregunta del usuario.
3. Recuperación — encuentra los chunks cuyos embeddings están más cerca del embedding de la pregunta.
4. Generación — pone esos chunks en el prompt como contexto de apoyo, y deja que el modelo componga la respuesta a partir de ellos.

RAG resuelve de golpe tres problemas duros: trae conocimiento actualizado/privado que el modelo nunca vio, ancla las respuestas en fuentes (reduciendo alucinaciones seguras), y mantiene la ventana asequible enviando solo los fragmentos relevantes en lugar de documentos enteros.

RAG vs. fine-tuning: el fine-tuning cambia el propio modelo; el RAG no lo toca y solo cambia el contexto que le das. El RAG es rápido de actualizar (solo añades documentos) y totalmente auditable — sabes exactamente qué chunk aterrizó una respuesta.

En el Space: la Base de conocimiento (/space/knowledge) es un almacén RAG. Ingiere subidas/URLs/YouTube, y POST /api/rag con search devuelve los chunks relevantes que puedes inyectar como “contexto de apoyo”.

Qué convierte algo en un “agente” (vs. un chatbot)

Un chatbot mantiene una conversación. Un agente es un programa en bucle que puede actuar: además de generar texto, puede llamar herramientas, observar resultados y decidir la siguiente acción, iterando hasta alcanzar una meta.

El bucle que lo define:

1. Razonar sobre la tarea con un LLM.
2. Decidir qué hacer — responder, o llamar a una herramienta.
3. Actuar llamando a una función externa (leer un archivo, ejecutar código, consultar GitHub, enviar un mensaje).
4. Observar el resultado de la herramienta, devolverlo al contexto.
5. Repetir hasta terminar, y entonces responder.

Las herramientas convierten un generador de texto en un actor: sin llamadas a herramientas el modelo solo puede describir acciones; con ellas puede realizarlas. Por eso los agentes necesitan capacidades con alcance, puertas de consentimiento y registros de auditoría (ver Runtimes y bridge).

Más allá de un bucle único, un sistema puede usar orquestación multi-agente: un agente líder planifica y delega subtareas a agentes especializados, que a su vez pueden crear trabajadores — un árbol de agentes que cooperan.

En el Space: el chat usa un Lead Orchestrator que delega en el catálogo de 16 agentes; el panel de jerarquía te deja crear ejecutores/verificadores; el pipeline studio ejecuta grafos enteros de estos agentes.

Llamadas a funciones / herramientas

La llamada a herramientas (tool/function calling) es el mecanismo formal detrás de “un agente puede actuar”. Se le dice al modelo el esquema de las herramientas disponibles (nombre, parámetros, descripción) pero no puede ejecutarlas — solo puede emitir la petición de llamar a una, con argumentos. La aplicación ejecuta la función real, obtiene el resultado y lo devuelve al modelo como un mensaje de herramienta, para que continúe.

Ejemplo con GitHub:

1. El LLM anuncia call get_issue({"number": 42}).
2. Tu código llama a la API de GitHub y obtiene el cuerpo del issue.
3. Ese cuerpo se añade a la conversación; el modelo razona sobre él y responde.

Las llamadas a herramientas son cómo la plataforma tiende un puente entre el modelo y tu código, filesystem, red, bases de datos y mensajería — cada una limitada por una capacidad y sujeta a consentimiento.

En el Space: los agentes declaran herramientas recomendadas; los servidores MCP las aportan mediante un protocolo estándar; el bridge expone capacidades desktop.*/mobile.*/sync.* como acciones invocables.

MCP (Model Context Protocol)

MCP — el Model Context Protocol — es un estándar abierto que da a los modelos herramientas y recursos de servidores externos a través de una interfaz común. Piensa en él como “el USB-C de las herramientas de modelo”: en lugar de que cada integración requiera código a medida, cualquier servidor MCP (GitHub, Notion, Slack, una API interna de empresa) expone sus capacidades de forma uniforme, y el modelo las llama a través de MCP.

• Herramientas: acciones que expone un servidor (p. ej. create_issue, search_issues).
• Recursos: datos que el modelo puede leer (p. ej. archivos, esquemas).
• Prompts: plantillas de prompting reutilizables del servidor.

En runtimes de borde (como Workers) no hay proceso que lanzar, así que MCP corre sobre Streamable HTTP en lugar de lanzar un proceso stdio local.

En el Space: la pestaña Servidores MCP gestiona un registro de conectores (GitHub, GitLab, Jira, Asana, Linear, Notion, Slack, Discord…), cada uno con su paquete de servidor y modo de configuración.

Streaming

Streaming es enviar la respuesta del modelo al cliente mientras se genera, token a token, en lugar de esperar a la salida completa. Es una victoria de latencia percibida: las primeras palabras aparecen en milisegundos aunque la respuesta completa tarde segundos, y convierte una espera larga en una experiencia de “escribiendo”.

Arquitectónicamente significa que la respuesta es un stream (SSE o troceado), no un string amortiguado — el servidor vacía completados parciales continuamente y el cliente los renderiza de forma incremental.

En el Space: el chat transmite por defecto vía streamText; la ruta nunca amortigua la respuesta completa. El streaming es un requisito de producto deliberado.

Modelos de razonamiento y tokens de “pensamiento”

Los modelos de razonamiento (p. ej. GPT-5/“thought”, Claude reasoning, Gemini think, DeepSeek reasoner) gastan tokens extra en una cadena de pensamiento interna explícita antes de producir la respuesta final. En lugar de responder a la primera, redactan pasos de razonamiento, se autocorrigen y luego responden — lo que mejora el rendimiento en tareas complejas/matemáticas/depuración a costa de más latencia y más tokens (de razonamiento).

La plataforma expone un nivel de pensamiento (off / low / medium / high) que mapea al control de reasoning-effort del propio proveedor. Los proveedores difieren en si el razonamiento es opcional o siempre activo, así que el cliente deriva la capacidad y envía el parámetro correcto por proveedor.

En el Space: cada conversación guarda un nivel de pensamiento; src/lib/thinking.ts calcula el parámetro de control de razonamiento correcto para OpenAI, Anthropic, Gemini y DeepSeek.

Salida estructurada y “extracción de plan”

Los LLMs producen texto libre, pero las aplicaciones a menudo necesitan datos estructurados (un plan con pasos, un JSON, un objeto). La salida estructurada constriñe al modelo a devolver algo que encaja con un esquema — normalmente aportando un JSON schema y/o parseando y validando.

Dos técnicas complementarias que se usan juntas:

1. Salida guiada por esquema — pedir/entrenar al modelo para que devuelva JSON que encaje con un esquema definido (Output.object({ schema })).
2. Parseo tolerante — por separado, escanear lo que haya vuelto en busca de un bloque tipo JSON y validarlo estrictamente, para que la salida sobreviva incluso cuando el modelo la envuelva en prosa u olvide los fences de código.

En el Space: el plan del orquestador se extrae de la respuesta del asistente mediante un escáner JSON tolerante + validación Zod estricta (safeParsePlan), y luego se abre como grafo en el Pipeline studio.

Fine-tuning vs. prompts, brevemente

El fine-tuning actualiza los pesos del modelo con un dataset; el prompting aprende en contexto a partir de lo que escribes. Un modelo base suele ser bastante potente para casi todas las tareas; el fine-tuning se reserva para especializar un modelo en un dominio, formato o tono. El RAG y el prompting son más baratos, reversibles y auditables (siempre sabes qué contexto se metió) — por eso el Space se apoya en ellos y en el BYOK en lugar de alojar o afinar modelos.

El hilo que lo une todo

Ese es el modelo mental: un muestreador token a token sobre una ventana de contexto finita, dirigido por prompts y perillas de sampling, anclado por recuperación (RAG) cuando hacen falta hechos, extendido con herramientas/MCP para actuar, compuesto en bucles de agentes y pipelines, y entregado en streaming a tu pantalla. Con este vocabulario, el resto de la documentación describe cómo el Space conecta esas ideas con sus páginas, APIs y almacenamiento.

Siguiente: Visión general para el mapa de producto, o Arquitectura para la ruta de petición.