RAG con citas: cómo generar respuestas con fuentes verificables y trazabilidad
Una cita en RAG no es decoración: es un contrato de evidencia que conecta cada afirmación con un fragmento identificable, una versión, un ancla y los permisos que permiten mostrarlo.
RAG con citas es un flujo en el que cada afirmación verificable se asocia a evidencia visible y recuperable. La cita conserva identidad de documento y fragmento, versión, ancla u offset, permisos y fuente. El modelo redacta; el sistema decide qué evidencia existe y qué puede mostrarse.
Contrato mínimo de evidencia
Define una cita como objeto estable, no como URL pegada al final. Incluye `citation_id`, `document_id`, `document_version`, `chunk_id`, `source_uri`, `start_offset`, `end_offset`, `retrieved_at`, `tenant_id`, `visibility` y un hash del texto observado. El hash detecta que el enlace ya no apunta al contenido citado.
Conserva un extracto autorizado, nunca secretos por defecto. La identidad de documento y chunk debe sobrevivir a reindexaciones; si cambia la versión, la cita debe declararlo.
Checklist
Validación en TypeScript
type Evidence = { id: string; documentId: string; version: string; chunkId: string; uri: string; start: number; end: number; textHash: string; tenantId: string };\ntype Claim = { text: string; status: "supported" | "partial" | "unsupported"; evidenceIds: string[] };\n\nexport function validateClaims(claims: Claim[], evidence: Evidence[], tenantId: string) {\n const byId = new Map(evidence.map(item => [item.id, item]));\n return claims.map(claim => claim.evidenceIds.every(id => { const item = byId.get(id); return item && item.tenantId === tenantId && item.start >= 0 && item.end > item.start && item.uri.startsWith("https://"); }) ? claim : { ...claim, status: "unsupported" as const, evidenceIds: [] });\n}Esta validación comprueba forma, tenant y rango; añade groundedness o una regla de dominio para comprobar soporte semántico.
Ingesta, offsets y versiones
Normaliza el documento una sola vez antes de fragmentarlo y guarda offsets sobre esa representación. Para HTML o PDF conserva página, sección, párrafo o selector. En recuperación registra versión del índice y candidatos; al generar congela solo las evidencias usadas.
Puntos a revisar
Lo que conviene comprobar
- Una cita debe responder qué documento vio el sistema y qué versión. Guarda `retrieved_at` y vigencia; para políticas o permisos, evidencia caducada debe degradar el claim o bloquearlo.
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratisACL, multi-tenant y redacción
Filtra por tenant y permisos antes de entregar evidencia al modelo, y repite la comprobación al mostrarla. Si el lector no puede ver el fragmento, presenta referencia mínima. Redacta PII, secretos y tokens antes de indexar o crear el extracto visible. Consulta [RAG multi-tenant y permisos](/rag-multitenant-filtros-permisos/).
Checklist
Fallos y antipatrones
Antipatrones: citar todo el top-k, usar título como prueba, enlazar página mutable sin versión, mostrar cita de otro tenant, ocultar inferencias, conservar IDs antiguos tras regenerar y aceptar URLs sin validación. Inspecciona siempre el mapping claim-evidence y una muestra con permisos reales.
Integración con la recuperación
Las citas se benefician de [BM25, vectores y reranking](/busqueda-hibrida-rag-bm25-vectorial-reranking/) para hallar candidatos, pero no los reemplazan. Los chunks enriquecidos conservan contexto, aunque la cita señala el fragmento concreto. Usa [salidas estructuradas y validación](/salidas-estructuradas-llm-json-schema-validacion/) para conectar claims con IDs.
Citas en streaming y reintentos
En streaming no envíes una cita antes de haber validado el claim al que pertenece. Puedes emitir tokens de texto y adjuntar una lista provisional, pero marca el estado como pendiente hasta que termine la validación. Si falla, reemplaza la afirmación por una abstención en vez de dejar una cita huérfana.
Los reintentos pueden cambiar el conjunto de evidencias. Conserva el intento que produjo la respuesta, su versión de índice y un identificador de ejecución; no mezcles IDs de un intento descartado con texto de otro. En una interfaz, muestra el estado de verificación y permite abrir el fragmento sin perder el contexto de la respuesta.
Citas de cálculos y transformaciones
No todo claim sale literalmente de un documento. Para un cálculo, cita las entradas, la versión del dato y la fórmula o herramienta usada. Para una síntesis, conserva las fuentes contribuyentes y marca que el texto es una inferencia. La procedencia de un resultado derivado es un pequeño grafo, no una única URL.
Valida unidades, periodos y filtros antes de afirmar un número. Si una fuente dice ‘hasta’ o condiciona el resultado a una región, esa condición debe sobrevivir al claim y a su etiqueta visible.
Checklist
Checklist antes de ponerlo en producción
Comprueba que cada claim verificable tiene al menos una evidencia y que cada ID resuelve a un documento, versión y chunk existentes. Verifica que offsets y hashes corresponden a la representación indexada, que la fuente conserva una fecha de recuperación y que los cambios de documento crean una nueva versión.
Ejecuta la comprobación de permisos dos veces: al construir el contexto y al renderizar el enlace. Prueba explícitamente que un usuario de otro tenant, un documento revocado y un extracto redactado no aparecen por accidente. Los errores deben degradar a referencia mínima o abstención, nunca a contenido completo.
Revisa seguridad del renderer con URI maliciosas, HTML en títulos, atributos inesperados y enlaces caducados. Audita que los logs no guarden prompts, tokens o PII sin justificación. Finalmente, abre muestras manuales: una cita correcta, una parcial, una contradictoria y una rechazada. Si el equipo no puede explicar por qué cada una pasó, el contrato todavía es demasiado débil.
Documenta quién es responsable de corregir una cita rota, cuánto tiempo se conserva la evidencia y qué ocurre durante una reindexación. La operación diaria importa tanto como el schema: una procedencia perfecta que nadie monitoriza se degrada silenciosamente. Incluye alertas para enlaces inválidos, caída de cobertura, aumento de abstenciones y cambios de versión inesperados; son señales tempranas de que el corpus o la política ya no coincide con la respuesta publicada.
Preguntas frecuentes
¿Una URL al final es suficiente?
No: faltan fragmento, versión, ancla y autorización.
¿Debo citar cada frase?
Cada afirmación verificable necesita evidencia; una inferencia se etiqueta.
¿Qué hago con versiones contradictorias?
Muestra vigencia y abstente si no puedes resolverlo.
¿Puedo ocultar el extracto?
Sí con datos restringidos, pero reautoriza al abrirlo.
¿Groundedness sustituye revisión humana?
No siempre; depende del riesgo.
Cómo construir un flujo RAG con citas verificables
- Definir el contrato. Decide campos para claim, evidencia, versión, offset, tenant, hash y soporte.
- Capturar procedencia. Normaliza documentos y guarda anclas estables.
- Generar estructura. Pide claims y evidence_ids mediante schema.
- Validar soporte. Comprueba IDs, tenant, permisos, rangos, versión y relación semántica.
- Renderizar seguro. Emite enlaces allowlisted o reautorizados con redacción.
- Evaluar y operar. Mide cobertura, prueba negativos y revisa muestras reales.
Fuentes y referencias
También te puede interesar
Evaluación RAG en producciónRAG multi-tenant: filtros y permisosBúsqueda híbrida para RAGContextual retrieval y chunks enriquecidosSalidas estructuradas y validaciónRecibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Suscribirme gratis
