Der Anfang

Strukturierte Daten beantworten "was ist wahr". Sie beantworten nicht "wie viel davon soll ein Modell sehen, und in welcher Reihenfolge" — und sobald jede Domäne echte Struktur hatte, aus der sie schöpfen konnte, wurde das zur einzig verbliebenen Frage, an zwei Fronten, die nichts miteinander zu tun hatten: wie Fotos gegen eine Suchanfrage gerankt werden, und wie eine Phrase aus einer Stellenbeschreibung meinem eigenen Vokabular zugeordnet wird.

Die erste Lösung

Für die Fotosuche behandelte die früheste Version der Ranking-Pipeline — intern "Hybrid Retrieval v1" genannt — semantische Ähnlichkeit als primäres Signal, wobei lexikalische Tag-Treffer nur kleine additive Boosts obendrauf beisteuerten, +0,03 bis +0,05. Das fühlte sich vernünftig an: Semantische Ähnlichkeit soll der raffinierte Teil sein, der Teil, der Bedeutung versteht statt nur Zeichenketten abzugleichen, also sah es so aus, als würde man dem fähigeren Signal vertrauen, es als primär zu gewichten.

Für den Capability-Abgleich war die Überlegung ähnlich naheliegend: Mein von Hand gepflegtes Schlüsselwort-Wörterbuch hatte rund 150 Einträge und war offensichtlich unvollständig, also ergab ein Embedding-basierter Recovery-Schritt Sinn — wenn eine Formulierung aus einer Stellenbeschreibung nah genug an etwas ist, das bereits in meinem eigenen Vokabular steht, wird sie befördert. Ich nahm an, ein einzelner Ähnlichkeits-Schwellenwert würde gute von schlechten Beförderungen sauber genug trennen, um ihn einmal zu justieren und dann in Ruhe zu lassen.

Was kaputtging

Unter Hybrid Retrieval v1 konnte ein Foto, das mit "street" getaggt war und einen Ähnlichkeitswert von 0,3 hatte, gegen ein völlig unverwandtes Foto verlieren, das allein auf semantischer Ähnlichkeit 0,85 erzielte. Explizite Nutzerabsicht — der exakte Tag, nach dem jemand gesucht hatte — wurde vom "klügeren" Signal überholt, genau weil dieses Signal mehr numerischen Spielraum hatte, um die Summe zu dominieren. Mehr Gewicht auf die raffiniert aussehende Zahl produzierte schlechtere Rankings, nicht bessere.

Der Capability-Schwellenwert ging auf eine Weise kaputt, die schwerer vorherzusehen war. Ich kalibrierte ihn gegen fünf echte Stellenbeschreibungen — 2.015 Kandidaten-Formulierungen, 1.711 einzigartige — und erwartete, dass sich die Ähnlichkeitswerte bestätigt guter und bestätigt schlechter Beförderungen sichtbar in zwei getrennte Bereiche clustern würden. Taten sie nicht. Der niedrigste Wert unter den Beförderungen, die ich als korrekt bestätigen würde, und der höchste Wert unter den Formulierungen, die nie hätten befördert werden sollen, lagen bei genau demselben Wert: 0,550. Es gab keine Lücke, in die man eine Linie hätte ziehen können. Die manuelle Durchsicht dieses überlappenden Bereichs förderte echte, konkrete Falsch-Positive zutage: "velocity" befördert zu "vector" bei 0,570, "documentation" zu "database" bei 0,587, und — das, was mir etwas Strukturelles zeigte, nicht nur Rauschen — das englische Verb "architect", absorbiert in das deutsche Substantiv "Architektur" bei 0,567, weil das Vokabular bewusst deutsche Begriffe enthält, damit deutschsprachige Stellenbeschreibungen denselben Expansionsvorteil bekommen wie englische — was bedeutete, dass sich englische und deutsche Formulierungen den Embedding-Raum auf eine Weise teilten, die ein einsprachiges gedankliches Modell von "Ähnlichkeit" nicht berücksichtigt hatte.

Beide Fehler hatten unter der unterschiedlichen Mathematik dieselbe Form: Ein größeres oder stärker gewichtetes Signal war nicht informativer, es war mehr Raum für das Falsche, um selbstbewusst zu wirken. Dass semantische Ähnlichkeit die Summe dominierte, machte das Foto-Ranking nicht klüger, es ließ irrelevante Ergebnisse mit mehr scheinbarer Sicherheit höher punkten. Ein Beförderungs-Schwellenwert, behandelt als einzelner sauberer Schnitt, machte den Capability-Abgleich nicht großzügiger, er ließ "vector" und "velocity" im selben Bereich sitzen wie echte, korrekte Wiederherstellungen, ohne dass man sie allein am Score unterscheiden konnte.

Die Entscheidung

Für das Ranking habe ich verworfen, semantische Ähnlichkeit als primär zu gewichten, und auch einen simplen gewichteten Durchschnitt aus lexikalischem und semantischem Score verworfen — ein gewichteter Durchschnitt kann unter der richtigen Konfiguration immer noch zulassen, dass ein starker semantischer Treffer einen schwachen, aber exakten lexikalischen Treffer überholt, was bedeutet, dass er den v1-Fehler nur meistens vermeidet, statt ihn strukturell zu verhindern. Was ich stattdessen gebaut habe, macht die Garantie strukturell: finalScore = lexicalScore + min(semanticScore × 2, 2). Ein einzelner exakter Tag-Treffer ist +5 wert, überholt also immer den maximal möglichen semantischen Beitrag von +2 — nicht weil ich die Zahlen so justiert habe, dass das meistens stimmt, sondern weil der Deckel es per Konstruktion wahr macht, in jeder Konfiguration, dauerhaft.

