Pensando equipes de produto "AI Driven" - encadeamentos, ética e mais.

Equipes de trabalho precisam se transformar para pensarem produtos conversacionais, há inspiração em equipes de chatbots, contudo é necessário formar novas composições voltadas a IA Generativa.

Muito se especula sobre os impactos da IA Generativa, quais setores serão os mais afetados, como começar provas de conceito, quais são os riscos para uso corporativo e por aí vai. É um dos propósitos deste blog, inclusive, fazer esse exercício de futurologia tentando antecipar essas tendências, já que tudo que sabemos é que muitas dessas mudanças serão exponenciais em termos de velocidade e transformação dos processos de trabalho. Contudo, vejo pouco se falando sobre como os times irão se transformar quando começarem a sair do modelo UX para telas de produtos transacionais, ao passar para produtos conversacionais com Foundation Models por trás, orquestrando um processo baseado em "capacidades" e gerindo as bases de dados próprias dos negócios. Isso muda bastante como uma equipe de produto deve ser organizada. A primeira mudança de paradigma é que produtos amparados em modelos multimodais requerem pensar a experiência do usuário de um jeito cada vez menos transacional, com cada vez com menos telas e “funcionalidades” específicas. Isto porque modelos multimodais combinam diferentes formas de interação com o usuário de um jeito muito mais eficiente que os atuais chatbots lidam. Será muito mais fácil o usuário preferir interagir por áudio, toques na tela e escrita. Como estes modelos são consideravelmente mais naturais que os anteriores, minha aposta é que os usuários vão cada vez mais preferir interações em linguagem natural, tendendo mais para o áudio do que para a escrita e toques na tela. A própria OpenAI lançou seu aplicativo iOS aproveitando de sua mais moderna API de reconhecimento de texto por áudio a “Whisper”, bem como a Google, aposta bastante na inclusão de novas APIs de reconhecimento de texto em seu portfólio. Essa transformação por si só, já irá abrir portas do mundo UX para o retorno de pesquisas que giram em torno do formato o qual o usuário irá interagir e não das funcionalidades em si, em relação às funcionalidades, os próprios Foundation Models com ajuda de outros papéis como o de arquiteto para incorporação de base de dados próprias, e designers de produto curadores já irão entregar o que o usuário precisa em formato conversacional.

As perguntas serão, nosso usuário preferirá interagir de que jeito? Qual é a linguagem que iremos utilizar para tal contexto? Quais combinações de multimodalidades iremos utilizar?

A segunda mudança de paradigma é pensar uma arquitetura de consumo e escrita de dados que estejam preparadas para serem conectadas em LLMs. O que é certo é que a estrutura de Cloud precisará ser repensada para entender onde estará essa camada intermediária que irá se conectar aos LLMs/Chains. As “chains” nada mais são que cadeias que a partir de ações do usuário, o modelo de LLM realiza sub-acionamentos a sua base de dados para chegar na resposta ao usuário ou um escrita de dados em sua base. Abaixo um exemplo de como “encadeamento” funciona, comparado ao método que a maioria dos chatbots hoje funcionam em um modelo “sandbox” ou melhor, em consultas isoladas. Quer saber mais? Artigo completo aqui :)

