Ja – und ich würde unser Vorhaben an genau dieser Stelle bewusst hinterfragen.

Meine Antwort wäre: **Für Reconcilix sollten wir die Referenzvokabulare nicht durch ein LLM ersetzen. Aber wir sollten experimentell prüfen, wie weit ein modernes LLM ohne sie kommt.** Das sind zwei verschiedene Fragen.

Ein aktuelles LLM kann bei Begriffen wie `Unterteller`, `Tonfigur`, `Restholz` oder `Steckschlüssel` sehr wahrscheinlich hervorragende semantische Zuordnungen erzeugen. Es kann Komposita zerlegen, Synonyme erkennen, Kontext berücksichtigen und Schreibvarianten normalisieren – vieles davon, wofür wir gerade mehrere Discovery Methods untersuchen.

Das Problem beginnt aber bei der Frage: **Worauf wurde eigentlich reconciled?**

Wenn ich ohne Referenzvokabulare aus

```text
SourceValue:
Restholz
```

beispielsweise

```text
Holzabfall
```

mache, habe ich eine plausible semantische Normalisierung erzeugt. Ich habe aber noch keinen kontrollierten Vocabulary Concept identifiziert.

Für Reconcilix ist der Unterschied fundamental:

```text
LLM:
Restholz
→ "Holzabfall"

Vocabulary-backed:
Restholz
→ GND Concept
→ URI: ...
→ prefLabel: Holzabfall
→ Definition / Broader / Relations / Provenance ...
```

Im zweiten Fall haben wir einen **identifizierbaren, nachprüfbaren und interoperablen Knowledge Organization System Concept**. Im ersten Fall haben wir zunächst eine Behauptung des Modells.

### Aber daraus folgt für mich ein besseres Experiment als unser bisher geplantes

Wir sollten **nicht nur LLM-01 auf die Referenzergebnisse setzen**. Denn dann geben wir dem LLM bereits unseren Lösungsraum vor und erfahren nicht, ob wir einen großen Teil unserer Discovery-Infrastruktur vielleicht tatsächlich nicht mehr brauchen.

Ich würde drei Versuchsarme daraus machen:

```text
A – Classical / Reference

SourceValue
 ↓
WNK + OBG + GND
 ↓
Candidate Sets


B – LLM Closed

SourceValue
+ Context
+ Candidates aus A
+ Definitions
 ↓
LLM
 ↓
Candidate Decision


C – LLM Blind

SourceValue
+ Context
 ↓
LLM
 ↓
"Was ist damit wahrscheinlich gemeint?"
```

Und **C darf die Ergebnisse aus A ausdrücklich nicht kennen**.

Erst *nach* der LLM-Antwort vergleichen wir:

```text
LLM Blind Result
        ↕
WNK / OBG / GND Results
```

Das halte ich wissenschaftlich für viel interessanter.

### Dabei könnte uns das LLM an einer Stelle ziemlich überraschen

Nehmen wir unsere Failure Classes:

```text
Regalbrett
Unterteller
Sägeblatt
Steckschlüssel
Heugabel
Eisenring
Schleifpapier
Tonfigur
Tellerbrett
Diaprojektor
```

Für ein starkes LLM sind German Compound Decomposition, Morphology und Synonymy keine exotischen Spezialprobleme. Es hat gute Chancen, diese sprachlichen Beziehungen direkt zu erfassen.

Dann könnte sich tatsächlich herausstellen:

> Wir investieren zu viel in immer raffiniertere lexical Discovery Profiles für Probleme, die ein LLM bereits wesentlich robuster löst.

Das wäre eine **wichtige Erkenntnis für die Reconcilix-Roadmap**, auch wenn sie Teile unserer bisherigen Überlegungen infrage stellt.

Aber ich erwarte gleichzeitig einen anderen Befund. Bei fachlich engen Begriffen, Homonymen und Vokabularbesonderheiten dürfte das LLM ohne kontrollierten Knowledge Context zunehmend unsicher werden.

Unser `Bogen`-Beispiel ist dafür hervorragend:

```text
Bogen
Bogen + Bauwerk
Bogen + Architektur
```

Ein LLM kann semantisch hervorragend argumentieren. Aber die Frage

> „Welcher konkrete Concept existiert in WNK, OBG oder GND und welche URI muss ins Ausgangssystem zurückgeschrieben werden?“

kann es **ohne Zugriff auf diese Wissensbasis prinzipiell nicht zuverlässig aus seinem Sprachmodell beantworten**. Selbst wenn es manche GND Concepts aus Trainingsdaten kennt, wäre das kein belastbarer Retrieval-Mechanismus.

### Deshalb würde ich die Referenzmenge behalten – aber ihre Rolle ändern

Nicht:

> Referenzvokabulare erzeugen Candidates, damit das LLM überhaupt arbeiten kann.

Sondern:

> Referenzvokabulare bilden unsere kontrollierte Vergleichs- und Grounding-Ebene, gegen die wir alternative Verfahren evaluieren.

Das ist ein erheblicher konzeptioneller Unterschied.

Und daraus entsteht für mich sogar ein vierter, wahrscheinlich langfristig besonders interessanter Arm:

```text
D – LLM + Vocabulary Tools

SourceValue + Context
        ↓
       LLM
        ↓
entscheidet selbst:
"Ich brauche OBG"
"Ich suche GND"
"Ich brauche WNK"
        ↓
Vocabulary/API Retrieval
        ↓
LLM evaluates returned Concepts
        ↓
grounded Match Decision
```

Das wäre weder unser heutiges klassische Discovery Profile noch „ChatGPT weiß alles“.

Es wäre **agentic, vocabulary-grounded Reconciliation**.

Und genau dort könnte ich mir für Reconcilix langfristig sehr viel vorstellen: Das LLM übernimmt Interpretation und Search Strategy; Reconcilix stellt ihm kontrollierte Candidate Sources, Tools, Evidence, Provenance und Persistence zur Verfügung.

Für unseren Versuch mit den 200 Records würde ich deshalb **A, B und C unbedingt parallel fahren**. Das kostet uns vergleichsweise wenig, beantwortet aber eine ziemlich große Architekturfrage:

> **Brauchen wir LLMs hauptsächlich zur Bewertung unserer Discovery Candidates – oder können sie bereits wesentliche Teile von Interpretation und Candidate Discovery übernehmen?**

Das ist meines Erachtens deutlich wertvoller als nur zu zeigen, dass ChatGPT aus drei vorgegebenen Candidates den besten auswählen kann.
