- Tutorial de ingeniería de prompts ofrecido por Anthropic que guía de forma interactiva y paso a paso sobre cómo redactar prompts optimizados para los modelos Claude
- Los usuarios pueden practicar y aprender directamente la estructura de un buen prompt, los casos de fallo y técnicas eficaces de mejora
- Cada capítulo incluye ejemplos prácticos y explicaciones, lo que ofrece una experiencia cercana al uso real
- Está compuesto por 9 capítulos y un apéndice, desde nivel básico hasta avanzado, para desarrollar habilidades de redacción de prompts y resolución de problemas
- Este tutorial también ofrece una versión para Google Sheets, lo que mejora su accesibilidad y utilidad
Tutorial interactivo de ingeniería de prompts de Anthropic
- Recurso de aprendizaje de código abierto que ofrece conocimientos sobre diseño de prompts optimizados para el modelo de IA Claude
- Aunque es similar al flujo de aprendizaje de chatbots basados en OpenAI, destaca frente a otros tutoriales por su enfoque en las fortalezas y limitaciones específicas del modelo Claude, así como por su orientación a la práctica real y su alta aplicabilidad en el trabajo
- En especial, permite redactar prompts y experimentar con los resultados al mismo tiempo, lo que brinda una gran ventaja para ingenieros principiantes
Introducción y objetivos del curso
- Este tutorial guía paso a paso sobre cómo diseñar y utilizar prompts óptimos dentro de Claude
- Al completar el curso, el usuario podrá adquirir lo siguiente
- Comprensión de la estructura de prompts efectivos
- Identificación de patrones de fallo comunes y métodos prioritarios de mejora (regla 80/20)
- Comprensión de las fortalezas y debilidades del modelo Claude
- Capacidad para construir prompts aplicables a múltiples tareas comunes
Estructura y contenido del curso
- Está compuesto por 9 capítulos (de básico a avanzado) y un apéndice de profundización
- Cada capítulo ofrece tanto explicación teórica como práctica directa
- Al final de cada parte, hay un espacio en el "Example Playground" donde se puede ingresar prompts directamente y experimentar los cambios en las respuestas
- Todos los ejemplos incluyen una clave de explicación
- El modelo base del tutorial es Claude 3 Haiku, el más ligero, rápido y económico. Cuando es necesario, también se menciona Sonnet y Opus, de mayor capacidad
- También puede utilizarse en una versión extendida de Google Sheets, lo que facilita el acceso al aprendizaje
Índice del currículo
- Básico
- Chapter 1: Estructura básica de prompts
- Chapter 2: Cómo redactar instrucciones claras y directas
- Chapter 3: Asignación de roles
- Intermedio
- Chapter 4: Separar datos e instrucciones
- Chapter 5: Especificar el formato de salida y convertirlo en conversación para Claude
- Chapter 6: Pensamiento previo (hacer emerger el razonamiento paso a paso)
- Chapter 7: Cómo usar ejemplos
- Avanzado
- Chapter 8: Prevención de alucinaciones (Hallucination)
- Chapter 9: Construcción de prompts complejos (casos por industria)
- Ej.: chatbot, servicios legales, servicios financieros, programación y otros problemas de aplicación práctica según distintas tareas
- Apéndice
- Métodos más allá de los prompts estándar
- Técnicas avanzadas como prompt chaining, uso de herramientas, búsqueda/integración de resultados de búsqueda, etc.
Guía de uso
- Se recomienda avanzar por el tutorial en orden, capítulo por capítulo
- Gracias a los ejercicios centrados en la práctica y a las explicaciones paso a paso, incluso un ingeniero principiante puede desarrollar de forma natural una capacidad de diseño de prompts útil para situaciones reales
- Todos los nombres de productos y modelos se mantienen como en el original, por lo que pueden utilizarse de inmediato también en entornos de trabajo basados en inglés
Características adicionales e información de código abierto
- En GitHub registra más de 19,400 Stars y 1,900 Forks
- El lenguaje principal de desarrollo es Jupyter Notebook, e incluye también algo de código Python
- No hay un paquete de distribución separado; todo el material está disponible como código abierto y puede consultarse libremente
1 comentarios
Opiniones en Hacker News
Me molesta mucho que se use la palabra "engineering" en este contexto; no creo que se pueda considerar ingeniería de verdad. La ingeniería consiste en diseñar y construir de forma predecible con base en conocimientos acumulados durante muchos años, leyes físicas, reglas, etc.; lo que se hace aquí no es más que probar a ciegas hasta que salga algún resultado.
Creo que cualquier palabra puede tener varios significados. En "prompt engineering", "engineering" tiene un matiz parecido pero distinto, como en "social engineering". Por ejemplo, la definición 2 de engineering según Google es algo como "maniobrar para lograr un objetivo". Si ves la tercera definición en Merriam-Webster o revisas Collins Dictionary o YourDictionary, queda claro que también existe un sentido no técnico como “manipulación ingeniosa” o “hacer planes con astucia”. Es un significado secundario ya establecido de la palabra.
Yo como cereal mientras reviso las especificaciones de la caja de cereal. Lo hago todas las mañanas. También aplico mis habilidades de ingeniería para subirme al autobús, porque me gano la vida con el prompt engineering. Últimamente siento que demasiadas palabras están perdiendo su significado original, así que al menos me consuela saber que no soy el único al que eso le irrita.
Sigo prefiriendo el enfoque de Canadá, donde para usar el título de ingeniero hay que tener licencia del organismo regulador profesional de cada provincia. En Estados Unidos me parece excesivo que llamen ingeniero a todo desarrollador de software, mecánico, instalador de HVAC o plomero.
Creo que esta misma discusión en realidad también podría aplicarse exactamente igual al trabajo que hacen muchos "engineering teams". Hay una suposición implícita de que si lo hace un ingeniero, entonces eso ya es ingeniería, y más al fondo también hay una gran suposición sobre si el software en sí merece llamarse software engineering.
Creo que la palabra "Engineering" es un recurso retórico para dar la impresión de que no se trata simplemente de escribir frases. Si dijeran "prompt writing", honestamente podría sonar como algo menor, y para la gente que ya detesta el término "soft skill" eso sería aún más incómodo.
Se siente como el episodio de hoy de "alquimia para principiantes". Me recordó a un caso en que la velocidad de un algoritmo aumentó 30% en un benchmark set cuando se usó una random seed de 7. Ni 8 ni 6, sino 7.
Al leer este artículo, lo más importante que me llevé fue pensar en cómo ordenar la salida. Por ejemplo, pedir que primero extraiga evidencia o indicadores antes de responder. Ya sabía que un LLM es un autocompletado probabilístico, pero no había pensado en este tipo de priming.
Puede que esto no aplique a los modelos de reasoning. Los modelos de reasoning recorren un proceso de pensamiento en la forma deseada antes de dar una respuesta, así que el orden de la salida influye menos en la precisión. Quizá por eso OpenAI quiere forzar el reasoning.
Yo normalmente le pido que primero saque citas cortas de fuentes encontradas en línea, cuando aplica. Eso ayuda a compensar un poco la confiabilidad de la información. Recientemente fue algo muy necesario mientras implementábamos Cloudflare Zero Trust en nuestra organización.
En cambio, si primero le pides la respuesta y luego que dé el sustento, el modelo entra en un "modo de tonterías" en el que lanza una respuesta arbitraria y luego la racionaliza para que suene convincente. Mucho mejor hacer que primero enumere objetivamente pros y contras y luego saque una conclusión; así responde con mucho más cuidado.
Creo que estaría bien poner "(2024)" en el título de esta publicación.
En problemas difíciles, el mejor tip de prompt engineering que se me ocurre es "abrir y luego cerrar". Más específicamente: primero presentar con claridad el problema y el contexto, luego hacer que la IA analice y busque todas las opciones y enfoques posibles para abrir al máximo el espacio de información; después listar las ventajas y desventajas de cada método, y finalmente hacer que elija la solución más adecuada. Si el problema es fácil, puedes saltarte todo eso y preguntar directamente, y aun así obtendrás una respuesta. Pero en problemas difíciles, si pides la respuesta de inmediato, simplemente se la inventa de forma convincente, así que hay que empezar necesariamente desde fundamentos realistas. Por eso hace falta un flujo de contexto específico -> análisis de opciones -> pros y contras -> elección final.
Opinión de que se agregue 2024 al título.
Siento que estamos aprendiendo a enseñarle a la IA el trabajo que hacíamos nosotros mismos, y luego a indicarle de forma eficaz que vuelva a hacer ese trabajo. Si esta tecnología no queda sostenida por toda la economía de Estados Unidos, podría elevarse como un globo de aire caliente y luego desplomarse de golpe.
Igual que otros comentarios, esto no me parece ingeniería en el sentido ortodoxo. Pero sí creo que Anthropic ha hecho investigaciones bastante buenas en interpretabilidad de modelos. Si esa herramienta llegara a publicarse como API pública, quizá podría crearse un ciclo de retroalimentación para comparar diferencias en el estado interno del modelo según el prompt y hacer un ajuste mucho más sistemático.
Este tutorial fue escrito para tres modelos (Sonnet, Haiku y Opus 3). Algunas lecciones siguen siendo aplicables hoy, pero hay partes que no importan tanto para modelos RL más inteligentes (como Sonnet 4.5). Como referencia, Claude 3 Haiku es el modelo más pequeño, rápido y barato; Sonnet y Opus son más inteligentes, y Opus es el mejor de los tres.