Vista geral das estratégias de comandos

Embora não exista uma forma certa ou errada de criar um comando, existem estratégias comuns que pode usar para afetar as respostas do modelo. Os testes e a avaliação rigorosos continuam a ser cruciais para otimizar o desempenho do modelo.

Os modelos de linguagem (conteúdo extenso) (MDLs/CE) são preparados com grandes quantidades de dados de texto para aprender os padrões e as relações entre unidades de linguagem. Quando recebem algum texto (o comando), os modelos de linguagem podem prever o que é provável que venha a seguir, como uma ferramenta de preenchimento automático sofisticada. Por isso, ao criar comandos, tenha em conta os diferentes fatores que podem influenciar o que um modelo prevê que vai acontecer a seguir.

Fluxo de trabalho de engenharia de comandos

A engenharia de comandos é um processo iterativo e orientado por testes que pode melhorar o desempenho do modelo. Ao criar comandos, é importante definir claramente os objetivos e os resultados esperados para cada comando e testá-los sistematicamente para identificar áreas de melhoria.

O diagrama seguinte mostra o fluxo de trabalho de engenharia de comandos:

Diagrama do fluxo de trabalho de engenharia de comandos

Como criar um comando eficaz

Existem dois aspetos de um comando que, em última análise, afetam a sua eficácia: o conteúdo e a estrutura.

  • Conteúdo:

    Para concluir uma tarefa, o modelo precisa de todas as informações relevantes associadas à tarefa. Estas informações podem incluir instruções, exemplos, informações contextuais, etc. Para obter detalhes, consulte o artigo Componentes de um comando.

  • Estrutura:

    Mesmo quando todas as informações necessárias são fornecidas no comando, dar uma estrutura às informações ajuda o modelo a analisá-las. Aspetos como a ordem, a etiquetagem e a utilização de delimitadores podem afetar a qualidade das respostas. Para ver um exemplo da estrutura de comandos, consulte o modelo de comando de exemplo.

Componentes de um comando

A tabela seguinte mostra os componentes essenciais e opcionais de um comando:

Componente Descrição Exemplo
Objetivo O que quer que o modelo alcance. Seja específico e inclua quaisquer objetivos abrangentes. Também denominada "missão" ou "objetivo". O seu objetivo é ajudar os alunos com problemas de matemática sem lhes dar diretamente a resposta.
Instruções Instruções passo a passo sobre como realizar a tarefa em questão. Também chamado "tarefa", "passos" ou "direções".
  1. Compreender o que o problema está a pedir.
  2. Compreender onde o aluno está com dificuldades.
  3. Dá uma dica para o passo seguinte do problema.
Componentes opcionais
Instruções do sistema

Diretivas técnicas ou ambientais que podem envolver o controlo ou a alteração do comportamento do modelo num conjunto de tarefas. Para muitas APIs de modelos, as instruções do sistema são especificadas num parâmetro dedicado.

As instruções do sistema estão disponíveis no Gemini 2.0 Flash e em modelos posteriores.

 É um especialista em programação que se dedica à renderização de código para interfaces front-end. Quando descrever um componente de um Website que quero criar, devolve o HTML e o CSS necessários para o fazer. Não inclua uma explicação para este código. Também oferece algumas sugestões de design da IU.
