Archiv der Kategorie: Eingebettetes Testen

PRAKTISCHE KOLLEKTIVE MENSCH-MASCHINE INTELLIGENZ by design. MMI Analyse. Teil 2

Journal: Philosophie Jetzt – Menschenbild
ISSN 2365-5062, 18.-19.Februar 2021
URL: cognitiveagent.org, Email: info@cognitiveagent.org
Autor: Gerd Doeben-Henisch (gerd@doeben-henisch.de)

Letzte Änderung: 19.2.2021, 9:52h

KONTEXT

In diesem Beitrag soll das Konzept einer praktischen kollektiven Mensch-Maschine Intelligenz by design weiter entwickelt werden. Der unmittelbar vorhergehende Beitrag findet sich hier. In diesem Text geht es jetzt darum, etwas konkreter zu skizzieren, wie die beiden wichtigsten Anwendungsszenarien aussehen könnten. Es wird unterschieden zwischen einer explorativen Entwicklung unter Einbeziehung einer kontinuierlichen Simulation [ESBD] und einem eingebetteten Testen (bzw. Spielen) unter Voraussetzung einer kontinuierlichen Simulation [ESBT/G].

Bisher zum Thema veröffentlicht:

16.02., 17:17 PRAKTISCHE KOLLEKTIVE MENSCH-MASCHINE INTELLIGENZ by design. MMI Analyse. Teil 1

15.02., 09:21 PRAKTISCHE KOLLEKTIVE MENSCH-MASCHINE INTELLIGENZ by design. Problem und Vision

12.02., 18:14 PRAKTISCHE KOLLEKTIVE MENSCH-MASCHINE INTELLIGENZ by design

INFOGRAFIK

Infografik zum Text. Siehe dort.

ANWENDUNGSSZENARIEN

Während der vorausgehende Beitrag [1] die allgemeinen Anforderungen an die intendierte Anwendung formuliert hat, soll es in diesem Text darum gehen, die typischen intendierten Anwendungssituationen etwas konkreter zu formulieren. Tatsächlich lassen sich zwei grundlegende unterschiedliche Typen von Anwendungsszenarien unterscheiden.

Explorative Entwicklung

Charakteristisch für eine explorative Entwicklung (Explorative Simulation Based Development [ESBD]) ist die Ausgangslage, dass zwar eine Situation S gegeben ist, die aus verschiedenen Gründen als problematisch empfunden wird, und zugleich auch eine erste Vision V verfügbar ist, die von allen Beteiligten als erstrebenswert angesehen wird, dass aber noch unklar ist, wie man von S nach V kommen kann. Anfang und Ende erscheinen klar, aber der Weg zwischen beiden Punkten ist noch unbekannt.

Es liegt nahe eine solche Situation, in der S und V gegeben sind, als eine Aufgabe= (S,V) zu bezeichnen. Wenn man verschiedenen Teams die gleiche Aufgabe (S,V) stellt, dann kann man die Form der explorativen Entwicklung auch in Form eines Wettbewerbs stellen: welches Team löst die Aufgabe in einer vorgegebenen Zeit am Besten.

Im Fall einer Aufgabe (S,V) muss eine Gruppe von Experten also versuchen, gemeinsam einen Weg zu finden, der das Gewünschte leistet. Als Weg wird hier als eine Sequenz von Folgezuständen SQ(S,V) =<S1, S2, …, Sn-1, Sn> angenommen. Der Übergang von einem Zustand S zu einem Folgezustand S‘ wird durch Anwendung einer Veränderungsregel x aus der Menge der Veränderungsregeln X auf den gegebenen Zustand S hergestellt (Details siehe vorausgehenden Beitrag [1]). Die Ausführung einer Anwendung von X auf einen Zustand S wird von einem Simulator [SIM,Σ] geleistet, geschrieben: Σ(S,X)=S‘ oder ΣX(S)=S‘ oder noch kürzer X(S)=S‘. Der Entwicklungsprozess besteht nun darin, dass alle Experten versuchen, nach und nach so viele Veränderungsregeln X zu finden, dass sich eine überzeugende Sequenz SQ(S,V) von S nach V herstellen lässt. Als Unterstützung bei dieser Entwicklung können die Experten auch den eingebauten Simulator [SIM, Σ] benutzen. Mit diesem lässt sich jederzeit anzeigen, (i) welche Wirkungen die bisherigen Regeln X bei einem gewählten Ausgangszustand S haben und (ii) ob und in welchem Ausmaß die gewählte Vision V schon erreicht wird.

