[C26002-ATVX] EscopoVix

EscopoVIX é uma solução baseada em Inteligência Artificial criada para automatizar a análise de solicitações recebidas por e-mail. Utilizando modelos de linguagem avançados, o sistema interpreta o conteúdo das mensagens e seus anexos, comparando-os com a base de serviços oferecidos pela empresa. Dessa forma, ele classifica automaticamente as demandas como dentro ou fora do escopo de atendimento, auxiliando a área comercial na triagem de oportunidades e reduzindo o tempo gasto com análises manuais.

C26002-ATVX

1. Visão Geral

O objetivo do projeto é validar automaticamente se uma solicitação recebida por e-mail está dentro ou fora do escopo de atendimento da empresa.

Essa validação é realizada por meio da análise do conteúdo do e-mail e de seus anexos, utilizando um modelo de linguagem (LLM) que compara a solicitação com uma base de serviços prestados pela empresa, armazenada em uma planilha estruturada.

O sistema utiliza como base:

2. Problema Resolvido

O sistema automatiza a análise preliminar normalmente realizada por um atendente comercial.

Antes da automação, a equipe precisava:

Esse processo gerava:

Com a solução implementada, o sistema realiza uma classificação inicial automática, reduzindo significativamente o tempo gasto na triagem de propostas fora do escopo.

3. Arquitetura da Solução

A solução é composta por diferentes componentes responsáveis pela ingestão, armazenamento, processamento e análise dos dados.

Componentes da Arquitetura

GitHub

Repositório responsável por armazenar os scripts de transformação de arquivos anexos em formato textual.

As transformações incluem:

Essa etapa garante que os dados possam ser interpretados pelo modelo de linguagem.

Power Automate

Responsável pela captura automática dos e-mails recebidos na caixa:

comercial@autvix.com.br

Ao detectar um novo e-mail, o fluxo automatizado:

  1. Cria uma pasta no OneDrive
  2. Salva o corpo do e-mail
  3. Salva todos os anexos

A estrutura de armazenamento segue o padrão:

<Hora>_<Minuto>$<Data>$<Remetente>
Exemplo:
12_47$13_03_2026$petronect@petronect.com.br

Dentro da pasta são armazenados:

corpo_email.html
anexos enviados pelo remetente

OneDrive

Funciona como camada de armazenamento intermediária do pipeline.

Todos os e-mails processados ficam armazenados nesta estrutura de pastas, permitindo:

Servidor Ubuntu

Servidor responsável por hospedar o modelo de linguagem utilizado para análise dos e-mails.

Funções do servidor:

A sincronização dos arquivos é realizada através da ferramenta onedrive.

Modelo de Inteligência Artificial

O sistema utiliza o modelo:

gpt-oss:120b

O modelo recebe como entrada:

A partir dessas informações, o modelo avalia se a solicitação:

4. Fluxo do Processo

  1. Um e-mail é recebido na caixa comercial@autvix.com.br e comercial@advixsolucoes.com.br
  2. O Power Automate detecta automaticamente o novo e-mail.
  3. O fluxo cria uma pasta no OneDrive contendo:
    • corpo do e-mail
    • anexos enviados
  4. O servidor Ubuntu sincroniza automaticamente os dados utilizando onedrive.
  5. Os arquivos são processados e convertidos para texto.
  6. O conteúdo do e-mail e anexos é enviado ao LLM junto com a base de serviços da empresa (BUS), bem como o prompt agent e histórico de solicitações.
  7. O modelo analisa a solicitação e realiza a classificação.
  8. O sistema retorna uma decisão preliminar:

5. Classificação dos E-mails

Os e-mails são classificados em quatro categorias principais.

Dentro do Escopo

Solicitações compatíveis com os serviços oferecidos pela empresa.

Exemplos:

Resultado:

Prosseguimento da prospecção comercial.

Fora do Escopo

Solicitações que não fazem parte do portfólio de serviços da empresa.

Exemplos:

Resultado:

