Fine-tuning frente a RAG: cuándo utilizar cada uno

El debate en torno a fine-tuning frente a RAG suele estar contaminado por la parcialidad de los proveedores y la incomprensión de las compensaciones técnicas. Si está desarrollando aplicaciones de LLM en producción, no puede permitirse el lujo de equivocarse en esta decisión de diseño. Elegir el camino incorrecto significa desperdiciar ciclos de GPU, trabajar con datos desactualizados y obtener sistemas propensos a alucinaciones.

Este artículo elimina el ruido teórico. Analizaremos el espacio del problema exacto, examinaremos la arquitectura tanto de Retrieval-Augmented Generation (RAG) como del ajuste del modelo (fine-tuning), y le daremos un marco claro para decidir cuándo utilizar cada uno.

El problema

Los Large Language Models (LLMs) están congelados en el tiempo. Un modelo entrenado en 2024 no sabe nada sobre la base de código propietaria que su equipo escribió ayer, ni comprende las actualizaciones en tiempo real del esquema de la API enviadas hace una hora. Cuando le pide a un modelo fundacional que razone sobre documentos internos o datos empresariales privados, alucinará con total confianza o se negará a responder.

Tiene datos específicos de su dominio. Necesita que el LLM los use. Ese es el problema fundamental.

Por qué es difícil

Cerrar la brecha entre los pesos estáticos de un LLM y los datos privados y dinámicos presenta grandes desafíos de ingeniería. No puede simplemente volcar un PDF de 50MB en la ventana de contexto de un prompt; incluso con modelos que admiten ventanas de más de un millón de tokens (1M+), los contextos largos sufren el fenómeno de "perdido en el medio" (lost in the middle), latencia masiva y costos exorbitantes por token.

Si decide actualizar los pesos del modelo (fine-tuning), entra en el caótico ámbito del entrenamiento distribuido, la curación de conjuntos de datos y el olvido catastrófico (catastrophic forgetting). Los pipelines de entrenamiento se rompen, los formatos de datos requieren una estandarización rigurosa y evaluar si un modelo ajustado realmente mejoró requiere costosos marcos de evaluación manual.

Arquitectura: RAG frente a Fine-Tuning

Retrieval-Augmented Generation (RAG)

RAG no modifica los pesos del LLM. En su lugar, altera el prompt dinámicamente en el momento de la inferencia. Usted convierte sus datos propietarios en vectores de alta dimensión, los almacena en una base de datos vectorial y realiza búsquedas de similitud semántica cuando llega una consulta. Los documentos recuperados se inyectan entonces en el contexto del prompt.

RAG es un problema de recuperación de datos disfrazado de un problema de IA. La arquitectura suele verse así:

1. Pipeline de ingesta de datos (extracción de texto de PDFs, Confluence, etc.)
2. Estrategia de fragmentación (división del texto en bloques de 512 a 1024 tokens)
3. Modelo de embeddings (por ejemplo, text-embedding-3-small)
4. Almacén de vectores (por ejemplo, Pinecone, Qdrant, pgvector)
5. Modelo de generación (por ejemplo, GPT-4, Claude 3 Opus)

Fine-Tuning (Ajuste Fino)

El fine-tuning altera permanentemente los pesos de la red neuronal. Toma un modelo preentrenado (como Llama-3-8B) y lo entrena más en un conjunto de datos curado de pares de prompt-completación. Esto integra el conocimiento o comportamiento directamente en los parámetros del modelo.

Arquitectura para Fine-Tuning (específicamente LoRA/QLoRA):

1. Preparación del dataset (formato JSONL de instrucciones y respuestas)
2. Selección del modelo base
3. Adaptadores de Parameter-Efficient Fine-Tuning (PEFT)
4. Clúster de entrenamiento distribuido
5. Bucles de evaluación
6. Servidor de inferencia con adaptadores fusionados

Fine-tuning frente a RAG: el desglose de criterios

Utilice RAG cuando necesite que el modelo conozca hechos. Utilice fine-tuning cuando necesite que el modelo aprenda un formato, tono o comportamiento.

No ajuste un modelo para memorizar la política de recursos humanos de su empresa. Olvidará detalles, alucinará números y requerirá un reentrenamiento completo cuando la política cambie. Utilice RAG para esto.

No use RAG para enseñar a un modelo cómo generar esquemas JSON propietarios altamente específicos y complejos, o para escribir código en un DSL interno profundamente personalizado. La ventana de contexto se saturará con ejemplos few-shot y la latencia arruinará la experiencia de su aplicación. Ajuste el modelo (fine-tune) para esto.

Implementación

Construcción del pipeline de RAG

Para RAG, utilizaremos Python 3.11, LlamaIndex 0.10.x y Qdrant.

# requirements.txt
# llama-index==0.10.15
# llama-index-vector-stores-qdrant==0.1.2
# qdrant-client==1.7.3
 
import qdrant_client
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext
from llama_index.vector_stores.qdrant import QdrantVectorStore
 
# 1. Inicializar el almacén de vectores
client = qdrant_client.QdrantClient(location=":memory:")
vector_store = QdrantVectorStore(client=client, collection_name="internal_docs")
storage_context = StorageContext.from_defaults(vector_store=vector_store)
 
# 2. Cargar documentos
documents = SimpleDirectoryReader("./data").load_data()
 
