El problema de la ambigüedad
Ya sabemos qué función cumple un prompt: convertir una necesidad profesional en una instrucción para una tarea. El problema aparece cuando esa instrucción contiene menos información que la necesaria para determinar qué trabajo concreto esperaba realmente el usuario.
Consideremos otra vez:
Revisa este contrato.La frase parece clara porque un ser humano entiende las palabras. Sin embargo, desde el punto de vista de la tarea quedan abiertas numerosas decisiones. ¿Revisar significa resumir, detectar riesgos, corregir redacción, comparar con un modelo o evaluar cumplimiento? ¿Desde la posición de quién? ¿Qué partes del contrato importan más? ¿Qué estándar debemos aplicar? ¿Qué evidencia debe mostrar la respuesta? ¿Qué debe ocurrir si falta un anexo?
Para producir una salida, el sistema no puede dejar todas esas preguntas suspendidas. De algún modo debe completar el encargo.
Un prompt no necesita describir absolutamente todo.
Pero cuando deja abierta una decisión que puede cambiar materialmente el resultado, el sistema tendrá que resolverla usando el contexto disponible y los patrones que condicionan su generación.
La buena práctica consiste en no obligar al sistema a adivinar aquello que el usuario ya sabe que importa.
Ambigüedad no significa solamente “palabra poco clara”
En lenguaje ordinario solemos hablar de ambigüedad cuando una palabra admite varios significados. Aquí utilizaremos el término en un sentido más amplio: existe ambigüedad práctica cuando más de una ejecución razonable de la tarea es compatible con la instrucción.
Por ejemplo:
Analiza la cláusula de responsabilidad.La expresión “cláusula de responsabilidad” puede estar perfectamente identificada. Sin embargo, el encargo sigue siendo subespecificado.
Un abogado podría:
- describir qué dice la cláusula;
- calcular el alcance del cap;
- revisar carve-outs;
- contrastarla con una política interna;
- evaluar desde la posición del cliente;
- evaluar desde la posición del proveedor;
- formular una propuesta de negociación.
Todas esas tareas son compatibles con la palabra “analiza”. El problema no está en que el castellano sea incomprensible. Está en que la especificación profesional es insuficiente.
Qué debe inferir el modelo
Cuando el prompt no fija una decisión, el sistema debe continuar a partir de lo que tiene disponible. Puede apoyarse, entre otros elementos, en:
- la formulación concreta del mensaje;
- mensajes anteriores de la conversación;
- instrucciones adicionales incorporadas por la aplicación;
- documentos o fragmentos presentes en el contexto;
- patrones aprendidos durante el entrenamiento;
- ejemplos incluidos en el propio prompt.
Para un lector principiante puede resultar útil decir que el modelo “rellena los huecos”. Técnicamente no debemos imaginar a una persona interior que detecta conscientemente lagunas y decide cómo resolverlas. La idea importante es funcional: la salida incorpora decisiones que quizá nunca fueron escritas explícitamente por el usuario.
Si escribimos:
Prepara un informe sobre esta sentencia.alguna estructura tendrá que aparecer. Algún nivel de detalle será seleccionado. Algunos hechos se considerarán centrales y otros secundarios. Algún criterio de relevancia orientará la síntesis. Nada de eso desaparece porque el prompt no lo mencione.
La prueba de las dos respuestas razonables
Existe una prueba mental sencilla para detectar subespecificación.
Pregúntate:
¿Dos profesionales competentes podrían leer esta instrucción y ejecutar tareas significativamente distintas sin que ninguno estuviera desobedeciendo?
Si la respuesta es sí, existe una decisión abierta que conviene examinar.
Por ejemplo:
Dime si esta cláusula es aceptable.Dos abogados pueden discrepar legítimamente porque “aceptable” podría significar:
- jurídicamente válida;
- conforme al modelo interno;
- dentro de una posición de mercado;
- comercialmente tolerable;
- aprobable sin escalamiento;
- negociable, aunque desfavorable.
Antes de pedir al modelo que clasifique algo como “aceptable”, debemos saber qué regla convierte la palabra en un criterio operativo.
No todas las inferencias tienen el mismo costo
Sería imposible y contraproducente explicitar cada detalle imaginable.
Supongamos:
Resume esta sentencia en cinco párrafos para un abogado que no conoce el caso.No especificar si cada párrafo debe contener exactamente cuatro oraciones probablemente no importa.
En cambio, no indicar si la respuesta debe distinguir la decisión del tribunal de las alegaciones de las partes puede ser material.
Conviene entonces distinguir entre dos tipos de decisiones implícitas.
Inferencias de bajo costo: pueden variar sin alterar significativamente la utilidad de la respuesta.
Inferencias de alto costo: pueden cambiar el objeto, la perspectiva, el estándar, la evidencia, la conclusión o el uso posterior.
La ingeniería de prompts no consiste en eliminar las primeras. Consiste en identificar las segundas.
Cinco zonas donde suele esconderse la ambigüedad
Aunque la página siguiente desarrollará una anatomía más completa, aquí es útil reconocer cinco zonas recurrentes.
1. Ambigüedad sobre la operación
Revisa la política.¿Debemos resumir, corregir, comparar, verificar o evaluar?
Una mejora mínima sería:
Extrae todas las obligaciones que la política impone a proveedores externos.2. Ambigüedad sobre la perspectiva
Identifica cláusulas problemáticas.¿Problemáticas para quién?
Identifica cláusulas que generen exposición para el cliente.3. Ambigüedad sobre el estándar
Clasifica los riesgos.¿Según qué criterio?
Clasifica los riesgos según su impacto operativo y la dificultad de mitigarlos antes de la firma.4. Ambigüedad sobre la evidencia
Explica qué obligaciones tiene el proveedor.¿Puede responder desde conocimiento general o debe usar exclusivamente el contrato?
Identifica obligaciones expresamente establecidas en el contrato. Para cada una indica la cláusula que la sustenta.5. Ambigüedad sobre la salida
Dame el resultado.¿Una síntesis, una tabla, una lista de prioridades o una minuta extensa?
Devuelve una tabla de hallazgos y una síntesis ejecutiva de máximo cinco puntos.Estas cinco zonas no agotan el problema, pero ayudan a reconocer por qué una frase aparentemente comprensible puede seguir siendo una especificación profesional débil.
Qué conviene explicitar
La regla no es “mientras más, mejor”. La regla es hacer explícita la información que cambia la tarea.
Antes de enviar un prompt importante podemos formular una serie de preguntas:
¿Qué debe hacer exactamente?
¿Sobre qué debe trabajar?
¿Para qué necesito la respuesta?
¿Desde qué posición debe analizar?
¿Qué información contextual cambia la evaluación?
¿Qué documentos son fuente?
¿Qué debe contar como evidencia?
¿Qué criterio debe aplicar?
¿Qué límites no debe cruzar?
¿Cómo necesito recibir la salida?No todas requieren una respuesta extensa. A veces basta una línea.
Por ejemplo:
Perspectiva: cliente.puede resolver una ambigüedad que alteraría todo el análisis.
Objeto, alcance y contexto: tres cosas distintas
Una fuente frecuente de confusión aparece cuando se mezclan estas tres dimensiones.
Objeto: aquello sobre lo cual se realiza la tarea.
“el contrato de servicios”.
Alcance: qué parte o dimensión del objeto debe examinarse.
“únicamente terminación, datos y responsabilidad”.
Contexto: hechos externos que ayudan a comprender por qué esas cuestiones importan.
“el servicio será crítico y no existe un proveedor alternativo disponible”.
Comparemos:
Analiza el contrato.con:
Analiza el contrato de servicios únicamente respecto de terminación, portabilidad de datos y continuidad.
Contexto: el servicio será crítico para operaciones diarias y el cliente necesita poder migrar a otro proveedor en caso de término.La segunda versión no sólo contiene más palabras. Separa tres decisiones diferentes.
Documentos: adjuntar no equivale a explicar
Una interfaz puede permitir adjuntar varios archivos. Eso no significa que el sistema sepa qué función cumple cada uno.
Supongamos que adjuntamos:
- contrato principal;
- propuesta comercial;
- política interna;
- anexo de seguridad.
Sin instrucciones adicionales, existe el riesgo de que sean tratados como si tuvieran el mismo rol.
Los materiales del curso proponen una solución sencilla: asignar función a cada documento.
Archivos:
1. contrato_principal.pdf
Documento contractual que debe revisarse.
2. anexo_seguridad.pdf
Anexo vinculante. Úsalo para revisar obligaciones de seguridad.
3. propuesta_comercial.pdf
Úsala sólo para detectar diferencias entre lo ofrecido y lo contratado.
4. politica_interna.pdf
Estándar interno de la organización. No la trates como norma jurídica ni como parte del contrato.Esta pequeña descripción evita una forma de ambigüedad especialmente delicada en trabajo jurídico: confundir procedencia con contenido.
Contexto no es evidencia
Supongamos que el usuario escribe:
Contexto: el cliente cree que el proveedor utilizará sus datos para entrenar modelos.y luego pregunta:
Analiza el tratamiento de datos.El hecho de que esa preocupación esté presente en el prompt no significa que el contrato contenga una autorización de entrenamiento.
Por eso puede ser útil indicar:
Trata la afirmación del cliente como contexto del caso, no como hecho acreditado por el contrato.
Distingue:
1. texto contractual;
2. contexto entregado por el usuario;
3. inferencias.Esta separación es crucial porque el lenguaje fluido puede ocultar cambios de estatus epistémico. Una frase puede comenzar como hipótesis del cliente y terminar redactada como si fuera una obligación contractual confirmada.
Qué conviene dejar flexible
Un buen prompt no intenta controlar decisiones irrelevantes.
Supongamos:
Identifica las cinco cláusulas de mayor impacto práctico para el cliente.La cifra cinco puede ser funcional si queremos preparar una síntesis ejecutiva.
Pero:
Identifica exactamente siete riesgos aunque existan menos o más.puede obligar al sistema a rellenar una cuota artificial.
Lo mismo ocurre con restricciones estilísticas excesivas:
Cada explicación debe tener exactamente 43 palabras.Puede controlar forma sin mejorar sustancia.
Conviene distinguir:
restricción funcional: protege una propiedad importante de la tarea;
restricción ornamental: aumenta rigidez sin un beneficio claro.
Ejemplo funcional:
Si no puedes localizar el fundamento documental, no presentes el hallazgo como confirmado.Ejemplo ornamental:
Usa exactamente dos adjetivos en cada hallazgo.Especificar trabajo, no buscar palabras mágicas
El prompting se vuelve confuso cuando se enseña como un repertorio de fórmulas secretas.
Es común encontrar instrucciones como:
Actúa como un experto mundial.Piensa profundamente.Haz tu máximo esfuerzo.Sé absolutamente preciso.Estas expresiones pueden influir en el estilo o en ciertos comportamientos, pero no reemplazan una especificación incompleta.
Comparemos:
Actúa como el mejor abogado tecnológico del mundo y revisa exhaustivamente este contrato.con:
Identifica todas las cláusulas que permitan al proveedor:
1. modificar unilateralmente el servicio;
2. cambiar tarifas;
3. suspender prestaciones;
4. cambiar subprocesadores.
Para cada una indica:
- cláusula;
- facultad concedida;
- condición para ejercerla;
- aviso requerido;
- remedio del cliente.
No analices otras materias.El segundo prompt define una operación, un universo de búsqueda y una estructura de respuesta. Su calidad no depende de una palabra secreta.
Phoenix y Taylor sintetizan una filosofía semejante mediante cinco principios: dar dirección, especificar formato, proporcionar ejemplos cuando sea necesario, evaluar calidad y dividir trabajo. Berryman y Ziegler, con otra arquitectura conceptual, enfatizan clarificar la pregunta, seleccionar contenido y ensamblar el prompt de manera deliberada. Las taxonomías no son idénticas, pero ambas apuntan a una idea más robusta que “usar frases mágicas”: hacer explícita la estructura de la tarea.
El peligro opuesto: sobreespecificar
Reducir ambigüedad puede producir un exceso de instrucciones.
Un prompt sobrecargado puede contener:
- reglas duplicadas;
- criterios que compiten entre sí;
- excepciones escondidas;
- prioridades incompatibles;
- formatos imposibles de satisfacer simultáneamente.
Por ejemplo:
Sé exhaustivo, pero responde en máximo 100 palabras.
Identifica todos los riesgos, pero incluye únicamente tres.
No hagas inferencias, pero concluye si el contrato es aceptable.El problema ya no es falta de especificación, sino conflicto entre especificaciones.
Por eso la calidad requiere un equilibrio:
muy poco control ←────────→ demasiadas reglas
↑
especificación útilLa meta no es escribir el prompt más largo. Es escribir el prompt que contiene las decisiones necesarias y no más complejidad de la que la tarea justifica.
Una técnica práctica: convertir expectativas en preguntas
Antes de redactar un prompt complejo, puede ser útil imaginar qué preguntaría un colega humano competente antes de empezar.
Si le entregamos una carpeta y decimos:
“Hazme la revisión.”
probablemente preguntará:
“¿A quién representamos?”
“¿Para qué decisión es?”
“¿Qué versión del contrato es la principal?”
“¿Qué temas preocupan?”
“¿Existe un modelo interno?”
“¿Quieres diagnóstico o propuesta de redacción?”
“¿Qué consideramos material?”
Esas preguntas hacen visible conocimiento que el usuario posee pero no había expresado.
En prompting, explicitar ese conocimiento evita que la aplicación tenga que completar decisiones de alto costo con señales mucho más débiles.
La ambigüedad y la evaluación posterior
Existe otro beneficio de especificar mejor: permite evaluar el cumplimiento.
Prompt vago:
Prioriza bien los riesgos.Después es difícil decidir qué significa “bien”.
Prompt observable:
Prioriza cada hallazgo según:
- impacto económico;
- impacto operativo;
- probabilidad de materialización;
- dificultad de mitigación.Ahora podemos examinar si la priorización se apoya realmente en esos criterios.
El prompt no sólo dirige. También crea una base para revisar la respuesta.
Caso conductor: de “aprobar” a “preparar la decisión”
Volvamos al contrato del proveedor de IA.
Prompt inicial:
Revisa el contrato y dime si podemos aprobarlo.La palabra “aprobar” concentra varias decisiones ocultas. ¿Quién tiene autoridad para aprobar? ¿Qué criterios debe cumplir el contrato? ¿Existe una política de excepciones? ¿Una desviación bloquea o sólo exige escalamiento?
Una reformulación más segura podría ser:
Prepara un diagnóstico previo a la decisión de aprobación.
No adoptes la decisión final.
Identifica los puntos que requieren:
- aclaración;
- negociación;
- información adicional;
- eventual escalamiento.
Analiza desde la posición del cliente.
Usa el contrato y sus anexos como evidencia contractual. Si una conclusión depende de información que no aparece en ellos, márcala como información faltante.Aquí hemos retirado varias decisiones de la zona implícita y, además, hemos separado capacidad analítica de autoridad decisoria.
Esa separación reaparecerá mucho más adelante cuando estudiemos herramientas, workflows y agentes.
Qué debes recordar
El problema de la ambigüedad no consiste simplemente en que los modelos “no entiendan” palabras vagas. Consiste en que una tarea profesional contiene muchas decisiones y un prompt puede expresar sólo una parte de ellas.
Lo que falta no desaparece: la generación tendrá que tomar alguna forma compatible con el contexto disponible.
Por eso conviene explicitar especialmente aquello que puede cambiar materialmente:
- operación;
- objeto y alcance;
- finalidad;
- perspectiva;
- procedencia de la información;
- criterio;
- evidencia;
- límites;
- salida.
La regla editorial de esta sección puede condensarse así:
No expliques todo. Explica lo que no quieres dejar al azar de una inferencia innecesaria.
El problema que todavía queda abierto
Ya sabemos detectar que una instrucción está subespecificada. Todavía necesitamos un método más estable para construirla.
¿Qué piezas deberíamos revisar? ¿Cómo distinguimos tarea de objetivo? ¿Perspectiva de audiencia? ¿Contexto de documentos? ¿Evidencia de criterios? ¿Restricciones de formato?
El siguiente nodo introduce una anatomía de un prompt sólido: diez componentes que sirven como mapa de diseño, no como formulario obligatorio.