La Ingeniería de Prompts con 3CX: Parte 1

Su Agente IA no necesita un manifiesto. Necesita unas especificaciones claras y concisas. A continuación le explicamos cómo redactarlas.

Hace poco reescribimos el prompt del sistema de nuestra Recepcionista IA. La versión anterior tenía 450 líneas, estaba muy bien estructurada y llena de políticas cuidadosamente elaboradas, ¡pero ocupaba tanto espacio en la ventana de contexto que el agente tenía menos margen para escuchar realmente a la persona que llamaba! Para ayudarle a evitar los mismos problemas, este blog – ahora la Parte 1 y más adelante la Parte 2 – le explica cómo dejar de escribir poesía y empezar a escribir instrucciones, ¡así que siga leyendo para saber más!

El Error que Todos Cometen al Inicio

No somos los únicos que cometemos este error. Casi todos los clientes de 3CX que editan un prompt del sistema por primera vez cometen el mismo error: tratan el prompt como si fuera un documento normativo, un contrato legal o, peor aún, un trabajo de redacción creativa.

Aquí está el problema: como los prompts están escritas en inglés, la gente se olvida de que está escribiendo código. Escriben párrafos enteros. Añaden adjetivos. Definen términos que el modelo ya entiende. Repiten la misma instrucción cinco veces porque les parece importante.

El modelo no lee la prosa como lo hacen los humanos. Cada palabra del prompt cuesta contexto, atención y, con frecuencia, coherencia. Un prompt largo no es sinónimo de un prompt más cuidadoso. Por lo general, es peor.

Esta guía contiene lo que hemos aprendido al reescribir la nuestra. Si está editando el prompt del sistema de un agente IA de 3CX, léala antes de guardar.

La Trampa del Inglés

Cuando la ingeniería del prompt significaba escribir para una API en JSON sin formato, la gente lo respetaba como una disciplina técnica. Ahora que las instrucciones están en inglés, la gente escribe como si estuviera enviando un mensaje de Slack a un nuevo empleado.

Eche un vistazo a este fragmento de la versión anterior de nuestro propio prompt:

“Es necesario conocer el motivo de la llamada antes de la transferencia, pero este no debe utilizarse para identificar, delimitar, clasificar, desambiguar, sustituir o anular el destino solicitado.”

Esa frase es gramaticalmente correcta, está bien pensada y es casi imposible que un modelo la repita de manera coherente a lo largo de una llamada real. Seis palabras casi sinónimas. Dos cláusulas. Una negación que envuelve una exigencia. Para el tercer turno de la conversación, el modelo ya la interpreta de manera diferente a como lo hizo en el primero.

Esto es lo que resultó:

“No utilice la búsqueda de información para decidir a quién debe llamar.”

Una sola oración. Una sola instrucción. Sin ambigüedades. El mismo comportamiento.

Regla número uno de la ingeniería del prompt: el inglés es la interfaz, no el género literario. Sigue escribiendo instrucciones. Breves, declarativas, comprobables. Si una frase suena como algo que encontraría en un documento de condiciones de servicio, elimínela y vuelva a intentarlo.

Deje de Definir Elementos en el Modelo

El antiguo prompt incluía esta joya:

“Un traspaso es cualquier paso siguiente permitido que se lleva a cabo mediante una de las acciones que se enumeran a continuación.”

El modelo sabe lo que es un traspaso. También sabe lo que significan “transferencia”, “buzón de voz” y “correo electrónico”. Definir términos cotidianos para el modelo es un hábito tomado de la redacción técnica dirigida a personas. En un prompt, eso solo gasta tokens y crea espacio para que el modelo malinterprete.

Lo mismo se aplica a los encabezados de sección ceremonial. El prompt anterior decía:

• Cumplimiento Obligatorio
• Orden de Prioridad
• Esquema Base
• Reglas de Selección de Acciones

Parecen sacados de un RFC. No aportan nada nuevo. El nuevo prompt utiliza encabezados como Estilo, Enrutamiento u Hostilidad – etiquetas breves que describen de qué trata la sección, no lo grave que suena.

Regla número dos: si una línea no cambia lo que hace el modelo, elimínela.

Dígalo Una Vez

Uno de los mayores problemas de los prompts largos es que la misma regla aparezca en cuatro lugares distintos. En nuestra versión anterior, la frase “no transferir si el destino es ambiguo” aparecía, con ligeras variaciones, en:

• Regla de Ambigüedad de Destino
• Portal de Acción de Traspaso
• Normas del Directorio
• Contrato de Entrega Confidencial

Cada reformulación era ligeramente diferente. Cada una utilizaba una redacción ligeramente distinta. Una persona que las lee ve cuatro versiones de la misma idea y comprende la intención. Un modelo que las lee ve cuatro reglas, y cuando estas no coinciden a la perfección, tiene que elegir. A veces, su elección es diferente en la tercera llamada del día que en la primera.

Regla número tres: cada regla debe aparecer en un solo lugar. Si se encuentra reforzando una regla al repetirla en una nueva sección, no necesita una nueva sección. Lo que necesita es una primera versión más clara.

Deje de Acumular Cosas que No Debe Hacer

Observe esto:

“No seleccione el primer resultado, el mejor resultado, el resultado disponible ni el resultado más relevante.”

Son cuatro instrucciones negativas cuando bastaría con una sola positiva. Lo que la regla realmente significa es:

“Si la búsqueda arroja varios resultados, pida aclaraciones al usuario.”

Las instrucciones positivas le indican al modelo qué debe hacer. Las instrucciones negativas le indican al modelo qué debe evitar, lo que deja abierta la pregunta de qué hacer en su lugar, y el modelo inventará una respuesta.

Regla número cuatro: es mejor utilizar instrucciones positivas. Utilice “no” solo cuando no haya un equivalente positivo.

Preste Atención a las Contradicciones

Este es el asesino silencioso.

El antiguo prompt contenía dos secciones que, leídas en conjunto, resultaban contradictorias:

• Enrutamiento por Razón: cuando la persona que llama indique un motivo, consulta la agenda para determinar el destino.
• Enrutamiento por Destino Solicitado: cuando la persona que llama pregunte por alguien o por un departamento, no utilice el motivo de la transferencia.

Ambas son ciertas. Ambas son razonables. Pero, al presentarse en un prompt largo con ejemplos que se superponen y subreglas que se refuerzan entre sí, el modelo se confunde sobre cuál se aplica, y esa confusión se manifiesta en un comportamiento inconsistente que el cliente nunca logra reproducir a voluntad.

Utilice OpenAI Tokenizer para ver cómo el modelo divide realmente su prompt en tokens. Luego, vuelva a leer el prompt como si no supiera nada sobre su negocio, en orden y sin contexto. Si dos reglas pudieran aplicarse de manera creíble a la misma situación y dar lugar a acciones diferentes, existe una contradicción, incluso si puede explicar por qué no entran en conflicto.

Regla número cinco: un prompt es coherente cuando no hay dos reglas que puedan aplicarse al mismo tiempo y contradecirse. No cuando se puede justificar la diferencia.

En los próximos días publicaremos la Segunda Parte de esta serie, en la que analizaremos más a fondo lo que el modelo puede y no puede hacer, daremos consejos para quienes se inician en la ingeniería de prompts y mucho más. ¡Estén atentos!

Comparta sus Comentarios

Únase a nuestro Foro para decirnos lo que piensa y no olvide seguirnos en X y LinkedIn para estar al tanto de las novedades y nuevas funciones.