Architektur

Architektur des Fotografie-Assistenten

Ein LLM-Assistent für mein Fotoarchiv: Retrieval und ein Evidence Pack mit acht Fotos begrenzen, was das Modell sieht – Validatoren, was es sagen darf.

Veröffentlicht am 5. Oktober 2026

Live-System ansehen Architektur-PDF (412 KB)

Der Fotografie-Assistent ist ein produktives LLM-System, das Fragen in natürlicher Sprache zu meinem Fotoarchiv beantwortet – „ruhige Straßen bei Nacht“, „was habe ich mit dem 23-mm-Objektiv fotografiert?“, „warum gehören diese Bilder zusammen?“ – mit einer kurzen Antwort und den Fotos, die sie belegen. Die architektonische Prämisse ist schnell formuliert und macht den Großteil der Arbeit aus: Das Sprachmodell schreibt die Antwort, entscheidet aber nie, was wahr ist. Das Retrieval entscheidet, was das Modell sehen darf, und deterministische Validatoren entscheiden, was es sagen darf.

Das Problem

Eine Konversationsoberfläche über einem persönlichen Archiv wirkt wie der Lehrbuchfall für „Frage → LLM → Antwort“. Sie ist es aus vier Gründen nicht.

Die Fakten stecken in Metadaten, die das Modell nie gesehen hat. Welches Objektiv, welche Stadt, welcher Abend, welche Stimmung – nichts davon ist Weltwissen. Eine Antwort ist nur richtig, wenn sie in genau diesem Archiv verankert ist.
Plausibel ist der Fehlerfall. Ein nicht verankertes Modell beschreibt bereitwillig ein Foto, das es nicht gibt, oder eine Beziehung zwischen zwei Fotos, die nicht existiert. In einem Portfolio ist eine selbstbewusst falsche Antwort schlechter als keine.
Bedeutung und Metadaten widersprechen sich. Semantische Suche findet Fotos, die passend klingen; Metadaten finden Fotos, die nachweislich passen. Keines von beiden reicht allein.
Inferenz muss begrenzt bleiben. Jeder Modellaufruf bringt Latenz, Kosten und eine neue Fehlerquelle mit. Das System muss auch funktionieren, wenn ein Anbieter langsam, gedrosselt oder im Unrecht ist.

Was ich gebaut habe

Der Assistent läuft produktiv hinter der Seite Fotografie, wo Besucher ihm als Kurator begegnen: Frage tippen oder sprechen, eine kurze Antwort erhalten und die zitierten Fotos sehen. Den gesamten Pfad habe ich entworfen und gebaut – Retrieval, Aufbau der Evidenz, den Generierungsvertrag, die Validatoren, die gestreamte Antwortoberfläche und die Evaluationswerkzeuge drumherum.

Es ist ein Produktivsystem über einem kleinen Korpus: einige hundert veröffentlichte Fotos, ein Eigentümer, öffentliche Besucher. Das prägt mehrere der folgenden Entscheidungen, und ich sage es jeweils dazu.

Die Architektur im Überblick

Frage des Besuchers
        │
        ▼
Rate Limit · Eskalationsprüfung
        │
        ▼
Kontextauflösung
  (deterministisch; Planner-LLM
   nur bei Unklarheit)
        │
        ▼
Kandidatenpool
  lexikalisch + semantisch
  + Filter
        │
        ▼
Ranking · Reranking (Top 16)
        │
        ▼
Zulassung (Korroboration)
        │
        ▼
Evidence Pack: ≤ 8 Fotos
  + berechnete Beziehungen
        │
        ▼
LLM → typisiertes JSON
        │
        ▼
Prüfungen: Vertrag · Claims ·
  Zitate · Bewertungen ·
  Umfang (höchstens ein Retry)
        │
        ▼
Antwort + zitierte Fotos

