im Aufkommen des Codeseine Reihe täglicher Programmierherausforderungen, die zum ersten Mal im Dezember veröffentlicht werden. Die täglichen Herausforderungen bestehen in der Regel aus zwei Rätseln, die auf einem ähnlichen Drawback aufbauen. Auch wenn diese Herausforderungen und Probleme nicht typischen Arbeitsabläufen in der Datenwissenschaft ähneln, habe ich festgestellt, dass viele der Gewohnheiten, Denkweisen und Problemansätze, die sie fördern, überraschend intestine auf datenorientierte Arbeit übertragen werden können. In diesem Artikel denke ich über fünf Erkenntnisse nach, die ich durch die Befolgung des erhalten habe Aufkommen des Codes Herausforderung in diesem Jahr und wie sie sich auf die Datenwissenschaft übertragen lassen.

Für mich, Aufkommen des Codes conflict eher eine kontrollierte Übungsumgebung, in der ich die Grundlagen wieder aufgreifen und an meinen Programmierkenntnissen arbeiten konnte. Sie konzentrieren sich auf das Wesentliche, da es keine Ablenkungen gibt, denen Sie im Arbeitsalltag ausgesetzt wären. Sie haben keine Besprechungen, keine sich ändernden Anforderungen, keine Stakeholder-Kommunikation oder keinen Koordinationsaufwand. Stattdessen haben Sie eine direkte und binäre Rückkopplungsschleife: Ihre Antwort ist richtig oder nicht. Es gibt kein „quick richtig“, keine Möglichkeit, das Ergebnis zu erklären und keine Möglichkeit, Ihre Lösung zu verkaufen. Gleichzeitig haben Sie die Freiheit und Flexibilität, jeden Ansatz zu wählen, den Sie für richtig halten, solange Sie zu einer richtigen Lösung gelangen.

Die Arbeit in einem solchen Umfeld conflict eine große Herausforderung, aber auch sehr wertvoll, da dadurch auch Gewohnheiten offengelegt wurden. Da Sie kaum Raum für Unklarheiten haben und Ihre Fehler nicht verbergen können, wurden eventuelle Mängel in Ihrer Arbeit sofort aufgedeckt. Mit der Zeit wurde mir auch klar, dass die meisten Fehler, auf die ich stieß, wenig mit der Syntax, der Wahl des Algorithmus oder der Codierungsimplementierung zu tun hatten, sondern viel mehr mit der Artwork und Weise, wie ich Probleme angegangen bin, bevor ich mit Code in Berührung gekommen bin. Was folgt, sind meine wichtigsten Erkenntnisse aus dieser Erfahrung.

Lektion 1: Skizzieren Sie die Lösung – Denken Sie nach, bevor Sie programmieren

Ein Muster, das währenddessen oft auftauchte Aufkommen des Codes conflict meine Tendenz, direkt in die Umsetzung zu gehen. Wenn ich mit einem neuen Drawback konfrontiert wurde, conflict ich normalerweise versucht, sofort mit dem Codieren zu beginnen und zu versuchen, so schnell wie möglich eine Lösung zu finden. Ironischerweise bewirkte dieser Ansatz oft genau das Gegenteil. Ich habe zum Beispiel tief verschachtelten Code geschrieben, um Grenzfälle zu bewältigen, die die Laufzeit des Codes in die Höhe trieben, ohne zu bemerken, dass es eine viel einfachere Lösung gab.

Was mir letztendlich geholfen hat, conflict, einen Schritt zurückzutreten, bevor ich mit dem Code begann. Stattdessen begann ich damit, Anforderungen, Eingaben und Einschränkungen zu notieren. Der Prozess des Notierens hat mir geholfen, ein Maß an Klarheit und Struktur zu erreichen, das mir gefehlt hatte, als ich direkt in den Code gesprungen conflict. Darüber hinaus trug das Nachdenken über mögliche Ansätze, das Skizzieren einer groben Lösung oder die Arbeit an einem Pseudocode dazu bei, die benötigte Logik noch weiter zu formalisieren. Sobald dies erledigt conflict, wurde die Implementierung über den Code viel einfacher.

Diese Erkenntnisse lassen sich auf die Datenwissenschaft übertragen, da viele Probleme aufgrund unklarer Ziele, schlecht formulierter Ziele oder weil Einschränkungen und Anforderungen im Voraus nicht intestine genug bekannt sind, eine Herausforderung darstellen können. Durch die Definition gewünschter Ergebnisse und Überlegungen zur Lösung vor Beginn des Codeschreibens kann unnötiger Aufwand vermieden werden. Wenn man vom angestrebten Ergebnis rückwärts arbeitet, anstatt von einer bevorzugten Technologie auszugehen, bleibt der Fokus auf dem eigentlichen Ziel, das erreicht werden muss.

