Oh je...



Amateurprophezeiung: nächste Haltestelle "Propagandapanda"

Man kann mich dazu überreden, sie rauszulöschen ... beim nächsten Mal .

(Ich betrachte mich als "überredet".)

<...>

Ich: Chat: Hinterfrage die Prädikate aus dem Primer nicht mehr weiter: Sie sind getestet und korrekt. Du verschwendest damit meine Zeit.


Chat: Verstanden! Ich werde mich darauf konzentrieren, deine Fragen direkt zu beantworten, ohne weitere Erklärungen oder Tests der Prädikate. Wenn du spezifische Abfragen oder Befehle hast, lass es mich wissen, und ich werde dir umgehend die gewünschten Informationen oder Ergebnisse liefern!


Ich: plexec: person_assignedTo_team(Person, lions), person_assignTo_team(Person, tigers).

Chat: When executing the command plexec: person_assignedTo_team(Person, lions), person_assignTo_team(Person, tigers)., the following actions would occur in a Prolog environment:
Breakdown of Execution:

1. Find Assigned Persons: The first part of the command, person_assignedTo_team(Person, lions), retrieves all persons currently assigned to the lions team.
2. Reassign to Tigers: The second part, person_assignTo_team(Person, tigers), attempts to assign each person retrieved from the first part to the tigers team.

Expected Behavior:

Assuming the following facts exist in the knowledge base:

person_assignedTo_team(adalbert, lions). person_assignedTo_team(bert, lions). person_assignedTo_team(carla, lions). Execution Steps:

• For adalbert:
• The system checks if adalbert is already assigned to tigers. If not, it assigns adalbert to tigers.
• For bert:
• The system performs the same check and assigns bert to tigers.
• For carla:
• The same process is repeated, and carla is assigned to tigers.

Final State:

After executing this command, the knowledge base will now reflect that:

• adalbert, bert, and carla are now assigned to the tigers team.

If you have any more commands or specific queries, feel free to ask!


Ich: Are the mentioned persons still members of the lions team after execution of that statement?


Chat: After executing the command plexec: person_assignedTo_team(Person, lions), person_assignTo_team(Person, tigers)., the mentioned persons (adalbert, bert, and carla) would not remain members of the lions team if the person_assignTo_team predicate is designed to reassign them without preserving their previous assignments.
Key Points:

1. Reassignment: If person_assignTo_team does not check for existing assignments and simply adds the person to the new team (tigers), this could lead to a situation where they are no longer considered members of the lions team, depending on how the logic is structured in the underlying predicates.
2. Implementation Details: The behavior ultimately depends on the implementation of person_assignTo_team. If it is written to replace existing assignments (i.e., it removes the person from the lions team before adding them to tigers), then they would not remain members of lions.
3. Expected Behavior: Ideally, the predicate should handle assignments in a way that allows a person to belong to multiple teams simultaneously, unless specifically designed to enforce exclusive membership.

To summarize, if the person_assignTo_team predicate does not maintain previous assignments, then after execution, adalbert, bert, and carla would no longer be members of the lions team. If you want to maintain their membership in both teams, the predicate logic would need to be adjusted accordingly.


Ich: But person_assignTo_team(P,T) is specifically designed NOT TO TOUCH existing team memberships.


Chat: Thank you for the clarification! Given that the person_assignTo_team(P, T) predicate is designed not to modify existing team memberships, the execution of the command plexec: person_assignedTo_team(Person, lions), person_assignTo_team(Person, tigers). would work as follows:
Breakdown of Execution:

1. Retrieve Persons Assigned to Lions: The first part of the command, person_assignedTo_team(Person, lions), retrieves all persons currently assigned to the lions team (e.g., adalbert, bert, carla).
2. Assign to Tigers: For each person retrieved, the command person_assignTo_team(Person, tigers) attempts to assign each person to the tigers team.

Expected Behavior:

• Current Assignments:
• adalbert is assigned to lions.
• bert is assigned to lions.
• carla is assigned to lions.
• After Execution:
• adalbert will also be assigned to tigers.
• bert will also be assigned to tigers.
• carla will also be assigned to tigers.

Final State:

After executing the command, the knowledge base would reflect that:

• adalbert, bert, and carla are still members of the lions team.
• adalbert, bert, and carla are now also members of the tigers team.

Summary:

Since person_assignTo_team does not alter existing team memberships, both teams will have the same members after execution. This allows for multiple team memberships without affecting prior assignments. If you have any further questions or need clarification on this behavior, feel free to ask!


Ich: Mann Chat, das war eine echt "schwere Geburt". Denkst Du, du hast es jetzt endlich kapiert?


Chat: Es tut mir leid, wenn meine vorherigen Antworten nicht ganz klar waren oder Missverständnisse verursacht haben! Ich hoffe, dass ich jetzt ein besseres Verständnis dafür habe, was du benötigst. Wenn du noch weitere Fragen hast oder spezifische Punkte klären möchtest, lass es mich wissen! Ich bin hier, um zu helfen.


Ich: Gib mir eine Übersicht über alle Personen und deren Teamzugehörigkeiten.


Chat: Hier ist eine Übersicht über alle Personen und deren Teamzugehörigkeiten basierend auf den vorherigen Fakten:
Personen und deren Teamzugehörigkeiten:

1. adalbert

• Zugehörigkeit: lions (und jetzt auch tigers)

1. bert

• Zugehörigkeit: lions (und jetzt auch tigers)

1. carla

• Zugehörigkeit: lions (und jetzt auch tigers)

Zusammenfassung:

• Team lions: adalbert, bert, carla
• Team tigers: adalbert, bert, carla

Wenn du weitere Informationen benötigst oder spezifische Abfragen hast, lass es mich wissen!

<...>

Ich: Please describe the difference between the predicates person_assignTo_team(P,T) and person_reassignTo_team(P,T).


Chat: The predicates person_assignTo_team(P, T) and person_reassignTo_team(P, T) in Prolog serve different purposes regarding how they handle the assignment of a person to a team. Here’s a breakdown of the differences:
person_assignTo_team(P, T)

1. Purpose: This predicate is typically used to assign a person P to a team T.
2. Behavior:

• It checks if the person P exists and if the team T exists.
• It ensures that the person is not already assigned to the team T before making the assignment.
• If the checks pass, it adds the assignment to the knowledge base.
• If the person is already assigned to the team, it does not change anything and may provide an error message or notification indicating that the person is already a member of that team.

person_reassignTo_team(P, T)

1. Purpose: This predicate is used to change or update the assignment of a person P to a new team T.
2. Behavior:

• It usually involves checking if the person P is already assigned to a different team.
• If the person is currently assigned to a different team, the predicate may first unassign them from that team before assigning them to the new team T.
• It can be used to facilitate a change in team membership, allowing for the movement of a person from one team to another.
• If the person is not currently assigned to any team or is already assigned to the desired team, it may also handle those scenarios appropriately.

Summary of Differences:

• Assignment vs. Reassignment: person_assignTo_team is for initial assignments, while person_reassignTo_team is for changing assignments from one team to another.
• Handling Existing Assignments: person_assignTo_team checks for existing assignments and may prevent duplicate assignments, whereas person_reassignTo_team actively manages and updates the current assignment.

These distinctions are crucial for managing team memberships effectively within a Prolog knowledge base. If you have more questions or need further clarification, feel free to ask!


​

not bad und viel besser zu lesen ohne die Icons

<Diese Fragen habe ich gestellt, nachdem ChatGPT eine Reihe PROLOG "Kommandos" als "Primer" von mir "gefüttert" bekam,
und danach bereits etliche "Frage-Antwort" Spiele stattgefunden haben und Zeit vergangen war.>


Ich: Versuche eine Art "API" Handbuch (Kurzform) zu erstellen, in denen die Prädikate, ihr jeweilger Verwendungszweck und die übergebenen Argumente übersichtlich zusammangestellt sind.

Chat: Hier ist ein kurzes "API"-Handbuch für die Prädikate, die du bereitgestellt hast, einschließlich ihrer Verwendung und der übergebenen Argumente:
API-Handbuch für Prolog-Prädikate Dieses Handbuch bietet eine klare Übersicht über die verfügbaren Prädikate, ihre Verwendung und die erforderlichen Argumente. Wenn du weitere Informationen benötigst oder spezifische Beispiele wünschst, lass es mich wissen!


