El siguiente framework de prompt lo preparé con ayuda del modelo “o3-mini” para evaluar el objetivo por el cual ha sido concebido: Rápido en razonamiento avanzado. Sólo para adelantarte, a la fecha en la que generé este contenido, la versión del modelo no permite adjuntarle un pdf para analizarlo como lo hacen otros modelos.
Elaboré una instrucción sin condicionamientos previos, o sea, no le formulé ninguna estructura previa de las que tengo para ser aplicadas a determinadas situaciones, como por ejemplo el enfoque TAG que en una publicación anterior lo he explicado. Podrás consultar artículos anteriores donde hago mención de algunos de estos enfoques.
En fin, para este ensayo me ocupé básicamente en pensar una instrucción que permitiera evaluar la rapidez y capacidad del modelo «o3-mini» en razonamiento avanzado, mediante la generación de un esquema (framework) de prompt genérico que transforme un requerimiento de negocio en una Historia de Usuario clara, definiendo su alcance y criterios de aceptación.
La idea principal es poder contar con un resultado que le pueda ser de utilidad a un Product Owner, por lo tanto el esquema debería tener ciertas propiedades para que sea flexible y capaz de adaptarse a todo tipo de situaciones que un Product Owner debiera enfrentar.
Objetivo y Contexto
Objetivo principal:
Generar un esquema (framework) de prompt genérico que transforme un requerimiento de negocio en una historia de usuario clara, definiendo su alcance y criterios de aceptación correspondientes..
Contexto:
- Se debe interpretar el requerimiento de negocio, entendiendo su propósito, el dominio específico y las necesidades del cliente.
- La salida deberá estar en español, incluso si el requerimiento original se encuentra en inglés.
- El prompt debe incluir roles definidos, por ejemplo: experto en software testing y experto en prompt engineering, para garantizar una interpretación técnica y rigurosa.
Punto de reflexión: Es necesario aquí que te comparta un idea que lo vengo haciendo en mis artículos anteriores y lo seguiré haciendo. Para lograr un framework de prompt que sea realmente efectivo y eficaz, se debe tener conocimiento y experiencia en el campo a ser tratado. ¿Qué significa ésto? Si por ejemplo se debe tratar una situación específica de un requerimiento que el equipo estuviera recibiendo, es recomendable saber cómo tratarlo bajo el punto de vista de un Product Owner, bajo la metodología y/o técnica más apropiada, y estos aspectos son los que se debieran incluir dentro de la estructura del framework cuando sea más oportuno en la interacción que hagamos con la IAGen (Inteligencia Artificial Generativa). Por lo tanto, por más que tengamos un framework enfocado a resolver una situación particular, es necesario contar con el conocimiento que lo complemente, ya que de esa forma se podrán obtener los resultados que el equipo de proyecto necesita.
Estructura del Framework de Prompt
La estructura del framework debe contener varios módulos, cada uno de ellos orientado a guiar al modelo en diferentes fases del proceso. A continuación, describo los módulos clave:
Módulo de Contextualización e Instrucción Inicial
Este módulo establece el escenario y define el rol que debe asumir el modelo. Recomiendo que incluyas los siguientes elementos:
- Introducción: Describir brevemente el requerimiento de negocio que se ha recibido.
- Contexto: Describir los detalles relevantes (dominio, características específicas, público objetivo).
- Rol: Indicarle al modelo que debe actuar bajo un rol (o función) particular como un experto Product Owner, ó Scrum Master, o en software testing y experto en prompt engineering para cada caso como para complementar las indicaciones y que el prompt sea más efectivo.
- Objetivo del prompt: Transformar el requerimiento en una Historia de Usuario que permita identificar claramente el alcance y los criterios de aceptación correspondientes.
Ejemplo de prompt inicial:
«Imagina que eres un experto en software testing y prompt engineering. Se te presenta el siguiente requerimiento de negocio (en inglés o español) para el desarrollo de una nueva funcionalidad en una plataforma [nombre del dominio]. Tu tarea es generar una Historia de Usuario completa que permita a los equipos de testers y developers comprender el requerimiento del negocio.
La Historia de Usuario debe incluir:
- Descripción: Describir un resumen claro del requerimiento.
- Alcance: Definir de manera precisa lo que se debe incluir y excluir.
- Criterios de aceptación: Listar las condiciones que deben cumplirse para considerar la funcionalidad como completa.
Si encuentras ambigüedades o faltan detalles, realiza preguntas específicas para aclararlas antes de generar la historia.
Requerimiento: <Insertar requerimiento del negocio aquí>
Asegúrate de entregar la salida en español, adaptándola al dominio especificado y utilizando un lenguaje formal.»
Punto para reflexionar: Aquí recomiendo incluir alguna de las prácticas específicas que tiene cada uno de los roles mencionados para darle mayor robustez al prompt y por ende al resultado a generar. En cada uno de estos puntos se debe tener una muy buena comunicación con el responsable del área de negocio y del área técnica para lograr que el framework de prompt contenga toda la información y datos necesarios que nos permita obtener el resultado esperado y que las interacciones posteriores se den conforme a lo esperado. Este aspecto es sumamente importante para evitar retrabajo.
Módulo de Desglose y Parámetros Personalizables
Este módulo permite parametrizar el prompt según diferentes necesidades y escenarios, haciendo el framework modular y flexible. Incluye:
- Variables de entrada:
- <requerimiento>: Incluir el texto original del requerimiento de negocio.
- <dominio>: Registrar el dominio al que pertenece el requerimiento (por ejemplo, e-commerce, salud, educación, etc.).
- <nivel_de_detalle>: Definir el indicador que permita ajustar la complejidad del desglose (bajo, medio, alto).
- <preguntas_para_clarificar>: Espacio para que el modelo solicite información adicional si es necesario.
- Instrucciones para manejo de errores:
- Si la información es insuficiente o ambigua, el modelo deberá preguntar: «¿Podrías proporcionar más detalles sobre [elemento específico]?».
- En caso de respuestas inesperadas, se debe reiniciar el prompt con la instrucción: «Revisa los detalles y genera nuevamente la Historia de Usuario, asegurándote de incluir todos los elementos solicitados.»
Ejemplo de prompt modular:
«Utilizando los siguientes parámetros:
- Requerimiento: <requerimiento>
- Dominio: <dominio>
- Nivel de detalle: <nivel_de_detalle>
Actúa como un experto en software testing y prompt engineering y genera una Historia de Usuario que contenga:
- Descripción General: Resumen del requerimiento.
- Alcance: Detalle de lo que se incluye y se excluye en la funcionalidad.
- Criterios de Aceptación: Lista de condiciones que validan la implementación.
Si encuentras aspectos poco claros, pregunta: «¿Podrías clarificar [elemento ambiguo]?»
Asegúrate de que la salida sea en español, manteniendo un tono formal y ajustado al dominio indicado.»
Módulo de Ejemplos y Retroalimentación Iterativa
Para facilitar la mejora continua, la recomendación es incluir ejemplos prácticos de entradas y salidas esperadas, no importa que no estén estructuradas, se lo aclara. Lo importante es darle al modelo un parámetro para que pueda entender por dónde debe ir además de permitir iteraciones según el feedback.Es más, en caso de no estar estructuradas ni las entradas ni las salidas, se lo menciona también. Esto se puede estructurar de la siguiente forma:
- Ejemplo de requerimiento:
- Requerimiento: «El usuario debe poder filtrar productos por precio y categoría en un e-commerce.»
- Ejemplo de Historia de Usuario generada:
Historia de Usuario:
«Como usuario de la plataforma de e-commerce, quiero filtrar productos por precio y categoría, para poder encontrar rápidamente aquellos productos que se ajusten a mi presupuesto y necesidades.
Alcance:
- Se incluirán filtros para precio (rango mínimo y máximo) y categoría.
- Se excluirán filtros para características adicionales (como color o marca) en esta versión.
Criterios de Aceptación:
- El sistema debe permitir seleccionar un rango de precios.
- El sistema debe mostrar únicamente productos que pertenezcan a la categoría seleccionada.
- La funcionalidad debe responder en menos de 2 segundos.»
- Retroalimentación iterativa:
Después de obtener la respuesta, se debe solicitar:
«Revisa la Historia de Usuario generada. Si detectas ambigüedades o falta algún criterio, por favor, realiza las preguntas necesarias para clarificar y luego ajusta la historia en consecuencia.»
Consideraciones Adicionales
Manejo de Errores y Respuestas Inesperadas
- Detección de errores:
El modelo debe analizar la salida y, si no se han cumplido todos los parámetros (descripción, alcance y criterios de aceptación), deberá emitir una alerta y pedir confirmación:
«La salida no incluye todos los elementos requeridos. ¿Deseas que formule preguntas adicionales para clarificar el requerimiento?» - Retroalimentación en tiempo real:
Se recomienda un ciclo iterativo en el que, tras la primera respuesta, el usuario pueda ajustar parámetros o hacer preguntas adicionales para optimizar la Historia de Usuario.
Punto para reflexionar: Este último punto es super importante, es decir, no quedarse con la primera devolución o entrega que nos ofrezca el modelo. Es muy importante analizar el resultado e identificar puntos a mejorar, hasta incluso se le puede solicitar al modelo que los identifique y que recomiende acciones y así de esa forma, uno mismo con un criterio humano, evaluar que opción elegir y volver a solicitarle una nueva entrega, una nueva versión con las mejoras incluidas.
Flexibilidad y Adaptabilidad
- El framework está pensado para que sea totalmente modular, por lo que podrás añadir o quitar secciones según las necesidades del requerimiento del negocio.
- Permitirá la integración de nuevas variables o instrucciones específicas (por ejemplo, inclusión de métricas de rendimiento o instrucciones de seguridad informática) conforme se identifiquen nuevas necesidades durante la prueba del modelo «o3-mini».
Resumen del Framework
La estructura principal del framework comprende:
- Introducción y Contexto:
- Definir objetivo, contexto y rol (experto en software testing y prompt engineering).
- Presentar el requerimiento original.
- Desglose Modular:
- Parámetros personalizables: requerimiento, dominio, nivel de detalle, etc.
- Instrucciones para manejo de errores: solicitar aclaraciones cuando sea necesario.
- Ejemplos y Retroalimentación:
- Proveer ejemplos prácticos de entrada y salida.
- Incluir un ciclo iterativo de feedback para ajustar la salida.
- Consideraciones de Seguridad y Automatización:
- Incluir directrices de seguridad informática y recomendaciones para la automatización de pruebas.
Este framework te permitirá evaluar no solo la rapidez en razonamiento avanzado del modelo «o3-mini», sino también su capacidad para adaptarse a distintos escenarios de negocio y entregar resultados coherentes y de alta calidad.
Fuente de la imagen: OpenAI
