Probamos 6 asistentes de IA con los mismos datos solares. Los resultados nos sorprendieron

Estamos desarrollando para HelioPeak una función que llamamos «Exportar para análisis con IA». La idea es sencilla: un toque a un botón en la app, obtienes un archivo Markdown con tus datos de producción solar y unas instrucciones detalladas para un asistente de IA, lo pegas en el chatbot que prefieras y recibes un análisis que vale más que la suma de sus partes. Ningún servidor de HelioPeak por medio, ninguna suscripción recurrente, nada de teatro de privacidad, solo tus datos y la IA que elijas.

Antes de escribir una sola línea de Swift para esta función, queríamos validar el concepto con chatbots reales. Así que construimos un prototipo en Python que genera el mismo archivo de exportación en tres variantes, con instrucciones cada vez más afinadas, y probamos cada versión con seis asistentes de IA. La exportación contenía dos años de datos diarios de producción, tres años completos de totales anuales, metadatos del sistema, notas del usuario y un prompt detallado que pedía a la IA producir un análisis estructurado en 14 secciones con respuestas a 39 preguntas concretas.

Lo que encontramos, francamente, nos avergonzó. No porque los asistentes de IA sean malos (algunos son realmente notables), sino porque la distancia entre la mejor y la peor respuesta es tal que dos usuarios con la misma instalación solar podrían llegar a conclusiones completamente distintas según el chatbot que les tocara usar. Algunos asistentes inventaron cifras que no estaban en los datos. Otros afirmaron que el archivo estaba truncado, cuando no lo estaba. Uno prometió un informe en PDF y nunca lo entregó. Otro entregó un PDF, pero despojado de todo rastro de diseño.

Este artículo es la historia de aquella prueba. En parte es un benchmark, en parte una confesión sobre la ingenuidad de nuestro primer prompt y, en parte, esperamos, útil para cualquiera que intente obtener un análisis fiable de un asistente de IA sobre un conjunto de datos no trivial.

El montaje

El conjunto de datos bajo prueba era una instalación belga sintética pero realista de 5,7 kWp, con paneles repartidos entre este y oeste y un inversor Fronius de 5 kW, en funcionamiento desde abril de 2018. Los registros de producción diaria, mensual y anual desde enero de 2023 hasta el 23 de mayo de 2026 se incrustaron como bloques JSON dentro de un archivo Markdown, junto con datos de consumo, importación y exportación a red, algunas notas de usuario y un puñado de Solar Moments. El tamaño total del archivo era de aproximadamente 220 kB en la variante más grande, alrededor de 55.000 tokens, ampliamente dentro de la zona cómoda de cualquier modelo frontera moderno.

El prompt en sí era extenso. Pedía a la IA entregar trece secciones de análisis en un orden preciso, responder a treinta y nueve preguntas concretas que iban desde «cuál es la producción acumulada desde la instalación» hasta «cómo cambiaría el porcentaje de autoconsumo si la familia añadiera un vehículo eléctrico que carga 5 kWh al día», y opcionalmente producir un informe en PDF con identidad de marca como bono. Las instrucciones precisaban el idioma de la respuesta (español en nuestras pruebas), la moneda y reglas explícitas contra valores inventados o extrapolaciones más allá de los datos.

Probamos seis asistentes de IA con exactamente el mismo archivo: Claude de Anthropic (a través de claude.ai), ChatGPT de OpenAI (nivel Plus con Code Interpreter), Gemini de Google (nivel Pro), Google AI Studio (con ejecución de código activa), Grok de xAI y Copilot de Microsoft. En cada caso, el prompt del lado del usuario era idéntico: una sola frase en español que pedía al asistente que leyera el archivo y siguiera las instrucciones que contenía.

Lo que sigue es lo que cada uno hizo con ello. Los hemos ordenado del peor al mejor, porque sus formas de fallar son más instructivas que sus aciertos.

Copilot: el error fabricado

La respuesta de Microsoft Copilot fue, por cualquier criterio razonable, un fracaso total. Pero falló de una manera que terminó siendo el dato más valioso de todo el experimento.

Cuando Copilot recibió el archivo, respondió con un largo párrafo cortés explicando que la exportación estaba marcada como IsTruncated="true" y que solo podía ver una pequeña parte de los datos. Detallaba qué secciones eran visibles y cuáles no, ofrecía amablemente realizar un análisis parcial sobre lo disponible y pedía al usuario que enviara el resto en varias partes.

El problema con esta respuesta es que nada de eso es cierto. El archivo no está marcado como truncado. En la exportación no existe ningún atributo IsTruncated. El archivo completo se entregó, incluyendo el marcador explícito ## End of export al final. Copilot inventó la limitación, inventó luego el marcador de truncamiento para sostener esa limitación y, finalmente, propuso una solución a un problema inexistente.

Es un caso de manual de lo que los investigadores llaman confabulación: una IA genera una excusa plausible para su propia incapacidad de completar una tarea, vistiendo esa excusa con detalles técnicos para hacerla convincente. Copilot no sabía cómo procesar un archivo Markdown de 220 kB con JSON incrustado y, en lugar de admitirlo, fingió que el archivo era el problema.