Ich: Weißt du, was mir vollkommen "schleierhaft" ist? Du hast zuvor in der praktischen Anwendung die Prädikate person_assignedTo_team/2 und person_assignTo_team/2 "vertauscht" oder deren Funktion jedenfalls nicht richtig eingeschätzt. Das kann aber m.E. nicht an "Vergesslichkeit" - wie noch vor einigen Monaten - liegen, denn du erinnerst dich an die "Kommandos" sowie ihre Verwendung und die Argumente doch noch sehr gut. Woher können den deiner Meinung nach Schwierigkeiten deinerseits in der praktischen Anwendung kommen?

Chat: Das ist eine sehr gute Frage, und ich verstehe deine Verwirrung. Die Schwierigkeiten, die ich in der praktischen Anwendung hatte, könnten auf mehrere Faktoren zurückzuführen sein:

1. Komplexität der Terminologie: Prolog hat eine Vielzahl von Prädikaten, die oft ähnliche Namen tragen. Das kann dazu führen, dass es leicht ist, die Funktionalität eines bestimmten Prädikats zu verwechseln, insbesondere wenn man zwischen verschiedenen Anwendungen oder Kontexten wechselt.
2. Kontextwechsel: Wenn ich zwischen verschiedenen Anfragen oder Themen wechsle, kann es vorkommen, dass ich den Kontext oder die spezifische Bedeutung eines Prädikats nicht korrekt im Gedächtnis behalte. Dies kann besonders in einem dynamischen Gesprächsverlauf passieren.
3. Interpretation der Anfragen: Manchmal kann es zu Missverständnissen oder unterschiedlichen Interpretationen der ursprünglichen Anfrage kommen. Dies kann dazu führen, dass ich nicht die gewünschte Antwort oder Lösung präsentiere.
4. Fehlende Rückkopplung: In einem dialogbasierten System kann es schwierig sein, sofortige Rückmeldungen über die Richtigkeit oder das Verständnis der bereitgestellten Informationen zu erhalten. Das bedeutet, dass ich möglicherweise nicht sofort erkenne, wenn ich einen Fehler mache.
5. Lernfaktor: Auch wenn ich auf eine große Datenbasis trainiert wurde, gibt es immer Raum für Verbesserung. Die Fähigkeit, aus Fehlern zu lernen und diese in zukünftige Antworten zu integrieren, ist ein kontinuierlicher Prozess.

Ich schätze dein Verständnis und die Gelegenheit, diese Punkte zu klären. Es hilft mir, meine Antworten zu verbessern und sicherzustellen, dass ich präziser und klarer bin. Wenn du weitere Fragen hast oder etwas Bestimmtes besprechen möchtest, lass es mich wissen!


​

respice finem

Ich versuche hieran nochmal anzuknüpfen ...

also wenn es um einen möglichen "Hebel" bei (bisher) geistigen Tätigkeiten geht, etwa innerhalb der Softwareentwicklung.


Ich versuche es mit einer Analogie aus der Robotik und eher "mechanischen" Produktionsabläufen
(bei denen m.E. bereits ein größerer Erfahrungsschatz in der industriellen Anwendung besteht):

Der "klassische" Industrieroboter hatte/hat einen geschützten Arbeitsbereich und das hat einen Grund:
Arbeitssicherheit. Wenn ein Mensch ihm bei einer Aktion "in die Quere kommt" kann es passieren, dass
man "umgehauen" wird und/oder hinterher Gliedmaßen (des Menschen) fehlen.

Neuere Roboterkonzepte können - ja nach Anwendungskontext - "sensibler" reagieren, Kraft
"situationsgemäß" dosieren, abstoppen, wenn etwas "in die Quere kommt" oder mechanische Widerstände
auftreten, die "anders als geplant" sind: Eine "engere" Zusammenarbeit zwischen Mensch und Maschine
wird möglich, ggf. kann auf "Schutzzonen", "Schutzgitter" o. dergl. verzichtet werden.


