Kaum ein Begriff wird derzeit so häufig verwendet wie „Künstliche Intelligenz“. Ob in Nachrichten, Marketingbroschüren oder Strategiepapieren – „KI“ soll Unternehmen effizienter, Produkte smarter und ganze Branchen zukunftsfähig machen. Allerdings bleibt oft unklar, was damit konkret gemeint ist. Viele Personen verbinden den Begriff mit futuristischen Vorstellungen von Maschinen, die denken oder gar fühlen können. In der Realität beschreibt „Künstliche Intelligenz“ jedoch ein breites Spektrum an Verfahren und Technologien, die weit weniger mystisch sind.

Diese neunteilige Blogserie widmet sich unterschiedlichen Aspekten von KI. Im ersten Beitrag möchte ich den Begriff KI systematisch aufdröseln, seine Entwicklung nachzeichnen und eine erste Einordnung geben, die die Grundlage für die weiteren Folgen der Serie bildet.

KI, ML, DL – was bedeutet das eigentlich?

Wenn von „KI“ gesprochen wird, ist häufig eine ganze Familie von Verfahren gemeint. Die gebräuchlichsten Abkürzungen sind dabei:

• KI (Künstliche Intelligenz) ist ein Oberbegriff, der alle Ansätze umfasst, Maschinen so zu gestalten, dass sie Aufgaben übernehmen können, die gemeinhin als „intelligent“ gelten. Dazu zählen etwa Sprache verstehen, Probleme lösen, lernen und planen.
• ML (Machine Learning) ist ein Teilbereich der KI, der sich darauf fokussiert, dass Maschinen auf Basis von Daten Muster erkennen und daraus Vorhersagen oder Entscheidungen ableiten.
• DL (Deep Learning) ist wiederum ein Teilbereich des Machine Learning, der komplexe neuronale Netze verwendet, um besonders tiefgehende Muster in Daten zu erkennen.

Maschinelles Lernen und Deep Learning sind also Unterkategorien der Künstlichen Intelligenz. In vielen Diskussionen werden diese Begriffe jedoch unscharf verwendet, was Missverständnisse begünstigt.

Von Expertensystemen zu lernenden Maschinen

Historisch begann die Forschung an Künstlicher Intelligenz nicht mit maschinellem Lernen, sondern mit sogenannten symbolischen Ansätzen. In den 1950er- und 1960er-Jahren entstanden Programme, die Wissen in Form von Regeln und Fakten speicherten. Daraus entwickelten sich später Expertensysteme, die etwa in der medizinischen Diagnose oder technischen Fehleranalyse eingesetzt wurden. Diese Systeme arbeiteten mit klar formulierten Wenn-Dann-Regeln. Ihr Vorteil war, dass ihre Entscheidungen transparent und nachvollziehbar waren. Ihr Nachteil bestand darin, dass sie nicht selbstständig lernen konnten und bei unvollständigem oder unscharfem Wissen schnell an ihre Grenzen stießen.

In den 1980er- und 1990er-Jahren rückte deshalb das maschinelle Lernen stärker in den Vordergrund. Statt einer Maschine explizit zu sagen, wie sie zu entscheiden hat, begann man, ihr Daten zu geben, aus denen sie selbst Regeln ableiten konnte. Damit wurden Systeme möglich, die flexibler auf neue Situationen reagieren konnten.

Ein einfaches Beispiel ist die Spam-Erkennung in E-Mails. Während ein Expertensystem vielleicht nur nach festen Schlüsselwörtern sucht, lernt ein Spam-Filter auf Basis vieler Beispiele von Spam- und Nicht-Spam-Nachrichten, typische Muster zu erkennen. Das erlaubt es, auch neue Formen von Spam zu identifizieren, ohne dass jemand manuell Regeln dafür hinterlegen muss.

Warum „Künstliche Intelligenz“ oft in die Irre führt