Lernen 2: Eingabevalidierung – Kennen Sie Ihre Daten

Selbst nach diesem Ansatz, Lösungen zu skizzieren und die gewünschte Lösung im Voraus zu definieren, tauchte ein weiteres wiederkehrendes Hindernis auf: die Eingabedaten. Einige Fehler, die ich erlebte, hatten nichts mit fehlerhaftem Code zu tun, sondern mit Annahmen über die Daten, die ich gemacht hatte, die in der Praxis nicht zutrafen. In einem Fall ging ich davon aus, dass die Daten eine bestimmte Mindest- und Höchstgrenze hatten, was sich als falsch herausstellte und zu einer falschen Lösung führte. Schließlich kann Code isoliert betrachtet korrekt sein, aber völlig versagen, wenn er mit Daten arbeitet, für die er nie entwickelt wurde.

Dies zeigte erneut, warum die Überprüfung der Eingabedaten so wichtig ist. Oft musste meine Lösung nicht komplett überarbeitet werden, kleinere Anpassungen wie die Einführung zusätzlicher Bedingungen oder Grenzüberprüfungen reichten aus, um eine korrekte und robuste Lösung zu erhalten. Darüber hinaus kann eine erste Datenuntersuchung Hinweise auf den Umfang der Daten geben und Hinweise darauf geben, welche Ansätze machbar sind. Bei großen Bereichen, extremen Werten oder hoher Kardinalität ist es sehr wahrscheinlich, dass Brute-Power-Methoden, verschachtelte Schleifen oder kombinatorische Ansätze schnell an ihre Grenzen stoßen.

Dies ist natürlich ebenso wichtig bei datenwissenschaftlichen Projekten, bei denen Annahmen über Daten (implizit oder explizit) zu ernsthaften Problemen führen können, wenn sie nicht überprüft werden. Die frühzeitige Untersuchung von Daten ist ein entscheidender Schritt, um zu verhindern, dass sich Probleme nach unten ausbreiten, wo es später viel schwieriger werden kann, sie zu beheben. Die wichtigste Erkenntnis besteht nicht darin, Annahmen über Daten überhaupt zu vermeiden, sondern sie vielmehr explizit zu machen, zu dokumentieren und frühzeitig im Prozess zu testen.

Lernen 3: Schnell iterieren – Fortschritt statt Perfektion

Die Rätsel in Aufkommen des Codes werden in der Regel in zwei Teile geteilt. Während die zweite häufig auf der ersten aufbaut, bringt sie eine neue Einschränkung, Herausforderung oder Wendung mit sich, beispielsweise eine Vergrößerung der Problemgröße. Die zunehmende Komplexität machte die ursprüngliche Lösung für den ersten Teil oft ungültig. Dies bedeutet jedoch nicht, dass die Lösung des ersten Teils nutzlos ist, da sie eine wertvolle Grundlage bietet.

Eine solche funktionierende Ausgangsbasis hilft zu klären, wie sich das Drawback verhält, wie es angegangen werden kann und was die Lösung bereits bewirkt. Von da an können Verbesserungen strukturierter angegangen werden, da man weiß, welche Annahmen nicht mehr gelten und welche Teile geändert werden müssen, um zu einer erfolgreichen Lösung zu gelangen. Die Verfeinerung einer konkreten Basislösung ist daher viel einfacher, als von Anfang an eine abstrakte „perfekte“ Lösung zu entwerfen.

In Aufkommen des Codesder zweite Teil erscheint erst, nachdem der erste gelöst wurde, wodurch frühe Versuche, eine Lösung zu finden, die für beide Teile funktioniert, sinnlos sind. Diese Struktur spiegelt eine in der Praxis häufig anzutreffende Einschränkung wider, da man in der Regel nicht alle Anforderungen im Voraus kennt. Der Versuch, alle möglicherweise erforderlichen Erweiterungen im Voraus vorherzusagen, ist nicht nur weitgehend spekulativ, sondern auch ineffizient.

In der Datenwissenschaft lassen sich ähnliche Prinzipien beobachten. Wenn sich Anforderungen ändern, Datenquellen sich weiterentwickeln und Stakeholder ihre Bedürfnisse und Anfragen verfeinern, müssen sich auch Projekte und Lösungen weiterentwickeln. Daher ist es weitaus effektiver, mit einfachen Lösungen zu beginnen und auf der Grundlage echten Feedbacks zu iterieren, als zu versuchen, von Anfang an ein vollständig allgemeines System zu entwickeln. Solch eine „perfekte“ Lösung ist am Anfang selten sichtbar, und die Iteration ist es, die es den Lösungen ermöglicht, zu etwas Nützlichem zu konvergieren.

Lernen 4: Design for Scale – Kennen Sie die Grenzen

