Skip to main content

C26002-ATVX

# 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.

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: -

  • Conteúdo textual do e-mail
  • Anexos - Anexos

    enviados pelo solicitante -

  • Histórico de padrões de solicitações
  • Base - Base

    de serviços da empresa (BUS)


    ------------------------------------------------------------------------


    ##

2. Problema Resolvido


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

 atendente comercial.


Antes da automação, a equipe precisava: -

  • Ler manualmente cada e-mail

     recebido -

  • Analisar anexos -
  • Comparar a solicitação com o portfólio de

     serviços da empresa


Esse processo gerava: -

  • Alto consumo de tempo operacional -
  • Análise

     manual repetitiva -

  • Possível atraso na resposta ao cliente


Com a solução implementada, o sistema realiza uma **classificação

 inicial automática**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


#### GitHub


Repositório responsável por armazenar os scripts de transformação de

 arquivos anexos em formato textual.


As transformações incluem: -

  • .zip`.zip` → descompactação e extração de

     conteúdo -

  • `.html`html → extração do corpo textual -
  • `.pdf`pdf → conversão para texto

  • texto - .excel`.excel` → conversão para `.csv`csv


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

linguagem.


------------------------------------------------------------------------


####

Power Automate


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


    comercial@autvix.com.br


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


  1. 1.  Cria uma pasta no **OneDrive**OneDrive

    2.  

  2. Salva o corpo do e-mail

    3.  

  3. Salva todos os anexos


A estrutura de armazenamento segue o padrão:


    <Hora>_<Minuto>$<Data>$<Remetente>


Exemplo:

    Exemplo:

    12_47$13_03_2026$petronect@petronect.com.br


Dentro da pasta são armazenados:


corpo_email.html

    - corpo_email.html

    - anexos enviados pelo remetente


------------------------------------------------------------------------


####

OneDrive


Funciona como **camada de armazenamento intermediária**ria do pipeline.


Todos os e-mails processados ficam armazenados nesta estrutura de

 pastas, permitindo: -

  • rastreabilidade -
  • histórico de análise -

  • sincronização com o servidor de processamento


    ------------------------------------------------------------------------


    ####

Servidor Ubuntu


Servidor responsável por hospedar o modelo de linguagem utilizado para

 análise dos e-mails.


Funções do servidor: -

  • sincronizar dados do OneDrive
  • realizar - realizar

    transformação de arquivos -

  • executar inferência do modelo de IA -

  • classificar a solicitação


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


    onedriver

    https://software.opensuse.org/download.html?project=home:jstaf&package=onedriver


------------------------------------------------------------------------


#### onedriver.

Modelo de Inteligência Artificial


O sistema utiliza o modelo:


    gpt-oss:120b


O modelo recebe como entrada:


-  

  • conteúdo do e-mail

    -  

  • conteúdo dos anexos convertidos em texto

  • -   base de serviços da empresa (BUS) em formato `.csv`csv


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


-  

  • está dentro do escopo de atendimento

    -  

  • está fora do escopo

    -  

  • não representa uma solicitação válida


    ------------------------------------------------------------------------


    ### Diagrama simplificado da arquitetura


    ``` mermaid

    flowchart LR


    A[Email recebido] --> B[Power Automate]


    B --> C[OneDrive]


    C --> D[Sincronização onedriver]


    D --> E[Servidor Ubuntu]


    E --> F[Transformação de anexos]


    F --> G[LLM GPT-OSS 120B]


    G --> H[Classificação da Solicitação]

    ```


    ------------------------------------------------------------------------


    ##

4. Fluxo do Processo


  1. 1.  Um e-mail é recebido na caixa **comercial@autvix.com.br**br


  2. 2.  O **Power Automate**Automate detecta automaticamente o novo e-mail.


  3. 3.  O fluxo cria uma pasta no **OneDrive**OneDrive contendo:


        -  

    • corpo do e-mail

          -  

    • anexos enviados


  4. 4.  O servidor **Ubuntu**Ubuntu sincroniza automaticamente os dados utilizando

      **onedriver**onedriver.


    5.  

  5. Os arquivos são processados e convertidos para texto.


  6. 6.  O conteúdo do e-mail e anexos é enviado ao **LLM**LLM junto com a base

      de serviços da empresa (BUS).


    7.  

  7. O modelo analisa a solicitação e realiza a classificação.


    8.  

  8. O sistema retorna uma decisão preliminar:


        -  

  • Aceitar prospecção (dentro do escopo)

        -  

  • Recusar educadamente (fora do escopo)


    ------------------------------------------------------------------------


    ##

5. Classificação dos E-mails


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


###

Dentro do Escopo


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


Exemplos:

Exemplo: -

  • pedidos de proposta -
  • solicitações técnicas relacionadas aos

     serviços da empresa

Resultado:


Resultado: Prosseguimento da prospecção comercialcomercial.


------------------------------------------------------------------------


###

Fora do Escopo


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


Exemplos:

Exemplo: -

  • serviços que a empresa não oferece -
  • demandas fora da área de

     atuação

Resultado:


Resultado: Resposta automática recusando educadamente a solicitaçãoo.


------------------------------------------------------------------------


###

Não é Solicitação


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


Exemplos:

Exemplo: -

  • convites -
  • newsletters -
  • comunicações institucionais

Resultado:


Resultado: Ignorar ou arquivararquivar.


------------------------------------------------------------------------


###

Oportunidade Externa


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


-  

  • links

    -  

  • portais externos

    -  

  • plataformas de licitação

Resultado:


Resultado: Encaminhamento para análise manualmanual.


------------------------------------------------------------------------


##

6. Tecnologias Utilizadas


###

Infraestrutura


-  

  • Ubuntu Server

    -  

  • Microsoft 365

    -  

  • OneDrive


    ###

Automação


-  

  • Power Automate


    ###

Repositório de código


-  

  • GitHub


    ###

Inteligência Artificial


Modelo:


  • gpt-oss:120b


    ------------------------------------------------------------------------


    ##

7. Pipeline de Processamento


O pipeline de processamento segue as seguintes etapas:


Ingestão de e-mail\

mail
↓\


Armazenamento no OneDrive\

OneDrive
↓\


Sincronização com servidor\

servidor
↓\


Extração de conteúdo\

do
↓\


Conversão de anexos para texto\

texto
↓\


Envio para modelo LLM\

LLM
↓\


Classificação da solicitação\

o
↓\


Retorno da decisão


------------------------------------------------------------------------


##

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


Algumas limitações do sistema incluem:


-  

  • Dependência da qualidade do texto extraído dos anexos

    -  

  • Possível ambiguidade na interpretação de solicitações

    -  

  • Necessidade de atualização constante da base de serviços (BUS)

    -  

  • Carga computacional elevada para execução de modelos de grande porte

    -  

  • Casos complexos podem exigir validação humana


    ------------------------------------------------------------------------


    ##

9. Melhorias Futuras


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


  • -   Implementação de **RAG (Retrieval Augmented Generation)** para

      melhorar a consulta da base de serviços

  • -   Indexação semântica dos serviços utilizando **embeddings**embeddings

  • -   Criação de **dashboard de monitoramento das classificações**es

  • -   Implementação de **fila de revisão humana para casos ambíguos**guos

    -  

  • Treinamento ou ajuste fino do modelo com histórico de e-mails da

      empresa

  • -   Integração com **CRM comercial**comercial

Back to top