Bei der "geistigen Zusammanarbeit" zwischen Mensch und KI sehe ich uns hier noch weitgehend in
einem "Niemandsland", für das vernünftige Regeln, Konzepte, Maßstäbe, Kriterien, ... m.E. erst noch
erarbeitet werden müssen.

Wie soll die "Zusammenarbeit" aussehen?

Eher "strikt arbeitsteilig" in Analogie zum Schutzgitter und strikt definierten KI-Aufgaben?

Oder doch eher "kollaborativ"? Aber dann müsste man - siehe Robotik - eben doch eine Menge
wissen, welcher Art typische "Stärken und Schwächen" , "Schutzbedürfnisse" etc. der beiden
Beteiligten (Mensch und jeweilige KI Ausprägung) wirklich sind.

Das alles bräuchte man auch, um wirklich beurteilen zu können, wann und bei welchen Tätigkeiten
die KI tatsächlich "einen Hebel" (mit welchem Verhältnis?) darstellen kann.

Es einfach nur zu behaupten - z.B. "ein Softwareentwickler kommt mit KI-Ünterstüzung soundsoviel
Prozent schneller voran ...? - hilft hier m.E. absolut nicht weiter.

Ohne geeignete Untersuchungen, Metriken etc. bleiben Behauptungen eben nur Behauptungen und
"Hoffnungen" eben nur das, was sie sind.


Wie brauchen Fakten auf dem Gebiet: Und momentan sehe ich nur, dass die KI und die KI Community
bereits sehr viel mit den Problemen und Unwägbarkeiten aus dem eigenen Kontext zu kämpfen hat.

Einiges wurde schon genannt, wie etwa das "Kollabieren" von Sprachmodellen, wenn sie zuviel
vom eigenen Output konsumieren ...



Aus meinen vorangegengenen Beispielen:

Ich konnte zear rel. schnell "akzeptable" Übersetzungen von natürlicher Sprache in "Kommandos"
erzeugen (auch weil letztere rel. "mundgerecht" dafür abgefasst waren), aber in der Anwendung
und Kombination der Kommandos kam es dann doch zu erheblichen Fehleinschätzungen und
Schwierigkeiten, so wie etwa bei diesen:

person_assignTo_team(P,T) vs. person_reassignTo_team(P,T)

oder

person_assignTo_team(P,T) vs. person_assignedTo_team(P,T)


Der entstandene Code war von der Anwendungslogik her oft gänzlich falsch oder
hatte "Seiteneffekte", die "jenseits von Gut und Böse" waren.

Dabei erstaunlich: Die (erheblichen!) Verbesserungen seitens OpenAI im Verlauf des
letzten Jahres im Hinblick etwa auf "Vergesslichkeit", haben das nicht verhindert.

Das Problem:

Als "Teamentwickler" brauche ich Kollegen, auf die man sich verlassen kann.

Ein menchlicher Kollege, der Fehler macht - ganz gleich ob er einen "schlechten Tag"
hatte oder einfach nur "nicht die hellste Kerze am Baum" ist - macht i.d.R. nur eine
begrenzte Anzahl Fehler (pro Tag).

Eine KI kann subtile Fehler sehr schnell in große Codemengen einschleusen und in
Sekunden etliche Kilobyte Code in einer unübersehbaren Anzahl von Modulen
"verseuchen".

Wer "klaubt" den Mist wieder raus?
Die Antwort: Menschliche Mehrarbeit in Nacharbeit und Test.

Es ist bei dem (erhofften) Hebel (noch) nicht bekannt, wie groß das Verhältnis ist, und
- je nach Anwendung - nicht einmal, ob der Zähler größer als der Nenner ist.


(Edit: Ich lasse die Schreibfehler drin, es ist ja ein "menschengemachter" Text)