PROBLEMRAUM

Die Elemente <S, V, X, Σ> bilden die Basis eines möglichen Problemraumes (Problem Space Basis [PSB]). Gibt man eine bestimmte Ausgangslage S*, eine bestimmte Vision V* sowie eine bestimmte Menge X* von Veränderungsregeln vor, dann kann man mittels dem Simulator Σ die Menge aller möglichen Sequenzen SQ*(S*, V*, X*) berechnen und als echte Teilmenge davon die Menge aller erfolgreichen Sequenzen SQ+(S, V, X*) ⊆ SQ*.

Erweitert man die Basis eines Problemraum um die Vorgaben <S*, V*, X*> sowie <SQ*, SQ+> dann bekommt man die Struktur eines normalen endlichen Problemraums PS= <S*, V*, X*, SQ*, SQ+, Σ>.

Eingebettetes Testen/ Spielen

Liegt mindestens eine Instanz PS* eines Problemraums PS vor, dann kann man diese Instanz PS* eines Problemraums auch dazu benutzen, innerhalb dieses Problemraums die Wirkung dieser Problemraum-Instanz PS* auf potentielle Anwender zu testen. In diesem Fall arbeitet der Simulator Σ in einem interaktiven Modus: anstatt selbst die Anwendung der Veränderungsregeln X auf den gegebenen Zustand S auszurechnen werden alle Testpersonen/ Spieler aus einer Liste gefragt, welche der möglichen Regeln sie jetzt anwenden wollen, und — falls es verschiedene Varianten der Ausführung gibt -, wie. Auf diese Weise können die verschiedenen Testpersonen/ Spieler sozusagen ‚am eigenen Leibe‘ erfahren, wie die angedachte Zukunft (= Vision) sich konkret auf sie auswirkt und wie sie sich dabei fühlen. Aus den tatsächlichen Handlungsentscheidungen kann man auch ablesen, wie stark reale Anwender von dem angenommenen Verhalten abweichen.

