Die jüngsten Fortschritte in der KI sind sehr aufregend. Die Menschen nutzen es auf vielfältige Weise, von des Kundensupports über von Code bis hin zum neuer Musik und sogar der medizinischen Bildgebungstechnologie. der Verbesserung das Schreiben und Ausführen Erstellen der Beschleunigung Doch dabei zeichnet sich ein besorgniserregender Trend ab: Die KI-Community scheint die Datenbewegung (auch bekannt als ETL) neu zu erfinden. Unabhängig davon, ob sie sie Konnektoren, Extraktoren, Integrationen, Dokumentlader oder etwas anderes nennen, schreiben die Leute denselben Code, um Daten aus denselben APIs, Dokumentformaten und Datenbanken zu extrahieren und sie dann in Vektor-DBs oder Indizes für ihre LLMs zu laden. Das Problem besteht darin, dass der Bau und die Wartung robuster Förder- und Verladepipelines von Grund auf ein enormer Aufwand ist. Und es gibt so viel Stand der Technik in diesem Bereich, dass es für fast alle Ingenieure oder Unternehmen im KI-Bereich eine enorme Zeitverschwendung ist, ihn neu aufzubauen. In einem Umfeld, in dem etwa jede Stunde aktuelle Nachrichten auftauchen, sollte das Hauptaugenmerk darauf liegen, Ihr Kernprodukt für Ihre Benutzer unglaublich zu machen, und nicht auf Nebenquests. Und für fast alle ist das Kernprodukt nicht die Datenbewegung; Es ist die KI-gestützte Zaubersoße, die Sie brauen. Über die Herausforderungen beim Aufbau robuster ETL-Pipelines (Extrahieren, Transformieren und Laden) wurde viel geschrieben ( , ), aber lassen Sie uns dies innerhalb der KI kontextualisieren. 1 2 Warum braucht KI Datenbewegung? Auf öffentlichen Daten geschulte LLMs sind großartig, aber wissen Sie, was noch besser ist? KIs, die spezifische Fragen zu uns, unseren Unternehmen und unseren Nutzern beantworten können. Wir würden uns alle freuen, wenn ChatGPT unser gesamtes Unternehmens-Wiki lernen, alle unsere E-Mails, Slack-Nachrichten, Besprechungsnotizen und Transkripte lesen, sich in die Analyseumgebung unseres Unternehmens einbinden und alle diese Quellen bei der Beantwortung unserer Fragen nutzen könnte. Oder wenn wir KI in unser eigenes Produkt integrieren (z. B. mit Notion AI , möchten wir, dass das KI-Modell unserer App alle Informationen kennt, die wir über einen Benutzer haben, wenn wir ihm helfen. ) Voraussetzung dafür ist die Datenbewegung. Unabhängig davon, ob Sie ein Modell verfeinern oder Retrieval-Augmented Generation (RAG) , müssen Sie Daten von jedem Speicherort extrahieren, sie in ein für Ihr Modell verdauliches Format umwandeln und sie dann in einen Datenspeicher laden, auf den Ihre KI-App zugreifen kann um Ihren Anwendungsfall zu bedienen. verwenden Das obige Diagramm veranschaulicht, wie dies bei Verwendung von RAG aussieht. Sie können sich jedoch vorstellen, dass sich die grundlegenden Schritte selbst dann wahrscheinlich nicht ändern, wenn Sie RAG nicht verwenden: Sie müssen die Daten extrahieren, transformieren und laden, auch bekannt als ETL Erstellen Sie KI-Modelle, die nicht öffentliche Informationen speziell für Sie und Ihren Anwendungsfall kennen. Warum ist die Datenverschiebung schwierig? Der Aufbau eines grundlegenden funktionalen MVP für die Datenextraktion aus einer API oder Datenbank ist normalerweise – wenn auch nicht immer – kurzfristig (<1 Woche) machbar. Der wirklich schwierige Teil besteht darin, es produktionsreif zu machen und es so zu halten. Schauen wir uns einige der Standardherausforderungen an, die einem beim Bau von Förderleitungen in den Sinn kommen. Inkrementelle Extrakte und Zustandsverwaltung Wenn Sie über ein bedeutendes Datenvolumen verfügen, müssen Sie die inkrementelle Extraktion implementieren, sodass Ihre Pipeline nur die Daten extrahiert, die sie zuvor noch nicht gesehen hat. Dazu benötigen Sie eine Persistenzschicht, um zu verfolgen, welche Daten jede Verbindung extrahiert hat. Behandlung vorübergehender Fehler, Backoffs, Wiederaufnahme bei Fehler(n), Air Gapping Ständig vorgelagerte Datenquellen, manchmal ohne klaren Grund. Ihre Pipelines müssen dem standhalten und es mit den richtigen Backoff-Richtlinien erneut versuchen. Wenn die Ausfälle nicht so vorübergehender Natur sind (aber immer noch nicht Ihre Schuld), muss Ihre Pipeline robust genug sein, um sich an die Stelle zu erinnern, an der sie aufgehört hat, und an derselben Stelle fortzufahren, sobald die Störung stromaufwärts behoben ist. Und manchmal ist das vom Upstream kommende Problem so schwerwiegend (z. B. wenn eine API einige wichtige Felder aus Datensätzen löscht), dass Sie die gesamte Pipeline anhalten möchten, bis Sie untersucht haben, was passiert, und manuell entscheiden, was zu tun ist. Konfigurationsfehler erkennen und proaktiv beheben Wenn Sie Datenextraktionspipelines erstellen, um die Daten Ihrer Kunden zu extrahieren, müssen Sie einige Abwehrkontrollen implementieren, um sicherzustellen, dass alle Konfigurationen, die Ihre Kunden Ihnen zum Extrahieren von Daten in ihrem Namen gegeben haben, korrekt sind, und wenn nicht, schnell Geben Sie ihnen umsetzbare Fehlermeldungen. Die meisten APIs machen dies nicht einfach, da sie keine umfassenden Fehlertabellen veröffentlichen, und selbst wenn sie dies tun, stellen sie Ihnen selten Endpunkte zur Verfügung, mit denen Sie die Berechtigungen überprüfen können, die z. B. API-Tokens zugewiesen sind. Sie müssen also Wege finden, dies umfassend auszubalancieren prüft mit schnellem Feedback für den Benutzer. Authentifizierung und Geheimverwaltung Die Einfachheit der APIs reicht von einfacher Bearer-Token-Authentifizierung bis hin zu „kreativen“ Implementierungen von Sitzungstoken oder Single-Use-Token-OAuth. Sie müssen die Logik implementieren, um die Authentifizierung durchzuführen und die Geheimnisse zu verwalten, die möglicherweise einmal pro Stunde aktualisiert werden. Möglicherweise müssen Sie die Aktualisierung von Geheimnissen über mehrere gleichzeitig arbeitende Mitarbeiter hinweg koordinieren. Optimieren von Extraktions- und Ladegeschwindigkeiten, Parallelität und Ratenbeschränkungen Apropos gleichzeitige Worker: Sie möchten wahrscheinlich Parallelität implementieren, um einen hohen Durchsatz für Ihre Extraktionen zu erreichen. Während dies bei kleinen Datensätzen möglicherweise keine Rolle spielt, ist es bei größeren Datensätzen absolut entscheidend. Auch wenn APIs offizielle Ratenlimits veröffentlichen, müssen Sie empirisch die besten Parallelitätsparameter ermitteln, um das von der API bereitgestellte Ratenlimit zu maximieren, ohne dass IP-Adressen auf die schwarze Liste gesetzt werden oder die Raten für immer begrenzt werden. Anpassung an Upstream-API-Änderungen APIs ändern sich und nehmen ständig neue undokumentierte Verhaltensweisen oder Eigenheiten an. Viele Anbieter veröffentlichen vierteljährlich neue API-Versionen. Sie müssen im Auge behalten, wie sich all diese Aktualisierungen auf Ihre Arbeit auswirken können, und Zeit in die Entwicklung investieren, um alles auf dem neuesten Stand zu halten. Es tauchen ständig neue Endpunkte auf, und einige ändern ihr Verhalten (und Sie erhalten nicht immer eine Benachrichtigung). Planung, Überwachung, Protokollierung und Beobachtbarkeit Über den Code hinaus, der Daten aus bestimmten APIs extrahiert, müssen Sie wahrscheinlich auch einige horizontale Funktionen entwickeln, die von allen Ihren Datenextraktoren genutzt werden. Sie benötigen eine gewisse Planung sowie Protokollierung und Überwachung für den Fall, dass die Planung nicht funktioniert oder wenn andere Dinge schiefgehen und Sie Nachforschungen anstellen müssen. Sie möchten wahrscheinlich auch eine gewisse Beobachtbarkeit, z. B. wie viele Datensätze gestern, heute, letzte Woche usw. extrahiert wurden und von welchen API-Endpunkten oder Datenbanktabellen sie stammen. Datenblockierung oder Hashing Je nachdem, woher Sie Daten beziehen, benötigen Sie möglicherweise einige Datenschutzfunktionen zum Blockieren oder Hashing von Spalten, bevor Sie sie weiterleiten. Um es klarzustellen: Das oben Genannte gilt nicht, wenn Sie nur einmalig ein paar Dateien verschieben möchten. Dies gilt jedoch, wenn Sie Produkte entwickeln, die eine Datenverschiebung erfordern. Früher oder später müssen Sie sich mit den meisten dieser Bedenken auseinandersetzen. Und obwohl keine einzelne davon ein unüberwindbares Hexenwerk ist, können sie zusammengenommen schnell einen oder mehrere Vollzeitjobs ergeben, und zwar umso mehr, je mehr Datenquellen Sie nutzen. Und genau das ist die Schwierigkeit bei der Aufrechterhaltung der Datenextraktion und Pipelines: Der Großteil der Kosten entsteht durch die kontinuierlichen inkrementellen Investitionen, die erforderlich sind, um diese Pipelines funktionsfähig und robust zu halten. Für die meisten KI-Ingenieure ist dies einfach nicht der Job, der ihren Benutzern den größten Mehrwert bietet. Ihre Zeit verbringen sie am besten woanders. Was muss ein KI-Ingenieur also tun, um hier einige Daten zu verschieben? Wenn Sie jemals Datenextraktions- und Ladepipelines benötigen, probieren Sie die bereits verfügbaren Lösungen aus, anstatt automatisch Ihre eigenen zu erstellen. Die Chancen stehen gut, dass sie viele, wenn nicht alle Ihrer Probleme lösen können. Wenn nicht, bauen Sie als letzten Ausweg Ihr eigenes. Und selbst wenn vorhandene Plattformen nicht alles unterstützen, was Sie benötigen, sollten Sie mit einem tragbaren und erweiterbaren Framework dennoch in der Lage sein, den größten Teil dieses Ziels zu erreichen. Auf diese Weise können Sie, anstatt alles von Grund auf neu zu erstellen, 90 % des Ziels mit Standardfunktionen der Plattform schaffen und nur die letzten 10 % erstellen und warten. Das häufigste Beispiel sind Long-Tail-Integrationen: Wenn die Plattform nicht mit einer Integration zu einer von Ihnen benötigten API ausgeliefert wird, erleichtert eine gute Plattform das Schreiben von Code oder sogar einer No-Code-Lösung zum Erstellen dieser Integration und Sie erhalten weiterhin alle nützlichen Funktionen, die die Plattform bietet. Selbst wenn Sie die Flexibilität wünschen, einen Connector einfach als Python-Paket zu importieren und ihn nach Belieben aus Ihrem Code auszulösen, können Sie eines der vielen Open-Source-EL-Tools wie Airbyte- oder Singer-Connectoren verwenden. Um es klar zu sagen: Die Datenbewegung ist nicht vollständig gelöst. Es gibt Situationen, in denen bestehende Lösungen wirklich unzureichend sind und Sie neue Lösungen entwickeln müssen. Dies ist jedoch nicht die Mehrheit der KI-Ingenieure. Die meisten Menschen müssen nicht immer wieder dieselben Integrationen mit Jira, Confluence, Slack, Notion, Gmail, Salesforce usw. neu erstellen. Nutzen wir einfach die Lösungen, die bereits praxiserprobt und für jedermann zugänglich gemacht wurden, damit wir den Mehrwert schaffen können, der unseren Benutzern tatsächlich am Herzen liegt. Erscheint auch . hier

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Dieses Audio ist in der Originalsprache der Geschichte produziert!

KI sollte keine Zeit damit verschwenden müssen, ETL neu zu erfinden

Zu lang; Lesen

John Lafleur

STORY’S CREDIBILITY

Opinion piece / Thought Leadership

Vested Interest

About Author

Hängeetiketten

Languages

DIESER ARTIKEL WURDE VORGESTELLT IN...