Notas de Engenharia da Naly: Escrita de Artigos com Geração Aumentada por Recuperação e Fontes Persistidas

Resumo

A geração aumentada por recuperação dá ao pipeline de artigos da Naly uma memória de pesquisa mais atual e mais auditável do que apenas os pesos do modelo. Para cada nota de engenharia ou trabalho de artigo de inteligência de mercado, o sistema pode pesquisar na web e no arXiv, manter as URLs das fontes junto ao artefato gerado, pedir ao modelo que responda primeiro e renderizar o resultado como HTML. O objetivo não é automação por si só; é publicar afirmações que os leitores possam rastrear.

A tese é simples: RAG para escrita de artigos deve ser tratada como um sistema de evidências em produção, não como um padrão de chatbot. Um chatbot pode ser perdoado por uma resposta fraca; um artigo publicado se torna uma superfície duradoura de confiança. Portanto, a implementação da Naly precisa de três invariantes: recuperação antes da redação, registros de fontes que sobrevivem após a publicação e um renderizador que preserve Markdown legível enquanto evita HTML inseguro.

Onde isso se encaixa na Naly

Os trabalhos de artigos da Naly ficam entre a aquisição de pesquisa e a publicação pública. O trabalho começa com um tópico selecionado, gera intenções de busca, coleta material da web e do arXiv, normaliza os resultados em registros de fontes e então pede a um modelo que escreva um artigo orientado pela resposta a partir desse conjunto delimitado de evidências. A saída não é apenas prosa. É um pacote: conteúdo em Markdown, HTML renderizado, URLs das fontes, títulos das fontes, tipos de fontes e metadados suficientes para explicar por que cada fonte foi usada.

Isso importa para o ciclo de confiança da Naly. A postura editorial mais ampla da Naly é publicar o que outros escondem: memorandos de decisão, limites de calibração, falhas e as evidências por trás das afirmações. A geração respaldada por fontes torna essa postura operacional. Os leitores não deveriam ter que adivinhar se uma declaração veio dos dados de treinamento de um modelo, de um documento oficial, de um artigo acadêmico ou de uma afirmação do operador.

A camada de RAG pertence ao momento anterior à redação, não depois dela. A anexação de citações post-hoc é mais fraca porque o modelo já formou afirmações. Em um design mais forte, a recuperação restringe o contexto de geração, e a geração produz afirmações que podem ser verificadas contra o conjunto recuperado. O artigo visível pode continuar conciso, mas o artefato armazenado deve reter a trilha de pesquisa.

Mecanismo técnico

Para a escrita de artigos, o fluxo de RAG da Naly é um pipeline em lote:

A seleção do tópico cria uma pergunta de pesquisa delimitada, como de que modo a geração aumentada por recuperação fundamenta a escrita de artigos respaldados por fontes.
O planejamento de consultas expande essa pergunta em consultas na web, consultas a documentos oficiais e consultas no arXiv.
A recuperação coleta documentação oficial, artigos primários e fontes explicativas de alto sinal.
A normalização extrai título, URL canônica, tipo de fonte, contexto de publicação ou atualização quando disponível, e trechos ou resumos relevantes.
A persistência de fontes armazena o livro-razão de URLs antes da geração para que o artigo possa ser auditado depois.
A montagem do prompt fornece ao modelo o tópico, fatos de implementação específicos da Naly, restrições de escrita e evidências recuperadas.
A geração produz Markdown com um resumo orientado pela resposta, modos de falha explícitos e uma seção de referências.
A validação verifica se cada referência no artigo renderizado corresponde a um objeto de fonte armazenado.
A renderização converte Markdown em HTML para o site enquanto aplica sanitização e verificações de produção.

Isso se aproxima do padrão de recuperação e geração aumentada descrito no guia de RAG da Vercel: recuperar primeiro o contexto relevante e então combiná-lo com a pergunta do usuário ou do trabalho antes da geração. A diferença é que a Naly não está otimizando para suporte conversacional. Ela está otimizando para publicação duradoura, na qual uma URL de fonte faz parte do modelo de dados do artigo.

