La Clave de los Agentes RAG es el PROMPT

En este artículo te voy a enseñar por qué, después de crear una saga completa de vídeos sobre agentes RAG, he llegado a la conclusión de que el prompt es la pieza más importante. ¿Por qué te digo esto? Pues porque mucha gente se centra en la base vectorial o el modelo de lenguaje, pero si no le das instrucciones claras, el agente se va a comportar como le dé la gana.

Yo lo he vivido en primera persona. En mi agente RAG profesional para crear tutoriales sobre N8N, le conecté una memoria RAG con toda la información relevante. Y aquí viene la clave: aunque la arquitectura técnica estaba ahí, el resultado final dependía al 100% de lo que le pusiera en el prompt. Si no lo diseñaba bien, el sistema era un caos. Y créeme, no es magia: es cuestión de saber qué pedirle. De ahí mi conclusión.

¿Por qué el prompt es el cerebro de tu agente RAG?

Todo el mundo habla de arquitecturas complejas, de bases vectoriales y de modelos de última generación. Pero si te paras a pensarlo, ¿de qué sirve tener el mejor motor del mundo si no sabes conducir? Con los agentes RAG pasa exactamente lo mismo.

La técnica de Retrieval-Augmented Generation (RAG) combina la recuperación de información de una base de conocimientos externa con la generación de texto de un modelo de lenguaje. Esa es la teoría. Pero en la práctica, ese «mejorar la precisión» no es automático. Depende de que le digas al modelo exactamente cómo debe comportarse con esa información que le estás dando.

Más allá de la arquitectura técnica

Puedes tener el RAG mejor montado del mercado: un espacio vectorial impecable, un retriever súper rápido, el modelo más potente… Y aun así, si tu prompt es un simple «responde a las preguntas del usuario», lo que vas a conseguir es un agente que te contesta lo que le parece, en el tono que le apetece y con la información que él decide que es relevante.

El problema es que mucha gente se obsesiona con la parte técnica – que si LangChain, que si Pinecone, que si los embeddings – y se olvida de que el modelo de lenguaje necesita contexto. Necesita que le digas: «oye, tú eres esto, tienes estas herramientas y me vas a responder así». Sin eso, estás lanzando un sistema a la aventura.

El problema de la inconsistencia y las ‘alucinaciones’

¿Y qué pasa cuando no das ese contexto? Pues lo que yo llamo «alucinaciones a la carta». El agente se inventa cosas, mezcla información de forma rara, cambia de tono en cada respuesta… En definitiva, se comporta de forma inconsistente.

Y esto no es un fallo del modelo, ojo. Es un fallo de comunicación. Si tú no eres claro con lo que quieres, ¿cómo va a saberlo él? Es como si contratas a un redactor y le dices «escribe algo sobre marketing» sin darle más detalles. Te puede salir cualquier cosa.

La clave está en entender que el prompt no es un simple texto de introducción. Es el manual de instrucciones completo de tu agente. Es lo que va a determinar si tu sistema es útil o es un generador de respuestas aleatorias.

Los 4 pilares que DEBES definir en tu prompt

Después de trastear con esto durante meses, he llegado a una estructura que funciona. No es la única posible, pero sí la que a mí me ha dado mejores resultados. Si quieres que tu agente RAG funcione como tú esperas, tienes que cubrir estos cuatro puntos en el prompt. Sin excepciones.

1. Identidad y rol del agente

Lo primero: ¿quién es? Tienes que definirle una personalidad clara. No vale con «eres un asistente». Tienes que ser específico: «Eres un experto técnico especializado en N8N, con 5 años de experiencia ayudando a usuarios a automatizar sus workflows». O «Eres un agente de soporte para una tienda online, encargado de resolver dudas sobre envíos y devoluciones».

¿Por qué? Porque el modelo necesita un marco de referencia. Si le das un rol concreto, sus respuestas se alinearán con ese conocimiento experto. Si le dejas en el aire, responderá como un «asistente genérico» que sabe de todo y de nada a la vez.

2. Herramientas disponibles y cuándo usarlas

Esto es crítico, y donde más he visto fallar a la gente. Si tu agente tiene acceso a herramientas – como una base de datos vectorial, una API de correo, un calendario – tienes que enumerárselas explícitamente. Y no solo eso: tienes que decirle para qué sirve cada una y cuándo debe usarla.

Por ejemplo: «Tienes acceso a una base de datos vectorial (Pinecone) que contiene toda la documentación de N8N. DEBES usar esta herramienta SIEMPRE que el usuario pregunte sobre funcionalidades, errores o tutoriales de N8N. No inventes respuestas si la información no está en la base de datos».