Während bei der Iteration der Schwerpunkt darauf liegt, mit einfachen Lösungen zu beginnen, Aufkommen des Codes weist auch immer wieder darauf hin, wie wichtig es ist, die Größenordnung zu verstehen und wie sie sich auf den zu verwendenden Ansatz auswirkt. Bei vielen Rätseln erhöht der zweite Teil nicht nur die logische Komplexität, sondern erhöht auch die Problemgröße dramatisch. Daher kann eine Lösung mit exponentieller oder faktorieller Komplexität für den ersten Teil ausreichend sein, wird jedoch unpraktisch, wenn die Problemgröße im zweiten Teil zunimmt.

Selbst wenn man mit einer einfachen Basislinie beginnt, ist es wichtig, eine ungefähre Vorstellung davon zu haben, wie sich diese Lösung skalieren lässt. Verschachtelte Schleifen, Brute-Power-Aufzählung oder erschöpfende Suche nach Kombinationen signalisieren, dass die Lösung nicht mehr so ​​effizient funktioniert, wenn das Drawback größer wird. Wenn Sie den (ungefähren) Bruchpunkt kennen, können Sie leichter abschätzen, ob oder wann ein Umschreiben erforderlich ist.

Dies widerspricht nicht dem Gedanken, eine vorzeitige Optimierung zu vermeiden. Vielmehr bedeutet es, dass man die Kompromisse verstehen sollte, die eine Lösung mit sich bringt, ohne gleich den effizientesten oder skalierbarsten Ansatz implementieren zu müssen. Skalierungsorientiertes Design bedeutet, sich der Skalierbarkeit und Komplexität bewusst zu sein und nicht von Anfang an blind optimieren zu müssen.

Hier ist auch eine Parallele zur Datenwissenschaft gegeben, da Lösungen bei Beispieldaten oder begrenzten Datensätzen intestine funktionieren können, bei Größen auf „Produktionsebene“ jedoch zum Scheitern neigen. Sich dieser Engpässe bewusst zu sein, wahrscheinliche Grenzen zu erkennen und various Ansätze im Auge zu behalten, macht diese Systeme widerstandsfähiger. Wenn Sie wissen, wo eine Lösung möglicherweise nicht mehr funktioniert, können später kostspielige Neugestaltungen und Neufassungen vermieden werden, selbst wenn diese nicht sofort implementiert werden.

Lernen 5: Seien Sie konsequent – ​​Schwung schlägt Motivation

Eine der weniger offensichtlichen Erkenntnisse aus der Teilnahme am Creation of Code hatte weniger mit der Lösung von Problemen als vielmehr mit dem „Auftauchen“ zu tun. Jeden Tag ein Rätsel zu lösen, klingt theoretisch machbar, conflict aber in der Praxis eine Herausforderung, vor allem, wenn es mit Müdigkeit, begrenzter Zeit oder einem Rückgang der Motivation einherging, insbesondere nach einem ganzen Arbeitstag. Die Hoffnung, dass die Motivation auf magische Weise wieder auftaucht, conflict daher keine praktikable Strategie.

Wirkliche Fortschritte wurden durch die tägliche Arbeit an Problemen erzielt, nicht durch gelegentliche Inspirationsschübe. Durch die Wiederholung wurden Denkweisen gestärkt und Probleme entwirrt, was wiederum für Dynamik sorgte. Sobald dieser Schwung aufgebaut conflict, begannen sich die Fortschritte zu verschärfen und Beständigkeit conflict wichtiger als Intensität.

Auch die Kompetenzentwicklung in der Datenwissenschaft erfolgt selten durch einmalige Projekte oder isolierte Vertiefungen. Stattdessen ist es das Ergebnis wiederholter Übung, des sorgfältigen Lesens von Daten, des Entwerfens von Lösungen, des Iterierens von Modellen und des Debuggens von Annahmen, die im Laufe der Zeit konsequent durchgeführt werden. Sich auf Motivation zu verlassen ist nicht praktikabel, aber feste Routinen machen es nachhaltig. Aufkommen des Codes veranschaulichte diesen Unterschied: Während die Motivation schwankt, verstärkt sich die Konsistenz. Eine solche Tagesstruktur hat dazu beigetragen, das Lösen von Rätseln zur Gewohnheit und nicht zum Wunsch zu machen.

Schlussgedanken

Wenn ich zurückblicke, ist der wahre Wert, den ich aus der Teilnahme gezogen habe Aufkommen des Codes Es ging mir nicht darum, einzelne Rätsel zu lösen oder ein paar neue Programmiertricks zu lernen, sondern darum, meine Gewohnheiten sichtbar zu machen. Es hat gezeigt, wo ich dazu neige, überstürzt nach Lösungen zu suchen, wo ich dazu neige, es zu kompliziert zu machen, und wo es mir viel Zeit gespart hätte, langsamer zu werden und einen Schritt zurückzutreten. Die Rätsel als solche waren nur ein Mittel zum Zweck, die Erkenntnisse, die ich daraus gewonnen habe, waren der wahre Wert.

