Markdex IA · Referencia técnica
Este apartado funciona como el anexo técnico del manual: reúne las definiciones que se usan en el resto de las guías, las tablas de valores con los que se configuran los sistemas y las plantillas que se copian directamente en la herramienta. Si en algún momento un término le resulta ambiguo, conviene resolver la duda aquí antes de tocar un flujo en producción.
Cada entrada está redactada con el mismo criterio: qué es, para qué sirve y qué consecuencia tiene si se configura mal. Observe que no incluimos definiciones comerciales; solo parámetros verificables y su efecto operativo.
Sección 01
Antes de automatizar conviene fijar el vocabulario. La razón es práctica: la mayoría de los errores de configuración no provienen de la herramienta, sino de interpretar un término de forma distinta a como lo interpreta el motor que ejecuta el flujo. Cuando un equipo define «token», «contexto» y «agente» de manera uniforme, las pruebas se reducen y las discusiones sobre resultados desaparecen. Por consiguiente, este glosario se ordena de lo general a lo específico y se complementa con los fundamentos que se explican en Fundamentos de automatización con IA.
Un término mal entendido obliga a repetir la prueba completa. Con definiciones cerradas se ajusta un solo parámetro y se aísla la causa del fallo en lugar de rehacer el flujo entero. En términos medibles, un equipo que documenta su vocabulario tarda aproximadamente la mitad en poner en marcha un proceso nuevo.
Cuando dos personas escriben «instrucción» y se refieren a cosas distintas, las revisiones se convierten en negociaciones. El glosario fija una única acepción por término y permite que las plantillas circulen sin traducciones intermedias entre áreas técnicas y de negocio.
Revisar un flujo ajeno exige saber qué hace cada bloque. Con un vocabulario compartido, la lectura del registro de ejecución se vuelve mecánica: se identifica el paso, su entrada y su salida sin interpretaciones. Esto es condición previa para cualquier control de calidad documentado.
Sección 02
Las siguientes tablas recogen los valores que se repiten en casi todos los proyectos. Use la primera para fijar parámetros iniciales y la segunda como guía de diagnóstico cuando un flujo ya está en marcha. Ambos cuadros se amplían con ejemplos en la guía práctica de ingeniería de prompts.
| Parámetro | Valor típico | Efecto | Riesgo si se ignora |
|---|---|---|---|
| Temperatura | 0,1 – 0,3 | Salida estable y repetible | Resultados distintos en cada ejecución |
| Máx. tokens de salida | 400 – 800 | Limita longitud y coste | Respuestas truncadas a mitad de frase |
| Reintentos por paso | 2 | Absorbe fallos de red puntuales | Ejecuciones duplicadas y envíos repetidos |
| Tiempo de espera | 30 s | Corta llamadas colgadas | Bloqueo de la cola de trabajo |
| Iteraciones de agente | ≤ 6 | Evita bucles improductivos | Consumo de tokens sin resultado |
| Síntoma | Causa probable | Corrección |
|---|---|---|
| La salida cambia de formato | Temperatura alta o formato no especificado | Fijar temperatura en 0,2 e indicar estructura exacta |
| El flujo se ejecuta dos veces | Disparador duplicado o ausencia de idempotencia | Añadir clave única y comprobación previa de estado |
| El agente repite la misma acción | Sin criterio de parada ni verificación | Limitar iteraciones a 6 y definir condición de éxito |
| El modelo ignora instrucciones antiguas | Ventana de contexto desbordada | Resumir el historial y mover reglas al inicio del prompt |
Sección 03
Una prueba bien hecha se limita a comprobar una hipótesis concreta. Si cambia tres cosas a la vez, no sabrá cuál produjo la mejora. Siga el orden siguiente y anote el resultado de cada paso antes de continuar con el siguiente.
Escriba el objetivo en términos de entrada y salida: «recibir un correo de reclamación y devolver un resumen de tres líneas con la categoría asignada». Si la frase necesita un «y» adicional, divida la tarea en dos.
Incluya al menos un caso límite: un texto vacío, un idioma distinto o un dato incompleto. Sin casos adversos la prueba mide el mejor escenario, que nunca es el habitual.
Orden recomendado: rol, tarea, datos de entrada, restricciones y formato de salida. Coloque las reglas críticas al principio; el modelo las respeta mejor cuando aparecen antes del contenido variable.
Fije 0,2 y repita la prueba dos veces por caso. Si los resultados difieren entre sí, el problema está en la especificación, no en el modelo. Documente la diferencia antes de cambiar el prompt.
Guarde el prompt aprobado con fecha y una nota de qué casos ha superado. Cualquier cambio posterior se prueba de nuevo con el mismo lote de cinco casos para comparar objetivamente.
⚠ Atención
No conecte una plantilla de prueba a una cuenta de correo o a un sistema de facturación real hasta haber validado los cinco casos. Un prompt sin límite de longitud puede generar mensajes incompletos enviados a clientes, y un reintento mal configurado duplica facturas. Use siempre un entorno de prueba con datos ficticios.
ROL: Analista de soporte.
TAREA: Clasificar el mensaje y resumirlo en tres líneas.
ENTRADA: {{texto_del_cliente}}
RESTRICCIONES:
- No inventar datos ausentes.
- Idioma de salida: español.
- Si falta información, responder "INCOMPLETO".
FORMATO: Categoría | Resumen | Prioridad (alta/media/baja)La línea de formato es la que más discusiones evita: obliga al sistema a devolver un resultado parseable por el siguiente paso del flujo. Encontrará variantes para clasificación, extracción y redacción en Flujos de trabajo automatizados.
Sección 04
El orden de lectura importa: cada capítulo asume lo explicado en el anterior. Empiece por los fundamentos, continúe por la escritura de instrucciones y termine por la integración de agentes y el diseño de flujos completos.
Capítulo 01
Qué se puede automatizar y qué no, cómo se mide el retorno de un proceso y qué requisitos previos necesita una pyme antes de conectar herramientas.
Leer capítuloCapítulo 02
Estructura de una instrucción, control de variables, evaluación de resultados y errores frecuentes que arruinan la reproducibilidad.
Leer capítuloCapítulo 03
Método para elegir el primer proceso, calcular horas ahorradas y mantener el sistema sin crear dependencias difíciles de auditar.
Leer capítuloSección 05
Con el vocabulario fijado y las tablas a mano, el paso siguiente es aplicar una plantilla a un proceso real de su organización y medir el resultado. Si duda por dónde empezar, vuelva al índice del manual y revise el criterio de selección de procesos.