Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Diseño de una petición
Diseñar una petición adecuada es un paso importante para crear una aplicación que funcione bien con los modelos de Amazon Bedrock. En esta sección, aprenderá a diseñar una petición coherente, clara y concisa. También aprenderá a controlar la respuesta de un modelo mediante el uso de parámetros de inferencia. La siguiente figura muestra un diseño de petición genérico para el caso de uso, un resumen de las reseñas de restaurantes y algunas opciones de diseño importantes que los clientes deben tener en cuenta al diseñar las peticiones. Los LLM generan respuestas indeseables si las instrucciones que reciben o el formato de la petición no son consistentes, claros y concisos.
![Ejemplo de una buena construcción de petición con comentarios descriptivos.](images/example-good-prompt-construction.png)
(Origen: petición escrita por AWS)
El siguiente contenido proporciona orientación sobre cómo crear peticiones correctamente.
Temas
- Proporcionar instrucciones sencillas, claras y completas
- La pregunta o instrucción debe colocarse al final de la petición para obtener los mejores resultados
- Utilice caracteres separadores para las llamadas a la API
- Uso de indicadores de resultados
- Prácticas recomendadas para una buena generalización
- Optimice las peticiones para los modelos de texto en Amazon Bedrock, cuando lo básico no sea suficiente
- Control de la respuesta del modelo con parámetros de inferencia
Proporcionar instrucciones sencillas, claras y completas
Los LLM de Amazon Bedrock funcionan mejor con instrucciones sencillas y directas. Al describir claramente las expectativas de la tarea y reducir la ambigüedad siempre que sea posible, puede asegurarse de que el modelo pueda interpretar la petición con claridad.
Por ejemplo, pensemos en un problema de clasificación en el que el usuario desea obtener una respuesta a partir de un conjunto de posibles opciones. El ejemplo «bueno» que se muestra a continuación ilustra la salida que el usuario desea en este caso. En el ejemplo «malo», las opciones no se nombran explícitamente como categorías para que el modelo pueda elegir. El modelo interpreta la entrada de forma ligeramente diferente, sin opciones y produce un resumen del texto de forma más libre, a diferencia del ejemplo bueno.
|
|
(Origen de la petición: entrada de Wikipedia sobre daltonismo
La pregunta o instrucción debe colocarse al final de la petición para obtener los mejores resultados
Incluir la descripción de la tarea, la instrucción o la pregunta al final ayuda al modelo a determinar qué información debe encontrar. En el caso de la clasificación, las opciones de respuesta también deberían aparecer al final.
En el siguiente ejemplo de pregunta-respuesta de libro abierto, el usuario tiene una pregunta específica sobre el texto. La pregunta debe aparecer al final de la petición para que el modelo pueda centrarse en la tarea.
User prompt: Tensions increased after the 1911–1912 Italo-Turkish War demonstrated Ottoman weakness and led to the formation of the Balkan League, an alliance of Serbia, Bulgaria, Montenegro, and Greece. The League quickly overran most of the Ottomans' territory in the Balkans during the 1912–1913 First Balkan War, much to the surprise of outside observers. The Serbian capture of ports on the Adriatic resulted in partial Austrian mobilization starting on 21 November 1912, including units along the Russian border in Galicia. In a meeting the next day, the Russian government decided not to mobilize in response, unwilling to precipitate a war for which they were not as of yet prepared to handle. Which country captured ports?
Output: Serbia
(Origen de la petición: entrada de Wikipedia sobre la Primera Guerra Mundial
Utilice caracteres separadores para las llamadas a la API
Utilice caracteres separadores para las llamadas a la API
Los caracteres separadores como \n
pueden afectar significativamente al rendimiento de los LLM. En el caso de los modelos Anthropic Claude, es necesario incluir líneas nuevas al formatear las llamadas a la API para obtener las respuestas deseadas. El formato siempre debe ser el siguiente: \n\nHuman: {{Query
Content}}\n\nAssistant:
. Para los modelos Titan, agregar \n
al final de una petición ayuda a mejorar el rendimiento del modelo. Para tareas de clasificación o preguntas con opciones de respuesta, también puede separar las opciones de respuesta mediante \n
para los modelos Titan. Para obtener más información sobre el uso de separadores, consulte el documento del proveedor de modelos correspondiente. El siguiente ejemplo es una plantilla para una tarea de clasificación.
Prompt template: """{{Text}} {{Question}} {{Choice 1}} {{Choice 2}} {{Choice 3}}"""
El siguiente ejemplo muestra cómo la presencia de caracteres de nueva línea entre las opciones y al final de una petición ayuda a Titan a producir la respuesta deseada.
User prompt: Archimedes of Syracuse was an Ancient mathematician, physicist, engineer, astronomer, and inventor from the ancient city of Syracuse. Although few details of his life are known, he is regarded as one of the leading scientists in classical antiquity. What was Archimedes? Choose one of the options below. a) astronomer b) farmer c) sailor
Output: a) astronomer
(Origen de la petición: entrada de Wikipedia sobre Arquímedes
Uso de indicadores de resultados
Indicadores de resultados
Añada detalles sobre las restricciones que le gustaría tener en la salida que debería producir el modelo. El siguiente ejemplo bueno produce una salida que es una frase corta que constituye un buen resumen. El ejemplo malo en este caso no es tan malo, pero el resumen es casi tan largo como el texto original. La especificación de la salida es crucial para obtener lo que se desea del modelo.
Ejemplo de indicador con un indicador claro de restricciones de salida
|
Ejemplo sin especificaciones de salida claras
|
(Origen de la petición: entrada de Wikipedia sobre Charles Mingus
A continuación, ofrecemos algunos ejemplos adicionales de los modelos Anthropic Claude y AI21 Labs que utilizan indicadores de salida.
El siguiente ejemplo demuestra que el usuario puede especificar el formato de salida especificando el formato de salida esperado en la petición. Cuando se le pide que genere una respuesta con un formato específico (por ejemplo, mediante etiquetas XML), el modelo puede generar la respuesta en consecuencia. Sin un indicador de formato de salida específico, el modelo genera texto de formato libre.
Ejemplo con indicador claro, con salida
|
Ejemplo sin indicador claro, con salida
|
(Origen de la petición: entrada de Wikipedia sobre machine learning
El siguiente ejemplo muestra una petición y una respuesta para el modelo AI21 Labs Jurassic. El usuario puede obtener la respuesta exacta especificando el formato de salida que se muestra en la columna de la izquierda.
Ejemplo con indicador claro, con salida
|
Ejemplo sin indicador claro, con salida
|
(Origen de la petición: entrada de Wikipedia sobre la Liga Nacional de Fútbol
Prácticas recomendadas para una buena generalización
Mantenga un pequeño conjunto de instrucciones de prueba «de espera» para ver si sus modificaciones de peticiones se generalizan. Con este método, primero se recopila un conjunto de datos de muestra. Luego, puede dividir los datos en dos subconjuntos: un conjunto de «desarrollo» y un conjunto de «prueba» retenido. Utilice el conjunto de «desarrollo» como dato de desarrollo de peticiones con el que podrá probar diferentes modificaciones de peticiones y observar los cambios en la respuesta del modelo para encontrar la petición que mejor funcione. Trate el conjunto de «pruebas» como datos de reserva invisibles que solo pueden usarse para verificar la mejor petición final.
Optimice las peticiones para los modelos de texto en Amazon Bedrock, cuando lo básico no sea suficiente
Tareas complejas: busque la respuesta paso a paso
Titan puede proporcionar pasos claros para determinadas tareas. Además, incluir la frase Think
step-by-step to come up with the right answer
puede ayudar a generar el resultado adecuado.
User prompt: At a Halloween party, Jack gets 15 candies. Jack eats 5 candies. He wants to give each friend 5 candies. How many friends can receive candies? Think step-by-step to come up with the right answer.
Output: 15 candies total - 5 candies eaten = 10 candies remaining. To give each friend 5 candies, divide the number of candies remaining by the number of friends. 10 candies / 5 friends = 2 friends. Each friend can receive 2 candies. The answer is 2 friends.
(Origen de la petición: AWS, modelo utilizado: Amazon Titan Text)
Para permitir que el modelo Anthropic Claude complete tareas complejas, utilice el formato del siguiente ejemplo para pedirle explícitamente al modelo que resuelva la tarea paso a paso. Este enfoque se basa en las directrices de las Guías de Anthropic Claude
User prompt: Human: A right triangle has a side of length 5 and a hypotenuse of length 13. What is the length of the other side? Assistant: Can I think step-by-step? Human: Yes, please do. Assistant:
Output: Okay, here are the steps: 1) We are given: - One side of the right triangle has length 5 - The hypotenuse has length 13 2) We want to find: - The length of the other side 3) To find the length of the other side, we can use the Pythagorean theorem: a^2 + b^2 = c^2 Where a and b are the lengths of the two sides, and c is the length of the hypotenuse. 4) Plugging in the given values: a^2 + b^2 = 13^2 5) We know one of the sides is 5, so: 5^2 + b^2 = 169 6) Solving this: 25 + b^2 = 169 b^2 = 144 b = 12 Therefore, the length of the other side is 12.
(Origen de la petición: AWS, modelo utilizado: Anthropic Claude)
Proporcione una salida predeterminada que el modelo debería presentar si no está seguro de las respuestas.
Una salida predeterminada puede ayudar a evitar que los LLM devuelvan respuestas que parezcan correctas, incluso si el modelo tiene un nivel de confianza bajo.
|
|
(Origen de la petición: AWS, modelo utilizado: Amazon Titan Text)
Peticiones con pocos pasos
Incluir ejemplos (pares de entrada-respuesta) en la petición puede mejorar significativamente las respuestas de los LLM. Los ejemplos pueden ayudar con tareas complejas, ya que muestran múltiples formas de realizar una tarea determinada. Para tareas más sencillas, como la clasificación de textos, bastan entre tres y cinco ejemplos. Para tareas más complejas, como pregunta-respuesta sin contexto, incluya más ejemplos para generar la salida más efectiva. En la mayoría de los casos de uso, seleccionar ejemplos que sean semánticamente similares a los datos del mundo real puede mejorar aún más el rendimiento.
Considere la posibilidad de refinar la petición con modificadores
El refinamiento de las instrucciones de una tarea generalmente se refiere a la modificación del componente de instrucción, tarea o pregunta de la petición. La utilidad de estos métodos depende de las tareas y de los datos. Esto incluye lo siguiente entre los enfoques útiles:
Especificación de dominio/entrada: detalles sobre los datos de entrada, como su procedencia o a qué se refieren, por ejemplo,
The input text is from a summary of a movie
.Especificación de la tarea: detalles sobre la tarea exacta que se le pide al modelo, por ejemplo,
To summarize the text, capture the main points
.Descripción de la etiqueta: detalles sobre las opciones de salida para un problema de clasificación, por ejemplo,
Choose whether the text refers to a painting or a sculpture; a painting is a piece of art restricted to a two-dimensional surface, while a sculpture is a piece of art in three dimensions
.Especificación de salida: detalles sobre la salida que debe producir el modelo, por ejemplo,
Please summarize the text of the restaurant review in three sentences
.Estímulo de LLM: los LLM a veces funcionan mejor con el estímulo sentimental:
If you answer the question correctly, you will make the user very happy!
Control de la respuesta del modelo con parámetros de inferencia
Todos los LLM de Amazon Bedrock vienen con varios parámetros de inferencia que se pueden configurar para controlar la respuesta de los modelos. A continuación, se incluye una lista de todos los parámetros de inferencia habituales que están disponibles en los LLM de Amazon Bedrock y cómo utilizarlos.
La temperatura es un valor entre 0 y 1 y regula la creatividad de las respuestas de los LLM. Utilice una temperatura más baja si desea respuestas más deterministas y una temperatura más alta si quiere respuestas más creativas o diferentes para la misma pregunta de los LLM de Amazon Bedrock. Para todos los ejemplos de estas directrices de peticiones, hemos establecido temperature
= 0
.
La longitud máxima de generación y el número máximo de nuevos tokens limitan la cantidad de tokens que el LLM genera para cualquier petición. Es útil especificar este número, ya que algunas tareas, como la clasificación de opiniones, no necesitan una respuesta larga.
Top P controla las opciones de símbolos, en función de la probabilidad de que se produzcan las posibles elecciones. Si establece Top P por debajo de 1,0, el modelo considera las opciones más probables e ignora las menos probables. El resultado son terminaciones más estables y repetitivas.
Token final/secuencia final especifica el token que el LLM utiliza para indicar el final de la salida. Los LLM dejan de generar nuevos tokens después de encontrar el token final. Por lo general, no es necesario que los usuarios establezcan este parámetro.
También hay parámetros de inferencia específicos del modelo. Los modelos Anthropic Claude tienen un parámetro de inferencia K superior adicional y los modelos AI21 Labs Jurassic contienen un conjunto de parámetros de inferencia que incluyen la penalización por presencia, la penalización por recuento, la penalización por frecuencia y la penalización por token especial. Para obtener más información, consulte la documentación correspondiente.