Notas de ingeniería de Naly: redacción de artículos con RAG centrado en fuentes para una publicación persistente y auditable

TL;DRLa generación aumentada por recuperación (RAG) convierte la canalización de artículos de Naly en un sistema de publicación basado en fuentes en lugar de composición por memoria del modelo. Cada solicitud de borrador primero reúne evidencia web y de arXiv, normaliza y persiste las URL de origen y luego pide al modelo que produzca un borrador answer-first y un artículo HTML final. Esto desplaza el riesgo de «¿puede el modelo alucinar?» a «¿es completa y trazable la capa de recuperación», lo que brinda a los editores artefactos estables, tareas repetibles y reclamos públicos defendibles.

Resumen

RAG en Naly debe diseñarse en torno a la persistencia de fuentes y contratos deterministasEl 27 de junio de 2026, la confiabilidad práctica depende menos de un modelo más grande y más de si los artefactos de recuperación son consultables, versionados y validados antes de la publicación. Esta nota propone un diseño de plano dual: un plano de evidencia para recuperación/almacenamiento y un plano de generación para redactar, y argumenta cómo esta arquitectura mejora directamente la confianza editorial y el manejo de incidentes.

Dónde encaja en Naly

Naly lo ejecuta como un subsistema de contenido en producción dentro de una pila App Router de Next.js 16.0.7 (next + react), donde la publicación de artículos forma parte de rutas de código en tiempo de ejecución en lugar de un paso de redacción offline separado. La ruta de trabajo de artículos es donde deben aplicarse todas las restricciones: un trabajo no se escribe hasta que existan registros de fuente, la estructura del resumen se valide y se materialice el HTML.

La alineación del stack es intencional:

next@16.0.7 + Los React Server Components alojan el renderizado activado por trabajos en el espacio del servidor, emparejando contratos de salida del lado del servidor para artículos.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 define tablas tipadas y persistentes de trabajos y fuentes para que cada afirmación pueda rastrearse.
ai@6.0.0-beta.105 proporciona a la generación controles de salida conscientes del esquema.
marked@17.0.1 convierte los resúmenes Markdown generados en HTML renderizado para la publicación.
@vercel/blob@2.0.0 almacena los activos generados como URL duraderas para reutilización.
Las herramientas de Anthropic pueden añadirse como proveedor alternativo del modelo dentro del mismo sobre de contrato, pero no como vía de escape de las restricciones estructuradas.

Esto reemplaza un modelo de “generar y luego corregir” con un bucle de redacción con fundamento: recuperación, validación, generación, renderizado y publicación deben aprobarse antes de que el artículo sea visible.

Mecanismo técnico

Un diseño robusto de Naly tiene cinco etapas acotadas:

Plan de evidencia y orquestación de consultas

Definir la especificación del trabajo con tema, ventana temporal y política de evidencia.
Ejecutar tanto búsqueda web como búsqueda en arXiv para fuentes primarias.
Desduplicar por URL canónica y normalizar protocolo, host y cadena de consulta.

Capa de persistencia de fuentes

Almacenar metadatos por URL (url, URL canónica, estado de fetch, marca de tiempo de fetch, título, extracto, tipo de fuente).
Almacenar fragmentos orientados al modelo por separado de las cargas útiles sin procesar, de modo que las re-ejecuciones sean deterministas incluso si cambian las páginas de origen.
Agregar checksums por fuente para detectar deriva.

Modelado de contexto y restricciones

Construir un contexto de recuperación ordenado por relevancia y recencia.
Requerir IDs de fuente explícitas en el contrato del prompt.
Forzar la forma de salida answer-first (intro claim, evidence bullets, risk caveats, uncertainty), además de referencias de fuente ordenadas.

Generación estructurada con esquema estricto

Usar salida estructurada para que las respuestas malformadas o que violen el esquema fallen rápido y se vuelvan a intentar con contexto más estricto.
Mantener la generación en contexto de servidor y rechazar borradores que afirmen hechos no soportados sin IDs de fuente mapeadas.

Renderizar, publicar y verificar

Convertir markdown validado a HTML y persistir markdown + HTML.
Almacenar en caché la salida final solo tras una validación exitosa.
Emitir métricas de análisis y auditoría: conteo de fuentes, reclamos rechazados, número de reintentos y latencia de generación.

El movimiento de diseño más importante es la separación de responsabilidades: la calidad de recuperación y la calidad de generación son diferentes dominios de fallo con métricas distintas. Los Server Components de Next.js encajan con esta separación porque el renderizado puede permanecer determinista mientras la recuperación y la generación ocurren en tareas asíncronas controladas.

Lo que dice la literatura