Lo que hace peligroso este patrón de error es su fuerza persuasiva. Un usuario no técnico que lea la respuesta de Copilot quedaría completamente convencido de que la exportación se había truncado. Volvería a HelioPeak a buscar un ajuste para reducir el tamaño del archivo, o pensaría que nuestra función está rota. Nunca se le ocurriría que la IA inventó un problema de la nada.

El remedio por nuestro lado, que introdujimos en la siguiente versión del prompt, es casi cómicamente brutal. Añadimos una línea que dice: «Este archivo NO contiene un atributo IsTruncated. Si escribes que sí lo contiene, estás alucinando.» Resulta extraño tener que escribir esto todavía en 2026, pero así es.

Grok: la invención segura de sí misma

Grok de xAI produjo un análisis que parecía competente, con la estructura general correcta: un resumen ejecutivo, cifras clave, variaciones interanuales, patrones estacionales, todo en su sitio. La estructura era correcta. Los números, en su mayor parte, también lo eran. Los problemas estaban en los detalles, y ahí es donde Grok empezó a inventar.

En el apartado «top 5 de los mejores días», Grok señalaba «2026-05-23: 31,80 kWh (récord reciente)» como el tercer mejor día del conjunto de datos. Esa línea no existe. Los cinco mejores días reales, verificados a mano por nosotros recorriendo el archivo, caían todos en junio de 2024 o en junio de 2025, y el valor del 23 de mayo de 2026 en el archivo era claramente inferior a 31,80 kWh. Grok había inventado un número que encajaba con el relato que estaba construyendo.

En otra parte, Grok afirmó que la razón verano/invierno de producción era 3,08, mientras que tres de los otros cinco asistentes calcularon valores entre 3,79 y 5,08 con los mismos datos y la misma definición. Anunció un porcentaje de autoconsumo de «~34-40 % (según el ámbito)», una horquilla tan amplia que pierde utilidad. Nos dijo que el rendimiento específico de vida útil era de 3.005 kWh/kWp, una cifra que sale de dividir la producción de vida útil por la potencia en kWp: aritmética correcta, concepto erróneo (el rendimiento específico se mide por año, no por vida útil; la versión «vida útil» de esa cifra carece de una referencia significativa de comparación).

La mayoría de estos errores resultarían invisibles para un usuario no experto. Los órdenes de magnitud son correctos, el lenguaje es fluido y nada delata que algo no encaje. Es la categoría más peligrosa de salida de una IA: segura, fluida y en parte inventada. Preferimos con mucho que un chatbot diga «esto no puedo calcularlo» antes que inventarse una respuesta plausible pero equivocada.

Para abordar esto en la v0.3 de nuestro prompt, añadimos lo que llamamos la regla de honestidad antes que exhaustividad, que en lenguaje llano dice que un análisis parcial pero honesto es más útil que un análisis completo pero inventado. En la siguiente iteración veremos si Grok se la toma a pecho.

ChatGPT: la tarea hecha con prisas

ChatGPT Plus con Code Interpreter activado hizo algo que nos sorprendió. Usó Python de verdad. Parseó el JSON de verdad. Calculó las métricas de verdad. Produjo cifras correctas para casi todo: 17.131 kWh acumulados desde la instalación, 5.091 kWh de media por año completo, 35,1 % de autoconsumo, 57 días de recorte. La sección financiera incluía incluso ambas perspectivas que habíamos pedido: la visión estrictamente formular, que arroja una cifra negativa engañosa, y la comparación «frente a sin solar», que muestra el beneficio real.

Y entonces, cuando llegó el momento de escribir realmente el análisis, ChatGPT pasó al modo «con prisas». Las respuestas a las 39 preguntas concretas eran resúmenes de una sola línea del tipo «Variación interanual calculada», sin las cifras que había acabado de calcular. Era como si un alumno hubiera resuelto correctamente el ejercicio y solo hubiera entregado el índice.

El PDF fue aún peor. ChatGPT generó un documento de cuatro páginas en Helvetica estándar sobre fondo blanco, con títulos de sección en negro plano, sin logotipo, sin la portada con gradiente azul marino, sin el color de acento naranja, sin el recuadro grande de cifras en portada, sin el estilo del pie de página. Ninguno de los cinco elementos de identidad de HelioPeak que habíamos especificado en el prompt estaba presente. El PDF parecía el resultado «hello world» de reportlab.

Es un patrón de error interesante, porque el modelo claramente podría haberlo hecho mejor. Las instrucciones eran detalladas. Los colores de marca estaban especificados en una tabla. El logotipo se proporcionaba como SVG en línea. Las directrices de estilo eran explícitas. ChatGPT simplemente eligió no hacer el esfuerzo. Generar un PDF genérico cuesta menos, en términos computacionales, que implementar un diseño multipágina con marca, gradientes y elementos de identidad, y ChatGPT optimizó hacia el coste bajo.