Der Begriff „Künstliche Intelligenz“ weckt häufig leicht falsche Assoziationen. Menschen neigen dazu, Maschinen Eigenschaften zuzuschreiben, die diese gar nicht besitzen. Ein Chatbot, der in flüssigen Sätzen antwortet, wirkt schnell so, als „wüsste“ er etwas. Tatsächlich basiert er jedoch lediglich auf komplexen statistischen Modellen, die aus unzähligen Beispielen gelernt haben, welche Wortfolgen wahrscheinlich aufeinanderfolgen.

Auch Programme, die Brettspiele meistern oder Bilder erkennen, verfügen nicht über ein Verständnis im menschlichen Sinne. Sie optimieren ihre Entscheidungen auf der Basis von Mustern in den Daten, ohne dass sie deren Bedeutung begreifen. Daher sprechen manche Fachleute lieber von „statistischer Mustererkennung“ statt von Intelligenz. Das mag sperrig klingen, trifft jedoch den Kern wesentlich besser.

Warum der Hype trotzdem berechtigt ist

Trotz dieser Einschränkungen hat Künstliche Intelligenz in den vergangenen Jahren beeindruckende Fortschritte gemacht. Rechnerische Ressourcen, größere Datenmengen und neue Algorithmen haben dazu geführt, dass Maschinen heute Aufgaben bewältigen können, die vor wenigen Jahren noch als Domäne des Menschen galten. Sprachmodelle wie GPT-4 formulieren Texte, Bildgeneratoren erschaffen fotorealistische Szenen und Algorithmen analysieren in Sekunden medizinische Aufnahmen.

Diese Erfolge beruhen jedoch nicht auf Magie, sondern auf systematischen Verfahren. Wenn Sie verstehen, was hinter Begriffen wie „Machine Learning“ und „Deep Learning“ steckt, können Sie besser einschätzen, was KI-Systeme tatsächlich leisten können – und wo ihre Grenzen liegen. Genau das soll diese Serie leisten.

Wohin die Reise geht

In den folgenden Beiträgen werden wir die verschiedenen Teilgebiete schrittweise vertiefen. Wir werden uns ansehen, wie Maschinen lernen, was neuronale Netze auszeichnet und warum Deep Learning „deep“ ist. Zudem werden wir beleuchten, wie Transformer-Architekturen die Sprachverarbeitung revolutioniert haben und was Large Language Models von früheren Ansätzen unterscheidet.

Das Ziel ist, dass Sie am Ende dieser Serie nicht nur einzelne Schlagworte einordnen können, sondern ein Gesamtverständnis dafür entwickeln, wie die verschiedenen Konzepte zusammenhängen. Damit können Sie fundierter entscheiden, ob und wie Künstliche Intelligenz für Ihre Projekte oder Ihr Unternehmen sinnvoll sein könnte.

Ergänzend zu dieser Serie seien an dieser Stelle die Blogposts von Michael Stal über den Aufbau von Neuronalen Netzen empfohlen.

(rme)

Das Softwareunternehmen JetBrains hat seine .NET- und Spieleentwicklungs-IDE Rider mit Version 2025.2 ausgestattet, ebenso wie die Visual-Studio-Erweiterung ReSharper und die .NET-Tools. In Rider steht damit eine schnellere Version des KI-Coding-Agenten Junie als Beta bereit, während ReSharper nun unter anderem den Out-of-Process-Modus ermöglicht.

Coding mit KI für .NET-Developer

Im neuen Release soll der KI-Coding-Agent Junie um bis zu 30 Prozent schneller sein, mit Remote-Entwicklung umgehen können und dank Model Context Protocol (MCP) ein tiefergehendes Kontextbewusstsein besitzen. Darüber hinaus können Entwickler im Early-Access-Programm Junie mit GitHub verbinden, um Pull Requests zu verwalten, ohne die IDE öffnen zu müssen.

Junie ist laut JetBrains für komplexe Entwicklungsaufgaben geeignet. Der „Ask“-Modus erlaubt High-Level-Brainstorming, der „Code“-Modus ist für die Hands-on-Implementierung zuständig. Dabei kann Junie Code schreiben und refaktorieren, Dateien generieren und Tests ausführen. Die Entwicklerinnen und Entwickler sollen dabei jedoch die Kontrolle behalten.

