Avaliação das Tecnologias Utilizadas no Projeto

[samuelveigarangel]

O projeto tem como objetivo disponibilizar um modelo de IA capaz de realizar a marcação de citações em documentos. Considerando esse escopo, surgem algumas dúvidas em relação às tecnologias propostas para a arquitetura da solução, principalmente quanto à necessidade e adequação de algumas delas.

A principal delas é o Wagtail. Como o projeto não possui, a princípio, a finalidade de gerenciar conteúdo ou páginas web, sua utilização parece adicionar uma camada de complexidade sem trazer benefícios proporcionais. Dessa forma, seria importante justificar tecnicamente a escolha do Wagtail ou reavaliar sua necessidade dentro da arquitetura.

Outro ponto diz respeito ao uso do Redis e do Celery. É necessário esclarecer qual será o papel dessas tecnologias no projeto. Elas serão utilizadas para processar documentos de forma assíncrona? Existe o requisito de submissão simultânea de múltiplos documentos ou de execução de tarefas em segundo plano? Ainda seria importante avaliar se esse nível de complexidade é realmente necessário para a primeira versão da aplicação ou se um processamento síncrono atenderia aos requisitos iniciais. Além disso, caso haja previsão de aumento significativo de carga, vale discutir aspectos como escalabilidade, monitoramento das filas, tratamento de falhas e reprocessamento de tarefas.

Em relação ao framework da aplicação, a escolha deveria considerar o ambiente em que a solução será utilizada.

Caso o objetivo seja fornecer uma solução para execução local, por exemplo para um único usuário ou para utilização em ambiente de pesquisa e desenvolvimento, uma alternativa mais adequada seria o Flask. Por ser um framework leve e flexível, ele oferece apenas os componentes essenciais para a construção da aplicação, evitando a sobrecarga de funcionalidades que não serão utilizadas.

Por outro lado, se houver a necessidade de disponibilizar a aplicação para uma equipe ou em um ambiente corporativo, o Django passa a ser uma opção mais interessante. O framework oferece diversas funcionalidades prontas, como autenticação e gerenciamento de usuários, controle de permissões, painel administrativo, ORM para acesso ao banco de dados e uma estrutura mais robusta para aplicações multiusuário.

[pitangainnovare]

Pelo que conheço do projeto, ele tem como objetivo maior ser uma plataforma para ler documentos DOCX — e, quem sabe, outros formatos no futuro —, extrair sua estrutura, gerar XML SciELO/SPS, validar com packtools e produzir os objetos finais de publicação, como XML, PDF, HTML e o pacote SPS, além de realizar a marcação de citações.

Assim, concordo que alguma simplificação da stack poderia ser benéfica. Eu separaria o sistema em camadas mais claras. O núcleo poderia ser o conversor/validador: leitura do DOCX, extração de metadados, marcação SPS/JATS, apoio de IA quando fizer sentido, validação e geração dos artefatos finais. A API poderia ser o contrato principal para acionar esse núcleo — ou seja, essas operações seriam feitas por chamadas à API, e não por módulos espalhados pelo projeto —, consultar status e integrar com outros sistemas. Os workers assíncronos, usando Celery e Redis, parecem necessários, pois parte dessas etapas é demorada ou concorrente e também pode envolver o uso de IA com GPU ou CPU.

Já para a interface web de uma versão suficiente do projeto, talvez algo como Django com templates já resolva bem: gestão de usuários, envio de documentos, acompanhamento do processamento e revisão dos objetos gerados. O Wagtail costuma adicionar recursos interessantes, mas também tende a engessar um pouco a incorporação de novas telas personalizadas. Na prática, muitas vezes uma tela customizada acaba fazendo mais sentido. Sofri um pouco com isso no projeto Upload, que, apesar de também usar Wagtail, acabou tendo quase todas as telas feitas com templates customizados. No Wagtail 5 isso era mais simples; no 6 ficou mais trabalhoso com as Snippet Views.

Então, eu diria que o Wagtail se justificaria se houver uma necessidade clara de CMS ou de fluxo editorial nativo. Caso contrário, ele tende a aumentar a complexidade e tamanho do projeto (e concordo com o "sem trazer benefício proporcional"). Em especial, digo isso porque eu tendo a preferir fazer layouts e views do zero do que reaproveitar a camada CMS do Wagtail.

Talvez valha também separar melhor os modos de uso esperados. Uma coisa é uma versão standalone desktop, instalada na máquina do usuário, para uso individual e com processamento local. Outra é uma versão web local single user, em que a aplicação roda localmente, mas é acessada pelo navegador, ainda sem necessidade de usuários, permissões complexas ou infraestrutura de servidor. E um terceiro cenário é uma versão web intranet, voltada para uso por equipe, com múltiplos usuários, controle de acesso, filas de processamento, histórico, monitoramento e eventualmente integração com outros sistemas. Essa distinção é importante porque a stack não precisa ser a mesma para todos os cenários: Wagtail parece pouco necessário nos dois primeiros casos; Django com templates pode atender bem a versão web local e a intranet; e Celery/Redis passam a fazer mais sentido quando há processamento concorrente, múltiplos documentos ou necessidade de reprocessamento e acompanhamento das tarefas.