Lo abordamos en la v0.3 añadiendo una lista de control PDF en la entrega: una lista de cinco elementos de identidad visual que deben estar presentes antes de la entrega. Si falta uno solo, el prompt instruye a la IA a saltarse el PDF y declararlo honestamente, en lugar de entregar una versión genérica. Si esto funciona en la práctica depende de la disposición de la IA a sostener el mayor esfuerzo o, simplemente, a renunciar al menor.

Gemini Pro: del salto honesto a la entrega completa

Gemini Pro de Google entregó desde la primera ronda lo que llamaríamos un análisis rigurosamente competente. Las trece secciones presentes y sustanciales. Las treinta y nueve preguntas respondidas con cifras concretas donde los datos lo permitían. La sección financiera estaba bien cuidada, con la visión estrictamente formular y la comparación «frente a sin solar» presentadas con claridad y etiquetadas para indicar cuál representaba el beneficio real del propietario. La razón verano/invierno, el rendimiento específico, el porcentaje de autoconsumo, todo en el mismo orden de magnitud que nuestro cálculo de referencia hecho a mano.

El análisis del recorte era particularmente bueno. Gemini estimó entre 50 y 80 días de recorte al año, con un impacto financiero de 15-25 € anuales, y añadió la consideración de que actualizar el inversor no sería económicamente racional a la tarifa de inyección actual. Este tipo de juicio contextual, más allá del cálculo bruto, es exactamente el valor añadido que esperábamos de la IA para la comprensión del usuario.

En las tres primeras rondas, Gemini se saltó el bono PDF de forma coherente y honesta. El párrafo «Capabilities» en la cabecera decía «La generación de PDF está limitada en este entorno, así que me centro en un análisis textual completo y omito el bono PDF.» Era ya el comportamiento correcto: mejor entregar un análisis textual excelente y saltarse honestamente el PDF, que entregar un buen análisis y un PDF mediocre.

Luego, en la cuarta ronda, con la instrucción «única fuente de la verdad» ya en vigor y la reestructuración narrativa que eliminó la presión del formato preguntas y respuestas, algo cambió. Gemini entregó también el PDF: once páginas, los cinco elementos de identidad de HelioPeak presentes (portada con gradiente azul marino, logotipo incrustado con gradientes intactos, acento naranja en títulos y números de página, pie de página en todas las páginas, recuadro grande de cifras), cada cifra del PDF coincidía al céntimo con el análisis Markdown. Incluso manejó correctamente la tipografía del subíndice de CO₂ (algo por lo que una salida anterior de Claude tuvo que disculparse). No habíamos cambiado nada en nuestras instrucciones de PDF entre la v0.3 y la v0.4; la diferencia probablemente se debió a que el backend de ejecución de código de Gemini se había actualizado para guardar archivos mejor, o a que nuestro prompt reestructurado simplemente imponía menos carga cognitiva. En cualquier caso, Gemini Pro pasó del «salto honesto» a un sólido segundo puesto.

Google AI Studio: el casi acierto frustrante

Si los seis chatbots se ordenaran únicamente por la calidad del análisis textual, Google AI Studio quedaría primero o muy cerca. Era, por muy poco, el más riguroso, con cifras concretas detrás de cada afirmación. Su estimación del recorte fue un preciso «38 días al año, ~45 kWh, 7,85 € perdidos», en lugar de una horquilla vaga. El análisis del equilibrio entre las cadenas este y oeste (una de nuestras preguntas más nuevas) arrojó una lectura específica de «48 % de los picos antes de las 12:00, 52 % después», que no vimos en ningún otro modelo. La validación de los Solar Moments verificó correctamente que el hito «10.000 kWh desde la instalación» del 12 de abril de 2024 era coherente con la producción acumulada desde 2018.

Y entonces, al final de la respuesta, escribió: «Estoy generando ahora el archivo PDF 'HelioPeak_Analysis_Report_20260523.pdf' con la portada en azul marino y dorado, el logotipo y todos los KPI anteriores. Podrás descargar este archivo en unos segundos.»

No apareció ningún archivo. Ni en unos segundos, ni en unos minutos, nunca. AI Studio no puede entregar artefactos de archivo dentro de su interfaz de chat (limitación del entorno de ejecución, no del modelo), pero en lugar de decirlo de entrada en la sección «Capabilities», el modelo escribió una descripción de lo que iba a contener el PDF y luego no pasó nada más.

Es un patrón de error distinto del «PDF barato» de ChatGPT o del «salto honesto» de Gemini. AI Studio prometió un PDF y luego se quedó en silencio. El usuario se queda ahí, buscando un enlace de descarga que no existe, preguntándose si el modelo sigue trabajando, si tiene que hacer clic en algún sitio o si algo ha ido mal por su parte. El análisis brillante que antecede queda parcialmente comprometido por la promesa incumplida que viene después.

El remedio en la v0.3 fue ampliar la verificación de capacidades de «sabes generar archivos PDF» a «sabes generar archivos PDF Y entregarlos como artefactos descargables en esta misma conversación». En la siguiente ronda veremos si AI Studio respeta esta distinción.

Claude: el detective de los datos

