Este é um guia prático inspirado no artigo de Chip Huyen “Common pitfalls when building generative AI applications“

Introdução

Construir aplicações com modelos de linguagem (LLMs) é, ao mesmo tempo, uma das áreas mais empolgantes e mais desafiadoras da engenharia de software atual. Estamos todos, coletivamente, aprendendo enquanto executamos e isso significa que erros fazem parte do processo.

Chip Huyen, autora de referência em sistemas de IA em produção, publicou um artigo mapeando os enganos mais frequentes que ela observa tanto em estudos de caso públicos quanto em sua experiência profissional. Se você já trabalhou em algum produto de IA, é bem provável que reconheça pelo menos um desses padrões, talvez até em projetos que você mesmo conduziu.

Neste post, vamos percorrer as seis armadilhas identificadas por ela, com exemplos, análises e recomendações práticas para times de engenharia de IA no contexto brasileiro.

Armadilha 1: Usar IA generativa quando você não precisa de IA generativa

Toda vez que surge uma tecnologia nova, engenheiros experientes suspiram em uníssono: “nem tudo é prego”. A IA Generativa não escapa dessa regra, pelo contrário, suas capacidades aparentemente ilimitadas amplificam a tentação de aplicá-la em qualquer problema.

Huyen compartilha um caso ilustrativo: um time propôs usar LLMs para otimizar o consumo de energia elétrica residencial, alimentando o modelo com a lista de atividades da casa e os preços horários da eletricidade para gerar uma programação otimizada. O experimento sugeria uma redução de 30% na conta de luz.

Impressionante, certo?

A pergunta crítica, no entanto, era simples: como esse resultado se compara a uma regra básica de agendamento, do tipo “ligue a máquina de lavar depois das 22h, quando a tarifa é mais barata”? Técnicas clássicas de otimização (como programação linear) resolvem esse tipo de problema há décadas, com custo computacional irrisório e resultados previsíveis.

Esse padrão se repete em diversos contextos: empresas que querem detectar anomalias em tráfego de rede, prever volume de chamadas em call centers, identificar desnutrição em pacientes, todos com LLMs, quando abordagens estatísticas ou de Machine Learning tradicional resolveriam o problema com mais eficiência, mais previsibilidade e menor custo.

Lição prática: explorar novas tecnologias é legítimo, mas é fundamental ter clareza se o objetivo é resolver um problema ou testar uma solução. São coisas distintas. “Resolvemos o problema” e “usamos IA Generativa” geram manchetes muito diferentes e, infelizmente, muita gente prefere a segunda, até descobrir que fez a escolha errada.

Armadilha 2: Confundir “produto ruim” com “IA ruim”

No extremo oposto da primeira armadilha estão os times que experimentaram IA Generativa, receberam feedback negativo dos usuários e concluíram que a tecnologia não serve para o caso de uso deles quando, na verdade, outros times foram bem-sucedidos em casos praticamente idênticos.

A análise de Huyen é reveladora: quando ela teve acesso aos detalhes desses projetos fracassados, descobriu que o problema não estava na IA, mas no produto.

Mais especificamente, na experiência do usuário (UX).

A engenharia por trás da IA costuma ser a parte mais fácil. O difícil é responder perguntas como:

  • Qual é a interface certa para essa funcionalidade?
  • Como integrar a IA ao fluxo de trabalho do usuário sem criar fricção?
  • Onde e como envolver o humano no loop de decisão?

Alguns exemplos concretos que ilustram como as preferências dos usuários são contraintuitivas:

Resumos de reuniões: um time inicialmente debatia se os resumos deveriam ter 3 ou 5 frases. Descobriram depois que o tamanho era o menor dos problemas e o que importava era a estrutura, a acionabilidade e a integração com os sistemas de notas existentes.

Chatbot do LinkedIn para avaliação de adequação a vagas: os engenheiros perceberam que os usuários não queriam respostas corretas, queriam respostas úteis. Parece a mesma coisa, mas não é.

Chatbot de impostos da Intuit: o feedback inicial foi morno. Investigando a fundo, a equipe descobriu que os usuários simplesmente odiavam digitar. Diante de um campo vazio, não sabiam o que perguntar nem o que o bot era capaz de fazer.

Lição prática: como todos os times usam basicamente os mesmos modelos hoje, o componente de IA acaba sendo parecido entre produtos concorrentes. A diferenciação real está no produto, na forma como a tecnologia é embrulhada, apresentada e integrada ao contexto do usuário.

Armadilha 3: Começar com complexidade demais

