¿Fine-tune, recuperar o usar un prompt? La decisión es económica

«¿Deberíamos hacer fine-tuning?» se plantea como si fuera una pregunta sobre un modelo. Es una pregunta sobre un presupuesto, con una forma que ningún benchmark responde: qué se paga una vez, qué se paga por pregunta y qué se vuelve a pagar cada vez que el mundo se mueve.

Las tres rutas tampoco son tres formas de hacer lo mismo, y los proveedores lo dicen con más claridad que la mayoría de posts de blog. La propia tabla de OpenAI sobre para qué es mejor el fine-tuning supervisado enumera cuatro usos: clasificación, traducción matizada, generar contenido en un formato específico y corregir fallos de seguimiento de instrucciones.¹ Ninguno es «enseñar al modelo algo que no sabe». Su resumen del beneficio es que «puedes usar prompts más cortos con menos ejemplos y datos de contexto, lo que ahorra costes de token a escala y puede reducir la latencia»: un argumento sobre la factura, de la empresa que vende la función.

Así que:

• El fine-tuning enseña forma y comportamiento. Tono, formato, la estructura de una respuesta, un límite que puedes demostrar pero no describir. La versión publicada más sólida es la hipótesis de alineación superficial de LIMA: el conocimiento viene del pretraining, la alineación enseña sobre todo en qué subdistribución de formatos hablar; por eso allí bastaron mil ejemplos curados.²
• La recuperación aporta hechos que cambian. Es la única de las tres en la que una edición de tu documentación llega a la respuesta sin tocar el modelo.
• El prompting cubre la mayoría de los casos reales, y es la línea base honesta. El aprendizaje en contexto ha sido el valor por defecto desde Language Models are Few-Shot Learners: la tarea se demuestra dentro del prompt y ningún peso se mueve.³

Dos papers medidos cierran la puerta al error intermedio. Ovadia y sus colegas compararon inyectar conocimiento mediante fine-tuning no supervisado frente a inyectarlo mediante recuperación, y la recuperación ganó de forma consistente, incluso en hechos que el modelo base ya había visto durante el pretraining.⁴ Gekhman y sus colegas midieron el daño: los ejemplos que introducen conocimiento nuevo se ajustan lentamente y, cuando el modelo acaba ajustándolos, su tasa de alucinación en otras preguntas aumenta.⁵ Enseñar hechos mediante fine-tuning no solo falla; degrada respuestas sobre las que no estabas entrenando.

Esa mitad queda resuelta. La mitad económica no, y es el resto del capítulo.

Un caso, ejecutado de tres formas: soporte técnico sobre tu propia documentación, que cambia cada semana.

El corpus es real y está en este disco: los 23 documentos Markdown que un repositorio de software en activo mantiene como documentación interna: la guía de build, las reglas de marca, el brief de traducción, diez manuales de servicios, las notas de rendimiento y seguridad. Medido con o200k_base, la codificación del capítulo 7:

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

Cuarenta y tres mil tokens es un tamaño cómodo para esta decisión: cabe en cualquier context window moderna, así que las tres rutas están disponibles de verdad. Con diez millones, la decisión ya está tomada por ti, y es recuperación.

Ahora el trabajo que hace la palabra «semanal». El churn de documentación suele afirmarse; aquí se cuenta, a partir del historial de versiones de ese repositorio:

Los documentos se mueven más o menos cada dos semanas. Las cadenas visibles para el usuario —que son aquello por lo que realmente pregunta un equipo de soporte— se movieron todas las semanas desde que existen, a unos veinte commits por semana. La ruta que elijamos tiene que sobrevivir a eso, y «¿con qué frecuencia cambia aquello con lo que entrenaste?» resulta tener un número en tu propio repositorio, no una opinión.

Se escribieron veinte preguntas de soporte realistas contra este corpus, una por tema, y todas las cifras de abajo se calculan sobre esas veinte.

Lo más sencillo que funciona: poner todo el corpus en el system prompt, la pregunta al final, y dejar que el modelo lo encuentre.

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

