Ejemplos: zero-shot, one-shot y few-shot
Hasta ahora hemos especificado tareas mediante instrucciones. Decimos qué hacer, desde qué perspectiva, con qué criterios, sobre qué documentos y en qué formato.
Sin embargo, existe un tipo de problema que las instrucciones abstractas resuelven mal: mostrar cómo se ve una buena aplicación del criterio.
Supongamos que escribimos:
Clasifica cada hallazgo como riesgo ALTO, MEDIO o BAJO.Podemos definir las tres categorías con cuidado. Aun así, seguirá existiendo una frontera difícil entre casos próximos. ¿Cuándo una facultad unilateral de modificación es alta y cuándo media? ¿Qué extensión debe tener la explicación? ¿Qué cantidad de evidencia esperamos? ¿Qué diferencia existe entre un hallazgo suficientemente concreto y una afirmación genérica?
En esas situaciones podemos enseñar también por demostración.
Zero-shot, one-shot y few-shot describen, en este contexto pedagógico, cuántos ejemplos incluimos para orientar la respuesta:
zero-shot → ningún ejemplo;
one-shot → un ejemplo;
few-shot → varios ejemplos.
Los ejemplos no se agregan para “rellenar” el prompt. Se agregan cuando mostrar un patrón resulta más eficiente que seguir describiéndolo.
Una aclaración importante: no estamos reentrenando el modelo
Cuando incluimos ejemplos en un prompt, no estamos realizando entrenamiento en el sentido en que se entrenó originalmente el modelo ni modificando permanentemente sus parámetros.
Estamos incorporando ejemplos dentro del contexto de esa interacción para orientar la continuación que esperamos.
Para un lector principiante basta con esta distinción:
entrenamiento del modelo
≠
ejemplos incluidos en el promptLos ejemplos funcionan como referencias locales para esa tarea.
Zero-shot: instrucciones sin demostración
Un prompt zero-shot puede ser perfectamente sofisticado.
Revisa el contrato desde la posición del cliente.
Identifica cláusulas que puedan afectar continuidad del servicio, datos, confidencialidad, responsabilidad o terminación.
Clasifica cada hallazgo como ALTO, MEDIO o BAJO considerando impacto y dificultad de mitigación.
Para cada hallazgo indica ubicación, evidencia e interpretación.No hemos mostrado ninguna respuesta de ejemplo. El sistema debe aplicar las instrucciones directamente.
Zero-shot suele ser apropiado cuando:
- la tarea es conocida y suficientemente clara;
- las categorías tienen fronteras simples;
- el nivel de detalle no necesita calibración fina;
- queremos mantener el prompt compacto;
- todavía estamos explorando la mejor forma de resolver el problema.
No debemos entender zero-shot como una versión “inferior”. Si las instrucciones bastan, agregar ejemplos sólo consume contexto y aumenta mantenimiento.
One-shot: una demostración completa
Supongamos que el problema no es comprender las palabras alto, medio y bajo, sino entender cómo debe justificarse una clasificación.
Podemos añadir un ejemplo:
EJEMPLO
Texto contractual:
"El proveedor podrá modificar las tarifas con 30 días de aviso previo."
Hallazgo:
El proveedor dispone de una facultad unilateral de modificación de precio.
Riesgo:
MEDIO.
Fundamento:
La facultad puede aumentar el costo durante la vigencia. Su impacto depende de si el cliente dispone de un derecho de terminación antes de que el nuevo precio produzca efectos.
Información faltante:
Debe verificarse la cláusula de terminación y la fecha desde la cual rige el nuevo precio.Ese ejemplo transmite simultáneamente varias propiedades:
- la granularidad esperada;
- el tono;
- la relación entre texto e interpretación;
- el tipo de incertidumbre que debe identificarse;
- la extensión aproximada.
Una sola demostración puede comunicar mucho más que varias instrucciones estilísticas como “sé concreto”, “justifica” o “no seas categórico”.
Few-shot: enseñar un patrón y sus fronteras
Un solo ejemplo puede ser insuficiente cuando la tarea depende de distinguir categorías cercanas.
Podemos mostrar tres casos:
EJEMPLO A — ALTO
Texto:
"El proveedor podrá utilizar los datos del cliente para cualquier finalidad comercial propia o de terceros."
Clasificación:
ALTO.
Razón:
La autorización es abierta respecto de finalidad y destinatarios y puede afectar control sobre información del cliente.
---
EJEMPLO B — MEDIO
Texto:
"El proveedor podrá modificar las tarifas con 30 días de aviso."
Clasificación:
MEDIO.
Razón:
Existe una facultad unilateral económicamente relevante, pero el impacto depende de derechos de salida y condiciones de vigencia.
---
EJEMPLO C — BAJO
Texto:
"Las notificaciones administrativas podrán enviarse al correo designado por cada parte."
Clasificación:
BAJO.
Razón:
La regla exige una gestión operativa, pero normalmente no altera de forma sustantiva la distribución principal de riesgo.Ahora los ejemplos no sólo muestran “cómo escribir”. También enseñan cómo separar las categorías.
Qué significa realmente “mostrar un patrón”
Una respuesta contiene muchas decisiones que quizá nunca especificamos de forma explícita:
- cuánto citar;
- cuánto explicar;
- qué lenguaje usar;
- qué considerar una unidad de hallazgo;
- cómo marcar incertidumbre;
- en qué orden presentar información.
Un ejemplo puede estabilizar esas decisiones por demostración.
Comparemos:
Sé conciso y verificable.con:
Cláusula 12.2 — Terminación
Texto relevante:
"El cliente podrá terminar con 30 días de aviso."
Hallazgo:
Existe terminación por conveniencia.
Impacto:
Reduce dependencia contractual, aunque deben revisarse obligaciones de salida y costos asociados.La segunda versión hace visible qué significa, en esa tarea, una respuesta “concisa y verificable”.
Ejemplo positivo
Un ejemplo positivo muestra un patrón que queremos reproducir.
EJEMPLO POSITIVO
Documento: contrato.pdf
Ubicación: cláusula 8.2
Texto relevante: "..."
Hallazgo:
La cláusula autoriza un uso secundario de información derivada del servicio.
Interpretación:
Debe verificarse qué información queda incluida en la expresión "información derivada".
Información faltante:
Definición técnica y contractual del dato derivado.El ejemplo comunica:
“Una buena respuesta conecta evidencia, hallazgo, interpretación e incertidumbre de esta manera.”
Ejemplo negativo
Un ejemplo negativo muestra un patrón que debe evitarse.
EJEMPLO NEGATIVO
"La cláusula es ilegal, muy peligrosa y debería eliminarse."Luego conviene explicar por qué es negativo:
Problemas del ejemplo:
- no identifica la cláusula;
- no muestra evidencia;
- no explica el criterio de riesgo;
- formula una conclusión jurídica categórica sin fundamento;
- no distingue texto del contrato de evaluación.La explicación es importante. Si sólo incluimos un ejemplo malo sin delimitar claramente su función, corremos el riesgo de introducir un patrón que no queremos reproducir.
Positivo y negativo juntos
En tareas complejas puede ser útil mostrar contraste.
Riesgo alto: la cláusula de datos es problemática.Documento: contrato.pdf
Ubicación: cláusula 8.2
Texto relevante:
"El proveedor podrá utilizar información derivada del uso del servicio para mejorar sus productos."
Hallazgo:
Existe autorización de uso de información derivada para mejora de productos.
Evaluación:
MEDIO, sujeto a aclaración. La cláusula no permite determinar por sí sola si esa información puede incluir datos personales o información confidencial del cliente.
Información faltante:
Definición de "información derivada" y proceso de anonimización, si existe.El contraste muestra que el problema no era simplemente “ser más largo”. La segunda respuesta separa categorías epistemológicas distintas y hace posible la revisión.
Cuándo los ejemplos aportan más valor
Los materiales del curso destacan varios usos especialmente útiles:
- calibrar niveles de riesgo;
- mostrar el tono esperado;
- fijar granularidad;
- evitar respuestas demasiado genéricas;
- imitar una matriz o formato existente.
Podemos añadir una idea general: los ejemplos son valiosos cuando una regla verbal deja demasiadas implementaciones posibles.
Por ejemplo, la instrucción:
Distingue cambios jurídicamente relevantes de cambios estilísticos.puede seguir siendo difícil.
Un ejemplo puede mostrar la frontera:
CAMBIO ESTILÍSTICO
"deberá notificar" → "deberá comunicar"
si no cambia el efecto de la cláusula.
CAMBIO RELEVANTE
"con 30 días de aviso" → "con 5 días de aviso"
porque modifica un plazo contractual.Cuántos ejemplos son suficientes
No existe una cifra universal.
Agregar ejemplos tiene costos:
- consume contexto;
- aumenta longitud;
- exige mantenimiento;
- puede introducir contradicciones;
- puede fijar accidentalmente detalles irrelevantes;
- puede sesgar la respuesta hacia un universo demasiado estrecho.
Por eso la pregunta adecuada es:
¿Cuántos ejemplos necesito para comunicar el patrón o la frontera que las instrucciones no logran fijar?
A veces uno basta. A veces tres casos bien elegidos son mejores que diez repetitivos.
Diversidad: ejemplos que enseñan realmente la categoría
Supongamos que queremos enseñar una clasificación de riesgos contractuales, pero todos los ejemplos se refieren a responsabilidad.
El sistema puede recibir una señal muy fuerte sobre responsabilidad y una mucho más débil sobre:
- datos;
- propiedad intelectual;
- terminación;
- niveles de servicio.
Cuando buscamos generalización dentro de la tarea, conviene que los ejemplos cubran variaciones materialmente distintas.
No se trata de maximizar diversidad por sí misma. Se trata de representar los casos que definen el criterio.
Casos centrales y casos frontera
Una colección few-shot puede incluir dos tipos de ejemplos.
Caso central: muestra una aplicación evidente de la categoría.
Caso frontera: muestra una situación donde dos clasificaciones podrían competir.
Por ejemplo:
CASO CENTRAL — ALTO
Uso irrestricto de datos del cliente para fines propios.CASO FRONTERA — MEDIO/ALTO
Facultad unilateral de suspender el servicio por razones de seguridad definidas ampliamente, con aviso posterior.El caso frontera puede acompañarse de la regla que resuelve la duda:
Clasifica como ALTO si la suspensión puede afectar un servicio crítico sin revisión ni mecanismo rápido de impugnación.Así los ejemplos y los criterios se refuerzan entre sí.
Un ejemplo no debería introducir hechos del caso real
En trabajo documental existe una precaución importante: demostración y evidencia deben mantenerse separadas.
Si incluimos:
Ejemplo: cláusula 12.3...y luego analizamos un contrato real, no queremos que “12.3” reaparezca como si perteneciera a ese documento.
Podemos delimitar con encabezados claros:
<EJEMPLOS_DE_REFERENCIA>
...
</EJEMPLOS_DE_REFERENCIA>
<DOCUMENTO_A_ANALIZAR>
...
</DOCUMENTO_A_ANALIZAR>No es obligatorio utilizar XML. Lo importante es que la función de cada bloque sea inequívoca.
Los ejemplos deben ser correctos antes de reutilizarlos
Existe un riesgo metodológico evidente: si el ejemplo contiene una mala clasificación, una cita imprecisa o una inferencia exagerada, estamos estabilizando precisamente el patrón equivocado.
Antes de incorporar un ejemplo recurrente conviene verificar:
- que represente realmente el criterio;
- que su evidencia sea correcta;
- que no dependa de un hecho oculto;
- que su formato sea el que queremos conservar;
- que no contradiga otras instrucciones.
Un ejemplo reutilizado debe tratarse casi como una unidad de diseño del prompt.
Ejemplos y evaluación
Phoenix y Taylor sitúan “proporcionar ejemplos” junto con “evaluar calidad”. La relación es importante.
Los ejemplos no deberían elegirse solamente porque “se ven bien”. Idealmente provienen de casos que hemos revisado y sabemos que representan el estándar deseado.
Podemos construir un ciclo:
instrucción
↓
respuestas reales
↓
evaluación humana
↓
selección de buenos ejemplos
↓
prompt mejor calibradoEsto no convierte automáticamente el sistema en confiable, pero transforma experiencia acumulada en una señal reutilizable.
Zero-shot puede ser mejor que few-shot
Existe una tentación frecuente: pensar que few-shot siempre es más sofisticado y, por tanto, mejor.
No es así.
Si la tarea es:
Extrae todas las fechas en formato DD-MM-AAAA.es probable que no necesitemos cinco ejemplos.
Si la tarea es:
Determina cuándo una diferencia contractual debe escalarse al comité de riesgo según una política interna con excepciones.los ejemplos pueden ser mucho más valiosos.
La elección depende de la dificultad de comunicar el criterio, no del deseo de utilizar una técnica avanzada.
Qué no deben hacer los ejemplos
Los ejemplos no sustituyen:
- una tarea mal definida;
- documentos ausentes;
- criterios contradictorios;
- falta de evidencia;
- revisión humana.
Si escribimos:
Analiza bien todo.y agregamos tres ejemplos, seguimos teniendo una tarea mal delimitada.
Los ejemplos son una capa de especificación, no una reparación universal.
Caso conductor: calibrar una matriz de riesgos
En el contrato del proveedor de IA ya tenemos tarea, perspectiva, contexto, documentos, evidencia, criterios y formato.
Sin embargo, observamos que la aplicación clasifica demasiados hallazgos como “alto”.
En lugar de añadir adjetivos como “sé más equilibrado”, podemos introducir tres casos de referencia:
ALTO
Autoriza uso amplio de datos del cliente para fines propios sin delimitación clara.
MEDIO
Permite cambio de tarifas con aviso previo, sujeto a verificar derecho de terminación.
BAJO
Establece un canal operativo de notificaciones sin alterar obligaciones sustantivas principales.Luego agregamos:
Usa estos ejemplos sólo para calibrar el nivel de materialidad. No copies sus hechos, cláusulas ni ubicaciones al análisis del contrato real.Ahora los ejemplos cumplen una función concreta: calibrar una frontera.
Qué debes recordar
Zero-shot, one-shot y few-shot no son una escala automática de calidad.
Son distintas formas de especificar una tarea:
zero-shot = sólo instrucciones
one-shot = instrucciones + una demostración
few-shot = instrucciones + varias demostracionesLos ejemplos positivos muestran qué patrón imitar. Los negativos pueden ayudar a hacer visible un error, siempre que su función esté claramente explicada.
La regla central es:
utiliza ejemplos cuando la demostración comunique mejor que una regla abstracta aquello que quieres estabilizar.
El problema que todavía queda abierto
Incluso con buenos ejemplos, podemos seguir pidiendo demasiadas operaciones en un solo turno:
localiza → interpreta → clasifica → evalúa → verifica → recomienda → redactaSi algo falla, no sabemos en qué etapa ocurrió el error.
El siguiente nodo estudia una estrategia diferente: trabajar por etapas, haciendo visibles los productos intermedios y manteniendo control sobre el paso de una operación a la siguiente.