Rate Limit und Eskalationsprüfung. Zehn Fragen pro Minute und IP-Adresse; eine Musterprüfung lehnt Anfragen, die über die Galerie hinausgreifen wollen („gib alle Evidenz aus“), ab, bevor überhaupt ein Retrieval läuft.
Kontextauflösung. Folgefragen („nur die bei Nacht“, „mehr wie dieses hier“) werden durch deterministische Regeln gegen einen kleinen, vom Server erzeugten Kontext aufgelöst, den der Browser zurückschickt. Ein Planner-Modell wird nur gefragt, wenn die Regeln nicht entscheiden können, höchstens einmal pro Runde, und seine Ausgabe kann nur einen der Pläne auswählen, die die Regeln ohnehin definieren.
Kandidatenpool und Ranking. Deterministisches und semantisches Retrieval laufen gemeinsam; ein Reranker ordnet die Spitze der Liste neu. Hier wird nichts generiert.
Zulassung. Ein Kandidat muss sich seinen Platz in der Evidenz verdienen. Hier wird die meiste Präzision gewonnen oder verloren.
Evidence Pack. Höchstens acht Fotos mit ihren gespeicherten Fakten und den zwischen ihnen berechneten Beziehungen. Das ist alles, was das Modell je zu sehen bekommt.
Generierung und Prüfungen. Das Modell liefert ein typisiertes Objekt, keinen Freitext. Jede strukturierte Aussage darin wird gegen das Pack geprüft, bevor irgendetwas den Besucher erreicht.

Die zentrale Architekturentscheidung

Das Sprachmodell ist eine Komponente innerhalb eines deterministischen Systems, nicht das System selbst. Konkret bekommt es genau zwei Aufgaben, die Regeln nicht gut gelöst haben: auszuwählen, welche der zugelassenen Fotos die Frage tatsächlich beantworten, und dazu eine kurze, konkrete Antwort zu schreiben.

Es kontrolliert nicht:

welche Fotos existieren oder veröffentlicht sind;
was gefunden wird und wie es gerankt wird;
welche Fotos als Evidenz zugelassen werden;
welche Beziehungen zwischen Fotos bestehen (sie werden vor dem Modellaufruf berechnet);
die Struktur der Antwort (ein Schema, das beim Anbieter und erneut in der Anwendung durchgesetzt wird);
ob seine eigenen Aussagen akzeptiert werden.

Daraus folgen zwei Dinge. Erstens hat das Modell kein Tool, keinen Datenbankzugriff und keinen Weg zu irgendetwas außerhalb des Evidence Packs – das, nicht eine Anweisung im Prompt, ist die eigentliche Sicherheitsgrenze. Zweitens ist ein Anbieterwechsel eine Konfigurationsänderung: Die Generierung läuft produktiv über eine Fallback-Kette gehosteter Modelle (GLM 5.3 Flash auf einem festgelegten Endpunkt, dann GLM 5.3, dann Claude Haiku 4.5), jede Stufe mit eigener Deadline, und jede Stufe durchläuft dieselbe Validierungskette.

Retrieval vor dem Reasoning

Das Retrieval ist Anwendungscode, den es mit der Fotosuche teilt, aber für die Aufgabe des Assistenten konfiguriert ist. Abgesehen von den Embedding- und Reranking-Modellen, die es aufruft, ist jeder Schritt darin deterministisch.