Todos los números de ahí se contaron salvo el último: 150 output tokens es una suposición, elegida dentro del rango de turnos del asistente que el capítulo 16 facturó. Es la única cifra aquí que no se ejecutó, se aplica de forma idéntica a las tres rutas y la sección de punto de equilibrio muestra exactamente cuánto se mueve la conclusión cuando la cambias.

A las tarifas leídas en la página del proveedor el 7 de septiembre de 2026 —$1.50 por millón de input tokens, $9.00 por millón de output⁶— eso son $0.066317 por pregunta. Estás pagando por releer cuarenta y tres mil tokens para responder trece.

La solución del capítulo 16 se aplica directamente: el corpus es estable y está al principio, así que es un prefijo perfecto para caché, y volver a leerlo cuesta una décima parte: $0.007864 por pregunta, un recorte del 88 %. La advertencia del capítulo 16 también se aplica, en la forma que ese capítulo señaló pero no puso precio. Este proveedor no cobra prima de escritura; cobra alquiler. Una caché explícita cuesta $0.000001 por token almacenado y hora,⁶ así que mantener calientes 43,298 tokens cuesta

pregunte alguien o no. Eso son $189.78 en seis meses, por una sala vacía. Divide el alquiler por el ahorro por pregunta y la condición sale en una línea: almacenar este corpus en caché se paga solo por encima de 0,74 preguntas por hora: 546 al mes una vez incluido también el rebuild semanal de la caché. Por debajo de eso, la función que activaste para ahorrar dinero lo pierde.

Misma ruta, mismo código, una bandera, cinco veces la factura. El capítulo 16 encontró una versión de esto causada por un timestamp en el lugar equivocado; aquí no hay nada mal salvo el tráfico. Una caché es una apuesta por el volumen, y en este proveedor la haces por horas.

El recuperador del capítulo 19, sin cambios: cortar por límites de sección con una cabecera contextual, indexar, poner los cuatro mejores extractos en el prompt. Medido sobre las veinte preguntas:

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

Cuarenta y dos veces menos prompt tokens que la ruta uno, a $0.002906 por pregunta. El índice cuesta $0.0070 construirlo a $0.15 por millón de embedding tokens⁶: menos que tres preguntas, y los mismos $0.0070 para reconstruirlo desde cero cada vez que cambia la documentación. Reconstruir todo el índice cada semana durante seis meses cuesta dieciocho céntimos.

Hay una cosa en la que merece la pena detenerse. La recuperación destruye el prompt caching. El prefijo estable es ahora la instrucción de sistema de 140 tokens; desde el token 141, el prompt difiere en cada llamada, porque los extractos se eligen por pregunta. Y 140 tokens está por debajo de todos los mínimos de caché que citó el capítulo 16. Así que la ruta dos no puede cachearse en absoluto, lo que suena mal y no lo es: no cachear 1,037 tokens es más barato que cachear 43,298.

Esa es una regla general que conviene llevarse: las dos grandes técnicas de ahorro de tokens son mutuamente excluyentes sobre el mismo contenido, y gana la que elimina más tokens. La recuperación elimina el 97,6 %.

Entrena con doscientos ejemplos en el estilo de la casa y luego haz preguntas sin adjuntar documentación alguna.

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

El entrenamiento cuesta 24,389 × 3 × $10.00 por millón = $0.7317. Ese es todo el coste de construcción, menos que un café, que es exactamente por qué tantos equipos lo pagan antes de comprobar si ayuda.

Ahora la trampa, y es la razón por la que existe este capítulo. Un modelo con fine-tuning no cuesta lo mismo que su modelo base al ejecutarse. La página de precios lo dice en una frase: «para inferencia de modelos a partir de Gemini 3, el precio de predicción del endpoint de modelo ajustado será 1,5 veces el del modelo base».⁶ No el entrenamiento. La inferencia, en cada token, durante toda la vida del modelo.

