RAG, web search, fine-tuning o reglas: como elegir para un sistema con LLMs

Guia para elegir entre RAG, busqueda web, fine-tuning y reglas deterministas al construir asistentes y automatizaciones con LLMs.

Cuando un asistente de IA responde mal, una reaccion habitual es pensar que necesita un modelo mas potente. Muchas veces, el problema real esta en otro sitio: el sistema no dispone del conocimiento correcto, utiliza informacion desactualizada o intenta dejar al LLM una decision que deberia estar definida mediante reglas.

RAG, web search, fine-tuning y logica determinista resuelven problemas diferentes. Elegir bien entre estas opciones suele aportar mas que cambiar de proveedor o escribir un prompt mucho mas largo.

Respuesta directa: cuando elegir cada enfoque

Usaria RAG cuando el asistente debe consultar documentos privados o conocimiento interno que cambia con el tiempo.
Usaria web search cuando necesita informacion publica, reciente y verificable mediante fuentes.
Usaria fine-tuning cuando quiero modificar de forma consistente el comportamiento, formato o estilo del modelo a partir de muchos ejemplos de calidad.
Usaria reglas deterministas cuando una decision debe ser predecible, auditable y cumplirse siempre.
Combinaria varias tecnicas cuando el sistema necesita conocimiento, razonamiento y acciones reales.

Necesidad	Primera opcion
Responder sobre manuales internos	RAG
Investigar noticias o datos publicos recientes	Web search
Repetir un formato especializado con consistencia	Fine-tuning
Validar permisos, limites o condiciones de negocio	Reglas
Ejecutar un proceso empresarial completo	Arquitectura hibrida

La pregunta importante no es "que tecnica es mejor", sino que parte del problema intenta resolver cada una.

Antes de elegir: separar conocimiento, comportamiento y decisiones

Muchos proyectos de IA mezclan tres necesidades:

Conocimiento: que informacion necesita el modelo para responder.
Comportamiento: como debe interpretar y redactar.
Decision: que acciones estan permitidas y bajo que condiciones.

RAG y web search aportan principalmente conocimiento. El fine-tuning modifica principalmente el comportamiento. Las reglas controlan decisiones.

Esta separacion evita pedirle a una sola tecnica cosas para las que no fue disenada. Por ejemplo, entrenar un modelo con una politica interna no garantiza que aplique siempre su ultima version. Si esa politica cambia, probablemente sea mejor recuperarla desde una fuente actual y validar sus condiciones mediante codigo.

Que es RAG y cuando aporta valor

RAG significa Retrieval-Augmented Generation. Antes de generar una respuesta, el sistema busca fragmentos relevantes dentro de una coleccion de documentos y los entrega al LLM como contexto.

Una arquitectura simplificada seria:

Pregunta
    -> busqueda en documentos
        -> fragmentos relevantes
            -> LLM genera una respuesta con contexto

RAG encaja bien para:

manuales internos;
documentacion tecnica;
procedimientos empresariales;
bases de conocimiento;
catalogos y fichas de producto;
contratos o normativa con acceso controlado;
historiales que deben consultarse bajo permisos.

Su ventaja principal es poder actualizar el conocimiento sin reentrenar el modelo. Si cambia un documento, se vuelve a procesar y la siguiente consulta puede recuperar la nueva version.

RAG no es simplemente guardar PDFs en una base vectorial

La calidad depende de muchas decisiones:

que documentos se incluyen;
como se limpian y dividen;
que metadatos se conservan;
como se aplican permisos;
que metodo de busqueda se utiliza;
cuantos fragmentos se recuperan;
como se ordenan y deduplican;
como se citan las fuentes.

Si el recuperador devuelve fragmentos irrelevantes, el LLM respondera con un contexto malo. Antes de evaluar la redaccion final, conviene medir si el sistema encontro la informacion correcta.

Cuando utilizar web search

La busqueda web es adecuada cuando el conocimiento necesario es publico, externo y puede haber cambiado recientemente. Algunos ejemplos:

noticias;
webs corporativas;
informacion de mercado;
documentacion publica actualizada;
publicaciones academicas;
registros y fuentes oficiales;
investigacion OSINT.

A diferencia de un RAG interno, la web no es una coleccion controlada. Las fuentes pueden ser contradictorias, estar desactualizadas o intentar manipular al agente. Por eso, el resultado debe conservar enlaces, fechas, evidencia y nivel de confianza.

En mi guia sobre OSINT con LLMs y web search explico este principio con mas detalle: el modelo puede acelerar la investigacion, pero cada conclusion importante debe poder volver a su fuente.

RAG y web search no son opuestos

Un asistente empresarial puede utilizar ambos:

RAG para consultar politicas y documentos privados;
web search para obtener contexto publico reciente;
reglas para decidir que fuentes o acciones estan permitidas.

Lo importante es que la respuesta distinga claramente que procede de conocimiento interno y que procede de una fuente externa.

Cuando tiene sentido el fine-tuning

El fine-tuning ajusta un modelo mediante ejemplos para que reproduzca mejor un comportamiento determinado. Puede ser util cuando existen muchos pares de entrada y salida de alta calidad y el objetivo es consistente.

Lo consideraria para:

clasificaciones especializadas y repetitivas;
formatos de salida muy concretos;
estilo o tono estable;
vocabulario de dominio;
tareas donde un modelo pequeno ajustado puede sustituir a uno general mas costoso;
comportamientos que ya han demostrado funcionar mediante prompting.

No lo utilizaria como primera solucion para mantener datos actualizados. El conocimiento incorporado durante el entrenamiento no es una base de datos facil de editar, citar o borrar.

