Unternehmen können künftig Apps für ChatGPT entwickeln und bereitstellen. Es ist der nächste Versuch von OpenAI, ein Ökosystem zu schaffen, das Menschen für ihr digitales Leben nicht mehr verlassen müssen. Als erste Partner sind unter anderem Spotify, Canva, Booking.com, OpenTable, Uber und Zillow auf den OpenAI Dev Days benannt worden. Letztgenannter Dienst ist eine Immobilienplattform, die als Erstes bereits in ChatGPT verfügbar ist, andere folgen bald. Grundsätzlich ist zunächst ein Start in den USA geplant, bis die Integration von Apps in der EU möglich ist, wird es noch ein bisschen dauern.

Entwickler, die das ChatGPT-SDK nutzen, können in ihren Apps Tags setzen, um eine Aufgabe zu erledigen. Nutzer kommunizieren die Aufgabe im ChatGPT-Interface. Dort können sie auch Kontext hinzufügen oder Ratschläge einholen, die ebenfalls umgesetzt werden. Beispielsweise kann ChatGPT auf Wunsch eine Playlist für eine bestimmte Laune oder einen Anlass zusammenstellen und diese direkt von Spotify abspielen lassen. In einer Demo hat ein OpenAI-Mitarbeiter gezeigt, wie man in ChatGPT ein Poster beschreiben kann, das von Canva umgesetzt wird.

OpenAI hatte bereits mit Erweiterungen und GPTs ähnliche Vorhaben an den Start gebracht. Auch da sollten andere Dienste via ChatGPT bedient werden. Mit Verbesserungen des Chatbots und agentischen Fähigkeiten erweitert sich nun deutlich der Umfang dessen, was möglich ist. Es sind allerdings auch immer nahezu dieselben Verdächtigen, die gleich zu Beginn an Bord sind. OpenTable hat noch jede Möglichkeit genutzt, den Dienst zum Reservieren eines Tisches im Restaurant auf anderen Wegen als der eigenen Webseite und App anzubieten. Neben OpenAI etwa auch via Googles KI-Assistenten als der noch Bard hieß.

Suchen, Shoppen, Kaufen via ChatGPT

Das Bestreben OpenAIs, Menschen vollumfänglich digital zu versorgen, zeigt sich auch in der erst kürzlich vorgestellten Funktion, zum Bezahlen direkt via ChatGPT. Auch zum Shoppen muss dann der Chatbot nicht mehr verlassen werden. Man fragt ihn nach dem besten Produkt einer bestimmten Kategorie und schlägt direkt zu. Online-Händler haben dann zwar im Zweifel einen Vorteil durch die schnelle Verfügbarkeit, niemand muss umständlich einen neuen Account anlegen – all das kann (zumindest in der Theorie) ChatGPT für einen erledigen. Allerdings fehlt auch der Besuch einer Webseite und damit einhergehende Werbemöglichkeiten für weitere Produkte. In den USA ist Etsy bereits dabei. Weitere Shops sollen folgen.

Mit dem Update des Videogenerators Sora auf Version 2 ist zudem das damit einhergehende Soziale Netzwerk erweitert worden. Sora kam bereits mit einem Feed daher, in dem KI-generierte Videos gezeigt wurden. Man konnte diese teilen und als Inspiration nehmen. Nun gibt es eine iOS-App namens Sora, die es erlaubt, Videos anderer Nutzer zu remixen, sich auszutauschen und freilich Videos zu erstellen und zu teilen. Mit Cameos kann man sich selbst in Aufnahmen integrieren. Auch die Sora-App ist zunächst nur in den USA und Kanada über eine Warteliste verfügbar.

Meta hat erst kürzlich Vibes eingeführt, einen Feed für KI-generierte Videos. Sie lassen sich in der Meta AI App entdecken und sind daher auch für alle Menschen bereits verfügbar.

OpenAI hat auf den Dev Days auch ein neues AgentKit vorgestellt sowie eine API für Sora 2. Codex bekommt eine Slack-Integration und ebenfalls ein SDK. Neu ist zudem ein kleineres Voice-Model, das 70 Prozent günstiger sein soll als das bisherige große gpt-realtime, sowie ein ebenfalls kleineres gpt-image-1-mini, das sogar 80 Prozent im Vergleich zum Vorgänger einsparen soll.

(emw)

Die auf arXiv veröffentlichte Arbeit „A 1000× Faster LLM-enhanced Algorithm For Path Planning in Large-scale Grid Maps“ von Forschenden der National University of Defense Technology in China stellt einen neuen Algorithmus vor, der die Effizienz der Pfadplanung auf großen Gitterkarten erheblich steigern soll. Der Ansatz iLLM-A* kombiniert ein Sprachmodell mit einem optimierten A*-Algorithmus und soll die Suchzeit im Vergleich zu bestehenden Methoden um mehr als den Faktor 1000 reduzieren. Davon könnten potenzielle Anwendungsfelder wie autonome Robotik, Logistikplanung und die KI-Steuerung in komplexen Simulationen oder Videospielen profitieren.

