De responder a executar: como mudou a interface entre as pessoas e a IA

Uma história contada a partir do que é possível delegar

A história da inteligência artificial costuma ser contada por meio das suas técnicas, dos seus resultados ou dos períodos de entusiasmo que a acompanharam. Também pode ser contada a partir de uma pergunta mais concreta: o que uma pessoa podia pedir a um sistema e que parte da tarefa podia deixar a cargo dele? Essa perspetiva centra-se na interação e na delegação, e não apenas na capacidade de gerar uma resposta.

Uma conversa convincente, uma interface integrada num produto e uma ação executada por software são coisas diferentes. No primeiro caso, o sistema produz uma resposta que a pessoa pode usar. No segundo, o diálogo surge junto das funcionalidades de um serviço. No terceiro, o sistema pode intervir num processo externo, desde que disponha de ferramentas e permissões para o fazer. O simples facto de uma interface parecer conversacional não permite concluir que consiga realizar uma tarefa do princípio ao fim.

As fontes disponíveis para este artigo permitem observar vários exemplos atuais ou apresentados como contexto, mas não documentam com detalhe suficiente o lançamento e a evolução de uma sequência histórica comum. Por isso, este percurso compara formas de interação e delimita o que é possível afirmar sobre cada exemplo. Não propõe uma cronologia universal nem defende que cada forma nova seja necessariamente mais fiável ou útil do que a anterior.

Cinco perguntas para distinguir interação de capacidade

Para comparar produtos sem confundir as suas diferenças, convém separar cinco dimensões. A interface descreve como a pessoa comunica com o sistema. A técnica ou o mecanismo indica, na medida em que a documentação o permite, o que o software faz com o pedido. O alcance da ação especifica se o resultado é uma resposta, uma recomendação ou uma operação executada. A supervisão abrange as permissões e confirmações envolvidas. Por fim, as evidências disponíveis esclarecem se a afirmação vem da documentação do produto, de uma análise externa ou de uma demonstração avaliada.

Esta separação também ajuda a usar com precisão termos próximos. Um prompt é a entrada ou instrução que orienta uma resposta. Um agente costuma designar um sistema organizado para perseguir um objetivo ao longo de vários passos, embora o uso do termo varie. Tool-calling refere-se a um modelo pedir a utilização de uma ferramenta disponível; isso não significa automaticamente que a ferramenta seja executada, que a operação tenha êxito ou que seja concluída sem supervisão. Por si só, estes termos não descrevem o desempenho real de um produto.

Diálogo textual: uma resposta não equivale a uma ação

No diálogo textual, a interação assume a forma de pergunta e resposta. A pessoa escreve um pedido e o sistema devolve texto. Como contexto jornalístico, a BBC Mundo descreve o ChatGPT como capaz de responder a perguntas ou gerar conteúdo. Essa descrição permite caracterizar um uso conversacional geral, mas não basta para estabelecer que mecanismo concreto produz cada resposta, que limitações foram testadas ou que funções estavam disponíveis numa determinada data.

Esta distinção é importante porque uma resposta pode orientar uma tarefa sem a executar. Se alguém pedir ajuda para redigir uma mensagem, receber um rascunho não demonstra que o sistema a tenha enviado. Se perguntar como fazer uma reserva, obter instruções não significa que tenha sido consultada a disponibilidade nem confirmada uma reserva. Estes exemplos são situações ilustrativas, não afirmações sobre as funções de um produto específico.

Também não é correto deduzir que uma interação textual inicial dependia necessariamente de regras ou guiões apenas por ser apresentada como chatbot. A IBM oferece uma visão geral histórica que menciona os primeiros chatbots conversacionais, mas a informação aqui disponível não detalha o funcionamento de um sistema específico. Sem documentação do produto ou uma fonte histórica direta, não é possível reconstruir com rigor que regras, bases de dados ou técnicas participavam num caso concreto.

A lição comparativa é modesta, mas útil: a conversa é uma forma de acesso, não uma prova completa de capacidade. Para avaliar um sistema, são necessários dados sobre a tarefa, as respostas aceitáveis, os erros e as condições de utilização. A fluidez da interação não substitui essas evidências.

Assistentes integrados em produtos: conversa situada num serviço

Um assistente integrado num produto muda o lugar da interação: a pessoa pode conversar no contexto de um serviço específico, em vez de o fazer numa interface isolada. Essa integração pode reduzir o número de passos necessários para encontrar uma função ou pedir ajuda. No entanto, a proximidade das funcionalidades do produto não demonstra que o assistente tenha acesso a todas elas, que interprete corretamente cada pedido ou que as consiga executar sem intervenção.

A documentação da Adobe incluída nas fontes corresponde a um guia da interface de utilizador do seu Assistente de IA. A documentação do Primo Research Assistant identifica uma ferramenta generativa orientada para tarefas de investigação. Estes materiais servem para descrever exemplos de assistentes apresentados em produtos ou serviços. A informação fornecida não estabelece as capacidades exatas que existiam no lançamento nem permite reconstituir uma sequência de alterações com datas verificadas.

Um caso diferente, descrito pela Facephi, aborda a conceção de uma interface de decisão para analistas perante recomendações de IA. Isto aponta para uma questão relevante de produto: apresentar uma recomendação não é o mesmo que substituir o juízo da pessoa que a recebe. Mas, de acordo com a descrição disponível, essa fonte não documenta uma evolução histórica nem demonstra, por si só, os resultados de uma interface específica.

