Celem testów ryb jest sprawdzenie, czy nowsza wersja Stockfisha stała się silniejsza . Definicja silniejszego polega na pokonaniu poprzedniej wersji.

Nie jestem pewien, jak pomogłoby przetestowanie każdej nowej wersji z silnikiem takim jak Leela. Twoim pomysłem może być zaakceptowanie nowej wersji Stockfisha tylko wtedy, gdy będzie ona skuteczniejsza przeciwko Leeli niż poprzednia wersja Stockfisha. Więc teraz każda wersja Stockfisha gwarantuje lepszą grę przeciwko Leeli, ale nie gwarantuje, że będzie ogólnie lepszym szachistą. Powodem jest to, że Stockfish mógł polegać na pewnych cechach gry Leeli, aby wygrywać więcej gier.

EDYCJA - pomyślałem o przykładzie, który mógłby tutaj pomóc. Załóżmy, że kilka lat temu zostałeś sklasyfikowany jako 1500, a teraz masz 1800. Jeśli rozegrałeś swój poprzedni mecz, jasne jest, że wygrasz. Ale ze względu na dyskusję jest możliwe, że twoje 1500 ja byłoby lepsze przeciwko Kasparowowi niż twoje obecne 1800 ja. Może ta 1500-osobowa osoba była mniej konserwatywna i podejmowała znacznie większe ryzyko. To udaje się pokonać Kasparowa w rzadkiej grze, podczas gdy twoje obecne 1800 ja przegrywa za każdym razem (ale gry byłyby średnio nieco bliżej).

Po pierwsze, z innych odpowiedzi nie wynika jasno, że w zasadzie możesz użyć dowolnego przeciwnika (o stałej sile gry) do porównania siły gry dwóch wersji programu.

Istnieje jednak kilka dobrych powodów, aby przetestować wersje bezpośrednio ze sobą, niezależnie od tego, czy tworzysz silnik Stockfisha, czy inny:

• Porównanie siły gry podmiotów grających w szachy zazwyczaj tak nie spełnia przechodniości, tj. jeśli A> B i B> C, A < C jest nadal możliwe. Tak długo, jak porównanie z dużą pulą przeciwników (w celu uśrednienia problemu przechodniości) nie jest wykonalne, bezpośrednie porównanie powinno być najbardziej wiarygodnym pomiarem, chociaż oczywiście możesz mieć ten sam problem dla trzech wersji testu pojedynczy program.
• Wykonując bezpośrednie porównanie, zmniejszasz wymaganą liczbę gier w testowaniu, ponieważ wystarczy uruchomić tylko jeden mecz zamiast dwóch, a jednocześnie otrzymujesz mniejsze paski błędów dla różnica siły gry.
• Testowanie przeciw przeciwnikowi o (prawie) równej sile maksymalizuje statystyczną wrażliwość wyniku pojedynczego meczu, więc ponownie oszczędzasz koszty sprzętu. Jeśli różnica w sile gry jest bardzo duża, informacja / entropia pojedynczej gry jest bardzo niska.

Ponadto w przypadku testu ryb / sztokfisza istnieje kilka konkretnych powodów, dla których bezpośrednie porównanie było najbardziej zasadniczym wyborem:

• W czasie, gdy początkowo testowano ryby, Leela nie była dostępna.
• Używanie komercyjnych silników, takich jak Komodo i Houdini, było / nie jest opcja z powodu problemów licencyjnych.
• Korzystanie z innych programów może powodować zagrożenia bezpieczeństwa, a także dodatkowe zależności oprogramowania lub wymagania sprzętowe, których chcesz uniknąć w rozproszonym środowisku komputerowym.
• Przed Leela w zasadzie nie istniał silnik open source, który byłby wystarczająco silny, aby uzyskać statystycznie istotne wyniki podczas dopasowywania do Stockfish.

Zasadniczo zgadzam się z @inertialignorance, ale chciałbym nieco wyjaśnić to stanowisko.

Kiedy człowiek gra człowiekiem, wynik jednej gry jest stosunkowo bez znaczenia, biorąc pod uwagę ekstremalną zmienność ludzkiej zabawy. (Jako przykładu tej zmienności użyję Kasparowa v Deep Blue - w dobry dzień ja mógłbym prawdopodobnie pokonać Kasparowa w grze, którą popełnił przeciwko DB.) Więc po prostu zignorujmy ludzkość w to i skoncentruj się na maszynie.

Maszyny grają na znacznie bardziej stałym poziomie umiejętności niż ludzie. Dlatego pojedyncza gra znaczy więcej, a seria gier wiele znaczy. Dlatego warto przetestować proponowane ulepszenie Stockfish na maszynie. Ale dlaczego Stockfish?

Po prostu dlatego, że nie ma sposobu na ilościowe określenie „radzi sobie lepiej z Leela” w żaden znaczący sposób. Mógłby działać lepiej i nadal przegrywać. Ale jaki jest standard na lepsze, w takim przypadku? Jak udowodnisz, że zagrał lepiej? Nie widzę realnego standardu.

O wiele łatwiej jest udowodnić, że Stockfish prime jest ulepszeniem w stosunku do oryginału Stockfish, po prostu grając w zestaw gier i licząc wyniki.

Edward Deming utrzymywał, że wybór właściwej miary ma pierwszorzędne znaczenie, ponieważ wiesz, że poprawiasz się tylko dzięki temu, co mierzysz. Zadaj więc pytanie: jaki jest cel tego procesu? Dlaczego proponujesz łatkę dla Stockfisha?