Tambien requiere un conjunto de ejemplos realmente bueno. Ajustar con datos inconsistentes solo hace que el modelo repita inconsistencias con mayor confianza.

Antes de hacer fine-tuning

Comprobaria primero:

si un prompt claro resuelve el problema;
si una salida estructurada mejora la consistencia;
si faltan ejemplos o contexto;
si la evaluacion actual mide realmente la tarea;
si el volumen justifica preparar datos, entrenar y mantener versiones.

El fine-tuning debe responder a una limitacion medida, no a la sensacion de que el modelo "podria estar mas entrenado".

Cuando las reglas son la mejor herramienta

Las reglas deterministas suelen ser menos llamativas, pero son esenciales. Las usaria cuando una condicion debe cumplirse siempre:

permisos y autorizacion;
limites de gasto;
horarios y capacidad;
campos obligatorios;
calculos;
transiciones de estado;
prevencion de duplicados;
cumplimiento de politicas explicitas.

Un LLM puede interpretar que un usuario quiere cancelar una reserva. Una regla debe comprobar si la reserva existe, pertenece al usuario, puede cancelarse y que consecuencias tiene.

LLM interpreta la intencion
    -> reglas validan condiciones
        -> servicio ejecuta la accion
            -> sistema registra el resultado

Esta division aparece tambien en mi articulo sobre automatizaciones de IA fiables para produccion: la IA aporta flexibilidad, pero las operaciones reales necesitan contratos, estado e idempotencia.

Ejemplo: asistente interno de una empresa

Imaginemos un asistente que ayuda a empleados a resolver dudas y solicitar acciones internas.

RAG

Recupera procedimientos, manuales y preguntas frecuentes segun el departamento y permisos del usuario.

Web search

Consulta documentacion publica de proveedores o informacion externa reciente cuando la politica lo permite.

Fine-tuning

Podria utilizarse si existen miles de ejemplos revisados para clasificar solicitudes internas con una taxonomia muy especifica.

Reglas y servicios

Comprueban identidad, permisos, campos obligatorios y ejecutan las acciones autorizadas.

El resultado no es "un chatbot con RAG". Es un sistema donde cada componente tiene una responsabilidad concreta.

Arquitectura hibrida de referencia

Solicitud del usuario
    -> clasificacion e interpretacion
        -> recuperar documentos internos con RAG
        -> buscar fuentes publicas si es necesario
        -> generar respuesta o proponer herramienta
            -> validar mediante reglas
                -> ejecutar o escalar a una persona

Esta arquitectura permite mantener conocimiento y decisiones separados:

los documentos pueden actualizarse;
las fuentes externas quedan citadas;
el comportamiento del modelo puede evaluarse;
las reglas pueden probarse;
las acciones dejan trazabilidad.

Como evaluaria cada componente

No utilizaria una unica metrica para todo el sistema.

Componente	Preguntas de evaluacion
RAG	¿Recupera el documento correcto? ¿El fragmento contiene la respuesta?
Web search	¿Prioriza buenas fuentes? ¿Las citas respaldan las afirmaciones?
Fine-tuning	¿Mejora la tarea frente al modelo base? ¿Generaliza a ejemplos nuevos?
Reglas	¿Cubren limites y casos extremos? ¿Son consistentes y testeables?
Respuesta final	¿Es correcta, clara, util y honesta sobre sus limites?

Para RAG mediria primero retrieval: precision, cobertura y ranking de fragmentos. Una respuesta incorrecta puede deberse a que el modelo razono mal o a que nunca recibio el documento adecuado.

Para fine-tuning mantendria un conjunto de evaluacion separado de los datos de entrenamiento. Si se evalua con ejemplos ya vistos, el resultado puede parecer excelente sin demostrar capacidad real.

Errores habituales

Utilizar RAG para datos que deberian consultarse mediante una API

Si necesito el saldo actual, el estado de un pedido o la disponibilidad exacta, consultaria el sistema oficial. RAG sirve para conocimiento documental, no para sustituir datos transaccionales.

Utilizar fine-tuning para memorizar informacion cambiante

Actualizar documentos y recuperar su ultima version suele ser mas controlable que volver a entrenar.

Permitir que web search decida sin verificar fuentes

Encontrar una pagina no convierte su contenido en cierto. Las afirmaciones importantes necesitan procedencia y contraste.

Esconder reglas dentro del prompt

Una instruccion como "nunca superes este limite" no sustituye una validacion en codigo cuando el limite tiene impacto real.

Combinar todo antes de medir lo sencillo

Cada componente aumenta coste y complejidad. Empezaria con la arquitectura minima que permita medir el problema y anadiria piezas solo cuando resuelvan una limitacion observada.

Mi criterio final

RAG, web search, fine-tuning y reglas no compiten por hacer exactamente lo mismo:

RAG entrega conocimiento privado y controlado;
web search aporta informacion publica y reciente;
fine-tuning especializa comportamientos repetibles;
las reglas protegen decisiones y acciones.

La arquitectura correcta suele combinar algunas de ellas, pero no necesita utilizarlas todas.

El mejor sistema con LLMs no es el que incorpora mas tecnicas, sino el que sabe donde termina la probabilidad y donde debe empezar la certeza.

Puedes leer tambien mi guia sobre como elegir entre n8n, FastAPI y Spring o revisar los sistemas de IA que he construido para NexaVision AI.

Para hablar sobre agentes, automatizacion y arquitectura de IA, puedes contactar conmigo desde la pagina de contacto.