Resposta automática recusando educadamente a solicitação.

Não é Solicitação

E-mails que não representam uma demanda comercial.

Exemplos:

Resultado:

Ignorar ou arquivar.

Oportunidade Externa

Quando a solicitação não está diretamente no e-mail, mas sim em:

Resultado:

Encaminhamento para análise manual.

6. Tecnologias Utilizadas

Infraestrutura

Automação

Repositório de código

Inteligência Artificial

7. Pipeline de Processamento

mermaid-diagram.png

8. Pontos de Atenção / Limitações

Algumas limitações do sistema incluem:

9. Melhorias Futuras

Possíveis evoluções da solução:

image.png

Estudos

Estudos

Agents

Estudos

Tokens em Modelos de Linguagem e sua Importância para Agentes de IA

1. O que são tokens

Tokens são as menores unidades de texto que um modelo de linguagem consegue processar.

Um texto como:

"Aprender IA é incrível!"

Pode ser transformado em algo como:

["Aprender", " IA", " é", " incrível", "!"]

Ou até em pedaços menores, dependendo do modelo.

Importante:
O modelo não entende palavras diretamente — ele entende tokens.

2. Tipos de tokens

2.1 Tokens comuns (tokens de texto)

São os tokens que representam conteúdo normal:

Exemplo:

"inteligência"→ ["inteli", "gência"]

2.2 Tokens especiais

São tokens que não representam texto comum, mas sim estrutura ou controle.

Eles funcionam como instruções internas para o modelo.

3. Principais tipos de tokens especiais

3.1 BOS (Beginning Of Sequence)

Indica o início da entrada.

<bos>

Serve para avisar ao modelo:

"Aqui começa o conteúdo"

3.2 EOS (End Of Sequence)

Indica o fim da geração.

<eos>

Função:

Analogia:
É como o ponto final de uma frase, mas com poder de encerrar completamente a resposta.

3.3 PAD (Padding)

Usado para completar sequências até um tamanho fixo.

<pad>

Muito usado em treinamento.

3.4 Tokens de papel (role tokens)

Usados em chats:

<user><assistant><system>

Servem para indicar:

3.5 Tokens delimitadores

Alguns modelos usam formatos próprios:

[INST] ... [/INST]

ou

<s> ... </s>

Eles delimitam blocos de instrução.

4. Como isso funciona em um modelo de chat

Por trás de uma conversa simples, o modelo recebe algo como:

<system> Você é um assistente útil </system><user> O que é IA? </user><assistant>

O modelo então completa:

IA é o campo da computação que... <eos>

5. Por que tokens especiais são importantes

5.1 Estrutura da conversa

Sem tokens especiais:

Usuário: Oi Assistente: Olá Usuário: Tudo bem?

Para o modelo isso vira um texto confuso.

Com tokens:

<user> Oi </user><assistant> Olá </assistant><user> Tudo bem? </user>

Agora há estrutura clara.

5.2 Controle da geração

O token <eos> permite:

5.3 Definição de comportamento

O token <system> pode mudar completamente o modelo:

<system> Seja formal </system>

Isso altera o estilo da resposta.

5.4 Compatibilidade entre modelos

Cada modelo tem seu próprio formato.

Exemplo:

Por isso existem chat templates:

eles adaptam a entrada para o formato correto do modelo

6. Importância para agentes de IA

Agentes de IA dependem fortemente desses tokens porque:

6.1 Mantêm contexto

Permitem separar:

6.2 Controlam comportamento

O agente pode:

Tudo via estrutura de tokens.

6.3 Evitam ambiguidade

Sem tokens especiais, o modelo pode:

6.4 Permitem automação

Ferramentas, memória e raciocínio estruturado dependem de:

7. Insight avançado

Tokens especiais são uma forma de:

"programar o modelo usando texto"

Eles funcionam como uma camada de controle sem precisar alterar o código do modelo.

8. Conclusão

Estudos

Pensamento-Ação-Observação: ReAct

ATA

