Cómo formular un prompt para resolución de problemas

Dar instrucciones a una IA (prompting) para la resolución de problemas es, en realidad, una tarea de instrucción trabajo. Art Smalley y Tyson Heaton muestran cómo el pensamiento lean optimiza las preguntas que se le hacen al modelo.

El ciclo PDCA, conocido por todos los expertos en Lean, también se aplica al trabajo con un modelo de lenguaje extenso (LLM), pero sustituyendo la P de Plan por P de Prompt. El modelo se encarga de la ejecución. La verificación y la acción dependen principalmente del usuario. Nuestro artículo anterior («Indicar, Ejecutar, Verificar, Actuar») abordó este ciclo a un nivel superior; hoy profundizamos en la parte más importante: la indicación inicial y la conversación con el modelo para obtener los mejores resultados. Utilizaremos la resolución de problemas como ejemplo, ya que es un tema con el que cualquiera puede identificarse.

Pregunta: ¿Cómo se formula el prompt para la resolución de problemas?

Al igual que en el pensamiento Lean, un prompt tiene partes que aportan valor y otras que generan desperdicio. Curiosamente, lo que funcionaba bien hace un año puede que no funcione igual de bien hoy. En este artículo, analizaremos las partes básicas de una indicación, citando la documentación de Anthropic sobre buenas prácticas,¹ utilizando como ejemplo la resolución básica de problemas. Le animamos a trabajar con un LMM mientras lee.

Un prompt genérico

Escriba esto en cualquier modelo:

Actúa como un asesor para la resolución de problemas y ayúdame a analizar un problema.

Es una solicitud razonable. Conversa con el modelo y revisa la respuesta.

Los resultados variarán, y hace dos años variaban mucho. Una respuesta podría sugerir pensamiento de diseño. Otra, Six Sigma. Otra, 8D. Otra plantea el problema matemáticamente. A veces, el modelo crea su propio método y lo presenta con total seguridad. Esto depende en gran medida del modelo específico, el esfuerzo de razonamiento y la configuración personalizada que le hayas dado para la memoria. Sin embargo, si ejecutas el mismo prompt mañana, obtendrás una respuesta ligeramente diferente a la de hoy. Los modelos no son deterministas y las respuestas variarán.

Observa, sin embargo, que nada en ese prompt le indicó al modelo qué método exacto usar. En otras palabras, no le proporcionamos al modelo la capacitación adecuada en instrucciones de trabajo ni un trabajo estandarizado. Hay miles de ejemplos de asesoramiento para la resolución de problemas en los datos de entrenamiento del modelo, y los solicitamos todos a la vez. Así que calculó el promedio. Y tiene que adivinar cuál es el que se desea.

Aquí es donde muchos se inclinaron inicialmente a descartar por completo los modelos LLM. Introdujeron algo genérico, leyeron el resultado y concluyeron que las herramientas eran inútiles. Tenían razón en cuanto al resultado. Se equivocaron en cuanto a la causa. Incluso los modelos de hace dos años producían resultados mucho mejores cuando se les proporcionaban las indicaciones o instrucciones adecuadas. El factor limitante no era el modelo, sino lo que cada vez se denomina más el «harness». Piense en esto como los prompt, las herramientas, los datos, los scripts y otros dispositivos a los que el modelo puede acceder. Un modelo promedio con un buen harness puede superar a un modelo excelente con un harness deficiente.

Nos centraremos en la parte más básica del harness, conocida como prompt. Sencillamente, los prompts genéricos producen respuestas decepcionantes. En la metodología Lean, esto es lo mismo que un trabajo estandarizado genérico que produce una gran variación en los resultados del operario. Cuanto más se deja a la interpretación, ya sea por parte del modelo o de la persona, menos específico es el resultado.

Anthropic publica su propia guía sobre cómo usar las indicaciones, y vale la pena leerla directamente,² donde se enumeran cinco principios generales:

