¿Por qué Fishtesting prueba Stockfish contra sí mismo, no con otros motores?

Según entiendo el llamado Fishtesting , las personas escriben parches y luego prueban los parches con la versión actual de Stockfish. Si la nueva versión funciona mejor, se promociona para ser la versión principal; de lo contrario es rechazado.

Pregunta: ¿por qué probar contra la versión actual de Stockfish? Funcionó en el pasado, y el Stockfish actual es mucho más fuerte que el Stockfish de dos años. Sin embargo, también podemos ver limitaciones a este enfoque. Aunque Stockfish ahora es capaz de destruir completamente otros motores tradicionales, también perdió recientemente la superfinal TCEC S15 contra Leela. Por lo tanto, ¿por qué no probar cada nueva versión contra Leela?

La respuesta obvia es que los recursos de Fishtesting provienen de las CPU y Leela es horrible con la CPU. Sin embargo, eso no debería ser fatal: uno podría darle a Leela más tiempo, por ejemplo, con Stockfish ejecutándose en 10 segundos por juego, darle 100 segundos a Leela por juego o las probabilidades de tiempo necesarias para obtener la relación de Leela en la superfinal. Esto ciertamente disminuirá la velocidad de Fishtesting, pero si conduce a un motor que pueda vencer a Leela en un partido, aún podría valer la pena.

En primer lugar, lo que no queda claro a partir de otras respuestas es que, por supuesto, en principio puede usar cualquier oponente (con una fuerza de juego constante) para comparar la fuerza de juego de dos versiones de un programa.

Sin embargo, hay varias buenas razones para probar las versiones directamente entre sí, independientemente de si está desarrollando Stockfish o cualquier otro motor:

• La comparación de la fuerza de juego de las entidades de ajedrez generalmente no cumple la transitividad, es decir, si A> B y B> C, A <C todavía es posible. Por lo tanto, siempre que una comparación contra un gran grupo de oponentes (para promediar el problema de transitividad) no sea factible, una comparación directa debería ser la medición más confiable, aunque, por supuesto, puede tener el mismo problema para tres versiones de un programa único
• Al hacer una comparación directa, reduce el número requerido de juegos en las pruebas, porque solo necesita ejecutar un partido en lugar de dos, y al mismo tiempo obtiene barras de error más pequeñas para la diferencia de fuerza de juego.
• La prueba contra un oponente de (casi) igual fuerza maximiza la sensibilidad estadística de un solo resultado del juego, por lo que nuevamente ahorra costos de hardware. Si la diferencia en la fuerza de juego es muy alta, la información / entropía de un solo juego es muy baja.

Además, en el caso de fishtest / Stockfish hay varias razones concretas por las que elegir una comparación directa fue la opción más basada en principios:

• En el momento en que se desarrolló inicialmente fishtest, Leela no estaba disponible.
• El uso de motores comerciales como Komodo y Houdini era / no es una opción debido a problemas de licencia.
• El uso de otros programas puede presentar riesgos de seguridad, así como dependencias de software adicionales o requisitos de hardware que desea evitar en un entorno informático distribuido.
• Antes de Leela, básicamente no había un motor de código abierto que fuera lo suficientemente fuerte como para obtener resultados estadísticamente significativos cuando se compara con Stockfish.

El objetivo de la prueba de peces es probar si una nueva versión de Stockfish se ha fortalecido . La definición de más fuerte es que supera a su versión anterior.

No estoy seguro de cómo ayudaría probar cada nueva versión contra un motor como Leela. Su idea podría ser solo aceptar una nueva versión de Stockfish si funciona mejor contra Leela que la versión anterior de Stockfish. Así que ahora se garantiza que cada versión de Stockfish jugará mejor contra Leela, pero no se garantiza que sea un mejor jugador de ajedrez en general. La razón es que Stockfish podría confiar en ciertas características en el juego de Leela para ganar más juegos.

EDITAR: pensé en un ejemplo que podría ayudar aquí. Supongamos que obtuviste 1500 hace unos años, y ahora tienes 1800. Si jugaste tu mismo pasado en un partido, está claro que ganarías. Pero en aras de la discusión, es posible que su 1500-self funcione mejor contra Kasparov que su 1800 self actual. Quizás el 1500-self fue menos conservador y tomó muchos más riesgos. Esto se las arregla para vencer a Kasparov en un juego raro, mientras que tu 1800 actual perderá cada vez (sin embargo, los juegos estarían un poco más cerca en promedio).

Estoy de acuerdo en general con @inertialignorance pero me gustaría aclarar un poco la posición.

Cuando los humanos juegan humanos, el resultado de un juego es relativamente insignificante, dada la extrema variabilidad del juego humano. (Usaré Kasparov v Deep Blue como un ejemplo de esa variabilidad; en un buen día , probablemente podría haber derrotado a Kasparov en el juego que cometió un error contra DB). Así que ignoremos a la humanidad en esto y concentrémonos en la máquina.

