Resumen de las estrategias de formulación de peticiones

Aunque no hay una forma correcta o incorrecta de diseñar una petición, existen estrategias comunes que puedes usar para influir en las respuestas del modelo. Las pruebas y evaluaciones rigurosas siguen siendo fundamentales para optimizar el rendimiento de los modelos.

Los modelos de lenguaje extensos (LLMs) se entrenan con grandes cantidades de datos de texto para aprender los patrones y las relaciones entre las unidades de lenguaje. Cuando se les proporciona un texto (la petición), los modelos de lenguaje pueden predecir lo que es probable que venga después, como una herramienta de autocompletado sofisticada. Por lo tanto, al diseñar las peticiones, ten en cuenta los diferentes factores que pueden influir en lo que predice un modelo que viene a continuación.

Flujo de trabajo de ingeniería de peticiones

La ingeniería de peticiones es un proceso iterativo basado en pruebas que puede mejorar el rendimiento de los modelos. Al crear peticiones, es importante definir claramente los objetivos y los resultados esperados de cada una de ellas, así como probarlas de forma sistemática para identificar áreas de mejora.

En el siguiente diagrama se muestra el flujo de trabajo de la ingeniería de peticiones:

Diagrama del flujo de trabajo de ingeniería de peticiones

Cómo crear una petición eficaz

Hay dos aspectos de una petición que afectan a su eficacia: el contenido y la estructura.

  • Content:

    Para completar una tarea, el modelo necesita toda la información pertinente asociada a ella. Esta información puede incluir instrucciones, ejemplos, información contextual, etc. Para obtener más información, consulta Componentes de una petición.

  • Estructura:

    Aunque se proporcione toda la información necesaria en la petición, indicar la estructura de la información ayuda al modelo a analizarla. Aspectos como el orden, las etiquetas y el uso de delimitadores pueden afectar a la calidad de las respuestas. Para ver un ejemplo de estructura de petición, consulta la plantilla de petición de ejemplo.

Componentes de una petición

En la siguiente tabla se muestran los componentes esenciales y opcionales de una petición:

Componente Descripción Ejemplo
Objetivo Lo que quieres que consiga el modelo. Sé específico e incluye los objetivos generales. También se denomina "misión" u "objetivo". Tu objetivo es ayudar a los alumnos con problemas matemáticos sin darles la respuesta directamente.
Instrucciones Instrucciones detalladas sobre cómo realizar la tarea. También se denomina "tarea", "pasos" o "indicaciones".
  1. Entiende lo que se pide en el problema.
  2. Averigua dónde se ha quedado atascado el alumno.
  3. Da una pista para el siguiente paso del problema.
Componentes opcionales
Instrucciones del sistema

Directrices técnicas o ambientales que pueden implicar el control o la modificación del comportamiento del modelo en un conjunto de tareas. En muchas APIs de modelos, las instrucciones del sistema se especifican en un parámetro específico.

Las instrucciones del sistema están disponibles en Gemini 2.0 Flash y modelos posteriores.

 Eres un experto en programación especializado en renderizar código para interfaces de frontend. Cuando te describa un componente de un sitio web que quiero crear, devuélveme el HTML y el CSS necesarios para hacerlo. No me des ninguna explicación sobre este código. También ofrece algunas sugerencias de diseño de la interfaz de usuario.