Este capítulo contém as ATAS das reuniões realizadas com os stakeholders do projeto. 

ATA

ATA - 23/03/2026

Ata de Reunião

Data da Reunião: 23/03/2026
Pauta: Definição do fluxo inicial do projeto, requisitos técnicos, classificação de e-mails e organização do processo comercial
Participantes: Lucas C. Arruda, Gustavo Schwartz, Marcos Monfardini, Vinícius Caetano, Wanderson Silva e Romeu Roveda

🎯 Objetivos

🗒️ Acompanhamento e Definições

✅ Encaminhamentos

📎 Observações Finais


ATA

ATA - 30-03-2026

Ata de Reunião
Data da Reunião: 30-03-2026
Pauta: Validação de fluxograma, análise de requisitos para dashboard e definição de acessos aos portais
Participantes: Lucas C. Arruda, Victor, Wanderson, Marcos, Gustavo e Romeu

🎯 Objetivos

🗒️ Acompanhamento e Definições

✅ Encaminhamentos

📎 Observações Finais

ATA

ATA - 06/05

ATA DE REUNIÃO

Projeto: C26002-ATVX – Implantação de IA no Comercial

Campo Informação
Data 06 de maio de 2026
Horário 17h01
Duração 2h08min28s
Formato Reunião remota com compartilhamento de tela
Participantes identificados Lucas C. Arruda – Autvix Group; Gustavo L. Schwartz – Autvix Group
Fonte Transcrição da gravação da reunião

1. Objetivo da reunião

Revisar o estado atual do sistema de implantação de IA no Comercial, incluindo arquitetura, requisitos funcionais e não funcionais, modelo de dados, fluxo de ingestão de e-mails, observabilidade, dashboards e evolução dos filtros de classificação. A reunião também teve como objetivo definir ajustes técnicos, prioridades de implementação e próximos prazos do projeto.

2. Pauta tratada

3. Principais discussões

3.1 Arquitetura e fluxo atual

Foi revisado que o fluxo atual envolve captura de e-mails, geração de pastas, sincronização via OneDrive, detecção por mecanismo baseado em Inotify/Fuse Poller, validação dos dados e inserção em banco MySQL. Também foram citados Metabase e Grafana para visualização e observabilidade. Foi destacado que o fluxo atual funciona, mas possui uma cadeia de serviços extensa e complexa.

3.2 Complexidade técnica e necessidade de simplificação

Lucas destacou que o projeto apresenta profundidade técnica em pontos como logs, migrations e observabilidade, mas ainda possui pendências em elementos essenciais do entregável, como estruturação definitiva da base e do filtro principal. Foi defendida a priorização do esqueleto funcional e entregável ao cliente antes de novas camadas de refinamento técnico.

3.3 Migração para Microsoft Graph API / Power Automate

A equipe convergiu que a migração do fluxo atual para uma abordagem baseada em Microsoft Graph API, possivelmente via Power Automate, deve reduzir a complexidade lógica e operacional. A substituição reduziria dependências de OneDrive, Fuse Poller e Watch/Inotify, além de facilitar rastreabilidade e confiabilidade do processamento.

3.4 Revisão do banco de dados

A tabela de e-mails foi tratada como principal por valor agregado, pois concentra as informações recebidas e serve como base para auditoria, dashboards e relacionamento com classificações. Foi reforçado que o banco não deve ser o mecanismo principal de processamento do modelo, mas sim um repositório histórico, de auditoria e análise futura.

3.5 Campos da tabela de e-mails

Foi discutida a manutenção de campos como ID, contato_id, classificacao_id, destinatário, subject, data de recebimento, data de processamento, folder_path, quantidade de anexos, nomes dos anexos e ID da mensagem. Foi sugerida a remoção de body_html e body_text, pois os arquivos correspondentes já ficam salvos na pasta, evitando duplicidade e ambiguidade.

3.6 Contatos, clientes e domínios

