El prompt aumentado: cómo se construye el contexto

Sexta entrega de la serie. Entre la recuperación y la respuesta hay un paso que casi nadie documenta y que decide una parte considerable de la calidad final: cómo se empaquetan los fragmentos recuperados en un texto que el modelo va a leer. Aquí está la anatomía de ese paquete.

Qué es el aumento del prompt

El modelo generador no recibe una lista de fragmentos ni una estructura de datos. Recibe texto. Todo lo que ha hecho el sistema de recuperación —vectorizar, buscar, filtrar, reordenar— termina convertido en una cadena de caracteres que se concatena con la pregunta del usuario y con las instrucciones. Ese ensamblaje es el aumento del prompt, y es la última oportunidad de arruinar una recuperación correcta.

Se subestima porque parece trivial: unir fragmentos con saltos de línea y añadir «responde a esto». Y funciona lo bastante como para pasar una demo. Los problemas aparecen después, cuando los fragmentos son diez en lugar de tres, cuando dos dicen cosas distintas, cuando el usuario pregunta algo que no está en ninguno, o cuando el conjunto no cabe.

Anatomía de la plantilla

Una plantilla de RAG en producción tiene seis partes, y el orden en que aparecen no es indiferente.

1. Rol y alcance. Qué es el asistente y sobre qué responde. Sirve para acotar el registro y para rechazar de entrada lo que queda fuera del dominio.
2. Instrucción de fidelidad. La orden de responder exclusivamente con el material aportado. Es el corazón del asunto y merece apartado propio.
3. Formato de salida. Cómo debe estructurarse la respuesta y, sobre todo, cómo debe citar.
4. Los fragmentos, cada uno delimitado y con su identificador.
5. Historial de conversación, si el sistema es conversacional, resumido o recortado.
6. La pregunta del usuario, al final.

Una plantilla concreta, del tipo que se usa realmente:

=== SISTEMA ===
Eres el asistente documental de [ORGANIZACIÓN]. Respondes preguntas
sobre la documentación interna que se te proporciona en cada consulta.

REGLAS DE RESPUESTA
1. Responde ÚNICAMENTE con información contenida en los fragmentos
   delimitados por <fragmento> que aparecen más abajo.
2. No uses conocimiento propio ni completes con lo que te parezca
   razonable. Si un dato no está en los fragmentos, no está.
3. Si los fragmentos no contienen información suficiente para
   responder, escribe exactamente: "No dispongo de información
   suficiente para responder a esa pregunta." y, si procede, indica
   qué información concreta faltaría.
4. Si dos fragmentos se contradicen, dilo explícitamente, expón
   ambas versiones y cita las dos fuentes. No elijas por tu cuenta.
5. Cita la fuente de cada afirmación con su identificador entre
   corchetes, así: [F3]. Una afirmación sin cita es un error.
6. No inventes identificadores de fragmento. Usa sólo los que
   aparecen abajo.

=== FRAGMENTOS ===
<fragmento id="F1" fuente="politica-devoluciones-v4.pdf"
           seccion="3.2 Plazos" fecha="2025-11-03">
El cliente dispone de un plazo de catorce días naturales desde la
recepción del pedido para comunicar su voluntad de desistimiento,
sin necesidad de justificar la decisión.
</fragmento>

<fragmento id="F2" fuente="politica-devoluciones-v4.pdf"
           seccion="3.5 Reembolsos" fecha="2025-11-03">
Una vez recibida la mercancía en almacén, el reembolso se emite
en un plazo máximo de siete días hábiles por el mismo medio de
pago utilizado en la compra.
</fragmento>

<fragmento id="F3" fuente="faq-atencion-cliente.md"
           seccion="Devoluciones" fecha="2025-06-18">
Los artículos personalizados quedan excluidos del derecho de
desistimiento salvo defecto de fabricación.
</fragmento>

=== PREGUNTA ===
Compré una taza con mi nombre grabado hace diez días. ¿Puedo
devolverla y cuándo me devuelven el dinero?

Merece la pena fijarse en tres detalles de esta plantilla. Los fragmentos van delimitados por etiquetas, no separados por líneas en blanco: el modelo distingue con claridad dónde empieza y acaba cada uno, y eso reduce las citas cruzadas. Cada uno lleva metadatos visibles —fuente, sección y fecha— que el modelo puede usar para resolver conflictos y para citar con precisión. Y la regla 3 fija literalmente el texto de la respuesta cuando no hay información, lo que permite detectar ese caso con una comparación de cadenas en lugar de con un clasificador.

La instrucción de fidelidad

Es la línea que convierte al modelo de recitador en lector. Sin ella, el modelo mezcla lo que ha leído con lo que recuerda de su entrenamiento, y no queda forma de saber de dónde salió cada frase. Con ella, la respuesta se puede auditar contra los fragmentos.

Tres matices que marcan diferencia. El primero: la instrucción debe ser positiva y concreta además de prohibitiva. «No inventes» funciona peor que «si el dato no está en los fragmentos, di que no está». El segundo: hay que dar salida al caso negativo. Un modelo al que se le prohíbe inventar pero no se le indica qué hacer cuando no sabe tiende a improvisar una respuesta evasiva pero afirmativa. El tercero: conviene prever la contradicción. En cualquier corpus real hay documentos que se pisan, y un modelo sin instrucciones al respecto elegirá uno en silencio, normalmente el primero que leyó.

Y una advertencia: la instrucción de fidelidad reduce mucho las alucinaciones, no las elimina. Los modelos difieren bastante en su disposición a decir que no saben, y ninguno lo hace siempre. Es un control, no una garantía.

El orden de los fragmentos y el «perdido en el medio»

