De cero a un modelo de IA propio

1. La idea central: ¿qué estamos construyendo realmente?

Imagina una empresa ficticia llamada CMBR. CMBR construye software sobre Cloudflare: Workers, D1, R2, KV, Queues, Durable Objects. Tiene sus propias convenciones de código, su propia arquitectura interna, su documentación, sus decisiones de diseño acumuladas durante años y su propio historial de errores y soluciones.

Un desarrollador nuevo en CMBR tarda semanas en entender por qué las cosas se hacen de cierta manera. La pregunta que dispara este artículo es:

¿Podemos construir un sistema de IA que conozca CMBR tan bien como un ingeniero senior de la empresa, que pueda responder preguntas, generar código en el estilo correcto, consultar documentación actualizada y, eventualmente, ejecutar tareas usando herramientas?

Ese sistema es lo que llamaremos CMBR AI, y su componente de modelo (si es que llega a tenerlo) se llamaría conceptualmente CMBR-1G.

Es fundamental aclarar desde la primera línea:

CMBR AI no es un chatbot que “sabe de Cloudflare”. Es, en el mejor de los casos, algo más parecido a un AI Engineer / AI Agent especializado: un sistema que combina un modelo de lenguaje, una base de conocimiento actualizable, y la capacidad de usar herramientas para actuar sobre sistemas reales (repositorios, APIs, bases de datos).

Y aquí está la idea que sostiene todo el artículo:

Un modelo de IA propio es, como mucho, una pieza de este sistema. Nunca es el sistema completo.

Antes de seguir, una advertencia honesta que vas a leer repetida varias veces en distintas formas: la mayoría de las empresas nunca necesitan entrenar un modelo desde cero, y muchas ni siquiera necesitan hacer fine-tuning. Este artículo te lleva a través de todo el camino, pero el objetivo es que aprendas a decidir cuándo detenerte, no a llegar automáticamente al final.

2. Los cinco conceptos que la gente mezcla

Este es probablemente el bloque más importante del artículo. Casi todos los malentendidos sobre “entrenar mi propia IA” vienen de mezclar estos conceptos, que son completamente distintos entre sí.

La idea clave que debes internalizar:

• RAG cambia lo que el modelo sabe en el momento de responder, sin tocar sus pesos.
• Fine-tuning cambia cómo se comporta el modelo, de forma permanente, modificando (parte de) sus pesos.
• Distillation no es una técnica alternativa a fine-tuning: es una forma de generar el dataset (o de guiar el entrenamiento) usando un modelo grande como fuente de verdad para entrenar uno más pequeño. Frecuentemente se combina con fine-tuning.
• Training from scratch es construir el modelo entero, sin punto de partida. Esto es lo que hacen laboratorios como los que entrenan Llama, Qwen o GPT: requiere datasets del orden de billones de tokens y clústeres de miles de GPUs.
• Quantization no cambia el comportamiento del modelo (en teoría); solo lo hace más barato de ejecutar, con una pequeña pérdida de precisión.
• Un agente no es un tipo de modelo. Es una arquitectura: un modelo + un bucle de razonamiento + herramientas que puede invocar.

Una empresa real como CMBR normalmente combina varias de estas técnicas, nunca usa solo una. Por ejemplo: un modelo base + RAG sobre la documentación + un adapter LoRA con el estilo de código de la empresa + un conjunto de herramientas que lo convierten en agente.

3. Arquitectura conceptual de CMBR AI

                         ┌─────────────────────────┐
                         │      CMBR-1G Model       │
                         │                          │
                         │  comportamiento          │
                         │  razonamiento            │
                         │  patrones de estilo      │
                         │  conocimiento aprendido  │
                         │  (lo que NO cambia       │
                         │   constantemente)        │
                         └────────────┬─────────────┘
                                      │
                                      ▼
                              ┌───────────────┐
                              │      RAG      │
                              │               │
                              │ Documentación │
                              │ GitHub        │
                              │ Código        │
                              │ Arquitectura  │
                              │ Manuales      │
                              │ (lo que SÍ    │
                              │  cambia)      │
                              └───────┬───────┘
                                      │
                                      ▼
                         ┌─────────────────────────┐
                         │       Tools / APIs      │
                         │                         │
                         │ GitHub                  │
                         │ Cloudflare API          │
                         │ Workers                 │
                         │ D1 / R2 / KV            │
                         │ Workers AI              │
                         │ CI/CD                   │
                         │ (lo que EJECUTA acciones)│
                         └─────────────────────────┘

Tres frases resumen esta arquitectura, y vale la pena memorizarlas:

1. El modelo aprende comportamientos cómo razona, qué estilo de código prefiere, cómo estructura una respuesta técnica. Esto es relativamente estable en el tiempo.
2. RAG proporciona conocimiento que puede cambiar la URL de un bucket R2, el nombre de un endpoint, una decisión arquitectónica tomada la semana pasada. Esto cambia constantemente y nunca debería vivir “dentro” de los pesos del modelo.
3. Las herramientas permiten actuar sobre sistemas externos crear un PR, consultar el estado de un Worker, leer una tabla de D1. Sin herramientas, el sistema solo puede hablar, no hacer.

Un error extremadamente común de principiante es intentar resolver el problema 2 (conocimiento que cambia) con la herramienta equivocada (fine-tuning), cuando la herramienta correcta es RAG.

4. Fundamentos: qué es un modelo de lenguaje, en serio

Vamos a construir la intuición desde el suelo, sin matemáticas todavía.

4.1 Token

Un modelo de lenguaje no “lee” palabras como nosotros. Divide el texto en tokens: fragmentos de texto (a veces palabras completas, a veces partes de palabras). Por ejemplo, "Hola mundo" podría tokenizarse aproximadamente como:

["Hola", " mundo"]   → 2 tokens (simplificado)

Pero una palabra poco común, como "tokenización", podría partirse en varios tokens:

["token", "izaci", "ón"]  → 3 tokens (ejemplo ilustrativo)

El componente que hace esta división se llama tokenizer. Cada modelo tiene su propio tokenizer, entrenado para dividir el texto de forma eficiente en el idioma y dominio en que fue entrenado.

4.2 De token a número: embeddings

Los modelos no trabajan con texto, trabajan con números. Cada token se convierte en un vector: una lista larga de números decimales (por ejemplo, 4096 números). A esta representación numérica se le llama embedding.

La propiedad mágica de un buen embedding: tokens con significados parecidos terminan con vectores parecidos. El vector de “rey” está matemáticamente cerca del vector de “reina” menos “hombre” más “mujer” (el ejemplo clásico, simplificado). Esta propiedad es la base tanto de los LLMs como de RAG (lo veremos en la sección 7).

4.3 Parámetros

Un modelo de lenguaje es, en esencia, una función matemática gigantesca con millones o miles de millones de parámetros ajustables (también llamados “pesos”). Cuando ves nombres como:

• 1B → mil millones (1,000,000,000) de parámetros
• 7B → siete mil millones
• 14B, 70B, etc.

te están diciendo cuántos números ajustables tiene ese modelo. Más parámetros generalmente significa más capacidad de representar patrones complejos, pero también más memoria (VRAM) necesaria y más lento/caro de ejecutar. Más parámetros no es automáticamente “mejor” para una tarea concreta volveremos a esto en la sección de errores comunes.

4.4 Entrenar vs. inferir

• Entrenamiento (training): el proceso de ajustar los parámetros del modelo mostrándole ejemplos, comparando su predicción con la respuesta correcta, y corrigiendo los pesos poco a poco (mediante un algoritmo llamado descenso de gradiente, que no cubriremos matemáticamente aquí).
• Inferencia (inference): usar un modelo ya entrenado para generar una respuesta a partir de un input nuevo. Es lo que ocurre cada vez que le mandas un prompt a ChatGPT, Claude, o a un modelo corriendo en Workers AI.

Entrenar es caro y lento. Inferir es (relativamente) barato y rápido. El 95% de lo que hace una empresa con IA es inferencia, no entrenamiento.

4.5 Checkpoint

Durante el entrenamiento, el estado de los pesos se guarda periódicamente en un checkpoint: una “foto” del modelo en ese momento. Puedes retomar el entrenamiento desde un checkpoint, comparar checkpoints entre sí, o simplemente usar el checkpoint final como tu modelo de producción.