• Sea claro y directo. Piense en el modelo como un empleado brillante pero nuevo que desconoce sus normas y flujos de trabajo. Cuanto más precisamente explique lo que quiere, mejor será el resultado.
• Añada contexto para mejorar el rendimiento. Explique la motivación detrás de la instrucción, no solo la instrucción en sí. El modelo generaliza a partir de la explicación.
• Utilice ejemplos de forma eficaz. De tres a cinco ejemplos bien elegidos guían el resultado de forma más fiable que una simple descripción.
• Estructure el prompt. Separe las instrucciones, el contexto, los ejemplos y la información para que el modelo no los confunda.
• Asigne un rol al modelo. Una sola frase que defina al personaje cambia el comportamiento y el tono.

La regla de oro es una buena forma de comprobar su propio trabajo: muestre su indicación a un compañero con poco conocimiento de la tarea y pídale que la siga. Si él se confunde, el modelo también lo hará.

No analizaremos cada principio en detalle. En cambio, crearemos una pregunta sencilla para la resolución de problemas y dejaremos que los principios se manifiesten a medida que aumentemos su complejidad.

Especificar claramente el método

El primer cambio fundamental que haremos en nuestra pregunta inicial, sencilla y directa, es indicarle al modelo que asuma una personalidad y que especifique qué método de resolución de problemas utilizar.

Supongamos que usted es un coach experto en el método de ocho pasos de Toyota Business Practice. Ayúdeme a resolver un problema.

Incluso hace entre 18 meses y dos años, en modelos más antiguos y menos avanzados, esto producía una respuesta de coaching notablemente mejorada. Hoy en día, en modelos de vanguardia como Claude Opus 4.8, Claude Fable 5 o ChatGPT-5.6 Sol, funciona aún mejor. Con este sutil cambio en la pregunta, el modelo ahora se ciñe a un solo método en lugar de promediar entre varios. Seguirá mejor una secuencia definida, utilizará el vocabulario de ese método y formulará preguntas más relevantes para el mismo.

Aquí utilizamos las Prácticas Empresariales de Toyota como ejemplo específico, pero obviamente no es un requisito. Utilice el método que realmente practica: 8D, Six Sigma, Kepner-Tregoe, Design Thinking. Utilice el método estandarizado por su organización y el que mejor se adapte al tipo de problema al que se enfrenta. Al modelo no le importa qué método elija; simplemente se adapta mejor al método que usted especifique claramente.

Este cambio, que solo requiere una frase, merece la pena implementarlo antes que nada.

Especifique los pasos y los puntos clave.

A continuación, profundizaremos en la consigna y seremos aún más específicos. Esto es similar al consejo de Anthropic de añadir contexto y ejemplos para que el modelo comprenda su objetivo. Mencionar el método le permite entrar en el terreno correcto, pero no le garantiza un buen mentor. Los modelos de vanguardia más recientes conocen los ocho pasos de la Práctica Empresarial de Toyota solo de nombre:

1. Clarificar el problema
2. Desglosar el problema
3. Establecer un objetivo
4. Analizar la causa raíz
5. Desarrollar contramedidas
6. Implementar las contramedidas
7. Evaluar tanto los resultados como el proceso
8. Estandarizar los procesos exitosos

Casi cualquier modelo puede recitar estos pasos. Sin embargo, el conocimiento que importa reside en su interior. ¿Qué implica realmente "clarificar el problema" antes de poder avanzar? ¿Qué diferencia hay entre desglosar un problema y simplemente reformularlo? Estos puntos clave son los que utiliza un verdadero coach, y son los que el modelo a menudo desconoce a menos que se los proporciones con mayor claridad.

Por lo tanto, para tu ejercicio de resolución de problemas, escribe los pasos y los puntos clave, y añade más detalles contextuales. Ten en cuenta que esto es similar a redactar una hoja de desglose de instrucciones de trabajo, y lleva aproximadamente el mismo tiempo hacerlo bien. Pasos importantes, puntos clave, razones.