Esta é, talvez, a armadilha em que mais vemos engenheiros caindo atualmente. Exemplos típicos:

  • Adotar um framework agêntico completo quando chamadas diretas à API resolveriam.
  • Gastar semanas escolhendo entre vector databases quando uma busca por termos (BM25, por exemplo) já atenderia o requisito.
  • Insistir em fine-tuning quando engenharia de prompt é suficiente.
  • Implementar cache semântico antes de validar o padrão de uso.

O problema de incorporar ferramentas externas cedo demais é duplo:

Abstrações escondem detalhes críticos. Quando algo quebra, você não sabe se o erro está no seu código, no prompt default do framework ou em alguma atualização silenciosa da biblioteca.

Abstrações introduzem bugs que não são seus. Desenvolvedores de ferramentas também erram e Huyen menciona ter encontrado erros de digitação em prompts padrão ao revisar códigos-fonte de frameworks populares.

Abstrações, em geral, são boas. Mas boas abstrações incorporam boas práticas consolidadas ao longo do tempo. Como estamos nos primórdios da engenharia de IA, essas boas práticas ainda estão evoluindo. Convém, portanto, redobrar a vigilância antes de adotar qualquer camada de abstração.

Lição prática: comece simples, entenda o comportamento do sistema no nível mais baixo possível e só adicione complexidade quando houver evidência clara de que ela resolve um problema real. Framework agêntico, fine-tuning e vector database são ferramentas poderosas, mas não precisam ser o seu ponto de partida.

Armadilha 4: Superestimar o sucesso inicial

Essa é, provavelmente, a primeira lição dolorosa que todo time que constrói produtos de IA aprende: é fácil criar uma demo; é difícil criar um produto.

Huyen cita três casos que ilustram bem essa realidade:

LinkedIn: levou um mês para atingir 80% da qualidade de experiência desejada, e mais quatro meses adicionais para passar dos 95%. O sucesso inicial fez com que o time subestimasse drasticamente a dificuldade das melhorias subsequentes.

Startup de assistentes de vendas para e-commerce: chegou a relatar que “ir de 0 a 80% levou o mesmo tempo que ir de 80% a 90%”. Os gargalos incluíam trade-off entre precisão e latência, dificuldade dos agentes em diferenciar ferramentas similares, obediência imperfeita a requisitos de tom (“fale como um concierge de marca de luxo”), dificuldade em capturar completamente a intenção do cliente e impossibilidade de criar uma suíte exaustiva de testes unitários (já que as combinações de queries são virtualmente infinitas).

Paper UltraChat (Ding et al., 2023): os autores observaram que a jornada de 0 a 60 é tranquila, enquanto progredir de 60 para 100 se torna extraordinariamente desafiador.

Além dos problemas já conhecidos (alucinações, latência, tool use, avaliação) equipes maduras também enfrentam:

Confiabilidade dos provedores de API: um time relatou que 10% das chamadas davam timeout. Ou então o comportamento do produto muda porque o modelo foi atualizado sem aviso prévio.

Conformidade (compliance): direitos autorais sobre a saída da IA, acesso e compartilhamento de dados, privacidade do usuário, riscos de segurança em sistemas de retrieval/cache e ambiguidades sobre a linhagem dos dados de treinamento.

Segurança (safety): uso malicioso do produto, geração de respostas ofensivas ou insensíveis.

Lição prática: ao planejar marcos e alocar recursos, reserve capacidade para lidar com esses obstáculos. Uma postura saudável é o que um colega de Huyen chama de “otimismo cauteloso”. E vale sempre lembrar: muitas demos fantásticas nunca viram produtos incríveis.

Armadilha 5: Abrir mão da avaliação humana

Para avaliar aplicações de IA de forma automatizada, muitos times adotam a abordagem AI-as-a-judge (ou LLM-as-a-judge), ou seja, usar modelos de IA para avaliar as saídas de outros modelos de IA. A armadilha aqui é confiar exclusivamente nesses juízes automatizados e abandonar completamente a avaliação humana.

Juízes de IA são úteis, mas não são determinísticos. A qualidade deles depende do modelo, do prompt utilizado e do caso de uso. Se o juiz não for desenvolvido com cuidado, ele pode fornecer avaliações enganosas sobre o desempenho da sua aplicação. Juízes de IA, assim como qualquer outra aplicação de IA, precisam ser avaliados e iterados ao longo do tempo.

