Interfaces de IA para quem não escreve prompts

Neste contexto de design, um prompt é a instrução e o contexto fornecidos a um modelo de IA. Tratar esse material como a interface principal concentra várias decisões de design num único campo de texto: que informação é importante, como deve ser formulado o pedido, que restrições se aplicam e que forma deve assumir o resultado. Essa flexibilidade pode adequar-se a algumas tarefas, mas continua a ser uma escolha de produto, em vez de uma opção predefinida neutra.

Uma alternativa consiste em conceber a interação em torno do próprio trabalho. O produto pode recolher material relevante, apresentar escolhas significativas e devolver um resultado preparado para um passo seguinte específico. Isto não elimina a construção do prompt. Transfere essa construção para um sistema que os designers podem inspecionar, testar e rever.

Começar pela tarefa, não pelo prompt

Comece por descrever o trabalho em termos que não dependam de um modelo. Identifique o material de origem, a decisão a apoiar, a pessoa responsável pela revisão e a ação que se segue. Um pedido abrangente de ajuda com um documento deixa muitas decisões da interface por resolver. Uma tarefa centrada na extração de perguntas por resolver para posterior revisão dá ao produto um limite mais claro.

A interface deve representar as escolhas que alteram de forma concreta o resultado. Evite pedir informação apenas porque esta poderá ser útil. Cada campo, seleção e valor predefinido deve estar associado a uma regra de resultado ou a uma condição de implementação que a equipa tenha verificado.

• Defina o material de origem e os respetivos limites.
• Indique a decisão pretendida ou a ação seguinte.
• Identifique as restrições que podem alterar o que constitui um resultado aceitável.
• Especifique quem revê o resultado antes da utilização.

Transformar o contexto em entradas estruturadas

Uma entrada estruturada é informação recolhida através de campos identificados, opções selecionadas ou material anexado, em vez de ser inteiramente reunida em texto livre. A estrutura pode clarificar a tarefa quando as respetivas categorias correspondem ao trabalho pretendido. Um formulário rígido que omita uma exceção importante pode ser menos útil do que um formulário pequeno com um campo de notas opcional.

Separe os factos fornecidos das instruções e preferências. Esta distinção pode ajudar a preservar a proveniência, ou seja, a origem da informação, mantendo as escolhas de formatação separadas do conteúdo de origem. O prompt interno pode combinar estas partes, mas a interface visível deve permitir que a pessoa responsável pela revisão compreenda o que entrou no processo.

1. Recolha o mínimo de material de origem necessário para a tarefa.
2. Peça as restrições através de escolhas com consequências claras.
3. Apresente exemplos apenas quando estes clarificarem a entrada esperada.
4. Preserve o contexto opcional sem lhe atribuir tacitamente autoridade.
5. Mostre o que será processado antes de o processamento começar.

Tornar visíveis as escolhas do sistema

Se o produto construir uma instrução por detrás da interface, também faz escolhas editoriais. Pode selecionar contexto, atribuir etiquetas, pedir um formato ou excluir material. A equipa deve documentar essas escolhas como parte da funcionalidade, mesmo quando a instrução interna completa não aparece na interface principal.

Uma visibilidade útil não exige a exposição de todos os detalhes técnicos. Significa mostrar as condições que afetam a tarefa, incluindo as fontes selecionadas, as restrições ativas, o tipo de resultado e as exclusões. Se um modelo ou método de processamento mudar, a equipa deve verificar se essa alteração afeta estas condições antes de a considerar um mero detalhe interno de implementação.

Ao nível da interface, apresente as fontes selecionadas e o material omitido, resuma as restrições ativas em linguagem corrente, distinga os valores predefinidos do produto das seleções explícitas e permita rever as escolhas automáticas que têm consequências. Cada elemento deve estar associado a uma condição que possa alterar o resultado ou a revisão necessária.

Preparar os resultados para revisão e reutilização

A resposta de um modelo não deve tornar-se automaticamente no artefacto final do produto. Conceba o resultado em função da forma como será verificado, editado, copiado, comparado ou aprovado. Uma resposta conversacional pode ser adequada a uma tarefa exploratória, enquanto uma tarefa de revisão pode exigir conclusões identificadas e associadas ao material fornecido. A forma adequada é uma decisão de produto.

Separe o conteúdo gerado da informação de estado. A informação de estado descreve as condições de processamento, as entradas em falta ou as verificações que exigem atenção. Não deve ser incorporada no texto proposto. Se a incerteza for relevante, apresente o motivo da revisão, como passagens contraditórias no material de origem ou uma restrição por cumprir, em vez de pressupor que existe um valor numérico de confiança ou que esse valor é significativo.

1. Apresente o artefacto pedido na estrutura pretendida.
2. Coloque os avisos e as notificações de entradas em falta fora do conteúdo gerado.
3. Mantenha as referências às fontes associadas quando a implementação o permitir.
4. Disponibilize controlos de edição adequados à ação prática seguinte.

Avaliar o ciclo completo da interação

A avaliação deve abranger o percurso desde a seleção das fontes, passando pela construção das entradas, pelo processamento e pela revisão, até à ação final. Um conjunto de avaliação é uma coleção atualizada de exemplos representativos e difíceis, utilizada para verificar uma funcionalidade face a condições definidas. O seu objetivo é tornar o comportamento pretendido passível de inspeção, em vez de reduzir a interação a um exemplo aperfeiçoado.

Escolha exemplos que testem variações significativas da tarefa, como material incompleto, instruções contraditórias e conteúdo que deva permanecer inalterado. Registe o que a pessoa responsável pela revisão deve inspecionar, em vez de reduzir cada resultado a uma única pontuação. Quando as condições de implementação mudarem, volte a executar as verificações relevantes e examine se a interface continua a comunicar os respetivos limites.

• Confirme que cada controlo visível altera a condição pretendida.
• Verifique se a informação omitida continua claramente assinalada como omitida.
• Reveja os resultados segundo critérios de aceitação específicos da tarefa.
• Teste os percursos de recuperação para entradas incompletas ou inadequadas.
• Mantenha a aprovação humana nas decisões que exigem discernimento.

Criar um contrato de entrada e resultado

Um design prático pode ser resumido como um contrato: o produto declara o que aceita, como esse material é restringido, o que devolve e onde deve ocorrer a revisão. Este contrato deve ser compreensível sem ser necessário saber escrever um prompt. Internamente, dá à equipa pontos estáveis para testar prompts, modelos e passos de processamento sem confundir esses componentes com a própria interface.

Para a próxima decisão de design, registe quatro elementos: a entrada necessária, as escolhas que têm consequências, o resultado verificável e a ação seguinte. Em seguida, examine cada controlo e mensagem de acordo com essa sequência. Se um elemento não puder ser associado ao contrato, remova-o, clarifique-o ou trate-o como um detalhe de implementação que ainda necessita de verificação.