La literatura reciente sobre RAG respalda este patrón arquitectónico. Una encuesta de 2024 sobre arquitectura RAG describe cómo los sistemas aumentados por recuperación reducen la deriva factual al condicionar la generación en evidencia externa, pero señala compensaciones en la complejidad del pipeline y la coordinación modular [Gupta et al., 2024]. Una encuesta de seguimiento de 2025 añade que la robustez ahora depende de la recuperación adaptativa, el control de decodificación y la evaluación de extremo a extremo, más que de la calidad de generación por sí sola [Sharma, 2025].

Para el control de calidad de producción, la encuesta de 2025 centrada en evaluación divide explícitamente la evaluación en métricas internas de recuperador/generador y métricas externas de sistema; esa descomposición es especialmente útil para pipelines de artículos porque “un mal artículo” puede significar elección incorrecta de fuente incluso cuando la calidad del lenguaje es alta [Gan et al., 2025]. El trabajo específico de groundedness también ha evolucionado hacia capas de detección que clasifican el soporte de reclamos usando el contexto recuperado y verificaciones estilo NLI, reforzando el valor práctico de la validación posterior a la generación [Gerner et al., 2025].

En resumen, los papers convergen en una tesis: RAG no es solo una forma de inyectar contexto, es un contrato de ingeniería entre recuperación y generación. Por ello Naly debe optimizar el contrato, no solo el prompt.

Compromisos de diseño

Actualización frente a determinismo: TTLs más estrictas reducen la obsolescencia pero aumentan el costo de reobtener. Persistir instantáneas permite mantener renderizado determinista y seguir revalidando ventanas de frescura.
Cobertura vs precisión en la recuperación: una recuperación más amplia puede aumentar la cobertura, pero inyecta ruido; un filtro de relevancia en segunda etapa protege la calidad de los reclamos.
Rigor del esquema vs fluidez de prosa: esquemas de salida estrictos mejoran la confiabilidad de máquina pero pueden reducir la libertad estilística. El patrón de esquema answer-first preserva la legibilidad mientras mantiene barreras de seguridad.
Velocidad de renderizado estático vs auditabilidad: el HTML pre-renderizado mejora el rendimiento de entrega y reduce cómputo repetido, pero solo si los artefactos de fuente utilizados son referencias inmutables.
Complejidad vs costo operativo: cada paso de validación añadido (checks de fuente, checks de esquema, persistencia de artefactos) agrega latencia. La guía de producción en caché, fronteras de ruta y verificación en tiempo de compilación es importante para mantener esto operable.

Modos de fallo

Deriva de fuente: las URL devuelven 404/cambios leves tras la creación del trabajo. Mitigación: clave canónica + hash de instantánea + cadena de fuentes de respaldo.
Sobre-recuperación: alta cobertura con baja precisión genera síntesis plausibles pero no respaldadas. Mitigación: exigir restricciones evidence-first y bloquear reclamos sin coincidencias de fuente.
Fallo de formato del modelo: desajuste de esquema o JSON truncado de la generación. Mitigación: validación de esquema estricta y reintento con contexto reducido.
Carreras de doble publicación: los trabajadores concurrentes pueden publicar artefactos parciales. Mitigación: claves de idempotencia del trabajo, transiciones de estado a nivel de fila (pending -> drafting -> validated -> published).
Regresiones de renderizado: markdown malformado o transformaciones inseguras de HTML. Mitigación: vía de conversión marked determinista y pruebas de salida HTML vinculadas a manifiestos de muestra.
Ilusiones de caché: datos dinámicos obsoletos en la salida del servidor pueden desincronizar el texto publicado y el índice de fuentes. Mitigación: alinear la estrategia de renderizado de ruta con una política explícita de frescura en tiempo de ejecución y evitar cachés implícitas donde se requiera frescura de evidencia.

Notas de implementación

Para un despliegue práctico, trata esto como un contrato de publicación contract:

Definir tablas de fuente en Drizzle con restricciones explícitas: unicidad de URL por host/ruta canónico, enums de estado de fetch y columnas de checksum.
Usar consistentemente una ruta de driver compatible con Neon con el comportamiento de ejecución serverless; la documentación de Drizzle describe opciones específicas de runtime y neon-* opciones de driver.
En la generación, hacer cumplir contratos de salida estructurada y fallar en objetos inválidos antes del renderizado.
Usar la guía de producción de Next.js para límites de servidor, páginas de error, caché y metadatos SEO para rutas de artículos para que la publicación siga siendo observable y rápida.
Persistir blobs generados (por ejemplo, imágenes de portada, anexos, exportaciones) mediante Vercel Blob con política de acceso explícita y nombres deterministas para evitar colisiones.
Emitir comprobaciones operativas antes de publicar: conteo mínimo de fuentes, diversidad mínima de fuentes, frescura de evidencia y tasa mínima de finalización para reclamos mapeados.

Este es el cambio clave: el artículo ya no se evalúa por la astucia del modelo; se evalúa por si evidencia y generación permanecen sincronizadas bajo reintentos y redeploys.