Czy naprawdę ostatecznym celem łatki jest pokonanie Leeli? A może raczej sprawić, by Stockfish grał lepiej w szachy? Powiedziałbym, że to drugie. Pokonanie Leeli nastąpi samoistnie, jeśli tylko Stockfish będzie nadal wystarczająco się poprawiał.

Tak, ścieżka stopniowego doskonalenia dla Stockfisha może dojść do płaskowyżu. Mimo to jedyną możliwą do zweryfikowania ścieżką z tego płaskowyżu będzie wprowadzenie zmian, które uczynią go lepszym. Jeśli podejście „uderza w ścianę”, ciągłe poszukiwanie ulepszeń wyznaczy inną ścieżkę. Jeśli proponowana ścieżka alternatywna nie może pokonać bieżącej ścieżki, dlaczego ją wybrać?

Wygląda na to, że istnieje sprzętowy powód, dla którego nie należy wprowadzać tej zmiany.

Głównym problemem związanym z używaniem Leeli jako sparingowego przeciwnika jest to, że Leela działa najlepiej na GPU. Możliwe jest uruchomienie Leeli na procesorze, ale wydajność Leeli bardzo cierpi. OP sugeruje podanie Leeli szans czasowych na wyrównanie, ale szanse czasowe nie działają zbyt dobrze: wydajność Leeli słabnie tak bardzo, że wymagane szanse czasowe są przytłaczająco długie.

Aby zorientować się, jak słabsza jest Leela na CPU, możemy przyjrzeć się Leeli w 12. sezonie TCEC, kiedy nie miała obsługi GPU i działała na CPU. Oto przykładowa gra, w którą wtedy grała Leela. Jeśli spojrzeć na osiągane prędkości, to około 1-3 kn / s, czyli 1000-3000 pozycji na sekundę. Dla porównania, w ostatnim 15 sezonie, kiedy Leela działała na potężnych procesorach graficznych, osiągała około 50 kN / s ( przykładowa gra). Dlatego, aby móc przetestować Stockfisha przeciwko Leeli na równych warunkach, należy podać Leeli około 25-krotne szanse czasowe. Jeśli sztokfisz ma minutę, Leela potrzebuje 25 minut.

W chwili pisania tego tekstu, testy Fishtesting przy dwóch kontrolach czasowych: 10 s + 0,1 s / ruch i 60 s + 0,6 s / ruch (poprawki, które przejdą pierwszy, krótkotrwały test kontrolny, są promowane do jeden i ponownie przetestowany. Łatki, które przejdą drugą, stają się „nową” wersją). Przy prawdopodobieństwie 25x Leela potrzebuje 250s + 2,5s / ruch w pierwszej kontroli czasu i 1500s + 15s / ruch w drugiej kontroli czasu. Spowolnienie jest ogromne; w efekcie Leela grałaby przy szybkich kontrolach czasu, a nie kulą. Liczba gier, które można ukończyć w jednostkowym czasie, również spadłaby o około 25x. Testy rybne regularnie wymagają dziesiątek tysięcy gier, aby przetestować każdy patch; ukończenie każdego testu trwa 25 razy dłużej. Brzmi niedopuszczalnie wolno.

O ile wiem, Leela miała mniejszą sieć w sezonie 12, aby dodać paliwa do ognia - najnowsze sieci mogły działać jeszcze wolniej teraz na CPU.

Możliwe, że któregoś dnia, jeśli Fishtesting dostanie zasoby GPU do przetestowania z Leela, może się zmienić; jednak jeszcze nie jesteśmy na tym etapie.

Edycja : Lc0-CPU gra obecnie na TCEC. Dostaje około 5 knps. Jednak według niektórych osób na czacie, Lc0-CPU jest zmodyfikowany do gry na CPU; niezmodyfikowany, jest około 80 razy wolniejszy niż na GPU. Dlatego użycie procesora Lc0 jako przeciwnika testowego wiąże się z realnymi kosztami sprzętowymi.

(Dodaję inną odpowiedź, ponieważ tak naprawdę nie jest moja)

Programista Stockfish o nazwisku Михаил Чалый napisał to w grupach dyskusyjnych Fishcooking (w zasadzie na forum dla programistów Stockfisha), kiedy ten sam pomysł został zasugerowany:

1) Na większości maszyn nie mamy sprzętu odpowiedniego dla lc0 (80 +% maszyn to maszyny noob * w / o GPU);

2) testowanie z zewnętrznym silnikiem podwoi paski błędów, co zwiększy czterokrotnie liczbę gier, w których test będzie wiarygodny;

3) będziesz musiał napisz nową logikę, ponieważ a) nie możesz używać SPRT, b) musisz znormalizować prędkość leela / sf do jakiejś wartości (tak jak robimy z TC w normalnych testach), więc będziesz potrzebować asymetrycznej kontroli czasu;

4) istnieje 0 dowodów na to, że łatki działające w trybie samodzielnej gry nie działają w porównaniu z leela. W rzeczywistości istnieją przeciwne dowody, takie jak lista 16 rdzeni fastgm, gdzie sf 11 wyprzedza sf10 o 50 elo, co jest dokładnie tym, co mierzymy, jeśli porównasz je ze sobą.

Więc tldr - trudno lub prawie niemożliwe i tak naprawdę korzyści z tego nie istnieją.

* O ile wiem, „maszyny noob” to maszyny należące do innej osoby w społeczności o nazwie „noob”, która ma dużo dostępnego sprzętu CPU, ale nie ma sprzętu GPU.

Inercja jest poprawna. Powinienem też dodać, że przed LC0 nie było silnego silnika open source. Zarówno Komodo, jak i Houdini miały ograniczenia licencyjne.