Como escolher modelos de IA para cada tarefa da empresa?

Uma empresa decide incorporar inteligência artificial a dois processos diferentes.

No primeiro, o modelo deve classificar solicitações de compras em categorias predefinidas. No segundo, precisa analisar contratos, localizar cláusulas relevantes e explicar possíveis divergências para uma equipe especializada.

Os dois processos utilizam linguagem, mas não apresentam a mesma complexidade, o mesmo risco nem os mesmos requisitos operacionais.

A classificação de compras pode exigir respostas rápidas, estruturadas e consistentes. A análise contratual pode precisar de maior capacidade de interpretação, contexto mais amplo, identificação das evidências utilizadas e revisão de especialistas.

Adotar o mesmo modelo para os dois processos pode elevar custos sem melhorar a tarefa mais simples e produzir uma falsa sensação de segurança na tarefa mais complexa.

A seleção precisa começar pelo trabalho que será executado.

Defina a tarefa antes de comparar modelos

Uma descrição genérica como “analisar documentos” não oferece critérios suficientes para a escolha.

É necessário detalhar quais documentos serão processados, que resultado o modelo deve produzir, quais erros são aceitáveis, quanto tempo a resposta pode levar e quem utilizará o resultado.

Também é importante esclarecer se o modelo apenas apoiará uma decisão ou se sua resposta será utilizada automaticamente por outro sistema. Quanto maior o impacto de uma resposta, maior deve ser o cuidado com avaliação, supervisão e registro.

A PwC recomenda que as organizações avaliem cada opção no contexto do caso de uso, considerando os dados envolvidos, os requisitos de desempenho, a tolerância a falhas e a capacidade da empresa de operar e proteger o modelo ao longo do tempo [1].

Antes de pesquisar fornecedores, a empresa precisa responder a algumas perguntas concretas.

Qual entrada será recebida? Qual saída será considerada correta? A resposta precisa seguir um formato estruturado? O processo exige consulta a documentos internos? Existe revisão humana? Qual é o impacto de uma resposta errada?

Sem essa definição, a comparação tende a privilegiar a popularidade, o tamanho ou as capacidades gerais dos modelos, em vez de avaliar sua adequação ao processo.

Os critérios precisam refletir o trabalho

Não existe um único critério capaz de determinar qual modelo deve ser escolhido.

A decisão precisa combinar requisitos funcionais, operacionais, econômicos e de risco. Esses critérios também precisam receber pesos diferentes conforme a tarefa.

Uma avaliação inicial pode considerar:

1. Capacidade funcional: verificar se o modelo atende às modalidades, aos idiomas, ao tamanho de contexto, ao formato de saída, ao uso de ferramentas e aos demais recursos exigidos pelo processo.
2. Qualidade: medir se as respostas são corretas, completas, consistentes e úteis dentro da tarefa avaliada.
3. Desempenho operacional: observar latência, capacidade de processamento, estabilidade e comportamento em períodos de maior demanda.
4. Dados e segurança: analisar quais informações serão enviadas, onde poderão ser processadas, como serão tratadas e quais controles de acesso e retenção serão necessários.
5. Integração: avaliar a compatibilidade com aplicações, APIs, mecanismos de identidade, monitoramento e arquitetura existentes.
6. Custo total: considerar consumo, infraestrutura, desenvolvimento, integração, revisão humana, retrabalho e operação contínua.

A BCG recomenda que a escolha parta da finalidade e considere o equilíbrio entre desempenho, custo e capacidade operacional. O modelo mais conhecido ou de maior porte não será necessariamente o mais adequado para todas as tarefas [3].

Um processo de classificação interna pode priorizar custo, velocidade e consistência. Uma aplicação que analisa contratos pode exigir maior capacidade de interpretação, evidências verificáveis, tratamento cuidadoso dos documentos e participação de especialistas.

Benchmarks ajudam a formar a lista de candidatos

Benchmarks públicos são úteis para reduzir o número inicial de alternativas.

Eles permitem observar como modelos diferentes se comportam em tarefas padronizadas de raciocínio, conhecimento, segurança, codificação, latência e capacidade de processamento.

Entretanto, uma pontuação agregada não representa todas as condições de uma aplicação empresarial.

Um modelo bem posicionado em uma avaliação geral pode não apresentar o mesmo desempenho ao classificar documentos internos, interpretar o vocabulário de determinado setor ou produzir respostas no formato exigido por uma integração.

A PwC destaca que benchmarks públicos podem orientar a decisão, mas não substituem testes com tarefas empresariais representativas, padrões reais de dados, limites de qualidade, requisitos de latência e tolerância a falhas [1].