Luego, añade el resto de tu situación:

• Su sector y su puesto. El coaching que necesita un ingeniero de mantenimiento no es el mismo que necesita un gerente de planta.
• El tipo de coaching que busca. Directivo, guiado y neutral, o basado únicamente en preguntas. Estos tres tipos de coaching dan lugar a sesiones realmente diferentes, y la mayoría de las personas nunca se han planteado que pueden elegir.
• Cualquier otro aspecto relevante para la situación.
• Qué evitar. Por ejemplo, no proponga la capacitación como contramedida y céntrese en las relaciones de causa y efecto que se pueden verificar.

Haga clic aquí para ver un ejemplo de una pregunta más completa sobre la resolución de problemas.

Nota: Deberá indicarle al modelo que siga esta pregunta. Copiar y pegar funciona bien. Si simplemente arrastra y suelta la pregunta, el modelo a menudo la considera material de referencia o opcional.

Vale la pena detenerse en el último punto. Puede indicarle al modelo en qué debe centrarse o ser claro sobre el tipo de respuesta que desea evitar. Por ejemplo, no proponga la capacitación como la causa raíz ni como la contramedida. Ni exija una forma específica de análisis. Explicaremos por qué más adelante en el artículo.

Da un paso y formula el prompt correctamente.

En este punto, es normal que el instinto te lleve a ampliar la instrucción hasta que todo el método se especifique en un documento extenso de ocho páginas, por ejemplo.

Este patrón detallado suele funcionar muy bien. Sin embargo, a veces hay una mejor manera. Desafortunadamente, varía según la situación. Para experimentar y aprender, intenta ahora extraer un solo paso del método y formular esa instrucción específica por separado.

El análisis de la causa raíz es un buen punto de partida. Un modelo al que simplemente se le pide que "encuentre la causa raíz" con la metodología de resolución de problemas de Toyota recurrirá casi siempre a los 5 porqués, ya que es lo que se encuentra en la mayor parte de internet. Pero esta puede o no ser la herramienta adecuada para tu problema. Por lo tanto, por ejemplo, podrías especificar algo como esto en el cuerpo de la instrucción:

• ¿Qué tipo de análisis se ajusta a este problema? 5 porqués. Diagrama de Ishikawa. Diagrama de dispersión. Diseño de experimentos. La elección depende del problema y es tuya, no del modelo.
• Asegúrese de que se esté abordando la causa raíz, en lugar del punto de detección.
• ¿Qué se observó en el gemba y quién lo observó?
• ¿Con quién se ha hablado? Operarios. Mantenimiento. Ingeniería. Proveedores. Todo el personal involucrado.
• ¿Qué datos se recopilarán y de qué tipo?
• Causas raíz similares conocidas en su sector. Es posible que el modelo tenga más información sobre estas causas que nosotros.
• Medidas de seguridad. Más información a continuación.

Haga clic aquí para ver un ejemplo de solicitud completa para el análisis de la causa raíz.

Nota: Deberá indicarle al modelo que siga esta solicitud. Copiar y pegar funciona bien. Si simplemente arrastra y suelta la solicitud, el modelo a menudo la considera material de referencia o opcional.

Aunque este prompt tiene varios párrafos, no ocupa ocho páginas. Y a menudo te será más útil en ese paso específico que la versión de ocho páginas, ya que todo su contenido se centra en el paso en el que estás trabajando. La resolución de problemas avanza paso a paso, por lo que, en la mayoría de los casos, la guía de un modelo también debe seguir ese mismo enfoque. Los modelos a veces se comportan como personas. No generes confusión accidentalmente al incluir "compartir buenas prácticas" cuando en realidad necesitamos centrarnos en "analizar la causa raíz".