Así que ponlo en una fórmula. Sea $p_i$ y $p_o$ los precios base de input y output, $m$ el multiplicador del modelo ajustado, $L_R$ la longitud del prompt de la ruta que estás sustituyendo, $L_F$ la longitud del prompt después del fine-tuning y $O$ la longitud de la respuesta. El fine-tuning solo es más barato por pregunta cuando

El primer término es obvio: tu nuevo prompt corto, con recargo. El segundo no lo es, y ahí es donde se va el dinero: el recargo sobre la respuesta, que no tiene nada que ver con tu prompt y que el entrenamiento no puede acortar. Con los números medidos —$m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$— el umbral es

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

A la longitud de respuesta medida, 492 tokens, de los cuales 450 son el recargo de la respuesta, no el prompt. Sustituir un prompt más corto que eso es más caro por pregunta, para siempre, a cualquier volumen; y el umbral crece linealmente con cuánto habla tu asistente, así que uno que escribe respuestas largas nunca puede hacer fine-tuning para lograr un token más barato por mucho prompt que elimine.

El mismo hecho visto desde el otro extremo es la frase que hay que recordar. De los $0.002088 por pregunta de la ruta con fine-tuning, el 97,0 % es la respuesta. El fine-tuning optimiza el tres por ciento restante.

Cuatro números describen cualquiera de estas rutas: lo que pagas una vez, lo que pagas cuando cambia la documentación, lo que pagas por hora independientemente de todo y lo que pagas por pregunta. Eso amplía el computeCost del capítulo 16 sin modificarlo.

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

El modelo ajustado no es una lista de precios distinta, es la misma multiplicada:

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

Esa línea resaltada es todo el argumento de la sección anterior escrito como código: el multiplicador también aterriza sobre output.

Seis meses, con la documentación actualizada semanalmente:

Y los cruces, que son los cuatro números que un presupuesto realmente necesita:

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

Lee los dos primeros juntos, porque son el punto del capítulo. Un corpus estacionario hace que el fine-tuning se pague solo en ciento cincuenta preguntas; un corpus que cambia semanalmente mueve el mismo cruce por un factor de veintisiete, y nada del modelo cambió: solo cuántas veces vuelves a pagarlo. El coste de construcción es una nota al pie; el coste de mantenimiento es la decisión.

Si ahora concluyes que un equipo de soporte con mucho volumen debería hacer fine-tuning, la aritmética te da la razón. Sigue siendo incorrecto, y la siguiente sección explica por qué.

La hoja de costes tiene una columna que no puede calcular, así que esta sección ejecuta el fine-tune: en local, sobre un modelo abierto pequeño, con el adaptador escrito a mano en lugar de importado de una librería. El capítulo 11 construyó LoRA; aquí está, sobre q_proj y v_proj de las 24 capas de Qwen2.5-0.5B-Instruct con rango 8:

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

Los doscientos ejemplos de entrenamiento salen mecánicamente del corpus, así que se reproducen: la pregunta es un encabezado de sección convertido en pregunta; la respuesta es el propio texto de esa sección en un estilo de casa rígido: una línea que empieza por Short answer:, una línea que empieza por Source: con la ruta del archivo. El formato es la forma que se enseña; la ruta es el hecho. Luego, dos números sobre veinte preguntas reservadas: ¿la respuesta sale en el estilo de la casa? ¿nombra el archivo que realmente responde a la pregunta?

Dos líneas base hacen legible la tabla, y ambas son la insistencia del capítulo 4, no una ocurrencia posterior. Diez de las veinte respuestas correctas son el mismo archivo, así que un modelo que ignora la pregunta y siempre responde CLAUDE.md puntúa 10/20. Y el recuperador tiene su propio techo: en estas veinte preguntas, sus cuatro extractos contienen el archivo correcto 14 veces y lo colocan primero 7, así que 14/20 es lo máximo que podría puntuar cualquier lector que lo usara.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

