Der erste Fehler ist der am leichtesten zu machende und der am schwersten zu bemerkende, während man ihn macht: jedes unscharf wirkende Abgleichsproblem als Aufgabe für ein Embedding zu behandeln.

Die Vokabular-Erweiterungsschicht dieses Retrieval-Systems existiert, um ein echtes Problem zu lösen — eine Anfrage nach "biking" hat keinen lexikalischen Weg zu einem mit "bike" getaggten Foto, und diese Anfrage rundweg abzulehnen wäre schlimmer, als sie auf den nächstgelegenen kontrollierten Vokabularbegriff zu befördern, wenn beide inhaltlich nah genug beieinanderliegen. expandPhotoQuery() tut genau das: Es embedded das tatsächlich genutzte Vokabular — welche Tags, Stimmungen und Orte auch immer auf veröffentlichten Fotos existieren — und befördert ein Freitext-Token auf den nächsten Begriff, wenn die Kosinus-Ähnlichkeit einen kategoriespezifischen Schwellenwert überschreitet. Das ist ein echter, funktionierender Mechanismus. Er ist strukturell aber auch eine probabilistische Antwort auf jede Frage, die ein Anfrage-Token aufwerfen könnte — unabhängig davon, ob die Frage darunter tatsächlich probabilistisch war.

Bei zweien dieser Fragen stellte sich heraus, dass sie es nicht waren.

Die erste war Pluralbildung und Groß-/Kleinschreibung. "mountains" und "mountain" sind derselbe Tag; "café" und "cafe" sind derselbe Tag. Hier gibt es nichts zu messen — es ist eine geschlossene Transformation mit einer bekannten, deterministischen Antwort, und sie über einen Embedding-Aufruf zu leiten würde bedeuten, einen Netzwerk-Roundtrip und eine Schwellenwert-Entscheidung für etwas auszugeben, das eine Suffix-Regel jedes Mal korrekt löst. canonicalizeTerm() faltet Groß-/Kleinschreibung, Unicode-Form, Akzente und reguläre englische Plurale, bevor überhaupt ein Embedding-Pfad konsultiert wird, und ist bewusst ausschließlich auf die Kategorie tag beschränkt — Stimmungen sind adjektivisch und pluralisieren selten, und Orte sind Eigennamen, bei denen ein naives Entfernen des Suffixes "Athens" zu "Athen" verstümmeln würde. Die Regel ist absichtlich schmal: Sie beansprucht nur den Boden, der tatsächlich deterministisch ist, und überlässt den Rest — "biking" gegenüber "bike", eine echte Synonymbeziehung ohne gemeinsame Wurzel — der Embedding-Schicht, wo eine probabilistische Antwort tatsächlich gebraucht wird.

Die zweite war Ausrichtung, und sie war ein echter Produktionsfehler, bevor sie eine Architekturkorrektur war. Ausrichtungs-Anfragen — "portrait", "landscape", "vertical" — wurden durch dieselbe kategorie-schwellenwertbasierte Embedding-Beförderungsmaschinerie geleitet wie Tags, Stimmungen und Farben, gedeckelt bei 0,75, dem strengsten der fünf verwendeten Kategorie-Schwellenwerte. Die Produktionslogs fingen den Fehler direkt ein: Ein Anfrage-Token für "pictures" wurde bei einer Kosinus-Ähnlichkeit von 0,5781 auf "portrait" befördert — bequem unter dem 0,75-Gate, was bedeutete, dass es niemals hätte befördert werden dürfen, außer dass das Gate nicht die Zahl war, auf die es ankam. "pictures" und "portrait" liegen im Embedding-Raum nah beieinander, weil beides fotografie-nahe Wörter sind, nicht weil eine Person, die "pictures" eintippt, nach Ausrichtung filtern wollte. Kein Schwellenwert, wie streng auch immer, schließt diese Lücke, weil der Schwellenwert eine Ähnlichkeitsfrage beantwortet, und die eigentliche Frage — bedeutet dieses Wort eines von genau drei festen Dingen — war nie eine Ähnlichkeitsfrage. Ausrichtung ist eine geschlossene, aufzählbare Menge, direkt aus den Pixel-Dimensionen eines Fotos berechnet. Es gibt keine unscharfe "zu 70 % portrait-artige" Anfrageabsicht, die ein Ähnlichkeitswert sinnvoll ausdrücken könnte.