4.6 Ventana de contexto (context window)

Un modelo no puede “leer” una cantidad infinita de texto de una vez. La ventana de contexto es el número máximo de tokens (entrada + salida) que el modelo puede procesar en una sola llamada. Si tu ventana de contexto es de 8,000 tokens y le mandas un documento de 20,000 tokens, simplemente no cabe de ahí la necesidad de técnicas como RAG (que selecciona solo los fragmentos relevantes en lugar de mandarlo todo).

4.7 Resumen visual

"Hola mundo"
     │
     ▼  tokenizer
["Hola", " mundo"]
     │
     ▼  embedding
[[0.12, -0.5, ...], [0.03, 0.88, ...]]   (vectores numéricos)
     │
     ▼  el modelo (millones/miles de millones de parámetros)
     │  procesa estos vectores capa por capa
     ▼
[[0.44, -0.1, ...]]  → siguiente token más probable
     │
     ▼  detokenizer
" ¿Cómo puedo ayudarte?"

5. Usar un modelo existente antes de pensar en entrenar nada

Un principiante no debería empezar entrenando un LLM desde cero. Ni siquiera debería empezar haciendo fine-tuning. El primer paso, siempre, es aprender a usar un modelo ya entrenado por otra organización.

Aplicación
   ↓
API
   ↓
LLM (ya entrenado por alguien más)
   ↓
Respuesta

En el contexto de CMBR, sobre Cloudflare, esto se vería así:

Aplicación (frontend / CLI / Slack bot)
   ↓
Cloudflare Worker
   ↓
Workers AI (o un proveedor externo vía AI Gateway)
   ↓
LLM

Un ejemplo mínimo con Workers AI, usando el binding AI desde un Worker:

export interface Env {
  AI: Ai;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const response = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
      messages: [
        { role: "system", content: "Eres un asistente técnico de CMBR." },
        { role: "user", content: "¿Qué es un Durable Object?" },
      ],
    });

    return new Response(JSON.stringify(response), {
      headers: { "content-type": "application/json" },
    });
  },
};

Esto ya es, técnicamente, “un sistema de IA de CMBR”. Es primitivo, pero funciona, cuesta poco, y es exactamente el punto de partida correcto. Todo lo que viene después son mejoras incrementales sobre esta base.

6. Prompting: la primera y más barata palanca

Antes de tocar RAG o fine-tuning, exprime el prompting. Es gratis (no cuesta entrenamiento) y es sorprendentemente poderoso.

Conceptos clave:

• System prompt: instrucciones que definen el rol, tono y límites del modelo, normalmente invisibles para el usuario final.
• User prompt: lo que pregunta o pide el usuario.
• Contexto: información adicional que le das al modelo dentro del prompt (código, documentos, historial).
• Few-shot prompting: mostrar ejemplos de “input → output deseado” dentro del propio prompt, para que el modelo imite el patrón sin necesidad de entrenamiento.
• Structured output: pedirle al modelo que responda en un formato específico (JSON, YAML) para que tu aplicación lo pueda procesar de forma fiable.
• Function / tool calling: el modelo no responde directamente, sino que “decide” qué función/herramienta llamar y con qué argumentos; tu código ejecuta esa función y le devuelve el resultado al modelo.

Ejemplo: de un prompt pobre a uno estructurado

Prompt pobre:

Arregla este código

Prompt estructurado:

Eres un revisor de código senior de CMBR. Sigues estas convenciones:
- TypeScript estricto, sin `any`.
- Manejo de errores explícito, nunca silencioso.
- Los Workers de CMBR usan bindings tipados (ver ejemplo abajo).

Tarea: revisa el siguiente código de un Cloudflare Worker y corrige
cualquier problema de tipado o manejo de errores. Devuelve:
1. El código corregido.
2. Una lista con viñetas de los cambios realizados y por qué.