La forma se aprendió, por completo y rápido. De cero a diecinueve de veinte, con un adaptador de 540,672 parámetros —el 0,109 % del modelo— en cinco minutos de entrenamiento en un procesador sin tarjeta gráfica a la vista.

Los hechos no. Ocho de veinte no se distingue de los diez que obtienes ignorando la pregunta por completo, y el intervalo del capítulo 4 sobre veinte muestras lo dice en voz alta. Esas rutas de archivo estaban en los datos de entrenamiento tres veces; lo que salió fue el hábito de terminar con una línea Source: de aspecto plausible. Ante la pregunta del principio de este capítulo, el modelo con fine-tuning respondió Short answer: 10.x . . . y citó CLAUDE.md. La respuesta correcta, que está en CLAUDE.md, es 18.17.0.

Y luego la forma se rompió, que es la fila que justifica el experimento. Dale al modelo con fine-tuning mil tokens de extractos recuperados —una forma de prompt que nunca vio, ya que todos los prompts de entrenamiento tenían veintiocho tokens— y el estilo de la casa cae de 19/20 a 1/20. En la pregunta del principio de este capítulo responde 18.17.0: correcto, y sin nada del formato para el que se entrenó. Así que el fine-tuning no enseñó un formato; enseñó un formato condicionado a los prompts del conjunto de entrenamiento, y el primer prompt que parecía distinto se llevó el formato por delante. Lo que sea sobre lo que hagas fine-tuning se convierte en la única distribución de entrada en la que tu modelo es bueno, y nadie pone eso en la hoja de cálculo.

Una última nota sobre la métrica, apuntando directamente al capítulo 29: «fuente correcta» puntúa forma y hecho juntos, por eso ambas filas de recuperación parecen terribles aunque ambos modelos acertaran el hecho de esa pregunta. Un único número end-to-end ocultaba tres cosas —un recuperador con recall 14/20, un lector de 0.5B y un formato de cita—, y elegir qué arreglar significa separarlas antes de medir, no después.

Ahora la columna que los proveedores rellenan por ti. Un modelo con fine-tuning no es un activo que poseas; es un alquiler sobre el modelo base de otra persona, con una fecha de finalización impresa. El 7 de septiembre de 2026, la sección de fine-tuning de la página de precios de OpenAI incluía este aviso completo:

OpenAI está retirando gradualmente la plataforma de fine-tuning. La plataforma ya no es accesible para nuevos usuarios, pero los usuarios existentes de la plataforma de fine-tuning podrán crear trabajos de entrenamiento durante los próximos meses. Todos los modelos con fine-tuning seguirán disponibles para inferencia hasta que sus modelos base queden obsoletos.⁷

La cronología está fechada al día: 7 de mayo de 2026, cerrada a organizaciones que nunca habían hecho fine-tuning; 2 de julio de 2026, cerrada a quienes no habían ejecutado inferencia sobre un modelo con fine-tuning en sesenta días; 6 de enero de 2027, ningún trabajo nuevo en absoluto.⁸ La misma página programa el apagado de los propios modelos con fine-tuning —ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002— el 23 de octubre de 2026, cada uno con un modelo base de reemplazo recomendado, que es una forma educada de decir: entrénalo otra vez.

El otro proveedor frontier nunca te vendió el alquiler. El índice de documentación de Anthropic enumera 699 páginas y ni una trata sobre fine-tuning; las secciones de personalización de modelos de la página de precios de Bedrock cubren Amazon Nova, Amazon Titan, Cohere, Meta y modelos OpenAI de pesos abiertos, y ningún Claude.⁹¹⁰ Si tu arquitectura depende de un fine-tune, una de las tres familias frontier simplemente no está disponible para ti con ningún presupuesto.