Die Korrektur war kein strengerer Schwellenwert. Sie bestand darin, Ausrichtung vollständig aus dem Vokabular-Erweiterungssystem zu entfernen. orientationKeywords.ts ist eine feste Schlüsselwort-Map — portrait/vertical → portrait, landscape/horizontal → landscape, square → square —, aufgelöst durch eine reine Funktion, resolveOrientationKeyword(), ohne Embedding-Aufruf, ohne KNN-Lookup, ohne Beförderungslogik. Sowohl der Query-Erweiterungspfad als auch der Filter-Extraktionspfad rufen genau diese eine Funktion auf, sodass es genau eine Stelle gibt, an der Ausrichtung erkannt wird, nicht zwei, die still auseinanderdriften könnten. Sobald das kontrollierte Vokabular überhaupt keine Ausrichtungs-Embeddings mehr konstruierte, wurde der Fehlermodus nicht nur seltener — er wurde strukturell unmöglich. Es gibt kein Embedding, das findNearest() versehentlich zurückgeben könnte, weil keines existiert.

Dieselbe Art von Korrektur tauchte später erneut auf, kleiner im Umfang, aber identisch in der Art, bei der Behandlung eines Bindestrichs. Eine Produktionsprüfung der Tag- und Stimmungs-Vokabulare ergab, dass von 120 unterschiedlichen Tags 26 einen Bindestrich enthalten — "golden-hour", "depth-of-field", "black-and-white" — und jeder einzelne ist ein zusammengesetztes Konzept, das niemals aufgespalten werden darf; "depth-of-field" in drei unabhängige Wörter aufzuspalten erzeugt Suchbegriffe ohne Bezug zum Foto. Bei Stimmungen zeigte sich das entgegengesetzte Bild: Von 21 unterschiedlichen Stimmungs-Strings nutzt genau einer, "whimsical-yet-stark", einen Bindestrich, um zwei tatsächlich unabhängige Gefühle zu verbinden, die zur Durchsuchbarkeit getrennt werden müssen. Keines von beidem ist eine Ermessensentscheidung, die ein Modell braucht. Beides sind deterministische Regeln, belegt durch eine tatsächliche Bestandsaufnahme der Daten statt im Voraus angenommen — eine gemeinsame Low-Level-Primitive faltet Bindestrich-Varianten auf einen einfachen ASCII-Bindestrich, und zwei getrennte, eng begrenzte Regeln sitzen darauf: eine, die einen Bindestrich als Verbindungspunkt für Tags behandelt, eine, die ihn als Trennpunkt für Stimmungen behandelt. Keine der beiden Regeln berührt ein Embedding.

Was Kanonisierung, Ausrichtung und Bindestrich-Behandlung verbindet, ist nicht, dass es alles kleine Korrekturen sind. Es ist, dass jede einzelne Beleg für denselben vorherigen Fehler ist: "das sieht nach unscharfem Abgleich aus" mit "das braucht ein Embedding" gleichzusetzen, wenn der eigentliche Test enger gefasst ist — hat der Raum möglicher Antworten eine geschlossene, berechenbare Struktur, oder nicht? Ein Plural hat eine kanonische Form. Eine Ausrichtung hat drei mögliche Werte, abgeleitet aus bereits vorhandenen Pixel-Dimensionen. Ob ein Bindestrich-Tag ein Konzept oder zwei ist, ist eine Tatsache über die Daten, herausfindbar durch einen Blick auf die Daten, keine Wahrscheinlichkeitsverteilung über zusammengesetzte Wortphrasen. Nichts davon musste geschätzt werden. Es musste nachgeschlagen, berechnet oder gezählt werden.

Die übertragbare Version dieser Lektion hat nichts mit Fotografien zu tun: Bevor man zu einem Embedding, einem Klassifikator oder einem anderen probabilistischen Mechanismus greift, sollte man fragen, ob die Frage tatsächlich eine geschlossene Antwort hat, die eine deterministische Regel bereits korrekt berechnet. Wenn ja, macht das Ausgeben eines Ähnlichkeits-Schwellenwerts darauf das System nicht raffinierter — es fügt einen Fehlermodus hinzu, der nicht existieren musste, gedeckelt durch eine Zahl, die nie das Richtige gemessen hat.

Nicht jede Frage in diesem System hat diese Form, allerdings. Farbe und Stimmung sind wirklich offen — die vollständige Menge der Töne, die eine Person "blau" nennen würde, oder der Gefühle, die eine Person "serene" nennen würde, ändert sich, während neue Fotos hinzukommen, und es gibt keine feste Aufzählung zum Nachschlagen, wie es sie für Ausrichtung gibt. Das probabilistische Gate lässt sich dort nicht entfernen, weil es eine Frage beantwortet, die tatsächlich probabilistisch ist. Die nächste Frage ist also nicht, ob ein Embedding-basierter Abgleich in der Pipeline bleiben soll. Es ist, was wahr sein muss über das, was dieser Abgleich vergleicht, bevor irgendein darauf gesetzter Schwellenwert überhaupt etwas bedeuten kann.