AI ENGINEERING / PROMPTING E INGENIERÍA DE CONTEXTO
Prompting e ingeniería de contexto
Dirigir los modelos de forma confiable: system prompts, instructions, context windows, structured output, y prompt caching. El oficio que convierte un modelo capaz en un componente confiable.
Fundamento · 2
Nota de producción
Gotchas de prompting: cómo un prompt se rompe en producción
Un prompt que funciona en el playground funciona con el input que escribiste, en el modelo en el que lo escribiste, por un camino que recorriste vos. Producción lo corre con inputs que nadie guionó, con texto no confiable en la ventana, contra una versión de modelo que se te mueve abajo — y una falla de prompt parece una respuesta con seguridad, no un error. Diez gotchas que rompen un prompt después de la demo, cada uno con la pregunta que tenés que contestar primero y el costo de equivocarte.
Marco de decisión
Style Guide de prompting: la vara que un prompt pasa antes de salir
Las reglas con opinión que Cleon aplica a cada prompt — la primera decisión (prompt, ground o fine-tune), la vara de calidad que un prompt pasa antes de salir, y cómo componemos Agentforce Prompt Templates y la Claude API según dónde corre el prompt en lugar de elegir bando. El documento de disciplina que convierte los gotchas de prompting en una compuerta y los principios en práctica, tratando al prompt como contexto de ingeniería, no como un string que ajustás a ojo.
Referencia · 5
Referencia
¿Qué es context engineering? Todo lo que el modelo ve antes de responder
Context engineering es el cambio de escribir un prompt a decidir todo lo que llena el context window para una llamada dada — el system prompt, las instructions, los ejemplos, los hechos recuperados, la historia, las tool definitions y el input del usuario, todos compitiendo por un solo presupuesto finito. El reframe: un modelo solo ve su ventana, así que la ventana es la verdadera unidad de control. Por qué la mayoría de los problemas de 'el modelo se equivocó' son problemas de contexto, no del modelo. Y el vocabulario que usa el resto de esta subcategoría. Principio 10: el contexto es un presupuesto, no un balde.
Referencia
System prompts e instructions: dirigir el modelo a propósito
La parte de la dirección del contexto, escrita a propósito: la anatomía del system prompt — role, task, límites, formato de salida — y por qué el contenido de system arma una base más fuerte que el user turn. Las técnicas que de verdad aguantan: ser claro y directo, darle al modelo el porqué de una regla, mostrar ejemplos trabajados (few-shot), dejarlo razonar en voz alta para tareas de varios pasos, y descomponer una tarea demasiado grande en una cadena. Dicho con honestidad: un modelo no puede pensar en privado, así que el razonamiento solo ayuda si se le permite emitirlo. Cada cambio puntuado contra un set de eval (principio 3) — la estructura y el orden le ganan al volumen.
Referencia
Structured output: cuando necesitás JSON, no prosa
Cuando la salida del modelo alimenta un sistema en vez de un humano, la forma es un contrato — y parsear prosa para sacarla es la apuesta frágil que se rompe en el primer input que no probaste. Los caminos confiables en orden de fuerza: Structured Outputs para cumplimiento de schema garantizado, tool calling para argumentos tipados, y un spec de formato preciso en el system prompt para flexibilidad. El prefill no es la técnica — no está soportado en los modelos Claude nuevos. Sea cual sea el camino, validá cada salida antes de usarla y tené un fallback determinista para cuando la validación falla.
Referencia
Ventanas de contexto: el presupuesto de tokens que gasta cada llamada
La context window es cada token que el modelo puede referenciar en una llamada — incluida su propia respuesta — y es dos cosas a la vez: finita y ordenada. Esta es la profundidad operativa debajo del context engineering: la ventana es un presupuesto del que tiran el system prompt, las instrucciones, los ejemplos, los hechos recuperados, la historia, las definiciones de tools y el input del usuario, así que más no es mejor; y está ordenada, así que un hecho clave varado en el medio se subpondera. Cómo manejar una ventana que crece, por qué un techo de un millón de tokens igual no es licencia para llenarlo, y las palancas — resumir, descartar, recuperar bajo demanda, server-side compaction — que la mantienen honesta. Principio 10: el contexto es un presupuesto, no un balde.
Referencia
Prompt caching: dejá de re-pagar el mismo prefix
El preámbulo estático grande — system prompt, tool defs, ejemplos, un documento de grounding largo — reenviado en cada llamada se reprocesa cada vez, y a volumen de producción eso es una factura que nadie aprobó. El prompt caching lo arregla: marcás un prefix estable con cache_control y las llamadas siguientes reusan el procesamiento del modelo en vez de re-pagarlo. La mecánica — el caching corre en orden sobre tools, después system, después messages, hasta el bloque marcado inclusive, con hasta 4 breakpoints, automáticos o explícitos. La economía dicha con honestidad: un cache read cuesta cerca de 0.1x un token de input base mientras un cache write cuesta más que uno, así que el caching gana sobre un prefix reusado y puede perder en una llamada de una sola vez. Y la regla de diseño que lo hace rendir — el contenido estable primero, el input variable último.