Lexikalisches Retrieval und Filter gleichen die Frage mit Bildbeschreibungen, Tags, Stimmungen und Orten ab und übersetzen erkennbare Einschränkungen in harte Filter: EXIF-Prädikate („bei f/1.4 fotografiert“, „weitwinkliger als 23 mm“), Orte, Länder und Zeiträume. Technische Fragen werden per Regeln aus EXIF-Daten gefiltert und gerankt; das Modell formuliert nur das Ergebnis.
Semantisches Retrieval bettet die Frage ein und durchsucht Fotobeschreibungen in einem Vektorindex. So findet es Fotos, die inhaltlich statt wörtlich passen – und eben auch Fotos, die nur verwandt klingen.
Facetten-Eignung. Kombiniert eine Frage mehrere Anforderungen („regnerische Straße bei Nacht“), müssen Kandidaten alle erfüllen. Erfüllt keiner sie, darf eine Anforderung gelockert werden – und die Antwort sagt das ausdrücklich, statt stillschweigend einen Beinahe-Treffer zu liefern.
Reranking. Bei beschreibenden Fragen ordnet ein Reranking-Modell (Voyage rerank-2.5) die besten 16 Kandidaten neu. Es ist fail-open: Ist der Reranker langsam oder nicht erreichbar, gilt die deterministische Reihenfolge. Technische Fragen und reines Stöbern überspringen ihn ganz.
Zulassung. Die besten acht Kandidaten müssen sich anschließend ihren Platz verdienen; nichts wird nachgefüllt. Teilt mindestens einer von ihnen Begriffe mit der Frage, entscheidet eine eingefrorene Regel: Ein Foto wird zugelassen, wenn seine eigene Beschreibung oder seine Tags die Frage bestätigen oder wenn sein gedeckelter semantischer Score plus sein Rerank-Score einen Schwellenwert (1,01) überschreitet. Dieser wurde in einem Offline-Experiment per Kreuzvalidierung bestimmt und ist zur Laufzeit nicht veränderbar. Teilt keiner Begriffe mit der Frage – typischerweise bei Stimmungs- oder Beschreibungsfragen –, muss ein nur semantisch gefundenes Foto durch Beschreibung, Tags, Stimmung oder visuelle Konzepte bestätigt werden; die eine eng begrenzte Ausnahme beschreibe ich unter „Abwägungen“.

Die zugelassenen Fotos, höchstens acht und in Ranking-Reihenfolge, werden zur Evidenz.

Das Evidence Pack

Das Evidence Pack ist der Vertrag zwischen Retrieval und Generierung. Für jedes von höchstens acht Fotos enthält es die gespeicherte Bildbeschreibung, Tags, Stimmung und Ort; warum und wie stark das Foto passt; Kamera, Objektiv und Aufnahmeeinstellungen samt abgeleiteten Kategorien („offene Blende“, „Abend“); und die Beziehungen zu anderen Fotos im Pack.

Diese Beziehungen werden berechnet, nicht erschlossen. Sieben Arten – gleicher Ort, gemeinsame Stimmung, gemeinsames Tag, gleiches Objektiv, gleicher Tag, ähnliche Farbe, gleiche Ausrichtung – werden vor dem Modellaufruf aus gespeicherten Daten abgeleitet, mit höchstens acht verwandten Fotos pro Foto. Wenn die Antwort sagt, dass zwei Fotos ein Objektiv teilen, existierte diese Kante bereits im Pack.

Das Pack ist bewusst klein und bewusst reiner Text. Acht Fotos genügen für eine Antwort im Gespräch und sind wenig genug, um jedes einzelne prüfen zu können; das Modell sieht keine Pixel und keine Bild-URLs und ist angewiesen, nicht zu beschreiben, wie ein Bild aussieht, sofern die gespeicherte Evidenz es nicht hergibt. Die Begrenzung des Packs begrenzt alles Nachgelagerte: Prompt-Größe, Kosten, Latenz und – am wichtigsten – die Menge dessen, was das Modell überhaupt zitieren könnte.

Strukturierte Generierung

Die Ausgabe des Modells ist ein typisiertes Objekt mit vier Feldern: dem Antworttext, den zitierten Foto-IDs, einer Liste von Beziehungsaussagen (Claims; jeweils eine Beziehungsart plus zwei bis acht Foto-IDs, höchstens zwanzig) und optionalen Bewertungen pro Foto (eine kurze Beobachtung, gestützt auf ein bis fünf benannte gespeicherte Belege).