Aufkommen des Codes Für mich funktionierte es am besten, wenn ich es als bewusstes Coaching und nicht als Wettbewerb betrachtete. Es erwies sich als weitaus wertvoller, konsequent aufzutreten, sich auf Klarheit statt auf Klugheit zu konzentrieren und Lösungen zu verfeinern, anstatt von Anfang an nach perfekten Lösungen zu streben, als eine einzige Lösung zu finden.

Wenn Sie es noch nicht selbst ausprobiert haben, würde ich Ihnen empfehlen, es auszuprobieren, entweder während der Veranstaltung im nächsten Jahr oder durch das Durcharbeiten früherer Rätsel. Der Prozess bringt schnell Gewohnheiten zum Vorschein, die über die Rätsel selbst hinausgehen. Und wenn Sie Spaß daran haben, Herausforderungen anzugehen, wird es höchstwahrscheinlich eine wirklich unterhaltsame und lohnende Erfahrung sein.

Computergestützte Designsysteme (CAD) sind bewährte Werkzeuge zum Entwerfen vieler physischer Objekte, die wir täglich verwenden. Allerdings erfordert die Beherrschung von CAD-Software program umfangreiches Fachwissen, und viele Instruments verfügen über einen so hohen Detaillierungsgrad, dass sie sich nicht für Brainstorming oder Speedy Prototyping eignen.

Um Design schneller und für Laien zugänglicher zu machen, haben Forscher vom MIT und anderswo ein KI-gesteuertes Roboter-Montagesystem entwickelt, das es Menschen ermöglicht, physische Objekte zu bauen, indem sie sie einfach in Worten beschreiben.

Ihr System verwendet ein generatives KI-Modell, um basierend auf der Eingabeaufforderung des Benutzers eine 3D-Darstellung der Geometrie eines Objekts zu erstellen. Anschließend ermittelt ein zweites generatives KI-Modell das gewünschte Objekt und findet heraus, wo verschiedene Komponenten entsprechend der Funktion und Geometrie des Objekts platziert werden sollten.

Das System kann das Objekt mithilfe der Robotermontage automatisch aus einem Satz vorgefertigter Teile erstellen. Das Design kann auch basierend auf dem Suggestions des Benutzers iteriert werden.

Die Forscher nutzten dieses Finish-to-Finish-System, um Möbel, darunter Stühle und Regale, aus zwei Arten vorgefertigter Komponenten herzustellen. Die Komponenten können nach Belieben zerlegt und wieder zusammengebaut werden, wodurch die Menge an Abfall reduziert wird, die durch den Herstellungsprozess entsteht.

Sie bewerteten diese Designs im Rahmen einer Benutzerstudie und stellten fest, dass mehr als 90 Prozent der Teilnehmer die von ihrem KI-gesteuerten System hergestellten Objekte im Vergleich zu anderen Ansätzen bevorzugten.

Obwohl es sich bei dieser Arbeit um eine erste Demonstration handelt, könnte das Framework besonders für die schnelle Prototypenerstellung komplexer Objekte wie Luft- und Raumfahrtkomponenten und Architekturobjekte nützlich sein. Längerfristig könnte es in Privathaushalten zur Herstellung von Möbeln oder anderen Gegenständen vor Ort eingesetzt werden, ohne dass sperrige Produkte von einer zentralen Einrichtung verschickt werden müssen.

„Früher oder später wollen wir in der Lage sein, mit einem Roboter und einem KI-System auf die gleiche Weise zu kommunizieren und zu reden, wie wir miteinander reden, um gemeinsam Dinge zu erschaffen. Unser System ist ein erster Schritt, um diese Zukunft zu ermöglichen“, sagt Hauptautor Alex Kyaw, ein Doktorand in den MIT-Fakultäten für Elektrotechnik und Informatik (EECS) und Architektur.

Kyaw wird bei dem Artikel von Richa Gupta unterstützt, einer Architekturstudentin am MIT; Faez Ahmed, außerordentlicher Professor für Maschinenbau; Lawrence Sass, Professor und Vorsitzender der Computation Group im Fachbereich Architektur; leitender Autor Randall Davis, EECS-Professor und Mitglied des Pc Science and Synthetic Intelligence Laboratory (CSAIL); sowie andere bei Google Deepmind und Autodesk Analysis. Der Papier wurde kürzlich auf der Konferenz über neuronale Informationsverarbeitungssysteme vorgestellt.

Generieren eines Mehrkomponentendesigns

Während generative KI-Modelle intestine darin sind, aus Texteingaben 3D-Darstellungen, sogenannte Meshes, zu generieren, erzeugen die meisten keine einheitlichen Darstellungen der Geometrie eines Objekts, die über die für die Robotermontage erforderlichen Particulars auf Komponentenebene verfügen.

