Notas de Engenharia da Naly: redação de artigos RAG orientada por fonte para publicação persistente e auditável

TL;DRA geração aumentada por recuperação (RAG) transforma o pipeline de artigos da Naly em um sistema de publicação fundamentado em fontes em vez de composição pela memória do modelo. Cada solicitação de rascunho primeiro reúne evidência da web e do arXiv, normaliza e persiste URLs de origem e depois pede ao modelo para produzir um rascunho answer-first e um artigo HTML final. Isso desloca o risco de "o modelo pode alucinar?" para "a camada de recuperação está completa e rastreável?", oferecendo aos editores artefatos estáveis, jobs reproduzíveis e alegações públicas defensáveis.

Resumo

A RAG na Naly deve ser projetada em torno de persistência de fontes e contratos determinísticos. Em 27 de junho de 2026, a confiabilidade prática vem menos de um modelo maior e mais do que a camada de recuperação seja consultável, versionada e validada antes da publicação. Esta nota propõe um design de plano duplo: um plano de evidência para recuperação/armazenamento e um plano de geração para redação, depois argumenta como essa arquitetura melhora diretamente a confiança editorial e o tratamento de incidentes.

Onde isso se encaixa na Naly

A Naly executa isto como um subsistema de conteúdo em produção dentro de uma stack Next.js 16.0.7 App Router (next + react), onde a publicação de artigo faz parte de caminhos de código em tempo de execução em vez de uma etapa offline de escrita. O caminho do job de artigo é onde todas as restrições devem ser aplicadas: um job não é "escrito" até que existam registros de fonte, a estrutura de resumo seja validada e o HTML seja materializado.

O alinhamento da stack é intencional:

next@16.0.7 + React Server Components hospedam renderização acionada por job no espaço do servidor, casando contratos de saída no lado do servidor para artigos.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 definem tabelas tipadas e persistentes de jobs e fontes para que cada alegação possa ser rastreada.
ai@6.0.0-beta.105 fornece à geração controles de saída conscientes de esquema.
marked@17.0.1 converte resumos em Markdown gerados em HTML renderizado para publicação.
@vercel/blob@2.0.0 armazena ativos gerados como URLs duráveis para reutilização.
Ferramentas da Anthropic podem ser adicionadas como provedor de modelo alternativo dentro do mesmo envelope de contrato, mas não como rota de escape para os limites estruturados.

Isso substitui um modelo de "gerar e depois revisar" por um ciclo de escrita fundamentado: recuperação, validação, geração, renderização e publicação precisam passar todos antes que o artigo fique visível.

Mecanismo técnico

Um design robusto da Naly tem cinco etapas delimitadas:

Plano de evidência e orquestração de consulta

Definir a especificação do job com tópico, janela de data e política de evidência.
Executar busca web e busca no arXiv para fontes primárias.
Deduplicar por URL canônica e normalizar protocolo, host e string de consulta.

Camada de persistência de fonte

Armazenar metadados por URL (url, URL canônica, status de busca, carimbo de data/hora da busca, título, resumo, tipo de fonte).
Armazenar snippets voltados para o modelo separadamente dos payloads brutos para que reruns sejam determinísticos mesmo se páginas de origem mudarem.
Adicionar checksums por fonte para detectar drift.

Moldagem de contexto e restrições

Construir contexto de recuperação ordenado por relevância e recência.
Exigir IDs de fonte explícitos no contrato do prompt.
Forçar formato de saída answer-first (intro claim, evidence bullets, risk caveats, uncertainty), além de referências de fonte ordenadas.

Geração estruturada com esquema estrito

Usar saída estruturada para que respostas malformadas ou com violação de esquema falhem rápido e sejam reenviadas com contexto mais restrito.
Manter geração em contexto de servidor e rejeitar rascunhos que afirmam fatos sem suporte sem IDs de fonte mapeadas.

Renderizar, publicar e verificar

Converter markdown validado para HTML e persistir markdown + HTML.
Cachear saída final apenas após validação bem-sucedida.
Emitir campos de análise e auditoria: contagem de fontes, alegações rejeitadas, contagem de retry e latência de geração.

A mudança de design mais importante é a separação de preocupações: a qualidade da recuperação e a qualidade da geração são domínios de falha diferentes com métricas diferentes. Os React Server Components da Next.js se encaixam nessa divisão porque a renderização pode permanecer determinística enquanto recuperação e geração ocorrem em tarefas assíncronas controladas.

O que diz a literatura

