> For the complete documentation index, see [llms.txt](https://docs.tabiya.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tabiya.org/tabiya-documentation/deutsch/unser-technologie-stack/inclusive-livelihoods-taxonomy/lessons-learned.md).
# Gelehrte Lektionen
Die Erweiterung der ESCO-Taxonomie durch die Einbeziehung der unsichtbaren Ökonomie und die Anpassung unserer Methodik an die aufgetretenen Herausforderungen hat uns wertvolle Erkenntnisse gebracht.
## ESCO vs. O\*Net
{% hint style="info" %}
In Überarbeitung
{% endhint %}
## Wahl der ICATUS-Ebene
Wie besprochen [hier](/tabiya-documentation/deutsch/unser-technologie-stack/inclusive-livelihoods-taxonomy.md), umfasst die ICATUS-Taxonomie drei Ebenen, die unterschiedliche Detaillierungsgrade repräsentieren, nämlich die Ebenen Hauptabteilung, Abteilung und Gruppe. Für das Matching-Verfahren von Tabiya werden die Aktivitäten auf Gruppenebene, die der unsichtbaren Wirtschaft zugeordnet sind, ESCO-Berufen zugeordnet. Insgesamt gibt es 60 ICATUS-Aktivitäten auf Gruppenebene, die den ICATUS-Input des Frameworks ausmachen. Die Gruppenebene wird anstelle der Ebene Hauptabteilung oder Abteilung vor allem deshalb gewählt, weil die Gruppenebene in der ICATUS-Taxonomie den höchsten Präzisionsgrad erreicht. So können wir beim Matching auf dieser Ebene im Vergleich zur Hauptabteilungs- und Abteilungsebene die meisten Details erfassen.
Die Herausforderung bestand jedoch darin, Aktivitäten auf Gruppenebene ESCO-Berufen zuzuordnen, da diese gelegentlich Aktivitäten und Berufe mit unterschiedlichem Detaillierungsgrad definieren. Insbesondere stellen wir fest, dass es einige Fälle gibt, in denen ein ESCO-Beruf mehr als einer ICATUS-Gruppenebene entspricht. So werden beispielsweise die Aktivitäten auf ICATUS-Gruppenebene „Aufräumen nach der Zubereitung von Speisen/Mahlzeiten/Snacks“ und „Zubereiten von Mahlzeiten/Snacks“ jeweils dem ESCO-Beruf „Küchenhelfer“ zugeordnet (definiert als „Küchenhelfer unterstützen bei der Zubereitung von Speisen und bei der Reinigung des Küchenbereichs.“). Offensichtlich besteht der Beruf „Küchenhelfer“ aus diesen beiden ICATUS-Aktivitäten auf Gruppenebene. Theoretisch wäre eine Möglichkeit, dies zu umgehen, ICATUS-Aktivitäten auf der Abteilungsebene statt auf der Gruppenebene zuzuordnen. Diese Methode wird jedoch letztlich als zu informationskostspielig angesehen, da auf der Abteilungsebene die Wahrscheinlichkeit sehr hoch ist, relativ seltene, aber relevante ESCO-Berufe (und damit Fähigkeiten) aus dem ICATUS-zu-ESCO-Mapping auszulassen. Dies schadet dem Endnutzer, weil dadurch die spätere Liste verfügbarer Fähigkeiten zur Darstellung der von ihm ausgeübten Arbeit eingeschränkt wird. Nach Diskussionen zwischen dem Forschungsteam und dem Harambee-Team waren wir uns einig, dass es in diesem Fall am besten ist, ICATUS-Aktivitäten auf Gruppenebene ESCO-Berufen zuzuordnen, um keinen Schaden anzurichten.
## ESCO-Berufe als Zwischenschritt zu Fähigkeiten (NLP, Word2Vec usw.)
Der Grund dafür, dass ICATUS-Aktivitäten zunächst mit ESCO-Berufen und erst danach mit Fähigkeiten abgeglichen werden, anstatt ICATUS-Aktivitäten direkt mit Fähigkeiten abzugleichen, erfordert eine Zusammenfassung des konzeptionellen Weges, der letztlich zu dieser Entscheidung führte. Zunächst schien es, da das Ziel darin besteht, Aktivitäten Fähigkeiten zuzuordnen, am naheliegendsten, ICATUS-Aktivitäten direkt mit ESCO-Fähigkeiten abzugleichen. Um dies zu erreichen, wurden Techniken der Verarbeitung natürlicher Sprache (NLP) eingesetzt. Insbesondere wurde zur Gegenüberstellung von ICATUS-Aktivitäten und ESCO-Fähigkeiten eine Technik namens Word2Vec verwendet. Word2Vec ist ein in NLP eingesetzter Algorithmus, der Wort-Embeddings nutzt, um einem gegebenen Wort numerische Werte im Verhältnis zum umgebenden Kontext dieses Wortes zuzuweisen; dieser Kontext wird durch die Beziehung bestimmt, die dieses Wort zu anderen Wörtern in einem Wörterbuch hat, das zum Trainieren des Algorithmus verwendet wird (Mikolov et al., 2013). Nach mehreren Versuchen, ESCO-Fähigkeiten direkt mit ICATUS-Aktivitäten abzugleichen, scheiterten die NLP-Techniken aufgrund der grundsätzlichen Inkompatibilität zwischen ICATUS/ESCO als Eingaben und den Eingaben, die der Algorithmus benötigt, um optimal zu funktionieren. Da ICATUS kurze Phrasen zu Aktivitäten umfasst und nicht einzelne Wörter wie die ESCO-Taxonomie bei Fähigkeiten, konnte Word2Vec diese Taxonomien nicht optimal zusammenführen, um einen sinnvollen Fähigkeitsabgleich zu erzeugen. Daraus ergab sich ein Kompromiss zwischen Präzision und Reproduzierbarkeit. Einerseits ermöglichen NLP-Methoden eine nahezu perfekte Reproduzierbarkeit, schneiden in diesem Kontext jedoch bei der Präzision schlecht ab. Bei der Konzeption des Tabiya-Frameworks wurde entschieden, die Präzision zu priorisieren. Daher erwies sich die vorherrschende Methodik, bei der ESCO-Berufe als Zuordnungsschlüssel zu Fähigkeiten verwendet werden, für unsere Zwecke als optimaler Ausgleich zwischen Präzision und Reproduzierbarkeit. Das heißt, die manuelle Zuordnung von ESCO-Berufen zu ICATUS-Aktivitäten, um Fähigkeiten abzuleiten, die mit der unsichtbaren Wirtschaft verbunden sind, erwies sich als präzise und zugleich hinreichend reproduzierbar, da diese Arbeit unabhängig überprüft wurde. Somit setzte sich für die Erstellung des Tabiya-Frameworks das manuelle Matching-Verfahren durch.
\
\
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.tabiya.org/tabiya-documentation/deutsch/unser-technologie-stack/inclusive-livelihoods-taxonomy/lessons-learned.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.