Los modelos de lenguaje no atienden de forma uniforme a todo su contexto. Lo que está al principio y lo que está al final se recupera mejor que lo que está en el centro. Es un efecto documentado, se le conoce como lost in the middle, y afecta a modelos de todos los tamaños, incluidos los de ventana muy larga. Cuanto más largo es el contexto, más pronunciado.

La consecuencia operativa es que colocar los fragmentos en orden decreciente de relevancia —lo natural, que es como salen del recuperador— es precisamente lo peor: el segundo y el tercer mejor fragmento acaban enterrados en la zona de peor atención.

La colocación que suele funcionar mejor es en forma de uve: el mejor fragmento al principio, el segundo mejor al final, y los peores hacia el centro. Muchas librerías lo implementan bajo el nombre de reordenación por relevancia perdida.

Dicho esto, hay una solución más eficaz y menos ingeniosa: meter menos fragmentos. El efecto es proporcional a la longitud del contexto, así que con cinco fragmentos bien elegidos apenas se nota. Reordenar es un parche para cuando hay que meter veinte; si estás metiendo veinte, la pregunta previa es por qué la recuperación no consigue distinguir los cinco buenos.

Deduplicación

Los corpus reales repiten. La misma cláusula aparece en tres versiones del contrato, el mismo párrafo está en el manual y en el resumen ejecutivo, y el solapamiento entre fragmentos consecutivos hace que dos vecinos compartan literalmente la mitad de su texto. Si los cinco fragmentos recuperados son cinco variantes de lo mismo, se ha gastado todo el presupuesto de contexto en una sola idea.

Hay tres niveles de defensa, de menos a más coste. El primero es descartar duplicados exactos por huella del texto normalizado, que es barato y resuelve más casos de los que parece. El segundo es descartar fragmentos casi idénticos comparando sus vectores: si dos superan un umbral alto de similitud entre sí, se conserva el mejor puntuado. El tercero es la selección con diversidad, donde cada fragmento se puntúa combinando su relevancia para la consulta y su disimilitud respecto a los ya elegidos; es la idea detrás de la relevancia marginal máxima, y tiene un parámetro que gradúa cuánto se prioriza cubrir aspectos distintos frente a repetir el más relevante.

Un caso que la deduplicación no cubre y conviene tratar aparte: las versiones. Dos fragmentos casi idénticos donde uno es de la política vigente y otro de la derogada no son duplicados, son un conflicto. Aquí no se deduplica: se filtra por metadatos antes de buscar, o se le da al modelo la fecha de cada fragmento y la instrucción de preferir el más reciente diciéndolo.

Presupuesto de tokens

El contexto tiene un límite y hay que repartirlo con criterio. Un reparto de partida razonable: instrucciones y formato, unos cientos de tokens fijos; historial de conversación, si lo hay, limitado a los últimos turnos o a un resumen; fragmentos, la mayor parte; y una reserva para la respuesta, que también consume ventana en muchos modelos.

Dos reglas prácticas. La primera: nunca truncar un fragmento por la mitad. Si el siguiente no cabe entero, se descarta entero. Un fragmento cortado a mitad de frase puede contener la primera parte de una condición sin la excepción que la anula, y eso produce respuestas peores que no incluirlo. La segunda: dejar margen. Contar tokens con el tokenizador del modelo, no estimarlos con una regla de tres sobre los caracteres, porque en español las estimaciones se quedan cortas con más frecuencia de la que se cree.

Y una observación de coste que se olvida: el prompt entero se paga en cada consulta. Pasar de cinco fragmentos a quince multiplica por tres el coste de entrada de todas las preguntas del sistema, incluidas las que se resolvían perfectamente con el primero.

Citas que se puedan verificar

Pedir citas es fácil; conseguir que sirvan requiere dos cosas. La primera, dar al modelo identificadores cortos y estables que aparezcan literalmente junto a cada fragmento: [F3] se copia bien, un nombre de archivo largo se copia mal y se inventa con facilidad. La segunda, validar la cita en el código, no confiar en ella: extraer los identificadores de la respuesta y comprobar que todos estaban entre los enviados. Una cita a un fragmento inexistente es una señal fiable de que el modelo se ha salido del contexto, y detectarla cuesta una expresión regular.

La validación fuerte —comprobar que la afirmación se sostiene en el fragmento citado, y no sólo que el identificador existe— es un problema distinto y más caro, que se trata en la parte de evaluación de la serie.

Cuando no hay contexto suficiente

Es el caso que más se descuida y el que más daño hace, porque el sistema siempre devuelve algo. Si la respuesta no está en el corpus, la búsqueda devuelve igualmente los cinco fragmentos menos malos, con puntuaciones de aspecto respetable, y el modelo redacta encima de ellos.

La defensa tiene tres capas. Un umbral de similitud por debajo del cual un fragmento no entra en el prompt, calibrado contra preguntas reales y no fijado a ojo. Una ruta explícita para el conjunto vacío: si no queda ningún fragmento por encima del umbral, no se llama al modelo, se responde directamente que no hay información. Y la instrucción literal de la plantilla para el caso intermedio, en el que hay fragmentos del tema pero no la respuesta.

Que el sistema diga «no lo sé» con cierta frecuencia no es un fallo: es la prueba de que las demás respuestas significan algo. Un RAG que nunca se abstiene es un RAG que no distingue entre saber y no saber, que era justamente el problema del que partimos en la primera entrega.

Qué viene ahora

La siguiente entrega cierra el bloque de fundamentos poniendo RAG frente a sus dos alternativas reales: el ajuste fino del modelo y las ventanas de contexto largo. Qué hace cada uno, una tabla de decisión por frescura del dato, coste, latencia, trazabilidad, escala y control de acceso, y por qué en la práctica los sistemas maduros no eligen uno sino que los combinan.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.