Foi diferenciada a entidade contato da entidade cliente: contato representa quem envia e-mails, enquanto cliente representa a base de clientes cadastrados. Ficou indicado que os domínios de remetentes devem ser relacionados posteriormente a clientes, com apoio de pessoas da área comercial, já que a equipe técnica não possui domínio completo para essa vinculação.

3.7 Classificação e filtros de IA

Lucas apresentou testes com regressão logística, banco vetorial, LLM e combinação dos modelos. Foi mencionada acurácia combinada em torno de 91% em amostra de teste e acurácia de 96% na regressão logística sobre 1.097 dados. Também foi reforçada a necessidade de testar com dados não usados no treinamento para validar a real capacidade de generalização.

3.8 Métricas, dashboards e observabilidade

A dashboard é considerada requisito do sistema para visualização dos e-mails e indicadores. Foram discutidas métricas como quantidade de anexos, nomes/extensões de arquivos, status de processamento e saúde dos serviços. A observabilidade atual usa Grafana e registros em tabela de status dos serviços.

3.9 Integrações externas e limitações

Foi comentada a limitação relacionada a APIs de portais externos, especialmente Petrobras/Petronet. A equipe reconheceu que parte desses problemas depende de terceiros, mas que será necessário acompanhar e cobrar resolução para viabilizar etapas futuras.

4. Decisões e alinhamentos

  1. Priorizar a entrega funcional do projeto antes de aprofundar novas camadas de refinamento técnico.
  2. Migrar o fluxo atual para Microsoft Graph API/Power Automate, substituindo dependências excessivas de OneDrive, Fuse Poller e Watch/Inotify sempre que possível.
  3. Tratar a tabela de e-mails como a tabela principal para histórico, auditoria, dashboards e relacionamento com classificações.
  4. Manter o folder_path como referência para localização dos arquivos do e-mail e para consultas futuras, especialmente após classificação.
  5. Revisar a base de dados para eliminar inconsistências, especialmente duplicidade de message_id, reconstruindo a base se necessário a partir dos dados salvos.
  6. Remover ou deixar de utilizar campos redundantes como body_html e body_text enquanto não houver necessidade clara de uso no banco.
  7. Distinguir contato de cliente no modelo de dados, mantendo contato como remetente/domínio e cliente como entidade de cadastro comercial.
  8. Delegar a vinculação de domínios a clientes para pessoas com conhecimento comercial, como Juliana e/ou Vidal, por meio de planilha de validação.
  9. Focar inicialmente na classificação “solicitação” versus “não solicitação”, antes de aprofundar o filtro de dentro/fora do escopo.
  10. Reexecutar testes da pipeline de classificação com dados não utilizados no treinamento, para medir acurácia de forma mais confiável.

5. Encaminhamentos e responsáveis

# Ação Responsável Prazo
1 Implementar a migração do fluxo atual para Graph API/Power Automate, reduzindo dependências de OneDrive/Fuse/Watch. Gustavo Até 07/05/2026, 17h
2 Recarregar ou reconstruir a base de e-mails, validando duplicidades e consistência do message_id e do folder_path. Gustavo Após migração para Graph API
3 Revisar o modelo de dados da tabela de e-mails, removendo campos redundantes e mantendo os campos essenciais para auditoria e dashboard. Lucas e Gustavo Curto prazo
4 Exportar lista de domínios/contatos e solicitar validação de associação com clientes à área comercial. Gustavo, com apoio de Juliana/Vidal A definir
5 Revisar prompt/system prompt e repetir testes da pipeline de classificação. Lucas Antes da próxima validação técnica
6 Separar dados não utilizados no treinamento para nova rodada de testes de acurácia. Lucas, com apoio operacional a definir Curto prazo
7 Iniciar desenvolvimento de novo filtro após estabilização da ingestão e validação inicial da classificação. Lucas Após testes e base ajustada
8 Buscar bios/dados da Davis/Multimix ou focar inicialmente em uma única empresa para simplificar o recorte do teste. Lucas/Romeu Até 11/05/2026, se possível
9 Acompanhar pendências com APIs externas, especialmente Petronet/Petrobras. Lucas Contínuo
10 Preparar dashboard robusta para apresentação, com base nos dados disponíveis. Gustavo Até 11/05/2026

