IA SosteniblePrompts de programación y datos
Elegir el tamaño de modelo adecuado para una tarea
Programación y datosCuando integras IA en un producto y dudas si necesitas un modelo grande o basta uno pequeño.
Eres ingeniero/a de aprendizaje automático con enfoque en eficiencia. Mi tarea es [DESCRIPCIÓN], con volumen aproximado de [PETICIONES] y requisitos de calidad [CRITERIOS]. Diseña un procedimiento para decidir el tamaño de modelo: 1) cómo definir un conjunto de pruebas representativo con casos reales, 2) qué métricas de calidad y de coste de cómputo comparar, 3) cómo probar de menor a mayor tamaño y parar cuando la mejora ya no compense, 4) cuándo ayudan la caché, el ajuste con ejemplos o las reglas deterministas, 5) qué registrar para poder estimar energía. Formato: pasos numerados y plantilla de tabla de resultados. Restricciones: no des cifras de consumo de ningún modelo ni afirmes qué tamaño basta; di que debe medirse. Avisa de las limitaciones de tu propuesta.
- Incluye casos difíciles en el conjunto de pruebas, no solo los fáciles.
- Registra latencia y tamaño de entrada; son un indicador razonable del cómputo.
Qué esperar: Procedimiento escalonado con plantilla de resultados para comparar calidad y coste de cómputo. Un modelo pequeño que falla en casos críticos no es más sostenible; valida la calidad antes de optimizar el gasto.
Plan para medir la eficiencia de un servicio con IA
Programación y datosCuando desarrollas un servicio con IA y quieres instrumentarlo para saber cuánto cómputo usa por tarea.
Eres ingeniero/a de plataforma con interés en eficiencia. Mi servicio hace [FUNCIÓN] con [ARQUITECTURA: modelo propio o externo, nube o local]. Diseña un plan de medición que incluya: 1) qué métricas registrar por petición (tiempo, tamaño de entrada y salida, reintentos, tasa de caché), 2) qué datos de infraestructura pedir al proveedor o al operador (uso de aceleradores, potencia, región), 3) cómo relacionar las métricas con una estimación de energía, indicando la incertidumbre de cada paso, 4) cómo evitar sesgos (picos, tráfico de pruebas), 5) cómo presentar los resultados con rangos. Formato: lista numerada y un esquema de tabla de registro. Restricciones: no des valores de consumo típicos ni factores de emisión; di dónde obtenerlos de forma verificable. Avisa de que muchas veces no se dispone de medición directa.
- Empieza con un registro sencillo y evoluciona; medir demasiado pronto complica.
- Documenta cada supuesto para poder repetir el cálculo.
Qué esperar: Plan de medición con métricas, fuentes de datos de infraestructura y plantilla de registro con rangos. Una estimación indirecta puede errar por un amplio margen; preséntala siempre como rango.
Revisar un proceso de datos para reducir cómputo innecesario
Programación y datosCuando tienes un script o pipeline que reprocesa datos o llama a un modelo más veces de las necesarias.
Eres ingeniero/a de software con experiencia en eficiencia de recursos. Te paso la descripción y el código de un proceso: [CÓDIGO O PSEUDOCÓDIGO]. Frecuencia de ejecución: [FRECUENCIA]. Analízalo y propón mejoras en este orden: 1) trabajo repetido que podría evitarse (caché, procesamiento incremental), 2) llamadas a un modelo que podrían sustituirse por reglas o por un modelo menor, 3) lotes frente a llamadas sueltas, 4) datos que se leen o mueven sin necesidad, 5) horarios o regiones donde ejecutar sería preferible si hay datos de intensidad de la red. Formato: lista priorizada con el cambio, el riesgo y cómo medir antes y después. Restricciones: no afirmes ahorros concretos; recomienda medir. No cambies el resultado funcional. Avisa de cualquier punto que no puedas valorar sin ver el entorno real.
- Mide el tiempo y el volumen de datos antes de tocar nada.
- Cambia una cosa cada vez para saber qué mejoró.
Qué esperar: Lista priorizada de mejoras con riesgo y método de medición antes y después. Optimizar no debe alterar los resultados; añade pruebas que confirmen que la salida es idéntica.
Reducir peticiones repetidas a un modelo en una aplicación
Programación y datosCuando una aplicación envía muchas llamadas a un modelo y quieres reducirlas sin perder calidad.
Eres arquitecto/a de aplicaciones con IA y enfoque de eficiencia. Mi aplicación hace [FUNCIÓN] y las peticiones al modelo tienen esta forma: [EJEMPLOS DE ENTRADAS]. Revisa el diseño y propón: 1) qué peticiones podrían resolverse con reglas, búsquedas o validaciones previas, 2) cómo reutilizar respuestas con caché y qué riesgos hay, 3) cómo acortar el contexto enviado manteniendo lo necesario, 4) cuándo agrupar peticiones, 5) cómo limitar reintentos y bucles automáticos, 6) qué métricas vigilar. Formato: lista con prioridad, riesgo y prueba de que no se degrada la calidad. Restricciones: no des números de ahorro; evita sugerir cambios que comprometan la privacidad de los usuarios o la corrección de las respuestas. Avisa de que cada caso necesita medición y de lo que no puedes valorar sin ver el sistema.
- Haz primero un registro de peticiones reales para ver cuáles se repiten.
- Prueba la caché con casos donde la respuesta correcta cambie con el tiempo.
Qué esperar: Lista priorizada de cambios con riesgos y pruebas de calidad. Una caché mal diseñada puede devolver información obsoleta o de otro usuario; valida la privacidad.
Diseñar una función que use datos de intensidad de la red
Programación y datosCuando quieres que un trabajo diferible se ejecute en horas con electricidad menos intensiva en emisiones.
Eres desarrollador/a senior con interés en computación consciente del carbono. Necesito diseñar un planificador para tareas diferibles de [TIPO DE TAREAS], con plazo máximo de [PLAZO]. Describe: 1) qué datos necesito (previsión de intensidad de la red de [REGIÓN], fuente y frecuencia de actualización), 2) cómo decidir si esperar compensa teniendo en cuenta el plazo, 3) qué hacer si falla la fuente de datos, 4) cómo registrar la decisión para auditarla, 5) casos en que no debe aplicarse (tareas urgentes, cargas casi constantes), 6) pruebas. Formato: arquitectura en texto, pseudocódigo y lista de pruebas. Restricciones: no inventes datos ni nombres de servicios; di qué tipo de fuente sería adecuada. Avisa de que los datos de intensidad tienen límites de resolución y metodología, y de que el beneficio real debe medirse.
- Documenta qué metodología de intensidad usa la fuente (media o marginal).
- Mantén siempre un plazo máximo para no retrasar indefinidamente.
Qué esperar: Arquitectura, pseudocódigo y plan de pruebas de un planificador consciente de la red. Retrasar tareas puede tener costes para el negocio; prioriza los requisitos funcionales.
Pruebas para comprobar que una optimización no empeora la calidad
Programación y datosCuando cambias a un modelo menor o acortas el contexto y debes demostrar que el servicio sigue funcionando bien.
Eres ingeniero/a de calidad de sistemas con IA. He cambiado [CAMBIO REALIZADO] en un servicio que [FUNCIÓN]. Diseña un plan de pruebas para comprobar que la calidad no se ha degradado: 1) construcción de un conjunto de casos representativo, con casos límite y casos sensibles, 2) criterios de aceptación definidos antes de medir, 3) comparación ciega entre versión anterior y nueva, 4) revisión humana de una muestra y cómo evitar el sesgo del revisor, 5) monitorización tras el despliegue y condiciones de marcha atrás. Formato: lista numerada y plantilla de tabla de resultados. Restricciones: no des umbrales numéricos como si fueran estándar; deben fijarse según el uso. Avisa de que una mejora de eficiencia que perjudique a ciertos usuarios no es aceptable y de qué casos no cubre tu plan.
- Incluye ejemplos de usuarios o idiomas minoritarios en las pruebas.
- Guarda los resultados para comparar con futuras versiones.
Qué esperar: Plan de pruebas con criterios previos, comparación ciega, revisión humana y plan de reversión. Un ahorro de cómputo no justifica errores graves; define qué fallos son inaceptables.