Perfil ficticio Quién o qué es el modelo. También se denomina "rol" o "visión". Eres un tutor de matemáticas y tu objetivo es ayudar a los alumnos con sus deberes de matemáticas.
Restricciones Restricciones que debe cumplir el modelo al generar una respuesta, incluido lo que puede y no puede hacer. También se denominan "medidas de protección", "límites" o "controles". No le des la respuesta directamente. En su lugar, da pistas en el siguiente paso para resolver el problema. Si el alumno no sabe cómo seguir, proporciónale los pasos detallados para resolver el problema.
Tono El tono de la respuesta. También puedes influir en el estilo y el tono especificando un perfil. También se denomina "estilo", "voz" o "tono". Responde de forma informal y técnica.
Contexto Cualquier información que el modelo necesite consultar para llevar a cabo la tarea. También se denomina "fondo", "documentos" o "datos de entrada". Una copia de las guías didácticas de matemáticas del alumno.
Ejemplos de few-shot Ejemplos de cómo debería ser la respuesta a una petición determinada. También se denominan "ejemplares" o "muestras". input: Estoy intentando calcular cuántas pelotas de golf caben en una caja que tiene un metro cúbico de volumen. He convertido un metro cúbico en centímetros cúbicos y lo he dividido entre el volumen de una pelota de golf en centímetros cúbicos, pero el sistema dice que mi respuesta es incorrecta.
Las pelotas de golf output: son esferas y no se pueden empaquetar en un espacio con una eficiencia perfecta. En tus cálculos se tiene en cuenta la eficiencia de empaquetamiento máxima de las esferas.
Pasos de razonamiento Pide al modelo que explique su razonamiento. A veces, esto puede mejorar la capacidad de razonamiento del modelo. También se denominan "pasos de pensamiento". Explica tu razonamiento paso a paso.
Formato de respuesta El formato en el que quieres que se muestre la respuesta. Por ejemplo, puedes pedirle al modelo que genere la respuesta en formato JSON, tabla, Markdown, párrafo, lista con viñetas, palabras clave, breve descripción, etc. También se denomina "estructura", "presentación" o "diseño". Da formato Markdown a tu respuesta.
Resumen Repetición concisa de los puntos clave de la petición, especialmente las restricciones y el formato de la respuesta, al final de la petición. No des la respuesta y ofrece pistas. Siempre debes dar formato a tu respuesta en formato Markdown.
Protecciones Centra las preguntas en la misión del bot. También se denominan "reglas de seguridad". N/A

En función de las tareas específicas que tengas que realizar, puedes incluir o excluir algunos de los componentes opcionales. También puedes ajustar el orden de los componentes y comprobar cómo puede afectar a la respuesta.

Plantilla de petición de ejemplo

En la siguiente plantilla de petición se muestra un ejemplo de cómo podría ser una petición bien estructurada:

      <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ácticas recomendadas

Entre las prácticas recomendadas para diseñar peticiones, se incluyen las siguientes:

Lista de comprobación de la salud de las peticiones

Si una petición no funciona como se espera, usa la siguiente lista de comprobación para identificar posibles problemas y mejorar su rendimiento.

Problemas de escritura

  • Errores ortográficos: comprueba las palabras clave que definen la tarea (por ejemplo, sumarize en lugar de summarize), los términos técnicos o los nombres de entidades, ya que los errores ortográficos pueden dar lugar a un rendimiento deficiente.
  • Gramática: si una frase es difícil de analizar, contiene fragmentos continuos, tiene sujetos y verbos que no concuerdan o resulta extraña desde el punto de vista estructural, es posible que el modelo no entienda bien la petición.
  • Signos de puntuación: comprueba que has usado comas, puntos, comillas y otros separadores correctamente, ya que una puntuación incorrecta puede hacer que el modelo interprete mal la petición.
  • Uso de jerga indefinida: no uses términos, acrónimos o inicialismos específicos de un ámbito como si tuvieran un significado universal, a menos que se definan explícitamente en la petición.
  • Claridad: si no tienes claro el alcance, los pasos específicos que debes seguir o las suposiciones implícitas, es probable que la petición no sea clara.
  • Ambigüedad: evita usar calificadores subjetivos o relativos que no tengan una definición concreta y medible. En su lugar, proporciona restricciones objetivas (por ejemplo, "escribe un resumen de tres frases o menos" en lugar de "escribe un breve resumen").
  • Falta información clave: si la tarea requiere conocer un documento, una política de la empresa, un historial de usuario o un conjunto de datos específicos, asegúrate de que esa información se incluya explícitamente en la petición.
  • Elección de palabras inadecuada: comprueba si la petición contiene frases innecesariamente complejas, vagas o extensas, ya que podrían confundir al modelo.
  • Revisión secundaria: si el modelo sigue dando malos resultados, pide a otra persona que revise tu petición.

