¿Qué es lo que más te frustra al desarrollar aplicaciones de IA últimamente? Lo más probable es este escenario: has modificado tu indicación por decimoséptima vez, has ejecutado un par de casos de prueba y parece que todo va bien, pero al lanzarlo, un usuario encuentra un caso extremo (edge case) que no habías previsto y todo se desmorona. Esto es precisamente lo que el artículo de OpenAI publicado en octubre de 2025, "Building resilient prompts using an evaluation flywheel" (Construyendo indicaciones resilientes mediante un volante de evaluación), busca resolver de raíz.
El ingeniero de OpenAI, Neel Kapse, junto con el reconocido educador de ML, Hamel Husain, proponen en este artículo el concepto central de Evaluation Flywheel (Volante de evaluación). Utilizando una metodología consolidada proveniente de la investigación cualitativa en sociología, elevan el desarrollo de aplicaciones de IA desde el "prompt-and-pray" (modificar y rezar) hacia una verdadera disciplina de ingeniería. Este artículo desglosa el marco de trabajo del Volante de evaluación de OpenAI de la forma más sencilla posible para que puedas aplicarlo a tus propios proyectos de IA.
🎯 Guía rápida: El cookbook utiliza un caso práctico real: un "asistente de alquiler de apartamentos", mostrando todo el flujo de trabajo, desde el análisis de fallos hasta el grader automático y la integración con CI. Las herramientas Evals API y Prompt Optimizer mencionadas son capacidades avanzadas de la plataforma de OpenAI; los desarrolladores locales pueden ejecutar este flujo sin problemas utilizando servicios proxy de API como APIYI (apiyi.com).
Caso del asistente de alquiler: Una IA real colapsada por casos extremos
El caso elegido en el cookbook es muy cercano: un asistente de IA que responde preguntas a los inquilinos sobre dimensiones de apartamentos, citas para visitas, instalaciones, etc. Aunque parece un chatbot de atención al cliente común, al entrar en producción, los errores fueron de lo más variopintos.
Los ejemplos de fallos enumerados en el artículo son muy representativos y cualquiera que haya trabajado en esto se sentirá identificado:
| Tipo de fallo | Manifestación concreta | Consecuencia |
|---|---|---|
| Error de programación | Recomendó horarios de visita inexistentes | El cliente pierde el viaje, las quejas se disparan |
| Confusión de estado | No canceló la cita original al reprogramar | Doble reserva, caos en el embudo de ventas |
| Formato roto | La lista de instalaciones se convirtió en un bloque de texto | Mala experiencia, información ilegible |
| Enlace roto | El enlace al plano del piso daba error 404 | El usuario se va a la competencia |
| Deriva de datos | El horario de atención no coincidía con los datos reales | Información engañosa, riesgos legales |
Si has desarrollado alguna aplicación de IA, sabes que estos errores no se ignoran a propósito al escribir la indicación, sino que simplemente no se prevé que ocurran. El equipo de Fractional, en su caso de estudio sobre Receipt Inspection, resume bien este fenómeno: ejecutar solo unos pocos casos felices (happy paths) nunca detectará los errores de "cola larga" (long tail) en producción. Es obligatorio establecer un ciclo cerrado de "recolección de fallos → inducción de patrones → medición automática".
Este ciclo es, precisamente, el problema central que el volante de evaluación viene a resolver.
Definición central del volante de evaluación de OpenAI: disciplina de ingeniería para sustituir el "prompt-and-pray"
El libro de cocina (cookbook) define el volante de evaluación de forma concisa: un proceso de iteración continua que sustituye las conjeturas por una disciplina de ingeniería estructurada. Consta de tres etapas y, al igual que una rueda real, sigue girando; con cada vuelta, el sistema se vuelve un poco más resiliente.
Las responsabilidades de las tres etapas son muy claras y cada una resuelve un problema específico:
| Etapa | Problema central | Actividades principales | Entregables |
|---|---|---|---|
| Analyze (Análisis) | "¿Por qué falla?" | Revisión manual de muestras fallidas, inducción de patrones de error | Lista de clasificación de fallos + porcentaje |
| Measure (Medición) | "¿Qué tan grave es el fallo?" | Creación de evaluador (grader), ejecución de conjuntos de datos | Métricas cuantitativas + línea base |
| Improve (Mejora) | "¿Cómo solucionarlo?" | Ajuste de indicación, re-ejecución de evaluaciones | Nueva versión + comparación de métricas |
Muchos equipos se saltan la etapa de Análisis para pasar directamente a la evaluación automática, siendo esta la causa más común del fracaso del volante de evaluación. Cualquier medición automática sin un análisis cualitativo es un castillo en el aire, porque simplemente no sabes qué estás midiendo. Esta es la percepción más importante de este libro de cocina y lo que lo distingue de los tutoriales comunes de evaluación.
💡 Analogía: El volante de evaluación es similar al ciclo PDCA que conocen los gestores de producto, pero aplicado a la ingeniería de indicaciones con una metodología concreta. "Análisis" equivale a "encontrar problemas", "Medición" a "cuantificar problemas" y "Mejora" a "solucionar problemas"; las tres etapas son indispensables. Recomendamos que, al realizar invocaciones de modelos en apiyi.com utilizando la API de Evals de OpenAI, consolides primero la etapa de Análisis antes de iniciar la medición.
Etapa 1 del volante de evaluación de OpenAI: El método de etiquetado en dos pasos de Analyze (Análisis)
La etapa de Análisis es la más ignorada y, a la vez, la más crítica. El libro de cocina propone un método muy profesional: Open Coding (Codificación abierta) → Axial Coding (Codificación axial). Este método proviene de la investigación cualitativa en sociología, ha sido validado durante décadas y es uno de los paradigmas más maduros para analizar datos de texto no estructurados.
El primer paso, Open Coding (Codificación abierta), es sencillo: lee 50 muestras fallidas y, sin preestablecer ninguna categoría, asigna una etiqueta descriptiva a cada fallo. Por ejemplo:
- "Recomendó una hora de visita inexistente"
- "La lista de instalaciones es un bloque de texto ilegible"
- "No canceló la cita original tras reprogramar"
- "Respondió con dimensiones que no corresponden a este apartamento"
- "El enlace al plano de planta no funciona"
Ten en cuenta que en este paso no se busca una clasificación ordenada, solo necesitas describir honestamente lo que ves. La codificación abierta es como tomar notas de lectura: deja fluir tus ideas sin restricciones, ya que clasificar demasiado pronto te hará perder la capacidad de percibir patrones marginales.
El segundo paso, Axial Coding (Codificación axial), es donde comienza la estructuración: combinas las etiquetas dispersas del primer paso en categorías de alto nivel con significado. Los ejemplos de categorías que ofrece el libro de cocina son:
- Problemas de programación de visitas (combinación: hora incorrecta, no cancelada, reserva doble) → Representa el 35% de los fallos.
- Errores de formato (combinación: maquetación rota, enlaces rotos) → Representa el 10% de los fallos.
- Problemas de precisión de datos (combinación: horario de apertura incorrecto, dimensiones erróneas) → Representa un porcentaje de los fallos.
La codificación axial es como organizar el índice de un libro, permitiéndote ver el "mapa topográfico" de los fallos. Ese 35% te indica inmediatamente qué categoría priorizar, ya que ofrece el mayor retorno de inversión (ROI).
| Método de etiquetado | Objetivo | Mentalidad | Salida |
|---|---|---|---|
| Open Coding | Descubrimiento | Creativa, sin categorías previas | 50+ etiquetas descriptivas |
| Axial Coding | Estructuración | Inductiva, construcción de categorías | 5-8 categorías de fallo de alto nivel |
🔧 Consejo práctico: Los desarrolladores pueden conectar los registros de producción directamente a la interfaz de etiquetado de conjuntos de datos de la plataforma Evals mediante la API de transferencia de OpenAI (como apiyi.com), sin necesidad de programar un backend propio. Usa la columna de tipo "Feedback" para la codificación abierta y la columna de tipo "Label" para la codificación axial; el flujo será exactamente igual al del libro de cocina.
Fase 2 del ciclo de evaluación de OpenAI: Selección de los dos tipos de evaluadores (Grader) para la etapa de "Medición"
En la etapa de análisis ya identificaste "cómo se ve el fracaso", ahora en la etapa de medición debes convertir esos fallos en código de detección automática. El libro de recetas (cookbook) ofrece una guía de selección para dos tipos de evaluadores, que es donde los ingenieros suelen confundirse más.
| Tipo de Grader | Escenario de aplicación | Ventajas | Desventajas |
|---|---|---|---|
| Python Grader | Reglas deterministas (cadenas, regex, validación de API) | Resultados estables, cero alucinaciones, costo cero | No puede evaluar dimensiones subjetivas |
| LLM Grader | Juicio subjetivo (estética, alineación semántica, calidad de razonamiento) | Flexible, evalúa dimensiones difíciles de codificar | Requiere alineación con expertos (SME), costo en tokens |
Tomemos como ejemplo un asistente de apartamentos; ambos tipos de evaluadores tienen su lugar:
- "¿El horario recomendado está dentro de la disponibilidad real?" → Python Grader (consulta a base de datos o API)
- "¿La lista de instalaciones está bien organizada?" → LLM Grader (puntuación de 0 a 10)
- "¿El enlace al plano de planta es accesible?" → Python Grader (solicitud HEAD)
- "¿El tono de respuesta coincide con la identidad de marca?" → LLM Grader (puntuación basada en rúbrica)
El cookbook destaca una práctica de ingeniería fundamental: los LLM Grader deben pasar por una validación de alineación con expertos (SME, Subject Matter Expert); no puedes confiar ciegamente en la puntuación de GPT-4o. El método específico consiste en dividir los datos en entrenamiento/validación/prueba y verificar dos métricas:
- High TPR (Tasa de Verdaderos Positivos): Detecta los fallos reales.
- High TNR (Tasa de Verdaderos Negativos): No marca erróneamente muestras que son correctas.
Fijarse solo en la precisión puede llevar a engaños debido a una línea base alta; es obligatorio alinear ambos indicadores. Este es el punto de inflexión para pasar de un "LLM-as-Judge" que "parece funcionar" a uno que "realmente funciona".
📊 Proceso de validación: El experto (SME) etiqueta 100 muestras como verdad absoluta (ground truth) → El LLM Grader puntúa las mismas muestras → Se calculan TPR / TNR → Se ajusta la indicación del evaluador hasta que ambos indicadores cumplan el objetivo. Este flujo es compatible de forma nativa en la plataforma Evals de APIYI, ya que su API de Evals es totalmente compatible con el protocolo oficial de OpenAI.
Fase 3 del ciclo de evaluación de OpenAI: Experimentos de doble vía para la "Mejora"
En la tercera etapa, finalmente puedes poner manos a la obra para modificar tu indicación. El cookbook propone dos rutas de mejora paralelas; no son excluyentes, sino complementarias.
Ruta 1: Optimización automática de la indicación (Prompt Optimizer)
La plataforma de OpenAI incluye una herramienta de optimización de indicaciones. Le proporcionas un conjunto de muestras fallidas y la indicación original, y esta probará automáticamente una serie de estrategias (añadir few-shot, chain-of-thought, ajustar el orden de las instrucciones, etc.), evaluando el impacto en tu evaluador. Esta ruta es eficiente y es ideal como exploración inicial.
Ruta 2: Modificación manual basada en patrones de fallo
Basándose en los patrones de error identificados en la etapa de análisis, los ingenieros ajustan la indicación de forma específica. Por ejemplo:
- Error en la programación de visitas → Añadir un paso obligatorio en la indicación para "verificar el calendario de disponibilidad".
- Formato visual roto → Usar etiquetas XML para especificar claramente el formato de salida.
- Citas modificadas no canceladas → Añadir una lógica de máquina de estados: "cancelar primero, luego reservar".
La ventaja de la ruta manual es la precisión; sabes exactamente qué cambio ataca a qué fallo, lo que facilita el proceso de depuración.
Una vez completadas ambas rutas, tendrás N versiones candidatas de la indicación. Aquí llega el paso más crítico de la etapa de mejora: ejecutar todas las versiones en el mismo conjunto de datos usando el mismo evaluador y elegir la que tenga las mejores métricas. No te saltes este paso, ya que los humanos tenemos un sesgo de "auto-complacencia" con nuestras propias indicaciones; lo único que puede corregir ese sesgo son los números.
Tras probar todas las versiones, habrás completado una vuelta del ciclo. Descubrirás nuevos patrones de fallo (porque al mejorar el sistema, se exponen casos límite más profundos) y volverás a la etapa de análisis para la siguiente vuelta. Esta es la esencia del "ciclo": no se detiene, gira cada vez más rápido y se vuelve más robusto.
Diferencias esenciales entre una indicación resiliente y una frágil
El concepto de resilient prompt (indicación resiliente) mencionado en el título es fundamental. La definición que ofrece el libro de recetas (cookbook) es: una indicación capaz de ofrecer respuestas de alta calidad ante cualquier entrada posible. Aunque suena sencillo, en la práctica representa un estándar de ingeniería muy elevado.
Las diferencias entre resiliencia y fragilidad se manifiestan principalmente en cinco dimensiones:
| Dimensión de comparación | Indicación frágil | Indicación resiliente |
|---|---|---|
| Robustez de entrada | Falla al cambiar una palabra | Estable ante paráfrasis |
| Casos borde | Salidas extrañas o alucinaciones | Degradación elegante o intervención humana |
| Observabilidad | Caja negra, difícil de diagnosticar | Evaluadores (graders) completos para localizar fallos |
| Acceso a producción | El demo no garantiza el rendimiento | Ciclo de evaluación completo |
| Evolución | Arreglar A rompe B | Protección mediante regresión automática |
La intuición de muchos ingenieros es que una indicación "debería ser suficiente", pero al llevarla a producción aparecen problemas con una probabilidad del 0.1%. Aunque parezca poco, en un entorno de millones de invocaciones, esto se traduce en 1000 incidentes. El valor de ingeniería de una indicación resiliente no es pasar del 80% al 90%, sino elevar la fiabilidad del 99% al 99.9%.
🚀 Consejo de integración: Para llevar tu indicación a una resiliencia del 99.9%, debes automatizar el ciclo de evaluación. Esto requiere una invocación estable de la API de Evals de OpenAI y herramientas de optimización de indicaciones. Recomendamos utilizar plataformas de servicio proxy de API como apiyi.com, que ofrecen interfaces totalmente sincronizadas con la oficial y nodos IDC locales que garantizan que las tareas de evaluación prolongadas no se interrumpan.
Integración CI/CD del ciclo de evaluación de OpenAI y monitoreo en producción
El libro de recetas enfatiza que el paso final es: convertir el ciclo de evaluación en una disciplina de ingeniería diaria. Esto se implementa en dos frentes:
Primero: Integración CI/CD
Conecta tu conjunto de evaluadores (graders) al flujo de trabajo de CI, de modo que cada cambio en la indicación dispare una evaluación automática. Si las métricas se degradan por debajo de un umbral, se bloquea la fusión del PR. Este paso marca la transición de la "evaluación" como una actividad de investigación a una práctica de desarrollo diaria, lo que define la verdadera ingeniería de indicaciones.
| Tipo de umbral CI | Configuración recomendada | Explicación |
|---|---|---|
| Precisión global | Degradación ≤ 1% | Previene regresiones generales |
| Evaluador clave | Degradación ≤ 0.5% | Control estricto de fallos críticos |
| Detección de nuevos patrones | Advertencia, no bloqueo | Fomenta el descubrimiento de problemas |
| Latencia P95 | Crecimiento ≤ 10% | Controla costos y experiencia de usuario |
Segundo: Monitoreo en producción
Más allá del CI, es necesario realizar muestreos continuos en el entorno de producción para detectar "patrones de fallo salvajes" que no están en el conjunto de pruebas. Estos nuevos patrones se reintegran al conjunto de evaluación para impulsar la siguiente vuelta del ciclo.
La práctica consiste en muestrear los registros de producción en un porcentaje determinado (por ejemplo, 1%), ejecutar el mismo conjunto de evaluadores y realizar un análisis manual cuando se detecten anomalías. Los nuevos patrones de fallo identificados se procesan mediante codificación abierta (Open Coding) y codificación axial (Axial Coding) antes de añadirse al conjunto de pruebas.
Este ciclo garantiza que tu sistema de indicaciones sea cada vez más resiliente en lugar de estancarse tras el despliegue. Es la disciplina de ingeniería central que el libro de recetas deja para todos los ingenieros de IA.
5 lecciones prácticas del ciclo de evaluación de OpenAI para desarrolladores locales
Tras leer el libro de recetas (cookbook), he destilado 5 lecciones que ofrecen una guía directa para los desarrolladores que trabajan con modelos en chino:
Lección 1: Empieza por el análisis, no por la medición
Muchos equipos comienzan configurando evaluadores (graders) y analizando métricas, saltándose el análisis manual. Esto provoca que el evaluador no mida realmente los patrones de fallo, resultando en números atractivos mientras los usuarios siguen quejándose. No inicies una evaluación automática sin haber realizado al menos 50 codificaciones abiertas (Open Coding) manuales.
Lección 2: No dejes que el GPT haga la codificación abierta (Open Coding)
La codificación abierta debe ser realizada por humanos, ya que el GPT, al realizar tareas de inducción, puede contaminar tus etiquetas con los sesgos de sus datos de entrenamiento. El momento más temprano para involucrar a un LLM es después de la codificación axial, al implementar el evaluador; la fase de "descubrimiento" en el análisis es territorio exclusivo de los humanos.
Lección 3: Los evaluadores en Python son preferibles a los evaluadores basados en LLM
Siempre que puedas cubrir un caso con reglas deterministas, no uses un evaluador basado en LLM. Las razones son tres: estabilidad, bajo costo y no requiere alineación con expertos en la materia (SME). Reserva los evaluadores basados en LLM para dimensiones subjetivas que las reglas no pueden cubrir.
Lección 4: Vincula las métricas al impacto en el negocio
Un 35% de problemas de programación o un 10% de problemas de formato: estos porcentajes solo tienen valor para la toma de decisiones si se traducen en "tasa de abandono de usuarios" o "tasa de quejas". La métrica en sí misma no tiene significado; lo que importa son sus consecuencias comerciales.
Lección 5: Automatiza el ciclo, no lo conviertas en un proyecto de una sola vez
El retorno de inversión (ROI) de una sola vuelta del ciclo puede no ser muy alto, pero el interés compuesto a largo plazo es considerable. Convierte los evaluadores en tareas de integración continua (CI), el muestreo de producción en tareas programadas y la detección de nuevos patrones en alertas automáticas, permitiendo que el ciclo gire por sí solo las 24 horas.
Estructura de código en Python para replicar el ciclo de evaluación de OpenAI
Aunque el libro de recetas demuestra principalmente el flujo de trabajo de la interfaz de usuario de la plataforma OpenAI, la invocación programática de la API de Evals también es compatible. La siguiente estructura de código en Python muestra cómo llamar a la API de Evals para crear un evaluador y ejecutar una evaluación, ideal para desarrolladores que prefieren un flujo de trabajo basado en código:
from openai import AsyncOpenAI
client = AsyncOpenAI(
base_url="https://vip.apiyi.com/v1", # Cambiar a la puerta de enlace de APIYI
api_key="Tu clave API de APIYI"
)
# 1. Crear tarea de evaluación (definir conjunto de evaluadores)
eval_cfg = await client.evals.create(
name="leasing_assistant_v1",
data_source_config={
"type": "stored_completions",
"metadata": {"version": "v1"}
},
testing_criteria=[
{ # Ejemplo de evaluador en Python
"type": "string_check",
"name": "tour_time_valid",
"input": "{{sample.output}}",
"operation": "eq",
"reference": "{{item.expected_time}}"
},
{ # Ejemplo de evaluador basado en LLM
"type": "score_model",
"name": "format_quality",
"model": "gpt-4o",
"input": "{{sample.output}}",
"instructions": "Puntúa del 0 al 10 la claridad del formato de salida"
}
]
)
# 2. Ejecutar evaluación
run = await client.evals.runs.create(
eval_id=eval_cfg.id,
name="baseline_run",
data_source={"type": "completions"}
)
# 3. Obtener resultados de la evaluación
result = await client.evals.runs.retrieve(eval_id=eval_cfg.id, run_id=run.id)
print(f"Tasa de éxito: {result.report_url}")
Este código tiene tres puntos clave. El primero es el cambio de base_url; esta línea determina si puedes ejecutar tareas de evaluación de forma estable desde el país. El segundo es la matriz testing_criteria, donde puedes configurar todos los evaluadores en una lista y ejecutarlos de una sola vez. El tercero es que la API de Evals es asíncrona; ejecutar evaluaciones en grandes conjuntos de datos puede llevar desde unos minutos hasta decenas de minutos, por lo que debes gestionar la espera y los reintentos en tu programa.
FAQ sobre el ciclo de evaluación de OpenAI
P1: ¿Hay alguna diferencia entre el ciclo de evaluación y plataformas como LangSmith o Weights & Biases?
El enfoque es distinto. LangSmith se centra principalmente en la "instrumentalización de la evaluación", mientras que el ciclo de evaluación se enfoca en la "metodología de evaluación". El primero te dice cómo implementarlo, el segundo te enseña cómo pensar al respecto. Ambos pueden utilizarse de forma complementaria: usa la herramienta para dar soporte a la metodología.
P2: ¿Son suficientes 50 muestras de error o son muy pocas?
Para la fase de codificación abierta (Open Coding), 50 son suficientes, ya que el objetivo es descubrir patrones y no realizar una estadística exhaustiva. En la fase de medición (Measure), el número de muestras necesarias depende de la tasa de error: si la tasa es del 5%, necesitarás 1000 muestras para obtener un intervalo de confianza estable; si la tasa es del 30%, con 200 será suficiente.
P3: ¿Puede el optimizador de indicaciones (Prompt Optimizer) reemplazar completamente la edición manual?
No. Las herramientas automáticas son excelentes para la optimización local basada en un evaluador (grader) conocido, pero no son buenas para entender restricciones de negocio (como la regla implícita de que "el cliente requiere que cada respuesta no supere los 80 caracteres"). La combinación de edición manual y optimización automática es la mejor práctica.
P4: ¿Es estable la invocación de la API de Evals desde China?
La conexión directa a OpenAI para tareas de larga duración (la evaluación suele tardar desde unos minutos hasta varias horas) a menudo sufre reinicios de conexión. Recomendamos utilizar un servicio proxy de API como apiyi.com para las llamadas a OpenAI; los nodos de centros de datos locales están optimizados específicamente para conexiones largas, lo que reduce significativamente la tasa de interrupción de las tareas de evaluación.
P5: ¿Para qué tamaño de equipo es adecuado el ciclo de evaluación?
Es aplicable desde proyectos de una sola persona hasta equipos de 100 personas; la diferencia radica únicamente en la frecuencia con la que gira el ciclo. Un proyecto individual puede completar una vuelta cada dos semanas, mientras que un equipo grande puede lograr iteraciones diarias o incluso por hora. Lo clave es establecer la disciplina, no el tamaño.
P6: ¿Quién es Hamel Husain y por qué este libro de cocina (cookbook) ha recibido tanta atención?
Hamel es un educador muy influyente en la comunidad de aprendizaje automático y un promotor constante de las mejores prácticas de ingeniería para aplicaciones de Modelos de Lenguaje Grandes. Este libro de cocina es la primera vez que OpenAI introduce sistemáticamente metodologías de investigación cualitativa (como la codificación abierta) en la ingeniería de indicaciones, por lo que ha generado mucho debate en la industria.
Conclusión
El verdadero valor de la metodología del ciclo de evaluación de OpenAI es que proporciona a la comunidad de ingenieros de IA una respuesta estándar a la pregunta de "¿qué hace que la ingeniería de indicaciones sea profesional?". No es una herramienta específica, sino una disciplina de ingeniería que transforma el desarrollo de indicaciones de un "trabajo artesanal basado en la intuición" a una "práctica de ingeniería trazable".
Al integrar las etapas de Análisis → Medición → Mejora en tu flujo de trabajo, tu aplicación de IA pasará de ser un "demo que parece funcionar bien" a un producto "listo para producción y capaz de cumplir con un SLA". Detrás de esta mejora, existe un ciclo completo donde los fallos se recopilan sistemáticamente, los patrones se resumen de forma estructurada y las mejoras se validan mediante mediciones automáticas.
Si estás trabajando en cualquier aplicación de IA basada en indicaciones, te recomendamos encarecidamente que implementes este ciclo. Sugerimos utilizar plataformas de API proxy de OpenAI como apiyi.com para invocar directamente la API de Evals y el optimizador de indicaciones; con solo cambiar la base_url, podrás ejecutar todo el flujo del libro de cocina sin preocuparte por los problemas de estabilidad de la red.
Graba este "ciclo" en tu memoria muscular y, a partir de hoy, tus indicaciones comenzarán el camino hacia la resiliencia.
📌 Autor: Equipo de APIYI — Seguimiento a largo plazo de casos prácticos de ingeniería de API multimodales de OpenAI / Anthropic / Google. Para más interpretaciones prácticas de libros de cocina y guías de integración de la API de Evals, visita el centro de documentación en apiyi.com.