Así eliminas la ambigüedad. El modelo ya no tiene que adivinar si debe buscar información o inventarla. Tiene una regla clara.

3. Estilo y tono de las respuestas

Aquí es donde se marca la diferencia entre un agente profesional y uno que parece un experimento. ¿Quieres que sea formal o cercano? ¿Breve o detallado? ¿Debe usar tecnicismos o explicar las cosas de forma sencilla?

En mi caso, para el agente de tutoriales de N8N, especifiqué: «Responde en español de España, con un tono didáctico y cercano. Explica los conceptos técnicos de forma clara, como si se lo estuvieras contando a un compañero. Evita el lenguaje demasiado formal o corporativo».

Sin esta instrucción, el agente a veces me respondía en inglés. Otras veces se ponía en modo «manual técnico» con un tono frío. Y en alguna ocasión incluso se me fue al acento argentino, lo cual, sin ser un problema grave, no cuadraba con el público al que me dirijo.

4. Formato de salida específico

¿Qué tiene que devolver exactamente? ¿Texto plano? ¿Una lista? ¿Un JSON estructurado? Esto es especialmente importante si la salida de tu agente va a alimentar otro sistema.

Si solo necesitas que hable con un usuario humano, quizás con indicar el tono y estilo baste. Pero si su respuesta va a ser procesada por otro software – por ejemplo, para enviar un mensaje por Telegram o rellenar un campo en una base de datos – necesitas un formato estricto.

Como bien señalan en los recursos sobre construcción de un RAG chain, se necesitan tres piezas fundamentales: el LLM, el Retriever y un prompt contextualizado que guíe la generación. Ese «guíe» incluye, literalmente, la forma de la respuesta.

Mi caso real: El agente RAG para tutoriales de N8N

Te lo conté en el vídeo, pero quiero profundizar porque es el ejemplo que mejor ilustra todo esto. Yo creé un agente profesional cuyo único trabajo era ayudarme a generar tutoriales sobre N8N, una herramienta de automatización. Tenía toda la documentación oficial, posts de blog y ejemplos de workflows indexados en una memoria RAG (usando Pinecone). La arquitectura técnica era sólida. Pero el agente, tal cual, no servía para nada.

El problema del idioma y el acento

El primer fallo fue no especificar el idioma. Asumí que, como todo el sistema estaba en español y yo le hablaba en español, él respondería en español. Error. A veces me soltaba párrafos en inglés. Otras veces, usaba expresiones o conjugaciones propias del español de Argentina.

¿Es grave? Depende. Para mi caso, donde la audiencia es mayoritariamente de España, sí que generaba una pequeña desconexión. No era profesional. La solución fue tan simple como añadir al prompt: «Responde SIEMPRE en español de España. Utiliza los giros y conjugaciones propias de este variante del español».

Conectar una sola herramienta: Pinecone

Este agente solo tenía una herramienta: consultar la base de datos vectorial. Parece obvio que debería usarla, ¿no? Pues no. Sin una instrucción explícita, el modelo a veces intentaba responder con su conocimiento general sobre N8N (que podía estar desactualizado o ser incompleto) y otras veces sí que buscaba en Pinecone.

Tuve que dejarle claro: «Tienes UNA herramienta disponible: Pinecone. Esta herramienta contiene toda la información actualizada sobre N8N. DEBES usarla para CUALQUIER pregunta relacionada con N8N. No bases tus respuestas en conocimiento previo del modelo».

Por qué el output era texto plano

Aquí viene la parte de integración. Las respuestas del agente no se mostraban directamente a un usuario final. Formaban parte de un workflow más grande en N8N: el agente generaba el texto del tutorial, luego ese texto se formateaba y finalmente se enviaba por Telegram a un grupo de suscriptores.

Por eso, en el prompt especifiqué: «Devuelve ÚNICAMENTE el texto plano del tutorial. No incluyas títulos, introducciones del tipo ‘como experto en N8N te digo…’ o despedidas. Solo el contenido instructivo paso a paso».

Si hubiera necesitado que la salida fuera, por ejemplo, un JSON con los pasos separados y los recursos enlaces, el prompt habría sido completamente distinto. El formato no es un detalle estético; es un requisito funcional.

Cómo usar ChatGPT para iterar y refinar tu prompt (mi método)

Aquí está uno de mis trucos más valiosos, y que casi nadie cuenta. No escribas el prompt de tu agente desde cero. Usa a ChatGPT (o al modelo que prefieras) como compañero de diseño. Te explico mi proceso, paso a paso.

1. No le pidas un prompt genérico