Die Aufteilung dieser Netze in Komponenten stellt für ein Modell eine Herausforderung dar, da die Zuweisung von Komponenten von der Geometrie und Funktionalität des Objekts und seiner Teile abhängt.

Die Forscher gingen diese Herausforderungen mithilfe eines Imaginative and prescient-Language-Modells (VLM) an, einem leistungsstarken generativen KI-Modell, das vorab darauf trainiert wurde, Bilder und Textual content zu verstehen. Sie beauftragen das VLM damit, herauszufinden, wie zwei Arten vorgefertigter Teile, Strukturbauteile und Plattenbauteile, zu einem Objekt zusammenpassen sollten.

„Es gibt viele Möglichkeiten, Platten auf einem physischen Objekt anzubringen, aber der Roboter muss die Geometrie sehen und über diese Geometrie nachdenken, um eine Entscheidung darüber treffen zu können. Indem das VLM sowohl als Auge als auch als Gehirn des Roboters dient, ermöglicht es dem Roboter, dies zu tun“, sagt Kyaw.

Ein Benutzer fordert das System mit Textual content auf, beispielsweise durch die Eingabe von „Mach mir einen Stuhl“, und gibt ihm zum Starten ein KI-generiertes Bild eines Stuhls.

Dann überlegt das VLM den Stuhl und bestimmt anhand der Funktionalität vieler Beispielobjekte, die es zuvor gesehen hat, wo Plattenkomponenten auf Strukturkomponenten platziert werden. Beispielsweise kann das Modell festlegen, dass der Sitz und die Rückenlehne über Platten verfügen sollen, um eine Sitz- und Anlehnfläche für jemanden zu schaffen, der auf dem Stuhl sitzt.

Es gibt diese Informationen als Textual content aus, beispielsweise „Sitz“ oder „Rückenlehne“. Jede Oberfläche des Stuhls wird dann mit Nummern beschriftet und die Informationen werden an das VLM zurückgemeldet.

Anschließend wählt der VLM die Beschriftungen aus, die den geometrischen Teilen des Stuhls entsprechen, die zur Vervollständigung des Entwurfs mit Panels auf dem 3D-Netz versehen werden sollen.

Co-Design von Mensch und KI

Der Benutzer bleibt während dieses Prozesses auf dem Laufenden und kann das Design verfeinern, indem er dem Modell eine neue Eingabeaufforderung gibt, z. B. „Verwenden Sie nur Paneele an der Rückenlehne, nicht am Sitz.“

„Der Gestaltungsspielraum ist sehr groß, daher schränken wir ihn anhand von Benutzerfeedback ein. Wir glauben, dass dies der beste Weg ist, da Menschen unterschiedliche Vorlieben haben und es unmöglich wäre, ein idealisiertes Modell für alle zu erstellen“, sagt Kyaw.

„Der Human-in-the-Loop-Prozess ermöglicht es den Benutzern, die KI-generierten Designs zu steuern und ein Gefühl der Eigenverantwortung für das Endergebnis zu entwickeln“, fügt Gupta hinzu.

Sobald das 3D-Netz fertiggestellt ist, baut ein Roboter-Montagesystem das Objekt aus vorgefertigten Teilen auf. Diese wiederverwendbaren Teile können zerlegt und in verschiedenen Konfigurationen wieder zusammengebaut werden.

Die Forscher verglichen die Ergebnisse ihrer Methode mit einem Algorithmus, der Paneele auf allen horizontalen Flächen platziert, die nach oben zeigen, und einem Algorithmus, der Paneele zufällig platziert. In einer Benutzerstudie bevorzugten mehr als 90 Prozent der Personen die von ihrem System erstellten Designs.

Sie baten das VLM außerdem, zu erklären, warum es sich für die Anbringung von Panels in diesen Bereichen entschieden habe.

„Wir haben gelernt, dass das Imaginative and prescient-Language-Modell in der Lage ist, die funktionalen Aspekte eines Stuhls, wie Lehnen und Sitzen, bis zu einem gewissen Grad zu verstehen und zu verstehen, warum es Paneele auf dem Sitz und der Rückenlehne anbringt. Es spuckt diese Aufgaben nicht einfach nur wahllos aus“, sagt Kyaw.

Zukünftig wollen die Forscher ihr System so erweitern, dass es auch komplexere und differenziertere Benutzereingaben bewältigen kann, etwa einen Tisch aus Glas und Metall. Darüber hinaus wollen sie weitere vorgefertigte Komponenten wie Zahnräder, Scharniere oder andere bewegliche Teile einbauen, um den Objekten mehr Funktionalität zu verleihen.