Documentações técnicas da AWS e da Microsoft oferecem mecanismos para realizar avaliações automáticas, aplicar conjuntos de prompts próprios, utilizar modelos avaliadores e incorporar revisão humana [6][7]. Esses recursos são úteis para executar os testes, mas os critérios de sucesso precisam ser definidos pela própria organização.

O benchmark ajuda a formar a lista de candidatos. A decisão precisa ser confirmada no processo real.

Compare os modelos nas mesmas condições

Uma comparação confiável exige que todos os modelos recebam as mesmas instruções, os mesmos exemplos e os mesmos critérios de avaliação.

A amostra deve representar situações comuns, casos difíceis e exceções relevantes. Os dados utilizados precisam estar autorizados para esse tipo de teste. Quando houver informações sensíveis, a equipe deve avaliar o uso de anonimização, mascaramento ou dados sintéticos adequados ao objetivo.

A avaliação também deve definir previamente o que será considerado sucesso.

Em uma tarefa de classificação, pode ser possível comparar o resultado com categorias esperadas. Em uma análise contratual, a avaliação pode exigir especialistas que verifiquem se as cláusulas foram identificadas corretamente, se a explicação está sustentada pelo documento e se informações relevantes foram omitidas.

Avaliações automáticas aceleram a comparação. Modelos avaliadores também podem ajudar a examinar grandes volumes de respostas. Ainda assim, o resultado produzido por outro modelo não deve ser tratado como verdade absoluta.

Para processos importantes, a revisão humana e os critérios do negócio continuam necessários.

O NIST recomenda que as organizações avaliem capacidades relevantes e medidas de segurança antes da implantação e de forma contínua, considerando o contexto, a tolerância a risco e os impactos possíveis [5].

O menor preço por processamento não representa o custo total

Uma comparação limitada ao preço de entrada e saída pode distorcer a decisão.

Um modelo aparentemente mais barato pode exigir instruções maiores, gerar mais retrabalho ou depender de maior revisão humana. Outro pode custar mais por execução, mas reduzir correções e entregar respostas estruturadas que simplificam a integração.

A McKinsey trata esse problema como parte da economia mais ampla da inteligência artificial. O custo depende da seleção do modelo, do roteamento, do desenho do fluxo, do comportamento dos agentes, do volume de chamadas e da quantidade de processamento desperdiçado [2].

O custo total também pode incluir preparação e atualização de prompts, recuperação de documentos, armazenamento, chamadas a ferramentas, revisão humana, correção de erros, observabilidade e manutenção das integrações.

A BCG acrescenta que modelo, arquitetura e plataforma de controle representam decisões relacionadas, mas distintas. Otimizar apenas o preço divulgado por um provedor pode ocultar custos de integração, dependência tecnológica, governança e operação [4].

Uma diferença pequena por execução pode se tornar relevante em grande escala. Da mesma forma, economizar no modelo pode não compensar se a taxa de retrabalho aumentar.

A pergunta correta não é apenas quanto custa uma chamada. A empresa precisa saber quanto custa alcançar um resultado aceitável para o processo.

Um exemplo de seleção por tarefa

Considere uma empresa que deseja automatizar a triagem de solicitações de compras.

A tarefa consiste em ler uma descrição curta, identificar a categoria correspondente e devolver uma estrutura simples. A empresa possui exemplos históricos revisados e consegue definir claramente as categorias esperadas.

Os modelos candidatos podem ser comparados por precisão da classificação, estabilidade do formato, tempo de resposta e custo para o volume estimado.

Em outro processo, a mesma empresa quer apoiar a análise de contratos. O modelo precisa trabalhar com documentos extensos, localizar cláusulas, relacionar trechos e produzir uma explicação para revisão especializada.

A avaliação passa a considerar contexto, fundamentação das respostas, capacidade de indicar os trechos utilizados, omissões relevantes, privacidade dos documentos e qualidade da revisão humana.

O resultado pode indicar modelos diferentes para cada tarefa.

Isso não obriga a empresa a criar uma arquitetura complexa desde o início. Significa apenas que a seleção foi orientada pelo trabalho a ser realizado, e não pela tentativa de padronizar prematuramente toda a organização em uma única alternativa.

Uma empresa pode terminar com mais de um modelo

Depois de avaliar tarefas diferentes, a organização pode concluir que modelos distintos atendem melhor a partes diferentes de seus processos.

Um modelo menor pode realizar classificações, extrações e transformações estruturadas. Outro pode ser reservado para análises que exigem maior capacidade de raciocínio ou interpretação. Também pode haver diferenças relacionadas a dados, idiomas, modalidades ou condições de implantação.

