Benutzer-Werkzeuge
ss25:ssp-ai_protokolle
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | |||
|
ss25:ssp-ai_protokolle [2025/07/02 15:23] popelgott |
ss25:ssp-ai_protokolle [2025/07/03 03:26] (aktuell) popelgott |
||
|---|---|---|---|
| Zeile 15: | Zeile 15: | ||
| ===Woche des 18.6.=== | ===Woche des 18.6.=== | ||
| - | Diese Woche haben wir zu Begin unsere Handgestenerkennung getestet und uns überlegt wie wir nun fortfahren, da wir vorerst zufrieden mit der Erkennung sind. Viel Zeit haben wir diese Woche mit dem Suchen von Schere-Stein-Papier-Datensätzen verbracht. Wir konnten leider nicht viele Daten finden. Wir haben zwei Datensätze, die öffentlich sind, mit ca. 4000 Einträgen und ca. 1700 Einträgen gefunden. Außerdem haben wir herausgefunden, dass RedBull im Jahr 2007 in kooperation mit Facebook Roshambull gestartet hat. Eine App, die in Facebook installiert werden kann, um mit Freunden oder Fremden SSP zu spielen. Durch dieses Projekt entstand ein Datensatz mit ca. 2,5 millionen Einträgen, den wir sogar in einer Studie zu SSP gefunden haben ([[https://fluentpartners.com/worksamples/RedBull_and_Facebook_Case_Study_FINAL.pdf|| Link zur Studie]]). Die Forscher der Studie schreiben, dass sie den Datensatz von RebBull bekommen haben. Wir haben dann versucht mehr über diesen Datensatz herauszufinden und sind auf die Website von Craig Kohtz ([[https://kohtz.org/project/roshambull|| Craig Kohtz Website]]) gestoßen, auf der er kurz über das Projekt Roshambull schreibt, in dem er Mitarbeiter war. Wir haben ihm daraufhin eine Mail geschrieben, in der wir gefragt haben, ob er uns sagen kann wie wir eventuell an den Datensatz kommen können, um unser KI-Modell trainieren zu können. Er hat uns ziemlich schnell geantwortet, dass er nicht weiß, ob die Daten noch existieren, er aber für uns seine alten Kollegen nachfragen wird und vielleicht auch bei RedBull anfragt was mit den Daten passiert ist. | + | Diese Woche haben wir zu Begin unsere Handgestenerkennung getestet und uns überlegt wie wir nun fortfahren, da wir vorerst zufrieden mit der Erkennung sind. Viel Zeit haben wir diese Woche mit dem Suchen von Schere-Stein-Papier-Datensätzen verbracht. Wir konnten leider nicht viele Daten finden. Wir haben zwei Datensätze, die öffentlich sind, mit ca. 2600 Einträgen und ca. 1700 Einträgen gefunden. Außerdem haben wir herausgefunden, dass RedBull im Jahr 2007 in kooperation mit Facebook Roshambull gestartet hat. Eine App, die in Facebook installiert werden kann, um mit Freunden oder Fremden SSP zu spielen. Durch dieses Projekt entstand ein Datensatz mit ca. 2,5 millionen Einträgen, den wir sogar in einer Studie zu SSP gefunden haben ([[https://fluentpartners.com/worksamples/RedBull_and_Facebook_Case_Study_FINAL.pdf|| Link zur Studie]]). Die Forscher der Studie schreiben, dass sie den Datensatz von RebBull bekommen haben. Wir haben dann versucht mehr über diesen Datensatz herauszufinden und sind auf die Website von Craig Kohtz ([[https://kohtz.org/project/roshambull|| Craig Kohtz Website]]) gestoßen, auf der er kurz über das Projekt Roshambull schreibt, in dem er Mitarbeiter war. Wir haben ihm daraufhin eine Mail geschrieben, in der wir gefragt haben, ob er uns sagen kann wie wir eventuell an den Datensatz kommen können, um unser KI-Modell trainieren zu können. Er hat uns ziemlich schnell geantwortet, dass er nicht weiß, ob die Daten noch existieren, er aber für uns seine alten Kollegen nachfragen wird und vielleicht auch bei RedBull anfragt was mit den Daten passiert ist. |
| ===Woche des 25.6.=== | ===Woche des 25.6.=== | ||
| Da wir bis jetzt keine weitere Antwort von Craig Kohtz bekommen haben, schrieben wie ihm eine dankbare Mail, in der wir nocheinmal nachgefragt haben, ob er etwas neues in Erfahrung bringen konnte. Abseits davon haben wir nun angefangen mit PyTorch unser Modell zu basteln. Wir haben uns dafür entschieden eine LSTM-Architektur ([[https://docs.pytorch.org/docs/stable/generated/torch.nn.LSTM.html||PyTorch LSTM Dokumentation]]) zu nutzen, denn dabei kann Information von vorherigen SSP-Vorhersagen zur nächsten Vorhersage weitergegeben werden (sozusagen ein "Gedächtnis"). Wir wollen als erstes versuchen ein Vorhersagemodell zu bauen, dass anhand der Vergangenheit den nächsten Zug des Gegenspielers vorhersagt. Alternativ könnten wir ein SSP-Agenten bauen, den wir darauf trainieren, selbst SSP zu spielen. Dieser Agent könnte nicht nur auf gegnerische Strategien antworten, sondern selbst Strategien verfolgen. Wir haben uns an einem Beispiel ([[https://github.com/pytorch/examples/blob/main/word_language_model/main.py||LSTM Codebeispiel]]) orientiert und angefangen eine Class für unser Modell zu schreiben. | Da wir bis jetzt keine weitere Antwort von Craig Kohtz bekommen haben, schrieben wie ihm eine dankbare Mail, in der wir nocheinmal nachgefragt haben, ob er etwas neues in Erfahrung bringen konnte. Abseits davon haben wir nun angefangen mit PyTorch unser Modell zu basteln. Wir haben uns dafür entschieden eine LSTM-Architektur ([[https://docs.pytorch.org/docs/stable/generated/torch.nn.LSTM.html||PyTorch LSTM Dokumentation]]) zu nutzen, denn dabei kann Information von vorherigen SSP-Vorhersagen zur nächsten Vorhersage weitergegeben werden (sozusagen ein "Gedächtnis"). Wir wollen als erstes versuchen ein Vorhersagemodell zu bauen, dass anhand der Vergangenheit den nächsten Zug des Gegenspielers vorhersagt. Alternativ könnten wir ein SSP-Agenten bauen, den wir darauf trainieren, selbst SSP zu spielen. Dieser Agent könnte nicht nur auf gegnerische Strategien antworten, sondern selbst Strategien verfolgen. Wir haben uns an einem Beispiel ([[https://github.com/pytorch/examples/blob/main/word_language_model/main.py||LSTM Codebeispiel]]) orientiert und angefangen eine Class für unser Modell zu schreiben. | ||
| + | |||
| + | ===Woche des 2.7.=== | ||
| + | Clemens war diese Woche leider nicht da, nichtsdestotrotz werden wir im Folgenden aus der Wir-Perspektive schreiben. Wir haben uns zu Begin nocheinmal Gedanken gemacht, welchen Encoder wir für unser Modell benutzen wollen. Möglichkeiten wären z.B. der One-Hot-Encoder ([[https://docs.pytorch.org/docs/stable/generated/torch.nn.functional.one_hot.html||PyTorch One-Hot-Function]]) oder das sogenannte Embedding von PyTorch ([[https://docs.pytorch.org/docs/stable/generated/torch.nn.Embedding.html||PyTorch Embedding]]). Wir werden das Embedding von PyTorch nutzen, denn das ist ebenfalls ein Netz, das wir mit unserem Modell zusammen trainieren können. So wird im Optimalfall unser Encoding der Eingabedaten immer besser an unser Modell angepasst. Das Embedding ist noch nicht implementiert, aber wir haben den Code geschrieben, mit dem wir den einen Datensatz laden können und die Daten in ein sinnvolles Format umwandeln können. Für uns bedeutet das, die Daten bestehen immer aus Paaren (Tupel), die die Geste des Spielers und die Geste des Gegners (in diesem Fall die Geste des Menschen und die Geste des Computers, da die Daten von Mensch gegen KI stammen) beeinhalten. Bei drei Symbolen pro Spieler ergibt das neun Möglichkeiten, diese neun Möglichkeiten stellen wir als Zahlen von 0 bis 8 in einer Liste dar. Die Liste enthält nun 2600 Einträge von Partien mit jeweils 50 Runden. In der nächsten Woche wollen wir das Embedding implementieren und das Modell an den Daten anfangen zu trainieren. | ||
ss25/ssp-ai_protokolle.1751462615.txt.gz · Zuletzt geändert: 2025/07/02 15:23 von popelgott
Seiten-Werkzeuge
