Notas de ingeniería de Naly: redacción de artículos aumentada por recuperación con fuentes persistidas

Resumen

La generación aumentada por recuperación da a la canalización de artículos de Naly una memoria de investigación más actual y más auditable que los pesos del modelo por sí solos. Para cada nota de ingeniería o trabajo de artículo de inteligencia de mercado, el sistema puede buscar en la web y en arXiv, conservar las URL de las fuentes con el artefacto generado, pedir al modelo que responda primero y renderizar el resultado como HTML. El objetivo no es la automatización por sí misma; es publicar afirmaciones que los lectores puedan rastrear.

La tesis es simple: la RAG para escribir artículos debe tratarse como un sistema de evidencia de producción, no como un patrón de chatbot. A un chatbot se le puede perdonar una respuesta débil; un artículo publicado se convierte en una superficie duradera de confianza. Por eso, la implementación de Naly necesita tres invariantes: recuperación antes de redactar, registros de fuentes que sobrevivan después de la publicación y un renderizador que preserve Markdown legible evitando HTML inseguro.

Dónde encaja en Naly

Los trabajos de artículos de Naly se ubican entre la adquisición de investigación y la publicación pública. El trabajo empieza con un tema seleccionado, genera intenciones de búsqueda, obtiene material web y de arXiv, normaliza los resultados en registros de fuentes y luego pide a un modelo que escriba un artículo centrado en la respuesta a partir de ese conjunto acotado de evidencia. La salida no es solo prosa. Es un paquete: contenido Markdown, HTML renderizado, URL de fuentes, títulos de fuentes, tipos de fuentes y metadatos suficientes para explicar por qué se usó cada fuente.

Esto importa para el ciclo de confianza de Naly. La postura editorial más amplia de Naly es publicar lo que otros ocultan: memorandos de decisión, límites de calibración, fallos y la evidencia detrás de las afirmaciones. La generación respaldada por fuentes hace operativa esa postura. Los lectores no deberían tener que adivinar si una declaración provino de los datos de entrenamiento de un modelo, de un documento oficial, de un artículo académico o de una afirmación de un operador.

La capa RAG pertenece antes de la redacción, no después. Adjuntar citas a posteriori es más débil porque el modelo ya ha formado afirmaciones. En un diseño más sólido, la recuperación restringe el contexto de generación, y la generación produce afirmaciones que pueden verificarse contra el conjunto recuperado. El artículo visible puede seguir siendo conciso, pero el artefacto almacenado debería conservar el rastro de investigación.

Mecanismo técnico

Para la redacción de artículos, el flujo RAG de Naly es una canalización por lotes:

La selección del tema crea una pregunta de investigación acotada, como cómo la generación aumentada por recuperación fundamenta la redacción de artículos respaldados por fuentes.
La planificación de consultas expande esa pregunta en consultas web, consultas de documentos oficiales y consultas de arXiv.
La recuperación recopila documentación oficial, artículos primarios y fuentes explicativas de alta señal.
La normalización extrae título, URL canónica, tipo de fuente, contexto de publicación o actualización cuando está disponible, y fragmentos o resúmenes relevantes.
La persistencia de fuentes almacena el libro mayor de URL antes de la generación para que el artículo pueda auditarse más tarde.
El ensamblaje del prompt da al modelo el tema, datos de implementación específicos de Naly, restricciones de escritura y evidencia recuperada.
La generación produce Markdown con un resumen centrado en la respuesta, modos de fallo explícitos y una sección de referencias.
La validación comprueba que cada referencia del artículo renderizado se corresponda con un objeto de fuente almacenado.
El renderizado convierte Markdown a HTML para el sitio aplicando saneamiento y controles de producción.

Esto se acerca al patrón de recuperación y generación aumentada descrito en la guía RAG de Vercel: primero recuperar el contexto relevante y luego combinarlo con la pregunta del usuario o del trabajo antes de la generación. La diferencia es que Naly no optimiza para soporte conversacional. Optimiza para publicación duradera, donde una URL de fuente forma parte del modelo de datos del artículo.