El self-hosting sustituye el alquiler de un modelo por el alquiler de una máquina, y AWS hace esa aritmética en su propia página: una unidad de modelo de throughput aprovisionado para un modelo personalizado, compromiso de un mes, es «1 unidad de modelo × $21.18 × 24 horas × 31 días = $15,757.92» al mes.¹⁰ Alquilar el metal directamente es más barato y no gratis: $3.99 por GPU-hora bajo demanda para una H100, $1.99 preemptible¹¹, aproximadamente $2,900 al mes por una tarjeta que tiene que estar encendida pregunte alguien o no. Toda la ruta de recuperación con diez mil preguntas al mes cuesta $174.52 durante seis meses.

Aquí es donde LoRA se gana su sitio, como argumento presupuestario más que técnico. Medido sobre el mismo modelo, un adaptador de rango 16 sobre attention y las capas feed-forward tiene 8,798,208 parámetros —el 1,781 % del modelo, 17,6 MB en bfloat16— frente a 0,988 GB de pesos base, y su estado de optimizador y gradient ocupa 140,77 MB, donde el fine-tuning completo necesita 7,90 GB, un factor de 56. La consecuencia no es un entrenamiento más barato, sino que un modelo base cargado puede servir muchos adaptadores, que es la única forma de dividir el coste fijo de una GPU entre algo. El entrenamiento gestionado lo refleja: $0.48 por millón de tokens en bajo rango hasta 16B frente a $0.54 completo, con un mínimo de $4.00 por trabajo.¹¹ Ese suelo es el detalle. Con 24,389 tokens durante tres épocas, cada reentrenamiento sobre este corpus factura $4.00 en lugar de los $0.04 que salen de calcularlo: $104 de mínimos a lo largo de veintiséis ejecuciones semanales, por noventa y un céntimos de aritmética.

Dos columnas más que solo aparecen en la factura.

La residencia de datos cuesta alrededor de un diez por ciento, y dos proveedores coinciden en la cifra. OpenAI cobra «un recargo del 10 %» en endpoints de residencia de datos para modelos lanzados a partir del 5 de marzo de 2026;⁷ Vertex fija sus endpoints no globales en $1.65 frente a $1.50, el mismo diez por ciento.⁶ Compáralo con el cincuenta por ciento que cuesta un endpoint ajustado y el folclore se invierte: la residencia es barata y el fine-tuning no; y el fine-tuning tampoco es la opción privada, porque el corpus llega al proveedor de cualquier forma, una vez en el momento del entrenamiento en lugar de una vez por llamada.

El precio más explícito que jamás se ha puesto a tus datos está en la misma página, que lista dos veces un modelo con fine-tuning: con intercambio de datos activado, la inferencia cuesta exactamente la mitad: $2.00 frente a $4.00 en input, $8.00 frente a $16.00 en output.⁷ Dejar que el proveedor conserve lo que enviaste vale un descuento del 50 %, lo que te dice cuánto vale para ellos.

La destilación —entrenar un modelo pequeño propio con las respuestas de uno grande— suele presentarse como una salida para ambas cosas. Ponle precio y no lo es, porque el profesor es el sistema que intentabas sustituir: producir doscientos ejemplos de entrenamiento preguntando a la ruta de recuperación doscientas veces cuesta 200 × $0.002906 = $0.58, además de los $0.73 de entrenar con ellos. La destilación es algo que haces después de que la canalización de recuperación funcione, para abaratarla, y hereda cada hecho que el recuperador obtuvo mal.

El dinero es la mitad visible. La otra llega como una espera, con la misma causa que la factura: el modelo lee todo el prompt antes de decir una palabra. El capítulo 13 midió prefill frente a decode en un modelo que podías tocar; aquí está la misma medición, una ejecución, una máquina, contra la longitud del prompt:

Los números absolutos pertenecen a un modelo de 0.5B sobre dieciséis hilos de CPU y no dicen nada sobre un frontier model alojado. La forma se transfiere exactamente: el prefill crece con la longitud del prompt, y el coste por token sube lentamente cuando empieza a notarse el término cuadrático del capítulo 9: 4.79 ms con mil tokens frente a 6.04 ms con ocho mil, una penalización del 26 % por ser simplemente más largo.

