9. Prompt engineering

1 · QUÉ ES — PARA PROFANOS

El prompt es las instrucciones que le das al becario. Y "prompt engineering" es el oficio de

escribirlas bien: qué contexto darle, qué ejemplos, qué formato de salida, qué límites.

La metáfora del encargo: si le pides al becario "escríbeme algo sobre el cliente", te trae

cualquier cosa. Si le dices "resume en cinco líneas, en tono formal, citando el número de contrato,

sin opiniones, y si falta algún dato escribe FALTA y el nombre del dato", te trae trabajo hecho.

La diferencia entre las dos es prompt engineering.

Lo que un buen prompt lleva, siempre:

1. Rol — quién es el modelo en esta conversación ("eres el asistente de normativa interna…").

2. Contexto — lo que necesita saber para no inventar (los documentos del RAG van aquí).

3. Formato — cómo debe ser la salida (lista, tabla, JSON, máximo de líneas).

4. Límites — qué no debe hacer, y qué hacer cuando no sabe.

Y el matiz que separa a un senior de un aficionado: el prompt es la capa más frágil del

sistema. Un control que solo vive en el prompt es un control que el modelo puede ignorar, que un

cambio de redacción puede romper, y que no deja rastro. El prompt sirve para guiar; los controles

viven en otra parte (documento 08). Quien dice "con un buen prompt lo arreglo" es quien todavía no

ha visto un modelo ignorar una instrucción en producción.

Las técnicas del repertorio estándar:, Técnica, Qué es, Para qué,, Few-shot, meter 2-3 ejemplos de pregunta-respuesta, fijar el estilo y el formato,, Chain-of-thought, pedir "piensa paso a paso", razonamiento en varias etapas,, ReAct, pensar → actuar → observar, agentes con herramientas,, System prompt, el marco fijo que no cambia entre turnos, rol, reglas, tono,, Structured outputs, forzar salida JSON con esquema, integración fiable con código,, RAG, meter los documentos en el prompt, conocimiento corporativo, La práctica seria, que es la que importa en una empresa: el prompt se trata como código —

se versiona, se revisa, se evalúa contra ejemplos antes de desplegar, y se monitoriza en

producción. Herramientas del sector: prompt registries (LangSmith, Azure AI Foundry), evaluación

automática de variantes (pruebas A/B de prompts) y observabilidad de cada llamada.

Y la frontera honesta del oficio: prompt engineering no es magia ni es prompt-fu. Es

ingeniería de contexto: elegir qué información llega al modelo y en qué orden, y medir si la

respuesta mejora. Quien lo vende como trucos ("¡estos 10 prompts mágicos!") no lo ha operado en

producción.

- Context engineering: el término que el sector adoptó en 2025 para decir que el trabajo ya no

es "la frase mágica", sino diseñar qué contexto recibe el modelo: recuperación, resúmenes,

orden de la información, memoria. El prompt es el final del proceso, no el principio.

- Prompts optimizados por máquinas (DSPy y similares): en vez de escribir prompts a mano, un

optimizador los genera y los evalúa automáticamente contra un conjunto de ejemplos. La parte

aburrida del oficio se está automatizando; la que queda es saber qué evaluar.

- Modelos que razonan sin que se lo pidas: los razonadores (o-series, R1) hacen chain-of-thought

interno. Algunas técnicas de prompt pierden peso con ellos — y ganan otras: darles criterio,

no pasos.

- Prompts como activo de gobierno: en entornos regulados, el prompt versionado empieza a ser

parte de la documentación exigible. Quien tiene prompts sin versionar tiene, a efectos de

auditoría, decisiones sin registro. Es la dirección de nuestro documento 08.

El prompt no se escribe a mano: se genera por parámetros. En Zalo, el prompt de sistema se

arma por secciones según el tema de la conversación, y el estilo se controla con un vector

numérico de 7 dimensiones:

Por qué es prompt engineering industrial y no artesanía: cuando el tono o la longitud cambian,

no se reescribe el prompt — se cambia un número, y el generador recompone el texto. El prompt

queda parametrizado, reproducible y versionable — exactamente lo que la industria llama "prompt

as code". Y al ser generado, cada cambio se puede registrar.

Las tres reglas de casa sobre prompts:

1. El prompt guía; el control vive fuera. Si una regla importa de verdad, va al esquema de

datos o al validador — no al prompt. Un prompt se puede ignorar; un esquema no.

2. La cita manda sobre la prosa. El prompt obliga a citar el identificador del documento, y si

la respuesta no está en el contexto recuperado, el modelo tiene que decirlo. El estilo se

sacrifica antes que la procedencia.

3. El prompt se evalúa, no se confía. Las variantes de prompt pasan por la misma batería que los

modelos: una prueba solo entra en producción si el ancla de referencia la pasa completa. Un

prompt que no se ha medido contra ejemplos es una opinión con formato de instrucción.

Y la lección que resume el oficio, aprendida en producción: en los sistemas con varios agentes,

cada agente tiene su prompt por separado, con su contrato — el coordinador no habla como el

analista. El estilo no es decoración: es parte del contrato del agente, igual que sus

herramientas y sus permisos.

> "Desarrollar estrategias de prompt engineering y optimización de prompts." · "Prompt

> Engineering" (conocimientos requeridos).

"¿Cómo optimizas un prompt?"

> "Midiendo, no opinando. Primero fijo qué respuesta quiero y qué fallo quiero corregir; luego

> hago la variante y la paso por la batería de evaluación contra ejemplos; si mejora la métrica

> entra, si no, se descarta. La regla de casa es que un prompt no se cambia por sensación — se

> cambia por resultado medido. Y si el fallo persiste después de tres variantes, el problema no es

> el prompt: es la recuperación o el dato."

"¿Cómo versionas los prompts?"

> "Como código: el prompt se genera por parámetros, así que versionar es versionar esos

> parámetros. Un cambio de tono es un cambio de un número, registrable y reversible. Y como

> cualquier despliegue, la variante nueva pasa la puerta de evaluación antes de llegar a

> producción."

"¿Cuál es tu truco favorito de prompt engineering?"

> "Ninguno — y esa es mi respuesta. Los trucos son para demos. Lo que funciona en producción son

> tres cosas: contexto correcto delante (que es el RAG bien hecho), formato de salida forzado, y la

> orden de decir 'no lo sé' cuando la respuesta no está en el contexto. Eso último, en un banco,

> vale más que cualquier plantilla de 'eres un experto en…'."

"¿Dónde pones los límites: en el prompt o en el sistema?"

> "En el sistema siempre que el límite importe. El prompt es la guía; los controles viven en el

> esquema de datos y en los validadores. Si una prohibición solo está en el prompt, es una

> recomendación con apariencia de regla. Y en gobierno, esa diferencia es la que un auditor

> detecta en cinco minutos."