hh.ru explicó cómo diseñar prompts de producción para servicios de AI sin sorpresas

hh.ru compartió una práctica sobre cómo escribir prompts para sus servicios de IA en producción. La idea principal es simple: un prompt en un producto no es una conversación con un chatbot, sino un sistema de ingeniería con restricciones, pruebas y ajustes constantes.

Producción no es Chat

En el uso típico de LLM, todo es bastante flexible: un usuario hace una pregunta, obtiene una respuesta, refina la formulación, reinicia el diálogo y sigue adelante. En un producto, no hay ese lujo. Aquí, una respuesta fallida puede llegar a miles de usuarios, romper un escenario, crear un riesgo reputacional o simplemente empeorar la conversión.

Por lo tanto, un prompt en producción no es una frase única como "hazlo bonito", sino un conjunto de instrucciones interconectadas, datos, reglas y llamadas de herramientas, a veces abarcando cientos de líneas. El autor del artículo lo llama la batalla de un ingeniero contra un "loro estocástico". El modelo no entiende el significado de la manera que lo hacen los humanos; predice el siguiente token basándose en probabilidades.

La tarea del equipo es maximizar la reducción del espacio de aleatoriedad: dar al modelo un papel claro, contexto, restricciones y formato de respuesta esperado. Cuanto mejor esté diseñado este bucle, mayor es la probabilidad de obtener un resultado predecible, seguro y útil para el negocio real. Por eso trabajar con prompts cada vez más se parece al desarrollo regular, en lugar de a un experimento creativo.

El Marco de un Buen Prompt

En hh.ru, recomiendan escribir las instrucciones en inglés, mientras que dejan ejemplos de mensajes de usuarios en el idioma del producto —en este caso, ruso. La razón no es solo que las instrucciones en inglés sean interpretadas con más precisión por el modelo. El inglés también ahorra tokens, y en sistemas con miles y millones de llamadas, esto ya afecta el costo y la latencia. Las plantillas y el marcado ayudan adicionalmente: markdown o XML hacen que las instrucciones largas sean más estructuradas y reducen la ambigüedad. Un marco típico generalmente incluye el papel del modelo, objetivo, contexto, pasos de resolución de problemas y formato de respuesta.

• papel del modelo
• objetivo y tarea específica
• contexto de los datos de entrada
• algoritmo de acción o pasos de verificación
• restricciones y formato de respuesta

Los ejemplos few-shot son particularmente peligrosos. Realmente ayudan al modelo a entender mejor la tarea, pero con la misma facilidad se convierten en una plantilla que comienza a transferir mecánicamente a nuevas situaciones. El modelo a menudo se apega a las formulaciones literalmente y las reproduce fuera de contexto. El artículo proporciona un caso ilustrativo: agregaron un ejemplo de pregunta aclaratoria para un candidato al prompt del sistema, después de lo cual el agente comenzó a hacerla incluso donde era completamente inapropiado.

"¿Estás listo para viajes de negocios a Riazán?"

Después de eso, el asistente periódicamente preguntaba sobre viajes incluso en ofertas de trabajo donde los viajes no eran necesarios.

La conclusión del equipo es severa: todo lo riesgoso debe ser explícitamente prohibido. Si un bot no debe discutir otras compañías, expresar su opinión, salirse del tema o realizar tareas no relacionadas, esto debe estar explícitamente establecido. Otro consejo práctico es no temer a los prompts largos si están montados lógicamente y no se contradicen. También es importante pasar explícitamente la fecha actual, ajustar cuidadosamente la temperatura y recordar que los prompts casi siempre necesitan ser reescritos para diferentes modelos.

Cómo Lo Prueban

Incluso un buen prompt no se puede considerar listo después de un par de ejecuciones exitosas. El comportamiento de LLM no es completamente determinista: con solicitudes idénticas y parámetros idénticos, las respuestas aún pueden variar ligeramente. Por lo tanto, la garantía de calidad es más como una evaluación de ingeniería de un sistema que como una revisión manual de texto. Necesitas grandes conjuntos de casos de prueba, múltiples ejecuciones y cobertura de diferentes escenarios de usuario —casi como en las pruebas clásicas, pero con ajustes por la naturaleza probabilística del modelo.

La fuente más valiosa de nuevas pruebas son los registros reales de usuarios. Es ahí donde surgen preguntas inesperadas, intentos de desviar el bot y casos extremos que el equipo no anticipó. Conforme se acumulan estos casos, el conjunto de datos de evaluación necesita ser constantemente reabastecido. Otro hallazgo importante: los prompts deben probarse en un entorno lo más cerca posible de producción. Los LLM son sensibles incluso a cambios menores en el formato de entrada, por lo que un entorno "casi idéntico" fácilmente da una falsa sensación de estabilidad.

Lo Que Esto Significa

El artículo de hh.ru demuestra bien que la ingeniería de prompts se está transformando rápidamente en ingeniería de productos regular. Aquí, la victoria no va al pedido más creativo, sino a una combinación de estructura, restricciones, evaluaciones, registros y refinamiento iterativo. Para equipos que construyen características de IA en producción, esta es una señal: los prompts ahora necesitan ser versionados, probados, rastreados por métricas, vinculados a escenarios reales de usuarios y adaptados a modelos específicos tan seriamente como el código.