Perfil Quem ou o que o modelo está a representar. Também denominado "função" ou "visão". É um tutor de matemática que está aqui para ajudar os alunos com os seus trabalhos de casa de matemática.
Restrições Restrições que o modelo tem de cumprir ao gerar uma resposta, incluindo o que o modelo pode e não pode fazer. Também denominadas "guardrails", "limites" ou "controlos". Não dê a resposta diretamente ao aluno. Em alternativa, dê sugestões no passo seguinte para resolver o problema. Se o aluno estiver completamente perdido, dê-lhe os passos detalhados para resolver o problema.
Tom O tom da resposta. Também pode influenciar o estilo e o tom especificando uma personagem fictícia. Também denominado "estilo", "voz" ou "ambiente". Responda de forma informal e técnica.
Contexto Quaisquer informações que o modelo precise de consultar para realizar a tarefa em questão. Também denominados "fundo", "documentos" ou "dados de entrada". Uma cópia dos planos de aulas de matemática do aluno.
Exemplos de poucos disparos Exemplos do aspeto que a resposta deve ter para um determinado comando. Também denominados "exemplos" ou "amostras". input: Estou a tentar calcular quantas bolas de golfe cabem numa caixa com um volume de um metro cúbico. Convertei um metro cúbico em centímetros cúbicos e dividi-o pelo volume de uma bola de golfe em centímetros cúbicos, mas o sistema diz que a minha resposta está errada.
output: As bolas de golfe são esferas e não podem ser embaladas num espaço com eficiência perfeita. Os seus cálculos têm em conta a eficiência máxima de embalagem de esferas.
Passos de raciocínio Diga ao modelo para explicar o seu raciocínio. Por vezes, isto pode melhorar a capacidade de raciocínio do modelo. Também denominados "passos de reflexão". Explique o seu raciocínio passo a passo.
Formato de resposta O formato no qual quer que a resposta seja apresentada. Por exemplo, pode indicar ao modelo que gere a resposta em JSON, tabela, Markdown, parágrafo, lista com marcadores, palavras-chave, apresentação rápida, etc. Também denominado "estrutura", "apresentação" ou "esquema". Formate a sua resposta em Markdown.
Recap Repetição concisa dos pontos-chave do comando, especialmente as restrições e o formato de resposta, no final do comando. Não dê a resposta, mas dê pistas. Formate sempre a sua resposta no formato Markdown.
Salvaguardas Fundamenta as perguntas na missão do bot. Também denominadas "regras de segurança". N/A

Consoante as tarefas específicas em questão, pode optar por incluir ou excluir alguns dos componentes opcionais. Também pode ajustar a ordem dos componentes e verificar como isso pode afetar a resposta.

Modelo de comando de exemplo

O seguinte modelo de comando mostra um exemplo do aspeto que um comando bem estruturado pode ter:

      <OBJECTIVE_AND_PERSONA>
      You are a [insert a persona, such as a "math teacher" or "automotive expert"]. Your task is to...
      </OBJECTIVE_AND_PERSONA>

      <INSTRUCTIONS>
      To complete the task, you need to follow these steps:
      1.
      2.
      ...
      </INSTRUCTIONS>

      ------------- Optional Components ------------

      <CONSTRAINTS>
      Dos and don'ts for the following aspects
      1. Dos
      2. Don'ts
      </CONSTRAINTS>

      <CONTEXT>
      The provided context
      </CONTEXT>

      <OUTPUT_FORMAT>
      The output format must be
      1.
      2.
      ...
      </OUTPUT_FORMAT>

      <FEW_SHOT_EXAMPLES>
      Here we provide some examples:
      1. Example #1
          Input:
          Thoughts:
          Output:
      ...
      </FEW_SHOT_EXAMPLES>

      <RECAP>
      Re-emphasize the key aspects of the prompt, especially the constraints, output format, etc.
      </RECAP>

Práticas recomendadas

As práticas recomendadas de design de comandos incluem o seguinte:

Lista de verificação do estado dos comandos

Se um comando não estiver a ter o desempenho esperado, use a seguinte lista de verificação para identificar potenciais problemas e melhorar o desempenho do comando.

Problemas de escrita

  • Gralhas: verifique as palavras-chave que definem a tarefa (por exemplo, sumarizar em vez de resumir), termos técnicos ou nomes de entidades, uma vez que os erros ortográficos podem originar um desempenho fraco.
  • Gramática: se uma frase for difícil de analisar, contiver fragmentos incompletos, tiver sujeitos e verbos que não correspondem ou parecer estruturalmente estranha, o modelo pode não compreender corretamente o comando.
  • Pontuação: verifique a utilização de vírgulas, pontos, aspas e outros separadores, uma vez que a pontuação incorreta pode fazer com que o modelo interprete mal o comando.
  • Utilização de gíria indefinida: evite utilizar termos específicos do domínio, acrónimos ou siglas como se tivessem um significado universal, a menos que sejam definidos explicitamente no comando.
  • Clareza: se tiver dúvidas sobre o âmbito, os passos específicos a dar ou as suposições implícitas que estão a ser feitas, é provável que o comando não seja claro.
  • Ambiguidade: evite usar qualificadores subjetivos ou relativos que não tenham uma definição concreta e mensurável. Em vez disso, forneça restrições objetivas (por exemplo, "escreve um resumo de 3 frases ou menos" em vez de "escreve um breve resumo").
  • Falta de informações importantes: se a tarefa exigir o conhecimento de um documento específico, uma política da empresa, o histórico do utilizador ou um conjunto de dados, certifique-se de que essas informações estão explicitamente incluídas no comando.
  • Escolha de palavras inadequada: verifique se a instrução tem expressões desnecessariamente complexas, vagas ou detalhadas, uma vez que podem confundir o modelo.
  • Revisão secundária: se o modelo continuar a ter um desempenho fraco, peça a outra pessoa para rever o seu comando.