A pesquisa recente de RAG apoia esse padrão arquitetural. Uma pesquisa de 2024 sobre arquitetura RAG descreve como sistemas aumentados por recuperação reduzem drift de fatos ao condicionar a geração em evidências externas, mas aponta trade-offs de complexidade de pipeline e coordenação modular [Gupta et al., 2024]. Uma pesquisa de seguimento em 2025 acrescenta que a robustez agora depende de recuperação adaptativa, controle de decodificação e avaliação ponta a ponta, em vez de apenas qualidade de geração [Sharma, 2025].

Para controle de qualidade de produção, a pesquisa de avaliação de 2025 separa explicitamente a avaliação em métricas internas de recuperador/gerador e métricas externas de sistema; essa decomposição é especialmente útil para pipelines de artigo porque “mau artigo” pode significar escolha de fonte errada mesmo quando a qualidade da linguagem é alta [Gan et al., 2025]. O trabalho focado em fundamentação também avançou para camadas de detecção que classificam suporte de alegações usando contexto recuperado e checagens no estilo NLI, reforçando o valor prático da validação pós-geração [Gerner et al., 2025].

Em resumo, os papers convergem para uma tese: RAG não é apenas uma forma de injetar contexto, é um contrato de engenharia entre recuperação e geração. A Naly deve, portanto, otimizar o contrato, e não apenas o prompt.

Trade-offs de design

Atualidade versus determinismo: TTLs mais estritos reduzem obsolescência, mas aumentam custo de re-fetch. Persistir snapshots permite manter renderização determinística enquanto ainda revalida janelas de frescor.
Recall versus precisão na recuperação: recuperação mais ampla pode aumentar cobertura, mas injeta ruído; um filtro de relevância de segunda etapa protege a qualidade das alegações.
Rigor de esquema versus fluência de prosa: esquemas de saída estritos melhoram confiabilidade de máquina, mas podem reduzir a liberdade estilística. O padrão de esquema answer-first preserva a legibilidade enquanto mantém guardrails.
Velocidade de renderização estática versus auditabilidade: HTML pré-renderizado melhora a performance de entrega e reduz computação repetida, mas apenas se os artefatos de origem usados forem referências imutáveis.
Complexidade versus custo operacional: cada etapa de validação adicionada (checagens de fonte, checagens de esquema, persistência de artefatos) aumenta a latência. A orientação de produção da Next.js sobre cache, limites de rota e verificação em build-time é importante para manter isso operacional.

Modos de falha

Deriva de fonte: URLs retornam 404/mudanças suaves após a criação do job. Mitigação: chave canônica + snapshot hash + cadeia de fonte de fallback.
Excesso de recuperação: alto recall com baixa precisão causa síntese plausível, porém sem suporte. Mitigação: exigir restrições evidence-first e bloquear alegações sem correspondências de fonte.
Falha de formatação do modelo: mismatch de esquema ou JSON truncado na geração. Mitigação: validação de esquema estrita e nova tentativa com contexto reduzido.
Concorrência de dupla publicação: workers concorrentes podem publicar artefatos parciais. Mitigação: chaves de idempotência de job, transições de estado por linha (pending -> drafting -> validated -> published).
Regressões de renderização: markdown malformado ou transformações HTML inseguras. Mitigação: caminho de marked conversão determinístico e testes de saída HTML vinculados a manifestos de amostra.
Ilusões de cache: dados dinâmicos obsoletos na saída do servidor podem dessincronizar o texto publicado e o índice de fonte. Mitigação: alinhar a estratégia de renderização de rota com política explícita de freshness de runtime e evitar caches implícitos onde a frescura da evidência é necessária.

Notas de implementação

Para uma implantação prática, trate isto como um contrato de publicação de publicação:

Definir tabelas de fonte no Drizzle com restrições explícitas: unicidade de URL por host/caminho canônico, enums de status de busca e colunas de checksum.
Usar um caminho de driver compatível com Neon de forma consistente com o comportamento de execução serverless; os documentos do Drizzle descrevem opções específicas de runtime e neon-* opções de driver.
Na geração, impor contratos de saída estruturada e falhar em objetos inválidos antes da renderização.
Usar orientações de produção da Next.js para limites de servidor, páginas de erro, cache e metadados de SEO para rotas de artigo para que a publicação permaneça observável e rápida.
Persistir blobs gerados (por exemplo, capas, anexos, exports) via Vercel Blob com política de acesso explícita e nomenclatura determinística para evitar colisões.
Emitir verificações operacionais antes da publicação: contagem mínima de fonte, diversidade mínima de fonte, frescor de evidência e taxa mínima de conclusão para alegações mapeadas.

Essa é a mudança principal: o artigo não é mais julgado pela esperteza do modelo; é julgado por se evidência e geração permanecem sincronizadas sob retries e redeploys.