Puedes hacer lo mismo con "aclarar el problema" o cualquier otro paso. Una indicación muy específica suele ser más útil que una que intenta abarcar todo el método a la vez. Por supuesto, todo depende de tu situación y de la etapa del proceso en la que te encuentres. Al principio, las indicaciones genéricas orientadas al descubrimiento pueden funcionar mejor. A medida que avanzas, las indicaciones específicas y detalladas probablemente sean más efectivas. No existe una solución única para todos los casos.

Qué omitir.

Lo que perjudica un prompt no es el detalle, sino el material irrelevante. Los investigadores añadieron una sola frase irrelevante a problemas matemáticos que los modelos ya habían resuelto correctamente, y la precisión disminuyó drásticamente.³ El desperdicio en una instrucción se comporta como desperdicio en cualquier otro lugar. No agrega valor. La propia guía de Anthropic dice prácticamente lo mismo, pero en sentido contrario, indicando a los usuarios que eliminen las instrucciones excesivas y que dejen de transcribir manualmente el procedimiento del modelo, ya que el razonamiento del modelo suele exceder lo que una persona prescribiría.⁴

Por lo tanto, la regla no es escribir menos, sino escribir con claridad. Elimine las contradicciones, las instrucciones obsoletas de un modelo anterior y todo lo que no tenga relación con el paso en el que se encuentra. Conserve los detalles que son útiles.

Medidas de seguridad.

La sección de "qué evitar" merece un nombre propio. Son medidas de seguridad, y son la parte de la instrucción que la mayoría de las personas no abordan adecuadamente.

Un modelo le proporcionará la causa raíz. Lo hará con seguridad, a petición, sin datos. Incluso propondrá una contramedida (por ejemplo, trabajo estandarizado) antes de que el problema real esté claro. Las líneas de protección son los límites que lo detienen:

• Analiza solo los datos que te proporciono.
• No inventes números.
• No indiques la causa raíz. Pídeme lo que no tienes.
• No culpes al operario.
• Explica el probable mecanismo de causa y efecto.

La mayoría de las personas que escriben una instrucción piensan en lo que quieren que haga el modelo. Las líneas de protección también se refieren a lo que debe rechazar y al razonamiento que deseas en lugar del atajo. A veces, ahí reside el verdadero valor de tu instrucción.

Hay un límite a lo que se puede lograr al escribir las mismas instrucciones cada mañana. En algún momento, querrás que el método esté instalado en lugar de tener que escribirlo de nuevo, para que todos los miembros de tu equipo utilicen siempre las mismas instrucciones. Esto se denomina "archivo de habilidades" y será el tema de un artículo futuro.

Ejemplo de resolución de problemas de Viwinco

Tyson Heaton del LEI y Andrew Buczewski de Viwinco trabajaron juntos en una versión real de esto. Durante el proceso de laminación, se formaba una burbuja de aire entre dos paneles de vidrio, un problema recurrente que llevaba tiempo sin resolverse. Lo que sucedió después no ocurrió de la noche a la mañana. Un intercambio con el modelo desencadenó una serie de acontecimientos que se desarrollaron con el tiempo.

El primer paso no fue exigir una respuesta, sino añadir contexto y reformular la pregunta. En lugar de preguntar "¿cómo soluciono las burbujas?", le indicaron al modelo qué máquina y proceso se estaban utilizando, describieron lo que no entendían y le pidieron que explicara la química subyacente como si se lo explicara a alguien con conocimientos básicos de química. Es decir, "añadir contexto" y "darle un rol al modelo" aplicados simultáneamente.

La respuesta no resolvió el problema, y ​​ese es precisamente el objetivo. Generó conciencia en dos frentes. Primero, expuso suposiciones sobre la máquina y el proceso que el equipo desconocía. El modelo explicó la química, señaló que el proceso era inusual en comparación con el estándar de la industria y descartó la variabilidad entre operarios. La respuesta humana instintiva había sido estudiar el trabajo estandarizado del operario. La química era el punto clave para la interacción, y sin ese intercambio el equipo se habría estancado por más tiempo. En segundo lugar, les mostró el potencial del modelo. Existía conocimiento relevante del sector que nunca habían aprovechado.