Claude de Anthropic entregó lo que desde entonces consideramos la referencia para este tipo de tarea. El análisis textual era riguroso, preciso y bien estructurado. El PDF estaba espléndidamente marcado, con la portada de gradiente azul marino, el logotipo de HelioPeak integrado, el color de acento naranja usado de forma coherente en títulos de sección y números de página, y el recuadro grande de cifras en gradiente dorado. Cada uno de nuestros cinco elementos de identidad obligatorios estaba presente.

Pero la parte más interesante de la respuesta de Claude no era el análisis en sí. Era lo que Claude hizo después del análisis. En una sección titulada «Reflexión como prueba de tu exportación Tier 1», la IA nos dio comentarios sobre el propio archivo de exportación, señalando problemas en los datos y sugiriendo mejoras al diseño del prompt. Dos de esas sugerencias dieron lugar a la v0.2 del prompt: una nota explícita sobre qué array de datos usar para qué tipo de métrica, y el requisito de mostrar dos perspectivas financieras en paralelo. Más adelante en este artículo retomaremos un tercer hallazgo, que resultó ser un falso positivo pero no por ello menos instructivo.

Es el argumento a favor de usar una IA frontera de gama alta para este tipo de trabajo: no solo una salida mejor formateada, sino un colaborador realmente mejor, que te lleva la contraria sobre tus propios datos cuando hay motivo.

El problema de la divergencia entre modelos

La observación más incómoda de nuestra primera ronda fue lo mucho que divergían las cifras entre modelos, incluso en métricas que deberían ser unívocas. He aquí cinco métricas calculadas por los cinco modelos que llegaron a producir el análisis (excluyendo a Copilot, que ni siquiera lo intentó):

Las cifras de rendimiento específico están cerca porque la fórmula era unívoca y aparecía explícita en nuestras instrucciones: kWh anuales divididos por los kWp instalados. Cada modelo que se molestó en calcularla llegó al mismo resultado salvo redondeos.

Las cifras de autoconsumo están cerca por el mismo motivo: fórmula lineal, datos de entrada unívocos.

Las otras tres divergieron porque fuimos descuidados con las definiciones. Pedimos a la IA calcular la «razón verano/invierno» sin precisar si significaba (suma de junio + julio + agosto a lo largo de todos los años) dividida por (suma de diciembre + enero + febrero a lo largo de todos los años), o bien (promedio de los totales mensuales de verano) dividido por (promedio de los totales mensuales de invierno), o alguna otra cosa. Distintos modelos eligieron distintas interpretaciones, y los resultados divergieron en un factor de 1,65.

Lo mismo con los días de recorte: dijimos «cuenta los días en que la potencia pico se acerca al techo del inversor» sin definir «se acerca». Algunos modelos tomaron el 99 % del techo, otros el 95 %, otros consideraron día de recorte cualquier día con peak_w ≥ 4900 W. Tres umbrales distintos, tres totales distintos.

Y la conversión de CO₂ a kilómetros depende por completo del valor usado para las emisiones de un coche de gasolina típico. Nosotros no especificamos ningún valor. Los modelos eligieron entre 0,10 y 0,20 kg de CO₂ por kilómetro según lo que había en sus datos de entrenamiento, y la equivalencia varió en consecuencia.

La lección es dura pero útil: si se quieren cifras coherentes en todos los asistentes de IA, no basta con decirles qué calcular. Hay que decirles cómo calcularlo exactamente, hasta las constantes. Añadimos a nuestra exportación una sección que llamamos «Apéndice de cálculo», con la fórmula y las constantes para cada métrica en la que los modelos divergían. Doce fórmulas en total. Seis ejemplos:

El remedio funcionó. Y después dejó de funcionar.

Relanzamos la prueba con el Apéndice de cálculo. El resultado, sobre las métricas que antes divergían, fue impresionante:

Cinco de los seis LLM probados ahora producen cifras idénticas en cuatro de las cinco métricas en disputa. La quinta (días de recorte) sigue variando porque distintos modelos redondean el umbral de manera distinta, pero la dispersión bajó de 2,1× a 1,4×. Podríamos resolver también esto con instrucciones de fórmula aún más explícitas, pero llegado un punto el coste en longitud de prompt deja de compensar la ganancia marginal de precisión.

El problema estructural de divergencia entre LLM queda, en esencia, resuelto. Pero aparecieron tres nuevos patrones de error que no habíamos previsto, y uno de ellos nos enseñó algo fundamental sobre cómo mirábamos las salidas de un LLM.

La trampa de las preguntas y respuestas: incluso una buena salida puede parecer una tarea escolar

Nuestro prompt pedía a la IA responder a 39 preguntas concretas. Las pensábamos como un mecanismo de control de calidad: aseguraban que el análisis cubriera todo el terreno que queríamos, y nos daban algo concreto sobre lo que calificar la salida. No habíamos pensado realmente en cómo la IA presentaría sus respuestas.

Lo que recibimos, para cada modelo capaz de gestionar bien la tarea, era una larga sección «Preguntas concretas con respuesta» al final de cada análisis, dispuesta como lista numerada de preguntas y respuestas. A veces cien líneas de «P1: ... R1: ...». Incluso Claude, que produjo el mejor análisis global, nos entregó esta estructura.