Die Pfadplanung in großen, gitterbasierten Umgebungen stellt für traditionelle Wegfindungsalgorithmen wie A* und Dijkstra eine erhebliche rechnerische Herausforderung dar. Mit zunehmender Kartengröße steigen Zeit- und Speicherkomplexität überproportional an, was Echtzeitanwendungen in Bereichen wie Robotik oder der Simulation komplexer Systeme erschwert. Forscher stellen nun mit iLLM-A* einen hybriden Ansatz vor, der diese Beschränkungen adressiert.

Skalierungsgrenzen bestehender Algorithmen

Die Studie analysiert zunächst die Schwächen des bisherigen State-of-the-Art-Ansatzes LLM-A*. Dieser nutzt ein Large Language Model (LLM), um eine Sequenz von Wegpunkten zu generieren, zwischen denen dann der A*-Algorithmus kürzere, lokale Pfade sucht. Obwohl dieser Ansatz den globalen Suchraum reduziert, identifizierten die Forscher drei wesentliche Engpässe, die seine Leistung auf großen Karten (definiert als N ≥ 200, wobei N die Kantenlänge des Gitters ist) limitieren:

• Die Verwendung linearer Listen für die OPEN– und CLOSED-Mengen (im Prinzip die Listen der möglichen und der bereits besuchten Wegpunkte) im A*-Algorithmus führt zu einer hohen Zeitkomplexität bei Such- und Einfügeoperationen.
• Die global geführten Listen wachsen mit der Kartengröße stark an, was zu einem hohen Speicherverbrauch führt.
• LLMs neigen zur „räumlichen Illusion“ und generieren stochastische Wegpunkte, die redundant sein oder von der optimalen Route abweichen können, was den nachfolgenden A*-Suchprozess ineffizient macht.

Der von dem Team vorgestellte Algorithmus iLLM-A* (innovative LLM-enhanced A*) begegnet diesen drei Punkten mit gezielten Optimierungen:

• Die CLOSED-Liste wurde durch eine Hash-basierte Datenstruktur ersetzt. Dies reduziert die Komplexität der Abfrage, ob ein Knoten bereits expandiert wurde, von der Größenordnung O(N) auf durchschnittlich O(1).
• Eine verzögerte Aktualisierungsstrategie für die Heuristikwerte in der OPEN-Liste vermeidet kostspielige Neuberechnungen für den gesamten Listenumfang.
• Die Forscher setzen eine zweistufige Kollisionserkennung ein. Zunächst prüft ein rechenschonender Test mittels Axis-Aligned Bounding Boxes (AABB) auf potenzielle Kollisionen. Nur bei Überschneidung der Bounding Boxes wird eine präzise, aber aufwendigere Kollisionsprüfung durchgeführt.

Inkrementelles Lernen zur Erzeugung von Wegpunkten

Um die Qualität der vom LLM generierten Wegpunkte zu verbessern, haben die Forscher einen dynamischen Lernprozess implementiert: Dazu nutzt das System eine erweiterbare Few-Shot-Beispieldatenbank. Nachdem das LLM für eine Trainingskarte Wegpunkte generiert und der Algorithmus einen Pfad geplant hat, wird dieser Pfad anhand vordefinierter Metriken evaluiert. Diese Kriterien umfassen die Abweichung von der optimalen Pfadlänge sowie den Zeit- und Speicherverbrauch im Vergleich zu einer reinen A*-Lösung. Nur wenn der geplante Pfad die Qualitäts-Schwellenwerte erfüllt, wird das Paar aus Karte und generierten Wegpunkten als valides Beispiel in die Datenbank aufgenommen. Dies ermöglicht dem LLM, seine Strategie zur Wegpunkterzeugung iterativ an diverse Umgebungen anzupassen.

Empirisch fundierte Selektion der Wegpunkte

Eine empirische Untersuchung der Forscher zeigte, dass eine hohe Anzahl von Wegpunkten den Rechenaufwand überproportional erhöht, ohne die Pfadqualität signifikant zu verbessern. Basierend auf diesen Ergebnissen wurde eine einfache, effektive Auswahlregel implementiert: Wenn das LLM mehr als zwei Wegpunkte generiert, verwenden sie für die anschließende A*-Suche ausschließlich die ersten beiden Wegpunkte, die am nächsten zum Startpunkt liegen. Dadurch minimiert sich die Anzahl der auszuführenden A*-Suchläufe und damit der Gesamtaufwand erheblich.

