Olá, bem-vindes. Meu nome é Maíra de Oliveira, trabalho como editora de conteúdos aqui na Alura. Estou nos estúdios da Alura, sou uma mulher de pele morena, visto uma camiseta preta sem mangas, tenho o cabelo liso e preto na altura do peito, uso dois brincos brancos e sou uma pessoa muito sorridente.
Audiodescrição: Maíra é uma mulher de pele morena e está nos estúdios da Alura. Veste uma camiseta preta sem mangas, tem o cabelo liso e preto na altura do peito, usa dois brincos brancos e é muito sorridente.
Viemos hoje, com muita alegria, compartilhar um caso recente que realizamos na Alura, em colaboração com as equipes de marketing e de conteúdo, e apresentar o que aprendemos ao usar inteligência artificial desde o início do projeto — incorporando IA na concepção, no planejamento e no fluxo.
Na Alura, contamos com uma equipe de conteúdos especializada em criar tudo o que você encontra em nossos canais, e também com uma equipe de marketing, responsável por levar esse conteúdo ao mundo. Vamos explicar como nasceu o projeto “Como recuperamos o tráfego orgânico no blog (blog) da Alura com um assistente de revisão de artigos”.
Para começar, é importante contextualizar. Mantemos um blog (blog) há muitos anos, onde compartilhamos nossos conteúdos em artigos. Esse blog (blog) sempre foi um ativo muito estratégico para nós: gera receita, traz engagement (engajamento), possibilita aprendizado gratuito — é um objeto de aprendizagem —, atrai pessoas para a Alura, para nossas jornadas e cursos, e funciona como uma ferramenta de marketing. Por meio dele, sempre trouxemos muitas pessoas ao nosso produto com tráfego orgânico, sem a necessidade de grandes investimentos para atrair e conquistar o público.
É comum que, ao pesquisarem temas de tecnologia e inovação, as pessoas encontrem nosso blog (blog). Todo o nosso time de conteúdos trabalhou intensamente por muitos anos para construir esses artigos, o que torna esse ativo ainda mais valioso por trazer tráfego orgânico consistente. Como os artigos são escritos por pessoas especialistas nas áreas — instrutores, instrutoras, especialistas e nosso time interno de suporte —, o blog (blog) carrega autoridade técnica: quem assina entende profundamente do que está explicando. Além disso, muitos leitores e leitoras que chegam para tirar uma dúvida encontram chamadas para ação e hiperlinks para nosso site e produtos, o que gera receita orgânica significativa para o negócio.
O que aconteceu nos últimos tempos? Passamos a observar uma queda no desempenho do blog (blog). O time de marketing, que o gerencia, identificou perda de posições em temas estratégicos. A curva de crescimento deixou de ser ascendente e constante. Antes, ao buscar termos de tecnologia e programação — nosso forte —, o blog (blog) da Alura aparecia entre as primeiras posições em mecanismos como o Google e similares. Isso começou a mudar: perdemos posições no ranqueamento de SEO (otimização para mecanismos de busca) e, com isso, também cliques. Menos pessoas chegaram aos artigos, a taxa de cliques caiu e o impacto sobre a receita do blog (blog) se tornou evidente.
Diante desse cenário, intensificamos a colaboração entre marketing e conteúdo. O time de conteúdo cria, planeja e elabora os artigos; o de marketing distribui e potencializa esse material. Trata-se de uma parceria estratégica contínua. Quando o marketing identificou a queda, acionou rapidamente o conteúdo: indicaram uma redução drástica em indicadores do blog (blog) e mapearam artigos principais que estavam desatualizados.
Ao rastrear essas publicações, identificamos temas macro para a queda, sendo o principal a desatualização do conteúdo. Em tecnologia e inovação, tudo muda com frequência. Uma tecnologia vigente hoje pode mudar em um ou dois meses — e, com a inteligência artificial, esse ciclo é ainda mais acelerado, às vezes em semanas. Assim, um artigo de 2015 pode conter informações obsoletas ou hiperlinks que precisam de revisão. Esses foram alguns dos pontos críticos mapeados.
O marketing solicitou que priorizássemos a revisão de um conjunto de artigos críticos para recuperar posições nos rankings, melhorar métricas, retomar engagement (engajamento) e, consequentemente, receita. O desafio: o volume. Nosso blog (blog) existe há muitos anos e o número de publicações é significativo. Não se tratava do total de artigos, e sim de 400 artigos prioritários identificados como críticos e que precisaríamos revisar.
Ao analisarmos o fluxo de trabalho, estimamos que uma pessoa levava, em média, duas horas e meia para revisar um artigo já publicado. Para dar conta dos 400, seriam necessárias aproximadamente mil horas de trabalho. Não tínhamos equipe suficiente para essa demanda, e cada dia sem revisão continuaria corroendo relevância, engagement (engajamento), cliques e receita do blog (blog).
Refletimos sobre a natureza do problema: artigos do blog (blog) são textos desatualizados que precisam de revisão textual com atualização técnica e curadoria de especialistas. Em outras palavras, do início ao fim do fluxo, tratamos de texto que deve ser aprimorado. Então nos perguntamos: que ferramenta é excelente para trabalhar com texto — revisar e também gerar — e pode nos ajudar a acelerar esse processo? Chegamos aos LLMs (Modelos de Linguagem de Grande Porte), popularmente chamados de inteligência artificial, como ChatGPT, Gemini, Claude, Claude Code e afins — ferramentas muito capazes de transformar um texto em outro.
Propusemos construir um fluxo automatizado para otimizar a revisão dos 400 artigos, pois seria inviável revisar cada um integralmente, do início ao fim, somente com especialistas. Chamamos o Rodrigo, nosso especialista, para construir esse motor. A pergunta norteadora foi: e se a IA fizer a primeira revisão do documento? Ou seja, a partir do texto de entrada, criaríamos um assistente com IA para realizar a primeira passada no artigo e entregar um rascunho pré-revisado para validação humana. Assim, a pessoa especialista não começaria do zero; partiria de um texto já trabalhado por um assistente de IA.
A ideia foi facilitar o trabalho humano, não substituí-lo. Adotamos o conceito de AI First (IA em primeiro lugar): primeiro, o artigo passa por um assistente de revisão de artigos — construído com IA e outras ferramentas —, que executa o trabalho pesado; depois, entra a validação humana, sempre por pessoas especialistas, com critério, contexto e qualidade.
Para construir esse assistente, definimos diretrizes claras:
Com o fluxo definido, estabelecemos o entregável desejado: um documento de texto — no nosso caso, um arquivo do Word — com comentários do assistente seguindo as quatro diretrizes principais: técnica; SEO (otimização para mecanismos de busca); textual e didática; e imagens. Assim, quando o documento chegasse à fase de revisão humana, a pessoa especialista veria, nos comentários, o que foi sinalizado pelo assistente e decidiria o que aplicar.
Vamos mostrar como ficou o resultado final de um documento que acabou de sair do nosso assistente de revisão de textos. Aqui está um exemplo de artigo revisado pela IA: “Linux, visualizando o tamanho de diretórios”. Temos um arquivo do Word com as imagens e os textos do artigo, tal como foi publicado originalmente, neste caso em 2017. Podemos observar, na lateral, comentários inseridos como anotações.
Para contextualizar o exemplo, o título original do artigo aparece no documento assim:
Linux - Visualizando tamanhos de Diretórios
Trabalhamos com comentários de texto convencionais, como os blocos de revisão exibidos à direita do documento, que pessoas que atuam com revisão textual estão acostumadas a ver. O que acontece, então? Ao abrir um comentário, vemos categorias como revisão, IA, SEO (otimização para mecanismos de busca), mais técnico e mais texto. De imediato, identificamos a etiqueta da diretriz tratada. Por exemplo, um comentário pode abordar uma diretriz textual.
O comentário exibe o trecho original do texto, por exemplo: “por Yuri Matheus, 30/10/2017”. Em seguida, apresenta “Sugerido: por Yuri Matheus, 30/10/2017”. O assistente mostra o original, oferece uma sugestão e justifica o porquê. Nesse caso, sugere modernizar a data do artigo quando houver uma atualização significativa, evitando transmitir ao público uma impressão inicial de desatualização.
No arquivo, esse trecho de autoria e data aparece, originalmente, desta forma:
"Por Yuri Matheus - 30/10/2017"
Qual é nosso trabalho como pessoas revisoras, especialistas, validadoras? Verificar se a sugestão faz sentido. Se fizer, aplicamos no documento e marcamos o comentário como resolvido. Se não fizer, encerramos o comentário e seguimos adiante.
Vamos mostrar outro exemplo. Além de diretrizes textuais, temos comentários de diretriz de SEO (otimização para mecanismos de busca). Por exemplo, sobre um cabeçalho: o original, um H2, é “P6 reading 2, descobrindo o tamanho de um diretório”. A sugestão é alterar para “P6 reading 2, comando para ver o tamanho da pasta no Linux, como verificar o espaço em diretório”. A justificativa: inclusão direta de palavras-chave no H2 e esclarecimento do tema para melhorar a escaneabilidade para SEO (otimização para mecanismos de busca). A sugestão de SEO mostra o original, traz a proposta e explica o motivo.
Também vale mostrar uma diretriz técnica. Aqui, por exemplo, falamos de Linux em 2017. Mudou algo? Temos um exemplo de comentário de diretriz técnica no qual orientamos o time a partir dessas diretrizes. O comentário seleciona um trecho do texto e discute sobre ele: “Perceberam que os valores de saída dos comandos foram diferentes? Isso ocorre porque du lista apenas os arquivos e pastas contidos no diretório, enquanto df lista a partição junto com o sistema de arquivos montado nela.” Esse é o trecho original que o assistente destacou. Em alguns casos, ele mostra original e sugestão; em outros, apenas a justificativa. Cabe à pessoa especialista que está revisando avaliar se faz sentido. Se fizer, aceita. Se não, recusa. Simples assim.
A explicação está correta segundo a documentação atual de 2026: o comando du calcula o espaço em disco usado por arquivos e diretórios específicos, enquanto df exibe informações sobre todo o sistema de arquivos montado, incluindo metadados, journaling (registro) e blocos reservados. A diferença é esperada e está bem explicada no artigo.
Para dar materialidade a essa referência técnica, segue um exemplo simples do uso de du como aparece no contexto do artigo:
[root@servidor01 ~]# du /compartilhamento/
Esse comando percorre os arquivos e subdiretórios em “/compartilhamento/” e relata o uso de disco local desses itens, o que justifica diferenças em relação ao df, que reporta o uso do sistema de arquivos como um todo.
Observe que, no exemplo acima, há apenas uma validação. Porém, também é possível proceder de outra forma: se a pessoa especialista considerar conveniente, pode copiar diretamente do comentário, selecionar, copiar e colar no artigo original. A ideia é facilitar o trabalho humano de quem revisa o conteúdo, passando pelos comentários e validando, acelerando o processo, pois não é necessário ler o artigo inteiro para descobrir o que mudou e o que não mudou. Já existe uma navegação guiada pelo próprio assistente de revisão. A revisão se torna mais rápida, mais focada e melhora a produtividade e a eficiência do processo como um todo.
Vale reforçar que, depois de passar por todos os comentários que o assistente deixa no artigo, no arquivo, é muito importante realizar uma leitura completa, de ponta a ponta, feita por uma pessoa humana, preferencialmente em voz alta, para garantir que nada passe despercebido. A validação humana por parte da pessoa especialista no tema — quem pode confirmar se tudo está correto e atualizado — é o ponto mais importante.
Mesmo com as sugestões do assistente, percebemos que surgem questões de data: em 2017 era de um jeito, em 2026 já não é mais. Às vezes o assistente fornece links e recomenda: “Consulte a documentação, pois isso não é mais aplicável, mudou.” Cabe à pessoa revisora do artigo conferir esse hiperlink, acessar a documentação e verificar se está atualizada.
Este foi um exemplo de como fica um arquivo, um artigo, após passar pelo assistente e chegar às mãos da pessoa revisora especialista. E como ficou o fluxo de trabalho entre os times? Este projeto envolve principalmente os times de Conteúdo e Marketing.
O fluxo começa com o time de Marketing alimentando um backlog (fila de pendências) com esses 400 artigos. Não fazemos os 400 de uma vez; existe uma fila priorizada pelo time de Marketing, que conhece a estratégia de SEO (otimização para mecanismos de busca), de engagement (engajamento) e de receita. Utilizamos a ferramenta ClickUp para gerenciar esse fluxo. O time de Marketing alimenta o backlog e cria um cartão para cada artigo que precisa ser revisado pelo time de Conteúdo.
No passo dois, o time de Conteúdo inicia a revisão com inteligência artificial. A pessoa especialista pega o cartão criado por Marketing e o coloca na fase de revisão com IA. Ou seja, pegamos o artigo original, o texto antigo, e o submetemos à IA.
Depois que a IA faz seu trabalho — o que leva alguns minutos —, a própria IA inclui no cartão o link para o artigo pré-revisado. Esse é o passo três, quando entra a validação humana: uma pessoa especialista valida com base em um conteúdo já pré-revisado pela IA. Quando a revisão humana do documento termina, devolvemos o cartão ao time de Marketing, responsável por publicar o artigo no blog.
No ClickUp, o fluxo simples para os times trabalharem está assim: começa em “pronto para iniciar”. Quem alimenta essa fase é o time de Marketing, adicionando o link do documento tal como está, desatualizado, no nosso blog. Movemos o cartão e, quando entra na fase chamada “revisão automática”, nosso assistente começa a atuar. Ele acessa o texto antigo e realiza quatro varreduras seguindo as diretrizes definidas. É como se houvesse quatro miniassistentes dentro do assistente de revisão de artigos: um revisa a parte técnica, outro a parte de SEO (otimização para mecanismos de busca), outro revisa a parte textual e didática e, por fim, um revisa a parte de imagens. Depois desses quatro processos de varredura do texto antigo, o assistente cria um texto novo com comentários na lateral. Tudo isso ocorre nessa fase, em questão de minutos.
Como sabemos que o assistente terminou? Quando é criado, no cartão, um link para o documento pré-revisado. Desenvolvemos um sistema em que, ao finalizar a passagem do artigo pelo assistente, aparece no cartão um link para o documento no SharePoint, pronto para a revisão humana por uma pessoa especialista. Quando vemos que o cartão já tem o link, movemos para a fase de revisão humana. A partir daí, dividimos entre nós: cada pessoa revisa os artigos atribuídos. Ao finalizar a revisão, marcamos como “revisão feita”. Ao marcar “revisão feita”, o time de Marketing recebe um alerta, recupera o artigo já revisado pela IA e pelas pessoas especialistas e publica. Assim concluímos o fluxo do processo de revisão de artigos entre IA e humanos. Esse é o fluxo que montamos na plataforma de gestão de processos que usamos, no caso, o ClickUp.
O que é interessante observar? Obtivemos um ganho real de produtividade com o assistente. Antes, cada pessoa levava, em média, duas horas e meia para revisar um artigo desatualizado do blog. Agora, com o assistente, cada pessoa leva, em média, 40 minutos. Houve uma redução de 73% no tempo dedicado por pessoa à revisão. Com isso, estamos conseguindo entregar mais artigos, mesmo antes de completar a força-tarefa. O projeto segue em curso, mas, como os resultados foram muito bons, queremos compartilhar tanto o processo quanto o impacto.
Comparando o período do ano passado com o atual, vemos que os artigos que passaram pela revisão do assistente e por esse fluxo — primeiro o assistente, depois as pessoas especialistas — já voltaram ao blog com um engajamento muito maior do que no ano anterior, mesmo antes da revisão. No gráfico, a linha verde, comparada à linha rosa (que mostra a desindexação do blog, isto é, quando começou a queda mencionada no início), indica que as publicações crescem e apresentam leve aumento. Começa a se formar uma curva. Observamos uma tendência de crescimento muito maior do que quando o blog estava desindexado. Temos crescimento de 42% em relação ao ano passado e aumento do volume médio diário: 129% mais impressões e 11% mais cliques. Esses são números parciais do início do projeto, mas já demonstram alta produtividade com o assistente de revisão de artigos. Conseguimos atrair mais engajamento ao blog; o tempo de leitura e as interações superam o histórico anterior. Recuperamos ranking (posicionamento): artigos voltando às primeiras posições no Google. E, naturalmente, há retorno de receita proveniente do blog, com tráfego orgânico reativado e impacto em conversões para nossos conteúdos.
É importante reforçar que a IA não substitui a revisão humana. Ela serve para facilitar o trabalho das pessoas. Não pode fazer esse trabalho de ponta a ponta. Pode alucinar, precisa verificar links e, como falamos de texto e leitura de conteúdo educativo, é necessário ter cuidado. O texto deve ser agradável de ler, correto, completo e ensinar algo que faça sentido. Nunca queremos entregar às nossas pessoas estudantes um conteúdo textual truncado, pouco didático ou desatualizado, em desacordo com o que há de mais moderno e com as novidades no mundo da tecnologia, da inovação e das linguagens de programação. Por isso, a validação por pessoas especialistas na área é fundamental.
Quais foram os principais aprendizados? A IA funciona melhor com boas diretrizes. Quanto mais claro o contexto, melhor a entrega do assistente. Construímos isso com muito cuidado, com base nas nossas diretrizes e no conhecimento das pessoas especialistas. Automatizar não é abrir mão da qualidade, de forma alguma. O conceito de human in the loop (humano no circuito) garante critério, tom e contexto da marca, porque as IAs e essas ferramentas não têm contexto. Precisamos transmitir o contexto com precisão para obter um resultado satisfatório. As pessoas especialistas ganham tempo para o que importa. Ao criar esses processos e facilitar o trabalho, o trabalho da pessoa especialista melhora muito: menos tarefas mecânicas, mais decisões estratégicas de qualidade. Todos ganham.
Por fim, destacamos a ideia de AI First (IA primeiro), quando o fluxo de trabalho já começa com inteligência artificial. É preciso redesenhar o processo; não basta usar uma ferramenta. Pensamos em todo o fluxo com IA desde o início, para otimizar o trabalho, trazer efetividade, obter resultados e colocar o foco das nossas pessoas especialistas onde mais se precisa. Quando a IA assume a parte tediosa, repetitiva, manual e operacional, as pessoas têm mais espaço para criar — é onde nós, como seres humanos, brilhamos. Somos criativos, queremos criar, queremos mais tempo para fazer coisas diferentes. Criatividade é criar coisas distintas com as mesmas ferramentas. Com isso, também melhoramos a experiência de aprendizagem, que é nosso foco na Alura. Não sabemos qual é o seu foco, mas esse é o nosso.
Quero também agradecer muito e deixar meu perfil no LinkedIn. Quem quiser entrar em contato ou conversar, será uma enorme alegria. Já expliquei um pouco do contexto do nascimento deste projeto e dos resultados que gerou, mas é importante abrir o capô e ver o motor: como ficou o assistente por trás das câmeras, quais ferramentas utilizamos, como conectamos tudo e como construímos essas automações. Rodrigo, o especialista que trabalhou comigo neste projeto, vai contar e mostrar o motor para vocês, por trás das cortinas, para que possam unir o contexto inicial do desafio e ver a máquina interna. Aproveitem a conversa com o Rodrigo, está incrível.
Este projeto segue em andamento; continuaremos observando. Foi um trabalho muito bonito em colaboração entre Marketing e Conteúdo, com AI First (IA primeiro), em um esforço conjunto para revisar 400 artigos e fazer a curva voltar a subir — e vemos que está funcionando muito bem. É conhecimento, é aprendizagem aqui na Alura. Gostamos de trabalhar assim, de compartilhar e difundir com todo mundo, para que, por meio de vocês também, possamos multiplicar práticas, aprendizados e formas de trabalho eficientes com AI First (IA primeiro).
Muito obrigada pelo tempo e pela atenção até aqui, foi um prazer. Até a próxima! [♪]
Olá, pessoal, boas-vindas. Meu nome é Rodrigo Dias, eu sou um dos coordenadores de carreira aqui da Alura. Eu sou um homem de pele clara, cabelo castanho, uso uma barba grisalha, estou usando também um óculos com armação levemente arredondada e visto uma camisa preta com símbolo da Alura.
Nosso objetivo hoje é dar continuidade ao que a Maíra iniciou conosco. Ela apresentou um panorama geral do projeto e explicou por que começamos este projeto de revisão automática, com inteligência artificial, dos artigos da Alura. Como ela antecipou, neste vídeo nós vamos “abrir o capô” e detalhar como tudo funciona por dentro: que ferramentas usamos e como configuramos para fazer tudo operar.
Nós vamos dividir este processo em aproximadamente dois vídeos, para não ficar cansativo, e começaremos de trás para frente. Vamos iniciar pelo ClickUp, mostrando como o gatilho é disparado. A Maíra já apresentou a visão geral, mas aqui veremos em detalhes quais ferramentas usamos e como configuramos cada parte. Além disso, neste vídeo entraremos no n8n, ferramenta utilizada para automatizar o processo, explorando como os nós funcionam, como o fluxo foi construído e qual foi o raciocínio por trás das decisões.
Nós já estamos no n8n, dentro do nosso workflow (fluxo de trabalho) utilizado para rodar todo o processo de revisão automática. Vamos ampliar a visualização e explicar ponto a ponto. O primeiro nó é o que inicia o processo. Ele é um webhook (gancho da web), cuja função é escutar os eventos que acontecem no ClickUp. Quando ocorre um evento específico que deve disparar o nosso processo, esse webhook dispara o fluxo e traz as informações para dentro do n8n.
Dentro desse webhook, temos uma URL de teste e uma URL de produção. No processo, usamos a URL de produção, configurada para receber requisições via POST (requisição POST). Essa mesma URL é a que configuramos no ClickUp.
Para concretizar essa parte, usamos a chamada HTTP de produção nesse formato:
POST https://n8n.srv1021153.hctp.cloud/webhook/8e3935c2-3e95-4d51-9d69-aa0db12ab505
E entre os headers, garantimos a configuração do tipo de conteúdo:
Content-type
O que precisamos fazer para tudo funcionar? Precisamos permitir que o ClickUp se comunique com o n8n, e, dependendo da situação no ClickUp, dispare o processo de revisão. No ClickUp, utilizamos um quadro (board) — o mesmo que a Maíra mostrou — e deixamos um cartão (card) de teste para demonstrar o funcionamento.
Para habilitar o disparo, configuramos um webhook no ClickUp. No canto superior direito da interface, clicamos no ícone de raio (no nosso caso, com o número 1), abrimos o menu, e, ao final, clicamos no item com uma engrenagem, “Manage Automations” (gerenciar automações). Na janela que se abre, acessamos a aba “Webhooks” e criamos o webhook que fará a comunicação com o n8n. Já existem outros webhooks para tarefas diversas, mas o que usamos aqui se chama “Revisão Automática n8n”. No ícone de lápis, podemos ver a configuração: atribuímos o nome e colamos a mesma URL do nó de webhook do n8n. Mantemos o restante como está, incluindo os cabeçalhos (headers) — por exemplo, Content-Type definido como JSON — e salvamos.
Na prática, a automação no ClickUp fica definida assim:
When Status changes
from Any Status to REVISÃO AUTOMÁTICA
then Call webhook
E selecionamos o webhook de produção nomeado como:
Revisão Automática n8n
Voltando ao “Manage Automations”, configuramos a automação que dispara esse webhook e envia a mensagem ao n8n. Criamos uma automação do tipo Trigger (gatilho). O gatilho é uma mudança de status (status change, mudança de status): quando o status muda de qualquer estado (any status) para o status “revisão automática”. Assim que arrastamos o cartão (a tarefa) para “revisão automática”, o ClickUp dispara a ação “chamar um webhook” e seleciona o webhook “Revisão Automática n8n”. Com isso, o ClickUp envia uma comunicação ao n8n e o processo é iniciado. Essa é toda a configuração necessária no ClickUp.
No n8n, vemos o fluxo completo já publicado. Em “execuções”, deixamos vazio para facilitar a visualização. No ClickUp, mudamos o status da tarefa simplesmente arrastando o cartão para “revisão automática”. Em seguida, no n8n, observamos que uma nova execução é iniciada: a mensagem chega e o processo começa a rodar.
Nesse momento, aguardamos a conclusão, pois todo o fluxo é executado para revisar o artigo (neste caso, um artigo pequeno). Após a execução, o resultado é retornado. O processo terminou aqui em aproximadamente 5 minutos, mas esse tempo varia conforme a situação, o tamanho do arquivo e outros fatores. Vamos continuar avaliando pela aba de execuções, porque ela traz os dados utilizados no processo e facilita o entendimento do que está acontecendo.
Voltando ao nó de webhook, ele trouxe as informações iniciais do evento. Dentro de body, temos o payload e o id da tarefa (identificador). No ClickUp, o cartão que colocamos em “revisão automática” foi atualizado. Uma das etapas do nosso processo é: ao finalizar tudo corretamente e criar a pasta com o arquivo docx comentado, o sistema já transfere o cartão de “revisão automática” para “revisão humana”, o próximo passo, como a Maíra mostrou. O cartão de teste permanece identificado pelo mesmo id mostrado no n8n (por exemplo, final “95u”). Essa informação permite acessar os dados do cartão no n8n e extrair o que interessa.
Para capturar esse id diretamente do payload do webhook no n8n, usamos a expressão:
{{ $('Webhook').item.json.body.payload.id }}
No final do fluxo, criamos o arquivo no SharePoint: é criada uma pasta e o arquivo revisado é colocado lá. Ao clicar nesse arquivo, abrimos o documento já com os comentários (como a Maíra apresentou no vídeo anterior). Com a tarefa identificada no n8n, avançamos para o próximo passo: obter as informações detalhadas da tarefa.
No n8n, cada nó funciona com entrada e saída: o lado esquerdo mostra o que foi recebido do nó anterior (neste caso, do webhook), o lado direito mostra o que é passado adiante (para o próximo nó ou para finalizar). O que buscamos da entrada? O id em body > payload > id. Utilizamos um nó do ClickUp para, sobre as tarefas (tasks), realizar um GET (obter) passando o id da tarefa. Assim obtemos todas as informações do cartão.
Nesses dados, observamos especialmente o campo custom_fields (Custom Fields), que inclui:
Com essas informações em mãos, seguimos para o nó de configurações, cuja função é extrair apenas os dados relevantes da tarefa e acrescentar uma informação extra. Dentro dele, há um trecho em JavaScript. Hoje, com ferramentas de IA, conseguimos obter esses códigos de forma simples: podemos solicitar ao ChatGPT, ao Claude (Anthropic) ou ao Gemini, descrevendo o que estamos fazendo no n8n e o resultado desejado. A ferramenta explica e propõe os pequenos trechos de código necessários para o processo. Não é obrigatório ser especialista em JavaScript ou Python para utilizar aqui.
O que esse código faz? Ele recebe o JSON com as informações da tarefa. Em custom_fields, temos uma lista de campos (por exemplo, índices 0, 1, 2, 3). Cada item possui um name (por exemplo, “categoria”, que corresponde ao campo “Categoria” no ClickUp). O objetivo é encontrar o campo com name idêntico a “link do artigo na plataforma”. Para isso, percorremos a lista com um método como filter() ou find(), passando uma função entre parênteses () que verifica, em cada elemento, se name corresponde exatamente a “link do artigo na plataforma”. Ao localizar esse item, extraímos o value (ou value equivalente no objeto), que contém o link do artigo na plataforma da Alura — o artigo que será revisado.
Na prática do n8n, essa extração fica assim:
{{ $json.custom_fields.find(f => f.name === "Link do artigo na plataforma").value }}
A mesma lógica se aplica às palavras-chave: localizamos, em custom_fields, o item cujo name corresponde ao campo de palavras-chave e extraímos seu value.
Usamos a expressão:
{{ $json.custom_fields.find(f => f.name === "Palavras-chave do artigo").value }}
Definimos também o provider (provedor) de IA. Testamos OpenAI e Anthropic (Claude). De modo geral, usamos OpenAI neste fluxo; porém, em alguns pontos configuramos Anthropic, pois os testes indicaram melhor desempenho para etapas específicas. O importante é que, ao final desse nó de configurações, encaminhamos adiante a URL do artigo, o provider escolhido e as palavras-chave.
No campo de provider, a configuração mais comum no nosso fluxo ficou:
openai
A partir desse ponto, há uma bifurcação no fluxo: um caminho inferior e outro superior. Vamos começar pelo caminho inferior, que é central neste caso. Como o processo exige etapas mais complexas do que o n8n oferece nativamente, optamos por executar uma aplicação em Python que expõe uma API com vários endpoints, cada um responsável por uma tarefa específica. O funcionamento é simples: fazemos uma requisição e obtemos uma resposta.
Um desses endpoints se chama “html to docx”. Ele recebe o HTML do artigo e o transforma em um documento do Word (.docx). No próximo vídeo, mostraremos em linhas gerais como isso funciona, onde está hospedado e como construímos esse serviço, portanto não é necessário se preocupar com isso agora. Aqui, acessamos o endpoint via POST (requisição POST), enviando um JSON com a URL do artigo. O serviço acessa o artigo, realiza a raspagem do conteúdo e, como o HTML já é naturalmente bem estruturado, conseguimos convertê-lo em docx de forma direta e robusta. Ao final, esse endpoint retorna o arquivo gerado; ao baixá-lo, temos exatamente o docx correspondente ao conteúdo HTML do artigo (ainda sem os comentários, porque a revisão não ocorreu).
Voltando ao n8n, observamos o caminho superior da bifurcação. O time de Marketing mantém um documento de SEO, com regras e orientações bem definidas, armazenado em uma pasta na nuvem da Alura. Um nó do fluxo faz o download desse arquivo, que chamamos de Guia SEO. Ele baixa o conteúdo a partir do endereço configurado e o deixa disponível para uso nas etapas seguintes. Esse Guia SEO será utilizado ao longo do processo.
Seguindo em frente, temos o Guia SEO disponível e o nosso documento...
Iniciamos com um nó que recebe o arquivo do artigo junto com o guia de SEO (otimização para mecanismos de busca). A partir desse nó, começamos o processo que estamos chamando de assistentes (não agentes no sentido estrito, embora estejamos atualizando o fluxo para, possivelmente, torná-los agentes).
Este primeiro nó é um agregador: ele recebe um arquivo proveniente de um nó e outro arquivo de um segundo nó e os une em um só. A partir desse agregador, o fluxo segue para o primeiro processo, o assistente de SEO. Embora usemos o termo “agente”, aqui tratamos de um processo de inteligência artificial que recebe informações e aplica um prompt bem definido e estruturado com base nos comentários da revisão.
O assistente de SEO recebe tanto o documento quanto o guia de SEO, pois é o assistente responsável por essa dimensão da revisão. Os quatro assistentes a seguir (SEO, técnico, texto e imagem) funcionam de forma semelhante: acessam uma aplicação que está na mesma VPS (servidor virtual privado) do nosso N8n e consomem um endpoint (ponto de extremidade) específico. No caso do SEO, o endpoint é o do assistente de SEO.
O que enviamos para o assistente de SEO:
provider (provedor): OpenAI. É o provedor definido anteriormente.URL do artigo: enviada apenas como informação para repasse adiante; não é utilizada nessa etapa.data, que contém o nosso arquivo .docx com o conteúdo do artigo, e o guia de SEO.Esse endpoint executa o processo de IA, realiza a revisão de SEO e cria os comentários. O retorno segue um padrão que estabelecemos para integrar com os demais assistentes:
Ao final dessa etapa, temos um agregador que reunirá os resultados dos quatro assistentes: SEO, técnico, texto e imagem. Apenas o primeiro (SEO) recebe o guia de SEO. Embora falemos em execução “em paralelo”, na prática o fluxo aguarda cada um terminar; depois que os quatro resultados chegam, tudo é agregado e segue.
O próximo é o assistente técnico. Ele possui um endpoint diferente, específico para revisão técnica. Não é necessário enviar o guia de SEO. O provider aqui está travado em Anthropic, pois, após testes, os resultados foram melhores, especialmente porque o assistente técnico precisa de um processo mais atual. Por isso, utilizamos web search (busca na web) para consultar a internet e trazer recomendações técnicas atualizadas sobre as ferramentas revisadas. Enviamos novamente a URL do artigo e o binário com o texto para revisão. O retorno segue o mesmo padrão, com tipo “técnico”, total de sugestões (por exemplo, 12) e revisões com ação (ex.: substituir), texto original, texto proposto e justificativa.
Para o assistente de texto, seguimos com OpenAI como provider. A passagem de informações permanece igual.
Para o assistente de imagem, optamos por Anthropic novamente, pois, embora seja uma dimensão técnica, está especializada em imagens. Esse assistente avalia as imagens existentes e identifica se determinados parágrafos se beneficiariam de imagens adicionais para facilitar a leitura e enriquecer o recurso visual. Também utilizamos web search (busca na web) nessa etapa.
Com os quatro resultados prontos, retornamos ao agregador. Nele, conseguimos visualizar todos (por exemplo, em uma visualização em tabela): SEO, técnico, texto e imagem, em sequência.
No nó intermediário seguinte, utilizamos um código em JavaScript com apoio de IA para agregar os quatro JSONs. A lógica é simples: definimos claramente no prompt o formato do JSON de entrada e o formato desejado na saída. Esse nó aceita JavaScript ou Python, mas optamos por JavaScript, que é um padrão no N8n.
Para fazer essa agregação e produzir estatísticas por tipo, aplicamos um trecho como este no Code Node:
// Junta todas as revisões dos 4 agentes
const items = $input.all();
let todasRevisoes = [];
for (const item of items) {
if (item.json.revisoes &&
Array.isArray(item.json.revisoes)) {
todasRevisoes = todasRevisoes.concat(item.json.revisoes);
}
}
// Estatísticas
const seo = todasRevisoes.filter(r => r.tipo === 'SEO').length;
const tecnico = todasRevisoes.filter(r => r.tipo === 'TECNICO').length;
const texto = todasRevisoes.filter(r => r.tipo === 'TEXTO').length;
const imagem = todasRevisoes.filter(r => r.tipo === 'IMAGEM').length;
return [{
json: {
total_revisoes: todasRevisoes.length,
por_tipo: { seo, tecnico, texto, imagem },
revisoes: todasRevisoes
}
}];
O que chega a esse nó:
JSONs (um de cada assistente).O que queremos:
JSON consolidado, preservando cada conjunto separadamente e também permitindo o uso em conjunto.Com o JSON consolidado pronto, seguimos para a etapa seguinte do fluxo (“andar de baixo”). Trazemos duas entradas: o HTML (texto do artigo com o qual trabalhamos) e o JSON das revisões. Um agregador simples junta o JSON de revisões e o artigo para, então, acionar o processo que insere a revisão dentro do arquivo.
Para repassar esse conjunto de revisões a um endpoint que insere comentários no .docx, serializamos o array de revisões:
{{ JSON.stringify($json.revisoes) }}
Tínhamos duas opções:
.docx, incentivando a revisão humana atenta. Essa abordagem permite que uma pessoa especialista leia, decida e, quando necessário, reescreva as sugestões da IA. Um dos objetivos é melhorar o ranqueamento; se a IA do Google identificar que o texto foi integralmente escrito por IA, o ranqueamento tende a cair. Por isso, manter o toque humano é importante.O nó de Track Changes permanece no fluxo por histórico, mas sem continuidade. O nó válido é o de comentários. Ele recebe o JSON com as revisões, o autor (campo que deixamos configurado; pretendíamos incluir “imagem” no nome e ainda não atualizamos) e o binário do arquivo sem comentários. O endpoint da nossa API insere os comentários exatamente como os que vemos no resultado: tipo (ex.: SEO), ação (ex.: substituir), texto original, texto sugerido e justificativa.
Após comentar o arquivo, iniciamos a etapa de finalização, que inclui criar o link no SharePoint, fazer o upload (envio) do arquivo e concluir o processo no ClickUp, movendo a tarefa para revisão humana. Para o SharePoint, utilizamos a API Microsoft Graph.
Como a API do Microsoft Graph tem restrição de tamanho em uploads diretos (até 4 MB), criamos uma sessão de upload quando necessário:
Upload URL, que permite enviar o arquivo em chunks (partições). No nosso caso, geralmente enviamos em um único chunk, pois os arquivos não são tão grandes, mas o mecanismo suporta partições (ex.: um arquivo de 100 MB em 10 partes de 10 MB).Nessa etapa, consultamos a IA para verificar a composição da URL, como obter os IDs necessários e onde inseri-los, além da documentação do Microsoft Graph (bem definida, porém extensa). A IA acelera a localização dessas informações. Implementamos nossa forma de conexão com a API da FIAP e enviamos um JSON com os dados para criar a sessão. O retorno relevante é a Upload URL, válida por tempo limitado, pela qual realizamos o upload do arquivo em partições ou de uma só vez (nosso caso mais comum).
Para a criação da sessão no Graph, montamos o corpo com comportamento de conflito e nome do arquivo derivado do nó que aplicou os comentários:
{{ JSON.stringify({ item: { "@microsoft.graph.conflictBehavior": "replace", "name": $('6b. Aplicar Revisões - Comentários').item.binary.data.fileName } }) }}
A Upload URL e o arquivo já comentado seguem adiante. Antes do upload, há uma preparação exigida pela API do Microsoft Graph, que requer dois cabeçalhos específicos:
Content-Length: o tamanho total do arquivo (em bytes).Content-Range: o intervalo (em bytes) que está sendo enviado. Se enviássemos em chunks, indicaríamos os intervalos, por exemplo: do byte 0 ao 999, depois do 1000 ao 1999, e assim por diante. Como faremos em um único envio, indicamos de 0 até o tamanho total − 1 (ex.: de 0 até 101.332 para um arquivo com 101.333 bytes). Essa lógica considera contagem iniciada em 0.No n8n, usamos um Code Node para calcular o tamanho e preparar o cabeçalho Content-Range:
if (!binaryData.data) {
throw new Error('Binário não encontrado!');
}
// Usa o buffer pra pegar o tamanho real em bytes
const buffer = await this.helpers.getBinaryDataBuffer(0, 'data');
const fileSize = buffer.length;
return [{
json: {
uploadUrl: uploadUrl,
fileSize: fileSize,
contentRange: `bytes 0-${fileSize - 1}/${fileSize}`,
binary: binaryData
}
}];
A seguir, usamos as saídas desse nó nas requisições subsequentes:
{{ $json.uploadUrl }}
{{ $json.contentRange }}
{{ $json.fileSize }}
Com esses cabeçalhos definidos, criamos o próximo nó de upload e enviamos:
Content-Range no formato “bytes 0-(tamanho−1)/(tamanho total)”.Content-Length com o tamanho do arquivo.Concluído o upload, recebemos o link do arquivo no SharePoint. Em seguida:
CustomField específico.ID do CustomField correspondente ao “link do artigo revisado”.URL retornada no CustomField.No fluxo, a busca pelo ID do campo personalizado “Link do artigo revisado” é feita com:
{{ $('Obtendo Informações da Tarefa').item.json.custom_fields.find(f => f.name === "Link do artigo revisado").id }}
E a atualização do valor desse campo, com a URL publicada no SharePoint, é enviada assim:
{{ { "value": $json.webUrl } }}
Depois, realizamos um teste simples: verificamos se o link foi preenchido (realizando um GET nessa informação). Com um IF:
A partir desse ponto, uma pessoa especialista assume e realiza a revisão do artigo, conforme o procedimento que a Mayra demonstrou.
Neste vídeo eu queria mostrar justamente esse fluxo. Já ficou até grande demais. No próximo, eu vou mostrar como construímos a nossa API por trás, o aplicativo em Python, o que há nele, onde foi hospedado e como configuramos tudo para funcionar, pois esse aplicativo é o coração do processo, o motor que opera em segundo plano. Até lá.
Dando continuidade ao tema do vídeo anterior, neste vídeo, que será mais curto, vamos mostrar o motor por trás do processo de revisão de artigos usando inteligência artificial. No vídeo anterior, usamos o n8n, que serve para criar um workflow (fluxo de trabalho). Ele executa muito bem a comunicação com ferramentas externas. Por exemplo, acessa o ClickUp, obtém uma informação do ClickUp e a traz para o processo; acessa nossa API, obtém uma resposta da API e a incorpora ao processo. Assim, o n8n se encarrega desse gerenciamento.
Mas como essa API funciona? Onde ela foi montada? Quais ferramentas utilizamos para tudo isso operar? É o que vamos mostrar agora. Estamos com o navegador aberto na página da Hostinger. O n8n, a ferramenta que usamos para montar o workflow (fluxo de trabalho), é de código aberto, então podemos baixar o n8n, instalá-lo na nossa máquina e executá-lo localmente. Não recomendamos essa abordagem porque haverá algumas restrições. Eles também oferecem um serviço pago, mantido pela equipe de desenvolvimento. É um serviço relativamente caro, mas com algumas vantagens, incluindo ferramentas de inteligência artificial, entre outras. Para nosso propósito, não precisávamos de tantos recursos; precisávamos de mais liberdade, pois também há limites na quantidade de requisições que podemos fazer ao n8n nos planos oferecidos. Aqui, não teremos essas restrições: podemos executar tantas requisições e quantos projetos quisermos, tudo instalado em uma máquina nossa.
A Hostinger, que está na nossa página, oferece o serviço de aluguel de uma VPS, que é como um computador na nuvem, no qual instalamos o n8n. Inclusive, eles já oferecem a VPS com o n8n previamente configurado, o que é muito melhor, pois não precisamos nos preocupar com essa configuração.
Na página da Hostinger, já logados, no menu lateral temos a opção de VPS. Aqui está nossa VPS. Ao clicar em Gerenciar, entramos no gerenciador da VPS, onde visualizamos informações do servidor: está rodando Ubuntu (Linux), uso de CPU, uso de memória e disco. Também temos acesso a algumas orientações. Para acessar nosso n8n, vamos em Gerenciar aplicação (botão azul), que abre uma nova aba com o n8n em execução. Em Personal, conseguimos acessar o workflow (fluxo de trabalho) mostrado no vídeo anterior. Porém, nosso foco agora é a estrutura por trás disso.
Temos um botão chamado gerenciador do Docker. Ao clicar, vamos à página de gestão do Docker, onde temos acesso aos projetos Docker em execução nessa máquina. No topo está o n8n. Esse projeto, com dois contêineres em execução, é o n8n preinstalado pela Hostinger; portanto, já está todo configurado e organizado por eles. Mais abaixo, temos o n8n runner. Esse também é um projeto Docker, mas foi instalado por nós do zero. Criamos esse processo e instalamos os contêineres necessários. Temos mais de um projeto rodando dentro da mesma aplicação Python que estamos executando. Também há um projeto de banco de dados, que é outro componente. E temos o n8n runner, que é precisamente nossa API, em execução dentro desse Docker, com todas as ferramentas Python necessárias para funcionar, tudo instalado e configurado corretamente.
Essa API está rodando na mesma máquina que o n8n, de modo que eles se comunicam entre si dentro da rede interna. A API não é acessível diretamente a partir da sua máquina, mas o nosso n8n consegue acessá-la, fazer requisições e obter respostas, que é exatamente o que estamos fazendo. Essa é, basicamente, a estrutura na nuvem.
Como isso funciona no código? Montamos tudo com o apoio de inteligência artificial, indicando o que queríamos e como deveria funcionar. Temos experiência em desenvolvimento e compreensão do processo, mas isso não é indispensável para montar um projeto: basta ir orientando, estruturando e mantendo tudo organizado. Nosso código está estruturado em várias pastas. Dentro da pasta "local files runner", temos alguns arquivos. Nessa pasta está o arquivo app.py, que fornece a estrutura inicial do processo e define as rotas e os endpoints.
Para visualizar isso no código, veja como o app.py inicializa a aplicação FastAPI, expõe um endpoint de healthcheck (/ping) e inclui os routers dos projetos mencionados:
# RUNNER ALURA - FastAPI
from fastapi import FastAPI
from projects.alura_utils.router import router as alura_utils_router
from projects.classificador_competencias.router import router as classificador_competencias_router
from projects.classificador_competencias_otimizado.router import router as classificador_otimizado_router
from projects.classificador_competencias_batch.router import router as classificador_batch_router
from projects.revisao_artigos.router import router as revisao_artigos_router
app = FastAPI()
@app.get("/ping")
def ping():
return {"ok": True, "service": "runner"}
app.include_router(revisao_artigos_router)
app.include_router(alura_utils_router)
app.include_router(classificador_competencias_router)
app.include_router(classificador_otimizado_router)
app.include_router(classificador_batch_router)
Depois de definir a aplicação e os routers, cada projeto organiza suas rotas em um router próprio, que é incluído pelo app.py como mostrado acima.
Dentro de "projects", organizamos os projetos para, como mencionamos, na Alura termos mais de um projeto executando na mesma aplicação. Temos "Alura Utils", que contém alguns arquivos; o "classificador de competências", outro projeto que também executamos aqui; e a "revisão de arquivos", que é o projeto do qual estamos falando agora. Dentro dele, tudo está organizado em arquivos próprios do projeto, apenas com as funções que utilizaremos nele. Assim, mantemos uma organização melhor do que misturar funções do projeto A com o projeto B, o que tornaria a manutenção muito mais complexa.
Temos também o router, que é o arquivo no qual definimos e criamos os endpoints. Como exemplo, vamos examinar a definição de um endpoint com o qual trabalhamos: o de extrair texto.
Para esse caso de extração de texto estruturado a partir de um DOCX, o endpoint recebe o payload, trata o arquivo temporariamente e devolve os parágrafos com metadados e o texto concatenado:
async def revisao_extrair_texto(payload: ExtrairTextoDocxPayload):
"""Extrai texto estruturado de um documento DOCX para analise."""
try:
docx_bytes = await obter_docx_bytes(payload.docx_url, payload.docx_base64)
except ValueError as e:
raise HTTPException(400, str(e))
except Exception as e:
raise HTTPException(400, f"Erro ao obter documento: {str(e)}")
with tempfile.NamedTemporaryFile(suffix=".docx", delete=False) as tmp:
tmp.write(docx_bytes)
tmp_path = tmp.name
try:
doc = Document(tmp_path)
paragrafos = []
texto_parts = []
idx = 0
for para in doc.paragraphs:
texto = para.text.strip()
if not texto:
continue
estilo = para.style.name if para.style else "Normal"
tipo = "paragraph"
if "heading" in estilo.lower():
tipo = estilo.lower().replace(" ", "-")
paragrafos.append({
"indice": idx,
"texto": texto,
"tipo": tipo,
"tamanho": len(texto)
})
texto_parts.append(f"[{idx}|{tipo.upper()}] {texto}")
idx += 1
return {
"paragrafos": paragrafos,
"texto_completo": "\n\n".join(texto_parts),
"total_paragrafos": idx
}
finally:
os.unlink(tmp_path)
Esse endpoint ilustra bem a lógica de pré-processamento de documentos: validação de entrada, manipulação temporária do arquivo e retorno padronizado com indicadores úteis para etapas posteriores no fluxo.
Lembramos do fluxo de HTML para DOCX? Aqui definimos esse endpoint. Estamos passando todas as funções, como ele deve tratar os dados, de onde deve obter as informações do artigo no HTML, como deve extrair essas informações e como deve salvar no DOCX. Tudo está no código. Não vamos entrar no código novamente; vamos apenas explicar como está estruturado. Dentro do router, fazemos essas definições. Estão todas essas funções lá.
Para conectar o fluxo “HTML → DOCX” em uma única chamada, o endpoint abaixo faz o download do HTML, extrai o conteúdo do artigo, monta o payload e delega a geração do arquivo DOCX:
@router.post("/html-to-docx")
async def html_to_docx(payload: ExtractArticlePayload):
"""Pipeline completo: extrai artigo de URL e gera DOCX em uma única chamada."""
try:
print(f"Pipeline HTML -> DOCX: {payload.url}")
with httpx.Client(timeout=30, follow_redirects=True) as client:
response = client.get(payload.url)
response.raise_for_status()
html = response.text
article_data = extract_article_content(html, payload.url)
print(f"Extraido: {article_data['stats']}")
docx_payload = GenerateDocxPayload(
metadata=article_data["metadata"],
content=[ContentItem(item) for item in article_data['content']],
filename=article_data['filename'],
base_url=article_data['base_url']
)
return await generate_docx(docx_payload)
except Exception as e:
print(f"Erro no pipeline: {str(e)}")
import traceback
traceback.print_exc()
raise HTTPException(status_code=500, detail=f"Erro no pipeline: {str(e)}")
Observe como o pipeline encapsula todo o processo, preparando os dados extraídos para a função de geração do DOCX e tratando erros de forma centralizada.
Outro arquivo importante é o de prompts, onde guardamos os prompts do agente. Estamos trabalhando com processos de inteligência artificial. Não é muito diferente de quando entramos no chat, escrevemos um prompt e obtemos uma resposta. Aqui também é assim, mas usamos a API do ChatGPT, da OpenAI, e a API da Anthropic, que é a do Claude. Também precisamos de um prompt aqui e de definir qual modelo será executado. Há mais de um modelo, cada provedor tem os seus, e estamos testando esses modelos.
Para exemplificar, veja um recorte de um prompt de SEO utilizado para orientar a IA durante a análise e revisão de conteúdo educacional:
SEO_SYSTEM_PROMPT = """Você e um especialista em SEO/GED para conteudo tecnico educacional.
Seu objetivo e melhorar a performance organica e conversao, garantindo que o artigo responda a intencao de busca
### O QUE AVALIAR E SUGERIR
#### 1. Intencao de busca
- O conteudo responde a intencao de busca do leitor?
- Se o leitor pesquisar o tema no Google, o texto entrega o que ele espera?
- O texto responde as principais perguntas sobre o tema?
- Ha definicoes, exemplos e/ou passo a passo quando necessario?
- Sugestoes: adicionar explicacoes faltantes; colocar resposta mais direta no inicio; remover trechos que nao a
#### 2. Palavra-chave (principal e variacoes)
- A palavra-chave esta no H1, nos primeiros paragrafos, em pelo menos um H2?
- Esta distribuida naturalmente (sem repeticao forcada)?
- Aproximacao de densidade: 5% a 8% (sem exagero).
- Sugestoes: inserir nos lugares corretos; remover repeticoes exageradas.
"""
Como tudo isso funciona? Este prompt é trabalho do nosso time; a Mayra, que mostrou o vídeo anterior, contribuiu bastante na construção inicial, e nós fomos refinando esses prompts para deixá-los bem robustos. Na verdade, esse é um trabalho contínuo, pois é aqui que melhoramos a qualidade da resposta da inteligência artificial. Os prompts estão todos nesse arquivo.
Outro arquivo importante é o LLM Client, onde mantemos as abstrações das inteligências artificiais. É onde tudo está configurado: como tratamos com a Anthropic, como tratamos com a OpenAI, como tudo se configura. O prompt chega aqui, e este componente orquestra todo o processo. O TrackChanges, como dissemos no vídeo anterior, foi abandonado; não o usamos mais, mas o arquivo permanece, pois no futuro pode ter alguma utilidade.
Para ilustrar o papel do cliente de LLM, segue um trecho do cliente da Anthropic, que mostra como o prompt é estruturado e como habilitamos uma ferramenta de busca web no lado do servidor:
class AnthropicClient(LLMClient):
def gerar_resposta(self, system_prompt: str, user_prompt: str, max_tokens: int = 32000, artigo_contexto: s
"""Gera resposta com web search habilitado (server-side tool da Anthropic)."""
with self.client.messages.stream(
model=self.model,
max_tokens=max_tokens,
system=self.build_system(system_prompt, artigo_contexto),
tools=[{"type": "web_search_20230505", "name": "web_search"}],
messages=[{"role": "user", "content": user_prompt}]
) as stream:
return stream.get_final_text()
def preparar_imagens_para_mensagem(self, imagens: list) -> list:
"""
Prepara lista de imagens para o formato de mensagem da Anthropic.
Tenta usar URL direta para CDN da cdn-ec.alura.com.br, fallback para base64.
"""
content_blocks = []
for img in imagens:
if not img:
continue
Esse cliente centraliza a integração com o provedor e abstrai detalhes como ferramentas auxiliares e formatação de mensagens, mantendo o restante do código desacoplado.
Abaixo estão os arquivos do Docker, incluindo o Docker Compose, com todas as configurações que ajudam a fazer o quê? A montar o projeto no Docker, subir os serviços, instalar tudo o que é necessário, inclusive os requirements.txt. Aqui estão todas as bibliotecas Python usadas no projeto, então serão feitas todas as instalações necessárias dentro do Docker para montar o processo, levantá-lo e deixá-lo funcionando na nuvem sempre que fizermos uma alteração no código.
No Docker Compose, o serviço do runner define variáveis de ambiente (incluindo chaves de provedores de IA), volume de arquivos e a rede interna pela qual o n8n acessa a API via hostname interno:
services:
runner:
build:
context: ./runner
image: runner-playwright:latest
working_dir: /files/runner
environment:
- OPENAI_API_KEY=${OPENAI_API_KEY}
- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
- LLM_PROVIDER=${LLM_PROVIDER:-anthropic}
- ALURA_EMAIL=${ALURA_EMAIL}
- ALURA_PASSWORD=${ALURA_PASSWORD}
- DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-runner}
- REVISAO_ARTIGOS_ANTHROPIC_API_KEY=${REVISAO_ARTIGOS_ANTHROPIC_API_KEY:-}
- REVISAO_ARTIGOS_OPENAI_API_KEY=${REVISAO_ARTIGOS_OPENAI_API_KEY:-}
- CLASSIFICADOR_COMPETENCIAS_ANTHROPIC_API_KEY=${CLASSIFICADOR_COMPETENCIAS_ANTHROPIC_API_KEY:-}
- CLASSIFICADOR_COMPETENCIAS_OPENAI_API_KEY=${CLASSIFICADOR_COMPETENCIAS_OPENAI_API_KEY:-}
volumes:
- ./local-files/files
depends_on:
- postgres
# (A) Somente rede interna (acesso via http://runner:8000 do n8n)
networks:
n8n_net:
aliases: [runner]
Repare que a rede interna e o alias runner permitem que o n8n consuma a API sem expô-la publicamente, alinhado ao que comentamos sobre a comunicação dentro da mesma máquina/infra.
E, para que o ambiente Docker consiga instalar tudo, mantemos as dependências no requirements.txt, como mostrado a seguir:
fastapi
uvicorn
beautifulsoup4
lxml
python-multipart
openai
anthropic
python-docx
https
Pillow
defusedxml
cairosvg
Unidecode
playwright
asyncpg
Por exemplo, se precisarmos criar um endpoint novo amanhã, adicionamos @router.post ou .get, damos um nome, escrevemos a função e testamos no nosso ambiente. Se tudo estiver certo, fazemos o deploy. Queremos que essa novidade funcione na nuvem, na nossa VPS. Como fazemos? Vamos ao Git; esse processo está versionado. Temos um repositório no GitHub, que é o n8nrunner.alura. Todo esse processo está lá. Alguns arquivos não sobem, pois são sensíveis, então não os enviamos, mas tudo o que é necessário para executar sim.
Quando fazemos o push, configuramos o processo para usar GitHub Actions, que é acionado a cada envio. Sempre que subimos uma modificação, ao entrar em Actions (na aba Actions), veremos um workflow novo sendo executado. Assim, fizemos a alteração, criamos um endpoint novo, subimos, e um workflow iniciará. O que ele fará? Verificará os arquivos de configuração, os do Docker, o Compose, todos os arquivos de configuração; fará o upload do que for preciso; instalará tudo o que for necessário na VPS; levantará o serviço novamente e reiniciará para reconhecer as mudanças, deixando tudo funcionando automaticamente para nós.
Quando o indicador estiver em verde novamente no processo que colocamos para rodar, estará tudo ok na nuvem, funcionando. Basta acessar o N8n, gerenciar a aplicação e tudo já estará operando no workflow em que estamos trabalhando. Lembramos daquele fluxo de exemplo, o do HTML para DOCX. Se fizermos alguma modificação naquela entrada, ela será enviada com o GitHub Actions, fará as mudanças na nuvem, na nossa VPS, e ficará disponível para acesso. Em poucos minutos estará disponível, e poderemos executar o processo já com as alterações.
Também configuramos as variáveis de ambiente. Nos secrets do Actions, mantemos todas as variáveis configuradas: a chave da OpenAI, a chave da Anthropic (porque estamos acessando as APIs), além de outras chaves de outros projetos. Basicamente, essa é a configuração.
O processo por trás da nossa API funciona assim: usamos o hosting (hospedagem), a VPS, temos código em Python, trabalhamos bastante com Cloud Code e com inteligência artificial para ajudar a construir, organizar e manter esse código. As modificações são enviadas ao repositório Git; um processo no GitHub Actions monta tudo novamente na nuvem, sobe o projeto e o inicia para que fique disponível para o Git e para que o N8n o consuma.
Eu espero que você tenha gostado do conteúdo. Se precisar falar comigo, meu LinkedIn estará no meu perfil da Alura; é só acessar e me contatar. Terei prazer em conversar com você e esclarecer qualquer ponto que tenha ficado com dúvida nesta explicação. Podemos inclusive trocar ideias e ver um pouco mais do código em detalhes; é só me avisar. Espero que você tenha gostado, e nos vemos em outros cursos da Alura. Até então!
O curso Revisão de SEO com IA: construindo um assistente de conteúdo para otimizar tráfego orgânico possui 87 minutos de vídeos, em um total de 3 atividades. Gostou? Conheça nossos outros cursos de SEO em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Programação, Data Science, Front-end, DevOps, Mobile, Inovação & Gestão, UX & Design, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