# 3. Construir el índice
index = VectorStoreIndex.from_documents(
    documents,
    storage_context=storage_context,
)
 
# 4. Consultar
query_engine = index.as_query_engine()
response = query_engine.query("What is the new API rate limit?")
print(response)

Construcción del pipeline de Fine-Tuning

Para el fine-tuning, utilizamos Unsloth 2024.4 para un entrenamiento 2 veces más rápido y un menor uso de VRAM.

# requirements.txt
# unsloth[cu121-ampere] @ git+https://github.com/unslothai/unsloth.git
# trl==0.8.1
 
from unsloth import FastLanguageModel
from trl import SFTTrainer
from transformers import TrainingArguments
from datasets import load_dataset
 
# 1. Cargar el modelo base y los adaptadores LoRA
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name = "unsloth/llama-3-8b-bnb-4bit",
    max_seq_length = 2048,
    load_in_4bit = True,
)
 
model = FastLanguageModel.get_peft_model(
    model,
    r = 16,
    target_modules = ["q_proj", "k_proj", "v_proj", "o_proj"],
    lora_alpha = 16,
    lora_dropout = 0, 
    bias = "none",
    use_gradient_checkpointing = "unsloth",
)
 
# 2. Preparar el conjunto de datos
dataset = load_dataset("json", data_files="internal_dsl_dataset.jsonl", split="train")
 
def format_prompts(examples):
    instructions = examples["instruction"]
    outputs      = examples["output"]
    texts = []
    for instruction, output in zip(instructions, outputs):
        text = f"Instruction: {instruction}\nOutput: {output}<|end_of_text|>"
        texts.append(text)
    return { "text" : texts }
 
dataset = dataset.map(format_prompts, batched = True)
 
# 3. Entrenar
trainer = SFTTrainer(
    model = model,
    tokenizer = tokenizer,
    train_dataset = dataset,
    dataset_text_field = "text",
    max_seq_length = 2048,
    args = TrainingArguments(
        per_device_train_batch_size = 2,
        gradient_accumulation_steps = 4,
        max_steps = 60,
        learning_rate = 2e-4,
        fp16 = not torch.cuda.is_bf16_supported(),
        bf16 = torch.cuda.is_bf16_supported(),
        logging_steps = 1,
        output_dir = "outputs",
    ),
)
 
trainer.train()

Errores (Pitfalls)

Errores en RAG

1. Fragmentación ciega (Blind Chunking): Cortar el texto indiscriminadamente cada 512 tokens divide oraciones por la mitad y destruye el significado semántico. Debe usar fragmentación semántica (semantic chunking) o división recursiva de caracteres.
2. Ignorar los metadatos: La búsqueda por similitud vectorial es intrínsecamente ciega. Si busca "Q3 revenue", el embedding podría recuperar un documento de 2021 porque se ve matemáticamente similar. Filtre siempre por metadatos (fecha, autor, categoría) antes de realizar la búsqueda vectorial.
3. Perdido en el medio (Lost in the Middle): Introducir 20 documentos recuperados en la ventana de contexto a menudo hace que el LLM ignore los documentos del centro. Reordene sus documentos recuperados (utilizando herramientas como Cohere Rerank) para colocar los elementos más relevantes al principio y al final de la ventana de contexto.

Errores en Fine-Tuning

1. Basura entra, basura sale (Garbage In, Garbage Out): El fine-tuning amplifica la calidad de su conjunto de datos. Si sus datos de entrenamiento contienen errores de formato, alucinaciones o contradicciones, su modelo ajustado reproducirá agresivamente esos mismos errores.
2. Sobreajuste (Overfitting): Entrenar durante demasiadas épocas en un conjunto de datos pequeño destruirá las capacidades generales de razonamiento del modelo. Aprenderá a recitar los datos de entrenamiento palabra por palabra pero fallará espectacularmente ante nuevas entradas.
3. Olvido catastrófico (Catastrophic Forgetting): A medida que el modelo aprende su tarea específica, inevitablemente olvidará otra información. Un modelo ajustado intensamente para escribir consultas SQL podría volverse de repente deficiente para escribir Python o resumir texto.

Resultado

Deje de tratar el fine-tuning y RAG como una decisión de uno u otro. Resuelven problemas diferentes.

RAG proporciona contexto externo. Fine-tuning proporciona comportamiento interno.

Si su aplicación requiere razonar sobre bases de conocimientos dinámicas y privadas, construya un pipeline de RAG robusto. Si su aplicación requiere que el modelo genere de forma consistente estructuras complejas, hable con una voz de marca hiperespecífica o funcione de manera eficiente en modelos de código abierto más pequeños y económicos, debe realizar un fine-tuning.

Las arquitecturas empresariales más avanzadas utilizan ambos. Ajustan un modelo pequeño y económico (como Llama 3 8B) para comprender perfectamente su esquema de salida JSON específico y las intenciones del usuario, y luego conectan ese modelo ajustado a un pipeline de RAG masivo para recuperar los hechos reales requeridos para rellenar ese esquema.

Tome la decisión arquitectónica basada en la velocidad de sus datos y sus requisitos de salida, no en la última moda de Twitter. Construya con determinación, evalúe sin descanso y comprenda la mecánica central de su pila tecnológica.