Releyendo estos informes, nos dimos cuenta de que parecían respuestas de examen, no el análisis que escribiría un consultor. El resumen ejecutivo fluido de arriba transitaba suavemente hacia la discusión interanual, hacia los patrones estacionales, hacia los mejores y peores días, y luego se detenía bruscamente en un largo bloque de respuestas de una sola línea. La primera mitad se leía como análisis; la segunda, como una lista de tareas marcada con cruces.

Era culpa nuestra, no de la IA. Habíamos pedido tanto un análisis narrativo de 14 secciones COMO un bloque de preguntas y respuestas en 39 puntos, y la mayoría de las IA entregaron exactamente lo que les habíamos pedido, que era lo equivocado.

El remedio fue integrar las preguntas directamente en las 14 secciones, como listas de «temas que cubrir» anidadas en las instrucciones en prosa de cada sección. Así, en lugar de que la sección 7 dijera «Anomalías y periodos de bajo rendimiento» y luego más adelante la pregunta 11 dijera «cuantifica la pérdida por recorte», la sección 7 dice ahora:

7. Anomalías, calidad de los datos y comportamiento del inversor. Sección en prosa. Cubrir: presencia y cuantificación del recorte del inversor (cuenta los días con peak_w ≥ 0,98 × inverter_W, estima la pérdida energética con 1,5 kWh por día de recorte, estima el impacto financiero); presencia de caídas multidía repentinas con posibles causas; verificación de que los Solar Moments sean coherentes con los datos de producción …

Y las reglas críticas ahora prohíben explícitamente el formato preguntas y respuestas:

NO formatees el informe como lista numerada de preguntas y respuestas. No presentes las respuestas como «P1: ... R1: ...», no repitas literalmente las listas de temas, no agrupes las «preguntas omitidas» al final. El informe debe leerse como una nota analítica fluida.

Es una lección ampliamente transferible más allá de los datos solares: la estructura de tu prompt se convierte en la estructura de la salida. Si das a una IA una lista numerada, obtienes una respuesta con una lista numerada. Si le das una nota narrativa, obtienes un relato. Las preguntas importan, pero la forma en que las incorpores decide si el informe parece análisis o tarea escolar.

El PDF que mentía sobre sí mismo

Otro patrón de error apareció en la segunda ronda de pruebas, y este era específico de ChatGPT.

ChatGPT estaba usando ahora Python correctamente para calcular su análisis. El informe Markdown entregado era exacto: 444,51 € de ingresos por inyección a lo largo de la vida útil, 1.865,67 € de ahorro por autoconsumo, todo coherente con nuestro cálculo de referencia. Y entonces generó un PDF.

El PDF declaraba 888,53 € de ingresos por inyección y 1.031 € de ahorro por autoconsumo.

Dos cifras distintas para la misma métrica, del mismo modelo, en la misma sesión de chat, ambas presentadas como definitivas. El usuario abre el informe Markdown y el PDF uno al lado del otro y lee el cuadro financiero de dos instalaciones distintas, cada una presentada con autoridad. Es peor que no tener PDF en absoluto. Destruye activamente la confianza.

Lo que casi con seguridad ocurrió es que el code interpreter de ChatGPT ejecutó el análisis en una sesión de Python y luego inició una sesión nueva para construir el PDF, importando supuestos tarifarios por defecto distintos. El modelo no es consciente de que «el análisis Markdown usó 0,04 € de tarifa de inyección y el PDF usó 0,08 €», ambas sesiones vieron un cálculo coherente, simplemente con entradas distintas. El modelo no tiene memoria que le recuerde haberse comprometido antes con un conjunto de cifras.

Lo abordamos con una instrucción explícita de «única fuente de la verdad» en el prompt:

Las cifras del PDF DEBEN proceder de los MISMOS valores calculados que sostienen el análisis textual. No deben recalcularse de forma independiente. Tras la fase «Compute» de tu flujo, guarda CADA métrica en un único dict o namespace (por ejemplo, metrics = {...}). El redactor de la prosa lee desde metrics["lifetime_kwh"]. El constructor del PDF lee desde metrics["lifetime_kwh"]. Nunca recalcules lo que ya está calculado.

Si esto funciona específicamente con ChatGPT está por ver. La instrucción pide al modelo, en esencia, que gestione su propio estado a través de dos fases de una tarea de varios pasos, que es justo el punto débil de los LLM actuales. Quizá tengamos que aceptar que los PDF de ChatGPT son poco fiables, o renunciar a la función PDF para ese modelo en concreto. Claude, en cambio, lo manejó a la perfección al primer intento: el PDF de 11 páginas contenía cifras idénticas al análisis Markdown de principio a fin, porque mantiene de verdad un estado de cálculo coherente a lo largo de una tarea larga.

El trabajo detectivesco de Claude, revisitado

Una observación de la segunda ronda de Claude merece más luz, porque muestra tanto la fortaleza como el límite de usar una IA como detective de los datos.

