Fine-tuning es la herramienta más cara y menos usada correctamente en Bedrock. Antes de entrenar un modelo custom, hay dos alternativas más baratas que casi siempre deberían probarse primero.
Amazon Bedrock permite personalizar modelos base mediante dos mecanismos: fine-tuning supervisado (entrenar el modelo sobre pares de prompt-respuesta específicos de su dominio) y continued pre-training (entrenamiento adicional no supervisado sobre un corpus de texto propio, sin pares etiquetados, para que el modelo absorba vocabulario y patrones de un dominio específico). Ambos producen un "custom model" — una versión derivada del modelo base que solo su cuenta puede usar, y que requiere Provisioned Throughput para servir en inferencia; no está disponible en modo on-demand.
Esta última restricción es la que más sorprende a los equipos: un modelo fine-tuned en Bedrock implica un compromiso de capacidad reservada — con su costo fijo mensual — incluso si el volumen de tráfico real es bajo, lo que cambia completamente el cálculo de cuándo vale la pena frente a RAG o prompt engineering.
Antes de invertir en fine-tuning, dos alternativas resuelven la mayoría de los casos a menor costo y complejidad. Prompt engineering con few-shot examples — incluir ejemplos representativos directamente en el prompt — resuelve tareas de formato y estilo consistente sin ningún entrenamiento. RAG vía Knowledge Bases resuelve el problema de "el modelo no conoce mis datos" inyectando contexto relevante en tiempo de consulta, sin necesidad de reentrenar nada cuando los datos cambian.
Fine-tuning solo aporta valor incremental real sobre estas dos alternativas cuando el problema no es de conocimiento factual (eso lo resuelve RAG) sino de comportamiento: el modelo necesita adoptar un estilo de respuesta muy específico y consistente a gran escala, seguir un formato de salida estructurado con una tasa de error casi nula, o razonar sobre un dominio con terminología tan especializada que ni el prompt engineering ni el contexto de RAG logran una precisión aceptable.
El flujo empieza con la preparación del dataset en formato JSONL, con pares de prompt-completion siguiendo el esquema esperado por el modelo base elegido (no todos los modelos en Bedrock soportan fine-tuning — la disponibilidad varía por proveedor y versión). El dataset se sube a S3, y se lanza un job de personalización especificando hiperparámetros como número de épocas, tasa de aprendizaje y tamaño de batch.
Al finalizar el job, el modelo resultante aparece como un `custom-model` en su cuenta, y para invocarlo en inferencia primero debe aprovisionar Provisioned Throughput sobre ese modelo específico — no se puede invocar en modo on-demand.
Continued pre-training tiene sentido cuando el objetivo no es enseñar al modelo a responder de una forma específica, sino a "entender mejor" un dominio de vocabulario denso — por ejemplo, terminología médica especializada, jerga legal de un país específico, o el lenguaje técnico interno de una industria (minería, seguros agrícolas). No requiere pares etiquetados, solo un corpus representativo de texto del dominio, lo que reduce significativamente el costo de preparación de datos frente al fine-tuning supervisado, aunque el proceso de entrenamiento en sí puede requerir más volumen de texto para ser efectivo.
El costo de fine-tuning tiene dos componentes que se subestiman con frecuencia: el costo del job de entrenamiento en sí (cobrado por hora de cómputo de entrenamiento), y el costo recurrente de Provisioned Throughput necesario para servir el modelo resultante en producción — un compromiso mensual que no desaparece si el tráfico baja. Para que el fine-tuning sea económicamente racional, el volumen de inferencia proyectado debe ser lo suficientemente alto y estable como para que el costo de la capacidad reservada se diluya favorablemente frente al costo por token que pagaría usando el modelo base con RAG y prompt engineering optimizado.
Los casos reales donde fine-tuning en Bedrock justifica su costo incluyen: clasificación de alto volumen con un esquema de salida muy específico donde reducir la latencia y el consumo de tokens por invocación —al no necesitar un prompt largo de instrucciones— compensa el costo fijo de Provisioned Throughput; generación de contenido con una voz de marca extremadamente consistente a escala (miles de generaciones diarias) donde el prompt engineering muestra deriva; y dominios altamente especializados donde ni el modelo base ni RAG logran el nivel de precisión terminológica requerido, típicamente verificado primero con Bedrock Model Evaluation antes de comprometerse a entrenar.
La secuencia recomendada para cualquier equipo evaluando fine-tuning es: primero, optimizar el prompt con few-shot examples y medir la calidad resultante; segundo, si el problema es de conocimiento factual, implementar RAG con Knowledge Bases y volver a medir; tercero, solo si persiste una brecha de calidad después de agotar ambas alternativas, y el volumen de tráfico proyectado justifica el costo fijo de Provisioned Throughput, proceder con fine-tuning. Saltarse los dos primeros pasos es la razón más común por la que los proyectos de fine-tuning en la nube terminan costando más de lo que aportan.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel