Das Foto

Suche Anfang Juli nach "street", und du bekämst ein geranktes Raster zurück — das exakt getaggte Foto zuerst, ein paar semantisch verwandte danach, jedes mit einem kleinen Badge, das erklärt, warum es passte. Das ist ein vollständiges Such-Feature. Es ist auch, wie mir beim Betrachten klar wurde, nicht wirklich das, was ich von einer Fotobibliothek wollte, die sich wie Erinnerung anfühlen soll statt wie ein Aktenschrank. Ein Ergebnisraster weiß nicht, dass zwei dieser Fotos am selben Nachmittag aufgenommen wurden, oder dass drei von ihnen einen Ort teilen, den ich einmal besucht habe.

Das Problem

Hybrid-Abruf, Vokabularerweiterung, Kanonisierung — alles bis zu diesem Punkt machte die Suche besser: präziseres Ranking, besserer Recall, korrekte Erklärungen für einzelne Treffer. Nichts davon erlaubte dem System, über die Menge der zurückgegebenen Fotos nachzudenken. Frag es "was habe ich in Berlin fotografiert", und es würde einen Haufen einzeln korrekter Ergebnisse zurückgeben, ohne jedes Gefühl dafür, dass sie verbunden waren, in welcher Reihenfolge, oder warum sie zusammen wichtig waren statt getrennt.

Eine Keyword-Suchleiste, egal wie gut darunter abgestimmt, würde nie eine so geformte Frage beantworten. Die Oberfläche selbst hatte die falsche Form für das, was die Retrieval-Pipeline bereits zu liefern imstande war.

Die Untersuchung

Die Abrufseite musste sich überhaupt nicht ändern — das war der erste echte Befund. expandPhotoQuery() und seine Ausgabe, ExpandedPhotoQuery { originalQuery, normalizedQuery, promotedTerms, remainingSemanticTerms }, waren bereits so geformt, ohne dass ich das damals so geplant hatte, dass etwas Gesprächigeres sie direkt konsumieren konnte. Die Frage war nicht "wie baue ich Query-Verständnis für einen Assistenten" — das existierte bereits. Die Frage war, was man darauf aufbaut, und wie viel Autonomie man einem Modell gibt, sobald es da ist.

Die verlockende Version von "einen Assistenten hinzufügen" hätte Claude die Suche selbst aufrufen lassen, entscheiden lassen, wonach gesucht wird, vielleicht eine zweite Anfrage laufen lassen, wenn die erste die Frage nicht zu beantworten schien. Ich habe das sofort verworfen, aus demselben Grund, warum die Evidenzauswahl für Anschreiben außerhalb von Claudes Kontrolle bleibt: Ein Assistent, der entscheiden kann, was abgerufen wird, ist ein Assistent, der still entscheiden kann, was relevant ist, und "relevant", das zu "bequem" driftet, ist genau der Fehlermodus, den diese gesamte Plattform verhindern soll. Claude bekommt keine eigene Suche.

Die Entscheidung

Das Design, das auslieferte (02.07.2026), ruft die bestehende Hybrid-Retrieval-Primitive genau einmal pro Frage auf, deckelt das Ergebnis auf 8 Fotos und baut ein festes EvidencePack, bevor Claude überhaupt aufgerufen wird. Claude erklärt das Paket; es wählt das Paket nicht aus. buildEvidencePack() ist eine reine Abbildung über bereits gerankte Ergebnisse — es bewertet nie neu, sortiert nie neu, fügt nie ein Foto hinzu, das der Abruf nicht bereits geliefert hat.

Die schwierigere Entscheidung kam einen Tag später, am 03.07.2026: ob der Assistent neben der bestehenden Keyword-Suchleiste sitzen oder sie vollständig ersetzen sollte. Ich habe mich für Ersetzen entschieden — die SearchBar/SearchResults-Komponenten der Seite wurden gelöscht, nicht als veraltet markiert, und PhotographyAssistant übernahm exakt ihre Bildschirmposition, umgestylt zur Übereinstimmung: einzeilige Eingabe, zentriert, Enter zum Absenden. Das ist eine echte Produktentscheidung, nicht nur eine technische: Ein Besucher wählt nicht mehr zwischen "suchen" und "fragen", es gibt eine Box, und die ist zufällig auf demselben deterministischen Abruf gegründet, den auch jeder andere Modus genutzt hätte. Die Galerie selbst verschwand nicht — sie ist immer noch da, als der idle-Zustand, gerendert als die eigene children-Prop des Assistenten, dieselbe Komponente, die doppelte Aufgabe übernimmt: "noch nichts gefragt" und "hier ist die ganze Sammlung".

Die Architektur

Nutzerfrage ↓ retrievePhotos() dieselbe gemeinsame Primitive, die die Suche schon nutzte — unverändert ↓ buildEvidencePack() deterministisch: Deckel 8, Rangreihenfolge erhalten, keine Bild-URLs ↓ [Paket leer?] → feste NO_RESULTS_ANSWER, kein Claude-Aufruf ↓ buildAssistantPrompt() Evidenzpaket in retrieved_context (Vertrauen: abgeleitet), Frage in untrusted_input (Vertrauen: nicht vertrauenswürdig) ↓ structuredGenerate() Claude erklärt das Paket; berechnet es nie ↓ Antwort des Assistenten

EvidencePackPhoto trägt bewusst keine Bild-URLs — es ist Claudes Kontext-Payload, keine Render-Payload. Die UI löst auf, welche Fotos tatsächlich angezeigt werden, indem sie citedPhotoIds gegen die Galerie-Fotos verbindet, die die Seite bereits geladen hat, sodass das Backend-Schema nie ein neues Feld nur zur Unterstützung des Renderns bekam.

Was ich gelernt habe

Ich hatte erwartet, dass der Bau "eines Assistenten" bedeuten würde, eine neue Intent-Verständnis-Schicht zu bauen. Tat es nicht — die größte Überraschung hier war, wie viel vom schwierigen Teil einer Gesprächsoberfläche bereits gelöst war, indem die eigene Query-Erweiterungs-Ausgabe der Suche als wiederverwendbares Intent-Modell behandelt wurde, Monate bevor ich wusste, dass ein Assistent sie konsumieren würde.

Die Produktentscheidung — die Suchleiste zu löschen statt beide zu behalten — ist die, bei der ich im Rückblick am wenigsten sicher bin. Sie funktioniert, weil der Assistent auf identischem Abruf gründet, sodass tatsächlich keine Fähigkeit verloren geht. Aber es ist eine Einbahnstraßen-Tür für jeden, der speziell schnelles, keyword-förmiges Browsen statt einer Frage-Antwort-Interaktion will, und ich habe noch keine echten Nutzungsdaten, die mir sagen, ob dieser Kompromiss richtig war.

Der Blick nach vorn

Claude ein festes Evidenzpaket zu geben, hindert es daran, sich auszudenken, welche Fotos es bespricht. Es sagt nichts darüber, was Claude behaupten darf, sobald es sie hat — und diese Lücke, zwischen "hat die richtigen Fotos zitiert" und "hat etwas Wahres über sie gesagt", brauchte am Ende eine eigene Antwort.