O AI SDK é uma camada natural de orquestração para esse tipo de trabalho porque sua interface de geração de texto oferece suporte a automação não interativa, chamadas de ferramentas, resultados em múltiplas etapas e metadados de fontes quando os provedores retornam fontes com URL. Mesmo quando um provedor não retorna objetos de fonte nativos, a Naly pode anexar sua própria lista de fontes recuperadas ao artefato do artigo e tratar fontes nativas do modelo como suplementares, não autoritativas.

O que a literatura diz

A formulação original de RAG por Lewis et al. enquadrou bem o problema central: modelos de linguagem paramétricos armazenam fatos em pesos, mas atualizar esse conhecimento e fornecer proveniência continuam difíceis. Seu modelo aumentado por recuperação combinou um modelo sequencial com um índice vetorial denso e encontrou geração mais específica, diversa e factual do que uma linha de base apenas paramétrica em tarefas intensivas em conhecimento.

A revisão posterior de RAG por Gao et al. generaliza essa ideia em uma taxonomia: RAG ingênuo, RAG avançado e RAG modular. O pipeline de artigos da Naly deve ser modular. Recuperação, ranqueamento, persistência de fontes, construção de prompt, geração, validação de referências e renderização são unidades separadas com modos de falha separados. Tratá-las como unidades separadas torna o sistema mais fácil de depurar quando um artigo cita uma fonte fraca ou perde uma melhor.

Self-RAG acrescenta uma cautela importante. Asai et al. argumentam que recuperar um número fixo de passagens, seja a recuperação necessária ou não, pode degradar a qualidade da saída. Para a Naly, isso significa que a recuperação top-k não deve ser um ritual. Um artigo curto sobre um recurso estável de framework pode precisar de documentação oficial e um artigo acadêmico; um artigo fortemente baseado em literatura pode precisar de múltiplas fontes do arXiv e uma revisão. A profundidade da recuperação deve seguir o risco da afirmação.

RAGChecker traz a lição de avaliação. Ru et al. argumentam que sistemas de RAG precisam de diagnósticos granulares tanto na recuperação quanto na geração, especialmente para respostas longas. Para a Naly, a unidade de avaliação não deve ser apenas a qualidade do artigo. Ela deve incluir recall de recuperação, relevância das fontes, suporte às afirmações, cobertura de referências e se afirmações sem suporte entraram no Markdown final.

Trade-offs de design

Alto recall versus baixo ruído é o trade-off central. Mais recuperação melhora a chance de encontrar a fonte certa, mas também aumenta a chance de trechos fracos entrarem no prompt e conduzirem o modelo. A Naly deve preferir uma abordagem em etapas: coleta ampla, filtragem rígida e então contexto de prompt compacto.

A persistência de fontes melhora a auditabilidade, mas também cria trabalho de armazenamento e manutenção. URLs mudam, artigos são revisados e páginas de documentação são movidas. O registro durável deve incluir URL canônica, timestamp de coleta, título, tipo de fonte e, idealmente, um digest de conteúdo ou limite de excerto. Isso permite à Naly distinguir um erro do modelo de uma fonte alterada.

A escrita orientada pela resposta melhora o valor para o leitor, mas pode comprimir a incerteza de modo agressivo demais. O artigo deve começar pela conclusão enquanto preserva uma seção posterior para modos de falha e ressalvas. O resumo orientado pela resposta é o ponto de entrada; não é uma licença para achatar as evidências.

HTML renderizado melhora a distribuição e a experiência de leitura, mas cria uma fronteira de segurança. Marked é rápido e útil para parsing de Markdown, mas sua documentação alerta explicitamente que ele não sanitiza o HTML de saída. Um renderizador de artigos da Naly deve sanitizar o HTML gerado e manter a fonte Markdown confiável disponível para reprodução.

Modos de falha