Os times com os melhores produtos que Huyen observa mantêm, sem exceção, avaliação humana como complemento à avaliação automatizada. Todo dia, especialistas humanos revisam um subconjunto das saídas, entre 30 e 1000 exemplos, dependendo do caso.

Essa avaliação manual diária serve a três propósitos:

  • Correlacionar o julgamento humano com o da IA. Se a nota dos avaliadores humanos está caindo enquanto a nota do juiz automatizado está subindo, é sinal de que algo no seu juiz merece investigação.
  • Entender como os usuários realmente usam sua aplicação. Isso gera insights para melhorias de produto que nenhuma métrica agregada revelaria.
  • Detectar padrões e mudanças de comportamento que a exploração automatizada pode deixar passar, especialmente quando esses padrões se relacionam a eventos externos e contexto cultural.

A confiabilidade da avaliação humana depende, por sua vez, de diretrizes de anotação bem construídas. Curiosamente, essas mesmas diretrizes podem ser reaproveitadas para melhorar as instruções do modelo (se um humano tem dificuldade para seguir a instrução, o modelo também terá) e, eventualmente, como dados de fine-tuning.

Uma citação que vale guardar, atribuída por Huyen a Greg Brockman: a inspeção manual de dados talvez seja a atividade com maior razão valor-por-prestígio em todo o Machine Learning.

Lição prática: 15 minutos olhando dados brutos por dia costumam render mais insights do que horas olhando dashboards.

Armadilha 6: Terceirizar os casos de uso para a coletividade

Esta armadilha foi especialmente comum no começo da corrida das empresas pela adoção de IA Generativa. Sem uma estratégia clara sobre quais casos de uso priorizar, muitos executivos de tecnologia recorreram ao crowdsourcing interno: “contratamos gente inteligente, vamos deixar que eles nos digam o que fazer”.

O resultado foi previsível: um milhão de modelos text-to-SQL, um milhão de bots de Slack e um bilhão de plugins de código, todos construídos em paralelo, sem priorização estratégica.

O argumento de ouvir os colaboradores é legítimo. O problema é que indivíduos tendem a ser enviesados em direção aos problemas que afetam o dia a dia deles e não necessariamente em direção aos problemas com maior retorno sobre investimento para a organização.

Sem uma visão de conjunto (uma estratégia que considere o posicionamento competitivo da empresa, o estado da maturidade de dados, a cadeia de valor e os ativos proprietários de informação) é muito fácil se perder em uma sequência de aplicações pequenas e de baixo impacto. E daí vem a conclusão equivocada de que “IA Generativa não entrega ROI”.

Lição prática: decisões sobre onde aplicar IA Generativa são decisões estratégicas. Elas deveriam ser tomadas com a mesma seriedade com que se decide entrar em um novo mercado ou construir um novo produto.

Conclusão

Em síntese, as seis armadilhas mais comuns na engenharia de aplicações com IA Generativa são:

1- Usar IA Generativa quando você não precisa de IA generativa. Nem todo problema precisa de IA e muitos problemas que precisam de IA não precisam da variedade generativa.

2- Confundir “produto ruim” com “IA ruim”. Na maior parte dos produtos de IA, a IA é a parte fácil. O difícil é o produto.

3- Começar com complexidade demais. Frameworks sofisticados e fine-tuning têm seu lugar, mas não devem ser o ponto de partida.

4- Superestimar o sucesso inicial. Sair de uma demo funcional para um produto em produção pode levar muito mais tempo do que chegar à demo inicial.

5- Abrir mão da avaliação humana. Juízes automatizados precisam ser validados e correlacionados com avaliação humana sistemática.

6- Terceirizar os casos de uso. É preciso uma estratégia de panorama amplo para maximizar o retorno sobre investimento.

No contexto brasileiro, em que empresas ainda estão estruturando suas áreas de dados e IA, essas armadilhas ganham um peso adicional.

A maturidade organizacional de dados costuma ser um gargalo mais relevante do que a sofisticação do modelo escolhido e investir em frameworks agênticos sem ter observabilidade, governança e avaliação humana estruturada é pular etapas fundamentais.

O caminho saudável passa por começar simples, como medir com rigor (incluindo humanos no loop), tratar a UX como um problema de primeira ordem e, acima de tudo, manter o foco no problema de negócio, não na tecnologia da moda.

Se quiser compreender na prática e de forma profissional como não cair nessas armadilhas ao construir produtos de IA, escolha aqui sua capacitação e comece agora mesmo:

Qual Trilha de Aprendizagem Devo Escolher na Data Science Academy?

Equipe DSA