El error más común es escribir: «ChatGPT, crea un prompt para un agente RAG». Eso te dará una plantilla genérica que vale para poco. En su lugar, empieza contándole el contexto real de tu proyecto.

Por ejemplo: «Voy a crear un agente RAG que actúa como soporte técnico para usuarios de N8N. Tiene acceso a una base de datos con toda la documentación. Quiero que sea cercano, que responda solo en español de España y que sus respuestas sean concisas. ¿Qué debería incluir en el prompt para asegurarme de que se comporte así?».

2. Sé específico con las especificaciones

ChatGPT te va a preguntar por detalles. Aprovéchalo. Cuando te diga «¿quieres que use algún formato de salida específico?» o «¿debe tener acceso a otras herramientas además de la base de datos?», responde con el máximo detalle posible.

Cuanta más información le des sobre tu caso concreto, mejor podrá ayudarte a traducir eso a instrucciones claras para el modelo final. Este no es el momento de ser vago.

3. Pídele que te haga preguntas

Mi movimiento favorito. Después de darle el contexto inicial, le digo: «Ahora hazme todas las preguntas que necesites para poder escribir un prompt completo y efectivo». ChatGPT se pone en modo consultor y te va sacando información que quizás ni habías considerado.

¿Debe saludar al usuario? ¿Cómo debe manejar preguntas fuera de tema? ¿Tiene que citar sus fuentes? ¿Debe admitir cuando no sabe algo? Estas preguntas te fuerzan a pensar en escenarios que de otro modo pasarías por alto.

4. Prueba, pivota y ajusta

Una vez tengas el primer borrador del prompt, pruébalo. No esperes a tener el agente completo montado. Usa la Playground de OpenAI, o la interfaz de Claude, o directamente el entorno de desarrollo donde vayas a integrarlo.

Míralo fallar. Fíjate en qué se equivoca. ¿Responde en otro idioma? Añade esa regla al prompt. ¿No usa la herramienta cuando debería? Refuerza la instrucción. ¿El formato de salida no es el que necesitas? Redefínelo.

Este es un proceso iterativo. Créeme, aquí es donde vas a tener que pivotar y hacer cambios y probar unos, probar otros y ver cuál te da mejor resultado. No hay atajos.

El truco definitivo: Forzar el formato de salida con JSON

Llegamos a la artillería pesada. Hay veces en que, por mucho que le pongas reglas de estilo en el prompt, el agente se las salta. Decide que hoy no le apetece seguir tu formato y te devuelve la información de otra manera. Cuando la consistencia es crítica – porque la salida va a otro sistema automatizado – necesitas un método infalible. Y ese método es forzar un esquema JSON de salida.

¿Por qué las reglas de estilo a veces no bastan?

Los modelos de lenguaje son estocásticos, no deterministas. Aunque le digas «responde en este formato», siempre hay una pequeña probabilidad de que decida variarlo. Para un chatbot humano, un pequeño cambio de redacción no es problema. Pero si estás construyendo un pipeline automático donde una aplicación espera recibir un campo llamado "pasos" y el agente un día lo escribe como "instrucciones", todo se rompe.

Es entonces cuando las reglas de estilo son insuficientes. Necesitas una camisa de fuerza.

Cómo definir un esquema JSON de salida

La mayoría de plataformas que te permiten construir agentes (como la API de OpenAI o herramientas como n8n) incluyen la opción de definir un output schema. Básicamente, es un JSON que describe la estructura exacta que debe tener la respuesta.

Por ejemplo, para mi agente de tutoriales, si necesitara una salida estructurada, definiría algo como:

{
  "titulo_tutorial": "string",
  "descripcion_corta": "string",
  "pasos": ["string"],
  "recursos_necesarios": ["string"]
}

Al modelo no solo se le dice «responde así», sino que se le obliga a generar un JSON que valide contra ese esquema. Si no lo hace, la generación falla. Es la forma más robusta de garantizar consistencia.

Usar ChatGPT para generar el esquema automáticamente

¿Y cómo sacas ese esquema? De nuevo, con ChatGPT. Le puedes decir: «Necesito un esquema JSON para la salida de un agente que genera tutoriales. Debe incluir título, descripción, lista de pasos y lista de recursos. Genera el JSON Schema correspondiente».

ChatGPT te lo creará al instante. Luego solo tienes que copiarlo y pegarlo en la configuración de tu agente. Es un paso que te ahorra tiempo y te asegura que la estructura es válida.