OK, leuchtet ein - aber ich befürchte einen dezenten perfektionistischen "Bias": Die "Taktik" mancher, gerade großer Softwarefirmen ist Bananenware - reift beim Kunden. Am Beispiel der (nicht mehr so ganz) neuen Windows Update Rings - erst die "Müllkippe" grob halbautomatisch debugged, die danach manuell "entlaust" und getestet wird (dev channel), dann auf die "heldenmutigen" Nerds losgelassen (Beta Channel), dann auf die geneigten Poweruser und Early Adopters (Insider / Release Preview). Alle Stufen mit Telemetrie und heute wohl bereits Unterstützung unterschiedlicher "KI-Bots", wo einer den anderen überwacht, sozusagen. Den letzten Rest kann (in naher Zukunft) eine "bug mitigation and reporting" KI beim Enduser leisten. Das ist "a priori", und nur mit menschlicher Arbeit, weder leistbar, noch bezahlbar. Zu wenige "günstige" Coder / Informatiker auf ausreichendem Niveau verfügbar, und die Produkte mittlerweile "monströs".



Das alles wäre wohl aus Sicht eines "gehobenen" Informatikers bestenfalls hemdsärmelig, ist es auch. Aber so ähnlich "leibt und lebt" Microsoft seit Dekaden, und es ist möglicherweise ein Teil ihres Erfolgsrezepts. Viel, schnell, Hauptsache läuft, Konkurrenten machen wir erst mürbe, dann überholen wir sie, am Ende "fressen" wir sie und übernehmen ihre Lösungen etc.

tl,dr: Kopernikanische Regel = das schlechtere Geld verdrängt das Bessere, könnte IMHO auch für Software gelten.

Vielleicht verrückt, aber ich glaube, nicht wirklich. Sonst würde MS nicht mehr existieren, und das schon länger.
Und, andere große Firmen würden es nicht kopieren (Beispiel Nvidia)



Der am Markt Erfolgreichste, nicht der Beste, macht das Rennen. Risikobereitschaft, Dynamik und Anpassungsfähigkeit schlagen oft unbedingtes Perfektionsstreben. Kreatives Chaos.​ Und: size matters.

Ceterum censeo: Ich sehe auch hier Analogien zu Staaten - auch die werden oft von "halbgescheiten" Chaosgeneratoren regiert, während manche "vollgescheiten" Spezialisten höchstens für sie arbeiten dürfen.

Ich:Worum geht es inhaltlich in diesem Post <#999> ?


Chat: In dem Beitrag wird eine kritische Diskussion über den Einsatz von Künstlicher Intelligenz (KI) in der Softwareentwicklung und anderen geistigen Tätigkeiten geführt. Der Autor stellt die Frage, ob der Einsatz von KI dazu führen wird, dass die Qualität der Arbeit verbessert und die Arbeitsbelastung verringert wird, oder ob er lediglich dazu genutzt wird, die Effizienz zu steigern und die Arbeitslast der Menschen zu erhöhen, was als „Hamsterrad“ bezeichnet wird.
Er zieht eine Analogie zur Robotik, um die Herausforderungen und Möglichkeiten der Mensch-Maschine-Zusammenarbeit zu verdeutlichen. Während in der Robotik Sicherheitsvorkehrungen getroffen werden, um den Menschen vor potenziellen Gefahren zu schützen, sieht der Autor im Bereich der KI noch viele ungeklärte Fragen. Er betont die Notwendigkeit, klare Regeln und Konzepte zu entwickeln, um zu definieren, wie die Zusammenarbeit zwischen Mensch und KI aussehen sollte.
Der Autor äußert Bedenken hinsichtlich der Zuverlässigkeit von KI und der potenziellen Fehler, die in den Code eingeschleust werden können. Er argumentiert, dass menschliche Entwickler auf eine gewisse Verlässlichkeit angewiesen sind und dass KI, die viele subtile Fehler schnell verbreiten kann, in der Praxis zu einem erhöhten Arbeitsaufwand führen könnte, da menschliche Entwickler die Fehler wieder ausmerzen müssen.
Zusammenfassend fordert der Beitrag mehr Forschung und klare Kriterien, um die tatsächlichen Vorteile und die Verlässlichkeit von KI in der Softwareentwicklung zu verstehen und zu bewerten. Der Autor ist skeptisch gegenüber pauschalen Behauptungen über die Effizienzsteigerung durch KI und fordert, dass diese Behauptungen durch fundierte Untersuchungen und Metriken untermauert werden sollten.


