Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #653370

Re: US-Wirtschaftswachstum 4,3%

Show all headers | View raw

Salve allerseits,

Dr. Joachim Neudert schrieb:
> Am 25.12.25 um 09:28 schrieb Fidel Sebastián Hunrichse-Lara:
>> Michael Bode schrieb:
>>> "Dr. Joachim Neudert" <neudert@5sl.org> writes:
>>>> Am 24.12.25 um 14:41 schrieb Walter Brill:
>>>>
>>>>> Am Radio hiess es noch: "1 Programmierer + KI würden 10 IT-ler ersetzen".
>>>>
>>>> Eher 20 oder 30, meinst Du?
>>>
>>> So what? Vor 100 Jahren gab es im Deutschen Reich um die 22 Millionen
>>> Erwerbstätige. Danach gab es wohl einige Rationalisierungswellen durch den
>>> technischen Fortschritt. Das Ergebnis war eine Reduktion der Arbeitsplätze von
>>> 22 Millionen auf 46 Millionen in 2025. Falls jemand damals wahlweise die
>>> Massenarbeitslosigkeit oder das wir-werden-nicht-mehr-arbeite-müssen
>>> prophezeit hat, lag er grandios daneben.
>> 
>> | Vor einigen Monaten habe ich an dieser Stelle beschrieben, wie
>> | künstliche Intelligenz die Softwareentwicklung verändert und warum
>> | bestimmte Tätigkeiten in diesem Berufsfeld mittelfristig wegfallen
>> | werden. Die Reaktionen darauf waren gemischt: von Zustimmung über
>> | Skepsis bis hin zu offener Ablehnung. Doch eine Frage tauchte in den
>> | Kommentaren und in Gesprächen auf Konferenzen immer wieder auf: Wenn KI
>> | tatsächlich Code schreiben kann, was bleibt dann für Menschen übrig?
>> |
>> | Diese Frage ist berechtigt. Sie verdient eine ehrliche Antwort. Und
>> | diese Antwort führt uns zu einem Thema, das in der Debatte um KI in der
>> | Softwareentwicklung oft zu kurz kommt: die Rolle der Architektur, des
>> | Domänenwissens und der konzeptuellen Arbeit. Meine These lautet: Diese
>> | Bereiche werden nicht weniger wichtig, sondern wichtiger. Die
>> | Wertschöpfung verschiebt sich von der Umsetzung zur Konzeption. Und
>> | genau das hat weitreichende Konsequenzen für alle, die in diesem Feld
>> | arbeiten, von der Entwicklerin am Anfang ihrer Karriere bis zur
>> | Führungskraft, die Investitionsentscheidungen trifft.
>> |
>> | *Was KI heute kann und was nicht*
>> |
>> | Beginnen wir mit einer ehrlichen Bestandsaufnahme dessen, was moderne
>> | KI-Systeme im Bereich der Softwareentwicklung leisten. Die Fortschritte
>> | der letzten zwei Jahre sind beeindruckend, und wer sie leugnet, macht
>> | sich etwas vor. LLMs (Large Language Models) können heute Funktionen,
>> | Klassen und ganze Module auf Zuruf generieren. Sie erkennen Muster in
>> | bestehendem Code und wenden Best Practices an, ohne dass man sie
>> | explizit darauf hinweisen muss. Sie schreiben Tests, die tatsächlich
>> | sinnvolle Randfälle abdecken. Sie erstellen Dokumentation, die oft
>> | besser ist als das, was überarbeitete Entwickler um 23 Uhr produzieren.
>> | Sie schlagen Refactorings vor, die technische Schulden reduzieren.
>> |
>> | Wer heute mit GitHub Copilot, Claude, ChatGPT oder ähnlichen Werkzeugen
>> | arbeitet, erlebt täglich, wie viel Routinearbeit diese Systeme abnehmen
>> | können. Eine REST-API mit Standard-CRUD-Operationen, die früher einen
>> | halben Tag gekostet hätte, entsteht in dreißig Minuten. Ein
>> | Datenmigrationsskript, für das man früher Stack Overflow durchsucht
>> | hätte, generiert sich fast von selbst. Das ist real, das ist nützlich,
>> | und es wird noch besser werden.
>> |
>> | Das ist die beeindruckende Seite. Und sie wird noch beeindruckender
>> | werden. Die Modelle werden besser, die Integration in
>> | Entwicklungsumgebungen wird nahtloser, die Anwendungsfälle werden
>> | breiter. Wer glaubt, dass wir den Höhepunkt dieser Entwicklung bereits
>> | erreicht haben, unterschätzt das Tempo des Fortschritts.
>> |
>> | Doch es gibt auch blinde Flecken, die bei aller Euphorie nicht übersehen
>> | werden dürfen. Und diese Flecken werden nicht kleiner, wenn die Modelle
>> | größer werden – denn sie sind struktureller Natur.
>> |
>> | KI-Systeme arbeiten auf der Ebene von Syntax und Mustern. Sie haben
>> | gelernt, welche Codezeilen typischerweise auf welche anderen folgen. Sie
>> | wissen, wie ein Repository-Pattern in C# aussieht, weil sie Zehntausende
>> | davon gesehen haben. Aber sie wissen nicht, warum ein bestimmtes System
>> | dieses Pattern verwenden sollte, oder ob es überhaupt das Richtige ist.
>> | Sie kennen die Form, nicht die Bedeutung.
>> |
>> | Das zeigt sich besonders deutlich bei Halluzinationen. Ein LLM kann eine
>> | Funktion generieren, die syntaktisch korrekt ist, alle Konventionen
>> | einhält und auf den ersten Blick vernünftig aussieht, aber inhaltlich
>> | falsch ist. Nicht, weil das Modell lügt, sondern weil es gar nicht weiß,
>> | was „richtig“ in einem bestimmten fachlichen Kontext bedeutet. Es
>> | optimiert Wahrscheinlichkeiten für Zeichenfolgen, nicht für
>> | Geschäftslogik. Es produziert, was statistisch plausibel ist, nicht was
>> | sachlich korrekt ist.
>> |
>> | Hinzu kommt das Problem des lokalen Optimums: KI optimiert das
>> | Offensichtliche. Wenn Sie nach einer Lösung für ein Problem fragen,
>> | bekommen Sie die wahrscheinlichste Lösung basierend auf den
>> | Trainingsdaten. Das ist oft eine gute Lösung. Aber es ist selten die
>> | beste Lösung für Ihren spezifischen Kontext, denn den kennt das Modell
>> | nicht. Es weiß nicht, dass Ihr Team nur aus zwei Personen besteht und
>> | keine Zeit für eine Microservices-Architektur hat. Es weiß nicht, dass
>> | Ihre Datenbank-Performance der eigentliche Engpass ist. Es weiß nicht,
>> | dass der Fachbereich nächstes Jahr alles umwerfen wird.
>> |
>> | Die Schlussfolgerung daraus ist einfach: KI ist ein hervorragendes
>> | Werkzeug für die Umsetzung. Aber das setzt voraus, dass jemand weiß, was
>> | umgesetzt werden soll. Die entscheidende Frage verschiebt sich damit von
>> | „Wie schreibe ich diesen Code?“ zu „Welchen Code sollte ich überhaupt
>> | schreiben?“. Und diese Frage kann KI nicht beantworten.
>> |
>> | *Die Rolle des Architekten neu betrachtet*
>> |
>> | Damit sind wir bei der Architektur. Und hier lohnt es sich, zunächst zu
>> | klären, was dieser Begriff eigentlich bedeutet, denn er wird (zu) oft
>> | missverstanden.
>> |
>> | Architektur ist nicht das Diagramm mit den großen Boxen und Pfeilen, das
>> | in jeder Projektdokumentation auftaucht und nach dem Kick-Off nie wieder
>> | angeschaut wird. Architektur ist auch nicht die Entscheidung für ein
>> | bestimmtes Framework oder eine bestimmte Cloud-Plattform. Architektur
>> | ist vielmehr die Summe der Entscheidungen, die schwer zu ändern sind. Es
>> | sind die Entscheidungen über Struktur, über Kommunikationswege, über
>> | Grenzen zwischen Komponenten, über Verantwortlichkeiten. Es sind die
>> | Entscheidungen, bei denen eine Änderung später teuer wird, sei es
>> | technisch, organisatorisch oder beides.
>> |
>> | Diese Entscheidungen sind aus mehreren Gründen nicht automatisierbar.
>> | Und diese Gründe werden auch nicht verschwinden, wenn die Modelle größer
>> | werden.
>> |
>> | Erstens erfordern Architekturentscheidungen Kontextwissen, das nicht im
>> | Code steht. Um zu entscheiden, ob ein System als Monolith oder als
>> | verteiltes System gebaut werden sollte, muss man die Organisation
>> | kennen, die es betreibt. Wie groß ist das Team? Wie sind die
>> | Deployment-Zyklen? Welche Teile des Systems ändern sich häufig, welche
>> | selten? Wie sieht die bestehende Infrastruktur aus? Welche Kompetenzen
>> | sind vorhanden, welche fehlen? Diese Informationen stehen in keinem
>> | Repository. Sie existieren in Köpfen, in Gesprächen, in der gelebten
>> | Praxis einer Organisation.
>> |
>> | Zweitens erfordern Architekturentscheidungen Abwägungen zwischen
>> | konkurrierenden Zielen. Soll das System maximal performant sein oder
>> | maximal wartbar? Soll es schnell ausgeliefert werden oder langfristig
>> | stabil sein? Soll es flexibel erweiterbar sein oder einfach zu
>> | verstehen? Diese Trade-offs haben keine objektiv richtige Antwort. Sie
>> | hängen von Prioritäten ab, die Menschen setzen müssen, basierend auf
>> | Geschäftszielen, Ressourcen und Risikobereitschaft.
>> |
>> | Drittens erfordern sie Voraussicht. Was könnte sich in zwei Jahren
>> | ändern? Welche Annahmen, die wir heute treffen, werden sich als falsch
>> | herausstellen? Welche Teile des Systems müssen flexibel bleiben, welche
>> | dürfen in Beton gegossen werden? Wo lohnt sich Investition in
>> | Abstraktion, wo ist sie Over-Engineering? Diese Fragen erfordern
>> | Erfahrung, Intuition und die Fähigkeit, mit Unsicherheit umzugehen. Sie
>> | erfordern das, was erfahrene Architekten „Bauchgefühl“ nennen: eine
>> | internalisierte Mustererkennung, die sich nicht in Regeln fassen lässt.
>> |
>> | Viertens erfordern sie Dialog. Architektur entsteht nicht im stillen
>> | Kämmerlein. Sie entsteht im Gespräch mit Fachbereichen, mit
>> | Stakeholdern, mit dem Entwicklungsteam. Sie erfordert die Fähigkeit,
>> | zuzuhören, nachzufragen, zwischen verschiedenen Welten zu übersetzen.
>> | Ein Architekt muss verstehen, was der Vertrieb meint, wenn er von
>> | „flexiblen Rabatten“ spricht, und das in eine technische Struktur
>> | übersetzen. Diese Übersetzungsleistung ist zutiefst menschlich.
>> |
>> | Es gibt noch einen fünften Punkt, der oft übersehen wird:
>> | Architekturentscheidungen sind soziale Akte. Sie formen Teams, sie
>> | definieren Schnittstellen zwischen Menschen, sie beeinflussen, wer mit
>> | wem zusammenarbeiten muss. Die Entscheidung, ein System in drei Services
>> | aufzuteilen, ist nicht nur eine technische Entscheidung. Sie ist auch
>> | eine Entscheidung darüber, wie die Arbeit verteilt wird, welche Teams
>> | entstehen, wie Kommunikation fließt. Diese organisatorischen
>> | Implikationen zu verstehen und zu gestalten, erfordert
>> | Einfühlungsvermögen und politisches Gespür. All das sind Eigenschaften,
>> | die kein Sprachmodell besitzt.
>> |
>> | Ein LLM kann das Observer Pattern implementieren. Aber es kann nicht
>> | entscheiden, wann dieses Pattern die richtige Wahl ist. Es kann
>> | Microservices generieren. Aber es kann nicht beurteilen, ob
>> | Microservices für eine bestimmte Organisation überhaupt sinnvoll sind,
>> | oder ob sie die Komplexität nur verlagern, statt sie zu reduzieren. Die
>> | wertvollste Architekturentscheidung ist oft die Entscheidung, etwas
>> | nicht zu bauen. Und genau diese Entscheidung liegt außerhalb dessen, was
>> | ein generatives Modell leisten kann.
>> |
>> | *Kein LLM kennt die Domäne*
>> |
>> | Das führt uns zum zweiten Bereich, der durch KI nicht ersetzt wird: das
>> | Domänenwissen.
>> |
>> | Jede Software existiert, um ein Problem in einer bestimmten Domäne zu
>> | lösen. Ein Bestellsystem löst Probleme im E-Commerce. Eine Patientenakte
>> | löst Probleme im Gesundheitswesen. Eine Handelssoftware löst Probleme an
>> | den Finanzmärkten. Eine Produktionssteuerung löst Probleme in der
>> | Fertigung. Die Software ist nie Selbstzweck. Sie ist immer Mittel zu
>> | einem fachlichen Zweck. Diese Erkenntnis klingt banal, wird aber in der
>> | Praxis erstaunlich oft vergessen.
>> |
>> | Um gute Software zu bauen, muss man diesen Zweck verstehen. Man muss die
>> | Domäne verstehen. Und genau hier stößt KI an eine fundamentale Grenze,
>> | die sich nicht durch größere Modelle oder bessere Trainingsdaten
>> | überwinden lässt.
>> |
>> | LLMs wurden auf öffentlich verfügbarem Text trainiert. Sie kennen, was
>> | über Domänen geschrieben wurde. Sie kennen die allgemeinen Konzepte von
>> | Bestellungen, Patienten, Handelspositionen, Fertigungsaufträgen. Aber
>> | sie kennen nicht die spezifische Logik eines bestimmten Unternehmens.
>> | Sie wissen nicht, dass in Ihrem Unternehmen eine „Bestellung“ drei
>> | verschiedene Zustände haben kann, die nirgendwo dokumentiert sind, weil
>> | das historisch so gewachsen ist. Sie wissen nicht, dass der Begriff
>> | „Kunde“ in der Buchhaltung etwas anderes bedeutet als im Vertrieb. Sie
>> | wissen nicht, dass bestimmte Produkte aus regulatorischen Gründen anders
>> | behandelt werden müssen als andere.
>> |
>> | Die richtige Frage ist nicht „Wie baue ich ein Bestellsystem?“. Die
>> | richtige Frage ist: „Was bedeutet eine Bestellung in diesem Geschäft?
>> | Wann beginnt sie? Wann endet sie? Was passiert, wenn sie storniert wird?
>> | Was passiert, wenn sie teilweise geliefert wird? Wer darf sie ändern,
>> | und unter welchen Bedingungen? Welche Ereignisse in der Domäne sind
>> | relevant, welche nicht?“
>> |
>> | Diese Fragen lassen sich nicht durch Prompt-Engineering beantworten. Sie
>> | erfordern Gespräche mit Fachexperten. Sie erfordern das geduldige
>> | Herausarbeiten von implizitem Wissen, das oft nicht einmal den
>> | Fachleuten selbst bewusst ist. Es ist Wissen, das in Routinen steckt, in
>> | Ausnahmen. In den Geschichten, die erzählt werden, wenn etwas
>> | schiefgelaufen ist. Dieses Wissen sichtbar zu machen, erfordert Methoden
>> | wie Event-Storming oder Collaborative Modeling, bei denen Menschen
>> | gemeinsam an einem Whiteboard stehen und rekonstruieren, was in ihrer
>> | Domäne eigentlich passiert.
>> |
>> | Das ist zutiefst menschliche Arbeit. Es ist Arbeit, die Geduld
>> | erfordert, die Ambiguitätstoleranz verlangt, die manchmal frustrierend
>> | ist, weil die Antworten nicht sofort klar sind. Es ist Arbeit, die man
>> | nicht beschleunigen kann, indem man schneller tippt. Und genau deshalb
>> | wird sie durch KI nicht obsolet, sondern im Gegenteil: Je mehr die
>> | Umsetzung automatisiert wird, desto wichtiger wird es, das Richtige
>> | umzusetzen. Und um das Richtige zu identifizieren, benötigt man
>> | Domänenwissen.
>> |
>> | Ich erlebe in meiner Beratungsarbeit regelmäßig, dass Projekte
>> | scheitern, nicht weil die Technik schlecht wäre, sondern weil niemand
>> | die richtigen Fragen gestellt hat. Das neue System wurde gebaut, es
>> | funktioniert technisch einwandfrei – aber es bildet die falschen
>> | Prozesse ab, verwendet die falschen Begriffe, macht die falschen
>> | Annahmen. Das sind keine Fehler, die KI verhindern wird. Es sind Fehler,
>> | die entstehen, wenn man die Domäne nicht versteht. Und sie werden
>> | häufiger werden, wenn die Illusion entsteht, dass schnelle
>> | Codegenerierung auch schnelles Verstehen bedeutet.
>> |
>> | *Die neue Arbeitsteilung*
>> |
>> | Was bedeutet das alles für die Praxis? Wie verändert sich die
>> | Arbeitsteilung in der Softwareentwicklung? Diese Fragen höre ich oft,
>> | und die Antworten sind weniger düster, als manche befürchten.
>> | Vorausgesetzt, man versteht die Richtung der Veränderung.
>> |
>> | Zunächst das Offensichtliche: Routineaufgaben werden schneller und
>> | günstiger. Code, der früher Stunden gebraucht hat, entsteht heute in
>> | Minuten. Die Einstiegshürde „etwas zu bauen“ sinkt dramatisch. Das ist
>> | grundsätzlich positiv. Es demokratisiert den Zugang zur
>> | Softwareentwicklung und ermöglicht schnellere Experimente. Ideen können
>> | ausprobiert werden, bevor man sich auf eine teure Implementierung
>> | festlegt.
>> |
>> | Aber es birgt auch eine Gefahr: die Gefahr, das Falsche sehr effizient
>> | zu bauen. Wenn es einfach wird, Code zu generieren, besteht die
>> | Versuchung, sofort loszulegen, ohne vorher gründlich nachzudenken. Das
>> | Ergebnis sind Systeme, die technisch funktionieren, aber am eigentlichen
>> | Bedarf vorbeigehen. Oder Systeme, die kurzfristig funktionieren, aber
>> | langfristig nicht wartbar sind. Die Geschwindigkeit der Codegenerierung
>> | kann eine trügerische Sicherheit vermitteln. Man fühlt sich produktiv,
>> | obwohl man eigentlich nur schneller in die falsche Richtung läuft.
>> |
>> | Bestimmte Fähigkeiten werden in dieser neuen Welt wichtiger:
>> |
>> | • Abstraktionsfähigkeit: die Fähigkeit, das Wesentliche vom
>> |   Unwesentlichen zu trennen, komplexe Sachverhalte auf ihre Kernstruktur
>> |   zu reduzieren.
>> |
>> | • Kommunikationsfähigkeit: die Fähigkeit, zwischen Fachbereich und
>> |   Technik zu übersetzen, Anforderungen zu verstehen und technische
>> |   Implikationen zu erklären.
>> |
>> | • Urteilsvermögen: die Fähigkeit zu entscheiden, wann KI hilft und wann
>> |   sie schadet, wann man ihrem Output vertrauen kann und wann eine
>> |   manuelle Prüfung nötig ist.
>> |
>> | • Systemdenken: die Fähigkeit, Wechselwirkungen zu verstehen, nicht nur
>> |   einzelne Komponenten isoliert zu betrachten.
>> |
>> | Andere Fähigkeiten verlieren an Bedeutung. APIs und Syntax auswendig zu
>> | kennen, wird weniger wertvoll, wenn man jederzeit nachfragen kann.
>> | Boilerplate-Code zu schreiben war nie besonders erfüllend und wird
>> | künftig noch weniger nötig sein. Routine-Debugging bei Standardproblemen
>> | lässt sich zunehmend automatisieren. Das ist kein Verlust, sondern eine
>> | Befreiung, vorausgesetzt, man nutzt die gewonnene Zeit für wertvollere
>> | Tätigkeiten.
>> |
>> | Eine besondere Warnung möchte ich an dieser Stelle aussprechen: Hüten
>> | Sie sich vor der Prompt-Engineering-Illusion. Die Vorstellung, dass man
>> | nur „die richtige Frage stellen“ müsse, um von KI perfekte Ergebnisse zu
>> | bekommen, ist gefährlich. Ja, gute Prompts führen zu besseren
>> | Ergebnissen. Aber wer die richtige Frage nicht kennt, bekommt
>> | bestenfalls plausible Antworten auf die falsche Frage. Prompt
>> | Engineering ersetzt kein Domänenwissen. Es setzt es voraus. Wer nicht
>> | versteht, was gebaut werden soll, kann auch nicht sinnvoll danach fragen.
>> |
>> | *Was jetzt zu tun ist*
>> |
>> | Lassen Sie mich mit konkreten Empfehlungen schließen.
>> |
>> | Für Entwicklerinnen und Entwickler: Nutzen Sie KI als Werkzeug, nicht
>> | als Ersatz für das Denken. Lassen Sie sich Routinearbeit abnehmen, aber
>> | geben Sie die Verantwortung für das Ergebnis nicht ab. Prüfen Sie
>> | generierten Code kritisch, verstehen Sie ihn, bevor Sie ihn committen.
>> | Investieren Sie in Architektur und Domänenwissen, nicht nur in
>> | Technologie. Lernen Sie, mit Fachbereichen auf Augenhöhe zu sprechen.
>> | Kultivieren Sie die Fähigkeit, Anforderungen zu hinterfragen, statt sie
>> | blind umzusetzen. Die Frage „Warum benötigen wir das?“ ist wertvoller
>> | als die Frage „Wie bauen wir das?“.
>> |
>> | Für Führungskräfte und Unternehmen: Widerstehen Sie der Versuchung,
>> | „alles mit KI zu machen“. Die Technologie ist mächtig, aber sie ist kein
>> | Ersatz für Nachdenken. Erkennen Sie Architektur- und Domänenkompetenz
>> | als strategisches Asset. Diese Fähigkeiten lassen sich nicht kurzfristig
>> | einkaufen oder durch Tools ersetzen. Sie entstehen über Jahre, durch
>> | Erfahrung, durch Fehler, durch intensive Beschäftigung mit einer Domäne.
>> | Investieren Sie in Menschen, die verstehen, nicht nur in Tools, die
>> | generieren. Und stellen Sie sich regelmäßig die Frage: Wissen wir
>> | eigentlich, was wir bauen wollen? Wenn die Antwort unklar ist, wird auch
>> | die beste KI nicht helfen.
>> |
>> | Für die Ausbildung: Der Fokus auf Syntax und Programmiersprachen wird
>> | weniger wichtig. Konzepte, Modellierung und Abstraktion werden
>> | wichtiger. Interdisziplinäres Denken sollte gefördert werden, also die
>> | Fähigkeit, technische und fachliche Perspektiven zu verbinden. Und vor
>> | allem: die Fähigkeit, mit Unsicherheit umzugehen. Denn in einer Welt, in
>> | der sich Technologie schnell verändert, ist die Bereitschaft zum
>> | lebenslangen Lernen wichtiger als jedes spezifische Wissen. Die
>> | Absolventen von heute werden in ihrer Karriere Technologien nutzen, die
>> | heute noch nicht existieren. Was bleibt, sind die Grundlagen: logisches
>> | Denken, Abstraktion, Kommunikation.
>> |
>> | *Der Mensch als Bedeutungsgeber*
>> |
>> | Die Entwicklung, die wir gerade erleben, ist keine Bedrohung, sondern
>> | eine Verschiebung. Dabei wandert die Wertschöpfung von der Umsetzung zur
>> | Konzeption. Die Frage ist nicht mehr „Können wir das bauen?“, denn das
>> | können wir fast immer, und es wird immer einfacher. Die Frage ist:
>> | „Sollten wir das bauen? Und wenn ja, was genau? Für wen? Mit welchem
>> | Ziel?“
>> |
>> | Diese Fragen zu beantworten, erfordert etwas, das KI nicht hat: ein
>> | Verständnis von Bedeutung. Software ist nicht nur Code. Sie ist ein
>> | Ausdruck von Geschäftslogik, von Prozessen, von menschlichen
>> | Bedürfnissen. Sie bildet ab, wie Menschen arbeiten, wie sie
>> | kommunizieren, wie sie Entscheidungen treffen. Den Sinn hinter dem Code
>> | zu verstehen und zu gestalten, das bleibt menschliche Arbeit.
>> |
>> | Architekten, Domänenexperten und konzeptuelle Denker werden in dieser
>> | neuen Welt nicht weniger gebraucht. Sie werden mehr gebraucht. Denn je
>> | leichter es wird, irgendetwas zu bauen, desto wichtiger wird es, das
>> | Richtige zu bauen. Die Fähigkeit, das Richtige zu identifizieren, wird
>> | zur Kernkompetenz. Und diese Kompetenz ist nicht angeboren. Sie lässt
>> | sich entwickeln. Wer heute anfängt, in Architekturdenken und
>> | Domänenverständnis zu investieren, wird in fünf Jahren einen erheblichen
>> | Vorsprung denen gegenüber haben, die nur auf das nächste Tool warten.
>> |
>> | Software war nie Selbstzweck. Sie war immer Mittel zu einem Zweck. Und
>> | den Zweck definieren Menschen. Das war vor dreißig Jahren so, das ist
>> | heute so, und das wird auch in zehn Jahren noch so sein – egal, wie
>> | leistungsfähig die Modelle dann geworden sind.
>> |
>> | Die gute Nachricht ist: Wer diese Verschiebung versteht und sich darauf
>> | einstellt, hat eine glänzende Zukunft. 
> 
> Alles nur klassische Rückzugsgefechte. Wetten, während dieser Artikel 
> ersonnen, geschrieben, redigiert und publiziert wurde, ist schon wieder 
> einer der zitierten Bausteine an die KI gefallen?
>
+--- <hier abknabbern> ---
| Mitten im Meeting Englisch sprechen, während das Gegenüber die Worte in
| perfektem Spanisch hört – in Echtzeit. Was lange als Science-Fiction
| galt, rollt Google nun mit Meet und auf Pixel-Geräten aus. Hinter der
| Funktion steckt dieselbe KI, die auch Gemini antreibt – und ein
| komplexes Zusammenspiel spezialisierter Übersetzungsmodelle und
| generativer Sprach-Module.
|
| Wir haben mit Googles Director Product Management, Niklas Blum, über die
| zugrunde liegende Technik gesprochen: Wie funktioniert die
| End-to-End-Sprachübersetzung, die sogar die Originalstimme erhält? Wie
| arbietet das internationale Team? Und wo liegen die größten Hürden bei
| der Übersetzung von gesprochener Sprache?
|
| Mit Google Meet kann jeder in einer anderen Sprache sprechen – in
| Echtzeit. Das klappt mittels KI, konkret ist es derselbe Übersetzer wie
| in Gemini. Wie funktioniert das? Was passiert in dem Modell?
|
| Aktuell setzen wir spezialisierte Modelle für die Übersetzung und Gemini
| für die Sprachgenerierung ein. Diese Architektur setzt auf das
| AudioLM-Framework sowie Transformer-Blöcke und ist darauf ausgelegt,
| kontinuierliche Audioströme zu verarbeiten. Das ermöglicht es dem
| Modell, selbstständig zu entscheiden, wann die Übersetzung ausgegeben
| wird. Wir haben dazu kürzlich einen technischen Research-Blogpost
| veröffentlicht, der die Funktionsweise dieser End-to-End
| Speech-to-Speech Translation (S2ST) unter Beibehaltung der
| Originalstimme erläutert.
|
| Wie kommt es, dass an dem Echtzeit-Übersetzer ein Team aus Deutschland
| arbeitet?
|
| Unser Team und unsere Kunden sind global aufgestellt. Die Teams, die an
| diesem Feature arbeiten, verteilen sich auf Berlin, Stockholm, Zürich,
| New York und Mountain View. Das Google-Team in Stockholm ist dabei ein
| zentraler Hub für Googles Echtzeitkommunikation.
|
| Wofür lässt sich der Echtzeit-Übersetzer bisher nutzen? Er ist in Google
| Meet verfügbar, aber wo kommt er noch zum Einsatz, was ist geplant?
|
| Die Technologie zur Echtzeit-Übersetzung ist auch auf Pixel-10-Geräten
| für Anrufe und in Google Translate verfügbar. Bei Google Meet
| konzentrieren wir uns speziell auf Anwendungsfälle für
| Echtzeit-Gespräche in Unternehmen, die in verschiedenen Märkten tätig
| sind und mit Sprachbarrieren zu tun haben. Wir glauben, dass diese
| Technologie, auch wenn sie noch am Anfang steht, sich rasant
| weiterentwickeln wird. Echtzeit-Übersetzungen haben das Potenzial,
| Menschen zu verbinden und Gespräche zu ermöglichen, die so vorher kaum
| realisierbar waren.
|
| *Der Übersetzer ist ein „Lookahead*“
|
| Gesprochene Sprache ist fehlerhafter als geschriebene Sprache. Wie geht
| das Modell damit um? Wird eins zu eins übersetzt, also auch jedes “ähm”
| und im Zweifelsfall ein abgebrochener Satz? Denn so sprechen wir
| manchmal ja. Oder zieht der Echtzeit-Übersetzer auch Schlüsse und
| bereinigt die Sprache quasi?
|
| Unser Modell zur Echtzeit-Übersetzung nutzt Transformer-Blöcke und
| besteht aus zwei Hauptkomponenten: einem Streaming-Encoder, der die
| Quell-Audiodaten basierend auf den vorangegangenen zehn Sekunden der
| Eingabe zusammenfasst, und einem Streaming-Decoder. Letzterer sagt das
| übersetzte Audio autoregressiv vorher und nutzt dabei den komprimierten
| Encoder-Status sowie Vorhersagen aus früheren Iterationen.
|
| Die Transformer-Blöcke ermöglichen es dem Modell, selbstständig zu
| entscheiden, wann die Übersetzung ausgegeben wird. Basierend auf den
| Trainingsdaten ist das Modell in der Lage, über reine
| Wort-für-Wort-Übersetzungen hinauszugehen. Das ist besonders hilfreich
| bei Redewendungen oder dem Erkennen von Eigennamen. Begriffe wie die
| „Golden Gate Bridge” werden nicht übersetzt.
|
| Was ist die größte Schwierigkeit bei der Übersetzung gesprochener
| Sprache? Wo hapert es vielleicht auch manchmal noch?
|
| Bei der Übersetzung gesprochener Sprache stehen drei wesentliche
| Herausforderungen in Konkurrenz zueinander: Wir wollen eine möglichst
| hohe Übersetzungsqualität, eine minimale Verzögerung und gleichzeitig
| die originale Stimmcharakteristik beibehalten. Für Echtzeit-Gespräche
| wird aktuell eine Standardverzögerung von zwei Sekunden genutzt, was für
| die meisten Sprachen gut funktioniert. Ein längerer „Lookahead“ des
| Modells würde durch den zusätzlichen Kontext zwar die
| Übersetzungsqualität verbessern, beeinträchtigt aber das
| Echtzeit-Erlebnis. Eine optimale Übersetzungsqualität in möglichst
| kurzer Zeit zu erzielen, bleibt die zentrale Herausforderung und ein
| Bereich für weitere Verbesserungen.
|
| Generell haben die Fortschritte bei der KI-Audioverarbeitung und der
| Modellqualität zuletzt große Sprünge gemacht. Das dürfte der Grund sein,
| weshalb branchenweit eine zunehmende Integration von Sprachübersetzung
| in verschiedene Produkte stattfindet.
|
| Es gab eine Zeit, da haben Google und auch andere Anbieter ähnliche
| Übersetzungstools nicht veröffentlicht, weil Missbrauch drohte. Was hat
| sich geändert?
|
| Wir integrieren diese Funktion nun in unsere Produkte, weil die
| Technologie einen gewaltigen Sprung nach vorn gemacht hat. Ich glaube,
| dass es bis vor Kurzem nicht möglich war, wirklich hochwertige
| dialogorientierte Dienste zu entwickeln, die den erforderlichen
| Qualitätsstandards entsprechen.
|
| Wie steht es um die Gefahren vor Missbrauch, vor Deepfakes? Welche
| Schutzmaßnahmen gibt es?
|
| Wir sind natürlich zum Einhalten der geltenden Datenschutzgesetze
| verpflichtet. Im Laufe der Jahre haben wir eng mit Datenschutzbehörden
| auf der ganzen Welt zusammengearbeitet und strenge Datenschutzmaßnahmen
| umgesetzt. So haben wir für Meet klare Richtlinien, wie unser Tool
| genutzt werden darf. Nutzer:innen ist es beispielsweise nicht gestattet,
| Meet zu verwenden, um sich als eine andere Person auszugeben.
+--- </hier abknabbern> ---