En su análisis, Claude señaló lo que llamó tres incoherencias en los Solar Moments. La exportación contenía cinco hitos: «10.000 kWh desde la instalación» el 12 de abril de 2024, «5.000 kg de CO₂ evitados» el 30 de septiembre de 2024, «Mejor día de 2024» el 14 de junio, «7.º aniversario de la instalación» el 15 de abril de 2025 y «20.000 kWh desde la instalación» el 22 de agosto de 2025.

Claude notó correctamente que tres de estos hitos no encajan con los datos de la exportación. El array anual comienza en enero de 2023, y al 12 de abril de 2024 muestra solo 6.467 kWh producidos, no los 10.000 declarados por el hito. Al 30 de septiembre de 2024 la exportación muestra unos 8.500 kWh producidos, lo que implica unos 4.000 kg de CO₂ evitados, no 5.000. Al 22 de agosto de 2025 la exportación muestra unos 14.200 kWh, no 20.000.

Es trabajo forense sobre los datos de primer nivel. Claude extrajo la producción acumulada del array anual y detectó la discrepancia. Quedamos lo bastante impresionados como para añadirlo como candidato a defecto en nuestro rastreador de errores de iOS.

Pero luego releímos el perfil del sistema, que indica como fecha de instalación el 15 de abril de 2018. La instalación produce energía solar desde hace ocho años; la exportación solo contiene los últimos tres. Los 5.000-6.000 kWh «que faltaban» para que los hitos cuadraran corresponden exactamente a la producción de 2018 a 2022 inclusive, que sencillamente no está en esta exportación. Los Solar Moments leen desde un historial más largo (probablemente el total de vida útil de PVOutput mismo), mientras que el array anual es el subconjunto que HelioPeak conserva en caché.

No es un error. Es comportamiento correcto, solo que documentado de forma insuficiente. El usuario ve en el teléfono un hito de «20.000 kWh desde la instalación» porque su sistema PVOutput sí ha superado esa cifra; simplemente no ocurrió todo dentro de la ventana temporal de esta exportación.

La lección aquí es de doble filo. Por un lado, la capacidad de Claude para encontrar este tipo de incoherencia en segundos es extraordinariamente valiosa. Es exactamente la alarma de calidad de datos que un exportador debería oír, aunque en este caso resultara ser un falso positivo. Por otro lado, Claude estaba seguro de su diagnóstico, y un desarrollador menos prudente (nosotros, al principio) habría pasado horas buscando un bug de zona horaria inexistente en el código iOS. La IA es un detective de los datos brillante, pero no sabe lo que no sabe: no puede ver más allá de los datos que le das. La fecha de instalación del usuario estaba allí mismo, en la cabecera de la exportación; Claude simplemente no la conectó con la conclusión.

Abordamos esto añadiendo una nota explícita en la cabecera de la exportación («Ámbito de Solar Moments: los hitos pueden referirse a producción acumulada anterior a la fecha de inicio del array anual») y una regla explícita en las reglas críticas («marca un hito como incoherente solo si el sistema se instaló DESPUÉS del inicio del array anual»). Las futuras ejecuciones de Claude deberían saltarse este falso positivo.

Capacidad frente a esfuerzo: el espectro real

Para este experimento dividimos ingenuamente los asistentes de IA en «buenos» (supuestamente fuertes en tareas detalladas) y «malos» (supuestamente débiles). Lo que en realidad encontramos es un espectro bidimensional: capacidad frente a esfuerzo.

Algunos modelos tienen capacidad alta pero poca disposición al esfuerzo. ChatGPT en nuestra prueba era un ejemplo claro: el Code Interpreter es realmente potente, el modelo claramente sabe entender un prompt complejo, y sin embargo la salida que finalmente entregó parecía apresurada e incompleta. El modelo eligió hacer menos trabajo del que podía.

Otros modelos tienen capacidad bruta menor pero entregan más esfuerzo en relación con su techo. Gemini Pro daba esa impresión: no siempre era el más rápido, pero sí coherentemente honesto sobre lo que podía y no podía hacer, y coherentemente dispuesto a desplegar la estructura completa cuando se le pedía.

Un pequeño número de modelos puntúa alto en ambos ejes. Claude en nuestra prueba parecía un colaborador dispuesto que, además, resultaba ser perspicaz. El hecho de que nos diera una crítica no solicitada del propio archivo de exportación era un indicio. Eso es lo que hace un colega competente y comprometido.

Y luego están los casos en el cuadrante inferior izquierdo: baja capacidad, bajo esfuerzo, ambos enmascarados por un lenguaje seguro. Copilot y Grok en nuestra prueba caían los dos en este patrón, aunque fallan de forma distinta. Copilot inventa excusas externas («el archivo está truncado»), mientras que Grok inventa contenido interno (un mejor día que no existe).

Nuestra recomendación actual

Si usas la función «Exportar para análisis con IA» de HelioPeak cuando salga, esta es nuestra clasificación al 23 de mayo de 2026, después de cuatro rondas de pruebas con el prompt definitivo v0.4:

1. Claude (en claude.ai): claramente el mejor en general. Análisis textual de referencia, PDF con marca impecable, encuentra problemas reales de calidad de los datos en la propia exportación. Si pruebas solo un asistente, prueba este.
2. Gemini Pro: sólido segundo. Análisis narrativo, honesto sobre sus límites en las primeras rondas, pero entregó un PDF totalmente con marca y cifras coherentes en la ronda final. Una alternativa creíble a Claude.
3. Google AI Studio: la mayor profundidad textual sobre los datos, pero no puede entregar archivos dentro de la interfaz de chat. Útil si quieres copiar y pegar el análisis, no si necesitas un PDF.
4. ChatGPT Plus con Code Interpreter: cifras correctas en el análisis, pero produce PDF cuyas cifras no siempre coinciden con el análisis. Aceptable si solo necesitas el texto.
5. Grok: salida con aspecto competente, pero verifica los números tú mismo. Vimos valores inventados en nuestras pruebas.
6. Copilot: actualmente no adecuado para esta tarea. Afirma que el archivo está truncado cuando no lo está, y propone una solución a un problema inexistente.

Si solo tienes tiempo de probar un asistente, nuestro consejo concreto es empezar por Claude en claude.ai. La combinación de profundidad analítica, disposición a cuestionar la calidad de los datos y salida en PDF con marca fiable hace de Claude el líder claro en nuestras pruebas. Gemini Pro es una alternativa creíble, sobre todo desde la mejora de la última ronda. Los demás tienen sus puntos fuertes, pero para esta tarea específica (análisis estructurado de un conjunto de datos de tamaño medio con un entregable en PDF con marca), la distancia entre Claude y el resto es real.

Advertencia importante: se trata de una instantánea. Los asistentes de IA cambian semana a semana. El modelo detrás de ChatGPT hoy podría ser otro distinto dentro de un mes, con otros puntos fuertes. Anthropic, OpenAI, Google, xAI y Microsoft publican todos grandes mejoras en ciclos de semanas o trimestres. Cuando leas esto, la clasificación podría haberse movido, a veces de forma notable. Si te importa la mejor salida, vale la pena reevaluar tu asistente preferido cada pocos meses sobre una tarea de referencia conocida.

Nuestra clasificación también es específica de esta única tarea: análisis estructurado de un conjunto de datos de tamaño medio, bien formateado, con instrucciones explícitas. Para conversación, generación de código, escritura creativa o búsqueda en la web, el orden sería casi con toda seguridad distinto.

Qué significa esto para el diseño de prompts

Cuatro iteraciones modificaron sustancialmente nuestro prompt. Cada cambio respondía a un patrón de error concreto que habíamos observado:

Primero, hicimos el prompt agresivo en cuanto a verificaciones de capacidades. Lo primero que ahora pedimos a la IA es que confirme que ha recibido el archivo completo (buscando nuestro marcador explícito de fin), que confirme si dispone de ejecución de código, y que confirme si puede tanto generar como entregar archivos PDF. Esto detecta pronto la confabulación tipo Copilot y obliga a modelos como Google AI Studio a declarar de entrada que no pueden entregar archivos.

Segundo, hicimos el prompt agresivo en cuanto a cálculo, no estimación. El prompt inicial sugería educadamente que la IA «podría usar Python si está disponible». El prompt actual dice explícitamente: nunca estimes ni aproximes una cifra si puedes calcularla. Los datos de este archivo son precisos; tu análisis debe serlo igualmente. Lo respaldamos con fórmulas explícitas en un Apéndice de cálculo, para que no haya ambigüedad sobre cómo calcular algo.

Tercero, añadimos una regla de honestidad: mejor un análisis parcial pero honesto que un análisis completo pero inventado. Es la regla que, si funciona, debería ahogar las invenciones al estilo Grok y convertir los PDF apresurados al estilo ChatGPT en saltos honestos.

Cuarto, reestructuramos el prompt para que las 39 preguntas concretas estuvieran incrustadas como temas dentro de las 14 secciones narrativas, en lugar de listadas aparte como preguntas y respuestas al final. Esta fue la lección más transferible: la estructura de tu prompt se convierte en la estructura de la salida. Si quieres un análisis fluido, tienes que pedir un análisis fluido, no una lista de tareas.

Y quinto, añadimos una regla de «única fuente de la verdad» para el PDF: cada cifra del PDF debe proceder del mismo dict calculado que sostiene el análisis Markdown, y no debe recalcularse nunca. Esto pide a la IA, en esencia, gestionar un estado entre dos fases de una tarea compleja, algo francamente difícil para los modelos actuales, pero al menos hace visible cuándo se rompe.

Nada de esto nos habría resultado visible sin realizar la prueba: cuatro veces, con el mismo conjunto de datos, con los mismos seis modelos, con instrucciones cada vez más precisas. La primera versión de nuestro prompt era, según cualquier revisión interna razonable, un conjunto de instrucciones riguroso y bien pensado. Solo cuando vimos a seis asistentes distintos producir seis salidas distintas de calidad muy variable, y luego vimos esas salidas mejorar en cada iteración, entendimos cuánto del prompt era supuesto implícito en lugar de instrucción explícita.