Na prática, para descrever qualquer assistente integrado, convém verificar que informação pode consultar, que funcionalidades estão disponíveis, que resultado apresenta e quem confirma uma operação. Se as fontes documentarem apenas a interface ou o propósito geral, esses são os limites da descrição. Não é rigoroso preencher as lacunas supondo que o sistema tem acesso aos dados do utilizador ou a todas as funcionalidades do produto.

Ferramentas e ações: uma fronteira que exige provas

Quando um sistema pode pedir a utilização de ferramentas, a interação pode ir além da produção de texto. Uma ferramenta pode, por exemplo, consultar informação ou iniciar uma operação noutro serviço. Mas há várias etapas que não devem ser confundidas: o modelo pode propor uma chamada; o software pode validá-la; um serviço externo pode responder; e uma pessoa pode ter de autorizar o resultado. A existência de uma dessas etapas não demonstra que todas sejam concluídas nem que o processo esteja correto.

O termo tool-calling designa uma possibilidade técnica, não um resultado garantido. Um agente pode coordenar vários passos, mas esse rótulo também não prova que o sistema escolha os passos adequados, mantenha o contexto, recupere de falhas ou saiba quando deve parar. Para sustentar que um produto executa uma ação concreta, são necessárias fontes que descrevam a operação e, sempre que possível, uma demonstração reproduzível dos seus limites e requisitos.

As fontes reunidas para este artigo não apresentam um exemplo documentado com detalhe suficiente de um sistema que invoque uma ferramenta e conclua uma ação externa, nem descrevem as permissões e confirmações necessárias nesse caso. Por isso, não se atribui essa capacidade ao Primo Research Assistant, ao assistente da Adobe ou a qualquer outro produto mencionado. O contraste com os assistentes conversacionais serve aqui para formular o que seria necessário verificar, não para afirmar que uma nova etapa histórica já foi comprovada.

O que é possível comparar — e o que não é

Uma comparação justa usaria a mesma tarefa e critérios equivalentes para cada sistema. Por exemplo, poderia analisar se uma pessoa consegue encontrar informação, redigir uma resposta ou concluir um pedido. Mas, antes disso, seria necessário escolher sistemas concretos, fixar as respetivas versões e obter documentação suficiente para conhecer a tarefa, as permissões, a intervenção humana e o resultado. As evidências disponíveis não permitem reconstituir a mesma tarefa nos exemplos mencionados.

Por essa razão, este artigo compara categorias e limites das evidências, e não resultados de desempenho. O contexto da BBC Mundo sobre o ChatGPT e a referência da IBM aos chatbots conversacionais fornecem antecedentes gerais. Os guias da Adobe e do Primo documentam produtos concretos do ponto de vista dos respetivos fornecedores. O artigo da Facephi oferece contexto sobre a apresentação de recomendações e o critério humano. São fontes de tipos e alcances diferentes; não devem ser tratadas como se fossem ensaios comparáveis.

Esta cautela evita três erros frequentes. Primeiro, tomar a descrição de uma função como verificação independente do seu desempenho. Segundo, atribuir a um produto capacidades que um guia de interface não menciona. Terceiro, chamar «autonomia» a qualquer redução de passos, mesmo quando uma pessoa continua a tomar as decisões importantes. Integração, acesso a ferramentas e qualidade dos resultados são variáveis distintas.

Mais formas de interagir não equivalem a progresso medido

Uma interface pode facilitar a expressão de uma necessidade; um assistente integrado pode colocar a ajuda junto das funcionalidades de um serviço; uma ferramenta pode permitir que o software atue sobre outro sistema. Cada mudança amplia ou reorganiza as possibilidades de interação. Nenhuma delas, isoladamente, estabelece uma melhoria comum da fiabilidade, da utilidade ou da autonomia geral.

Para sustentar uma afirmação de progresso mensurável, é necessário especificar que tarefa está a ser avaliada, o que significa concluí-la, que erros contam, que nível de supervisão é permitido e com que sistemas é feita a comparação. Também é necessário distinguir o desempenho observado da descrição comercial ou documental de uma funcionalidade. Sem esses elementos, a afirmação pode referir-se a uma interface mais conveniente ou a um maior alcance de ação, mas não a uma capacidade geral superior.

As incertezas não são um defeito a ocultar; delimitam o que o leitor pode aprender a partir da documentação disponível. Neste caso, existem exemplos de conversa, de assistentes apresentados em serviços e de conceção em torno de recomendações, mas não uma base homogénea para narrar uma sucessão de produtos nem uma avaliação comparativa dos seus resultados. O mapa é, portanto, de perguntas e distinções, não uma classificação de sistemas.

A pergunta central é o que se delega e com que evidências

Contar a evolução da IA a partir da interação permite identificar mudanças importantes sem pressupor que formam uma escada inevitável. Pedir uma resposta, consultar um assistente dentro de um produto e delegar uma operação são experiências diferentes. Para perceber até que ponto a capacidade mudou realmente, é preciso acompanhar as funcionalidades concretas, as suas datas, as permissões, as confirmações e o comportamento perante falhas.

Com as evidências disponíveis, é possível distinguir entre diálogo textual, assistência integrada e a possibilidade conceptual de utilizar ferramentas. Não é possível afirmar que os exemplos citados representem três etapas sucessivas, que uma mesma tarefa tenha sido concluída melhor em cada uma delas ou que os sistemas mencionados executem ações externas. Manter essa fronteira torna a comparação mais útil: evita confundir uma nova interface com uma capacidade demonstrada.

Perante futuras afirmações de que um produto já consegue «fazer» alguma coisa, a pergunta mais prática continua a ser: o que fez exatamente, em que condições, quem confirmou e onde está documentado? A resposta permite separar aquilo que o sistema sugere daquilo que efetivamente executa, e a novidade de uma interface de uma melhoria medida.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.