Un modelo de lenguaje grande (LLM) sabe mucho, pero no conoce tu empresa, tu producto ni las noticias de la semana pasada. También puede divagar, ignorar tu formato o inventar datos. Hay tres soluciones habituales, y resuelven problemas distintos.

Primero, encuentra el problema real

Antes de elegir un método, pregunta qué falla realmente:

• ¿A la respuesta le faltan datos, como tus políticas o los datos del producto? Es un problema de conocimiento.
• ¿La respuesta tiene el estilo o formato equivocado? Es un problema de comportamiento.
• ¿El modelo malinterpreta la tarea? Es un problema de instrucciones.

Prompt engineering

El prompt engineering consiste en escribir mejores instrucciones. No cambias el modelo. Cambias lo que le dices.

• Indica el rol, el objetivo y las reglas con claridad.
• Muestra dos o tres ejemplos de una buena respuesta (few-shot prompting).
• Pide un formato de salida fijo, como JSON.
• Pide al modelo que diga “no lo sé” cuando no esté seguro.

Ideal para: empezar rápido, tareas simples y corregir problemas de formato. Límite: no puede añadir conocimiento que el modelo no tiene, y los prompts largos cuestan más por solicitud.

RAG (Retrieval-Augmented Generation)

El RAG busca primero la información relevante y luego se la da al modelo junto con la pregunta. El modelo responde usando ese contexto actualizado.

1. Divide tus documentos en fragmentos pequeños.
2. Convierte cada fragmento en un embedding, una lista de números que captura su significado.
3. Guárdalos en una base de datos vectorial.
4. Cuando un usuario hace una pregunta, encuentra los fragmentos más parecidos.
5. Envía esos fragmentos y la pregunta al modelo.

Aprende cómo funciona la parte de la búsqueda en nuestra guía de bases de datos vectoriales.

Ideal para: documentos de la empresa, centros de ayuda, catálogos de productos y todo lo que cambia a menudo. También puede mostrar las fuentes, lo que genera confianza. Límite: la calidad depende de una buena fragmentación y búsqueda. Si la búsqueda devuelve el fragmento equivocado, la respuesta también será errónea.

Fine-tuning

El fine-tuning entrena aún más un modelo existente con tus propios ejemplos, para que aprenda un estilo, un formato o una habilidad concreta.

• Necesitas un conjunto limpio de buenos ejemplos de entradas y salidas, a menudo cientos o miles.
• El modelo cambia, así que debes reentrenar cuando cambie el modelo base o tus necesidades.
• No es una buena forma de enseñar datos cambiantes. El modelo aún puede olvidarlos o confundirlos.

Ideal para: una voz de marca constante, formatos de salida estrictos, tareas de clasificación y prompts más cortos a escala. Límite: mayor coste, más esfuerzo y más lento de cambiar.

Comparación lado a lado

Cómo decidir: un camino sencillo

1. Empieza con prompts. Mejora las instrucciones y añade ejemplos. Mide el resultado.
2. ¿Necesitas datos privados o recientes? Añade RAG.
3. ¿Sigue fallando el estilo o el formato, o los prompts son demasiado largos? Plantéate el fine-tuning.
4. ¿Necesitas conocimiento y estilo? Combina RAG con un prompt, o con un modelo ajustado.

Combínalos en aplicaciones reales

La mayoría de los sistemas en producción mezclan los tres. Un bot de soporte puede usar un prompt de sistema cuidadoso, RAG para obtener las páginas de políticas y un pequeño modelo ajustado para mantener el tono de la marca. Si tu bot además realiza acciones, lee nuestras buenas prácticas de agentes de IA. Para programar con IA, consulta vibe coding en 2026.

Errores comunes

• Hacer fine-tuning para añadir datos que cambian a menudo. Usa RAG en su lugar.
• Saltarse la evaluación. Crea un conjunto de pruebas con preguntas reales y puntúa las respuestas.
• Meter demasiado texto en el prompt. Más no siempre es mejor.
• Ignorar la calidad de la recuperación. Revisa qué fragmentos devuelve la búsqueda.

Evaluar la salida de una IA se parece mucho a probar software. Consulta la automatización de pruebas con IA para ideas relacionadas.

Preguntas frecuentes

Sigue aprendiendo