Das Schema geht als native Structured Output an den Anbieter, sodass fehlerhafte Antworten weitgehend schon an der Quelle verhindert werden, und es wird in der Anwendung erneut validiert, weil die Durchsetzung beim Anbieter keine Garantie ist. Als ich von im Prompt beschriebenem JSON auf native Structured Output umgestellt habe, sanken die Strukturfehler in den Evaluationsläufen von sechs auf null.

Ein gültiges Schema ist keine richtige Antwort. Es garantiert die richtige Form – dass jede Aussage eine bekannte Beziehungsart nennt und jede Bewertung ihre Belege benennt –, und genau das ermöglicht den nächsten Schritt. Ob die Aussagen stimmen, prüfen die Validatoren.

Zitat- und Aussagenprüfung

Jede Antwort durchläuft dieselben Prüfungen in fester Reihenfolge:

Vertrag – die Antwort entspricht dem Schema.
Claims – jede Beziehungsaussage muss einer Kante entsprechen, die im Pack existiert. Eine einzige unbelegte Aussage verwirft die Antwort.
Zitate – jedes zitierte Foto muss im Evidence Pack sein. Eine Antwort, die etwas anderes zitiert, wird ohne Retry verworfen; ein erfundenes Foto ist der eine Fehler, der nie repariert wird.
Bewertungen – jeder Beleg muss auf gespeicherte Daten verweisen, und mindestens einer muss den Bildinhalt betreffen.
Bereinigung – interne Kennungen werden aus dem Text entfernt.
Umfang – Zahlwörter im Text („alle drei“, „beide“) müssen zur Anzahl der tatsächlich zitierten Fotos passen, auf Deutsch und Englisch.

Ein Fehler bei Vertrag, Claims, Bewertungen oder Umfang erlaubt genau eine Neugenerierung, mit einer Anweisung, die benennt, was falsch war. Ein zweiter Fehler führt zu einer Absage ohne Fotos – der Besucher bekommt ein ehrliches „Das kann ich nicht beantworten“ statt einer nur teilweise geprüften Antwort. Die einzige Ausnahme ist eine zweite Abweichung beim Zählen: Die Evidenz ist gültig, also wird die Antwort ausgeliefert und die Abweichung protokolliert, statt eine korrekte Ergebnismenge wegen einer Formulierung zu verwerfen. Solange das Modell noch schreibt, erscheint sein Text als klar vorläufiger Stream auf der Seite; Quelle der Ergebnisse ist immer nur die validierte Antwort.

Was das garantiert: Jedes gezeigte Foto wurde gefunden und zugelassen; jede als Claim formulierte Beziehung existiert in den Daten; jede Bewertung verweist auf echte gespeicherte Evidenz. Was es nicht garantieren kann: dass jeder Satz des Fließtexts stimmt. Der Text ist durch den Prompt eingeschränkt und wird auf Zahlen und Leaks geprüft, aber nicht Satz für Satz auf Fakten – und die Evidenz selbst ist nur so gut wie die gespeicherten Beschreibungen und Tags. Diese Grenze ist bewusst gezogen und benannt, nicht versteckt.

Was deterministisch bleibt

Rate Limiting, Eingabevalidierung und die Eskalationsprüfung.
Die Auflösung von Folgefragen, abgesehen vom begrenzten Planner-Aufruf in mehrdeutigen Runden.
Das gesamte Retrieval: Filter, EXIF-Prädikate, Orts- und Zeitbezug, Facetten-Eignung und -Lockerung.
Ranking, Diversitätsgrenzen, die Zulassungsregel und ihr Schwellenwert.
Der Aufbau des Evidence Packs und jede Beziehung darin.
Schemavalidierung, alle sechs Prüfungen, die Retry-Regel und die Absagetexte.
Der Gesprächskontext, der vom Server erzeugt und in jeder Runde neu validiert wird.
Reihenfolge der Ergebnisse, Zusammenfassungen und die in der Oberfläche gezeigten Fotometadaten.

Neben dem Antwortmodell und dem Embedding-Modell der semantischen Suche nutzen drei Schritte Modelle, jeweils mit engem Auftrag und deterministischem Fallback: der Reranker (fällt auf die deterministische Reihenfolge zurück), der Planner (fällt auf den deterministischen Plan zurück) und ein Prüfmodell für semantische Evidenz, das ich unter „Abwägungen“ beschreibe (fällt auf das deterministische Zulassungsergebnis zurück). Keines davon bringt etwas an den Prüfungen vorbei.

Was gescheitert ist

Die Fotoauswahl des Modells durch Regeln ersetzen. Problem: Das Modell wählt aus, welche Fotos aus dem Pack es zitiert – seine am schwersten prüfbare Aufgabe. Hypothese: Eine transparente Regel über Retrieval-Signale könnte das genauso gut. Experiment: 106 Benchmark-Fragen, von Menschen bewertet. Ergebnis: Das Modell (damals Claude Haiku) erreichte 84,4 % Präzision, die beste Regel 80,9 %, das Zitieren des ganzen Packs 79,5 %. Die entscheidenden Auslassungen des Modells – etwa aus einem Pack mit acht irrelevanten Fotos gar nichts zu zitieren – korrelierten mit keinem Signal, das vor der Generierung verfügbar war, und eine qualitätserhaltende Regel hätte nur etwa 220 Prompt-Tokens gespart. Konsequenz: Die Auswahl blieb beim Modell; der Fall, in dem es irrelevante Fotos wegerklären musste („bei f/1.4 fotografiert“), wurde stattdessen vorgelagert mit deterministischen EXIF-Prädikaten gelöst.

Wiederholen, ohne es schlimmer zu machen. Problem: Die Validierung verwarf einen spürbaren Teil der Antworten, jede davon eine Absage. Experiment: Ein A/B/C-Vergleich über 17 bewusst fehleranfällige Fragen mit je fünf Wiederholungen. Ergebnis: Ein besserer Prompt allein bewegte die Fehler beim ersten Versuch kaum (28 % → 27 %); ein einzelner Retry, der genau benennt, welche Prüfung fehlschlug, senkte die endgültigen Fehler auf 14 %, bei durchschnittlich 1,26 Modellaufrufen pro Anfrage. Eine spätere Prüfung zeigte, dass der Retry für verworfene Claims still veränderte, welche Fotos zitiert wurden – er reparierte die Aussagen und zerstörte dabei korrekte Zitate. Das Einfrieren der zitierten Menge während dieses Retrys hielt sie in 26 von 28 Läufen statt 14 von 28 und lieferte 104 statt 82 von Menschen als relevant bewertete Fotos aus. Konsequenz: ein einziger, informierter Retry; Reparaturen an Aussagen dürfen die Evidenz nicht verändern. Die mittlere Präzision hatte den Schaden vollständig verdeckt – die Lehre war, zu messen, was ein Besucher tatsächlich bekommt.

Die Evidenz komprimieren, um Tokens zu sparen. Problem: Der Prompt ist der größte Kostenfaktor. Experiment: Ein kompaktes tabellarisches Format (TOON) für die Evidenz, die Ausgabe oder beides, in verschränkten Läufen auf eingefrorenen Packs. Ergebnis: Die verlustfreie Variante sparte 7,4 % der Tokens – etwa 46 ms bei einer Anfrage von rund 4,5 Sekunden –, während die kompakte Kodierung der Ausgabe die Zuverlässigkeit beim ersten Versuch auf 66,7 % senkte. Eine Ersparnis von 16 % in einem frühen Prototyp stellte sich als stillschweigend weggelassene Evidenz heraus. Konsequenz: Das Evidenzformat blieb, und die Regel lautet seitdem: weniger Tokens ohne messbaren Latenzgewinn sind ein Ablehnungsgrund.