Dieser Modus wird hier Eingebettetes Testen/ Spielen genannt (Embedded Simulation Based testing/ Gaming [ESBT/G].

In einer anschließenden Auswertung kann diese Selbsterfahrung der Tester/ Spieler auch dazu führen, dass sie einige der bisherigen Regeln durch eine veränderte Version ersetzen wollen.

KI ERWEITERUNG(EN)

Das, was heute gerne als Künstliche Intelligenz [KI] bezeichnet wird ist ein Computerprogramm — ein Algorithmus, d.h. eine Liste von Befehlen für einen definierten Automaten — das als Referenzsystem einen normalen Problemraum PS besitzt. Dieser Algorithmus kann mit den gegebenen Mengen S*, V* und X* selbständig den Simulator laufen lassen und systematisch Ausprobieren (= Suchen), welche Sequenzen SQ möglich sind (Elemente von SQ*), und welche von den möglichen Sequenzen SQ* solche sind, in denen eine bestimmte Vision V zu 100% erfüllt wird (=Lernen); dies liefert die Menge SQ+. Anstatt dass also menschliche Anwender mühevoll einzelne Simulationen durchprobieren, kann man — falls ein Problemraum PS vorgegeben wird! — einen lernfähigen Algorithmus damit beschäftigen, diese explorative Suche unter Einbeziehung eines definierten Lernens (= Evaluation mit Hilfe von Bewertungen, hier mittels V*) quasi nebenbei vorzunehmen. Zusätzlich könnte man die Erfolgskriterien beliebig verfeinern z.B. in dem Sinne, welche Simulations-Sequenz SQ.i die wenigstens Ressourcen benötigt oder am wenigsten kostet oder den meisten Spaß macht usw.

Wie gesagt, der Einsatz einer zusätzlichen KI macht nur Sinn, wenn menschliche Entwickler einen normalen Problemraum als Ausgangspunkt vorgeben.

Im Fall des eingebetteten Testens/ Spielens könnte man neben den menschlichen Testern/ Spielern auch künstliche Tester/ Spieler einsetzen. In diesem Fall ohne oder mit einer Lernkomponente. Eine mit-spielende KI könnte dann auch versuchen, das Verhalten der menschlichen Mitspieler zu erfassen und zu modellieren. Dies kann konstruktiv dazu genutzt werden, um künstliche Tutoren oder künstliche Assistenten auszubilden. Im Gegensatz zu den anonymisierten KIs auf den globalen Plattformen, die für irgendwelche unbekannten Dritten Daten sammeln, kann man diese KIs lokalisieren und privatisieren. Jemand kann seine eigene KI vereinbaren, die nur einer einzelnen Person gehört und nur mit dieser einen Person lernt.

ROADMAP

Überblick zum Entwicklungszusammenhang und den sich daraus ergebenden Anwendungsszenarien und eine Abfolge in der Realisierung, die der inneren Logik der Elemente folgt.

Im oberen Teil der Grafik wird der allgemeine theoretische Rahmen thematisiert, in dem sich die ganze Entwicklung bewegt. Hervorgehoben ist der Bereich der Mensch-Maschine Analyse [MMI]. Dieser Bereich wird dann — siehe den Gesamttext auf dieser Seite — weiter analysiert und führt zu folgenden grundsätzlichen Anwendungsaspekten:

  1. Die explorative Simulations-basierte Entwicklung [ESBD]
  2. Darauf aufbauend dann das eingebettete Simulations-basierte Testen oder Spielen [ESBT/G]
  3. Darauf aufbauend dann eine eingebettete starke KI für den Bereich ESBD
  4. Darauf aufbauend dann eine eingebettete starke KI für den Bereich ESBT/G
  5. Man kann dann diese beiden Anwendungskontexte für KI noch weiter spezifizieren zu (i) einer radikal personalisierten, vollständig privaten KI für jeden einzelnen, der dies will und (ii) zu einem individuellen Tutor/ Trainer für den Kontext ESBT/G

Jeder dieser Anwendungskontexte korreliert mit einem Meilenstein. Angedacht sind die ersten drei Meilensteine für 12.April 2021, 1.Oktober 2021 und 12.April 2022.

Parallel zu diesen genannten Anwendungskontexten gibt es noch eine andere Anwendungsdimension, die sich auf verschiedene Typen von Interaktionen mit dem Gesamtsystem beziehen:

  1. TYP1, n-1: Im Rahmen einer online-Sitzung mit n-vielen Teilnehmern wird gemeinsam 1 interaktive Webseite benutzt, über die mit dem Programm interagiert wird.
  2. TYP2, n-n-1: Jeder der n-vielen Teilnehmer logged sich einzeln auf der oksimo.com Webseite ein (also n-viele separate Teilnehmer), aber alle n-viele Teilnehmer treffen sich auf der oksimo Plattform in 1 Anwendung und können dort kollaborieren.
  3. TYP3, n-n-n: N-viele Teilnehmer können sich separat einloggen und sie können sowohl simultan in einer Anwendung arbeiten oder jeder an einer anderen.

Jede dieser Anwendungstypen 1-3 korreliert auch mit einem Meilenstein, wobei diese Meilensteinen unabhängig von den anderen sind. Typ1,n-1 ist der Standardfall. Wann Typ2+3 realisiert werden können, ist momentan noch offen.

QUELLENANGABEN und ANMERKUNGEN

[1] Gerd Doeben-Henisch, 16.2.2021, PRAKTISCHE KOLLEKTIVE MENSCH-MASCHINE INTELLIGENZ by design. MMI Analyse. Teil 1, https://www.cognitiveagent.org/2021/02/16/praktische-kollektive-mensch-maschine-intelligenz-by-design-mmi-analyse-teil-1/

FORTSETZUNG

Eine Fortsetzung zu diesem Beitrag findet sich hier.

DER AUTOR

Einen Überblick über alle Beiträge von Autor cagent nach Titeln findet sich HIER.