OlmoEarth 1.3: Aus einem Embedding wird nicht automatisch eine belastbare Karte

Ai2 veröffentlichte OlmoEarth 1.3 am 22. Oktober zusammen mit vorab berechneten jährlichen Satelliten-Embeddings. (Ai2)

Die Model Card beschreibt ein Fernerkundungsmodell. Damit ist keine allgemein verfügbare kommerzielle Inferenz-API nachgewiesen. (Ai2)

Merkmale, Modell und Fachkarte auseinanderhalten

Ein Embedding ist eine Darstellung von Merkmalen, nicht bereits die Antwort auf eine fachliche Frage. Wer beispielsweise Flächentypen unterscheiden möchte, braucht zusätzlich eine nachvollziehbare Definition der Klassen und geeignete Referenzen. Der Schritt von einem Vektor zu einer Karte muss deshalb als eigenes Auswertungsverfahren beschrieben werden.

Für einen ersten illustrativen Versuch könnte ein Team einen kleinen zulässigen Untersuchungsraum wählen und bekannte Flächentypen markieren. Getrennte Referenzflächen dienen anschliessend der Prüfung. Eine farbige Ausgabe wäre dann das Ergebnis dieses Versuchs, nicht der Beleg, dass jede Fläche korrekt erkannt wurde. In diesem Beitrag wurden keine Karten erzeugt oder Geodaten ausgewertet.

Räumliche Auflösung ist keine Aussagegenauigkeit

Der Anbieter beschreibt jährliche Embeddings auf einem 10-Meter-Raster. Diese räumliche Auflösung darf nicht mit der Genauigkeit einer bestimmten Klassifikationsaufgabe verwechselt werden. (Ai2)

Wenn der tatsächliche Einsatzzweck andere Jahreszeiten oder ungewöhnliche Flächen betrifft, muss die Prüfung diese Fälle sichtbar machen. Eine globale Herstellerbewertung kann Hinweise liefern, ersetzt aber nicht die Abnahme der eigenen Fragestellung. Ergebnisse sollten mit ihrem Zeitraum und verbleibenden Unsicherheiten ausgeliefert werden.

Die Lizenz ist nicht Apache 2.0

Die OlmoEarth Artifact License enthält Zweckbeschränkungen, unter anderem für Militär-/Verteidigungsanwendungen, Überwachung von Menschen, Polizeiarbeit und bestimmte Rohstoffgewinnung. Sie verlangt zudem Bedingungen bei Weitergabe. Eine pauschale Freigabe ohne Einschränkungen wäre falsch. (Ai2)

Vor einem Projekt sollte klar sein, welche Artefakte verwendet werden: Gewichte, vorberechnete Daten, Code oder daraus abgeleitete Ergebnisse. Für jeden Bestandteil gehört der konkrete Rechts- und Versionsstand in eine Akte. Der Downloadzugang allein beantwortet nicht, ob die beabsichtigte Nutzung und spätere Weitergabe zulässig sind.

Die Lizenzentscheidung muss auch Empfänger und Zweck der Ergebnisse berücksichtigen. Ein interner Versuch und eine an Dritte verteilte Ableitung sind nicht automatisch gleich zu behandeln. Bei einer entscheidenden oder unklaren Konstellation sind die Vertragsbedingungen geeignet zu klären; dieser Beitrag gibt keine individuelle Rechtsfreigabe.

Aufwand nicht auf den Modellaufruf reduzieren

Ob ein vorberechnetes Embedding oder eigene Berechnung sinnvoll ist, hängt unter anderem vom Gebiet, der benötigten Zeitabdeckung und der vorhandenen Infrastruktur ab. Datenübernahme, Ablage, Referenzaufbau und wiederholbare Auswertung können einen erheblichen Teil der Arbeit bestimmen. Konkrete Speicher- oder Rechenkosten lassen sich ohne dieses Mengengerüst nicht seriös beziffern.

1. Aufgabe, zulässiges Gebiet und erwartete Aussage definieren.
2. Artefakte, Revisionen, Lizenztexte und Drittquellen dokumentieren.
3. Referenzdaten und getrennte Prüfbereiche aufbauen.
4. Fehlerklassen und Grenzen der Aussage festlegen.
5. Erst nach der Prüfung den Betriebs- und Weitergabemodus entscheiden.

Der veröffentlichte Code kann das technische Verständnis unterstützen, ist aber keine Abnahme des eigenen Verfahrens. Vor einer Ausführung sind Umgebung, Abhängigkeiten und die für den gewählten Stand geltenden Rechte zu prüfen. (Ai2)

Das sinnvolle Ergebnis der Vorprüfung ist nicht «das Modell ist gut», sondern eine begründete Entscheidung für oder gegen eine klar definierte Aufgabe. Diese Entscheidung kann auch lauten, dass Referenzdaten, Rechte oder eine belastbare Auswertung noch fehlen.