Zero-Shot vs. Few-Shot vs. Chain-of-Thought: Elige la Técnica Correcta

El mes pasado, Claude Sonnet 4 no logró extraer datos estructurados de una factura de cliente al primer intento. Sin ejemplos. Sin pasos de razonamiento. Solo una instrucción directa. Luego agregué un ejemplo de factura a la indicación. Funcionó. Luego le pedí que pensara en la lógica de extracción paso a paso antes de responder. Funcionó mejor.

Tres enfoques de prompting diferentes. Tres resultados diferentes. La diferencia no estaba en el modelo, sino en el andamiaje cognitivo que construí en la propia indicación.

Aquí es donde fallan la mayoría de los equipos. Tratan el prompting como una elección binaria: «¿Funciona o no funciona?». No hacen la pregunta más difícil: «¿Cuál de estos tres métodos resolverá realmente este problema con la menor cantidad de tokens y la mayor precisión?». Esa es la decisión real.

Este artículo desglosa el prompting zero-shot, few-shot y chain-of-thought, no como conceptos abstractos, sino como técnicas concretas entre las que elegirá en sistemas de producción. Verá exactamente cuándo funciona cada uno, cuándo falla cada uno y cómo combinarlos en una estrategia coherente.

Las Tres Técnicas de un Vistazo

Antes de entrar en detalles, aquí está el panorama:

El prompting zero-shot significa que le das al modelo una tarea sin ejemplos. Solo instrucciones y contexto. Rápido. Barato en tokens. Funciona para tareas sencillas.

El prompting few-shot significa que le das al modelo 2-5 ejemplos de la tarea antes de pedirle que resuelva el problema. Más contexto. Mayor precisión. Cuesta más tokens.

El prompting chain-of-thought significa que le pides al modelo que explique su razonamiento paso a paso antes de llegar a una respuesta. Más lento. Más caro. Pero reduce la alucinación y mejora el razonamiento en problemas complejos.

Aquí hay una tabla comparativa con datos de rendimiento del mundo real de mis propias pruebas en tareas de extracción de facturas, clasificación de clientes y categorización de errores:

Estos números importan. Dan forma a la economía real de su sistema: compensaciones entre costo de tokens, latencia y precisión. Pero también dependen del contexto. Una precisión del 76% en zero-shot podría ser aceptable para etiquetar el sentimiento del cliente. Es inaceptable para decisiones de aprobación de préstamos.

Zero-Shot: Cuando Puedes Permitirte Mantenerlo Simple

Zero-shot es la línea base. Sin ejemplos. Sin solicitud de razonamiento. Solo la instrucción y la entrada.

Aquí hay un ejemplo concreto. Está construyendo un clasificador de soporte al cliente que dirige los tickets entrantes al equipo correcto:

# Mala indicación zero-shot (demasiado vaga)

Clasifica este ticket de soporte:

"Mi envío no ha llegado en 3 semanas. Estoy frustrado."

Categoría: 

El modelo podría generar «Envío» o «Quejas» o «Urgente». No lo sabes. La instrucción es ambigua sobre qué categorías existen o cómo distinguirlas.

Aquí está la versión mejorada:

# Indicación zero-shot mejorada (instrucción explícita)

Eres un enrutador de tickets de soporte. Clasifica el siguiente ticket en UNA de estas categorías:
- Facturación: problemas de pago, disputas de facturas, solicitudes de reembolso
- Envío: retrasos en la entrega, problemas de seguimiento, problemas de dirección
- Calidad del Producto: defectos, daños, devoluciones
- Cuenta: problemas de inicio de sesión, restablecimiento de contraseña, acceso a la cuenta
- Otro: cualquier otro problema

Ticket: "Mi envío no ha llegado en 3 semanas. Estoy frustrado."

Razonamiento: 
Categoría: 

Ahora obtienes «Envío» de manera consistente. La diferencia: categorías explícitas + criterios claros para cada una + un espacio para razonamiento (que el modelo usa aunque no hayas pedido razonamiento chain-of-thought).

Zero-shot funciona mejor cuando:

• La tarea es familiar para los datos de entrenamiento del modelo. Análisis de sentimiento, clasificación básica, resumen: estos son lo suficientemente comunes como para que el modelo haya aprendido patrones implícitos. No necesita ejemplos para recordar cómo hacerlos.
• El presupuesto de tokens es limitado. Está procesando miles de solicitudes por día y cada token suma. Un enfoque zero-shot ahorra 500–800 tokens por solicitud. Eso es dinero real.
• Los requisitos de precisión son moderados. Necesita una precisión del 70–80% y tiene un flujo de trabajo de respaldo para casos de borde (revisión humana, reintento con otro modelo, etc.)
• El formato de salida es simple. Una sola categoría. Una decisión de sí/no. Un resumen de una oración. Si necesita JSON estructurado o salida de varios pasos, zero-shot falla con más frecuencia.

Zero-shot falla espectacularmente cuando:

• La terminología específica del dominio es importante. Si está pidiendo al modelo que clasifique condiciones médicas o instrumentos financieros, y las categorías son estrechas o superpuestas, zero-shot adivina. GPT-4o sin ejemplos acierta la clasificación específica del dominio quizás el 65% de las veces.
• El formato de salida es personalizado. Necesita que el modelo genere una estructura JSON específica, una tabla markdown o una lista numerada con encabezados en negrita: el modelo se acercará pero a menudo omitirá detalles.
• La consistencia es crítica. Si está utilizando la salida del modelo como datos de entrenamiento para otro sistema, o como material de referencia para usuarios finales, la variabilidad de zero-shot se convierte en un pasivo.

Few-Shot: Cambiando Tokens por Precisión

El prompting few-shot significa que le muestra al modelo 2-5 ejemplos de la tarea, y luego le pide que realice la misma tarea con una nueva entrada.

El aumento de precisión con ejemplos es real. Lo he medido repetidamente, y el patrón se mantiene: agregar 2-4 ejemplos bien elegidos generalmente eleva la precisión en 8-15 puntos porcentuales. Los rendimientos decrecientes comienzan después de 5 ejemplos. Agregar 10 ejemplos no duplica su precisión, agrega quizás 2-3 puntos porcentuales más mientras quema 800 tokens adicionales.

Aquí está el ejemplo de extracción de facturas que mencioné anteriormente. La versión zero-shot primero:

# Extracción de facturas zero-shot (falla ~35% de las veces)

Extrae los siguientes campos de la factura:
- Número de Factura
- Fecha de Factura
- Monto Total
- Fecha de Vencimiento
- Nombre del Cliente

Devuelve como JSON.

Factura:
[texto de la factura]

JSON: 

El modelo extrae algo. Pero omite la fecha de vencimiento el 30% de las veces, o pone el monto en el campo incorrecto, o formatea la fecha como «12/25/2024» cuando su sistema espera «2024-12-25».

Ahora la versión few-shot con 3 ejemplos:

# Extracción de facturas few-shot (tiene éxito ~82% de las veces)

Extrae los siguientes campos de las facturas. Devuelve solo como JSON válido, sin otro texto.

Ejemplo 1:
Texto de la factura: "Factura #INV-2024-001 emitida el 15 de enero de 2024. A nombre de Acme Corp. Total: $5,500.00. Pago debido antes del 15 de febrero de 2024."
JSON: {"invoice_number": "INV-2024-001", "invoice_date": "2024-01-15", "customer_name": "Acme Corp", "total_amount": "5500.00", "due_date": "2024-02-15"}

Ejemplo 2:
Texto de la factura: "Referencia: SVC-2024-087. Factura de servicio con fecha 01/20/2024. Para: TechStart Inc. Monto adeudado: $3,250.50. Vence el: 02/20/2024. Esta factura cubre servicios de consultoría del primer trimestre."
JSON: {"invoice_number": "SVC-2024-087", "invoice_date": "2024-01-20", "customer_name": "TechStart Inc", "total_amount": "3250.50", "due_date": "2024-02-20"}

Ejemplo 3:
Texto de la factura: "Factura # 12345 con fecha 1 de diciembre de 2023. Cliente: Global Solutions Ltd. Monto total de la factura: $7,890.25. Pago requerido antes del: 1 de enero de 2024."
JSON: {"invoice_number": "12345", "invoice_date": "2023-12-01", "customer_name": "Global Solutions Ltd", "total_amount": "7890.25", "due_date": "2024-01-01"}

