💻 computer science

From Business Problems to AI Solutions: Where Does Transformation Support Fail

Este artigo identifica a "Problema de Tradução Analítica" como uma lacuna crítica na transformação de problemas de negócios em soluções de IA, demonstrando através de uma revisão de literatura que a maioria das metodologias existentes falha em fornecer orientação sistemática para derivar tarefas de aprendizado de máquina e, consequentemente, propõe cinco recomendações de pesquisa para abordar essa deficiência.

Autores originais: Abir Trabelsi, Imen Benzarti, Hafedh Mili, Darine Ameyed

Publicado 2026-04-22

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Abir Trabelsi, Imen Benzarti, Hafedh Mili, Darine Ameyed

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é o dono de uma pizzaria e quer resolver um problema: "Quero que meus clientes voltem mais vezes."

Você contrata uma equipe de "magos dos dados" (cientistas de dados) para criar um sistema de Inteligência Artificial (IA) que resolva isso. Você espera que eles criem um robô mágico que saiba exatamente quem vai voltar e como fazê-lo.

Mas, infelizmente, a história muitas vezes termina assim: os magos constroem um robô superinteligente que prevê perfeitamente qual sabor de pizza o cliente prefere, mas ninguém perguntou se isso ajuda a fazer o cliente voltar. O robô funciona tecnicamente, mas não resolveu o problema do dono da pizzaria.

Este artigo de pesquisa é um "raio-X" de como tentamos conectar o problema do negócio (o desejo do dono) com a solução técnica (o robô), e descobre que essa conexão é o elo mais fraco de todo o processo.

Aqui está a explicação simples, usando analogias:

1. O Grande Problema: A "Tradução Perdida"

O artigo chama esse problema de Analytics Translation Problem (ATP). Pense nisso como uma barreira de idioma.

O Dono da Pizzaria fala a língua dos "objetivos de negócio" (lucro, satisfação, retenção).
O Cientista de Dados fala a língua dos "algoritmos" (classificação, regressão, redes neurais).

O que falta é um tradutor profissional. Hoje, a tradução é feita "na mão", baseada apenas na intuição de quem está no meio. Se o tradutor errar, o robô será perfeito para a tarefa errada.

2. O Mapa do Tesouro (A Pesquisa)

Os autores pegaram 18 métodos diferentes que existem no mundo (alguns focados em engenharia de requisitos, outros em gestão de projetos, outros em automação) e os organizaram em 4 famílias:

Família A (Os Arquitetos de Requisitos): Eles desenham mapas detalhados do que o sistema deve ter, mas não dizem como escolher o motor do carro.
Família B (Os Caçadores de Dados): Eles focam muito em garantir que os ingredientes (dados) estejam frescos, mas assumem que você já sabe qual prato vai cozinhar.
Família C (Os Gerentes de Projeto): Eles têm um cronograma perfeito (passo 1, passo 2, passo 3), mas dizem "faça a escolha do algoritmo" sem dar uma receita de como fazer essa escolha.
Família D (Os Autômatos): Eles são ótimos em ajustar o motor depois que você já escolheu o carro, mas não ajudam a escolher qual carro comprar.

A descoberta chocante: Nenhum desses 18 métodos ensina, de forma sistemática, como transformar a frase "Quero reduzir o cancelamento de assinaturas" em "Vamos usar um algoritmo de classificação binária com estes dados específicos".

3. Onde a Mágica Quebra? (O "Buraco Negro")

Os autores criaram um mapa de 7 etapas para transformar um problema em solução. Eles descobriram que a maioria dos métodos cobre bem o início (entender o problema) e o fim (colocar o robô para rodar), mas falha miseravelmente no meio.

Imagine uma ponte:

De um lado, você tem a Pergunta de Negócio ("Quem vai cancelar?").
Do outro lado, você tem a Tarefa de IA ("Classificação de dados").
No meio, há um abismo.

Os métodos atuais dizem: "Pule o abismo". Eles não dão a corda, nem a balsa. Eles deixam que o cientista de dados pule baseado no "feeling" (intuição). É aí que os projetos falham.

4. A Solução Proposta: 5 Dicas para Construir a Ponte

Para consertar isso, os autores sugerem 5 novas regras (recomendações) para criar um "Guia de Tradução" perfeito:

