Hace dos años desplegamos un sistema RAG para una empresa manufacturera que gestiona una extensa biblioteca de directrices técnicas y manuales de servicio. El sistema respondía con fluidez, sonaba seguro de sí mismo y los operarios lo adoptaron rápidamente. El problema llegó en la primera auditoría interna: el ingeniero de seguridad preguntó de qué documento concreto procedía el procedimiento de parada de línea. El sistema respondió — pero nadie en la sala podía verificar si era cierto o una alucinación convincente. La auditoría concluyó con la recomendación de retirar el sistema temporalmente.
Este escenario no es excepcional. Para cualquiera que despliegue RAG en un entorno regulado o con responsabilidad crítica — manufactura, energía, construcción, derecho, sanidad — el grounding (anclar la respuesta en fuentes concretas) y la attribution (asignar la respuesta a una fuente citable) son tan importantes como la propia precisión de la respuesta. Este artículo explica por qué es así, qué técnicas existen y dónde están sus límites.
Por qué las citas no son un detalle de UX
La mayoría de los equipos aborda las citas tarde — como último paso antes de producción, cuando queda claro que "hay que poner alguna referencia". Es un error. El grounding y la attribution son decisiones de arquitectura, no una capa cosmética.
Tres razones por las que importa:
Compliance y auditabilidad. En sectores regulados (normas ISO, REACH, Directiva de Máquinas, documentación médica) todo output que influya en una decisión debe ser rastreable. Un sistema que diga "siga la norma EN ISO 13849" sin enlazar a la sección concreta y la versión del documento no cumple los requisitos del auditor.
Confianza y onboarding. Un operario nuevo que ve la cita "Directiva de Seguridad BS-2024, sección 4.3, página 12" puede verificar la respuesta por sí mismo. Una respuesta sin cita exige confiar ciegamente en el sistema — y la mayoría de los profesionales lo rechaza, con razón.
Diagnóstico de errores. Cuando una respuesta es incorrecta, la cita señala de inmediato dónde falló el pipeline: retrieval cargó el documento equivocado, o la generación no lo citó correctamente. Sin cita, el debugging es mucho más lento. (Más sobre diagnóstico de pipeline en Cómo evaluar RAG: RAGAS, faithfulness, context precision.)
Qué significa exactamente "grounding"
Grounding es una propiedad de la respuesta: cada afirmación en ella está respaldada por un pasaje concreto del contexto recuperado. Lo contrario es una respuesta alucinada o interpolada libremente, generada por el modelo a partir de su conocimiento paramétrico en lugar de los documentos proporcionados.
Attribution es la realización operativa del grounding: asignar un identificador concreto (nombre de archivo, ID de documento, URL, número de página, número de sección) a cada afirmación o a la respuesta completa.
Distinción importante: grounding y attribution son diferentes de la corrección factual. Una respuesta puede estar completamente fundamentada — cada afirmación procede del contexto proporcionado — y aun así ser incorrecta si retrieval cargó un documento erróneo o desactualizado. Faithfulness (consistencia con el contexto) no es lo mismo que accuracy (corrección factual). El framework RAGAS también señala esta diferencia.
Técnicas para lograr el grounding
1. System prompt con prohibición explícita
La técnica más sencilla: en el system prompt se prohíbe explícitamente al modelo responder desde su propio conocimiento y se le ordena citar.
System prompt de ejemplo:
Responde exclusivamente a partir del contexto proporcionado.
Si la respuesta no está en el contexto, di: "No he encontrado esta información en los documentos disponibles."
Cada afirmación preséntala en el formato: [Fuente: {doc_id}, página {page}].
No inventes contenido que no esté en el contexto.Ventajas: sencillo, rápido, coste de infraestructura nulo.
Límites: los modelos no respetan siempre esta regla de forma fiable — especialmente con contextos largos, donde el pasaje relevante se pierde entre otros documentos. El position bias (el modelo presta más atención al inicio o al final del contexto) es un problema real, documentado en todos los modelos frontier.
2. Output estructurado con referencia por afirmación
En lugar de texto libre, se pide al modelo un output estructurado (structured outputs / JSON mode) donde cada afirmación incluye la referencia a la fuente:
{
"answer": "La temperatura máxima de operación es 85 °C.",
"citations": [
{
"claim": "La temperatura máxima de operación es 85 °C.",
"source_id": "manual-v3.2.pdf",
"page": 47,
"section": "4.2 Límites de temperatura",
"quote": "Operating temperature must not exceed 85 °C under continuous load."
}
]
}Este enfoque permite la verificación automática: tras la generación se puede comprobar programáticamente si el quote citado existe realmente en el documento en la página indicada. Si no, la respuesta se marca como no verificable.
Ventajas: la cita es legible por máquina y verificable automáticamente.
Límites: aumenta la longitud del output y los requisitos de context window; en algunos modelos la precisión de las citas disminuye con preguntas más complejas.
3. Verificación post-generación (grounding check)
Un enfoque más robusto separa la generación de la verificación. Tras generar la respuesta se lanza una segunda llamada LLM que recibe tanto el contexto original como la respuesta generada y verifica cada afirmación:
Para cada afirmación de la respuesta indica:
- claim: cita de la afirmación
- supported: true/false
- evidence: pasaje del contexto que respalda la afirmación (o null)El resultado se usa para filtrar: las afirmaciones marcadas como supported: false se eliminan o se señalan con una bandera roja en la UI.
Esta es la base conceptual de la métrica faithfulness en RAGAS — mide qué proporción de las afirmaciones de la respuesta está respaldada por el contexto recuperado.
Ventajas: las citas se verifican de forma independiente, no solo las genera el modelo; reduce significativamente la tasa de afirmaciones no verificables.
Límites: el coste LLM por respuesta se duplica; la latencia aumenta. Para aplicaciones en tiempo real el compromiso habitual es: generación online, verificación asíncrona con flagging en el log.
4. Multi-vector retrieval y grounding a nivel de pasaje
Técnica avanzada: en lugar de cargar documentos completos, retrieval devuelve pasajes concretos con sus identificadores. El modelo recibe no solo el texto sino también los metadatos de cada chunk:
[DOC: safety-manual-v2.pdf | SEC: 4.3 | PAGE: 31 | CHUNK_ID: sm-v2-431]
El equipo no debe arrancarse a temperaturas inferiores a -10 °C...
[DOC: iso-13849-2023.pdf | SEC: 6.1.2 | PAGE: 88 | CHUNK_ID: iso-13849-612]
La categoría de la función de seguridad se determina según...El modelo tiene los identificadores directamente en el contexto y su tarea es mucho más sencilla: al responder solo hace referencia al CHUNK_ID que contiene la información relevante. El backend traduce después el CHUNK_ID en el enlace completo.
Ventajas: el grounding es intrínsecamente más sencillo porque el modelo cita identificadores en lugar de reconstruir la ruta al documento.
Límites: requiere un enriquecimiento metadatado exhaustivo en el pipeline de ingestion; con un chunking deficiente el chunk_id puede ser engañoso. Más sobre ingestion y chunking en Pipeline RAG — 3 ajustes que deciden la calidad.
Dónde falla el grounding a pesar del RAG
RAG reduce significativamente las alucinaciones, pero no las elimina. En la práctica vemos cuatro patrones de fallo que aparecen incluso con un grounding correctamente configurado:
Position bias. Los modelos prestan más atención al inicio y al final de la ventana de contexto. Un pasaje relevante situado en el centro entre decenas de otros documentos puede ignorarse, aunque retrieval lo haya cargado correctamente. Solución: un reranker desplaza los chunks más relevantes al inicio del contexto.
Interpolación a nivel de token. El modelo a veces fusiona información de varios pasajes y genera una afirmación que literalmente no está en ninguno de ellos — aunque cada mitad de la afirmación proceda de un documento distinto. Esta es una forma sutil de alucinación que el grounding check solo detecta si es realmente granular.
Cita de una fuente existente pero no relevante. El modelo puede citar un documento que existe en el contexto pero en el que esa información concreta no aparece. Si solo se hace una comprobación superficial (¿existe la fuente en el contexto?), esto pasa desapercibido. La verificación profunda debe comprobar si el quote citado existe realmente en el documento.
Documento desactualizado en la knowledge base. El grounding es consistente con el contexto — pero si la knowledge base está desfasada, la respuesta será fundamentada y factualmente incorrecta a la vez. Esto no es un fallo del modelo ni del pipeline — es un problema de gestión de la knowledge base. Solución: los documentos deben tener versiones y fechas de vigencia; en la búsqueda hay que filtrar por actualidad.
Grounding en sectores regulados
Para las empresas donde los outputs de sistemas de IA se utilizan en decisiones con implicaciones de seguridad o legales, el grounding técnico no es suficiente — se necesita un registro auditable.
En la práctica esto significa:
- Cada respuesta se almacena con el rastro completo de citas (document ID, versión del documento, número de página, timestamp).
- La knowledge base tiene registros versionados — puedes saber qué versión de la norma estaba vigente el día en que el sistema generó las respuestas.
- Un cambio de documento en la knowledge base invalida las respuestas cacheadas dependientes — nuevo documento, nueva respuesta.
- Las respuestas rechazadas se registran en log — cuando el sistema dice "no he encontrado la información", se guardan tanto la pregunta como el motivo del rechazo.
El EU AI Act, en el contexto de sistemas de IA de alto riesgo (p. ej. sistemas utilizados en seguridad industrial), exige logging, trazabilidad y posibilidad de supervisión humana. El rastro de citas es una de las formas concretas de cumplir estos requisitos. Más sobre las obligaciones de las empresas en EU AI Act — obligaciones de la empresa.
Implementación práctica — por dónde empezar
Si estás construyendo un sistema RAG desde cero o refactorizando uno existente, proponemos una secuencia de tres pasos:
- 1.Empieza con los metadatos en la ingestion. Cada documento al cargarse recibe
doc_id,version,valid_from,section_path. Sin esto, las citas posteriores son solo nombres de archivo sin estructura.
- 1.Incorpora los identificadores en la plantilla de prompt. Retrieval devuelve chunks con metadatos; la plantilla de prompt los formatea en el contexto visible para el modelo. De este modo el modelo tiene los identificadores directamente disponibles.
- 1.Añade un grounding check asíncrono. En la primera iteración no tiene que ser síncrono — basta la verificación asíncrona post-generación; registra el resultado en log y márcalo en el dashboard de monitorización. Añade el grounding check síncrono cuando compliance lo exija explícitamente.
Herramientas que usamos en la práctica: LlamaIndex para el pipeline de retrieval con enriquecimiento de metadatos, Qdrant como base de datos vectorial con filtros de payload (lo que permite filtrar por versión de documento o fecha de vigencia), RAGAS para la medición offline periódica de faithfulness. Para la orquestación de la verificación multi-step, LangGraph.
Preguntas frecuentes
¿Es el grounding lo mismo que la corrección factual de la respuesta?
No. Grounding significa que la respuesta es consistente con el contexto recuperado — cada afirmación procede de los documentos proporcionados. La corrección factual depende también de la calidad de la propia knowledge base. Si en la knowledge base hay un documento desactualizado o incorrecto, la respuesta puede estar completamente fundamentada y ser factualmente errónea al mismo tiempo. Por eso la gestión de la knowledge base (versiones, fechas de vigencia, actualizaciones) es tan importante como el propio pipeline RAG.
¿Qué modelo sigue mejor las instrucciones de citación?
Los modelos frontier (Claude 4 Sonnet/Opus, GPT-4.1, Gemini 2.5 Pro) tienen un instruction following notablemente mejor que los modelos más pequeños. En los modelos open-weight (Llama, Qwen3, Mistral) la fiabilidad en el cumplimiento de instrucciones de citación es menor, especialmente con contextos largos. Para sistemas en producción con requisitos de compliance recomendamos la combinación: modelo más pequeño para la generación + llamada de verificación post-generación. Más sobre selección de modelos en Cómo elegir un modelo LLM en 2026.
¿Ralentiza el grounding check post-generación el tiempo de respuesta del sistema?
Sí — una llamada de verificación síncrona duplica la latencia de la generación. Para UI en tiempo real el compromiso estándar es la verificación asíncrona: la respuesta se muestra de inmediato, la verificación transcurre en segundo plano y el resultado se muestra como badge "verificado / no verificado" o se registra en log para auditoría. Para procesamiento en batch o sistemas de reporting (donde la latencia no es crítica) se prefiere el grounding check síncrono.
¿Cómo saber qué faithfulness tiene nuestro sistema RAG?
El método más sencillo: crea un golden set — una colección de preguntas con respuestas de referencia y documentos — y ejecuta la evaluación con RAGAS. La puntuación de faithfulness te indica qué proporción de las afirmaciones en las respuestas es consistente con el contexto recuperado. Para la monitorización continua en producción, la integración con Langfuse o LangSmith permite medir la faithfulness sobre una muestra de consultas reales. Procedimiento detallado en Cómo evaluar RAG: RAGAS, faithfulness, context precision.
¿Hay que citar cada chunk o basta una fuente por respuesta?
Depende del caso de uso. Para preguntas factualmente simples (una respuesta procede de un único lugar) basta una fuente. Para preguntas complejas donde la respuesta sintetiza varios pasajes de documentos distintos, la cita granular por afirmación es más precisa y auditable. Los sistemas para entornos regulados deberían citar por defecto a nivel de afirmación — aunque eso aumente el output.
*Si estáis gestionando un sistema RAG en el que necesitáis saber no solo qué respondió el modelo, sino también de dónde lo sabe, con mucho gusto analizamos vuestra situación concreta. El grounding y la arquitectura de citas forman parte de cada despliegue que realizamos en MP Industrial Solutions — contáctenos para una valoración inicial.*