Details zu diesen und weiteren Änderungen in Rider 2025.2 hält der JetBrains-Blog bereit.

ReSharper erlaubt Out-of-Process Mode

Eines der Highlights in ReSharper 2025.2 ist der Out-of-Process-(OOP)-Modus. Das bedeutet, ReSharper kann in einem von Visual Studio separaten Prozess laufen, was die Stabilität erhöhen und den Weg für zukünftige Performanceverbesserungen ebnen soll.

Entwicklerinnen und Entwickler wechseln zum OOP-Modus, indem sie in ReSharper Options | Environment | Products & Features aufrufen und dort die Option „Run ReSharper in separate process“ aktivieren. Ein Klick auf den Button Save and restart übernimmt die Änderung.

Zudem soll ReSharper merkliche Performanceverbesserungen bringen, unter anderem beim Rename– und Inline-Refactoring sowie bei der Razor/Blazor-Verarbeitung. Auch Support für die neuesten Features der Sprachversion C# 14.0, die Microsoft voraussichtlich im November 2025 veröffentlichen wird, ist nun enthalten.

Weitere Informationen zu den Updates in ReSharper sowie in den .NET-Tools dotTrace, dotMemory und dotCover in Version 2025.2 bietet der JetBrains-Blog.

(mai)

In der relationalen SQL-Datenbank Firebird haben die Entwickler zwei Sicherheitslücken geschlossen. Die ermöglichten Angreifern, Server mit manipulierten Anfragen lahmzulegen – oder unter Umständen sogar unbefugten Zugriff auf eigentlich verschlüsselte Daten.

Die schwerwiegendere Schwachstelle betrifft den Pool externer Verbindungen (ExtConnPool). Ist der aktiv, werden darin gespeicherte Verbindungen nicht erneut überprüft, ob die bei ihrer Erstellung verwendeten CryptCallback-APIs tatsächlich noch vorhanden und geeignet sind. Dadurch können Zugriffe auf verschlüsselte Datenbanken erfolgen, wenn externe SQL-Anweisungen ausgeführt werden, auf die später mit Attachments zugegriffen wird, denen ein Schlüssel zur Datenbank fehlt. Bei derartigen verketteten Execute-Statements kann zudem ein Segfault auftreten, auch auf unverschlüsselten Datenbanken, und damit die Serverprozesse lahmlegen (Denial of Service). Die Schwachstelle hat den CVE-Eintrag CVE-2025-24975 / EUVD-2025-25030 mit einem CVSS-Wert von 7.1 und der Risikoeinschätzung „hoch“ erhalten.

Davon ist FIrebirdSQL bis einschließlich 5.0.3 sowie 4.0.7 betroffen. Die Fehler korrigieren die Schnappschüsse 6.0.0.609, 5.0.2.1610 sowie 4.0.6.3183 und jeweils neuere.

Zweite Sicherheitslücke in Firebird

Vor den Versionen 5.0.3, 4.0.6 und 3.0.13 können beim Verarbeiten von XDR-Nachrichten NULL-Pointer-Derefenzierungen auftreten, also bereits freigegebene Ressourcen erneut freigegeben werden. Das mündet in einem Prozess-Absturz, also einem Denial-of-Service (CVE-2025-54989 / EUVD-2025-25032, CVSS 5.3, Risiko „mittel„).

IT-Verantwortliche sollten sicherstellen, die Firebird-Versionen auf die aktualisierten Stände zu bringen. Auf Github stehen die aktualisierten Quellcodes dafür bereit. Etwa die fehlerkorrigierte Fassung 5.0.3 ist seit Mitte Juli für diverse Betriebssysteme verfügbar. Die CVE-Einträge zu dem damit geschlossenen Sicherheitslücken wurden jedoch erst jetzt veröffentlicht.

(dmk)