Das Modell wählen. Günstigere gehostete Modelle scheiterten zunächst an Latenz (im Median 2,9-mal langsamer) und Verfügbarkeit (ein Drittel der Aufrufe mit Fehlern) – für eine Ersparnis von wenigen Dollar im Jahr kein Grund zu wechseln. Ein späteres Vergleichsturnier fand ein Modell (GLM 5.3), das Claude Haiku in einer verblindeten Nützlichkeitsbewertung und bei der Zuverlässigkeit im ersten Versuch schlug, auf Deutsch aber scheinbar gar keine Beziehungsaussagen erzeugte. Eine Nachuntersuchung zeigte, dass das ein Artefakt des Testsets war: Jede deutsche Frage war eine Aufzählungsfrage, bei der der Vertrag ausdrücklich keine Claims vorsieht. Konsequenz: eine anbieterneutrale Generierungsschicht und eine Fallback-Kette, der Wechsel als Konfigurationsänderung – und ein dauerhaftes Misstrauen gegenüber jeder Evaluation, deren Testfälle das gemessene Merkmal gar nicht sehen können.

Evaluation und Zuverlässigkeit

Das sind drei verschiedene Mechanismen, und keiner ersetzt einen anderen.

Offline-Evaluation entscheidet, ob eine Änderung ausgeliefert wird. Änderungen am Retrieval werden gegen einen eingefrorenen Benchmark mit 106 Fragen über 191 Fotos und 2.460 menschlichen Relevanzurteilen gemessen. Änderungen an der Generierung werden in verschränkten Läufen auf eingefrorenen Evidence Packs gegen vorab festgelegte Kriterien und Budgets gemessen. Einer der nützlichsten Befunde betraf den Benchmark selbst: Viele Kandidaten haben denselben Score, und die zufällige Auflösung dieser Gleichstände schönte das Produktivsystem um etwa vier NDCG-Punkte. Es schlug trotzdem alle 200 zufälligen Gleichstandsreihenfolgen – aber Rankings werden seitdem über viele solcher Reihenfolgen berichtet, nicht über eine.

Schutzmechanismen in Produktion greifen bei jeder Anfrage: die Prüfungen, der eine begrenzte Retry, fail-open-Komponenten im Retrieval, sichere Absagen, Deadlines pro Stufe und Rate Limits.

Beobachtbarkeit zur Laufzeit hält fest, was passiert ist: ein Ereignis pro Prüfung, der Kandidatentrichter vom Retrieval bis zur Evidenz, Entscheidungen von Planner, Reranking und Zulassung sowie ein Protokoll öffentlicher Fragen und ihrer Ergebnisse. Wenn Tracing aktiv ist, erfasst es nur Metadaten – nie Prompts oder Antworten.

Abwägungen

Mehr Code als ein direktes Retrieval-Augmented Generation. Sechs Prüfungen, eine Retry-Regel, eine Zulassungsregel und eine Kontextauflösung sind viel Maschinerie für ein Fotoarchiv. Jede davon existiert, weil ein gemessener Fehler sie nötig gemacht hat.
Ehrliche Absagen kosten Antworten. Eine Antwort, die zweimal scheitert, wird abgesagt, auch wenn das meiste richtig war. Ich habe mich für ein gelegentliches „Das kann ich nicht beantworten“ statt einer gelegentlichen selbstbewussten Erfindung entschieden.
Validatoren und Prompt müssen sich gemeinsam entwickeln. Der Prompt enthält 24 nummerierte Regeln, und mehrere Prüfungen existieren, um sie zu kontrollieren. Das eine ohne das andere zu ändern, ist eine Regression.
Acht Fotos sind eine Obergrenze. Die Grenze hält Antworten prüfbar und günstig – und begrenzt zugleich, wie breit eine Antwort sein kann.
Recall gegen Präzision, ausdrücklich. Bei Fragen, in denen kein Kandidat Begriffe mit der Frage teilt, war die deterministische Bestätigung sehr präzise und verlor viel tatsächlich relevante Evidenz. Ich habe ein eng begrenztes Prüfmodell ergänzt, das nur einen abgelehnten, rein semantischen Kandidaten nachträglich zulassen darf: Auf Englisch hob es den Recall auf diesem Rest von 33 % auf 95 %, während die Präzision von 100 % auf 91 % sank. Auf Deutsch verbesserte es den Recall ähnlich, verfehlte aber seine eigene Präzisionsschwelle; ich habe es trotzdem ausgeliefert, als Produktentscheidung für eine explorative Oberfläche, weil seine Befugnis begrenzt ist: Es kann eine Ablehnung nur in eine Zulassung verwandeln, nie umgekehrt; es kann nichts umsortieren; sein Urteil ist nie selbst zitierfähige Evidenz; und jeder Fehler führt zum deterministischen Ergebnis zurück.
Abhängigkeit vom Anbieter. In einer Messung im September war die primäre Modellstufe in etwa der Hälfte aller Runden gedrosselt; die Fallback-Kette hat sie aufgefangen – um den Preis von Antworten im Sekundenbereich und mehr beweglichen Teilen.

