Un resumen de pensamiento de Gemini ayuda a seguir la respuesta, pero no acredita que sus datos sean correctos
La documentación distingue salida final y resúmenes opcionales. Un ejemplo ficticio muestra qué conviene comprobar fuera de esa explicación.
La documentación de Gemini distingue el resultado final de los resúmenes de pensamiento que pueden acompañarlo. La API devuelve por defecto solo la salida final y permite habilitar esos resúmenes. El documento también advierte de que un bloque de pensamiento puede no incluir un resumen: puede ocurrir con peticiones simples, cuando está desactivado o con ciertos contenidos, como imágenes.
Que falte ese texto no basta para concluir que una llamada falló. Y que esté presente tampoco verifica automáticamente el resultado. Proponemos leerlo como una explicación que orienta la revisión: qué supuestos parece utilizar, qué pasos merece comprobar y qué información externa sigue necesitando contraste. La documentación lo denomina resumen; aquí no se presenta como una auditoría exhaustiva de todos los procesos internos.
Un ejemplo inventado lo hace más concreto. Supongamos que una respuesta propone una visita un lunes y la explicación dice haber revisado el horario. La comprobación útil es abrir el horario del organizador, localizar la fecha y verificar si ese lunes abre. La frase que asegura haberlo revisado no sustituye ese contraste. Si la respuesta acierta el día pero utiliza una tarifa antigua, la revisión debe detectar ese segundo dato por separado.
Para guardar una prueba revisable, puede conservarse la pregunta, la versión del modelo, la respuesta final, el resumen si existe y las fuentes efectivamente consultadas. Después se anota qué afirmación se comprobó y con qué resultado. No hemos ejecutado una llamada ni medido el rendimiento de Gemini para este artículo: explicamos cómo distinguir la información disponible de la evidencia necesaria. La longitud de una explicación no es una tasa de acierto.