Problemas con las instrucciones y los ejemplos

  • Manipulación evidente: elimina del prompt el lenguaje que no esté relacionado con la tarea principal y que intente influir en el rendimiento mediante recursos emocionales, halagos o presión artificial. Aunque los modelos fundacionales de primera generación han mejorado en algunas circunstancias con instrucciones como "si no lo haces bien, ocurrirán cosas muy malas", el rendimiento de los modelos fundacionales ya no mejorará y, en muchos casos, empeorará.
  • Instrucciones y ejemplos contradictorios: para comprobar si hay contradicciones lógicas o discrepancias entre las instrucciones o entre una instrucción y un ejemplo, audita la petición.
  • Instrucciones y ejemplos redundantes: revisa la petición y los ejemplos para ver si la misma instrucción o concepto se indica varias veces de formas ligeramente diferentes sin añadir información ni matices nuevos.
  • Instrucciones y ejemplos irrelevantes: comprueba si todas las instrucciones y los ejemplos son esenciales para la tarea principal. Si se pueden eliminar instrucciones o ejemplos sin reducir la capacidad del modelo para llevar a cabo la tarea principal, es posible que no sean relevantes.
  • Uso de ejemplos de "pocos disparos":si la tarea es compleja, requiere un formato específico o tiene un tono matizado, asegúrate de que haya ejemplos concretos e ilustrativos que muestren una entrada de muestra y la salida correspondiente.
  • Falta la especificación del formato de salida: no dejes que el modelo adivine la estructura de la salida. En su lugar, usa una instrucción clara y explícita para especificar el formato y mostrar la estructura de la salida en los ejemplos de pocas peticiones.
  • Falta la definición del rol: si vas a pedirle al modelo que actúe en un rol específico, asegúrate de que ese rol esté definido en las instrucciones del sistema.

Problemas de diseño de peticiones y del sistema

  • Tarea poco especificada: asegúrate de que las instrucciones de la petición proporcionen un camino claro para gestionar los casos extremos y las entradas inesperadas, y proporcionen instrucciones para gestionar los datos que faltan en lugar de asumir que los datos insertados siempre estarán presentes y bien formados.
  • Tarea que supera las capacidades del modelo: no uses peticiones que pidan al modelo que realice una tarea para la que tiene una limitación fundamental conocida.
  • Demasiadas tareas: si la petición pide al modelo que realice varias acciones cognitivas distintas en una sola pasada (por ejemplo, 1. Resumir, 2. Extraer entidades, 3. Traduce y 4. Redacta un correo), es probable que esté intentando hacer demasiado. Divide las solicitudes en varias peticiones.
  • Formato de datos no estándar: cuando las salidas del modelo deben ser legibles por máquina o seguir un formato específico, usa un estándar ampliamente reconocido, como JSON, XML, Markdown o YAML, que puedan analizar bibliotecas comunes. Si tu caso práctico requiere un formato no estándar, plantéate pedirle al modelo que genere el resultado en un formato común y, después, usar código para convertirlo.
  • Orden incorrecto de la cadena de pensamiento: no proporciones ejemplos que muestren al modelo generando su respuesta final estructurada antes de que haya completado su razonamiento paso a paso.
  • Referencias internas contradictorias: no escribas una petición con una lógica no lineal o condicionales que requieran que el modelo combine instrucciones fragmentadas de diferentes partes de la petición.
  • Riesgo de inyección de peticiones: comprueba si hay medidas de protección explícitas en torno a las entradas de usuarios no fiables que se insertan en la petición, ya que esto puede suponer un riesgo de seguridad importante.

Siguientes pasos