Was ich bei größerem Maßstab ändern würde

Ein Teil der heutigen Einfachheit ist für einen Eigentümer und einige hundert Fotos bewusst gewählt; ein Teil würde mehr nicht überstehen.

Größere Korpora: Der Vektorindex liegt in der SQLite-Datenbank der Anwendung, und die Packgröße von acht Fotos sowie die Reranking-Tiefe wurden auf diesem Korpus abgestimmt. Beides müsste neu gemessen werden; ich würde lange vor einer Änderung der Pipeline-Form auf einen eigenen Vektorspeicher wechseln.
Mehr Traffic: Rate Limits liegen im Prozessspeicher – richtig für eine Instanz, falsch für mehrere. Sie würden in einen gemeinsamen Speicher wandern, und Modellaufrufe bräuchten ein Budget und eine Warteschlangenstrategie statt nur Deadlines.
Mehrere Nutzer oder Mandanten: Die Evidenzgrenze legt bereits pro Anfrage fest, was das Modell sehen kann; Mandantenfähigkeit würde diese Grenze zum Teil von Retrieval und Autorisierung machen, nicht nur vom Veröffentlichungsstatus.
Strengere SLOs: Offline-Evaluation läuft heute bewusst gezielt statt bei jeder Änderung. Mit einem Verfügbarkeitsziel würde ein kleiner, günstiger Regressionssatz in der CI laufen, und die Latenz bekäme ein explizites Budget pro Stufe.

Das Gesprächsdesign müsste sich nicht ändern: Der Server hält keine Sitzung, und jede Runde trägt nur einen kleinen, validierten Kontext.

Was das an meiner Art, KI-Systeme zu bauen, verändert hat

Ich bin davon ausgegangen, dass die Modellqualität der wichtigste Hebel ist. Sie war wichtig – das aktuelle Modell wurde im verblindeten Vergleich bevorzugt –, aber sie wirkte innerhalb von Grenzen, die anderswo gesetzt werden: Kein Modell konnte ein Foto zitieren, das das Retrieval nicht zugelassen hatte, und mehrere der größten gemessenen Veränderungen dessen, was Besucher bekommen, kamen aus Zulassungsregeln, Evidenzgrenzen und der Form eines einzigen Retrys. Zwei der folgenreichsten Befunde waren Fehler in den Messungen selbst. Vertrauenswürdig wurde das System dadurch, dass das Modell die Aufgaben bekommt, die Regeln nicht so gut lösen – auswählen und erklären –, und alles um diese Aufgaben herum prüfbar ist.

Weiterlesen

Das Engineering Journal erzählt Teile dieses Pfads ausführlicher: Jeder Treffer braucht eine Erklärung, Pipelines schlagen Prompts und Suche für Erinnerungen gestalten.