Für den Capability-Abgleich erledigte ein einzelner Schwellenwert klar nicht zwei Jobs gut, also teilte ich ihn in zwei. expandCapabilityVocabulary() befördert weiterhin bei einem lockeren 0,55, absichtlich — das hält den vollen diagnostischen Bereich sichtbar, damit künftige Neukalibrierung echte Daten zum Anschauen hat, statt bereits verworfener Evidenz. Aber nur Beförderungen mit einem Score von 0,65 oder höher werden überhaupt von buildExpandedCapabilitySignal() für den tatsächlichen Abruf vertraut. Alles zwischen 0,55 und 0,65 wird berechnet, geprüft und dann verworfen, bevor es die Evidenzbewertung erreicht — genau der Bereich, in dem "velocity → vector" und "architect → Architektur" lebten.

Das Evidenzpaket selbst trägt eine dritte Version derselben Disziplin, in einer anderen Form. Es ist auf acht Einträge gedeckelt, und ein Profil-Abstimmungsbonus, der Tie-Breaking in Richtung Themen lenkt, die zu meiner eigenen Positionierung passen, ist selbst auf 0,3 gedeckelt — klein genug, dass er immer nur ein Beinahe-Unentschieden entscheiden kann, nie den primären Relevanz-Score außer Kraft setzen. Unentschieden werden überhaupt nur innerhalb eines 0,02-Delta-Fensters in Betracht gezogen; außerhalb dieses Fensters ist das Ranking maßgeblich, Punkt. Drei verschiedene Teilsysteme, drei verschiedene Formeln, und alle drei landen beim selben Prinzip: Ein sekundäres Signal darf eine Entscheidung am Rand anstoßen, und darf niemals selbst zur Entscheidung werden.

Die neue Architektur

Nicht das: Rohsignal → stark gewichten, weil es klug wirkt → der Summe vertrauen Sondern das: Rohsignal → normalisieren → strukturell deckeln oder einen Schwellenwert setzen → nur innerhalb eines engen Tie-Break-Fensters anwenden → Ranking außerhalb dieses Fensters bleibt maßgeblich

Konkret: min(semanticScore × 2, 2) deckelt ein Signal, statt es zu gewichten. Zwei Schwellenwerte (0,55/0,65) trennen "wert zu messen" von "wert zu vertrauen". Ein auf 0,3 gedeckelter Bonus innerhalb eines 0,02-Tie-Break-Fensters stößt an, ohne je zu übersteuern.

Was ich gelernt habe

Keiner der beiden Fehler sah aus wie ein Absturz. Hybrid Retrieval v1 gab keinen Fehler zurück — es lieferte Fotos, selbstbewusst, die zufällig einfach die falschen waren. Der Ein-Schwellenwert-Capability-Abgleich hat schlechte Beförderungen nicht abgelehnt — er akzeptierte sie mit derselben numerischen Sicherheit wie gute. Das ist dieselbe Fehlerform, die ich bereits auf der Generierungsebene gesehen hatte, beim Anschreiben, das Evidenzlücken mit etwas Plausiblem füllt, statt einfach zu schweigen — nur passierte es hier eine Ebene früher, im Retrieval, bevor die Generierung überhaupt ins Spiel kam. Es hat mir gezeigt, dass die Disziplin "ein sekundäres Signal darf nicht entscheiden" zweimal durchgesetzt werden muss: einmal darüber, was ein Modell sagen darf, und separat, früher, darüber, was einem Modell überhaupt gezeigt wird.

Ich war vor der Kalibrierung auch davon ausgegangen, dass sich Ähnlichkeitswerte so clustern würden, wie ich mir vorstellte, dass Sprache "sich verhalten sollte" — saubere semantische Nachbarschaften mit sichtbaren Lücken dazwischen. Bei einem Umfang von 1.711 echten Formulierungen über zwei Sprachen hinweg tun sie das nicht. Ich habe das nur herausgefunden, weil ich gegen echte Daten kalibriert habe, statt einen Schwellenwert zu wählen, der sich vernünftig anfühlte, und weiterzumachen.

Der Blick nach vorn

Sobald Ranking tatsächlich ein mehrstufiger Trichter ist — normalisieren, deckeln, einen Schwellenwert setzen, innerhalb eines engen Fensters Unentschieden brechen, und erst dann als final bezeichnen —, hört es auf, wie "eine Formel" auszusehen, und beginnt, wie eine Pipeline mit benannten Stufen auszusehen, von denen jede eine Stelle ist, an der eine Regel durchgesetzt werden kann. Das ist kein Zufall. Es ist die Form, die Retrieval immer annimmt, sobald man aufhört, einer einzelnen Zahl zu vertrauen, den ganzen Job zu erledigen, und es ist die Form, die der nächste Artikel explizit macht.

Fazit

Jedes Mal, wenn ich nach "gib dem Modell mehr" griff — mehr Gewicht auf das klug aussehende Signal, mehr Vertrauen in eine einzelne Zahl, mehr Evidenz nur für den Fall der Fälle —, wurde das Ergebnis schlechter, nicht besser, und jede Korrektur war irgendeine Version derselben Bewegung: ein Signal nehmen, das dominieren will, und ihm eine harte Obergrenze setzen, wie viel von der Entscheidung es strukturell treffen darf.