6. Prazos combinados

Data Entrega/Marco
07/05/2026, até 17h Conclusão estimada da migração inicial para Graph API/Power Automate e ajustes de base.
11/05/2026, até 17h Meta de ter pré-classificador em conjunto com a base ajustada; possibilidade de dashboard robusta.
29/05/2026 Meta indicativa para ter algo rodando no Comercial. O prazo foi reconhecido como desafiador, especialmente para a parte de IA.

7. Pontos em aberto

8. Encerramento

A reunião foi encerrada após a definição dos próximos passos técnicos, com foco na simplificação da arquitetura, revisão do modelo de dados, melhoria da confiabilidade da ingestão de e-mails e continuidade dos testes de classificação. A próxima etapa prática é a migração para Graph API/Power Automate, seguida da validação da base e avanço do pré-classificador.

Ata elaborada a partir da transcrição da reunião.

ATA

ATA 20/05

Ata de Reunião — Implantação de IA no Comercial

Projeto: C26002-ATVX — Implantação de IA no Comercial
Data: 20/05/2026
Duração: 1h13min35s
Participantes:

Fonte: Transcrição da reunião “Reunião em [C26002-ATVX] Implantação de IA no Comercial”. :contentReference[oaicite:0]{index=0}

1. Objetivo da reunião

Alinhar o andamento do projeto de IA aplicado ao processo comercial, com foco em:

2. Pontos discutidos

2.1 Benchmark e avaliação dos modelos

Foi discutida a necessidade de comparar diferentes modelos utilizados no processamento das solicitações.

O foco da prova de conceito, neste momento, não é avaliar se a resposta está “bonita” ou bem redigida, mas sim se ela é verídica e correta em relação ao conteúdo analisado.

Foi mencionado que as saídas devem seguir um formato padronizado, preferencialmente em JSON, para facilitar o tratamento posterior via código, regex ou integração com outros componentes do sistema.

Também foi levantada a necessidade de separar os resultados por modelo, criando pastas ou estruturas distintas para permitir comparação entre as execuções.

2.2 Fluxo atual de processamento de e-mails

Foi explicado que o sistema atual possui um endpoint responsável por receber o caminho da pasta do e-mail processado.

O fluxo descrito foi:

  1. receber o caminho da pasta do e-mail;
  2. localizar o arquivo HTML;
  3. extrair o texto do e-mail;
  4. aplicar filtros iniciais;
  5. verificar se é e-mail interno;
  6. verificar se é resposta;
  7. classificar se é ou não uma solicitação;
  8. aplicar modelos de classificação;
  9. gerar confiança consolidada com base nas classificações.

A classificação atual utiliza uma combinação de abordagens, incluindo:

2.3 Uso de LLM e regressão logística

Foi discutido que a regressão logística depende de um dataset treinado especificamente para a tarefa desejada.

O dataset atual classifica se um e-mail é ou não uma solicitação. Para classificar se uma solicitação Petronect é pública ou convite/dispensa, seria necessário outro dataset, pois se trata de uma classificação diferente.

Também foi discutida a possibilidade de criar uma chamada para LLM com prompt específico para essa nova classificação.

No entanto, para o caso específico da Petronect, foi entendido que talvez não seja necessário iniciar com modelo de IA, já que os e-mails possuem padrões textuais que podem ser tratados por regra simples.

3. Petronect — classificação de oportunidades públicas e convites

3.1 Problema identificado

Inicialmente, havia a hipótese de usar a API da Petronect para diferenciar oportunidades públicas de convites ou dispensas.

A lógica proposta era:

Durante a reunião, foi identificado que essa lógica não era suficientemente segura, pois houve casos em que uma oportunidade aparentemente pública não retornou corretamente pela API.