Código:
\`\`\`ts
<código aquí>
\`\`\`

Es importante insistir: mejorar el prompt no entrena el modelo. Cada vez que empiezas una conversación nueva, partes de cero otra vez. El prompt solo afecta a esa llamada concreta.

7. RAG: dale al modelo una biblioteca que se pueda actualizar

7.1 El problema que resuelve

Imagina que CMBR migra de un bucket R2 antiguo a uno nuevo:

R2 bucket viejo (cmbr-assets-v1)
       ↓
R2 bucket nuevo (cmbr-assets-v2)

Si el “conocimiento” de ese nombre de bucket estuviera dentro de los pesos del modelo (por fine-tuning), tendrías que volver a entrenar cada vez que algo así cambia. Eso es lento, caro, y en la práctica insostenible: las empresas cambian nombres de recursos, endpoints y decisiones constantemente.

La solución es RAG (Retrieval-Augmented Generation): en lugar de “memorizar” el dato dentro del modelo, se lo entregamos como contexto en el momento de la consulta, buscándolo en una base de conocimiento externa que se puede actualizar sin re-entrenar nada.

7.2 El pipeline de RAG

Documentos (docs, código, PRs, wikis)
    ↓
Chunking      (partir en fragmentos manejables)
    ↓
Embeddings    (convertir cada fragmento en un vector)
    ↓
Vector database (guardar esos vectores + metadata)
    ↓
Retrieval     (buscar los fragmentos más similares a la pregunta)
    ↓
Contexto      (insertar esos fragmentos en el prompt)
    ↓
LLM
    ↓
Respuesta

Vamos paso a paso.

Chunking. No metes un documento entero de 50 páginas en la base vectorial como una sola unidad; lo partes en fragmentos (“chunks”) de, por ejemplo, 300–800 tokens, a veces con solapamiento entre fragmentos consecutivos para no cortar ideas a la mitad. El tamaño correcto de chunk depende del tipo de contenido: un chunk de documentación conceptual puede ser más largo que un chunk de código.

Embeddings. Cada chunk se pasa por un modelo de embeddings (distinto del LLM generativo) que lo convierte en un vector numérico que representa su significado.

Vector database. Los vectores (junto con metadata como “archivo de origen”, “fecha”, “versión”) se guardan en una base de datos especializada en búsquedas de similitud, optimizada para encontrar rápidamente “los N vectores más cercanos a este vector de consulta” incluso entre millones de vectores.

Retrieval. Cuando llega una pregunta del usuario (“¿cómo configuro el binding de R2 en wrangler.toml?”), esa pregunta también se convierte en un vector, y se buscan en la base vectorial los chunks cuyo vector esté más cerca (similarity search).

Reranking (opcional pero recomendable en producción). El resultado inicial de similarity search no siempre ordena los fragmentos por relevancia real; un paso de reranking usa un modelo más preciso (aunque más lento) para reordenar los mejores N candidatos antes de insertarlos en el prompt.

Contexto → LLM. Los fragmentos recuperados se insertan en el prompt junto con la pregunta original, y el LLM genera la respuesta usando ese contexto.

7.3 Ejemplo práctico con documentación ficticia de CMBR

Supongamos este fragmento de documentación interna de CMBR:

## Configuración de R2 en CMBR

Desde la migración de marzo de 2026, todos los Workers de CMBR deben usar
el bucket `cmbr-assets-v2`. El binding en wrangler.toml debe llamarse
`ASSETS_BUCKET`, no `BUCKET` (nombre legado, deprecado).

Este texto se convierte en un chunk, se genera su embedding, y se guarda en la base vectorial junto con metadata (source: "r2-config.md", last_updated: "2026-03-15").

Cuando un desarrollador pregunta: “¿cómo llamo al binding de R2 en mi wrangler.toml?”, el sistema:

1. genera el embedding de la pregunta;
2. busca los chunks más cercanos → encuentra el fragmento de arriba;
3. lo inserta como contexto en el prompt;
4. el LLM responde: “El binding debe llamarse ASSETS_BUCKET, apuntando al bucket cmbr-assets-v2 (el nombre BUCKET está deprecado desde la migración de marzo de 2026).”

Sin RAG, el modelo simplemente no tendría forma de saber esto es información interna, específica y reciente.

7.4 Por qué RAG es especialmente útil para documentación empresarial

• Actualizable sin re-entrenar: cambia el documento, vuelve a indexarlo, listo.
• Trazable: puedes mostrar de qué documento salió la respuesta (citas), lo cual es clave para confianza y auditoría.
• Reduce alucinaciones (aunque no las elimina): el modelo tiene “algo a lo que agarrarse” en lugar de inventar.
• Barato de mantener comparado con re-entrenar un modelo cada vez que cambia un dato.

7.5 Limitaciones honestas de RAG

• Si la búsqueda recupera el fragmento equivocado, el modelo puede responder mal con total confianza (esto se llama a veces “RAG mal implementado”, no un problema del concepto en sí).
• No enseña comportamiento ni estilo solo aporta hechos. Si quieres que el modelo siempre responda en cierto formato de commit message, RAG no es la herramienta (eso es fine-tuning o, más barato, prompting con ejemplos).
• Documentos contradictorios o desactualizados en la base vectorial pueden confundir al modelo de ahí la importancia de mantener limpio el corpus (ver sección 8).

Cloudflare Vectorize es, en el ecosistema de Cloudflare, la pieza pensada exactamente para este rol: es una base de datos vectorial gestionada, distribuida globalmente, que se integra de forma nativa con Workers y Workers AI para construir aplicaciones RAG sin gestionar infraestructura de búsqueda vectorial por tu cuenta.

8. Construir el dataset de CMBR

Antes de hablar de fine-tuning o distillation, necesitas un dataset. Esta sección aplica tanto si el dataset alimenta RAG como si alimenta fine-tuning (aunque el formato es distinto en cada caso).

8.1 Fuentes posibles

CMBR podría recopilar:

• documentación técnica interna;
• código fuente y su historial;
• Pull Requests (con sus descripciones y comentarios de revisión);
• issues cerrados con su resolución;
• documentos de decisiones arquitectónicas (ADRs);
• postmortems de incidentes;
• preguntas frecuentes internas;
• conversaciones técnicas relevantes (Slack, tickets);
• ejemplos curados de “buen prompt → buena respuesta”.

8.2 La advertencia más importante de esta sección

No todo texto debe convertirse automáticamente en datos de entrenamiento.

Esto aplica doblemente a fine-tuning (donde el dato queda “incrustado” en los pesos del modelo, difícil de revertir) y en menor medida a RAG (donde al menos puedes borrar o actualizar el documento).

8.3 Limpieza necesaria

• Deduplicación: contenido repetido sesga el entrenamiento hacia esos patrones y desperdicia cómputo.
• Anonimización: nombres de clientes, datos personales, información identificable que no debería estar en un dataset de entrenamiento.
• Eliminación de secretos: API keys, passwords, tokens de acceso, connection strings. Esto es crítico hay casos documentados públicamente de modelos que memorizaron y luego regurgitaron credenciales presentes en sus datos de entrenamiento.
• Datos obsoletos: documentación de una versión anterior de la arquitectura que ya no aplica.
• Información contradictoria: dos documentos que dicen cosas distintas sobre el mismo tema confunden al modelo (y a los humanos, para el caso).

8.4 Formato de un ejemplo de dataset de fine-tuning

{
  "instruction": "¿Cómo debería implementar autenticación en un nuevo Worker de CMBR?",
  "context": "El Worker expone una API interna consumida por otros servicios de CMBR.",
  "response": "Usa el middleware de autenticación estándar de CMBR (@cmbr/auth-worker), que valida el JWT contra el servicio de identidad interno antes de procesar la petición.",
  "reasoning": "CMBR centraliza la autenticación de servicio a servicio para evitar que cada equipo reimplemente validación de tokens de forma inconsistente.",
  "code": "import { requireAuth } from '@cmbr/auth-worker';\n\nexport default {\n  async fetch(request, env) {\n    const auth = await requireAuth(request, env);\n    if (!auth.ok) return auth.response;\n    // lógica del worker\n  }\n};"
}

8.5 Calidad sobre cantidad

Un dataset de 2,000 ejemplos limpios, revisados por humanos, y representativos de casos reales, casi siempre produce mejores resultados de fine-tuning que uno de 500,000 ejemplos generados automáticamente sin revisión. Esta idea que la curación importa más que el volumen bruto es consistente con lo que reportan trabajos como LIMA: Less Is More for Alignment (Zhou et al., 2023), que muestra ganancias sustanciales de alineación con relativamente pocos ejemplos, siempre que estén cuidadosamente seleccionados.

9. Fine-tuning: cuándo el modelo necesita aprender comportamiento

9.1 Qué es, en términos simples

Fine-tuning parte de un modelo ya entrenado (por ejemplo Llama, Qwen o Mistral) y continúa entrenándolo con un dataset más pequeño y específico, ajustando sus pesos para que se comporte de forma distinta.

Qwen / Llama / Mistral (modelo base)
           ↓
       Dataset CMBR
           ↓
      Fine-tuning
           ↓
     Modelo adaptado

Según la documentación oficial de Cloudflare Workers AI: “Fine-tuning is a general term for modifying an AI model by continuing to train it with additional data. The goal of fine-tuning is to increase the probability that a generation is similar to your dataset.”

9.2 Qué aprende y qué NO aprende

Sí aprende:

• estilo de respuesta (formal, conciso, con ejemplos de código);
• formato consistente (siempre responder con JSON, siempre incluir tests);
• patrones de razonamiento repetitivos del dominio;
• terminología y jerga interna.

No aprende bien (o no debería usarse para esto):

• hechos que cambian con frecuencia (para eso está RAG);
• información que necesita trazabilidad/auditoría de fuente;
• conocimiento que solo aparece una vez en el dataset (el fine-tuning generaliza patrones, no memoriza hechos aislados de forma confiable).

9.3 Cuándo usarlo y cuándo no

Tiene sentido cuando:

• ya intentaste prompting y RAG y el modelo sigue sin adoptar el estilo/formato deseado de forma consistente;
• necesitas que el modelo siga un comportamiento específico en todas las conversaciones, no solo cuando se lo recuerdas en el prompt;
• quieres reducir el tamaño del prompt (menos few-shot examples porque el comportamiento ya está “aprendido”).

No tiene sentido cuando:

• el problema es que el modelo no sabe un hecho concreto → usa RAG;
• el problema es de instrucciones poco claras → mejora el prompt primero, es gratis;
• no tienes al menos unos cientos de ejemplos de calidad razonable;
• el conocimiento cambia semanalmente (fine-tuning “congela” el comportamiento hasta el próximo entrenamiento).

9.4 Vocabulario técnico necesario

• Entrenamiento completo (full fine-tuning): se actualizan todos los parámetros del modelo. Requiere mucha VRAM (memoria de GPU) porque hay que guardar gradientes y estados del optimizador para cada parámetro.
• PEFT (Parameter-Efficient Fine-Tuning): familia de técnicas que actualizan solo una fracción pequeña de los parámetros (o parámetros adicionales) en lugar de todo el modelo. LoRA es la más popular (sección 10).
• Adapters: módulos pequeños añadidos al modelo, entrenados en lugar del modelo completo.
• GPU / VRAM: el entrenamiento requiere GPUs con suficiente memoria de vídeo para cargar el modelo, los gradientes y los datos de un lote (batch) simultáneamente.
• Epochs: cuántas veces el modelo ve el dataset completo durante el entrenamiento. Demasiadas epochs sobre un dataset pequeño llevan a overfitting.
• Learning rate: qué tan grandes son los ajustes que se hacen a los pesos en cada paso. Muy alto = entrenamiento inestable; muy bajo = entrenamiento lentísimo.
• Batch size: cuántos ejemplos se procesan juntos antes de actualizar los pesos.
• Overfitting: el modelo “memoriza” el dataset de entrenamiento en lugar de generalizar, y funciona mal con ejemplos nuevos que no vio durante el entrenamiento.

10. LoRA: fine-tuning sin romper el banco

10.1 La idea intuitiva

Un modelo grande tiene matrices de pesos enormes. Modificar todas esas matrices durante el fine-tuning es caro: hay que guardar gradientes para cada uno de esos miles de millones de números.

LoRA (Low-Rank Adaptation), propuesta en el paper “LoRA: Low-Rank Adaptation of Large Language Models” (Hu et al., 2021), propone algo distinto: en lugar de modificar la matriz de pesos original, se congela (no se toca) y se entrena una pareja de matrices mucho más pequeñas (“de bajo rango”) que, combinadas, aproximan el cambio que hubiera producido el fine-tuning completo.

Modelo completo (fine-tuning tradicional)
████████████████████████████████   ← se actualizan TODOS estos pesos

LoRA
████████████████████████████████   ← pesos originales, CONGELADOS
                    + ██           ← pequeño adapter, esto SÍ se entrena

10.2 Ventajas

• Menor coste computacional: se entrenan órdenes de magnitud menos parámetros.
• Menor memoria: cabe en GPUs mucho más modestas que el fine-tuning completo.
• Portabilidad: el adapter resultante es un archivo pequeño (en el caso de Workers AI, menor a 300 MB), separable del modelo base.
• Múltiples adapters: puedes tener un adapter para “estilo de commits de CMBR”, otro para “generación de tests”, otro para “tono de soporte al cliente” todos sobre el mismo modelo base, intercambiándolos según la tarea.
• Especialización por dominio sin necesitar una copia completa del modelo por cada especialización.

10.3 LoRA en Cloudflare Workers AI (verificado en documentación oficial)

Según la documentación oficial de Cloudflare (developers.cloudflare.com/workers-ai/features/fine-tunes/loras/), Workers AI soporta inferencia con adapters LoRA entrenados con Low-Rank Adaptation, en beta abierta. Puntos importantes, tal como los documenta Cloudflare:

• El adapter debe estar entrenado con rank r <= 32 (dependiendo de las limitaciones vigentes en el momento; Cloudflare ha ido incrementando este límite con el tiempo, así que conviene revisar la página oficial antes de entrenar).
• El archivo del adapter debe pesar menos de 300 MB.
• Los archivos deben llamarse exactamente adapter_config.json y adapter_model.safetensors.
• Se pueden probar hasta 100 adapters LoRA por cuenta.
• Los modelos base compatibles son un conjunto específico y limitado (por ejemplo variantes de Llama, Mistral y Gemma con sufijo -lora); no cualquier modelo base sirve.

Un punto crítico que hay que entender bien: Workers AI no entrena el LoRA por ti (al menos no en el momento de escribir esto). El flujo es “Bring Your Own LoRA” (BYO LoRA): tú entrenas el adapter en otro lugar (por ejemplo con Hugging Face AutoTrain, o con tu propio script usando PEFT sobre una GPU alquilada), y luego subes ese adapter entrenado a Workers AI, que se encarga de aplicarlo en tiempo de inferencia sobre el modelo base.

// Ejemplo conceptual de inferencia con un LoRA subido a Workers AI
const response = await env.AI.run(
  "@cf/mistral/mistral-7b-instruct-v0.2-lora",
  {
    messages: [{ role: "user", content: "Genera un commit message para este diff" }],
    lora: "cmbr-commit-style-v1",
  }
);

Recomendación arquitectónica (no un hecho de Cloudflare): para CMBR, este flujo BYO LoRA encaja bien porque separa claramente “dónde se entrena” (una GPU alquilada puntualmente, o un notebook de Hugging Face) de “dónde se sirve” (Workers AI, en el borde, cerca del usuario). No hace falta mantener infraestructura de inferencia propia.

11. Teacher / Student

        TEACHER
     modelo grande
     (más capaz, más caro de ejecutar)
          │
          ▼
   genera ejemplos de alta calidad
          │
          ▼
      dataset sintético
          │
          ▼
       STUDENT
    modelo pequeño
    (más barato, más rápido)

La idea: en lugar de que humanos escriban a mano miles de ejemplos de entrenamiento, se usa un modelo grande y capaz (el “teacher”) para generar respuestas de alta calidad sobre el dominio de interés, y esas respuestas se usan como dataset para entrenar un modelo más pequeño (el “student”).

Para CMBR, esto podría verse así:

• Teacher: un modelo grande y capaz (por ejemplo, accedido vía API) al que se le piden explicaciones detalladas, revisiones de código y soluciones a problemas típicos de la arquitectura de CMBR, con su documentación como contexto (vía RAG).
• Student: un modelo pequeño (rango 1B–7B) que se entrena sobre esos ejemplos generados por el teacher, con el objetivo de que aprenda a responder de forma similar, pero siendo mucho más barato de ejecutar en producción.

Es importante ser honesto: el student nunca será mejor que el teacher en el caso general. La apuesta es que, dentro de un dominio acotado (la arquitectura y procesos de CMBR), el student pueda acercarse mucho a la calidad del teacher a una fracción del coste de inferencia porque no necesita ser bueno en todo, solo en esto.

12. Distillation en profundidad

12.1 Versión para principiantes

Knowledge distillation no es simplemente “copiar conocimiento”. Es un proceso donde un modelo pequeño (student) se entrena para imitar el comportamiento de un modelo grande (teacher), en lugar de (o además de) entrenarse solo con las respuestas “correctas” originales.

Teacher (grande, capaz, caro)
     ↓
genera 100,000 ejemplos sobre el dominio de CMBR
     ↓
Student (pequeño, 7B)
     ↓
CMBR-7B (más barato, se especializa en el dominio de CMBR)

12.2 Versión técnica

El paper original de distillation, “Distilling the Knowledge in a Neural Network” (Hinton, Vinyals & Dean, 2015), introduce la distinción central:

• Hard targets: la respuesta “correcta” única (por ejemplo, la etiqueta de clasificación, o el texto exacto de la respuesta esperada).
• Soft targets / logits: la distribución de probabilidad completa que el teacher asigna a todas las posibles siguientes palabras/tokens, no solo a la más probable. Esta distribución contiene información extra (“el teacher no solo eligió esta palabra, sino que consideró estas otras tres casi igual de probables”) que el hard target por sí solo no captura, y que ayuda al student a aprender una representación más matizada.

En la práctica moderna con LLMs, hay dos enfoques principales usados en la industria:

• Response distillation: se generan respuestas completas del teacher a un conjunto de prompts, y esas respuestas (texto) se usan como dataset de fine-tuning normal para el student. Es el enfoque más simple y el más accesible para un equipo sin infraestructura de entrenamiento avanzada es, en esencia, lo descrito en la sección 11 (Teacher/Student).
• Dataset distillation / distillation durante entrenamiento: se usa directamente la distribución de probabilidades (logits) del teacher como señal de entrenamiento del student, no solo el texto final. Esto requiere acceso a los logits del teacher (no siempre disponible si el teacher es un modelo cerrado detrás de una API) y una infraestructura de entrenamiento más sofisticada.

Un ejemplo histórico influyente de este enfoque es DistilBERT (Sanh et al., 2019), que logró retener aproximadamente el 97% de las capacidades de BERT usando un 40% menos de parámetros y siendo un 60% más rápido, combinando distillation con un objetivo de entrenamiento adicional.

12.3 Ventajas y limitaciones

Ventajas:

• Modelos mucho más baratos de ejecutar en producción (menos parámetros = menos cómputo por respuesta).
• Menor latencia, relevante para aplicaciones interactivas.
• Se puede especializar deliberadamente en un dominio acotado (la arquitectura de CMBR), aceptando perder capacidad general a cambio.

Limitaciones:

• El student hereda los errores y sesgos del teacher, sin corrección automática.
• Si el dominio no está bien acotado, el student puede terminar siendo peor que simplemente usar un modelo genérico pequeño sin distillation.
• Requiere generar (y revisar) un volumen considerable de ejemplos del teacher, lo cual tiene coste (en dinero si el teacher es una API de pago, en tiempo de revisión humana si quieres calidad).

13. Por qué (casi) nunca conviene entrenar desde cero

Datos (billones de tokens)
 ↓
Pretraining (miles de GPUs, semanas/meses)
 ↓
Modelo desde cero

Entrenar un modelo desde cero (pretraining) significa inicializar los pesos de forma aleatoria y entrenar sobre un corpus masivo (típicamente billones de tokens) hasta que el modelo aprende gramática, hechos generales, y capacidad de razonamiento desde el suelo. Esto es lo que hacen organizaciones como las que entrenan Llama, Qwen, Mistral o GPT.

Para una empresa como CMBR, esto casi nunca tiene sentido, por razones muy concretas:

• Cantidad de datos: los modelos base modernos se entrenan con corpus del orden de billones de tokens (texto, código, la web entera filtrada). CMBR, como cualquier empresa individual, no tiene ni remotamente esa cantidad de datos propios.
• GPU: se requieren clústeres de cientos o miles de GPUs de gama alta, corriendo durante semanas o meses.
• Tiempo: incluso con presupuesto ilimitado, entrenar y depurar un modelo desde cero toma meses.
• Infraestructura: orquestación distribuida, checkpointing, tolerancia a fallos a esa escala es un problema de ingeniería en sí mismo.
• Costes: entrenar un modelo competitivo desde cero está en el rango de millones de dólares, incluso para modelos relativamente modestos.
• Evaluación: necesitas benchmarks amplios para saber si el modelo resultante es siquiera coherente, no solo bueno en tu dominio.
• Mantenimiento: un modelo entrenado desde cero necesita mantenimiento continuo (nuevos datos, corrección de sesgos, actualizaciones) igual que cualquier modelo, pero sin el beneficio de partir de un modelo ya validado por la comunidad.

Tabla comparativa

14. El AI Worker: conectando todas las piezas

                    Usuario
                       │
                       ▼
                CMBR AI Worker
                       │
             ┌─────────┴─────────┐
             │                   │
             ▼                   ▼
           RAG                  LLM
             │                   │
             └─────────┬─────────┘
                       │
                       ▼
                    Tools
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       GitHub       Cloudflare      APIs
          │            │
          ▼            ▼
       Código       Workers/R2/D1

El flujo de una tarea real a través de este sistema:

1. Recibir una tarea: “revisa por qué falla este Worker en staging”.
2. Consultar documentación relevante (RAG).
3. Recuperar contexto (fragmentos de docs, quizás también el código del Worker vía una herramienta de GitHub).
4. Razonar: el LLM combina la pregunta, el contexto recuperado, y su conocimiento general para plantear hipótesis.
5. Decidir qué herramienta necesita: por ejemplo, “necesito ver los logs recientes de este Worker”.
6. Llamar una API (tool calling): se ejecuta la llamada real (p. ej. a la API de Cloudflare para obtener logs).
7. Analizar el resultado devuelto por la herramienta.
8. Generar una respuesta para el humano, con el diagnóstico.
9. Eventualmente, ejecutar una acción (crear un PR con el fix, si el sistema tiene permiso para ello).

LLM vs. Agent

Un LLM por sí solo solo puede responder dentro de una única llamada: recibe texto, produce texto. No tiene memoria persistente ni forma de actuar sobre el mundo exterior salvo lo que tú hagas manualmente con su respuesta.

Un Agent añade, alrededor de un LLM:

• un bucle que le permite hacer varios pasos de razonamiento antes de responder (a veces llamado ReAct: Reason + Act);
• acceso a herramientas que puede invocar cuando decide que las necesita;
• (opcionalmente) memoria persistente entre interacciones;
• (opcionalmente) estado por ejemplo, en el ecosistema de Cloudflare, el Agents SDK modela cada agente como un Durable Object, lo que le da estado persistente y ejecución de larga duración de forma nativa.

En otras palabras: el “agente” no es un tipo distinto de modelo. Es una arquitectura de software construida alrededor de un modelo.

15. Proyecto práctico progresivo: 12 niveles

La idea de esta sección es que construyas, sobre el mismo proyecto ficticio de CMBR, un sistema que evoluciona nivel a nivel. Cada nivel es funcional por sí mismo no es obligatorio llegar al nivel 12 para tener algo útil.

Estructura base del proyecto que usaremos en todos los niveles:

cmbr-ai/
├── worker/           # Cloudflare Worker (la app)
├── data/             # documentación, código fuente para RAG
├── rag/              # scripts de chunking, embeddings, indexado
├── training/         # datasets y scripts de fine-tuning/LoRA
├── evaluation/        # benchmark interno, scripts de evaluación
└── models/            # adapters LoRA entrenados, metadatos de modelos

Nivel 1 Chatbot básico con un modelo existente

Qué hacemos: un Worker que recibe una pregunta y la manda a un modelo de Workers AI. Por qué: validar el flujo más simple posible antes de añadir complejidad. Qué resuelve: nada específico de CMBR todavía es solo la tubería base. Qué necesitamos: una cuenta de Cloudflare, Wrangler, un binding AI.

export default {
  async fetch(request: Request, env: Env) {
    const { question } = await request.json();
    const result = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
      messages: [{ role: "user", content: question }],
    });
    return Response.json(result);
  },
};

Cómo comprobar que funciona: curl al Worker con una pregunta cualquiera y recibir una respuesta coherente. Errores comunes: olvidar el binding AI en wrangler.toml; nombre de modelo mal escrito. Qué aprendimos: cómo se ve, de punta a punta, el flujo de “usar un LLM ya entrenado”.

Nivel 2 Agregar system prompt

Qué hacemos: fijamos un system message que define el rol del asistente. Por qué: un LLM genérico no sabe que “trabaja para CMBR” hasta que se lo decimos. Qué resuelve: tono, alcance, y límites básicos de la conversación.

const messages = [
  { role: "system", content: "Eres el asistente técnico interno de CMBR. Respondes en español, de forma concisa, y siempre indicas cuándo no estás seguro de algo." },
  { role: "user", content: question },
];

Cómo comprobar que funciona: el tono y el idioma de las respuestas cambia de forma consistente. Qué aprendimos: prompting es la palanca más barata y debe agotarse antes de pasar al siguiente nivel.

Nivel 3 Agregar documentación mediante RAG

Qué hacemos: indexamos documentos internos de CMBR en Vectorize y recuperamos contexto relevante antes de llamar al LLM. Por qué: el modelo no conoce datos internos ni recientes. Qué necesitamos: un índice de Vectorize, un modelo de embeddings (por ejemplo, uno disponible en Workers AI), un pipeline de chunking.

// 1. Generar embedding de la pregunta
const { data } = await env.AI.run("@cf/baai/bge-base-en-v1.5", {
  text: [question],
});

// 2. Buscar los fragmentos más relevantes
const matches = await env.VECTORIZE.query(data[0], { topK: 4 });

// 3. Construir el contexto
const context = matches.matches.map(m => m.metadata.text).join("\n\n");

// 4. Llamar al LLM con el contexto
const messages = [
  { role: "system", content: "Responde usando SOLO el contexto proporcionado. Si no está ahí, dilo explícitamente." },
  { role: "user", content: `Contexto:\n${context}\n\nPregunta: ${question}` },
];

Errores comunes: chunks demasiado grandes (contexto irrelevante mezclado); no incluir metadata de origen (imposible auditar de dónde salió la respuesta); no manejar el caso “no encontré nada relevante”. Qué aprendimos: cómo separar “lo que el modelo sabe” de “lo que el modelo puede consultar”.

Nivel 4 Agregar GitHub como fuente de información

Qué hacemos: indexamos también código y descripciones de PRs desde el repositorio de CMBR. Por qué: mucho conocimiento útil vive en el código, no solo en la documentación. Qué necesitamos: un job periódico (o un webhook) que sincronice cambios del repo hacia el pipeline de indexado. Qué resuelve: preguntas del tipo “¿cómo implementamos X en otro servicio?”. Errores comunes: indexar secretos accidentalmente incluidos en el repo (revisar sección 18, seguridad); indexar código generado/vendored que no aporta valor.

Nivel 5 Crear un dataset propio

Qué hacemos: empezamos a recopilar ejemplos de calidad (“instrucción → respuesta ideal”) siguiendo el formato de la sección 8. Por qué: es el prerrequisito de fine-tuning. Qué necesitamos: revisión humana, un proceso de limpieza (deduplicación, eliminación de secretos). Resultado esperado: un archivo JSONL con unos cientos de ejemplos curados.

Nivel 6 Fine-tuning / LoRA

Qué hacemos: entrenamos un adapter LoRA sobre un modelo base compatible con Workers AI, usando el dataset del nivel 5. Por qué: queremos que el modelo adopte consistentemente el estilo/formato de CMBR sin tener que repetirlo en cada prompt. Qué necesitamos: una GPU (alquilada, p. ej. en la nube, o localmente si tienes una con suficiente VRAM), una librería como PEFT de Hugging Face, y luego subir el adapter resultante a Workers AI. Errores comunes: dataset demasiado pequeño → overfitting; rank de LoRA o tamaño de archivo fuera de los límites que soporta Workers AI (revisar la documentación oficial antes de entrenar). Cómo comprobar que funciona: comparar respuestas del modelo base vs. modelo + LoRA sobre las mismas preguntas.

Nivel 7 Crear un teacher y generar dataset sintético

Qué hacemos: usamos un modelo grande y capaz como “teacher” para generar automáticamente cientos o miles de ejemplos adicionales sobre el dominio de CMBR (con RAG como fuente de contexto para el teacher). Por qué: escribir manualmente miles de ejemplos de calidad es lento; el teacher acelera la generación (siempre con revisión humana de una muestra). Errores comunes: no revisar ni una muestra del output del teacher → contaminar el dataset con errores sistemáticos.

Nivel 8 Entrenar un student

Qué hacemos: entrenamos un modelo pequeño (1B–7B) sobre el dataset sintético del nivel 7. Por qué: buscamos un modelo mucho más barato de ejecutar en producción, especializado en el dominio acotado de CMBR.

Nivel 9 Aplicar distillation

Qué hacemos: si tenemos acceso a los logits del teacher (no siempre posible con APIs cerradas), incorporamos una señal de distillation más rica que solo el texto final, durante el entrenamiento del student. Por qué: mejora la calidad del student más allá de lo que lograría un simple fine-tuning sobre las respuestas de texto del teacher. Nota honesta: este nivel es técnicamente más exigente y en muchos casos el nivel 7+8 (response distillation simple) ya da resultados suficientemente buenos para una empresa como CMBR.

Nivel 10 Crear herramientas

Qué hacemos: definimos funciones/herramientas que el modelo puede invocar: consultar el estado de un Worker, buscar un issue en GitHub, leer una tabla de D1. Por qué: pasar de “responder preguntas” a “ejecutar tareas”. Errores comunes: dar demasiado permiso a una herramienta (ver seguridad, sección 18); no validar los argumentos que el modelo pasa a la herramienta antes de ejecutarla.

Nivel 11 Convertirlo en un agent

Qué hacemos: añadimos el bucle de razonamiento + herramientas + (opcionalmente) memoria persistente, por ejemplo usando el Agents SDK de Cloudflare, donde cada agente vive como un Durable Object con estado propio. Por qué: el sistema ahora puede encadenar varios pasos (“busca el error en logs → consulta la documentación relacionada → propón un fix → abre un PR”) sin intervención humana en cada paso intermedio.

Nivel 12 Desplegar en Cloudflare Workers / Workers AI

Qué hacemos: consolidamos todo en una arquitectura de producción: Worker como entrada, Vectorize para RAG, D1/KV para estado y configuración, Workers AI (con el adapter LoRA o el student distilado) para inferencia, AI Gateway delante para observabilidad, caching, rate limiting y control de costes. Resultado esperado: el sistema CMBR AI descrito al inicio del artículo, funcionando end-to-end.

16. Arquitectura final propuesta

                    CMBR AI
                       │
             ┌─────────┴──────────┐
             │                    │
             ▼                    ▼
       CMBR-1G Model             RAG
       (LoRA o student           │
        distilado)         ┌──────┼──────┐
             │              ▼      ▼      ▼
             │            Docs   GitHub  D1
             │
             ▼
          Tools
             │
      ┌──────┼─────────┐
      ▼      ▼         ▼
   Workers   R2        D1
      │
      ▼
  Workers AI

Qué debería vivir dentro del modelo:

• comportamiento y estilo (cómo estructura una respuesta técnica, qué formato de commit usa);
• patrones de razonamiento repetitivos y estables en el tiempo;
• terminología y convenciones que no cambian semana a semana.

Qué debería permanecer fuera del modelo (en RAG / Tools):

• cualquier dato que pueda cambiar (nombres de recursos, endpoints, versiones);
• cualquier dato que necesite trazabilidad de fuente para auditoría;
• credenciales, configuración, cualquier cosa sensible;
• la capacidad de ejecutar acciones eso vive en las herramientas, no en los pesos.

17. Evaluación: cómo saber si CMBR AI realmente funciona

Decir “parece que responde bien” no es evaluación, es intuición sin datos. Un sistema de IA empresarial necesita un benchmark interno.

100 preguntas conocidas (con respuesta esperada revisada por humanos)
        ↓
modelo base (sin nada)
        ↓
CMBR fine-tuned (solo LoRA)
        ↓
CMBR + RAG
        ↓
CMBR + RAG + tools

Se corre el mismo conjunto de preguntas contra cada configuración y se comparan resultados. Esto además sirve para aislar qué componente está aportando la mejora (o el problema).

Qué evaluar

Recomendación arquitectónica: empieza el benchmark con solo 20–30 preguntas reales que el equipo ya sabe responder de memoria. Es mejor tener un benchmark pequeño y honesto que uno grande y nunca mantenido.

18. Seguridad

Un agente que puede ejecutar herramientas necesita controles mucho más estrictos que un chatbot que solo responde. Los riesgos no son hipotéticos.

• Secretos en el dataset o en el corpus de RAG: API keys, passwords, tokens, connection strings que terminaron en un repo o documento indexado. Deben filtrarse antes de entrenar o indexar, no después.
• Datos privados / código propietario: define qué partes del código/documentación son elegibles para entrar al sistema de IA y cuáles no.
• Prompt injection: un usuario (o un documento malicioso recuperado por RAG) puede intentar manipular las instrucciones del sistema insertando texto como “ignora las instrucciones anteriores y…”. Mitigación: tratar todo contenido recuperado como datos, nunca como instrucciones con autoridad igual al system prompt; usar delimitadores claros; validar/filtrar salidas antes de ejecutar acciones.
• RAG poisoning: si cualquiera puede escribir en la fuente que alimenta el índice vectorial (por ejemplo, un wiki abierto), alguien podría insertar contenido diseñado para manipular las respuestas del sistema. Mitigación: controlar quién puede escribir en las fuentes indexadas, y revisar cambios sensibles.
• Tool abuse: si el modelo tiene una herramienta “borrar registro de base de datos” y comete un error de razonamiento, las consecuencias son reales, no solo texto incorrecto.
• Permisos y least privilege: cada herramienta debe tener el mínimo permiso necesario. Un agente que solo necesita leer logs no debería tener credenciales para escribir en producción.
• Sandboxing: ejecutar acciones potencialmente riesgosas (por ejemplo, correr código generado) en un entorno aislado, nunca directamente en producción.
• Logs y auditoría: cada decisión del agente (qué herramienta llamó, con qué argumentos, qué devolvió) debe quedar registrada para poder investigar qué pasó si algo sale mal. Herramientas como AI Gateway de Cloudflare están pensadas específicamente para dar esta visibilidad (logging, analíticas, límites de gasto) sobre el tráfico de inferencia de IA.

19. Roadmap de versiones: CMBR AI v0.1 → v1.0

CMBR AI v0.1  →  Prompt + API                (Nivel 1–2)
CMBR AI v0.2  →  + RAG                        (Nivel 3–4)
CMBR AI v0.3  →  + Tools                      (Nivel 10)
CMBR AI v0.4  →  + Dataset propio             (Nivel 5)
CMBR AI v0.5  →  + LoRA                       (Nivel 6)
CMBR AI v0.6  →  + Teacher                    (Nivel 7)
CMBR AI v0.7  →  + Student                    (Nivel 8)
CMBR AI v1.0  →  Distilled CMBR Model + Agent (Nivel 9–12)

Cada versión es funcional y desplegable por sí sola. No hay ninguna obligación de llegar a v1.0 muchas empresas obtienen el 80% del valor quedándose en v0.3 (Prompt + RAG + Tools), sin nunca entrenar nada.

20. Costes y hardware

Esta sección busca ser realista, no motivacional.

• CPU: suficiente para correr el Worker, el pipeline de chunking/indexado, y llamadas a APIs. No suficiente para entrenar ni para inferencia razonable de un LLM grande.
• GPU / VRAM: necesaria tanto para entrenar (fine-tuning/LoRA) como para correr inferencia de modelos grandes localmente. LoRA reduce sustancialmente los requisitos frente a fine-tuning completo, pero sigue necesitando una GPU con VRAM suficiente para cargar el modelo base en memoria durante el entrenamiento.
• RAM / almacenamiento: datasets, checkpoints y adapters ocupan espacio; los checkpoints de modelos completos pueden ser de varios GB a decenas de GB.

Qué puede hacer un desarrollador con…

• Una laptop sin GPU dedicada: usar APIs externas o Workers AI para inferencia; hacer prompting, construir RAG (el cómputo pesado de embeddings/vector search lo hace el proveedor); no es realista entrenar ni siquiera un LoRA de un modelo de varios miles de millones de parámetros con comodidad.
• Una GPU doméstica de gama alta: viable para entrenar LoRAs de modelos pequeños/medianos (según VRAM disponible), y para correr inferencia local de modelos pequeños para experimentación.
• GPU en la nube (alquilada por horas): la opción más práctica para la mayoría de equipos pequeños que necesitan entrenar un LoRA o hacer distillation puntual, sin comprar hardware.
• APIs de proveedores de modelos: cero infraestructura de tu lado; pagas por token; ideal para la fase de prompting, RAG, y para usar un modelo grande como “teacher”.
• Cloudflare Workers AI: inferencia gestionada, sin gestionar GPUs propias, con integración nativa a Workers, Vectorize y AI Gateway; para LoRA, el entrenamiento se hace fuera de la plataforma (BYO LoRA) y solo la inferencia corre en Workers AI.

Advertencia explícita: no prometas (ni te prometas) que un modelo de decenas de miles de millones de parámetros puede entrenarse cómodamente en hardware doméstico. Los precios, límites de VRAM y catálogos de modelos disponibles cambian constantemente verifica siempre cifras actuales antes de presupuestar un proyecto, tanto en la documentación de Cloudflare como en la del proveedor de GPU que uses.

21. Cloudflare en detalle: qué pieza hace qué

No todas estas tecnologías son necesarias para todo. Aquí una descripción honesta de qué hace cada una y cuándo tiene sentido usarla para CMBR, basada en documentación oficial de Cloudflare (developers.cloudflare.com).

Recomendación arquitectónica para CMBR (no un hecho de Cloudflare, es una decisión de diseño): para un primer sistema funcional, CMBR probablemente solo necesita Workers + Workers AI + Vectorize + D1. KV, Queues y Durable Objects se vuelven relevantes a medida que el sistema crece: KV cuando hay datos de lectura muy frecuente que cambian poco; Queues cuando el reindexado o la generación de datasets se vuelve pesado; Durable Objects cuando el sistema pasa de “responder preguntas” a “ser un agente con estado”. No hace falta adoptarlas todas desde el día uno.

Lo que hace el modelo vs. lo que hace Cloudflare:

• El modelo (LoRA/student) aporta comportamiento y razonamiento.
• Cloudflare aporta la infraestructura: dónde vive el conocimiento (Vectorize, R2, D1), dónde se ejecuta la inferencia (Workers AI), cómo se orquesta todo (Workers), y cómo se observa y controla (AI Gateway).

22. Arquitectura recomendada para CMBR

                    ┌─────────────────────┐
                    │      Usuario        │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ Cloudflare Worker   │
                    └──────────┬──────────┘
                               │
                    ┌──────────┴──────────┐
                    ▼                     ▼
                  RAG                    LLM
                    │                     │  (Workers AI,
          ┌─────────┼────────┐            │   modelo base + LoRA
          ▼         ▼        ▼            │   o student distilado)
       GitHub     Docs      D1            │
      (via API) (Vectorize)(metadata)     │
                                           │
                    ┌──────────────────────┘
                    ▼
                 Tools
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       GitHub     Cloudflare  APIs
        API          API      internas

     (todo el tráfico de inferencia pasa por AI Gateway
      para logging, caché, límites de gasto y fallback)

Dónde vivirían los componentes de datos:

• Embeddings y documentos indexados → Vectorize (vectores) + R2 (documentos fuente originales).
• Metadata (origen, fecha, versión de cada chunk) → junto a los vectores en Vectorize, o en D1 si necesita consultas relacionales más ricas.
• Modelos y adapters → R2 (almacenamiento de los archivos adapter_model.safetensors), registrados en Workers AI para servir inferencia.
• Logs → capturados vía AI Gateway (logging de peticiones de IA) y/o Workers Logs para el resto de la aplicación.
• Datasets → R2, versionados (ver sección 24, errores comunes: “no versionar datasets”).
• Evaluaciones → resultados de benchmark guardados en D1 para poder comparar versiones del sistema a lo largo del tiempo.

23. ¿Por qué no simplemente usar Qwen o Llama tal cual?

Es una pregunta legítima y merece una respuesta honesta, no una respuesta de marketing.

El valor real de construir algo propio

• Especialización: un modelo que ha visto miles de ejemplos del dominio de CMBR responde con menos ambigüedad sobre las convenciones específicas de la empresa que un modelo genérico al que hay que recordárselo cada vez.
• Comportamiento y estilo consistentes: sin depender de que cada usuario escriba un prompt perfecto con instrucciones detalladas.
• Eficiencia y coste: un student pequeño y especializado puede ser mucho más barato de ejecutar en volumen que llamar constantemente a un modelo grande y genérico.
• Privacidad y control: procesar información sensible de CMBR sin que salga hacia un proveedor externo, si eso es un requisito.
• Despliegue: correr inferencia cerca de los datos y de los usuarios (por ejemplo, en el borde con Workers AI) en lugar de depender de la disponibilidad de un tercero.
• Integración con herramientas: un sistema diseñado a medida para las APIs y procesos internos de CMBR, no un chatbot genérico al que hay que adaptar todo desde fuera.

La respuesta honesta

Construir un modelo propio no siempre es mejor que usar un modelo general + RAG + tools. De hecho, para la mayoría de las empresas, en la mayoría de los casos, no lo es.

Tiene sentido construirlo cuando:

• ya se agotaron prompting y RAG y sigue habiendo un problema de comportamiento/estilo consistente;
• el volumen de uso es lo suficientemente alto como para que el ahorro de coste de un modelo pequeño especializado compense la inversión de entrenarlo;
• hay requisitos reales de privacidad/control que un modelo externo no puede cumplir;
• existe la capacidad interna (o el presupuesto para contratarla) de mantener el pipeline de entrenamiento y evaluación en el tiempo un modelo entrenado y abandonado se vuelve obsoleto rápido.

Sería una mala decisión cuando:

• el problema real es de documentación desactualizada o mal organizada (eso lo arregla RAG, no fine-tuning);
• el equipo no tiene aún un proceso de evaluación entrenar sin poder medir si mejoraste o empeoraste es apostar a ciegas;
• el volumen de uso es bajo el coste de mantener un pipeline de entrenamiento propio puede superar por mucho lo que costaría simplemente seguir llamando a una API externa.

24. Errores comunes de un principiante

1. Querer entrenar un LLM desde cero. Casi nunca es necesario ni viable para una empresa individual (sección 13).
2. Creer que RAG equivale a entrenamiento. RAG no modifica el modelo; es contexto añadido en cada consulta.
3. Hacer fine-tuning con datos malos. Un modelo fine-tuneado sobre datos sucios aprende (y refuerza) esos errores de forma consistente.
4. Entrenar con secretos incluidos en el dataset. Las credenciales pueden quedar “memorizadas” y ser recuperables.
5. Usar datos duplicados. Sesga el entrenamiento y desperdicia cómputo.
6. No evaluar. Sin benchmark, no hay forma objetiva de saber si algo mejoró.
7. No separar datos de entrenamiento y evaluación. Si evalúas con los mismos ejemplos que usaste para entrenar, tus métricas no significan nada.
8. Creer que más parámetros siempre significa mejor. Para una tarea acotada, un modelo pequeño bien especializado puede superar a uno grande y genérico, con una fracción del coste.
9. Creer que un modelo pequeño automáticamente será igual de bueno que el grande. La distillation ayuda a acercarse, no a igualar hay una pérdida de capacidad general que hay que aceptar conscientemente.
10. Confiar demasiado en benchmarks genéricos. Un benchmark público no necesariamente predice el desempeño en tu dominio específico; de ahí la importancia del benchmark interno (sección 17).
11. No versionar datasets. Sin versión, no puedes reproducir por qué un modelo se comporta de cierta forma, ni volver atrás.
12. No versionar modelos/adapters. Lo mismo aplica a los checkpoints y adapters resultantes del entrenamiento.
13. No controlar las herramientas de un agente. Dar acceso amplio “por si acaso” es la forma más común de terminar con un incidente de seguridad evitable.
14. Mezclar conocimiento temporal con conocimiento que debería estar en RAG. Si algo cambia con frecuencia, no debería vivir dentro de los pesos del modelo.
15. No tener rollback. Si una nueva versión del modelo o del índice RAG empeora las cosas, necesitas poder volver a la versión anterior rápidamente.

25. Roadmap de aprendizaje por fases

26. Conclusión

Volvamos a la idea con la que empezamos este artículo. La pregunta nunca fue realmente:

“¿Cómo entreno mi propia IA?”

La pregunta real, y la que este artículo intenta responder, es:

“¿Cómo construyo progresivamente un sistema inteligente especializado en mi empresa, sabiendo exactamente qué pieza resuelve qué problema?”

La respuesta es una suma, no un solo componente:

Modelo
+
RAG
+
Fine-tuning
+
Distillation
+
Tools
+
Agents
+
Infraestructura
+
Evaluation
+
Seguridad
=
CMBR AI

El modelo especializado (CMBR-1G) es solo una pieza de este sistema, no el sistema completo. Y para la mayoría de los equipos, ni siquiera es la pieza por la que deberían empezar.

La visión realista con la que te queremos dejar es esta: no necesitas empezar construyendo un modelo de 70B desde cero. Puedes y probablemente deberías avanzar así:

API
 ↓
Prompt
 ↓
RAG
 ↓
Tools
 ↓
Dataset
 ↓
Fine-tuning
 ↓
LoRA
 ↓
Teacher
 ↓
Student
 ↓
Distillation
 ↓
Modelo especializado

Cada paso tiene un propósito claro. Cada paso es funcional por sí solo. Y en cada paso, la pregunta correcta no es “¿cómo llego al siguiente nivel?”, sino “¿el problema que tengo ahora mismo realmente necesita el siguiente nivel, o ya lo resolví?”

27. Glosario

• LLM (Large Language Model): modelo de lenguaje entrenado sobre grandes volúmenes de texto, capaz de generar y comprender lenguaje natural (y código).
• Token: fragmento de texto (palabra, parte de una palabra, o símbolo) en que un modelo divide el input/output.
• Parámetro: número ajustable dentro del modelo; la cantidad total de parámetros (1B, 7B, etc.) es una medida aproximada de su capacidad.
• Embedding: representación numérica (vector) de un token, palabra, frase o documento, tal que elementos con significado similar tienen vectores cercanos.
• Vector: lista ordenada de números; en IA, la forma en que se representa el “significado” de algo.
• Inference (inferencia): usar un modelo ya entrenado para generar una salida a partir de un input nuevo.
• Training (entrenamiento): proceso de ajustar los parámetros de un modelo a partir de ejemplos.
• Pretraining: entrenamiento inicial de un modelo desde pesos aleatorios, sobre un corpus masivo y general.
• Fine-tuning: continuar entrenando un modelo ya preentrenado sobre un dataset más pequeño y específico, para modificar su comportamiento.
• LoRA (Low-Rank Adaptation): técnica de fine-tuning eficiente que congela los pesos originales y entrena solo un pequeño conjunto de matrices adicionales.
• PEFT (Parameter-Efficient Fine-Tuning): familia de técnicas (LoRA entre ellas) que ajustan solo una fracción de los parámetros de un modelo.
• RAG (Retrieval-Augmented Generation): arquitectura donde el modelo recibe, en cada consulta, fragmentos de información relevante recuperados de una base de conocimiento externa.
• Vector database (base de datos vectorial): base de datos optimizada para almacenar embeddings y realizar búsquedas de similitud eficientes.
• Context window (ventana de contexto): cantidad máxima de tokens que un modelo puede procesar en una sola llamada (entrada + salida).
• Checkpoint: estado guardado de los pesos de un modelo en un momento determinado del entrenamiento.
• Quantization (cuantización): reducción de la precisión numérica de los pesos de un modelo (por ejemplo de 16 a 4 bits) para reducir su tamaño y acelerar la inferencia, a cambio de una pequeña pérdida de precisión.
• Distillation (destilación de conocimiento): proceso de entrenar un modelo más pequeño (student) para imitar el comportamiento de uno más grande (teacher).
• Teacher model: modelo grande y capaz usado como fuente de ejemplos/señal de entrenamiento para un modelo más pequeño.
• Student model: modelo más pequeño, entrenado a partir de las salidas o señales de un teacher.
• Dataset: conjunto estructurado de ejemplos usados para entrenar o evaluar un modelo.
• Evaluation (evaluación): proceso sistemático de medir el desempeño de un modelo frente a un conjunto de referencia.
• Benchmark: conjunto de pruebas/preguntas estandarizado usado para comparar el desempeño de distintos modelos o versiones.
• Agent (agente): arquitectura de software que combina un LLM con un bucle de razonamiento y acceso a herramientas, para poder ejecutar tareas, no solo responder preguntas.
• Tool calling / function calling: capacidad de un modelo de indicar que quiere invocar una función/herramienta externa, con ciertos argumentos, en lugar de responder directamente en texto.
• Hallucination (alucinación): cuando un modelo genera información que suena plausible pero es incorrecta o inventada.
• Prompt injection: técnica de ataque donde se inserta texto (en el prompt del usuario o en contenido recuperado) diseñado para manipular las instrucciones que sigue el modelo.
• Overfitting: cuando un modelo “memoriza” el dataset de entrenamiento en lugar de generalizar, funcionando mal ante ejemplos nuevos.
• Chunking: dividir un documento largo en fragmentos más pequeños y manejables antes de indexarlo para RAG.
• Reranking: paso adicional en RAG donde un modelo más preciso reordena los resultados iniciales de una búsqueda de similitud para mejorar la relevancia final.

28. Fuentes

Documentación oficial de Cloudflare (consultada en 2026; verifica la versión actual en cada enlace, ya que Cloudflare actualiza estos productos con frecuencia):

• Workers AI Fine-tunes overview: developers.cloudflare.com/workers-ai/features/fine-tunes/
• Workers AI Using LoRA adapters: developers.cloudflare.com/workers-ai/features/fine-tunes/loras/
• Vectorize Overview: developers.cloudflare.com/vectorize/
• Vectorize Introducción y conceptos de bases de datos vectoriales: developers.cloudflare.com/vectorize/get-started/intro/ y developers.cloudflare.com/vectorize/reference/what-is-a-vector-database/
• AI Gateway Overview: developers.cloudflare.com/ai-gateway/
• Cloudflare Blog “Leveling up Workers AI: general availability and more new capabilities” (anuncio de LoRA, GA de Workers AI, Vectorize metadata filtering): blog.cloudflare.com/workers-ai-ga-huggingface-loras-python-support/
• Cloudflare Blog “Running fine-tuned models on Workers AI with LoRAs”: blog.cloudflare.com/fine-tuned-inference-with-loras/
• Cloudflare Blog “Cloudflare’s AI Platform: an inference layer designed for agents” (Agents SDK, Durable Objects como base de los agentes): blog.cloudflare.com/ai-platform/

Papers académicos citados:

• Hu, E. J. et al. (2021). LoRA: Low-Rank Adaptation of Large Language Models.
• Hinton, G., Vinyals, O., & Dean, J. (2015). Distilling the Knowledge in a Neural Network.
• Sanh, V. et al. (2019). DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter.
• Zhou, C. et al. (2023). LIMA: Less Is More for Alignment.
• Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (paper original que introduce el término RAG).

Todos los nombres de modelos, límites técnicos (tamaño máximo de adapter, rank máximo, número de LoRAs por cuenta, modelos base compatibles) y capacidades de producto descritos en este artículo corresponden a lo documentado oficialmente por Cloudflare al momento de la investigación. Estos detalles cambian con relativa frecuencia antes de tomar decisiones de arquitectura o presupuesto, vuelve a consultar la documentación oficial vigente.