Blog
Data Science, Machine Learning & Co. Eine Begriffserklärung
Data Science, Machine Learning, Deep Learning und LLMs
Wo sind eigentlich die Unterschiede?
Künstliche Intelligenz ist längst im Alltag angekommen. Gleichzeitig werden Begriffe wie Data Science, Machine Learning, Deep Learning und Large Language Models (LLMs) oft durcheinandergeworfen. Kein Wunder: Die Konzepte hängen eng zusammen, beschreiben aber unterschiedliche Ebenen, Methoden und Anwendungsfälle.
Wenn wir im Kontext der Softwareentwicklung über die Architektur moderner KI-Systeme sprechen, stoßen wir auf eine ähnliche Herausforderung. Begriffe wie Agent, Tool, Skill, MCP oder Harness werden häufig unscharf verwendet. Irgendwann redet man aneinander vorbei, ohne es zu merken.
Dieser Artikel ist kein Tutorial. Er ist ein Lexikon. Für alle, die im Kontext von AI Driven Development eine gemeinsame Sprache finden wollen. Hier verbinden wir die fundamentale Taxonomie der KI mit der Architektur-Ebene, damit Theorie und Praxis ineinander greifen.
Teil 1: Die taxonomischen Schichten von Data Science
Was ist was?
Data Science ist der umfassendste Begriff in diesem Vergleich. Im Kern geht es darum, aus Daten Erkenntnisse zu gewinnen und daraus konkrete Entscheidungen, Prognosen oder Produkte abzuleiten.
Data Science ist also mehr als Modelltraining. Oft besteht ein großer Teil der Arbeit darin, Daten überhaupt erst nutzbar zu machen und die richtigen Fragestellungen zu formulieren.
Typische Data-Science-Fragen sind:
- Warum sinkt unsere Conversion Rate?
- Welche Kundengruppen verhalten sich ähnlich?
- Welche Faktoren beeinflussen die Lieferzeit?
- Wie können wir operative Kennzahlen besser prognostizieren?
Data Science ist damit häufig die strategische und analytische Klammer, in der auch Machine Learning eine Rolle spielt.
1. Machine Learning: Systeme lernen aus Daten
Machine Learning (ML) ist ein Teilgebiet der Künstlichen Intelligenz, bei dem Modelle nicht für jede Regel explizit programmiert werden, sondern Zusammenhänge aus Beispieldaten lernen.
Statt zu sagen: „Wenn A passiert, dann führe B aus“, wird dem Modell eine große Menge historischer Daten gegeben. Daraus lernt es Muster und kann auf neue Daten reagieren.
Typische Machine-Learning-Anwendungen sind:
- Nachfrageprognosen,
- Betrugserkennung,
- Churn Prediction,
- Produktempfehlungen,
- Klassifikation von Dokumenten oder Tickets.
Wichtig ist: Traditionelles Machine Learning funktioniert besonders gut, wenn Daten strukturiert, sauber und ausreichend gelabelt sind.
Beispiele für klassische ML-Verfahren sind:
- Lineare Regression,
- Entscheidungsbäume,
- Random Forests,
- Gradient Boosting,
- Support Vector Machines.
Diese Verfahren sind oft effizient, nachvollziehbar und in vielen Business-Szenarien völlig ausreichend.
2. Deep Learning: Wenn neuronale Netze komplexe Muster erkennen
Deep Learning ist ein spezialisierter Bereich des Machine Learning. Hier kommen künstliche neuronale Netze mit vielen Schichten zum Einsatz.
Der Vorteil: Solche Modelle können sehr komplexe Muster erkennen, etwa in Bildern, Audio oder Video. Genau dort stoßen klassische ML-Verfahren häufig an Grenzen.
Typische Deep-Learning-Anwendungen sind:
- Bilderkennung,
- Spracherkennung,
- automatische Übersetzung,
- Objekterkennung in Videos.
Deep Learning ist besonders nützlich, wenn die Bedeutung „zwischen den Zeilen“ liegt oder nicht durch einfache, manuell definierte Features beschrieben werden kann.
Diese Fähigkeit, “zwischen den Zeilen zu lesen”, hat jedoch ihren Preis:
Deep-Learning-Modelle brauchen zumeist
- deutlich mehr Daten,
- mehr Rechenleistung,
- längere Trainingszeiten,
- sorgfältige Evaluation.
Zudem sind sie oft schwerer zu interpretieren als klassische ML-Modelle.
3. LLMs: Sprachmodelle als Spezialfall von Deep Learning
Large Language Models (LLMs) sind eine spezielle Klasse von Deep-Learning-Modellen, die auf sehr großen Textmengen trainiert werden, um Sprache zu verstehen und zu erzeugen.
Technisch basieren moderne LLMs in der Regel auf der Transformer-Architektur. Dadurch können sie Zusammenhänge in natürlicher Sprache besonders gut erfassen und Antworten, Zusammenfassungen, Übersetzungen, Code oder andere textbasierte Inhalte generieren.
Was LLMs besonders macht? LLMs sind darauf ausgelegt:
- natürliche Sprache zu verarbeiten,
- Kontexte zu verstehen,
- Inhalte zu generieren,
- Wissen aus Textmustern abzuleiten.
Im Unterschied zu vielen klassischen ML-Modellen sind sie generativ: Sie sagen nicht nur Klassen oder Zahlen voraus, sondern erzeugen neue Inhalte.
Typische Einsatzszenarien für LLMs:
- Chatbots und Assistenten,
- Wissensmanagement,
- Textklassifikation und Zusammenfassung,
- Code-Unterstützung,
- Semantische Suche,
- Automatisierung von Dokumentenprozessen.
LLMs sind damit ein Teilbereich generativer KI. Gleichzeitig gilt: Nicht jede generative KI ist ein LLM, denn generative Systeme können auch Bilder, Audio oder Video erzeugen.
Die wichtigste Unterscheidung in der Praxis
Die Begriffe unterscheiden sich nicht nur theoretisch und technisch, sondern vor allem in ihrer praktischen Rolle:
| Begriff | Fokus | Typische Daten | Ziel |
| Data Science | Erkenntnisse aus Daten gewinnen | strukturiert und unstrukturiert | Analyse, Entscheidungshilfe |
| Machine Learning | Muster aus Daten lernen | meist strukturierte Daten | Vorhersagen, Klassifikation, Optimierung |
| Deep Learning | Komplexe Muster mit neuronalen Netzen erkennen | große, oft unstrukturierte Datenmengen | Sprache, Bild, Audio, komplexe Signale |
| LLMs | Sprache verstehen und erzeugen | sehr große Textmengen | Dialog, Generierung, Textautomatisierung |
Wann braucht man was?
In Unternehmen ist nicht immer das modernste Modell die beste Wahl. Oft ist die richtige Frage nicht: „Wo können wir ein LLM einsetzen?“, sondern: „Welches Problem wollen wir lösen und welche Technologie ist dafür angemessen?“
Data Science ist passend, wenn …
- Zusammenhänge erklärt werden sollen,
- Reports und Dashboards entstehen,
- Entscheidungen datenbasiert vorbereitet werden,
- Hypothesen geprüft werden.
Klassisches Machine Learning ist passend, wenn …
- strukturierte Daten vorhanden sind,
- Vorhersagen oder Scorings benötigt werden,
- Interpretierbarkeit wichtig ist,
- robuste und effiziente Lösungen gefragt sind.
Deep Learning ist passend, wenn …
- Bild-, Audio- oder komplexe Textdaten verarbeitet werden,
- klassische Feature-Engineering-Ansätze nicht ausreichen,
- sehr große Datenmengen vorliegen.
LLMs sind passend, wenn …
- natürliche Sprache im Zentrum steht,
- Texte generiert, zusammengefasst oder analysiert werden sollen,
- Wissenszugang conversational gestaltet werden soll,
- Produktivität in textbasierten Prozessen gesteigert werden soll.
Gerade dieser Unterschied wird in aktuellen Einordnungen betont: Traditionelles ML ist oft schnell und zuverlässig bei strukturierten Daten, Deep Learning hilft bei komplexer Semantik, und LLMs sind besonders stark in sprachbasierten Aufgaben.
Warum Begriffspräzision wichtig ist
Wenn in Projekten alle von „KI“ sprechen, aber eigentlich Unterschiedliches meinen, entstehen schnell Missverständnisse:
- Das Fachteam erwartet einen Chatbot, das Data-Team baut ein Prognosemodell.
- Das Management fordert „AI“, obwohl ein statistisches Modell genügt.
- Ein LLM wird eingesetzt, obwohl ein einfaches Klassifikationsmodell günstiger, schneller und kontrollierbarer wäre.
Ein gemeinsames Begriffsverständnis ist deshalb kein Selbstzweck. Es ist die Grundlage für:
- realistische Aufwandsschätzungen,
- geeignete Architekturentscheidungen,
- Datenschutz- und Governance-Fragen,
- nachhaltigen geschäftlichen Nutzen.
Fazit: Nicht alles ist ein LLM
Der aktuelle KI-Hype sorgt dafür, dass LLMs viel Aufmerksamkeit bekommen. Das ist nachvollziehbar, denn ihre Fähigkeiten sind beeindruckend. Trotzdem bleiben sie nur ein Baustein im größeren Daten- und KI-Ökosystem.
Die Einordnung lautet:
- Data Science ist der übergreifende datengetriebene Ansatz.
- Machine Learning ist das Lernen aus Daten.
- Deep Learning ist ein spezialisierter ML-Ansatz mit tiefen neuronalen Netzen.
- LLMs sind spezialisierte Deep-Learning-Modelle für Sprache LLMs für.
Wer diese Unterschiede versteht, kann Technologien gezielter auswählen, Projekte realistischer planen und echten Mehrwert schaffen.
Sie möchten herausfinden, welche KI- oder Datenstrategie zu Ihrem Anwendungsfall passt? Ob Analytics, klassisches Machine Learning oder der produktive Einsatz von LLMs: Entscheidend ist nicht der Buzzword-Faktor, sondern die passende Lösung für Ihr Geschäftsproblem.
Teil 2: AI-Driven Development: Was meinen wir damit?
Nehmen wir an, das LLM ist gleichzeitig Tool im Entwicklungsprozess als auch das Herzstück der fertigen Lösung. Jetzt stellt sich die Frage der Umsetzung. Denn ein Modell allein macht noch keinen Agenten. In der Architektur moderner AI-Pipelines ist es entscheidend, diese Komponenten klar zu trennen.
1. Token: Die Währung des Modells
Bevor wir über Agenten und Architektur sprechen, müssen wir die kleinste Einheit verstehen: den Token.
Ein Token ist die kleinste Verarbeitungseinheit eines Sprachmodells. Ein Token entspricht nicht immer einem vollständigen Wort, oft ist es auch nur ein Wortteil oder Satzzeichen.
Tokens beeinflussen:
- die Kosten einer Anfrage,
- die maximale Eingabelänge,
- die Menge an Informationen, die ein Agent gleichzeitig berücksichtigen kann.
Beispiel:
"IdentityResolver" → ca. 2–4 Tokens: "Identity", "Resolver" "Fix den 500er beim Login" → ca. 5–8 Tokens, abhängig vom Tokenizer
Hilfreicher Link: OpenAI Tokenizer
2. Context Window: Der Arbeitsspeicher des Modells
Das Context Window ist der Arbeitsbereich des Modells. Alles, was sich darin befindet, kann das Modell für seine Antwort berücksichtigen. Alles, was nicht reinpasst, existiert für das Modell nicht.
Context Window = 200.000 Tokens (~150.000 Wörter)
Inhalt z. B.:
System-Prompt + Skill = 2.000 Tokens Gesprächsverlauf = 15.000 Tokens Code-Datei = 8.000 Tokens Tool-Ergebnisse = 5.000 Tokens
Bei langen Agent-Sessions wächst der Kontext kontinuierlich. Jeder Tool-Aufruf, jede Datei, jedes Suchergebnis verbraucht Tokens. Das bedeutet: Irrelevante Informationen können wichtige Details verdrängen.
Praktische Regel: Ein Agent sollte nicht einfach immer mehr Informationen sammeln. Er sollte regelmäßig zusammenfassen, irrelevante Details entfernen und nur behalten, was für die aktuelle Aufgabe relevant ist. Ein guter AI Harness (dazu später mehr) übernimmt genau das.
3. Tool: Die Ausführung
Ein Tool ist eine einzelne ausführbare Funktion, die ein Agent aufrufen kann. Es:
- führt genau eine bestimmte Aktion aus,
- hat keine eigene Entscheidungslogik,
- nimmt Eingaben entgegen und liefert Ergebnisse zurück.
Analogie: Ein Tool ist wie git commit. Es führt eine Aktion aus und liefert das Ergebnis. Es fragt nicht nach dem Warum.
Beispiele:
searchLogs(service, from) → List runTests(module) → TestResult readFile(path) → String createPullRequest(title, diff) → PrUrl
Kernaussage: Tools entscheiden nicht, was getan werden soll. Sie führen aus.
4. Skill: Das Know-how
Ein Skill ist eine wiederverwendbare Sammlung von Anweisungen, Standards und Best Practices, die dem Agenten beschreibt, wie eine Aufgabe ausgeführt werden soll. Ein Skill führt die Aufgabe nicht selbst aus — er definiert den erwarteten Standard.
Analogie: Ein Skill ist wie die Code-Review-Richtlinien eines Teams.
Er kann enthalten:
- Security-Checkliste,
- Architekturregeln,
- Kommentarformat,
- Beispiel-Reviews.
Eine funktionierende Arbeitsteilung und sinnvolle Spezialisierung: Der Reviewer führt das Review weiterhin aus. Der Skill legt fest, wie ein gutes Review aussieht.
Ohne Skill:
Review this PR. → "Looks good."
Mit Code-Review-Skill:
Review this PR. → "Line 47: Missing null check. Potential NPE risk. Suggested fix: Add a null check before accessing user.getEmail()."
Der Skill macht das Ergebnis spezifischer, konsistenter und richtet es an den Teamstandards aus.
Kernaussage: Tools führen Aktionen aus. Skills definieren, wie ein Agent eine Aufgabe ausführen soll.
5. Agent: Von der Ausführung zur Autonomie
Der Agent bekommt ein Ziel und entscheidet selbst, welche Schritte nötig sind, um es zu erreichen.
Im Gegensatz zu einem Tool kann er Ergebnisse beobachten, bewerten und daraus ableiten, was als Nächstes zu tun ist.
Analogie: Es ist wie mit einem Entwickler aus Fleisch und Blut.: Gebt ihr ihm Ticket „Fix den sporadischen 500er beim Login.“, kennt er die Antwort auch nicht vorher. Er liest das Ticket, sucht in den Logs, bildet eine Hypothese, schreibt einen Fix, sieht, dass Tests fehlschlagen, iteriert. Diese Entscheidungsschleife, das ist ein Agent.
Beispiel:
agent.run("Fix den 500er beim Login")
→ Schritt 1: readTicket("LOGIN-42")
→ Schritt 2: searchLogs(service="auth", from=letzte_woche)
→ Schritt 3: findCode(keyword="authentication", "500")
→ Schritt 4: proposeCodeFix(hypothese)
→ Schritt 5: runTests(module="auth")
→ Tests fehlgeschlagen? → zurück zu Schritt 3, neue Hypothese
→ Schritt 6: createPullRequest(beschreibung, risikoZusammenfassung)
Die Abfolge ist nicht vorab fest definiert. Der Agent bewertet kontinuierlich den aktuellen Zustand.
Was kein Agent ist:
if error == 500: searchLogs() createFix() runTests()
→ Statischer Workflow: kein Agent. → Chatbot, der nur antwortet, aber keine Aktionen ausführt: kein Agent.
Die entscheidende Frage: Wer entscheidet, was als nächstes passiert?
if/else-Logik → kein Agent Modellgesteuerte Entscheidungen auf Basis von Beobachtungen → Agent
6. ReAct Pattern: Die Schleife des Agenten
ReAct, das steht für Reasoning + Acting. Es beschreibt das Muster, nach dem ein Agent in einer iterativen Schleife zwischen Denken, Handeln und Beobachten wechselt:
Reasoning → Action → Observation → Reasoning → ...
Jede Beobachtung liefert neue Informationen, die die nächste Entscheidung beeinflussen.
Beispiel:
Thought: "Der 500er kommt wohl aus dem Auth-Layer. Ich durchsuche die Logs."
Action: searchLogs(service="auth", pattern="500")
Observation: "17 Fehler in SecurityConfig.java, Zeile 142"
Thought: "Zeile 142 — der JWT-Validator. Ich lese den Code."
Action: readFile("SecurityConfig.java", lines=[135, 155])
Observation: "Missing null-check on token.getClaims()"
Thought: "Gefunden. Ich schreibe den Fix."
Action: editFile(...)
Warum das wichtig ist: ReAct macht das Verhalten eines Agenten transparent und nachvollziehbar. Wenn ein Agent einen Fehler macht, lässt sich nachvollziehen, ob die Ursache falsches Reasoning, die Wahl eines ungeeigneten Tools oder eine fehlerhafte Interpretation der Beobachtung war. Das erleichtert Debugging erheblich.
7. Model Context Protocol: Das gemeinsame Protokoll MCP
MCP ist ein offener Standard von Anthropic, der definiert, wie Agenten und Modelle mit externen Tools kommunizieren: einheitlich, unabhängig vom Modell oder Framework.
Analogie: Wie REST für APIs. REST ist ein gemeinsames Protokoll, damit alle HTTP-Clients mit allen Servern reden können. MCP ist das Equivalent für die Agent-Tool-Kommunikation.
// Ohne MCP: jedes Framework braucht ein eigenes Tool-Format
openaiAgent.tools = [{ name: "searchLogs", parameters: {...} }]
claudeAgent.tools = [{ tool_name: "searchLogs", input_schema: {...} }]
// → doppelte Implementierung für jedes Tool
// Mit MCP: ein Server, alle Agents
mcpServer.register("searchLogs", handler, schema)
claudeAgent.connect(mcpServer) // funktioniert
openaiAgent.connect(mcpServer) // funktioniert
Wer bestehende Spring Boot APIs hat, kann Tools über OpenAPI-Spezifikationen automatisch als MCP-Tools exportieren, ohne den bestehenden Code zu ändern. Das macht MCP besonders interessant für Teams, die vorhandene Backend-Systeme für Agenten öffnen wollen.
Weitere Infos: modelcontextprotocol.io
8. AI Harness: Die Laufzeitumgebung
Ein AI Harness ist die Infrastruktur, die einen Agenten überhaupt lauffähig und kontrollierbar macht. Der Agent entscheidet, was als Nächstes passieren soll, der Harness stellt die Laufzeitumgebung bereit, in der das sicher und zuverlässig ausgeführt werden kann.
Analogie: Tomcat für Java-Servlets. Ein Servlet weiß, wie es einen Request behandelt. Tomcat weiß, wie die Anwendung gestartet wird, wie Requests geroutet werden, wie Threads verwaltet werden und wie Fehler geloggt werden. Genauso verhält es sich mit Agent und Harness.
Tomcat : Servlet Runtime Harness : Agent Runtime
Ein AI Harness verwaltet typischerweise:
- Agent Loop,
- Tool-Zugriff (via MCP),
- Context Management,
- Berechtigungen,
- Logging & Tracing,
- Fehlerbehandlung,
- Human-in-the-loop-Freigaben.
Bekannte Harnesses: Claude Code, LangChain, OpenAI Agents SDK, Hermes oder eigene interne Agent-Runtimes. Wer ein eigenes agentisches System baut, baut effektiv auch einen AI Harness.
Zusammenfassung: Alle Schichten auf einen Blick
- Ein Token ist die Kosteneinheit. Tokens füllen das Context
- Window. Ein Tool tut genau eine Sache. Ein Skill weiß, wie man sie richtig tut (nach euren Regeln).
- Ein Agent entscheidet, was zu tun ist. (ReAct: Denken → Handeln → Beobachten)
- MCP ist das Protokoll, das Agent und Tool verbindet.
- Ein Agentic Agent verfolgt ein Ziel eigenständig und pausiert, wo ein Mensch muss.
- Ein Harness lässt das alles sicher und kontrolliert laufen.
Wer heute über „KI im Unternehmen“ spricht, sollte diese Fragen voranstellen:
- Ist ein klassisches ML-Modell oder eine statistische Analyse vielleicht günstiger und präziser?
- Wenn wir LLMs benötigen, haben wir das Token-Kostenmanagement im Blick?
- Ist die Lösung ein deterministischer Workflow oder benötigt sie tatsächlich agentische Autonomie?
- Existiert ein Harness, der das System kontrollierbar macht, bevor die Modelle auf Kunden losgelassen werden?
In einer Welt voller KI-Plattformen ist präzises Vokabular nicht nur akademisch. Es ist unsere beste Medizin gegen den Hype.
