Die Cerebellum Library ist eine Datenbank von Eröffnungsstellungen. Allerdings ist sie weit mehr, als ein klassisches Eröffnungsbuch, was einfach in die Stockfish-Engine eingefügt wurde. Und sie ist auch nicht nur eine simple Vorab-Berechnung von Stellungen mit einer Engine und das Abspeichern derselben in einer Datenbank. Deswegen spielt die Library auch tatsächlich besser als die verwendete Zugzeit und Hardware waren, und in einigen Fällen sogar besser, als es einer Engine heutzutage überhaupt möglich ist, d.h. es sind Analysen möglich, die mit einer Engine allein nicht machbar wären und es wird im praktischen Engine-Spiel eine Eloleistung erreicht, die deutlich und meßbar über die Leistung der Stockfish-Engine hinausgeht!

Brainfish basiert auf der Stockfish-Engine mit einer reduzierten Variante der Cerebellum Library. Daher ist die Engine-Datei auch um ein vielfaches größer, als ein normaler Stockfish-Compile.

Nehmen wir an, man will z.B. im Fernschach über eine komplizierte Stellung die "letzte Wahrheit" erfahren, d.h. eine korrekte Bewertung und alle wichtigen Abspiele/Zugfolgen. Nun kann man irgendeine Engine lange rechnen lassen, und erhält einen Score und eine Haupvariante (im Multi-Varianten Modus auch mehrere für die besten Züge). Jetzt schaut man sich das Ergebnis an und denkt, hoppla, da kann doch was nicht stimmen, was spielt denn die Engine z.b. auf diese oder jenen Zug/Zugfolge?.Also geht man in der GUI im Stellungsbaum immer wieder vor und zurück und schaut sich an ,was die Engine zieht. Augrund der Hashtables kann das dann auch zu einer Veränderung der Bewertung der Ausgangsstellung führen. Was hat man am Ende vorliegen? Eine grosse Anzahl von analysierten Stellungen mit Bewertungen und eine Idee von möglichen besten Zugfolgen. Was man nicht hat, ist ein konsistenter Überlick über den gesamten Variantenbaum, und man hat auch keine richtige Vorstellung davon, ob diese Analyse evtl. Lücken oder Fehler aufweist.

Nehmen wir an, man hat eine große Zahl von Stellungsbewertungen (Score + bester Zug) in einem Variantenbaum. Was ist das Problem? Diese Bewertungen sind fast nie konsistent! Beispiel:

Ausgangsstellung: Score + 0.20, bester Zug e4.

Stellung nach e4: Score + 0.18, bester Zug e5.

Stellung nach d4: Score + 0.22, bester Zug d5.

Stellung nach c4: Score + 0.16, bester Zug e5.

Was also jetzt? Die Bewertung im Ausgangsknoten sagt: Ziehe e4, wenn man sich aber die Nachfolgestellungen anschaut, müßte man eigentlich d4 ziehen, da das ja zur besten Bewertung führt. Und so weiter…​Das heißt, das Problem stellt sich für jede Stellung im gesamten Suchbaum. Der Score nach d4 kann wieder nicht konsistent sein mit den Nachfolgestellungen von d4. Was muss man also tun, wenn man z.b. eine Million analysierte Stellungen ausgehend von der Ausgangsstellung hat? Man muss diesen Stellungsbaum ausbalancieren, d.h. jede Stellung konsistent mit allen Nachfolgestellungen machen. Und das geht prinzipiell nicht mit der normalen Baumsuche einer Engine, da es sich aufgrund der Möglichkeit von Stellungswiederholungen um ein graphentheoretisches Problem handelt. Bei dieser Ausbalancierung kann man auch nicht einfach bei einer Stellungswiederholung den Knoten auf den Score 0 setzen, das führt zu unauflösbaren Wiedersprüchen.

Im Endergebnis erhält man dann für jeden Knoten einen neuen Score und auch evtl. einen neuen besten Zug. Diese nachträgliche Neuberechnung aller Stellungen ist die eigentliche Leistung der Library. Sie führt zu einer nachträgliche Erhöhung der Suchtiefe, die durchaus manchmal +40 betragen kann.