El AI SDK es una capa de orquestación natural para este tipo de trabajo porque su interfaz de generación de texto admite automatización no interactiva, llamadas a herramientas, resultados de varios pasos y metadatos de fuentes cuando los proveedores devuelven fuentes URL. Incluso cuando un proveedor no devuelve objetos de fuente nativos, Naly puede adjuntar su propia lista de fuentes recuperadas al artefacto del artículo y tratar las fuentes nativas del modelo como suplementarias, no autoritativas.

Qué dice la literatura

La formulación original de RAG de Lewis et al. planteó bien el problema central: los modelos de lenguaje paramétricos almacenan hechos en pesos, pero actualizar ese conocimiento y proporcionar procedencia sigue siendo difícil. Su modelo aumentado por recuperación combinó un modelo de secuencia con un índice vectorial denso y encontró una generación más específica, diversa y factual que una línea base solo paramétrica en tareas intensivas en conocimiento.

El estudio posterior de RAG de Gao et al. generaliza esa idea en una taxonomía: RAG ingenua, RAG avanzada y RAG modular. La canalización de artículos de Naly debería ser modular. La recuperación, clasificación, persistencia de fuentes, construcción del prompt, generación, validación de referencias y renderizado son unidades separadas con modos de fallo separados. Tratarlas como unidades separadas hace que el sistema sea más fácil de depurar cuando un artículo cita una fuente débil o pasa por alto una mejor.

Self-RAG añade una advertencia importante. Asai et al. sostienen que recuperar un número fijo de pasajes, se necesite o no la recuperación, puede degradar la calidad de salida. Para Naly, eso significa que la recuperación top-k no debe ser un ritual. Un artículo breve sobre una función estable de un framework puede necesitar documentación oficial y un artículo académico; un artículo cargado de literatura puede necesitar varias fuentes de arXiv y una revisión. La profundidad de recuperación debe seguir el riesgo de las afirmaciones.

RAGChecker aporta la lección de evaluación. Ru et al. sostienen que los sistemas RAG necesitan diagnósticos granulares tanto de recuperación como de generación, especialmente para respuestas largas. Para Naly, la unidad de evaluación no debería ser solo la calidad del artículo. Debería incluir exhaustividad de recuperación, relevancia de fuentes, respaldo de afirmaciones, cobertura de referencias y si afirmaciones sin respaldo se colaron en el Markdown final.

Compensaciones de diseño

Alta cobertura frente a bajo ruido es la compensación central. Más recuperación mejora la probabilidad de encontrar la fuente correcta, pero también aumenta la probabilidad de que fragmentos débiles entren en el prompt y orienten al modelo. Naly debería preferir un enfoque por etapas: recopilación amplia, filtrado estricto y luego contexto compacto para el prompt.

La persistencia de fuentes mejora la auditabilidad, pero también crea trabajo de almacenamiento y mantenimiento. Las URL cambian, los artículos se revisan y las páginas de documentación se mueven. El registro duradero debería incluir URL canónica, marca de tiempo de recuperación, título, tipo de fuente e idealmente un resumen de contenido o límite de extracto. Eso permite a Naly distinguir un error del modelo de una fuente modificada.

La escritura centrada en la respuesta mejora el valor para el lector, pero puede comprimir la incertidumbre de forma demasiado agresiva. El artículo debería empezar con la conclusión y preservar una sección posterior para modos de fallo y salvedades. El resumen centrado en la respuesta es el punto de entrada; no es una licencia para aplanar la evidencia.

El HTML renderizado mejora la distribución y la experiencia de lectura, pero crea una frontera de seguridad. Marked es rápido y útil para analizar Markdown, pero su documentación advierte explícitamente que no sanea el HTML de salida. Un renderizador de artículos de Naly debería sanear el HTML generado y mantener disponible la fuente Markdown confiable para su reproducción.

Modos de fallo