Com isso, concluiu-se que a API não deve ser a única fonte de decisão para classificar a oportunidade.

3.2 Decisão sobre o filtro Petronect

Foi decidido que a classificação entre pública e convite/dispensa deve considerar o corpo do e-mail.

A regra inicial definida foi:

Foi comentado que essa verificação pode ser implementada com uma lógica simples, como busca textual, regex ou consulta no banco, desde que o corpo do e-mail esteja salvo.

3.3 Uso da API da Petronect

A API continuará sendo considerada útil para buscar informações adicionais da oportunidade pública.

Entretanto, ela não será usada isoladamente para definir se a oportunidade é pública ou convite.

Fluxo acordado:

  1. identificar se o e-mail é uma solicitação;
  2. verificar se é Petronect;
  3. analisar o corpo do e-mail;
  4. classificar como oportunidade pública, convite ou dispensa;
  5. quando for pública e houver retorno da API, buscar dados complementares;
  6. quando não houver retorno da API, não assumir automaticamente que não é pública;
  7. salvar a classificação para consulta posterior.

4. MVP e limites do escopo

Foi reforçado que o projeto deve seguir com uma abordagem de MVP, priorizando a entrega funcional antes de buscar refinamentos excessivos.

A decisão foi trabalhar com as informações atualmente disponíveis, mesmo que a base da empresa ainda não esteja totalmente estruturada.

Foram citados alguns pontos que podem gerar limitações:

A orientação foi: primeiro entregar uma solução funcional e, quando os gargalos aparecerem em produção, tratar as melhorias com base em evidências.

5. Famílias Petronect

Foi discutido que a Petronect trabalha com famílias de fornecimento e que a empresa pode estar cadastrada em diferentes famílias.

Foi levantada a possibilidade de, futuramente, existir uma rotina para verificar ou atualizar automaticamente o cadastro da empresa nas famílias da Petronect.

No entanto, foi definido que esse tema não entrará como prioridade do MVP, pois a empresa ainda não possui documentação interna suficiente indicando:

A conclusão foi que esse tipo de refinamento depende de informações do negócio e poderá ser tratado futuramente.

6. BU e qualidade das classificações

Foi identificado que a BU atual pode estar genérica demais.

Exemplo discutido: uma BU que menciona “projetos elétricos” pode levar o modelo a concluir que a empresa atende uma solicitação de painel elétrico, mesmo que esse item não faça parte do escopo real da empresa.

Foi entendido que esse problema não é exclusivamente do software, mas também da qualidade da informação fornecida ao modelo.

A melhoria da BU foi considerada importante, mas não impeditiva para o MVP.

7. Requisitos de qualidade e SGQ

Foi discutido que algumas solicitações podem exigir requisitos específicos de qualidade, associados ao SGQ ou a categorias técnicas.

Foi citado que a empresa pode atender determinado item, mas não atender um requisito de qualidade específico exigido naquela oportunidade.

Apesar disso, ficou decidido que, no MVP, o sistema não fará essa validação detalhada.

A classificação inicial será baseada principalmente em aderência ao escopo da empresa.

Validações mais específicas, como requisitos de qualidade, famílias, tipos de fornecimento ou restrições técnicas, poderão ser adicionadas em fases futuras.

8. Interface, dashboard e acompanhamento

Foi discutida a existência de uma interface para visualização das classificações e acompanhamento dos e-mails.

Foi levantada a comparação com Metabase, mas foi apontado que a necessidade principal não é apenas visualizar gráficos, e sim permitir que o usuário veja os e-mails classificados, filtre por status e acompanhe o processo de triagem.

Também foi mencionado que ferramentas como Plums ou sistemas comerciais podem receber apenas aquilo que já está dentro do escopo, enquanto o sistema de IA precisa lidar também com:

9. Decisões tomadas

  1. A classificação Petronect não dependerá exclusivamente da API.
  2. O corpo do e-mail será usado para identificar se a solicitação é pública ou convite.
  3. Termos como “licitação pública” e “oportunidade pública” indicarão oportunidade pública.
  4. Termos como “sua empresa foi convidada” indicarão convite ou dispensa.
  5. A API será usada para buscar dados complementares, mas não como única regra de classificação.
  6. O MVP não tratará, neste primeiro momento, regras avançadas de famílias Petronect.
  7. O MVP não tratará, neste primeiro momento, requisitos específicos de qualidade/SGQ.
  8. O sistema será desenvolvido com base na realidade atual das informações disponíveis.
  9. Melhorias de BU, famílias e requisitos técnicos serão tratadas futuramente, conforme surgirem gargalos.
  10. A classificação deverá ser salva para consulta posterior em banco, dashboard ou interface de acompanhamento.

10. Encaminhamentos

Item Responsável Encaminhamento
1 Gustavo Implementar filtro para identificar e-mails Petronect.
2 Gustavo Criar regra para classificar oportunidade pública com base no corpo do e-mail.
3 Gustavo Criar regra para classificar convite/dispensa com base no corpo do e-mail.
4 Gustavo Avaliar se a regra será feita por regex, busca textual ou lógica no banco.
5 Lucas Apoiar na definição do fluxo geral e validação da lógica.
6 Lucas/Gustavo Definir nomenclatura final para as categorias Petronect.
7 Lucas/Gustavo Manter a API como fonte complementar para busca de informações da oportunidade.
8 Lucas/Gustavo Deixar melhorias de famílias, BU e SGQ para etapas futuras.

11. Pendências

12. Conclusão

A reunião consolidou que o projeto deve seguir com foco em entrega de MVP, evitando aprofundar neste momento em regras complexas de negócio que dependem de documentação ainda inexistente ou incompleta.

Para as solicitações da Petronect, ficou definido que a classificação entre oportunidade pública e convite/dispensa deve ser feita inicialmente por análise do corpo do e-mail, usando padrões textuais identificáveis. A API será mantida como apoio para buscar informações adicionais, mas não como única fonte de decisão.

O objetivo imediato é colocar o fluxo em produção com regras simples, validar o comportamento com dados reais e evoluir o sistema conforme os gargalos aparecerem.

Levantamento de requisitos - Modelo Atual


1. Visão Geral e Escopo


Objetivo: Automatizar a triagem de e-mails comerciais das empresas Autvix e Advix Soluções , utilizando LLM para classificar demandas contra uma base de serviços (BUS).


Principais Metas:

2. Requisitos Funcionais (RF)

ID

Descrição

Referência Técnica

RF01

Capturar e-mails e anexos das caixas comerciais e salvar no OneDrive.

Power Automate

RF02

Identificar o remetente e validar se o domínio já existe na base de contatos.

Tabela contacts

RF03

Converter anexos (.pdf, .xlsx, .zip) para texto para processamento pelo LLM .

Scripts Python

RF04

Classificar e-mails em categorias pré-definidas com nível de confiança e justificativa.

LLM gpt-oss:120b

RF05

Monitorar a saúde dos serviços de ingestão e processamento.

Tabela service_heartbeat

RF06

Armazenar o corpo do e-mail em HTML e texto plano para rastreabilidade.

Tabela emails

3. Requisitos Não Funcionais (RNF)

4. Modelo de Dados (Arquitetura do Banco)

O banco de dados MySQL é o coração da persistência do EscopoVix, estruturado da seguinte forma:

A. Núcleo de Comunicação

B. Inteligência e Classificação

C. Apoio e Monitoramento

5. Fluxo de Dados e Pipeline

  1. Ingestão: Power Automate salva e-mail no OneDrive.
  2. Detecção: O watcher detecta a nova pasta.
  3. Identificação: O sistema busca ou cria o registro em contacts via domínio do e-mail.
  4. Processamento: O LLM analisa o texto e gera um registro em classifications com o reasoning.
  5. Finalização: O registro em emails é atualizado com o classificacao_id e marcado como processado.