Recentemente, com o rápido aumento dos serviços de IA generativa, está ocorrendo uma mudança fundamental no papel do PM.
Isso também vale para a função de QA.
Se no passado o PM definia os requisitos (Spec) e o QA verificava o funcionamento correto das funcionalidades (Pass/Fail), na era da IA a qualidade se tornou uma área que o próprio PM precisa 'definir' e 'avaliar'.
- Por que o PM, e não o QA, é responsável pela qualidade?
- Ausência de resposta correta: as respostas de IA não são uma questão de certo ou errado, mas existem em um espectro entre 'melhor' e 'pior'.
- Subjetividade da avaliação: critérios qualitativos como "É natural?" e "É útil?" só podem ser definidos por um PM que conhece melhor do que ninguém a visão do produto.
- Definição é qualidade: em serviços de IA, a qualidade não é algo que se captura em testes; ela começa ao definir, desde o início, o que é um 'bom resultado'.
- Comparação do gerenciamento de qualidade: serviços comuns vs. serviços de IA
Há grandes diferenças entre serviços de software tradicionais e serviços de IA, desde a forma de encarar a qualidade até o modo de gerenciá-la.
-
Critério e julgamento da qualidade: em serviços comuns, a especificação é a própria resposta correta. É como um quiz de verdadeiro ou falso em que dá para separar claramente 'certo/errado (Pass or Fail)', como verificar se um botão funciona ou se o pagamento é processado. Já em serviços de IA, em vez de uma resposta correta clara, existe apenas uma 'resposta-modelo'. Como a qualidade está em um espectro contínuo, isso se parece mais com a correção de uma prova discursiva, em que se avalia o quanto o resultado está otimizado, e não apenas se está certo.
-
Núcleo e responsabilidade do gerenciamento de qualidade: em serviços comuns, o importante é a 'garantia de qualidade (QA)', que verifica se a funcionalidade foi concluída conforme o planejado, e essa responsabilidade costuma ficar com a equipe de QA. Mas em serviços de IA, o núcleo é o 'design de avaliação', que estabelece o critério do que é um bom resultado. Por isso, o PM, que melhor conhece a visão do produto, se torna o responsável final pela qualidade.
-
Mudança na forma de verificação: no passado, testava-se se a funcionalidade operava conforme cenários predefinidos; em serviços de IA, passa-se por uma avaliação qualitativa (Human Eval), em que pessoas analisam diretamente os resultados. Além disso, usando um LLM treinado com os critérios definidos pelo PM como avaliador (LLM Judge), é possível validar grandes volumes de dados de forma automatizada e melhorar a qualidade continuamente.
- Gestão de qualidade em 5 etapas para PMs de IA
- Dar notas você mesmo com um guia: selecione dados de exemplo e faça a avaliação manualmente para reconhecer seus próprios critérios de julgamento.
- Tornar os critérios explícitos: defina em linguagem explicável impressões vagas como "concretude" e "realismo".
- Construir um dataset: crie uma lista das principais perguntas que o serviço deve resolver e suas respostas-modelo.
- Automatizar a avaliação (LLM Judge): faça com que o LLM avalie grandes quantidades de resultados com base nos critérios definidos.\
- Desconfiar das métricas: se a pontuação de avaliação subir, mas a satisfação do usuário continuar baixa, reavalie os próprios critérios.
💡 Insight agora
O PM não é mais alguém que simplesmente cria funcionalidades, mas alguém que projeta os 'critérios para julgar o valor do produto'. A experiência de definir o que é um bom resultado e criar a estrutura para medi-lo será a vantagem competitiva mais poderosa para PMs na era da IA.
2 comentários
Lendo o post completo, parece ser originalmente o trabalho que um PM já fazia. Só que, com a chegada da era da IA, parece que a forma de fazer isso está mudando aos poucos. Gostei muito dos bons insights.
Obrigado.
Embora as formas de planejamento e de design também tenham mudado continuamente, parece que a velocidade está acelerando cada vez mais.