Explore Múltiplos Caminhos (R1): Não pule para a primeira ideia. Assim como um detetive considera várias teorias, o time deve listar várias formas de resolver o problema (ex: "Podemos prever quem cancela?" OU "Podemos agrupar clientes parecidos?") e comparar as opções antes de decidir.
Regras de Tradução (R2): Criar um "dicionário" claro. Se a pergunta é "Qual o valor?", a tarefa é "Regressão". Se a pergunta é "Isso é normal ou estranho?", a tarefa é "Detecção de anomalia". Nada de adivinhar.
Filtro de Restrições (R3): Antes de escolher o algoritmo, verifique as regras do jogo. Se o sistema precisa ser rápido (menos de 1 segundo) e justo, isso elimina automaticamente certos "monstros" (algoritmos complexos) e deixa apenas os "cavalos" (algoritmos mais simples e rápidos) que funcionam.
Rastreamento Probabilístico (R4): Em vez de prometer "Isso vai funcionar 100%", a IA deve dizer: "Com base no que sabemos, isso tem 85% de chance de funcionar, e se funcionar, vai economizar X reais". Isso conecta a matemática de volta ao dinheiro do dono da pizzaria.
Sinal de "Volte Atrás" (R5): Na IA, os dados podem dizer "Ei, não tem dados suficientes para fazer isso!". O processo precisa ter um botão de "Revisão" automático. Se os dados não suportam a ideia, o time deve voltar ao passo 1 e mudar a pergunta, em vez de insistir em um projeto falho.

Conclusão

Este artigo diz que a Inteligência Artificial não falha porque os robôs são burros, mas porque nós somos ruins em traduzir o que queremos para a linguagem dos robôs.

A solução não é criar robôs mais inteligentes, mas sim criar metodologias melhores que atuem como tradutores profissionais, garantindo que, quando o robô estiver pronto, ele esteja realmente resolvendo o problema que o dono da pizzaria (ou da empresa) queria resolver.

É como passar de "tentar a sorte" para "ter um manual de instruções" para construir pontes entre o mundo dos negócios e o mundo da tecnologia.

Título: De Problemas de Negócio a Soluções de IA: Onde Falha o Suporte à Transformação?

1. O Problema

O artigo identifica uma lacuna crítica no ciclo de vida de projetos de Inteligência Artificial (IA): a tradução de problemas de negócio (BP - Business Problems) para especificações de soluções de aprendizado de máquina (MLS - ML Solution Specifications).

Contexto: Projetos de IA falham a taxas estimadas duas vezes maiores que projetos de TI convencionais. Uma causa raiz recorrente é o desalinhamento entre o que as partes interessadas (stakeholders) desejam resolver (ex: "reduzir o churn de clientes") e a formulação técnica entregue às equipes de ciência de dados.
A Lacuna: A etapa de transformação "BP → MLS" é atualmente ad hoc, dependente da intuição individual e fraca-mente suportada por metodologias existentes. As equipes podem construir modelos tecnicamente sólidos que não atendem ao objetivo de negócio ou gastar tempo excessivo iterando na formulação do problema antes de começar a modelagem.
Natureza do Problema: Diferente da Engenharia de Requisitos (RE) tradicional, que refina objetivos em requisitos funcionais, esta transformação exige uma derivação cross-domínio. É necessário traduzir caracterizações de negócio (linguagem de metas, decisões, restrições) em constructos estatísticos e algorítmicos (paradigmas de ML, tipos de tarefa, métricas) que não possuem correspondência semântica direta no enunciado do problema original.

2. Metodologia

Os autores realizaram uma revisão narrativa estruturada da literatura para analisar como as abordagens existentes suportam essa transformação.

Corpus: 18 abordagens selecionadas de um conjunto inicial de 129 artigos, cobrindo três domínios: Engenharia de Requisitos (RE), Gestão de Projetos de ML e Automação.
Critérios de Seleção: As abordagens deveriam propor uma transformação concreta de necessidades de negócio para especificações de IA/ML, com detalhes metodológicos suficientes e validação em veículos revisados por pares.
Estrutura de Análise:
- Taxonomia: Organização das 18 abordagens em quatro famílias.
- Artefatos: Análise de 6 categorias de artefatos de entrada (problema) e 6 de saída (solução).
- Framework de 7 Estágios: Avaliação da cobertura de cada abordagem em um processo de transformação dividido em 7 estágios (S1 a S7), desde a formulação do problema até o planejamento de implantação.
- Confiabilidade: Avaliação inter-rater com Kappa de Cohen ponderado de 0,83 (concordância excelente).

3. Taxonomia das Abordagens Analisadas

As 18 abordagens foram classificadas em quatro famílias:

RE para IA (RE4AI): Focam em extensões de práticas de RE (ex: GR4ML, RE4HCAI). Geralmente organizam requisitos, mas carecem de mecanismos de transformação explícitos.
RE Centrada em Dados: Priorizam requisitos de dados como ponte (ex: AMDiRE, MLC Specification). Focam em especificação de dados, mas não na derivação da tarefa.
Processos de Gestão de Projetos (PM): Modelos de ciclo de vida (ex: CRISP-DM, CRISP-ML). Definem quando as atividades ocorrem, mas não como executar a decisão de formulação da tarefa.
Abordagens Orientadas à Automação: Focam na seleção de algoritmos downstream (ex: SmartML, MLOps), assumindo que a formulação do problema já está completa.

4. Resultados Principais

A análise comparativa revelou falhas sistemáticas no suporte à transformação:

Incompletude Universal: Todas as 18 abordagens apresentam cobertura mínima (ou inexistente) em pelo menos um estágio. Nenhuma abordagem cobre todos os 7 estágios com suporte forte.
A Descontinuidade S2–S3: Existe uma queda abrupta na cobertura de suporte na fronteira entre a formulação de decisões (S2) e a formulação da tarefa de ML (S3).
- S1 (Problema) e S2 (Decisão): Cobertura parcial a forte em algumas abordagens.
- S3 (Seleção de Tarefa/Paradigma ML): 0% de cobertura forte. Apenas 4 das 18 abordagens oferecem suporte parcial (ex: mapeamento cognitivo ou decomposição de metas), mas nenhuma fornece regras sistemáticas para derivar a tarefa de ML a partir do problema de negócio.
Falta de Mecanismos de Derivação: As abordagens existentes definem o que capturar (artefatos) ou quando fazer (processo), mas não explicam como derivar a formulação de ML (ex: classificação vs. regressão) a partir das características do problema.

5. Contribuições Chave

A. O Problema de Tradução Analítica (ATP - Analytics Translation Problem)
Os autores caracterizam a lacuna central como o ATP: a ausência de mapeamentos explícitos, rastreáveis e operacionalizáveis entre as caracterizações de negócio e as formulações de ML. O ATP é definido como a função $f_{ATP}$ que deve mapear entradas (Objetivos, Restrições, Dados, Requisitos do Usuário) para saídas (Paradigma, Tipo de Tarefa, Restrições de Algoritmo, Critérios de Avaliação).

B. Cinco Recomendações de Pesquisa (R1–R5)
Para preencher o ATP, os autores propõem um roteiro de pesquisa para futuros frameworks:

R1: Suporte à Exploração de Formulações Múltiplas: Em vez de buscar uma única solução, frameworks devem permitir a exploração de alternativas paralelas (ex: classificação vs. agrupamento) com critérios de comparação estruturados.
R2: Fornecer Orientação de Derivação de Tarefas: Estabelecer regras explícitas que liguem tipos de perguntas de negócio a tipos de tarefas de ML (ex: "Qual é o valor de Y?" → Regressão) e filtros baseados em dados.
R3: Habilitar Filtragem por Restrições-Algoritmo: Criar matrizes de compatibilidade que usem restrições não funcionais (ex: latência, explicabilidade) para eliminar famílias de algoritmos incompatíveis antes da seleção detalhada.
R4: Implementar Rastreabilidade Probabilística: Substituir a rastreabilidade binária (atendido/não atendido) por anotações probabilísticas que indiquem faixas de desempenho esperadas e impacto no objetivo de negócio.
R5: Definir Caminhos de Revisão Acionados por Dados: Estabelecer gatilhos explícitos onde descobertas empíricas de dados (ex: qualidade de rótulos insuficiente) forçam a revisão de decisões anteriores no processo, em vez de tratar isso como falha do projeto.

6. Significado e Implicações

Para a Engenharia de Requisitos (RE): O trabalho posiciona a transformação BP→MLS como um problema distinto de refinamento cross-domínio dentro da RE. Sugere que conceitos de RE (decomposição de metas, rastreabilidade) podem ser adaptados, mas precisam ser estendidos para lidar com a incerteza e a natureza estatística do ML.
Para a Prática: Os autores argumentam que a formulação de tarefas de ML deve ser tratada como uma atividade explícita de requisitos, não como uma decisão implícita de cientistas de dados. A falta de suporte sistemático leva a projetos que falham em alinhar-se aos objetivos de negócio.
Futuro: A formalização do ATP é um pré-requisito para o desenvolvimento de ferramentas de IA (como assistentes generativos) que possam realmente auxiliar na tradução de problemas de negócio para especificações técnicas, substituindo a intuição do praticante por mecanismos principiais e rastreáveis.

Em resumo, o artigo demonstra que, embora existam muitas metodologias para gerenciar projetos de IA, o "elo perdido" crítico — a derivação sistemática da tarefa de aprendizado de máquina a partir do problema de negócio — permanece sem suporte adequado, exigindo novas pesquisas e frameworks integrados.