Esa segunda toma de conciencia fue lo que les permitió seguir adelante. Activaron el modo de investigación y le pidieron al modelo que rastreara la literatura académica e industrial sobre esta química del vidrio específica y relativamente nueva. El modelo trabajó durante aproximadamente una hora. Filtraron los informes y los cargaron en un proyecto como base de conocimiento compartida. A partir de ahí, iteraron con el proyecto como un segundo mentor. Realizaron experimentos, construyeron un contexto compartido más amplio y mantuvieron las intervenciones que mejoraron el resultado. El resultado fue un mejor control del proceso y la incorporación de controles de calidad en los puntos clave del proceso y de la máquina. El problema de los desperdicios disminuyó significativamente. Quizás lo más valioso fue cuánto aprendió el equipo durante el proceso.

Un solo caso no demuestra una regla, y no afirmamos que el modelo sea mejor mentor que la persona. El modelo tampoco conocía la respuesta. Lo que hizo el intercambio fue plantear la pregunta correcta, visibilizar las suposiciones del equipo y señalar el conocimiento que ya existía. Las mejoras llegaron más tarde, a partir de los propios experimentos del equipo, y solo mediante pruebas y verificaciones.

Dónde practicar

Si desea practicar por su cuenta, el laboratorio autodirigido de nuestro último artículo sigue disponible en https://aiworkshop.tech.lean.org/, alojado en el portal LeanTech del LEI. Los participantes del taller lo probaron juntos para observar algunas de las diferencias que explicamos aquí. Con la práctica, lo comprenderá rápidamente. Se requiere iniciar sesión por motivos de seguridad básicos, recibirá un código de seis dígitos por correo electrónico y el LEI no recopila datos. Revise su carpeta de correo no deseado si no lo recibe. También ofrecemos estos talleres en vivo. Si su organización desea esta experiencia de aprendizaje rápido, póngase en contacto con Tyson Heaton, Director Ejecutivo de Lean Tech/IA de LEI.

Resumen

En el pensamiento Lean y la resolución de problemas, los pasos iniciales siempre parecen sencillos, pero en el fondo son engañosamente complejos. Proponer un modelo para la resolución de problemas, el coaching o la programación es muy similar. La analogía de la formación dentro de la instrucción laboral en la industria resulta muy útil.

Indique el método que utiliza. Describe los pasos y los puntos clave de cada uno, y explica claramente los motivos, del mismo modo que detallarías las instrucciones de un puesto de trabajo. Añade tu sector, tu rol y el tipo de coaching que deseas. Indica también lo que el modelo no debe hacer. Luego, da un paso y profundiza en los detalles. El análisis de la causa raíz es un buen ejemplo para experimentar cuando llegues a esa etapa. Describe ese paso por separado, con detalle, incluyendo los hechos, los datos y el proceso que requiere el análisis.

Y, como en la metodología Lean, elimina todo lo que no sea útil ni aporte valor. A veces, menos es más. Tendrás que experimentar y aprender sobre la marcha.

El modelo no debe sustituir tu propio razonamiento. No delegues tu comprensión de un problema o sus causas. Pero puedes usarlo para ayudarte a pensar y obtener mejores resultados más rápidamente.

Humanos + IA > Problemas.

¹ “Prompting best practices”, Anthropic.
² Ibíd.
³ Shi et al., «Large Language Models Can Be Easily Distracted by Irrelevant Context», ICML 2023.
⁴ «Prompting best practices», Anthropic.

Tyson Heaton. Director Sénior de Co-Learning y Estrategia Empresarial y Coach Sénior del Lean Enterprise Institute

Art Smalley. Veterano de Toyota y asesor del Lean Enterprise Institute

Extraído de: The Lean Post