A PwC observa que a seleção de modelos não precisa ser tratada como uma escolha binária entre uma única opção aberta ou fechada. Um portfólio pode combinar modelos e formas de implantação conforme os requisitos de cada caso de uso [1].

Essa abordagem também reduz a dependência de uma única família de modelos. Entretanto, ela aumenta a necessidade de critérios comuns, integração, controle de acesso, observabilidade e acompanhamento de custos.

O ambiente multimodelo deve ser consequência das decisões por tarefa. Ele não deve surgir apenas porque muitas alternativas estão disponíveis.

A escolha precisa ser revisada ao longo do tempo

Modelos, preços, versões e condições de uso mudam. O processo atendido também pode receber novas regras, dados e integrações.

Por isso, a decisão precisa ser documentada.

A empresa deve registrar qual versão foi avaliada, quais dados foram utilizados, quais critérios foram aplicados e quais resultados justificaram a escolha.

Mudanças relevantes devem provocar uma nova avaliação. Isso inclui substituição de versão, alteração do prompt principal, inclusão de novas ferramentas, ampliação do público e uso do resultado em decisões com maior impacto.

A capacidade de substituir um modelo também deve fazer parte da arquitetura. O investimento mais duradouro não está apenas no modelo escolhido, mas no processo de avaliação, nos controles, nos dados de teste e nos mecanismos que permitem revisar a decisão quando as condições mudarem [1].

Da seleção à operação: ARGUS

Depois que a organização define quais modelos atendem a cada tarefa, surge o desafio de controlar como aplicações e agentes acessam esses recursos em produção.

Com recursos de AI Gateway, o ARGUS pode centralizar o acesso aos modelos integrados, aplicar políticas definidas pela organização e registrar consumo e interações. A plataforma também pode apoiar o acompanhamento operacional dos agentes que utilizam esses modelos.

Essa camada de controle permite relacionar o uso do modelo ao agente, à aplicação e ao processo atendido. Também facilita a observação de consumo, falhas, latência e alterações operacionais nos componentes integrados.

O ARGUS não escolhe automaticamente o melhor modelo para cada tarefa. A definição dos critérios, a preparação das amostras e a decisão sobre qualidade, risco e custo continuam sob responsabilidade da organização.

A plataforma transforma uma escolha documentada em políticas e evidências operacionais que podem ser acompanhadas ao longo do tempo.

Sobre a Target Solutions

A Target Solutions atua há mais de 15 anos apoiando organizações na evolução de suas operações de infraestrutura, monitoramento, observabilidade, automação e inteligência operacional.

Ao longo dessa trajetória, participou de projetos em ambientes complexos de Telecom, Tecnologia, Governo, Energia e grandes empresas, contribuindo para aumentar a eficiência operacional e a confiabilidade dos serviços.

Na seleção de modelos de IA, a Target Solutions pode apoiar a definição dos casos de uso, dos critérios de comparação e do processo de avaliação. Os serviços também podem abranger arquitetura, governança, integração, observabilidade e preparação do modelo operacional necessário para colocar as aplicações em produção.

Essa atuação não está restrita à implantação de uma plataforma específica. O objetivo é ajudar a empresa a estruturar decisões técnicas e operacionais adequadas às suas tarefas. Quando fizer sentido para o ambiente, a Target Solutions também pode apoiar a implantação e a integração de uma plataforma como o ARGUS.

Sobre o autor

Paulo Florêncio de Menezes é cofundador da Target Solutions e atua há mais de 15 anos em projetos relacionados a infraestrutura, monitoramento, observabilidade, automação e operações de TI e Telecom.

É graduado em Processamento de Dados pela Universidade Federal do Amazonas (UFAM), possui MBA em Gestão Empresarial pela Fundação Dom Cabral (FDC) e Mestrado Profissional em Economia pela Fundação Getulio Vargas (FGV).

Em sua pesquisa de Mestrado, desenvolveu o IBEOP-IA (Índice Brasileiro de Exposição Ocupacional Potencial à Inteligência Artificial), investigando a exposição potencial das ocupações brasileiras às capacidades da IA por meio da combinação de dados ocupacionais, patentes de inteligência artificial e técnicas de processamento de linguagem natural.

Referências

[1] PwC. The open-weight decision: What CISOs should consider before they say yes.

[2] McKinsey & Company. The cost of intelligence: How CIOs can manage AI demand at scale.

[3] Boston Consulting Group. Laying the Foundation for Gen AI Success.

[4] Boston Consulting Group. There’s More to Cloud AI Cost Than Token Price.

[5] NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.

[6] Amazon Web Services. Evaluate the performance of Amazon Bedrock resources.

[7] Microsoft. Model leaderboards in Microsoft Foundry.