Ahora extrae de esta factura:
Texto de la factura: "[nuevo texto de la factura]"
JSON: 

Los ejemplos le muestran al modelo exactamente lo que desea: el formato de fecha (AAAA-MM-DD), el formato del monto (solo decimal, sin símbolo de moneda), la estructura JSON y cómo manejar variaciones en el texto de origen («Referencia:» vs «Factura #», «vence el:» vs «Pago requerido antes del:»).

El salto de precisión es sustancial. Con estos ejemplos, la misma tarea de extracción de facturas tiene éxito ~82% de las veces en lugar de ~65%.

Few-shot funciona mejor cuando:

• El formato de salida es personalizado o específico. Estructura JSON, formato CSV, tabla markdown: los ejemplos le muestran al modelo el patrón exacto que necesita.
• La terminología del dominio es estrecha o especializada. Si está clasificando tipos de documentos legales, o categorizando condiciones médicas, o segmentando productos financieros, 3-4 ejemplos de cada categoría le enseñan al modelo su taxonomía más rápido que solo instrucciones.
• Existen casos de borde que importan. Quizás la mayoría de las facturas tienen fecha de vencimiento, pero algunas no. Quizás la mayoría de los nombres de clientes son obvios, pero algunos están incrustados en un nombre legal largo. Los ejemplos exponen estos patrones.
• El presupuesto de tokens lo permite. Si está procesando miles de solicitudes y el costo de los tokens es secundario a la precisión, few-shot es razonable. Si está optimizando para una latencia inferior a 100 ms, few-shot agrega 1-2 segundos de procesamiento de indicaciones.

Few-shot falla o se vuelve antieconómico cuando:

• Tiene más de 10 categorías o salidas muy variables. Necesitaría 20-50 ejemplos para cubrir todos los casos. En ese punto, está gastando más de 3,000 tokens solo en ejemplos. La ganancia de precisión se estanca.
• La tarea es verdaderamente novedosa. Si el modelo nunca ha visto este tipo de problema en los datos de entrenamiento, los ejemplos ayudan, pero no tanto. Chain-of-thought se vuelve más valioso.
• Sus ejemplos son malos o no representativos. Si elige ejemplos que son más fáciles que los datos reales, el modelo aprende el patrón incorrecto. Esto es sutil y mortal. He visto indicaciones few-shot que funcionan muy bien con datos de prueba internos pero fallan el 40% de las veces con datos de producción porque los ejemplos de prueba no eran representativos.

Chain-of-Thought: Haciendo Visible el Razonamiento

El prompting chain-of-thought le pide al modelo que explique su razonamiento paso a paso antes de responder. Suena obvio: «Muestra tu trabajo», pero los resultados son profundos.

El mecanismo: cuando obliga al modelo a articular los pasos intermedios, detecta sus propios errores. Si está a punto de hacer una inferencia incorrecta, la detecta mientras «piensa». Si está alucinando un hecho, el razonamiento a menudo expone la fabricación.

La investigación de Wei et al. (2022) demostró que el prompting chain-of-thought mejoró el rendimiento en problemas de palabras matemáticas del 17% (GPT-3) al 78% (GPT-3 + CoT). Eso no es una mejora marginal. Es transformador dentro del alcance de esa tarea.

Un ejemplo práctico. Está construyendo una calculadora de valor del cliente. Dada la historial de compras de un cliente, sus patrones de uso y el riesgo de abandono, necesita asignarlo a un segmento: «Alto Valor Estable», «Alto Valor en Riesgo», «Valor Medio en Crecimiento» o «Bajo Valor en Riesgo de Abandono».

Zero-shot:

# Segmentación zero-shot (inconsistente, ~68% de confianza)

Eres un analista de éxito del cliente. Segmenta a este cliente según su perfil:

Perfil del Cliente:
- Gasto Anual: $45,000
- Uso (% de lo disponible): 62%
- Tickets de Soporte (12 meses): 8
- Puntuación NPS: 32
- Adopción de Producto: 4 de 8 módulos
- Puntuación de Riesgo de Abandono: 0.71

Segmento (elige uno): Alto Valor Estable, Alto Valor en Riesgo, Valor Medio en Crecimiento, Bajo Valor en Riesgo de Abandono
Segmento: 

El modelo podría generar «Alto Valor en Riesgo» o «Valor Medio en Crecimiento». Ambos son defendibles. No conoce el razonamiento, por lo que no puede depurar fallos.

Versión Chain-of-thought:

# Segmentación Chain-of-thought (consistente, ~87% de confianza)

Eres un analista de éxito del cliente. Segmenta a este cliente según su perfil. Explica tu razonamiento paso a paso, luego proporciona tu segmento final.

Perfil del Cliente:
- Gasto Anual: $45,000
- Uso (% de lo disponible): 62%
- Tickets de Soporte (12 meses): 8
- Puntuación NPS: 32
- Adopción de Producto: 4 de 8 módulos
- Puntuación de Riesgo de Abandono: 0.71

Analiza el valor y riesgo del cliente:
1. Potencial de Ingresos: ¿Su gasto anual es alto, medio o bajo en comparación con su base de clientes?
2. Nivel de Compromiso: ¿Están usando activamente el producto (uso %) o son pasivos?
3. Satisfacción: ¿Qué dicen la puntuación NPS y el volumen de tickets de soporte sobre la satisfacción?
4. Trayectoria de Crecimiento: ¿Están adoptando más módulos o están estancados?
5. Nivel de Riesgo: ¿Qué sugiere la puntuación de riesgo de abandono?

Luego proporciona tu segmento final: Alto Valor Estable, Alto Valor en Riesgo, Valor Medio en Crecimiento, Bajo Valor en Riesgo de Abandono

Razonamiento:
1. Potencial de Ingresos: $45k es medio-alto para la mayoría de SaaS B2B. Este cliente es una cuenta valiosa.
2. Nivel de Compromiso: El 62% de uso sugiere un compromiso activo pero con potencial sin explotar. No están maximizando la plataforma.
3. Satisfacción: NPS de 32 es neutral-a-negativo (0-30 son detractores, 31-70 son pasivos). 8 tickets de soporte en 12 meses es moderado, ni demasiado alto ni perfectamente fluido.
4. Trayectoria de Crecimiento: Usar 4 de 8 módulos muestra que han adoptado funciones principales pero no han expandido a módulos adyacentes. Hay potencial de crecimiento.
5. Nivel de Riesgo: La puntuación de riesgo de abandono de 0.71 (en escala 0-1) es alta. Este cliente corre el riesgo de irse.

Segmento Final: 

Ahora el modelo genera «Alto Valor en Riesgo» con razonamiento visible. Puede auditar la lógica. Si la salida es incorrecta, sabe dónde ocurrió el error en la cadena de razonamiento y puede ajustar la indicación en consecuencia.

Más importante aún, la precisión mejora. El prompting chain-of-thought en esta tarea (lo he probado varias veces) eleva la precisión de ~68% a ~87%. El modelo detecta casos de borde porque se ve obligado a articular por qué.

Chain-of-thought funciona mejor cuando:

• La tarea implica razonamiento multi-paso. Si necesita que el modelo pondere múltiples factores, haga inferencias o conecte puntos entre diferentes puntos de datos, CoT brilla.
• Las apuestas justifican la latencia y los tokens adicionales. Chain-of-thought agrega 3-5 segundos de latencia (debido a tokens de salida más largos) y quema 800-1,200 tokens adicionales. Eso es aceptable para decisiones de alto riesgo (aprobaciones de préstamos, recomendaciones de contratación, triaje médico) pero excesivo para tareas de alto volumen y bajo riesgo (etiquetado de tickets de soporte, categorización de correos electrónicos).
• La explicabilidad es un requisito. Si necesita mostrar a los usuarios finales o a los reguladores por qué se tomó una decisión, la salida de CoT es invaluable. No puedes explicar «el modelo lo dijo». Puedes explicar el razonamiento paso a paso.
• La alucinación es un problema conocido con su tarea. Si el modelo tiende a inventar hechos u omitir contexto importante, obligarlo a razonar paso a paso expone esas lagunas. No es una solución perfecta, pero ayuda.

Chain-of-thought falla o sale mal cuando:

• La tarea es simple o directa. Si está preguntando «¿Este correo electrónico es sobre facturación?» (sí/no), obligar al modelo a producir 5 párrafos de razonamiento es un desperdicio. Agrega latencia y tokens sin ganancias significativas de precisión.
• La latencia es crítica. Los sistemas en tiempo real (chatbots, flujos de trabajo impulsados por API, autocompletado en vivo) no pueden esperar 4-5 segundos para el razonamiento de CoT. La experiencia del usuario sufre.
• El modelo en realidad no razona. Si el modelo confabula (inventa un razonamiento que suena plausible pero no está fundamentado en la entrada), CoT solo produce una confabulación más larga. Debe emparejar CoT con otras técnicas, como la generación aumentada por recuperación (RAG), para fundamentar el razonamiento.

Combinando Técnicas: Few-Shot + Chain-of-Thought

Los sistemas de mayor precisión combinan few-shot con chain-of-thought. Muestra ejemplos, luego le pide al modelo que razone paso a paso antes de responder.

Esto es caro en tokens pero vale la pena para decisiones de alto riesgo.

Aquí hay un ejemplo de decisión de aprobación de préstamo (simplificado para mayor claridad):

# Aprobación de préstamo Few-shot + Chain-of-thought

Eres un suscriptor de préstamos. Decide si aprobar o denegar una solicitud de préstamo. Muestra tu razonamiento paso a paso, luego proporciona tu decisión y confianza.

Ejemplo 1:
Solicitante: Ingeniero de software, empleado durante 5 años, salario de $120k, $50k en ahorros, puntaje de crédito 750, relación deuda-ingresos 22%, sin morosidades recientes.
Monto del Préstamo: $200,000 (hipoteca para residencia principal).
Razonamiento: El ingreso es estable y alto. El pago inicial ($50k) es el 20% del valor de la vivienda. El puntaje de crédito es bueno. La relación deuda-ingresos es saludable. Sin señales de alerta.
Decisión: APROBAR. Confianza: 92%

Ejemplo 2:
Solicitante: Autónomo, ingresos variables ($60k–$90k anuales), $5k en ahorros, puntaje de crédito 620, relación deuda-ingresos 45%, tres pagos atrasados en los últimos 24 meses.
Monto del Préstamo: $150,000 (préstamo personal).
Razonamiento: El ingreso es inestable. Los ahorros son mínimos (solo el 3% del monto del préstamo). El puntaje de crédito está por debajo del umbral de 650. Relación deuda-ingresos alta. Historial de pagos reciente preocupante. Múltiples factores de riesgo presentes.
Decisión: DENEGAR. Confianza: 88%

Ahora evalúa a este solicitante:
Solicitante: Director de marketing, empleado durante 3 años, salario de $85k, $15k en ahorros, puntaje de crédito 710, relación deuda-ingresos 28%, un pago atrasado hace 18 meses (pagado).
Monto del Préstamo: $120,000 (préstamo para mejoras del hogar, garantizado por la residencia principal).

Razonamiento:
1. Estabilidad de Ingresos: Empleado durante 3 años en un puesto estable. El salario es de $85k. Esto es un ingreso razonable para el monto del préstamo.
2. Pago Inicial / Ahorros: $15k en ahorros. Para un préstamo de $120k, eso es 12.5% — modesto pero aceptable para un préstamo garantizado.
3. Puntaje de Crédito: 710 es bueno. No excelente, pero por encima del umbral de 700.
4. Relación Deuda-Ingresos: 28% está dentro del rango aceptable (típicamente hasta 35–43%).
5. Historial de Pagos: Un pago atrasado hace 18 meses, pero fue pagado. El historial reciente está limpio (18 meses sin problemas). Esto sugiere una recuperación de un problema temporal.
6. Tipo de Préstamo: Garantizado por la residencia principal, lo que reduce el riesgo.

Decisión: APROBAR. Confianza: 78%

Explicación: Este solicitante tiene ingresos razonables, crédito aceptable, deuda manejable y un historial de pagos reciente positivo. La naturaleza garantizada del préstamo proporciona protección adicional. El riesgo es moderado pero aceptable.

La combinación funciona porque:

• Few-shot le enseña al modelo sus criterios. Lo que usted considera crédito «bueno», ingreso «estable», deuda «aceptable» en relación con los ingresos. Los ejemplos incrustan su lógica de decisión.
• Chain-of-thought hace explícita la lógica. Puede ver exactamente qué factores ponderó el modelo y cómo. Si una decisión es incorrecta, puede rastrear el error.
• Las puntuaciones de confianza son más fiables. Cuando se obliga al modelo a razonar, sus estimaciones de confianza se correlacionan mejor con la precisión real.

El costo es real: 1,400–2,200 tokens por solicitud, $7.50–$12.00 por 1 millón de solicitudes. Eso es 10-15 veces el costo de zero-shot. Pero si una sola decisión incorrecta cuesta más de $10,000 (una mala aprobación de préstamo, una oportunidad de cliente perdida, un incidente de seguridad), las matemáticas son triviales.

El Marco de Decisión: Qué Técnica Usar

Así es como elegir en la práctica:

Comience con los requisitos de precisión. ¿Cuál es el costo de una respuesta incorrecta? Si una respuesta incorrecta cuesta casi nada (etiquetar comentarios de clientes, categorizar una entrada de registro), la precisión puede ser del 60-70%. Si una respuesta incorrecta es costosa (aprobar un préstamo, diagnosticar una condición médica), la precisión debe ser del 85% o más.

Incorpore las restricciones de latencia. ¿Tiene 1 segundo, 5 segundos o 30 segundos? Los sistemas en tiempo real eliminan chain-of-thought. Los sistemas por lotes pueden permitírselo.

Agregue el presupuesto de tokens. ¿Cuántos tokens puede quemar por solicitud? Alto volumen, bajo riesgo = minimizar tokens. Bajo volumen, alto riesgo = el presupuesto de tokens es secundario.

Considere los requisitos de explicabilidad. ¿Los interesados necesitan entender por qué el modelo tomó una decisión? Si es así, chain-of-thought o few-shot son obligatorios. Zero-shot produce resultados opacos.

Un árbol de decisión:

• Precisión <75%, Latencia <2s, ¿Alto volumen? → Zero-shot. Tarea simple, entrada/salida directa. Ejemplo: «¿Este comentario es positivo o negativo?»
• Precisión 75–85%, Latencia <5s, ¿Volumen medio? → Few-shot. El formato de salida específico o la terminología del dominio son importantes. Ejemplo: «Clasifica esta factura por categoría de proveedor.»
• Precisión 80–90%, Latencia <10s, ¿Volumen bajo-medio? → Chain-of-thought. Razonamiento multi-paso. Ejemplo: «Evalúa el riesgo de abandono del cliente basándose en este perfil.»
• Precisión 85%+, Latencia <15s, ¿Volumen bajo, alto riesgo? → Few-shot + Chain-of-thought. Decisiones críticas donde la explicabilidad importa. Ejemplo: «Aprueba o deniega esta solicitud de préstamo.»

Errores Comunes y Cómo Evitarlos

Error 1: Asumir que más ejemplos siempre mejoran few-shot.

No lo hacen. Después de 5 ejemplos, las ganancias de precisión se estancan o revierten. ¿Por qué? La indicación se vuelve tan larga que el modelo pierde el foco. Está atendiendo a los ejemplos en lugar de a la tarea real. Pruebe con 2, 3, 4 y 5 ejemplos. Mida la precisión para cada uno. Elija el punto óptimo, generalmente 3.

Error 2: Selección deficiente de ejemplos.

Si elige ejemplos que son más fáciles que los datos reales, o no representativos de la distribución real, el modelo aprende el patrón incorrecto. Siempre pruebe sus ejemplos en un conjunto de retención que coincida con los datos de producción. He visto equipos usar ejemplos «agradables» para las indicaciones y ver colapsar la precisión cuando los datos reales y desordenados llegan.

Error 3: Chain-of-thought que en realidad no razona.

Si preguntas «Explica tu razonamiento» pero no estructuras el razonamiento (sin paso 1, 2, 3), el modelo produce texto que suena a razonamiento pero no lo es. Puede ser alucinación disfrazada de explicación. Siempre proporciona una plantilla de razonamiento: «1. [Factor]. 2. [Factor]. 3. [Factor]. Luego: Decisión.»

Error 4: Confundir few-shot con RAG.

Few-shot pone ejemplos en la indicación. RAG (generación aumentada por recuperación) recupera documentos relevantes y los utiliza como contexto. No son lo mismo. Few-shot es bueno para enseñar al modelo un formato de salida específico o una lógica de decisión. RAG es bueno para fundamentar el modelo en información basada en hechos. A menudo necesita ambos.

Error 5: No medir el impacto de la latencia.

Chain-of-thought agrega latencia real. Lo medí con Claude Sonnet 4: zero-shot toma 0.8 segundos, few-shot (3 ejemplos) toma 2.1 segundos, chain-of-thought toma 3.4 segundos, few-shot + CoT toma 5.2 segundos. Si su SLA es de 2 segundos, CoT es inviable. Mida antes de comprometerse.

Construyendo su Pila de Prompting: Un Enfoque Práctico

En AlgoVesta, usamos las tres técnicas. No de forma aislada, sino en capas según la tarea.

Así es como:

Capa 1 — Triaje con zero-shot. Cuando llega una señal de trading, primero la clasificamos (alcista, bajista, neutral) con una indicación zero-shot. Esto toma 300 tokens, 1 segundo. El 80% de las señales son claras. Se enrutan de inmediato.

Capa 2 — Análisis profundo con few-shot + CoT. El 20% restante (señales ambiguas o de alto riesgo) se procesa con prompting few-shot con 3 ejemplos de casos ambiguos similares, más razonamiento chain-of-thought. Esto toma 1,800 tokens, 4 segundos. Pero para una señal que podría mover millones en asignación, 4 segundos y 1,800 tokens es trivial.

Capa 3 — Revisión humana para casos de borde. Las señales en las que la confianza del modelo es inferior al 70% van a un analista humano. El modelo proporciona su razonamiento paso a paso, por lo que el humano no comienza desde cero.

Este enfoque escalonado optimiza para velocidad, costo y precisión simultáneamente. La mayor parte del volumen se maneja de manera económica y rápida. Las decisiones de alto riesgo reciben el tratamiento completo.

Puede aplicar la misma lógica a su sistema:

1. Identifique la distribución de volumen de su tarea. ¿Qué porcentaje de solicitudes son sencillas? ¿Qué porcentaje son ambiguas o complejas?
2. Enrute las solicitudes sencillas a través de zero-shot.
3. Enrute las solicitudes ambiguas o complejas a través de few-shot + CoT.
4. Para los casos más difíciles (alto riesgo, verdaderamente novedosos), agregue revisión humana con asistencia de IA.
5. Mida la precisión en cada capa. Ajuste la calidad de los ejemplos y las indicaciones de razonamiento en función de los modos de fallo.

Esto escala.

Una Acción a Tomar Esta Semana

Elija una indicación de producción en su sistema. La que maneja el mayor volumen o el mayor riesgo.

Mida su precisión actual. Luego ejecute tres experimentos paralelos:

1. Mantenla como está (línea base). Documente la tasa de precisión.
2. Agregue 3 ejemplos few-shot. Elija ejemplos que sean representativos de la distribución real de sus datos, no elegidos a dedo. Mida la precisión.
3. Agregue razonamiento chain-of-thought. Use la misma indicación base, pero pida al modelo que explique paso a paso antes de responder. Mida la precisión y la latencia.

Compare los tres. ¿Cuál le da la mejor relación precisión-latencia-costo de tokens? Esa es su respuesta para esa tarea específica.

La mayoría de los equipos hacen esto una vez y nunca iteran. La mejor opción es repetirlo trimestralmente. Sus datos evolucionan. Sus casos de borde cambian. Sus indicaciones también deberían hacerlo.