Las máquinas juegan a un nivel de habilidad mucho más consistente que los humanos. Por lo tanto, un solo juego significa más y una serie de juegos significa mucho. Por lo tanto, tiene sentido probar la mejora propuesta de Stockfish contra una máquina. ¿Pero por qué Stockfish?

Simplemente porque no hay forma de cuantificar "funciona mejor contra Leela" de manera significativa. Podría hacerlo mejor y aún perder. Pero, ¿cuál es el estándar para mejorar, en ese caso? ¿Cómo demuestras que jugó mejor? No puedo ver un estándar viable.

Es mucho más simple demostrar que Stockfish prime es una mejora con respecto a Stockfish original simplemente jugando un conjunto de juegos y contando los resultados.

Edward Deming sostuvo que era de suma importancia elegir la métrica correcta, porque solo sabe que mejora debido a lo que mide. Entonces haga la pregunta: ¿Cuál es el propósito del proceso? ¿Por qué propone un parche para Stockfish?

¿Es realmente el objetivo final del parche para vencer a Leela? ¿O es más bien para hacer que Stockfish juegue mejor ajedrez? Yo diría que es lo último. Vencer a Leela vendrá por sí solo si solo Stockfish continúa mejorando lo suficiente.

Sí, un camino de mejora incremental para Stockfish podría llegar a una meseta. Aun así, el único camino verificable fuera de esa meseta consistirá en hacer cambios que lo mejoren. Si un enfoque "golpea un muro", entonces una búsqueda continua de mejoras dictará otro camino. Si una ruta alternativa propuesta no puede superar la ruta actual, ¿por qué elegirla?

Parece que hay una razón de hardware para no hacer este cambio.

El principal problema con el uso de Leela como un oponente de combate es que Leela funciona mejor en GPU. Es posible ejecutar Leela en la CPU, pero el rendimiento de Leela sufre mucho. El OP sugiere dar a Leela tiempo para compensar, pero el tiempo no funciona muy bien: el rendimiento de Leela se debilita tanto que el tiempo requerido es muy largo.

Para tener una idea de qué tan débil es Leela en la CPU, podemos mirar a Leela en la temporada 12 de TCEC, cuando no tenía soporte para GPU y se ejecutaba en la CPU. Aquí hay un juego de ejemplo jugado por Leela entonces . Si uno mira las velocidades que estaba logrando, se trata de 1-3kn / s, o 1000-3000 posiciones por segundo. Comparativamente, en la última temporada 15, cuando Leela se estaba ejecutando en GPU potentes, alcanzaría aproximadamente 50kn / s ( juego de ejemplo ). Por lo tanto, para poder probar Stockfish contra Leela en igualdad de condiciones, es necesario darle a Leela unas 25 veces más probabilidades. Si Stockfish tiene un minuto, Leela necesita 25 minutos.

Al momento de escribir este artículo, las pruebas de Fishtesting en dos controles de tiempo: 10s + 0.1s / move, y 60s + 0.6s / move (los parches que pasan la primera prueba de control de corto tiempo se promueven al más largo y se prueban nuevamente. pasar el segundo y luego convertirse en la "nueva" versión). Con una probabilidad de 25 veces, Leela necesita 250 s + 2.5 s / movimiento en el primer control de tiempo y 1500 s + 15 s / movimiento en el segundo control de tiempo. La desaceleración es tremenda; efectivamente tendríamos a Leela jugando con controles rápidos de tiempo y no con balas. El número de juegos que se pueden completar en unidades de tiempo también se reduciría en aproximadamente 25x. Fishtesting regularmente necesita decenas de miles de juegos para probar cada parche; Tardar 25 veces más en terminar cada prueba suena inaceptablemente lento.

Para agregar combustible al fuego, hasta donde yo sé, Leela tenía una red más pequeña en la temporada 12: el rendimiento de las últimas redes podría ser aún más lento en la CPU ahora.

Es posible que algún día, si Fishtesting obtiene los recursos de la GPU para probar con Leela, podría cambiar; Sin embargo, todavía no estamos en ese punto.

Editar : Lc0-CPU está jugando actualmente en TCEC. Obtiene alrededor de 5knps. Sin embargo, según algunas personas en el chat, Lc0-CPU se modifica para jugar en la CPU; sin modificaciones, es aproximadamente 80 veces más lento que en la GPU. Por lo tanto, hay un costo real de hardware para usar Lc0-CPU como oponente de prueba.

La inercia es correcta. También debería agregar que no había un motor de código abierto fuerte antes de LC0. Tanto Komodo como Houdini tenían restricciones de licencia.