Engenharia de Prompts com o 3CX: Parte 1

Seu Agente de IA não precisa de um manifesto. Ele precisa de uma especificação concisa e inequívoca. Veja aqui como redigir uma.

Recentemente, reescrevemos o prompt do nosso sistema Receptionista de IA. A versão anterior tinha 450 Linhas, estava lindamente estruturada, repleta de políticas cuidadosamente fundamentadas — e ocupava tanto espaço na janela de contexto que o agente tinha menos espaço para realmente ouvir o interlocutor! Para ajudar você a evitar os mesmos problemas, este blog — Parte 1 agora e Parte 2 a seguir — explica como parar de escrever poesia e começar a escrever instruções, então continue lendo para saber mais!

O Erro Que Todo Mundo Comete Primeiro

Não somos os únicos a cometer esse erro. Quase todos os clientes 3CX que editam um prompt do sistema pela primeira vez cometem o mesmo erro: tratam o prompt como um documento de política, um contrato legal ou — pior ainda — uma tarefa de redação criativa.

Aqui está a armadilha: como as mensagens são escritas em inglês, as pessoas esquecem que estão escrevendo código. Elas escrevem parágrafos. Acrescentam adjetivos. Definem termos que o modelo já compreende. Repetem a mesma instrução cinco vezes porque acham que é importante.

O modelo não lê prosa da mesma forma que os humanos. Cada palavra em sua solicitação custa contexto, atenção e — frequentemente — consistência. Uma solicitação longa não é uma solicitação mais cuidadosa. Geralmente é uma solicitação pior.

Este guia é o que aprendemos ao reescrever a nossa própria solicitação. Se você estiver editando a solicitação do sistema de um Agente de IA 3CX, leia-o antes de salvar.

A Armadilha do Inglês

Quando a engenharia de prompts significava escrever para uma API em JSON bruto, as pessoas a respeitavam como uma disciplina técnica. Agora que as instruções estão em inglês, as pessoas escrevem da mesma forma que escrevem uma mensagem no Slack para um novo funcionário.

Veja este trecho da versão antiga do nosso próprio prompt:

“O motivo do chamador é necessário antes da transferência, mas não deve ser usado para identificar, restringir, classificar, esclarecer ambiguidades, substituir ou anular o destino solicitado.”

Essa frase é gramaticalmente correta, bem pensada e quase impossível para um modelo seguir de forma consistente durante uma chamada real. Seis quase-sinônimos. Duas orações. Uma negação envolvendo um requisito. Na terceira rodada da conversa, o modelo já a interpreta de maneira diferente do que fez na primeira.

Eis o que ficou:

“Não use a pesquisa de informações para decidir quem deve receber uma chamada.”

Uma frase. Uma instrução. Zero ambiguidade. Mesmo comportamento.

Regra número um da engenharia de prompts: o inglês é a interface, não o gênero. Você ainda está escrevendo instruções. Curtas, declarativas, testáveis. Se uma frase parecer algo que você encontraria em um documento de termos de serviço, apague-a e tente novamente.

Pare de Definir Coisas para o Modelo

O prompt antigo continha esta pérola:

“Um handoff é qualquer próximo passo permitido executado por meio de uma das ações listadas abaixo.”

O modelo sabe o que é um handoff (transferência). Ele também sabe o que significam “transferência”, “correio de voz” e “e-mail”. Definir termos cotidianos de volta para o modelo é um hábito emprestado da redação técnica para humanos. Em um prompt, isso apenas gasta tokens e cria espaço para o modelo interpretar erroneamente.

O mesmo se aplica a títulos de seção cerimoniais. O prompt antigo tinha:

• Aplicação Obrigatória
• Ordem de Prioridade
• Esquema de Base
• Regras de Seleção de Ação

Parecem ter saído de um RFC. Não acrescentam nada ao comportamento. O novo prompt usa títulos como Estilo, Encaminhamento, Hostilidade — rótulos curtos que descrevem o tema da seção, não o quão séria ela soa.

Regra dois: se uma linha não altera o que o modelo faz, exclua-a.

Diga Uma Vez

Uma das piores patologias em prompts longos é a mesma regra aparecer em quatro lugares. Em nossa versão antiga, “não transferir se o destino for ambíguo” aparecia, com pequenas variações, em:

• Regra de Ambiguidade de Destino
• Porta de Ação de Transferência
• Regras de Diretório
• Contrato de Saída Confidencial

Cada reformulação era um pouco diferente. Cada uma usava uma redação ligeiramente diferente. Um ser humano que as lê vê quatro versões da mesma ideia e compreende a intenção. Um modelo que as lê vê quatro regras — e quando elas não concordam perfeitamente, ele precisa escolher. Às vezes, ele escolhe de maneira diferente na terceira chamada do dia do que na primeira.

Regra três: toda regra pertence a exatamente um lugar. Se você se pegar reforçando uma regra ao repeti-la em uma nova seção, você não precisa de uma nova seção. Você precisa de uma primeira versão mais clara.

Pare de Acumular Proibições

Veja isto:

“Não escolha o primeiro resultado, o melhor resultado, o resultado disponível ou o resultado mais relevante.”

São quatro instruções negativas em que bastaria uma instrução positiva. O que a regra realmente significa é:

“Se a pesquisa retornar várias correspondências, peça ao solicitante para esclarecer.”

Instruções positivas dizem ao modelo o que fazer. Instruções negativas dizem ao modelo o que evitar, o que deixa em aberto a questão do que fazer em vez disso — e o modelo inventará uma resposta.

Regra quatro: prefira instruções positivas. Use “não” apenas quando não houver equivalente positivo.

Fique Atento Às Contradições

Esta é a assassina silenciosa. O prompt antigo continha duas seções que, lidas juntas, eram inconsistentes:

• Encaminhamento pela Lógica: quando o chamador fornecer um motivo, consulte a agenda de contatos para determinar o destino.
• Encaminhamento por Destino Solicitado: quando o chamador pedir uma pessoa ou departamento, não use o motivo para o encaminhamento.

Ambas são verdadeiras. Ambas são razoáveis. Mas, quando sequenciadas em uma longa mensagem com exemplos sobrepostos e sub-regras reforçadoras, o modelo fica confuso sobre qual delas se aplica — e essa confusão se manifesta como um comportamento inconsistente que o cliente nunca consegue reproduzir sob demanda.

Use OpenAI Tokenizer para ver como o modelo realmente divide sua mensagem em tokens. Em seguida, leia a mensagem de volta como se não soubesse nada sobre sua empresa, em ordem, sem contexto. Se duas regras puderem se aplicar plausivelmente à mesma situação e levar a ações diferentes, você tem uma contradição — mesmo que consiga explicar por que elas não entram em conflito.

Regra cinco: uma mensagem é consistente quando nenhuma regra pode se aplicar e, ao mesmo tempo, discordar. Não quando você consegue racionalizar a diferença.

Nos próximos dias, publicaremos a Parte 2 desta série, onde examinaremos mais de perto o que o modelo pode e não pode fazer, dicas para engenheiros de prompts iniciantes e muito mais. Fique ligado!

Participe da Discussão

Participe da discussão sobre o 3CX em nossos fóruns. Siga-nos no X e no LinkedIn para se manter atualizado sobre as últimas notícias e lançamentos de recursos.