O que se aprende a pôr um agente de IA a atender a sério

Um agente que atende clientes de verdade parte por razões que não se leem em lado nenhum. Não parte por o modelo ser fraco. Parte por coisas medidas, repetíveis, e quase todas contra-intuitivas.

Isto é o que aprendemos a construir e a afinar um agente de marcações a atender no WhatsApp, com clientes reais do outro lado. São nove coisas.

1. Quando o agente se porta mal, muda-se o que ele lê

É a lição mais cara de todas e a que se aprende ao contrário.

O instinto é escrever mais uma regra: "não faças isto", "responde sempre assim". Provámos quatro vezes em dois dias que isso não resolve. O comportamento só mudou quando mudámos o dado, o exemplo, ou o texto que a ferramenta devolve.

Três casos, e são todos assim.

O agente dizia "marque a partir de 17" quando a data certa era 16. Nenhuma regra o corrigiu. Corrigiu-se mudando o texto que o sistema lhe devolvia, de "ausente até 15" para "disponível a partir de 16". Passou a escrever a data certa porque a data certa era a que ele via.

Escrevia "está livre o Pedro e o João", com o verbo no singular. A regra de concordância já lá estava e não servia de nada. O que o ensinava mal era o exemplo por baixo dela, que só mostrava o caso de um nome. Pusemos os dois exemplos e o erro desapareceu.

Inventou preços, com toda a confiança e sem consultar nada. Proibir não bastou. Foi preciso dar-lhe um caminho para quando lhe perguntam o preço antes de haver dia e hora: pedir o dia e a hora, e prometer o preço a seguir.

2. O tamanho do texto de instruções é uma medida, não um gosto

Mesmo agente, mesmo modelo, três tamanhos:

Abaixo das mil e novecentas palavras é seguro. Acima das duas mil e trezentas parte. No meio funciona, mas vai perdendo as regras miudinhas, e perde-as em silêncio.

Isto tem uma consequência que não é opcional. Sempre que se acrescenta uma secção às instruções, metade dos testes seguintes tem de ser das regras antigas, não das novas. As novas estão frescas e passam quase sempre. São as antigas que se apagam.

3. O agente não sabe que dia é hoje

Parece básico e é onde se perdem marcações.

A plataforma dá-lhe a data de hoje e mais nada. Se alguém escrever "quinta-feira" ou "para a semana", é o agente que tem de fazer a conta, e tem de a fazer sem pedir confirmação, porque um cliente que já disse quinta não quer que lhe perguntem qual quinta.

O erro que mais aparece é somar um dia sem razão nenhuma, ou empurrar a pessoa para o dia seguinte quando o dia que ela pediu ainda tem vagas.

4. A segurança fica no servidor, nunca nas instruções

Um modelo pode inventar um identificador. Se o sistema apagar aquilo que lhe mandarem apagar, um número inventado apaga a marcação de outra pessoa.

A verificação faz-se do outro lado. Antes de apagar, o servidor lê o registo e confirma que ele pertence a quem está a pedir, pelo telefone de quem escreve, pelo número de utente, ou pelo número de sócio.

Duas regras que andam com esta. Uma ação desconhecida não pode fazer nada: se o pedido não bater com nenhum caso previsto, o sistema não corre e não responde. E uma procura sem identificação não pode devolver tudo: sem isso, uma chamada sem dados devolvia a agenda inteira a quem perguntasse.

5. Verificar na fonte, não na palavra do agente

Ele diz que desmarcou. Vai-se ao calendário ver se desmarcou.

Parece exagero até à primeira vez em que ele diz que sim e não fez nada. A partir daí, cada teste tem duas metades: a resposta dele e o estado real do sistema.

6. Uma fronteira testa-se dos dois lados

Não chega ver que fecha às 15h30. É preciso ver que abre às 14h30.

Um lado só não distingue "fechou à hora certa" de "está sempre fechado". Já demos um sistema por avariado por o termos testado às 15h00 em ponto, que era o último minuto aberto.

7. Há perguntas que parecem técnicas e são de negócio

Se o filtro compara a hora a que o serviço começa ou a hora a que acaba contra a hora de fecho, isso decide se a última marcação do dia pode terminar depois de a porta fechar.

Numa barbearia acaba-se o corte já começado e ninguém discute. Noutro negócio esses quinze minutos custam dinheiro.

Isto não se decide sozinho. Pergunta-se ao cliente, ou sabe-se o suficiente do negócio dele para responder por ele, e escreve-se a razão ao lado para ninguém a mudar daqui a três meses sem saber o que está a mexer.

8. Um dado que se lê e nunca decide nada

Havia uma coluna na folha de dados que era lida, tratada, e não mandava em coisa nenhuma. As horas que ela devia controlar estavam escritas à mão dentro de um filtro da automação.

Mudar a folha não mudava nada, e ninguém percebia porquê.

Como se apanha: antes de acreditar que um dado manda em alguma coisa, segue-se a cadeia até ao fim. Se um valor não aparece em nenhuma expressão a jusante, é decorativo. O atalho é procurar números soltos dentro da automação: uma hora, uma duração ou um limite escrito à mão é sempre um dado que devia vir de fora.

9. Um mau resultado repetido três vezes é quase sempre de quem mede

Aconteceu-nos duas vezes. Uma foi um teste que partia o endereço a que chamava. Outra foi um filtro a apontar para o sítio errado.

Antes de acusar o sistema, verifica-se a medição.

O que isto tudo quer dizer

Nenhuma destas nove é sobre escolher o modelo certo. São sobre o que está à volta dele: os dados que lhe chegam, os exemplos que lê, o servidor que o trava, e a maneira como se testa.

É por isso que um agente se monta em camadas separadas, com as regras de negócio fora das instruções e a segurança fora do modelo. E é por isso que a maior parte do tempo de um projeto destes não se passa a escrever instruções, passa-se a fazer conversas de teste e a ir ao calendário confirmar o que aconteceu.