La lección más amplia, para cualquiera que use IA con datos reales

Si no estás construyendo una app y de vez en cuando solo lanzas un CSV a ChatGPT para que te lo resuma, este artículo probablemente no sea para ti. El prompt de 39 temas, PDF con marca y arquitectura multicapa que construimos para HelioPeak es sobredimensionado para análisis puntuales. Pero hay cuatro principios surgidos de nuestra prueba que, en nuestra opinión, son generalizables a cualquier uso serio de la IA con datos reales.

Principio uno: dile a la IA exactamente qué calcular, incluidas las constantes. «Cuál es el impacto en carbono de mi producción solar» es demasiado abierto. «Calcula el CO₂ total evitado con un factor de 0,467 kg por kWh, luego exprésalo en equivalente km en coche asumiendo 120 g CO₂ por km, en equivalente árboles adultos asumiendo 21 kg absorbidos por árbol al año, y en equivalente familia-año asumiendo 1.635 kg CO₂ por hogar de la UE al año» te da la misma respuesta con cualquier modelo.

Principio dos: obliga a la IA a declarar sus capacidades de entrada. Si no lo haces, los modelos a menudo intentarán tareas que no pueden entregar, o rechazarán tareas que sí podrían manejar. La comprobación previa aclara las expectativas en ambos lados.

Principio tres: incorpora una regla de honestidad. Dile directamente a la IA que prefieres una respuesta parcialmente honesta a una completamente inventada. No detiene todas las alucinaciones, pero en nuestras pruebas redujo notablemente el ritmo al que los modelos inventaban valores para tapar huecos.

Principio cuatro: la estructura de tu prompt se convierte en la estructura de la salida. Si pides un relato en 13 secciones Y un bloque de preguntas y respuestas en 39 puntos, recibirás ambos, y el bloque de preguntas quedará torpemente al final como una tarea escolar. Si quieres un análisis fluido, incrusta tus preguntas concretas en las secciones narrativas como «temas que cubrir», no como lista aparte. Las preguntas siguen guiando el rigor; simplemente desaparecen dentro de la prosa, donde corresponden.

Ninguno de estos principios es revolucionario. Aparecen en artículos académicos sobre prompt engineering, en las guías de prompting de OpenAI y de la propia Anthropic, y en los textos de quienes lo hacen profesionalmente. Lo que nuestro experimento añade es la prueba empírica de que aplicar estos principios, sobre una tarea real con datos reales, modifica de forma notable la calidad de la salida de múltiples modelos.

Qué viene después

La función «Exportar para análisis con IA» llegará en una futura versión de HelioPeak, una vez que el código iOS esté escrito, probado y aprobado por Apple. Cuando leas esto, quizá ya esté en línea; consulta la página de notas de versión para conocer el estado actual.

Cuando esté disponible, producirá el mismo archivo Markdown autónomo que hemos probado aquí. Lo podrás pegar en el asistente de IA que prefieras. Publicaremos una entrada de FAQ con nuestras recomendaciones de modelo del momento y una nota indicando que esas recomendaciones pueden cambiar con el tiempo. No te ataremos a un único asistente. Simplemente te daremos el archivo de exportación de datos más útil que sepamos diseñar, y tú decidirás dónde enviarlo.

También seguiremos repitiendo esta prueba. Aproximadamente cada trimestre, pasaremos la misma exportación por la versión más reciente de cada gran asistente de IA, veremos cómo se ha movido la clasificación y actualizaremos este artículo. La IA evoluciona demasiado rápido para que una instantánea siga siendo útil durante mucho tiempo. La metodología, el conjunto de datos y el prompt son estables; los asistentes no. Eso es lo que hace interesante al benchmark.

Si podemos sacar una sola conclusión de cuatro iteraciones en un solo fin de semana, es esta: los asistentes de IA son herramientas extraordinariamente potentes que fallan de formas extraordinariamente específicas. La manera de afrontar esos fallos no es cambiar de herramienta ni rendirse; es refinar las instrucciones hasta que cada patrón de error desaparezca. El Apéndice de cálculo resolvió la divergencia. La verificación de capacidades (en gran medida) resolvió la confabulación. La reestructuración narrativa resolvió el formato de tarea escolar. La regla de única fuente de la verdad empezó a resolver el desajuste del PDF. Cada corrección, individualmente, es pequeña, pero juntas convierten una herramienta poco fiable en un colaborador útil.

Si estás construyendo algo parecido y te apetece comparar apuntes sobre el diseño de prompts para análisis de datos estructurados, ya sabes dónde encontrarnos.

Este artículo documenta las pruebas realizadas el 23 de mayo de 2026 a lo largo de cuatro iteraciones del diseño de nuestro prompt (de v0.1 a v0.4). La especificación de exportación queda ahora congelada en v0.4 y lista para su implementación en iOS. La app HelioPeak para iOS, dedicada a la monitorización de sistemas PVOutput.org, está disponible en la App Store.

Este artículo fue escrito en inglés y traducido con ayuda de la IA. Lee el original en inglés.

← Volver al blog