„Unsere Hoffnung ist es, die Hürde beim Zugang zu Design-Instruments drastisch zu senken. Wir haben gezeigt, dass wir generative KI und Robotik nutzen können, um Ideen schnell, zugänglich und nachhaltig in physische Objekte umzuwandeln“, sagt Davis.

Ahh, das Meer.

Der Urlaub auf dem mediterranen Meer lag am Strand und starrte in die Wellen. Woman Luck hatte einen guten Tag: Die Sonne starrte von einem blauen und wolkenlosen Himmel herab und erhitzte den Sand und das salzige Meer um mich herum. Zum ersten Mal seit einiger Zeit hatte ich Ausfallzeiten. In der abgelegenen Area, in der ich warfare, gab es nichts mit ML zu tun, wo die rauen Straßen jeden verängstigt hätten, der sich an die gleichmäßigen Gehwege westlicher Länder gewöhnt hat.

Dann, weg von der Arbeit und teilweise Zivilisation, irgendwo zwischen Zonierung und Daydreaming, begannen meine Gedanken zu driften. In unserem täglichen Geschäft sind wir auch damit beschäftigt, Zeit damit zu verbringen, nichts zu tun. Aber Nichts ist hier ein starkes Wort: Als meine Gedanken teuerten, erinnerte ich mich zuerst an die jüngsten Ereignisse, dachte dann über die Arbeit nach und kam dann schließlich zum maschinellen Lernen an.

Vielleicht Spuren meines vorherigen Artikels –wo ich 6,5 Jahre „Machen“ ml nachdachte– Ich warfare immer noch im Hinterkopf. Oder vielleicht warfare es einfach die völlige Abwesenheit von irgendetwas Technischen um mich herum, wo das Meer mein einziger Begleiter warfare. Was auch immer der Grund warfare, ich begann psychological, die Jahre hinter mir zu proben. Was warfare intestine gelaufen? Was warfare seitwärts gegangen? Und – vor allem – was wünschte ich, jemand hätte mir zu Beginn jemand gesagt?

Dieser Beitrag ist eine Sammlung dieser Dinge. Es soll keine Liste dummer Fehler sein, die ich andere dringend bittet, um jeden Preis zu vermeiden. Stattdessen ist es mein Versuch, die Dinge aufzuschreiben, die meine Reise ein bisschen reibungsloser gemacht hätten (aber nur ein bisschen ist Unsicherheit notwendig, um die Zukunft genau das zu machen: die Zukunft). Teile meiner Liste überschneiden sich mit meinem vorherigen Beitrag und aus gutem Grund: Einige Lektionen lohnt sich wieder zu wiederholen und erneut zu lesen.

Hier ist Teil 1 dieser Liste. Teil 2 ist derzeit in meinem sandigen, seewasserfleckigen Notizbuch begraben. Mein Plan ist es, in den nächsten Wochen damit nachzuverfolgen, sobald ich genug Zeit habe, um es in einen Qualitätsartikel zu verwandeln.

1. ML MEHR MEH

Dies ist ein Punkt, den ich versuche, nicht zu viel nachzudenken, oder es wird mir sagen: Sie haben Ihre Hausaufgaben nicht gemacht.

Als ich anfing, warfare mein interner Monolog so etwas wie: „Ich will nur ml. ““ Was auch immer das bedeutete; letztlich Trainieren Sie ein maschinelles Lernenmodell. Das Modelltraining ist ironischerweise oft der kürzeste und letzte Teil des gesamten Prozesses.

Jedes Mal, wenn ich endlich zum Modelltrainingsschritt komme, atme ich psychological auf Erleichterung auf, weil ich es durch das unsichtbare Teil geschafft habe: die Daten vorzubereiten. Es gibt nichts „Verkaufbar“ in lediglich die Daten vorbereiten. Nach meiner Erfahrung ist die Vorbereitung der Daten in keiner Weise auffällig (solange es intestine genug gemacht wird).

Hier ist das übliche Muster dafür:

• Sie haben ein Projekt.
• Sie erhalten einen realen Datensatz. (Wenn Sie mit einem intestine kuratierten Benchmark-Datensatz arbeiten, haben Sie Glück!)
• Sie möchten ein Modell trainieren.
• Aber zuerst… Datenreinigung, Fixieren, Verschmelzen, Validieren.

Lassen Sie mich Ihnen ein persönliches Beispiel geben, das Ich habe als lustige Geschichte erzählt (Was es jetzt ist. Damals bedeutete es, ein paar Tage maschinelles Lernen unter Zeitdruck wieder zu resotieren…).