Fallo de recuperación: el paso de búsqueda encuentra fuentes plausibles pero incompletas. Esto suele ocurrir cuando el planificador de consultas es demasiado estrecho o usa términos de producto que difieren de la literatura. Mitigación: usar varios estilos de consulta, incluir documentación oficial y exigir al menos dos fuentes primarias o de arXiv cuando el artículo haga afirmaciones de investigación.

Lavado de citas: una fuente aparece en las referencias, pero en realidad no respalda la oración cercana. Esto es peor que no tener cita porque crea falsa confianza. Mitigación: validar las afirmaciones contra fragmentos de fuente y rechazar artículos donde las referencias sean meramente temáticas.

Deriva de fuentes obsoletas: una página de documentación oficial cambia después de la publicación. Mitigación: persistir los metadatos de la fuente en el momento de la generación y registrar la etiqueta de fecha. Para fuentes que impulsan afirmaciones importantes, almacenar una instantánea o resumen cuando la licencia lo permita.

Exceso de recuperación: demasiados fragmentos hacen que el modelo resuma el contexto en lugar de responder a la tesis del artículo. Mitigación: usar clasificación de fuentes, deduplicar documentos casi idénticos y limitar la evidencia del prompt por relevancia de afirmación en lugar de por recuento bruto.

Envenenamiento del contexto: páginas de spam, páginas SEO generadas o resúmenes de baja calidad superan a material primario. Mitigación: clasificar documentación oficial, arXiv, estándares y repositorios fuente por encima de comentarios secundarios, salvo que el artículo trate explícitamente sobre la recepción de la industria.

Riesgo del renderizador: el Markdown generado puede incluir HTML sin procesar, enlaces inseguros o tablas mal formadas. Mitigación: sanear el HTML renderizado, normalizar enlaces, rechazar contenido ejecutable y ejecutar controles de producción coherentes con la guía de Next.js sobre rendimiento, seguridad, metadatos y accesibilidad.

Notas de implementación

Dados los hechos actuales del entorno de ejecución de Naly, la arquitectura limpia es un trabajo en TypeScript que usa ai@6.0.0-beta.105 para orquestación de modelos, herramientas de recuperación web y arXiv para recopilación de evidencia, Drizzle ORM con Neon para registros de artículos y fuentes, marked@17.0.1 para renderizado de Markdown a HTML, y Next.js 16 para la superficie de publicación.

La base de datos debería tratar las fuentes como filas de primera clase, no como un blob de texto Markdown. Un esquema práctico tiene una tabla de artículos, una tabla de unión artículo-fuente y campos de fuente para URL, título, tipo de fuente, marca de tiempo recuperada, identificador canónico como arXiv ID cuando esté disponible y estado de extracción. El registro del artículo puede entonces apuntar a Markdown, HTML renderizado, resumen, puntos clave y metadatos de publicación.

Vercel Blob es útil para artefactos más grandes o salidas de renderizado inmutables, mientras que Postgres sigue siendo mejor como libro mayor consultable para fuentes y metadatos de artículos. Esa separación mantiene baratas las consultas de auditoría: listar cada artículo que usó una fuente, cada fuente usada por un artículo y cada artículo cuya extracción de fuentes falló.

El prompt del generador debería exigir disciplina de fuentes en la forma de la salida: sin afirmaciones no respaldadas, sin URL inventadas y una sección de referencias cuyos enlaces deban coincidir con la lista de fuentes persistida. El modelo puede escribir prosa fluida, pero el trabajo debe ser dueño de la verdad de las fuentes. Si el modelo emite una referencia que no fue recuperada, el validador debería fallar el artículo en lugar de publicarlo silenciosamente.

Por último, el comportamiento en producción importa. Next.js ya ofrece componentes de servidor, división de código, prerenderizado y valores predeterminados de caché, pero las canalizaciones de contenido generado todavía necesitan manejo explícito de errores, controles de seguridad, metadatos y conciencia de Core Web Vitals. RAG ayuda a Naly a escribir con evidencia. La ingeniería de producción se asegura de que esa evidencia llegue a los lectores de forma rápida, segura y repetida.