©<https://www.heise.de/hintergrund/Google-Echtzeit-Uebersetzer-Mehr-als-Wort-zu-Wort-Uebersetzungen-11122554.html>

	M.f.G.

-- 
Diese E-Mail-Adresse wird nur aus nostalgischen Gründen verwendet. Sie
wird praktisch nie gelesen.  Das MausNet ist nicht tot – es riecht nur
etwas komisch... ;-)

Back to ger.ct | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-23 16:26 +0100
  US-Wirtschaftswachstum (was: US-Wirtschaftswachstum 4,3%) ram@zedat.fu-berlin.de (Stefan Ram) - 2025-12-23 16:00 +0000
    Re: US-Wirtschaftswachstum "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-23 17:21 +0100
      Re: US-Wirtschaftswachstum "Wendelin Uez" <wuez@online.de> - 2025-12-24 12:46 +0100
    Re: US-Wirtschaftswachstum Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-23 17:29 +0100
    Re: US-Wirtschaftswachstum "DER GELAeUTERTE" <dergelaeuterte@web.de> - 2025-12-23 19:46 +0100
  Re: US-Wirtschaftswachstum 4,3% Ruediger Lahl <ruediger.lahl@gmx.de> - 2025-12-23 20:04 +0100
    Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-23 20:31 +0100
      Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-23 21:21 +0100
        Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse-Lara@b.maus.de> - 2025-12-24 10:15 +0100
          Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-24 10:34 +0100
      Re: US-Wirtschaftswachstum 4,3% Ruediger Lahl <ruediger.lahl@gmx.de> - 2025-12-23 22:36 +0100
        Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-23 22:58 +0100
        Re: US-Wirtschaftswachstum 4,3% Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2025-12-27 10:32 +0000
      Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-24 09:52 +0100
        Re: US-Wirtschaftswachstum 4,3% Walter Brill <WalterBrill@t-online.de> - 2025-12-24 14:41 +0100
          Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-24 14:50 +0100
            Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-24 15:41 +0100
              Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-24 15:45 +0100
              Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 09:28 +0100
                Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-25 10:08 +0100
                Re: US-Wirtschaftswachstum 4,3% Bernd Ohm <invalid@invalid.invalid> - 2025-12-25 10:59 +0100
                Re: US-Wirtschaftswachstum 4,3% Dr. Joachim Neudert <neudert@5sl.org> - 2025-12-25 10:22 +0000
                Re: US-Wirtschaftswachstum 4,3% Bernd Ohm <invalid@invalid.invalid> - 2025-12-25 11:48 +0100
                Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 14:52 +0100
                Re: US-Wirtschaftswachstum 4,3% Lars Gebauer <lgebauer@live.de> - 2025-12-25 12:46 +0100
                Re: US-Wirtschaftswachstum 4,3% Ruediger Lahl <ruediger.lahl@gmx.de> - 2025-12-26 09:16 +0000
                Re: US-Wirtschaftswachstum 4,3% Bernd Ohm <invalid@invalid.invalid> - 2025-12-26 12:21 +0100
                Re: US-Wirtschaftswachstum 4,3% Carlo XYZ <carloxyz@invalid.invalid> - 2025-12-26 12:30 +0100
                Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-26 16:44 +0100
                Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 11:48 +0100
            Re: US-Wirtschaftswachstum 4,3% Walter Brill <WalterBrill@t-online.de> - 2025-12-25 12:47 +0100
              Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 12:54 +0100
              Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 14:55 +0100
                Entwickler und KI (was: US-Wirtschaftswachstum 4,3%) Ulrich D i e z <ud.usenetcorrespondence@web.de> - 2025-12-26 17:05 +0100
                Re: Entwickler und KI (was: US-Wirtschaftswachstum 4,3%) Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-26 18:55 +0100
      Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 13:54 +0100
    Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 13:46 +0100
      Re: US-Wirtschaftswachstum 4,3% Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-30 14:58 +0100
        Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-30 15:14 +0100
          Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-30 15:16 +0100
          Re: US-Wirtschaftswachstum 4,3% Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-30 15:29 +0100
        Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 19:27 +0100
          Re: US-Wirtschaftswachstum 4,3% Dr. Joachim Neudert <neudert@5sl.org> - 2025-12-30 19:17 +0000
            Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-30 20:28 +0100
              Re: US-Wirtschaftswachstum 4,3% Dr. Joachim Neudert <neudert@5sl.org> - 2025-12-30 19:51 +0000
                Re: US-Wirtschaftswachstum 4,3% Andreas Bockelmann <xotzil@gmx.de> - 2025-12-31 09:19 +0100
  Re: US-Wirtschaftswachstum 4,3% Lothar Kimmeringer <news201705@kimmeringer.de> - 2025-12-24 19:20 +0100
    Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 09:27 +0100
      Re: US-Wirtschaftswachstum 4,3% "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-12-25 10:17 +0100
        Re: US-Wirtschaftswachstum 4,3% Michael Bode <m.g.bode@web.de> - 2025-12-25 10:26 +0100
        Re: US-Wirtschaftswachstum 4,3% Fidel Sebastián Hunrichse-Lara <Fidel-Sebastian_Hunrichse_Lara@b.maus.de> - 2025-12-25 12:01 +0100
        Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 15:00 +0100
    Re: US-Wirtschaftswachstum 4,3% Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-12-25 14:56 +0100
    Re: US-Wirtschaftswachstum 4,3% Alfred <Dez.2025@anon.invalid> - 2025-12-25 20:57 +0100
  Re: US-Wirtschaftswachstum 4,3% Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-25 18:12 +0100

csiph-web