La consecuencia para las tres rutas es directa. La ruta uno hace prefill de cuarenta y tres mil tokens por pregunta, y un acierto de caché es lo que lo hace soportable; el capítulo 16 explicó por qué: una lectura de caché sustituye trabajo de prefill, así que compra latencia y dinero en una sola transacción. La ruta dos hace prefill de mil y añade primero un viaje de ida y vuelta al índice. La ruta tres hace prefill de veintiocho y no añade nada, lo que la convierte, mediblemente, en la más rápida de las tres al responder. Solo que responde a lo equivocado.

Tres fallos que parecen problemas de modelo y no lo son: diez minutos aquí ahorran un mes después:

Y el requisito sobre todo ello: esta decisión no puede tomarse sin un conjunto de evaluación, y el proveedor que vende el fine-tune lo dice. La guía de OpenAI abre con «Solo invierte en fine-tuning después de configurar evals. Necesitas una forma fiable de determinar si tu modelo con fine-tuning rinde mejor que un modelo base», y añade que, si cincuenta buenos ejemplos no cambian nada, el problema es la tarea o el prompt, no el volumen de datos.¹ Veinte preguntas, que es lo que usó este capítulo, muestran un mecanismo y no pueden elegir proveedor; el capítulo 4 midió por qué, y qué hacer cuando veinte casos son todo lo que tienes —repetirlos, emparejarlos y medir la dispersión entre ejecuciones— es el capítulo 29.

Cuatro columnas, y solo la última decide:

La regla que sale de ahí, y es lo bastante corta para guardarla: empieza por el prompt; añade recuperación cuando los hechos se muevan; haz fine-tuning solo cuando hayas medido que lo que aún te falta es una forma, no un hecho; y pon precio a la respuesta, no al prompt, antes de hacerlo.

La versión incómoda, para cualquiera que llegara con la decisión ya tomada: en el caso medido de este capítulo, el fine-tuning sí es la ruta más barata por encima de cuatro mil preguntas al mes, y aun así, en los hechos, no puede superar responder CLAUDE.md a todo.

Todos los precios aquí han sido por token, y cada ruta una forma distinta de organizar tokens. Eso está a punto de dejar de ser cierto.

El capítulo 21 abandona el texto. Una imagen que entra en un modelo no es una string, sino una cuadrícula de patches con un recuento de tokens que no has elegido; un minuto hablado se factura por segundo en un proveedor y por audio token en otro; la voz sintética se vende por carácter, la transcripción por minuto, el compute bruto por GPU-segundo. La pregunta que este capítulo respondió con una función de coste —¿qué es más barato?— ni siquiera puede plantearse hasta que las unidades coinciden, y ninguna calculadora de internet las normaliza.

También es donde vuelve a aparecer el entrenamiento: un adaptador de imagen con una trigger word y una voz clonada a partir de una muestra. Lo que plantea la pregunta con la que abre el próximo capítulo, y no es retórica: si hacer fine-tuning de un modelo de lenguaje casi siempre es la compra equivocada, ¿por qué hacer fine-tuning de un modelo de imagen casi siempre es la correcta?

Cada precio, umbral y multiplicador de este capítulo se leyó en la propia página del proveedor el 7 de septiembre de 2026 y se cita con esa fecha, porque todos se moverán. Las cifras medidas —recuentos de tokens, tamaños de chunk, tamaños de recuperación, training loss, puntuaciones, latencias y recuentos del historial de versiones— se produjeron en una máquina ese mismo día y son reproducibles a partir del corpus descrito arriba.

Los experimentos locales usaron Qwen/Qwen2.5-0.5B-Instruct con greedy decoding, así que se reproducen exactamente; el adaptador es la clase de doce líneas impresa arriba, con rango 8 sobre q_proj y v_proj. El corpus es la documentación Markdown versionada de un repositorio de software en activo, excluyendo dos logs append-only, y su tasa de cambio se contó a partir del historial de versiones de ese repositorio.