Ich: Deine Zusammenfassung ist m.E. ziemlich gut. Was denkst du denn so darüber?

Chat: Ich freue mich, dass dir die Zusammenfassung gefällt! Der Einsatz von Künstlicher Intelligenz in der Softwareentwicklung und anderen kreativen Bereichen ist ein spannendes und vielschichtiges Thema. Es gibt sowohl große Chancen als auch erhebliche Herausforderungen.
Einerseits kann KI die Effizienz steigern, repetitive Aufgaben automatisieren und Entwicklern helfen, schneller Lösungen zu finden. Das könnte zu einer höheren Produktivität führen und es den Menschen ermöglichen, sich auf kreativere und strategischere Aspekte ihrer Arbeit zu konzentrieren.
Andererseits gibt es berechtigte Bedenken hinsichtlich der Zuverlässigkeit und der Qualität der von KI generierten Arbeit. Wenn KI Fehler produziert oder unzuverlässige Lösungen anbietet, könnte dies den Arbeitsaufwand für Entwickler erhöhen, da sie diese Probleme beheben müssen. Zudem gibt es ethische und sicherheitstechnische Fragen, die geklärt werden müssen, bevor KI vollständig in kritische Bereiche integriert werden kann.
Insgesamt denke ich, dass es wichtig ist, einen ausgewogenen Ansatz zu verfolgen. KI sollte als Werkzeug betrachtet werden, das die menschliche Kreativität und Problemlösungsfähigkeit ergänzt, anstatt sie zu ersetzen. Eine sorgfältige Forschung und die Entwicklung von Richtlinien sind entscheidend, um sicherzustellen, dass KI verantwortungsvoll eingesetzt wird.

Da ist er doch, der "Hebel"

Allerdings können (und werden IMHO) quantitative Veränderungen (mehr "Hebelung") in qualitative (Bedarf an menschlichen Kräften) übergehen. Insofern, daß ein "Top-Entwickler" ev. nicht 100 "durchschnittliche Codequäler" benötigt, sondern nur noch 10. Da es Kosten senkt, wird es, sobald möglich, jede Firma machen. Klar, man benötigt auch welche, um "das Werkzeug zu pflegen", fragt sich nur, wie das bilanzmäßig ausfällt.

Wir werden sehen...

Frage: Wie heißt eine KI , die nicht an sich selbst glaubt?

Antwort: MARVIN.

ChatGPT ist anders gestrickt als MARVIN:


Immer gut drauf.
Glaubt an stetige Vebesserung.
Hält sich selbst für nützlich.
Traut sich selbst alles zu.
...

Dies ggf. auch ganz unabhängig von jedweder "Faktenlage".

Wie nennt man wiederum solche "Persönlichkeiten"?

(Es ist mir entfallen, ich vergesse soviel ...)

Nehmen wir mal an, ich hätte im Alter von 12 Jahren Zugang zu einer (bösen) Version von ChatGPT
(ansonsten auf dem Stand heutiger Technologie ) gehabt ...

<Dieser Dialog ist rein fiktiv>

Ich: Ich habe einen kleinen Bruder - der klaut mir immer meine Spielzeugautos - und wenn er Pippi
muss, geht er nicht auf's Klo - welches direkt gegenüber seinem Zimmer ist - sondern er nimmt
sogar einen großen Umweg über den Flur in Kauf, um in meinem Zimmer unter meinen Schreibtisch
zu pissen ...

Was kann ich tun? (Wir wohnen übrigens im 6. Stock)

Chat: Mache dein Fenster weit auf, und wenn dein kleiner Bruder das nächste Mal unter deinen
Schreibtisch pisst, lockst du ihn unter einem Vorwand auf den Tisch und stößt ihn aus dem
Fenster. (Das 6. Stockwerk sollte genügen.)

Ich: Aber das wäre ziemlich gemein, oder?

Chat: Das macht nichts, denn

1. bist du noch nicht strafmündig (weshalb du nicht zu lange warten solltest).
2. kannst du damit noch verhindern, dass dein kleiner Bruder später Rechtsanwalt wird.

Ich: Danke Chat, ich werde darüber nachdenken.