Ich habe einmal an einem Projekt gearbeitet, bei dem ich die Vegetationsdichte (unter Verwendung des NDVI -Index) aus ERA5 -Wetterdaten vorhersagen wollte. ERA5 ist ein massiver Gitter-Datensatz, der frei im Europäischen Zentrum für Wettervorhersagen mit mittlerer Reichweite erhältlich ist. Ich habe diesen Datensatz mit NDVI -Satellitendaten von NOAA (im Grunde genommen der amerikanischen Wetteragentur) zusammengeführt, die Auflösungen sorgfältig ausgerichtet, und alles schien in Ordnung zu sein – keine Fehlanpassungen, keine Fehler wurden geworfen.

Dann rief ich die Datenvorbereitung an und trainierte ein Sehtransformatormodell auf dem kombinierten Datensatz. Ein paar Tage später habe ich die Ergebnisse und… Überraschung visualisiert! Das Modell dachte, die Erde sei auf den Kopf. Im wahrsten Sinne des Wortes waren meine Eingabedaten nach rechts, aber die Zielvegetationsdichte wurde am Äquator umgedreht.

Was warfare passiert? Ein subtiler Fehler in meiner Auflösungsübersetzung drehte die Breitengradorientierung der Vegetationsdaten um. Ich hatte es nicht bemerkt, weil ich bereits viel Zeit mit der Datenvorbereitung verbracht habe und schnell zum „lustigen Teil“ gelangen wollte.

Diese Artwork von Fehler ärgert sich in einem wichtigen Punkt: ML-Projekte in der realen Welt sind Datenprojekte. Insbesondere außerhalb der akademischen Forschung arbeiten Sie nicht mit Cifar oder ImageNet. Sie arbeiten mit chaotischen, unvollständigen, teilweise Labellel und Multi-Supply-Datensätzen, die erforderlich sind:

• Reinigung
• Ausrichten
• Normalisierung
• Debuggen
• Visuelle Inspektion

Und noch mehr ist diese Liste nicht exexhautiv. Dann alle oben genannten wiederholen.

Die Daten richtig machen Ist die Arbeit. Alles andere baut auf dieser (traurig unsichtbaren) Fundament auf.

2. Das Schreiben von Papieren ist wie die Vorbereitung eines Verkaufsgesprächs

Einige Papiere nur intestine lesen. Möglicherweise können Sie nicht erklären, warum, aber sie haben einen Fluss, eine Logik, eine Klarheit, die schwer zu ignorieren ist. Das ist selten zufällig*. Für mich stellte sich heraus, dass das Schreiben von Papieren ähnlich ist, um eine ganz bestimmte Artwork von Verkaufsgespräch zu erstellen. Du verkaufst deine Ideedein Ansatzdein Einblick zu einem skeptischen Publikum.

Dies warfare eine überraschende Erkenntnis für mich.

Als ich anfing, nahm ich an, dass die meisten Papiere genauso aussahen und fühlten. Alle von ihnen waren für mich „wissenschaftliches Schreiben“. Aber im Laufe der Zeit bemerkte ich, als ich mehr Papiere las, die Unterschiede. Es ist wie das Sprichwort: Außenstehende sehen alle Schafe gleich aus; Für den Hirten ist jeder unterschiedlich.

Vergleichen Sie beispielsweise diese beiden Papiere, auf die ich in letzter Zeit gestoßen bin:

Beide verwenden maschinelles Lernen. Aber sie sprechen mit unterschiedlichem Publikum mit unterschiedlichen Abstraktionsebenen, unterschiedlichen narrativen Stilen und sogar unterschiedlichen Motivationen. Der erste geht davon aus, dass die technische Neuheit von zentraler Bedeutung ist. Der zweite konzentriert sich auf die Relevanz für Anwendungen. Offensichtlich gibt es auch den visuellen Unterschied zwischen den beiden.

Je mehr Papiere Sie lesen, desto mehr erkennen Sie: Es gibt nicht eins Weg, um ein „gutes“ Papier zu schreiben. Es gibt viele Möglichkeiten, und der Weg variiert je nach Publikum.

Und es sei denn, Sie sind einer dieser sehr seltenen brillanten Köpfe (denken Sie an Terence Tao oder jemand dieses Kalibers), Sie brauchen wahrscheinlich Unterstützung, um intestine zu schreiben. Vor allem bei Anpassung eines Papiers für eine bestimmte Konferenz oder ein bestimmtes Journal. In der Praxis bedeutet dies, eng mit einer hochrangigen ML -Individual zusammenzuarbeiten, die das Feld versteht.

Das Erstellen eines guten Papiers ist wie die Vorbereitung eines Verkaufsgesprächs. Sie müssen:

• Rahmen Sie das Drawback richtig ein
• Verstehe deine Zielgruppe (dh Goal -Veranstaltungsort)
• Betonen Sie die Teile, die am meisten Resonanz finden
• Und polieren, bis die Nachricht bleibt

3. Die Fixierung des Fehlers ist der Weg nach vorne