Figura 1: Um exemplo passo a passo ilustrando as diferenças entre não-encadeamento (A) e Encadeamento (B), usando o exemplo da tarefa de escrever uma revisão de pares para ser mais construtiva. Com uma única chamada ao modelo em (A), mesmo que o prompt (em itálico) descreva claramente a tarefa, o parágrafo gerado permanece principalmente impessoal e não fornece sugestões concretas para todos os 3 problemas da apresentação do Alex. Em (B), ao invés, usamos uma Cadeia LLM com três etapas, cada uma para uma sub-tarefa distinta: (b1) Uma etapa de Divisão de pontos que extrai cada problema de apresentação individual do feedback original, (b2) Uma etapa de Ideação que faz um brainstorm de sugestões por problema, e (b3) Uma etapa de Composição de pontos que sintetiza todos os problemas e sugestões em um parágrafo amigável final. O resultado é notavelmente melhorado. O encadeamento por exemplo, é algo que arquiteto precisará pensar para que os LLMs sejam mais a “cara da empresa” e o mais natural possível, realizando pesquisas em dados proprietários para não deixar as respostas deste produto conversacional genéricas como o Chat GPT, mas sim, uma associação entre um LLM como o GPT-4 e bases de dados internas em consultas encadeadas. Os arquitetos devem pensar não só o encadeamento necessário para cada “capability” do produto, mas bem como como esses dados irão transitar para os sistemas legado. Desafio parecido com o que já temos com cargas de dados entre sistemas baseados em eventos do nosso dia a dia. Outro papel que irá se transformar bastante é o da pessoa encarregada por dados, este papel irá perder cada vez mais espaço em uma arquitetura baseada em eventos e interfaces, como por exemplo o Mixpanel e irá migrar para uma perspectiva de efetividade de resposta e mais satisfação do usuário e o atingimento de seus objetivos macro. Isto porque os próprios modelos multimodais serão tunados para “melhorar a conversão”, é intrínseco ao prompt, então talvez os famosos testes A/B que requerem tags bem estruturadas, percam espaço para o “fine tuning” que nada mais é que acompanhar se os objetivos macros estão sendo cumpridos, e se não, orientar via prompt ou ingerir mais dados proprietários para que o modelo por si só, consiga ir melhorando as métricas de produto. Isto vai requerer que o analista de dados tenha uma visão menos micro gerenciada de tags e painéis e passe a ter uma postura de saber implementar indicadores macro e saber como os papéis podem se articular para realizar esta tunagem.

Mais um papel que deve se transformar bastante é do próprio dono ou gerente de produto que passará a olhar de forma ainda mais macro para a visão da empresa, uma vez que a construção de LLM leva em consideração aspectos muito mais abstratos que uma aplicação comum, são estratégias que serão repassadas diretamente aos engenheiros de prompt para que o modelo de linguagem esteja adaptado aos objetivos da empresa. Outro papel importante que o PM passará a orquestrar é a transição da aplicação tradicional para um modelo conversacional. Se for um produto interno da empresa, a fase de discovery deve ser bem conduzido retirando os vieses processuais já existentes, uma vez que produtos conversacionais a partir de LLM podem ser estruturados do zero, em uma abordagem totalmente linguística e “goal-based”. Haja jogo de cintura para criar um novo processo com poucos pontos de controle, diferente das aplicações atuais onde absolutamente cada evento é monitorado, passando a ter uma abordagem puramente voltada a OKRs e cada vez mais experimentações no-code ou low-code.

Por fim, a dimensão ética ganha um espaço considerável, uma vez que um “fine tuning” pode gerar um efeito colateral não desejado enviesando ou corrompendo o fluxo de conversação, ou a própria segmentação de dados conter vieses que prejudique o cliente ou a empresa, para isto, devemos seguir as boas práticas e compartilho o guia da Unesco que pode ajudar nesse approach.

São grandes os desafios e é muito difícil tentar antecipar estas transformações, mas acredito que os papéis de arquitetura, designers e donos/gerentes de produto terão que estar ainda mais próximos. Equipe de dados passará a ter uma atuação ainda mais holística. E como não terá aquele vai e vem de testes em telas e endpoints, a equipe de engenharia deverá ganhar mais espaço para trabalhar diretamente com o arquiteto, garantindo mais autonomia ao time de desenvolvimento, e menos loops de correções, homologações e ajustes finos que são próprios de uma arquitetura voltada a funcionalidades, diferente do que iremos lidar a partir de agora com a IA Generativa voltado a "capacidades". É preciso experimentar novas abordagens de time, pois de certo, LLMs e encadeamentos trazem consigo um novo jeito de se pensar produto. Vamos pensar juntos. 😎