Einfacher ausgedrückt: Eine normale Engine rechnet in einer beliebigen Stellung in die Zukunft, also nach vorne. In der Library werden diese Berechnungsergebnisse nun in die Stellungen davor, d.h. in die Vergangenheit, zurückgeholt. Das Verfahren ähnelt, wie schon erwähnt, einer manuellen Analyse einer Stellung mit einer Engine, die persistente Hahstables nutzt: Man spielt Züge, ausgehend von einer Ausgangsstellung, vor. Die Engine sieht nun dabei (spätere) Konsequenzen dieser Züge und speichert diese als Bewertung in den persistenen Hashtables ab. Nun nimmt man die Züge wieder zurück und analysiert wieder die Ausgangsstellung. Nun „weiß“ die Engine aber schon um die möglichen Konsequenzen von späteren Zügen, weil diese ja schon in den Hashtables vorliegen. Dadurch wird die Ausgangsstellung nun anders (und besser, weil vertiefter) bewertet, auch der favorisierte beste Zug kann nun ein anderer sein. Die Analyse wird dadurch also schachlich hochwertiger, als nur mit reiner Engine-Berechnung in der Ausgangsstellung. Nur sind die Daten in der Library - im Gegensatz zu manuellen Analysen mit Hilfe persistenter Hashtables – konsistent und frei von Lücken.Brainfish enthält nun aber nicht das gesamte Wissen der Library (wie z.B. die Bewertung),sondern nur den nach der Neuberechnung ermittelten besten Zug (manchmal noch den zweitbesten Zug, um die Variabilität zu erhöhen), was für das praktische Spiel aber ausreicht. Da Brainfish sowieso nicht rechnet, wenn eine Stellung auf dem Brett ist, die in der Library gespeichert ist, ist eine Stellungsbewertung auch nicht vonnöten.

Die Stärke des Ergebnisses und das Potential der Library läßt sich daraus ablesen, das mit nur wenigen aus der Library ausgeführten Zügen in mehreren SPCC-Testruns von Stefan Pohl in jedem einzelnen Testrun (immer über jeweils 7000 Partien) bereits eine Elo Steigerung um ca. 70-80 Punkte erreicht wurde (im Vergleich zur jeweiligen „normalen“ Stockfish-Development Version ohne die Library). Dies wurde erreicht, indem die 500 Vorgabestellungen, die in einem SPCC-Testrun verwendet werden, sowie Partien aus früheren SPCC-Testruns, für die Library durchanalysiert wurden.

Bei anderen Vorgabestellungen, die gar nicht oder nur zu einem geringen Teil in der Library enthalten sind, ergäbe sich natürlich ein sukzessiv schlechteres Ergebnis, bis man schließlich bei der Leistung des normalen Stockfish ankommt. Die Library enthält momentan 3.4 Millionen analysierte Stellungen, die wichtigsten Eröffnungen sind also vorhanden, momentan ist der Fokus allerings mehr bei Computerpartien als bei menschlichen Vorgabestellungen. Denn leider haben Schacheröffnungen aus menschlichen Partien die Eigenschaft, äußerst viefältig zu sein. Das heißt, wenn man als Datenbasis beispielsweise ausgesuchte Großmeistenpartien bis zum 12. Zug nimmt, kann man trotz der breiten Abdeckungen von einigen Millionen gängiger Eröffnungsstellungen davon ausgehen, das alleine von den Stellungen bis zum 12 Zug schon die Hälfte fehlt, geschweige denn von den Nachfolgestellungen. Aber diese Stellungen auch durchzuanalysieren kostet prinzipiell nur Rechenzeit, davon allerdings jede Menge.

Die Library läßt sich auch bei sehr langen Bedenkzeiten und/oder sehr schneller Hardware einsetzen, der Effekt ist hier derselbe wie beim Spiel normaler Engines: die Remisquote steigt an, somit rücken Zweikampf-Ergebnisse näher zusammen und an die 50%-Marke heran. Bei den extremen TCEC Bedingungen würde man vielleicht kurz vor dem Endknoten aufhören, da hier bereits die Leistung der Engine die Leistung der Library durch die Neuberechnung übertreffen kann.