Este enfoque es especialmente útil cuando pasas de un RAG básico a sistemas más complejos, como los sistemas Agentic RAG que agregan tres capas además del RAG básico: un planificador, un ejecutor y un crítico. En esos flujos multi-paso, que cada componente espere un formato específico de los anteriores es vital para que todo encaje.

De RAG básico a Agentic RAG: ¿Necesitas un planificador y un crítico?

Con todo lo que te he contado, tu agente RAG básico debería funcionar bastante bien. Pero puede que llegue un punto en el que te preguntes: ¿y ahora qué? ¿Meto más capas de complejidad? ¿Implemento un sistema «agentic»? Vamos a ver cuándo tiene sentido y cuándo es overkill.

Cuándo un RAG simple ya no es suficiente

Un RAG básico es perfecto para preguntas directas que se responden con información de un solo lugar. «¿Cómo se crea un trigger en N8N?» -> Busca en la documentación, encuentra la respuesta, la devuelve.

El problema viene con preguntas complejas, de varios pasos. Por ejemplo: «Analiza mis últimos 5 proyectos de automatización y sugiere mejoras de optimización y coste». Aquí el agente necesita: 1) recuperar los proyectos, 2) analizarlos uno a uno, 3) compararlos con mejores prácticas, 4) calcular impactos de coste, 5) sintetizar recomendaciones.

Un RAG simple se atasca. O te devuelve información cruda sin análisis, o se inventa parte del proceso. Es aquí donde la arquitectura Agentic RAG empieza a cobrar sentido.

Las tres capas de un sistema Agentic RAG

Como explica la guía de Ara Technologies, un sistema Agentic RAG agrega tres capas además del RAG básico: un planificador que divide la consulta, un ejecutor que recupera información y actúa, y un crítico que valida los resultados.

• El planificador recibe la pregunta compleja y la desglosa en subtareas secuenciales. «Para sugerir mejoras, primero necesito los proyectos, luego analizar cada uno, después…»
• El ejecutor se encarga de cada subtarea. Usa las herramientas (RAG, APIs, cálculos) para completarlas.
• El crítico revisa los resultados parciales y finales. ¿Son coherentes? ¿Se basan en la información recuperada? ¿Cumplen el objetivo inicial?

Es como tener un project manager, un técnico y un auditor dentro de tu agente.

¿Merece la pena la complejidad añadida?

Aquí va mi opinión sincera: para la mayoría de los casos, no. Un RAG bien diseñado, con un prompt robusto que anticipe preguntas complejas y guíe al modelo paso a paso, puede manejar mucha más complejidad de la que crees.

La arquitectura Agentic RAG introduce más puntos de fallo, más latencia (por los múltiples ciclos de planificación-ejecución-crítica) y, sobre todo, mucha más complejidad en el desarrollo y mantenimiento.

Solo deberías considerarla si: 1. Tus preguntas son inherentemente multi-paso y cada paso requiere herramientas diferentes. 2. La precisión es tan crítica que necesitas un mecanismo de validación automática (el crítico). 3. El volumen de consultas justifica la inversión en desarrollar y mantener un sistema tan complejo.

Para mi agente de tutoriales de N8N, un RAG básico con un prompt bien hecho era más que suficiente. Incluso para preguntas como «crea un tutorial que compare el nodo HTTP Request con el Webhook», el prompt podía guiar al modelo para que primero busque información sobre cada nodo y luego la sintetice en una comparación. Sin necesidad de capas adicionales.

Conclusión: Construye tu agente como un puzle, donde el prompt es la pieza clave

Al final, crear un agente RAG que funcione es como montar un puzle. Tienes piezas técnicas (el modelo, el retriever, la base vectorial) y piezas de diseño (el prompt, el flujo de conversación, el formato de salida). Y de todas ellas, la que más influye en el resultado final es el prompt.

Es la pieza que conecta todo. Le dice al modelo qué hacer con las herramientas que le has dado, cómo interpretar la información que recupera y cómo presentarte el resultado. Sin un buen prompt, las mejores piezas técnicas se desperdician.

Así que mi recomendación es clara: invierte tiempo en diseñar, iterar y refinar tu prompt. Usa ChatGPT como aliado, sé hiper-específico con las instrucciones y no temas forzar formatos de salida cuando la consistencia sea clave. Y solo salta a arquitecturas más complejas como Agentic RAG cuando de verdad hayas exprimido las posibilidades de un RAG bien afinado.

Si quieres ver todo esto en acción, con el código y los flujos reales, échale un vistazo a la saga completa de vídeos donde lo fui construyendo paso a paso. Y si te ha quedado alguna duda o quieres que te eche un cable con tu propio agente, me puedes escribir directamente. Ya sabes dónde encontrarme.