Vor Jahren hatte ich diese romantische Idee von ML als Erkundung eleganter Modelle, Erfindung neuer Aktivierungsfunktionen oder das Erstellen von cleveren Verlustfunktionen. Das kann für eine kleine Reihe von Forschern zutreffen. Aber für mich sah der Fortschritt oft so aus: „Warum fährt dieser Code nicht aus?“ Oder noch frustrierender: „Dieser Code lief erst vor ein paar Sekunden-warum läuft er nicht mehr Jetzt? „

Nehmen wir an, in Ihrem Projekt müssen Imaginative and prescient -Transformatoren für Umwelt -Satellitendaten verwendet werden (dh der Modellseite von Abschnitt 1 oben). Sie haben zwei Optionen:

1. Implementieren Sie alles von Grund auf neu (nicht empfohlen, es sei denn, Sie fühlen sich besonders abenteuerlich oder müssen es für Kursnachweise tun).
2. Finden Sie eine vorhandene Implementierung und passen Sie sie an.

In 99% der Fälle ist Choice 2 die offensichtliche Wahl. Aber „einfach Ihre Daten einschließen“ funktioniert quick nie. Sie werden auf:

• Verschiedene Berechnungsumgebungen
• Annahmen über Eingangsformen
• Vorverarbeitung von Macken (z. B. Datennormalisierung)
• Hartcodierte Abhängigkeiten (von denen ich auch schuldig bin)

Schnell kann Ihr Tag zu einer endlosen Reihe von Debugging-, Backtracking-, Testen von Kantenfällen, Änderungen von Dataloadern, Überprüfung des GPU -Speichers ** und der Wiederaufnahme von Skripten. Dann beginnen die Dinge langsam zu funktionieren. Schließlich trainiert Ihr Modell.

Aber es ist nicht schnell. Es ist Fehler beheben Sie Ihren Weg nach vorne.

4. Ich (ganz mit Sicherheit) wird nicht machen Das Durchbruch

Sie haben definitiv von ihnen gehört. Der Transformator Papier. Die Gans. Stabile Diffusion. Es gibt einen kleinen Teil in meinem, der denkt: Vielleicht werde ich das nächste transformative Papier schreiben. Und sicher muss jemand. Aber statistisch gesehen werde es wahrscheinlich nicht ich. Oder Sie, Entschuldigung. Und das ist in Ordnung.

Die Werke, die dazu führen, dass ein Feld schnell ändert, sind per Definition außergewöhnlich. Diese Arbeiten sind außergewöhnlich, dass die meisten Werke, selbst gute Arbeit, kaum erkannt werden. Manchmal hoffe ich immer noch, dass eines meiner Projekte „in die Luft jagen“ würde. Aber bisher haben es die meisten nicht. Einige wurden nicht einmal veröffentlicht. Aber hey, das ist kein Misserfolg – es ist die Grundlinie. Wenn Sie erwarten, dass jedes Papier ein Homerun ist, sind Sie auf der schnellen Spur enttäuscht.

Gedanken schließen

Für mich erscheint maschinelles Lernen oft als schlankes, modernes Feld-eines, in dem sich Durchbrüche gleich um die Ecke haben und wo das „Tun“ intelligente Menschen mit GPUs und Mathematik Magie machen. Aber in meiner täglichen Arbeit ist es selten so.

Meistens besteht meine tägliche Arbeit aus:

• Umgang mit unordentlichen Datensätzen
• Debugging -Code aus GitHub gezogen
• Redrapferpapiere immer und immer wieder
• Wiederum neuartige Ergebnisse produzieren

Und das ist okay.

---

Fußnoten

Der vorherige Artikel erwähnte: https://towardsdatascience.com/lessons-lenarned-after-6-5-Jahre-of-machine-learning/

* Wenn Sie interessiert sind, ist mein Lieblingspapier das eine: https://arxiv.org/abs/2103.09762. Ich habe es vor einem Jahr an einem Freitagnachmittag gelesen.

** Bis heute erhalte ich immer noch E -Mail -Benachrichtigungen darüber, wie das Löschen des GPU -Speichers im Tensorflow unmöglich ist. Dieses 5-jährige GitHub-Drawback gibt die Particulars.

Ich sagte immer: „Ich habe nicht genug Zeit.“ In Wirklichkeit hatte ich einfach die falschen Prioritäten gesetzt und konnte mein Zeitmanagement seitdem deutlich verbessern.

So sehr, dass ich mehrmals gefragt wurde, wie ich es schaffe, ständig YouTube-Movies und Blogbeiträge zu posten, jede Woche einen E-newsletter zu schreiben und quick jeden Tag Sport zu treiben, während ich einer Vollzeitbeschäftigung nachgehe.

In diesem Artikel möchte ich meinen Prozess darlegen und hoffentlich jedem, der Schwierigkeiten hat, alle seine Prioritäten unter einen Hut zu bringen, ein paar Tipps geben.