Aprender prompting
No hay un prompt perfecto universal. Hay problemas distintos que piden información distinta: instrucciones, contexto, datos, ejemplos, restricciones, formato y el modelo adecuado.
El camino sugerido
- 1. Fundamentos. Objetivo, contexto, restricciones, delimitadores, formato y criterios.
- 2. Técnicas. Cuándo pedir directo, cuándo dar ejemplos y cómo dividir problemas.
- 3. Context engineering. El contexto correcto, no simplemente más contexto.
- 4. Prompts especializados. Programación, documentos, RAG, agentes e imágenes.
Cada técnica indica su nivel recomendado (Inicial, Intermedio, Avanzado, Técnico). El nivel orienta por dónde empezar, no qué es mejor.
Fundamentos
Instrucciones claras Inicial
Decir exactamente qué hacer, sin rodeos ni dobles sentidos.
Objetivo explícito Inicial
Declarar el resultado esperado, no solo la tarea.
Contexto relevante Inicial
Dar los antecedentes mínimos que cambian la respuesta.
Restricciones explícitas Inicial
Decir qué NO hacer y qué límites respetar.
Delimitadores Intermedio
Separar instrucciones de datos con marcas visibles.
Formato de salida Inicial
Pedir la forma exacta de la respuesta.
Criterios de aceptación Intermedio
Definir cómo sabrás que la respuesta es correcta.
Ejemplos guía Inicial
Mostrar el resultado esperado cuando es difícil de describir.
Técnicas
Zero-shot Inicial
Pedir directamente, sin ejemplos.
Few-shot Intermedio
Dar pocos ejemplos de entrada y salida esperada.
Rol cuando aporta valor Intermedio
Asignar un rol solo si cambia perspectiva o vocabulario.
Descomposición Intermedio
Dividir un problema grande en subtareas explícitas.
Encadenamiento (chaining) Intermedio
Usar la salida de un paso como entrada del siguiente.
Refinamiento iterativo Intermedio
Mejorar por rondas con crítica concreta.
Prompt Engineering vs Context Engineering
El prompt es solo una parte del contexto efectivo que recibe el modelo:
Prompt + instrucciones del sistema + conversación + archivos relevantes + conocimiento recuperado + herramientas + memoria + estado = contexto efectivo.
No es una fórmula matemática: es una forma de pensar. Mejorar el sistema que rodea al modelo suele rendir más que reescribir la misma frase.
Selección de contexto Avanzado
Elegir el contexto correcto, no simplemente más contexto.
Separar instrucciones de datos Intermedio
Que el contenido analizado nunca parezca una orden.
Reducción de ruido Avanzado
Quitar lo irrelevante antes de enviar.
Optimización de contexto y tokens
- Eliminá contexto irrelevante antes de enviar.
- Evitá repetir las mismas instrucciones.
- Resumí el historial cuando corresponda.
- Recuperá detalles bajo demanda en vez de pegarlo todo.
- Separá conocimiento estable de información dinámica.
El objetivo no es “prompt más corto = mejor”, sino máxima información relevante con mínimo ruido. Los tokens del estimador del analizador son siempre una estimación, no el conteo exacto de cada modelo.
Errores frecuentes al usar IA
Ejemplo: “Arreglá esto.”
Por qué puede fallar: Sin objeto, error ni resultado esperado, el modelo adivina y casi siempre erra el blanco.
Alternativa: Nombrá qué, qué error ves y qué debería pasar.
Ejemplo: Pegar 3 archivos enteros para preguntar por una función.
Por qué puede fallar: El ruido compite con la señal y gasta contexto que podrías necesitar.
Alternativa: Pasá el fragmento relevante + reglas del proyecto.
Ejemplo: “En una línea, explicá detalladamente cada paso.”
Por qué puede fallar: Obliga a desobedecer una de las dos.
Alternativa: Decidí cuál manda: “resumen de una línea + anexo detallado”.
Ejemplo: “Resumí, traducí, criticá y convertí a JSON.”
Por qué puede fallar: Cada tarea degrada a las demás; los errores se acumulan.
Alternativa: Descomponé o encadená: una tarea por paso, validando entremedio.
Ejemplo: Pedir código sin lenguaje ni versión.
Por qué puede fallar: Recibís la respuesta más probable, no la aplicable a tu entorno.
Alternativa: Lenguaje, versión, qué no cambiar.
Ejemplo: “Mostramelo lindo.”
Por qué puede fallar: “Lindo” no es un formato: cada respuesta vendrá distinta.
Alternativa: Nombrá el formato y, si es estructurado, el schema.
Ejemplo: Copiar código o cifras sin revisar.
Por qué puede fallar: El modelo produce texto plausible, no verificado.
Alternativa: Ejecutá, verificá cifras y pedí criterios de aceptación.
Ejemplo: Inflar el prompt “para que entienda mejor”.
Por qué puede fallar: Más ruido ≠ más comprensión; además cuesta tokens.
Alternativa: Máxima información relevante, mínimo ruido.
Ejemplo: “Sos el mejor experto mundial...” y nada más.
Por qué puede fallar: Sin instrucciones ni datos, el rol no cambia la respuesta.
Alternativa: Rol solo si define audiencia o perspectiva, más contenido real.
Ejemplo: Pedir citas y publicarlas directo.
Por qué puede fallar: Las citas generadas pueden no existir.
Alternativa: Abrí cada enlace; separá hechos de inferencias.
Ejemplo: “Ya te lo dije en el prompt anterior, ¿no te acordás?”
Por qué puede fallar: Cada conversación tiene su contexto; nada persiste solo.
Alternativa: Reinyectá lo esencial o usá RAG/memoria del sistema.
Ejemplo: Parsear directo lo que devuelve.
Por qué puede fallar: Pedir JSON no garantiza JSON válido.
Alternativa: Validá siempre; si la API lo soporta, usá structured output nativo.
Ejemplo: Agregarlo a todo esperando milagros.
Por qué puede fallar: Ayuda en razonamiento, no en cualquier tarea; alarga y cuesta.
Alternativa: Usalo en problemas multi-paso; en el resto, pedí el formato que necesites.
Mitos y realidad
Mito: “Siempre hay que decirle que es un experto.”
Realidad: El rol ayuda cuando define audiencia o perspectiva. Solo, sin instrucciones ni contexto, no mejora nada medible.
Mito: “Un prompt enorme siempre funciona mejor.”
Realidad: Rinde el contexto relevante, no el voluminoso. El relleno es ruido que compite con la señal y cuesta tokens.
Mito: “Hay palabras mágicas que mejoran cualquier respuesta.”
Realidad: No existen fórmulas universales. Lo que mejora es información: objetivo, contexto, restricciones, ejemplos, formato.
Mito: “Si le pedís que verifique, queda verificado.”
Realidad: La auto-revisión puede ayudar, pero no reemplaza ejecutar tests, abrir fuentes o validar schemas. Verificar lo hacés vos.
Mito: “Un modelo con contexto de 1M recuerda perfectamente 1M tokens.”
Realidad: Ventana grande no es atención uniforme: la calidad puede degradarse en documentos muy largos. Para eso existe RAG y la selección de contexto.
Mito: “Prompt engineering murió, ahora solo importa el modelo.”
Realidad: Evolucionó a context engineering: instrucciones + datos + herramientas + memoria. Comunicarse bien con el sistema sigue importando.
Los mitos no se reemplazan por nuevas reglas absolutas: cada caso tiene matices.