Die Evaluation auf verschiedenen Kartengrößen (N = 50 bis 450) zeigte laut den Forschern eine deutliche Überlegenheit von iLLM-A* gegenüber den Vergleichsmethoden (A*, Opt-A*, LLM-A*). iLLM-A* erzielte in den Untersuchungen bei der Suchzeit des kürzesten Wegs eine durchschnittliche Beschleunigung um den Faktor 1000 im Vergleich zu LLM-A*. In extremen Fällen lag die Beschleunigung sogar bei einem Faktor von knapp 2350 gegenüber LLM-A*. Der Speicherbedarf konnte um bis zu 58,6 Prozent im Vergleich zu LLM-A* reduziert werden. Auf einer Karte mit N=450 benötigte iLLM-A* 3,62 MByte, während der optimierte A*-Algorithmus (Opt-A*) allein 28,67 MByte belegte. Ferner wiesen die von iLLM-A* generierten Pfade eine geringere durchschnittliche Abweichung von der optimalen Länge auf (104,39 Prozent vs. 107,94 Prozent bei LLM-A*). Dabei war die Standardabweichung der Pfadlänge signifikant geringer, was auf eine höhere Stabilität und Vorhersagbarkeit der Ergebnisse hindeute, sagt das Forschungsteam.

Sollte sich diese massive Reduktion von Rechenzeit und Speicherbedarf auf die Wegfindung in komplexen Umgebungen anwenden lassen, eröffnet dies weitreichende Anwendungsmöglichkeiten. Konkrete Szenarien reichen von der dynamischen Navigation autonomer Roboter in der Logistik über die intelligente Steuerung von Charakteren in großen Videospielwelten bis zu schnellen Simulationen in digitalen Zwillingen.

(vza)

Nach dem dritten und finalen Release Candidate will die Python Software Foundation am 7. Oktober die stabile Version 3.14 der Programmiersprache veröffentlichen. Sie erhält Support bis Oktober 2027 und wird bis Oktober 2030 mit Sicherheitspatches versorgt.

Version 3.14 der Open-Source-Sprache wartet mit Neuerungen wie Template Strings (T-Strings) und Lazy Annotations auf. Dazu kommen zahlreiche in der Verständlichkeit verbesserte Fehlermeldungen. Diese fokussieren sich auf die häufigsten Fehler der Python-Entwicklerinnen und -Entwickler. Das soll verhindern, dass das Debugging in Detektivarbeit ausartet.

Außerdem ist der in Version 3.13 eingeführte Free-Threaded-Modus mit der neuen Version nun offiziell freigegeben.

Error: Konkrete Verbesserungsvorschläge

Die verbesserten Fehlermeldungen von Python 3.14 berücksichtigen die Fehlermeldungstypen SyntaxError, ValueError sowie TypeError, erklären jeweils genauer als zuvor, was falsch ist, und machen darüber hinaus gleich Verbesserungsvorschläge.

Ein Beispiel dafür sind die neuen elif-nach-else-Fehlermeldungen: Folgt ein elif-Block nach einem else-Block, meldet Python jetzt explizit, dass dies nicht erlaubt ist. Die Fehlermeldung weist zudem auf die korrekte Reihenfolge von if, elif und else hin.

Das Codebeispiel:

>>> if x > 0:
...     print("positiv")
... else:
...     print("nicht positiv")
... elif x == 0:  # ungültig!
...     print("zero")
...

liefert in Version 3.13 die wenig aussagekräftige Fehlermeldung

SyntaxError: invalid syntax

in Version 3.14 hingegen:

SyntaxError: 'elif' block follows an 'else' block

Ein weiteres Beispiel: Fehlende oder falsch gesetzte Anführungszeichen in Strings führen bei Python 3.14 jetzt zu einer gezielten Frage. Anstatt sich auf „invalid syntax“ zu beschränken, folgt in der Fehlermeldung nun noch der Zusatz „Is this intended to be part of the string?“

String-Platzhalter und komfortablere REPL

Mit Python 3.14 halten auch neue Funktionen wie Template Strings (T-Strings), Lazy Annotations sowie REPL-Autovervollständigung und -Syntax-Highlighting Einzug.

• Template Strings: Die neue String-Präfix-Option 't' erlaubt es, einen Platzhalter zu definieren, der später mit .substitute() oder .format_map() ersetzt werden kann. Nützlich sind die T-Strings zum Beispiel für Konfigurationsdateien und Templates. Außerdem erlauben sie eine sichere Verarbeitung von Nutzereingaben
• Lazy Annotations: Damit wertet Python 3.14 Typ-Annotationen nicht mehr sofort beim Laden eines Moduls aus. Stattdessen werden sie als Strings gespeichert und erst bei Bedarf analysiert, was unter anderem Importproblemen entgegenwirken kann.
• REPL-Autovervollständigung und -Syntax-Highlighting: Diese beiden Funktionen sind bei Version 3.14 in der REPL-Konsole (Read-Evaluate-Print-Loop) standardmäßig aktiviert und sollen es ermöglichen, den Code leichter zu lesen und in der interaktiven Shell effizienter zu programmieren.

Einen Überblick über sämtliche Neuerungen von Python 3.14 liefert die Seite zum Release Candidate.

(who)