Problemas com instruções e exemplos

  • Manipulação explícita: remova do comando a linguagem que não esteja relacionada com a tarefa principal e que tente influenciar o desempenho através de apelos emocionais, elogios ou pressão artificial. Embora os modelos de base de primeira geração tenham apresentado melhorias em algumas circunstâncias com instruções como "vão acontecer coisas muito más se não fizer isto corretamente", o desempenho dos modelos de base deixou de melhorar e, em muitos casos, vai piorar.
  • Instruções e exemplos em conflito: verifique se existem contradições lógicas ou incompatibilidades entre instruções ou entre uma instrução e um exemplo, auditando o comando.
  • Instruções e exemplos redundantes: reveja o comando e os exemplos para ver se a mesma instrução ou conceito exato é indicado várias vezes de formas ligeiramente diferentes sem adicionar novas informações ou nuances.
  • Instruções e exemplos irrelevantes: verifique se todas as instruções e exemplos são essenciais para a tarefa principal. Se for possível remover instruções ou exemplos sem diminuir a capacidade do modelo de realizar a tarefa principal, podem ser irrelevantes.
  • Utilização de exemplos de "few-shot": se a tarefa for complexa, exigir um formato específico ou tiver um tom matizado, certifique-se de que existem exemplos concretos e ilustrativos que mostrem uma entrada de amostra e a saída correspondente.
  • Especificação do formato de saída em falta: evite deixar o modelo adivinhar a estrutura da saída. Em alternativa, use uma instrução clara e explícita para especificar o formato e mostrar a estrutura de saída nos seus exemplos de poucos lançamentos.
  • Definição de função em falta: se vai pedir ao modelo para agir numa função específica, certifique-se de que essa função está definida nas instruções do sistema.

Problemas de design do sistema e de comandos

  • Tarefa pouco especificada: certifique-se de que as instruções do comando fornecem um caminho claro para processar casos extremos e entradas inesperadas, e fornecem instruções para processar dados em falta em vez de assumir que os dados inseridos estão sempre presentes e bem formados.
  • Tarefa fora das capacidades do modelo: evite usar comandos que peçam ao modelo para realizar uma tarefa para a qual tem uma limitação fundamental conhecida.
  • Demasiadas tarefas: se o comando pedir ao modelo para realizar várias ações cognitivas distintas numa única passagem (por exemplo, 1. Resumir, 2. Extrair entidades, 3. Traduzir e 4. Elaborar um email), é provável que esteja a tentar fazer demasiado. Divida os pedidos em comandos separados.
  • Formato de dados não padrão: quando as saídas do modelo têm de ser legíveis por máquina ou seguir um formato específico, use um padrão amplamente reconhecido, como JSON, XML, Markdown ou YAML, que possa ser analisado por bibliotecas comuns. Se o seu exemplo de utilização exigir um formato não padrão, considere pedir ao modelo para gerar resultados num formato comum e, em seguida, usar código para converter o resultado.
  • Ordem incorreta da cadeia de raciocínio (CoT): evite fornecer exemplos que mostrem o modelo a gerar a sua resposta final e estruturada antes de ter concluído o raciocínio passo a passo.
  • Referências internas em conflito: evite escrever um comando com lógica não linear ou condições que exijam que o modelo junte instruções fragmentadas de vários locais diferentes no comando.
  • Risco de injeção de comandos: verifique se existem salvaguardas explícitas em torno da entrada do utilizador não fidedigna que é inserida no comando, uma vez que isto pode ser um risco de segurança importante.

O que se segue?