(vor nicht allzu langer Zeit) Als Datenwissenschaftler zu arbeiten bedeutete, in einem Notizbuch zu leben und Hyperparameter zu optimieren, als hinge das Leben davon ab, und in vielen Fällen hing tatsächlich das gesamte Projekt davon ab.
Erinnern Sie sich an die nächtlichen Rastersuchen? Oder Function-Engineering-Pipelines bauen, die sich eher wie Kunst als wie Wissenschaft anfühlen? Und die Befriedigung, eine zusätzliche Genauigkeit von 0,7 % aus einem XGBoost-Modell herauszuholen?
Im Jahr 2019 struggle das die Aufgabe eines Datenwissenschaftlers! Was Sinn machte. Wenn Sie ein starkes Modell wollten, mussten Sie es selbst bauen oder hart arbeiten, um es richtig hinzubekommen. Der wahre Wert lag darin, wie intestine Sie die Daten abstimmen, optimieren und verstehen konnten.
Jetzt ist „State-of-the-Artwork“ nur noch einen API-Aufruf entfernt. Brauchen Sie ein High-Sprachmodell? Erledigt. Benötigen Sie Einbettungen oder multimodales Denken? Auch erledigt. Die schwierigsten Teile der Modellierung werden jetzt von skalierbaren Endpunkten übernommen, die weit über das hinausgehen, was die meisten Groups selbst erstellen könnten.
Die Frage ist nun, ob das Modell schon da ist, Wo ist die Arbeit geblieben?
Der Wert liegt nicht mehr nur im Modell. Es geht darum, wie alle Teile miteinander verbunden sind, kommunizieren und sich anpassen. Diese Änderung verändert die Rolle eines Datenwissenschaftlers völlig.
Wiefragst du? Darum geht es in diesem Artikel.
Was hat sich geändert?
1. Umgehen der .match()-Methode
Wenn Sie sich den Code in einem modernen KI-Projekt ansehen, werden Sie schnell feststellen, dass nicht viel tatsächliche Modellierung stattfindet.
Möglicherweise werden Sie zu einem LLM oder einem Einbettungsmodell aufgerufen, aber das ist selten die größte Herausforderung. Die eigentliche Arbeit liegt in der Datenaufnahme, dem Routing, dem Zusammenstellen des Kontexts, dem Caching, der Überwachung und der Handhabung von Wiederholungsversuchen.
Mit anderen Worten: Verwenden .match() ist jetzt einer der am wenigsten interessanten Teile des Codes.
2. Anpassung an die neuen Komponenten
Statt uns auf Modelleinbauten zu konzentrieren, bauen wir heute Systeme aus vorgefertigten Komponenten zusammen. Ein typischer Modellierungsstapel umfasst jetzt:
- Vektordatenbanken (z. B. Pinecone, Milvus)
- Prompte Technik.
- Erinnerungsschichten.
Zusätzlich zu Funktionen/Agentenanrufen. Wenn wir das Gesamtbild betrachten, erkennen wir, dass es sich hierbei nicht um traditionelle Modellierung handelt. Es ist Systemdesign. An dieser Stelle muss unbedingt darauf hingewiesen werden, dass keine dieser Komponenten für sich genommen besonders nützlich ist. Ihre Kraft ergibt sich aus der Artwork und Weise, wie sie zusammen orchestriert werden.
3. Alles zusammenfügen
Im Second geht es bei den meisten Information-Science-Codes darum, die einzelnen Teile miteinander zu verbinden. Es geht nicht um lineare Algebra, Optimierung oder gar Statistik.
Es geht darum, Code zu schreiben, der Daten zwischen Komponenten verschiebt, Eingaben formatiert, Ausgaben analysiert, Interaktionen protokolliert und den Standing verteilter Systeme verwaltet.
Wenn Sie Ihren Code messen, werden Sie feststellen, dass nur 10 bis 20 Prozent für die Verwendung eines Modells (API-Aufrufe, Inferenz) aufgewendet werden, während 80 bis 90 Prozent für die Orchestrierung aufgewendet werden – die Handhabung des Datenflusses, der Integration und der Infrastruktur.
Der Wandel vom Information Scientist zum AI Architect
Die größte Veränderung in der Denkweise besteht heute darin, dass man nicht mehr nur eine Funktion optimiert. Jetzt entwerfen Sie ein ganzes System und denken dabei über Latenz, Kosten, Zuverlässigkeit und die Artwork und Weise nach, wie Menschen damit interagieren.
Anstatt zu fragen: „Wie verbessere ich die Modellleistung?„Wir fragen jetzt, „Wie funktioniert dieses ganze System in realen Situationen?”
Ich weiß, was Sie denken – das ist eine ganz andere Herausforderung! Für viele Menschen, mich eingeschlossen, struggle es unangenehm, als dieser Wandel zum ersten Mal stattfand.
Um mit dem heutigen Stack Schritt zu halten, brauchen wir mehr als nur Statistiken und maschinelles Lernen. Wir müssen mit APIs (wie FastAPI oder Flask) für die Bereitstellung und Weiterleitung, Containerisierung (wie Docker) für die Bereitstellung, asynchroner Programmierung (mit Asyncio) für die Bearbeitung mehrerer Anfragen, Cloud-Infrastruktur für Skalierung und Überwachung sowie Datentechnik-Grundlagen für Pipelines und Speicher vertraut sein.
Wenn Sie denken, das klingt sehr danach Backend-Engineeringsie haben Recht.
Dieser Wandel hat die Grenze zwischen Datenwissenschaftler und Ingenieur verwischt. Gute Leistungen erbringen diejenigen, die in beiden Bereichen problemlos arbeiten können.
Das Alte vs. Das Neue
Die entscheidende Frage lautet nun: Wie sieht diese Verschiebung im Code aus?
Legacy Undertaking (2019): Stimmungsanalyse
Viele von uns haben an solchen Projekten mitgearbeitet. Der Vorgang ist einfach:
- Sammeln Sie einen beschrifteten Datensatz.
- Führen Sie Function Engineering durch (TF-IDF, n-Gramm).
- Zugklassifikator (logistische Regression, XGBoost).
- Optimieren Sie Hyperparameter.
- Modell bereitstellen.
Der Erfolg hängt hier von der Qualität Ihres Datensatzes und Ihres Modells ab.
Modernes Projekt (2026): Autonomer Kundenfeedback-Agent
Der Prozess ist jetzt anders. Um heute ein System aufzubauen, müssen Sie:
- Nehmen Sie Kundennachrichten in Echtzeit auf.
- Speichern Sie Einbettungen in einer Vektordatenbank.
- Rufen Sie den relevanten historischen Kontext ab.
- Erstellen Sie Eingabeaufforderungen dynamisch.
- Weiterleitung zu LLM mit Instrument-Zugriff (z. B. CRM-Updates, Ticketing-Systeme)
- Behalten Sie das Gesprächsgedächtnis bei.
- Überwachen Sie die Ausgänge auf Qualität und Sicherheit.
Können Sie erkennen, was fehlt? Hier ein Hinweis: Es gibt keine Trainingsschleife.
Dieses Beispiel ist absichtlich einfach, aber beachten Sie, worauf wir uns jetzt konzentrieren. Der Abruf ist Teil des Methods; Das Modell besteht nur aus einem Stück und der Wert ergibt sich aus der Artwork und Weise, wie alles miteinander verbunden ist und zusammenarbeitet.
So beginnen Sie, wie ein KI-Architekt zu denken
Nachdem wir nun wissen, was sich geändert hat, sprechen wir darüber, was Sie eigentlich anders machen sollten. Wie können Sie diesen Wandel vorantreiben, anstatt ins Hintertreffen zu geraten?
Die kurze Antwort: Beginnen Sie mit dem Aufbau von Systemen, nicht nur von Modellen.
Die längere Antwort: Konzentrieren Sie sich auf den Aufbau dieser Fähigkeiten:
1. Erstellen Sie Finish-to-Finish, nicht nur Komponenten
Anstatt zu denken: „Ich habe ein Mannequin trainiertzielen auf , „Ich habe ein System aufgebaut, das Eingaben entgegennimmt, verarbeitet und einen Wert zurückgibt.„Jetzt geht es um das große Ganze, nicht nur um eine Aufgabe.“
2. Lernen Sie gerade genug Backend, um gefährlich zu sein
Sie müssen kein Vollzeit-Backend-Ingenieur werden, aber Sie sollten genug wissen, um Ihr System zu erstellen. Konzentrieren Sie sich auf:
- Eine einfache API einrichten (FastAPI reicht aus)
- Anfragen asynchron bearbeiten
- Protokollierung und Fehlerbehandlung
- Grundlegende Bereitstellung (Docker + eine Cloud-Plattform)
3. Machen Sie sich mit Mehrdeutigkeiten vertraut
Moderne KI-Systeme sind nicht deterministisch wie herkömmliche Modelle. Dies erschwert die Arbeit mit ihnen, da Sie jetzt nicht nur Code debuggen; Vielmehr debuggen Sie das Verhalten.
Das bedeutet, Eingabeaufforderungen zu iterieren, Fallback-Mechanismen zu entwerfen und die Ergebnisse qualitativ und nicht nur quantitativ zu bewerten.
4. Messen Sie, was wirklich wichtig ist
Genauigkeit ist nicht mehr immer die wichtigste Messgröße. Jetzt sind Latenz, Kosten professional Anfrage, Benutzerzufriedenheit und Aufgabenerledigungsrate wichtiger.
Ein System, das zu 95 % genau ist, aber in der Produktion unbrauchbar ist, ist schlechter als eines, das zu 85 % genau und zuverlässig ist.
Der letzte Gedanke
In unserem Bereich besteht immer die Versuchung, dem nachzujagen, was sich am „technischsten“ anfühlt, dem neuesten Modell, dem größten Maßstab, der auffälligsten Architektur.
Aber der wertvollste Teil dieses Jobs struggle und ist immer die menschliche Seite! Das bedeutet, das Downside zu verstehen. Zu wissen, was wir zu lösen versuchen, ist wichtiger als die Daten oder das Modell, das wir verwenden.
Stellen Sie Fragen wie: „Welcher Bedarf besteht hier? Was interessiert den Benutzer? Was bedeutet eigentlich „intestine“ im Kontext?„macht einen großen Unterschied in dem, was Sie bauen.
Sie können diesen Teil nicht auslagern oder hinter einer API verstecken. Und man kann es definitiv nicht automatisieren.
Versuchen Sie additionally nicht nur, den Motor eines Autos zu bauen. Ziel ist es, die Individual zu sein, die versteht, wohin das Auto fahren soll, und dann das System aufbaut, um es dorthin zu bringen.