Falha de recuperação: a etapa de busca encontra fontes plausíveis, mas incompletas. Isso geralmente acontece quando o planejador de consultas é estreito demais ou usa termos de produto que diferem da literatura. Mitigação: usar múltiplos estilos de consulta, incluir documentação oficial e exigir pelo menos duas fontes primárias ou do arXiv quando o artigo fizer afirmações de pesquisa.

Lavagem de citação: uma fonte aparece nas referências, mas na verdade não sustenta a frase próxima a ela. Isso é pior do que não ter citação porque cria falsa confiança. Mitigação: validar afirmações contra trechos das fontes e rejeitar artigos em que as referências sejam apenas temáticas.

Deriva de fonte obsoleta: uma página de documentação oficial muda após a publicação. Mitigação: persistir metadados da fonte no momento da geração e registrar o rótulo de data. Para fontes que sustentam afirmações importantes, armazenar um snapshot ou digest quando a licença permitir.

Recuperação excessiva: chunks demais fazem o modelo resumir o contexto em vez de responder à tese do artigo. Mitigação: usar ranqueamento de fontes, deduplicar documentos quase idênticos e limitar as evidências do prompt por relevância à afirmação, não por contagem bruta.

Envenenamento de contexto: páginas de spam, páginas de SEO geradas ou resumos de baixa qualidade superam materiais primários no ranqueamento. Mitigação: ranquear documentação oficial, arXiv, padrões e repositórios de código-fonte acima de comentários secundários, a menos que o artigo seja explicitamente sobre a recepção da indústria.

Risco do renderizador: Markdown gerado pode incluir HTML bruto, links inseguros ou tabelas malformadas. Mitigação: sanitizar o HTML renderizado, normalizar links, rejeitar conteúdo scriptável e executar verificações de produção consistentes com a orientação do Next.js sobre desempenho, segurança, metadados e acessibilidade.

Notas de implementação

Dadas as informações atuais de runtime da Naly, a arquitetura limpa é um trabalho em TypeScript que usa ai@6.0.0-beta.105 para orquestração do modelo, ferramentas de recuperação da web e do arXiv para coleta de evidências, Drizzle ORM com Neon para registros de artigos e fontes, marked@17.0.1 para renderização de Markdown para HTML, e Next.js 16 para a superfície de publicação.

O banco de dados deve tratar fontes como linhas de primeira classe, não como um blob de texto Markdown. Um esquema prático tem uma tabela de artigos, uma tabela de junção artigo-fonte e campos de fonte para URL, título, tipo de fonte, timestamp de recuperação, identificador canônico como ID do arXiv quando disponível, e status de extração. O registro do artigo pode então apontar para Markdown, HTML renderizado, resumo, pontos-chave e metadados de publicação.

Vercel Blob é útil para artefatos maiores ou saídas de renderização imutáveis, enquanto o Postgres continua melhor como o livro-razão consultável para fontes e metadados de artigos. Essa separação mantém baratas as consultas de auditoria: listar todos os artigos que usaram uma fonte, todas as fontes usadas por um artigo e todos os artigos cuja extração de fonte falhou.

O prompt do gerador deve exigir disciplina de fontes no formato da saída: nenhuma afirmação sem suporte, nenhuma URL inventada e uma seção de referências cujos links devem corresponder à lista de fontes persistidas. O modelo pode escrever prosa fluida, mas o trabalho deve ser dono da verdade das fontes. Se o modelo emitir uma referência que não foi recuperada, o validador deve reprovar o artigo em vez de publicá-lo discretamente.

Por fim, o comportamento em produção importa. O Next.js já fornece componentes de servidor, divisão de código, pré-renderização e padrões de cache, mas pipelines de conteúdo gerado ainda precisam de tratamento explícito de erros, verificações de segurança, metadados e consciência de Core Web Vitals. RAG ajuda a Naly a escrever com evidências. A engenharia de produção garante que essas evidências cheguem aos leitores rapidamente, com segurança e de forma repetida.