Architektur von Engineering Ask

Engineering Ask ist der Assistent auf dieser Website, der Fragen dazu beantwortet, wie ich Software baue – „warum SQLite?“, „wie verhindert der Fotografie-Assistent Halluzinationen?“, „was hast du ausprobiert und verworfen?“. Die Antwort ist kurz, nennt die dokumentierten Entscheidungen, auf denen sie beruht, und verlinkt genau die Abschnitte meiner Architekturartikel, die die Umsetzung beschreiben. Die Prämisse ist dieselbe wie in meinen anderen KI-Systemen: Ein Sprachmodell schreibt den Text, entscheidet aber weder, was als Beleg zählt, noch wie sicher die Antwort klingen darf, noch welche Quellen es zitieren darf.

Das Problem

Ein Engineering-Portfolio ist meist eine Liste von Ergebnissen. Der interessante Teil – warum eine Option einer anderen vorgezogen wurde, was das gekostet hat, was zuerst gescheitert ist – steckt in Tickets, Berichten und meinem Gedächtnis, also dort, wo niemand ihn findet. Ich wollte diese Begründungen auffindbar machen, statt sie von einem Chatbot zusammenfassen zu lassen, der nur informiert klingt.

Das schloss den naheliegenden Entwurf aus vier Gründen aus.

• Die Antworten betreffen die Arbeit einer einzelnen Person. Kein Modell weiß, warum ich mich für einen bestimmten Reranker entschieden habe. Was nicht in meinen eigenen Aufzeichnungen steht, ist per Definition erfunden.
• Es gibt zwei Arten von Wahrheit, und sie lassen sich leicht verwechseln. Warum etwas entschieden wurde, steht in geprüften Entscheidungsdatensätzen. Wie ein System funktioniert, steht in veröffentlichten Architekturartikeln. Eine Antwort, die den Mechanismus eines Systems einem anderen zuschreibt, ist falsch, auch wenn jeder Satz plausibel klingt.
• Gefragt wird auf Deutsch und Englisch, und es wird nachgefragt. „Und das Frontend?“ lässt sich nur mit der vorigen Frage im Kopf beantworten – und es wird gefährlich, wenn das alte Thema in das neue hineinrutscht.
• Konfidenz muss etwas bedeuten. Ein Label „Hoch – direkt dokumentiert“ auf fast jeder Antwort ist schlechter als gar keins.

Was ich gebaut habe

Engineering Ask läuft produktiv auf der Startseite, hinter der „Engineering“-Insel. Ich habe den gesamten Pfad entworfen und gebaut: die Wissensbasis der Entscheidungen und ihren Review-Prozess, hybrides Retrieval und Reranking, den unabhängigen Index für Architekturbelege, den Generierungsvertrag, die Zitatprüfungen, kontextuelle Nachfragen, die Klassifikation von Konfidenz und Haltung sowie die Offline-Evaluierung hinter jeder der folgenden Änderungen.

Es ist ein produktives System in bewusst kleinem Maßstab: ein Autor, zum Zeitpunkt der jüngsten Messungen rund 280 geprüfte Entscheidungsdatensätze und acht Architekturartikel, dazu öffentliche, anonyme Besucher.

Die Architektur im Überblick

• Eingang. Zehn Fragen pro Minute und IP-Adresse plus eine globale Obergrenze; Fragen zwischen 3 und 500 Zeichen; eine Musterprüfung weist Anfragen, die die Belege pauschal abgreifen wollen, ab, bevor überhaupt ein Retrieval läuft.
• Kontextauflösung und Cache. Nachfragen werden durch deterministische Regeln über einen winzigen, vom Server verfassten Kontext aufgelöst, den der Browser zurückschickt. Ein Planner-Modell wird nur befragt, wenn die Regeln nicht entscheiden können. Aufgelöste Fragen, die in den letzten zehn Minuten beantwortet wurden, kommen aus einem prozessinternen Cache.
• Zwei Retrieval-Zweige. Engineering-Entscheidungen und Architekturabschnitte werden getrennt abgerufen – aus getrennten Indizes, mit unterschiedlichen Verfahren. Warum, zeigen die Messungen weiter unten.
• Evidence Pack. Höchstens fünf Entscheidungen und drei Artikelabschnitte. Mehr sehen weder das Antwortmodell noch der Konfidenz-Klassifikator.
• Konfidenz vor der Generierung. Das Konfidenz-Label wird zuerst bestimmt, weil es Teil des Antwort-Prompts ist.
• Generierung und Prüfungen. Das Modell liefert ein typisiertes Objekt; jede genannte Entscheidung und jeder zitierte Artikelabschnitt wird nach der Generierung gegen das Pack dieser Anfrage geprüft.

Die Haltungsanzeige liegt überhaupt nicht auf diesem Pfad:

Die Konfidenz fließt in den Prompt und damit in die Antwort; die Haltung entscheidet nur, ob neben der Antwort ein kleiner Chip „Eher ja / Bedingt / Eher nein / Unsicher“ erscheint. Warum das zwei getrennte Aufrufe sind, erklärt der Abschnitt zu Konfidenz und Haltung.

Die zentrale Architekturentscheidung

Das Antwortmodell ist der letzte und schmalste Schritt einer deterministischen Pipeline. Seine Aufgabe: aus den übergebenen Belegen eine kurze Antwort und ein paar Sätze Begründung schreiben und angeben, auf welche dieser Belege es sich stützt.

Es bestimmt nicht:

• welche Entscheidungen oder Artikelabschnitte existieren, geprüft oder veröffentlicht sind;
• was abgerufen wird, wie es gerankt wird oder wie viel es sehen darf;
• das Konfidenz-Label, das vorher feststeht und als feste Anweisung übergeben wird;
• die Haltungsanzeige, die es nie sieht;
• die Struktur der Antwort – ein Schema, das beim Provider und noch einmal in der Anwendung erzwungen wird;
• welche seiner Zitate bestehen bleiben;
• wie Belege dargestellt werden: Die Entscheidungskarten rendert die Anwendung aus den kanonischen Datensätzen, in der Sprache des Besuchers und über ihre ID – nicht aus dem Text des Modells.

Das Modell hat keine Tools und keinen Datenbankzugriff. Worin es irren kann, begrenzt der Inhalt des Packs; was es zitieren kann, begrenzen die Prüfungen.

Zwei Arten von Belegen: Warum und Wie

Die Wissensbasis hinter Engineering Ask ist kein Dokumentenhaufen. Ihre Einheit ist ein Entscheidungsdatensatz: Titel, Kategorie, Ausgangslage, betrachtete Optionen, gewählte Option, Begründung, akzeptierte Abwägungen und ein kleiner Satz kontrollierter Tags zum Engineering-Stil. Ein Datensatz kann die Quelle nennen, aus der er stammt.

Datensätze entstehen über einen Admin-Prozess. Ein Modell kann aus einem Dokument, das ich bereitstelle, Kandidaten vorschlagen – unter Regeln, die Schlüsse über den Text hinaus verbieten und belegende Zitate verlangen –, und Kandidaten unter einer Konfidenzschwelle werden verworfen. Nichts davon wird zum Beleg, bevor ich es geprüft und als Datensatz gespeichert habe. Abgelöste Entscheidungen werden in einer kanonischen Ablösungstabelle geführt und vor dem Ranking entfernt; eine Antwort baut also nicht auf einer Wahl auf, die ich inzwischen revidiert habe.

Architekturartikel – wie dieser – sind eine andere Art von Beleg. Sie beschreiben, wie ein System gebaut ist, mit einem Detailgrad, den ein Entscheidungsdatensatz nicht tragen sollte. Sie haben einen eigenen Lebenszyklus: Ein Artikel wird zuerst auf der Website veröffentlicht; seine Abschnitte werden dann deterministisch in eine Entwurfsrevision extrahiert; ich gebe jeden Abschnitt frei oder schließe ihn aus (und darf dabei nur Text entfernen, nie hinzufügen); erst dann wird die Revision eingebettet und in einer einzigen Transaktion aktiviert, die die vorherige ersetzt. Ein unveröffentlichter Artikel, eine unveröffentlichte Revision oder ein ausgeschlossener Abschnitt ist für Engineering Ask unsichtbar.

Die Trennung ist eine bewusste Entscheidung, kein historischer Zufall. Eine Entscheidung sagt warum, ein Abschnitt sagt wie; eine Antwort braucht meist beides, und ein Zitat muss sagen, welches von beiden es ist.

Die richtigen Entscheidungen finden

Das Entscheidungs-Retrieval kombiniert zwei Kandidatenlisten.

• Lexikalisch. Ein In-Memory-BM25 über neun Felder jedes Datensatzes, abgefragt mit den aus der Frage extrahierten Konzepten (gewichtet nach Extraktionskonfidenz) und den Wörtern der Frage selbst.
• Semantisch. Die Frage wird eingebettet und gegen die Entscheidungsvektoren gerankt; es zählen nur Vektoren, deren Inhalts-Hash zum aktuellen Datensatz passt – eine bearbeitete Entscheidung wird also nie über ein veraltetes Embedding gefunden.

Beide Listen werden per Reciprocal Rank Fusion zusammengeführt, und die zehn besten ordnet ein Reranking-Modell (Voyage rerank-2.5) neu. Die fünf besten bilden die Entscheidungen im Pack. Ist der Reranker langsam oder nicht erreichbar, bleibt die fusionierte Reihenfolge stehen.

Jeder Schritt wurde gemessen, bevor er live ging:

• Der vorherige Scorer hatte strukturelle Fehler – Teilstring-Abgleich, bei dem ein einziges gemeinsames Wort als Treffer zählte, keine Termgewichtung und ein „Wiederholungsbonus“, der für fast jede Entscheidung auf eine Konstante gesättigt war. Mit dem fusionierten BM25- und semantischen Ranking sank der Anteil der Antworten mit einer wesentlichen Auslassung von 28,6 % auf 12,5 % (16/56 → 7/56), in einem Vergleich mit 30 Fragen und 180 Antworten, blind von einem Modell bewertet.
• Das Reranking der besten zehn hob NDCG@5 auf 23 bewerteten Fragen von 0,562 auf 0,751, mit 17 Verbesserungen und einer Verschlechterung. Tiefe 20 erreichte mehr (0,810), aber mit mehr Verschlechterungen und mehr Latenz; Tiefe 10 hatte das beste Regressionsprofil.

Alle diese Urteile stammen von Modellen, nicht von mir oder einer anderen Person. Die menschliche Durchsicht der Streitfälle, die für den Reranker vorbereitet wurde, steht noch aus. Ich lese die Zahlen entsprechend: als Beleg für die Richtung, nicht als exakte Effektgrößen.

Architekturabschnitte als eigenständige Belege

Architekturabschnitte kommen aus einem eigenen Vektorindex, der keine Tabelle mit den Entscheidungs-Embeddings teilt. Die Frage wird mit jedem freigegebenen Abschnitt verglichen; Teilstücke sowie die deutsche und englische Fassung einer Überschrift fallen zu einem Kandidaten zusammen; die besten fünfzehn ordnet dasselbe Voyage-Modell neu; höchstens drei erreichen das Pack. Wie beim Entscheidungs-Reranker gilt: Fällt etwas aus, läuft die Anfrage ohne diesen Schritt weiter.

Aufschlussreich war, was nicht funktionierte. Auf einem eingefrorenen Satz von 46 Fragen erreichte semantisches Retrieval auf den belegbaren Fragen nDCG@5 0,628, BM25 0,339 und ein RRF-Hybrid 0,539 – in jedem Teilbereich unter dem semantischen Ergebnis. Am deutlichsten war Deutsch: Lexikalisches Retrieval kam auf 0,157, weil der Tokenizer für Englisch gebaut ist. Der Hybrid, der für Entscheidungsdatensätze funktioniert, wurde für Artikelabschnitte also verworfen. Fusion ist kein Standard; sie muss auf dem Korpus gewinnen, für den sie gedacht ist.

Zwei Befunde prägten die Integration:

• Kein Retrieval-Score trennt „nicht belegt“ von „schwach belegt“. Weder Kosinusähnlichkeit noch Reranker lieferten eine Schwelle, die Fragen zu unveröffentlichten Systemen abweist, ohne auch berechtigte Fragen abzuweisen. Eine Ablehnung muss deshalb aus Generierung und Konfidenz kommen, nicht aus einem Retrieval-Schwellenwert.
• Namen kollidieren. Die Engineering-Wissensbasis und die „Wissensschicht“ des KI-nativen Repositorys teilen sich Vokabular, und Antworten haben sie verwechselt. Eine Prompt-Regel, dass ähnlich benannte Systeme nicht dasselbe System sind, hat diesen Fehler verringert, aber nicht beseitigt (siehe Grenzen).

Gemessen über die ganze Pipeline mit 63 Fragen (134 Generierungen, blind von einem Modell auf einer Skala von 0–2 bewertet) hob das Hinzufügen gereranker Artikelabschnitte die Vollständigkeit von 0,92 auf 1,70 und die Genauigkeit von 1,54 auf 1,87, und der Anteil der Antworten mit falscher Quelle sank von 13 % auf 2 %. Entscheidungs-Retrieval, Entscheidungszitate und Konfidenz waren zwischen beiden Varianten byte-identisch; der Gewinn geht also auf die neuen Belege zurück.

Fundierte Generierung und Zitatverträge

Das Antwortmodell erhält in vertrauensmarkierten Blöcken: die extrahierten Konzepte und die festgelegte Konfidenz (vertrauenswürdig), ein deterministisches Stilprofil, die Entscheidungen, die Architekturabschnitte mit anfragelokalen Labels A1–A3 und zuletzt die Frage des Besuchers (nicht vertrauenswürdig). Artikeltext wird vor dem Prompt neutralisiert; Markup oder Anweisungen in einem Artikel bleiben Daten.

Zurück kommen genau vier Felder: eine Kurzantwort, ein paar Sätze Begründung, die Titel der Entscheidungen, auf die es sich stützt, und die Labels der verwendeten Artikelabschnitte. Die Ausgabe wird als natives Structured Output erzeugt und in der Anwendung noch einmal gegen einen Vertrag geprüft, der unbekannte Felder, Markdown und HTML ablehnt. Während das Modell schreibt, erscheint die Antwort als vorläufiger Text; erst die geprüfte Antwort ersetzt ihn.

Nach der Generierung laufen zwei deterministische Prüfungen:

1. Zuordnung der Entscheidungen. Jeder genannte Entscheidungstitel muss exakt einer Entscheidung im Pack dieser Anfrage entsprechen. Alle anderen werden entfernt; die akzeptierten Titel werden auf kanonische IDs abgebildet, aus denen die Belegkarten gerendert werden.
2. Architekturzitate. Jedes Label muss auf einen Abschnitt im Pack dieser Anfrage zeigen, und dieser Abschnitt muss noch zu der veröffentlichten Revision gehören, aus der er stammt. Unbekannte Labels, Duplikate, ein Abschnitt aus einem anderen Artikel und ein Abschnitt, dessen Revision sich inzwischen geändert hat, werden entfernt. Die URL – samt Anker der Überschrift, gelesen aus demselben Renderer, der die öffentliche Seite baut – erzeugt der Server. Das Modell schreibt nie einen Link.

Beide Prüfungen entfernen und protokollieren; keine versucht es erneut. Ein entferntes Zitat kostet einen Beleg, nicht die Antwort. In der integrierten Evaluation wurden 230 Architekturzitate beansprucht und 230 akzeptiert.

Wichtig ist, genau zu sagen, was das garantiert. Jede Entscheidungskarte und jeder Artikellink unter einer Antwort wurde für diese Frage abgerufen und ist veröffentlicht und geprüft. Nicht garantiert ist, dass jeder Satz des Textes stimmt: Der Text ist durch die Belege, aus denen er entsteht, durch den Vertrag und durch das Entfernen interner Kennungen eingeschränkt, wird aber nicht Satz für Satz auf Fakten geprüft. Und das Konfidenz-Label – dazu gleich mehr – misst die Belege, nicht die Antwort.

Nachfragen

Engineering Ask ist dialogfähig, aber der Server hält keine Sitzung. Nach jeder Antwort gibt er einen kleinen Kontext zurück: die tatsächlich ausgeführte Frage und die IDs der verwendeten Entscheidungen. Der Browser schickt ihn mit der nächsten Nachricht zurück. Er gilt als nicht vertrauenswürdige Eingabe – streng validiert, von derselben Eskalationsprüfung kontrolliert und auf noch existierende Entscheidungen gefiltert –, und ein fehlerhafter Kontext macht aus der Nachricht eine eigenständige Frage statt eines Fehlers. Früherer Antworttext, Konfidenz oder Haltung werden nie zurückgeschickt.

Zuerst lösen deterministische Regeln den Gesprächszug auf: Eine Verfeinerung („und die Barrierefreiheit?“) wird mit der vorigen Frage zusammengesetzt; eine Erklärung („warum?“) bleibt auf die vorigen Entscheidungen beschränkt; ein neues Thema beginnt von vorn. Ein Planner-Modell (standardmäßig Claude Haiku, ein Aufruf, Temperatur 0, vier feste Aktionen) wird nur bei Korrekturen, Rückverweisen („die da“) und Zügen ohne Subjekt oder mit kontextabhängigem Pronomen befragt. Seine Ausgabe muss Wörter enthalten, die im Gespräch tatsächlich vorkommen, und bei jedem Fehler gilt der deterministische Plan. Welche Entscheidungen im Geltungsbereich liegen, kann der Planner nie bestimmen.

Die Messungen machten die Abwägung greifbar. Auf 65 von Agenten gelabelten Nachfragen lösten Regeln allein 66,2 % korrekt auf, mit Planner bei unklaren Zügen 87,7 %. Aber der produktive Planner scheiterte – wie die Regeln allein – an beiden Themenwechseln vom Typ „und sein Sprachinteraktionssystem?“: Er hängte das alte Thema an das neue an („Wie ist die Frontend-Architektur des Fotografie-Assistenten gebaut?“). Die einzige Versuchsvariante, die einen davon richtig auflöste, war die mit einer zusätzlichen deterministischen Regel, und eine spätere Prompt-Regel hielt den Planner nicht auf. Ein ausdrücklich neues Thema wird deshalb jetzt deterministisch als neue Frage aufgelöst und erreicht den Planner nie – ein Fall, in dem das Entfernen des Modells die Lösung war.

Zwei weitere Schutzmechanismen richten sich gegen Vermischung. Bei einer Verfeinerung kann die zusammengesetzte Frage Belege des vorigen Gesprächsfadens für ein Thema mitbringen, das der Besucher gerade erst eingeführt hat; eine deterministische Konfidenz, neu berechnet aus den Konzepten des aktuellen Zugs, deckelt das finale Label, sodass geerbte Belege nicht für ein neues Thema bürgen. Und der Cache-Schlüssel enthält bei solchen Zügen die eigene Nachricht des Besuchers; zwei verschiedene Nachfragen zum selben Faden bekommen also nie dieselbe Antwort.

Die Vorschläge „Weiter erkunden“ unter einer Antwort entstehen im Browser aus festen deutschen und englischen Vorlagen über den zitierten Belegen – ohne Modellaufruf. Sie füllen nur das Eingabefeld; fragen muss der Besucher selbst.

Konfidenz ist nicht Haltung

Engineering Ask zeigt zwei Labels, und sie beantworten verschiedene Fragen.

Jev ist ein kleines gehostetes Klassifikationsmodell: Es beantwortet eine Auswahlfrage zu einem übergebenen Zustand und liefert ein Label mit einer Wahrscheinlichkeit pro Option, keinen Fließtext. Beide Aufgaben nutzen es – mit getrennten Verträgen, getrennten Anfragen und Tests, die sicherstellen, dass das eine Ergebnis das andere nicht verschiebt.

Konfidenz misst, ob das Evidence Pack ausreicht. Sie bewertet nicht die generierte Antwort – sie läuft, bevor es eine gibt. Sie beantwortet: Könnten diese Entscheidungen und Abschnitte diese Frage beantworten?

Dorthin führten drei Schritte:

1. Eine Regel, die fast alles als HOCH einstufte. Die ursprüngliche deterministische Regel bewertete eine Frage gegen den ganzen Korpus; irgendeine Entscheidung passte so zu fast jedem Konzept, und ein gemeinsames Wort genügte. In Produktion waren 73 von 81 beantworteten Fragen HOCH, in einer Stichprobe von 30 Fragen 27. Die Bewertung gegen das Pack, verbunden mit der Forderung, dass jedes Kernkonzept dokumentiert sein muss, ergab in der Stichprobe 10 HOCH, 17 MITTEL und 3 NIEDRIG. Eine manuelle Durchsicht fand keine zu hohen HOCH-Labels mehr, dafür etwa fünf gut dokumentierte, umformulierte Fragen, die nun zu niedrig eingestuft wurden.
2. Jev – mit einer Regression. In einem Offline-Experiment mit 50 Fragen lag Jev 42–43-mal richtig, die Regel 23-mal – aber Jev produzierte fünf falsche HOCH-Labels gegenüber drei bei der Regel, alle bei teilweise dokumentierten Fragen. Ein besserer Durchschnitt mit mehr Fällen des schädlichsten Fehlers war nicht auslieferbar.
3. Eine vorab registrierte Schwelle und ein unabhängiges Holdout. Alle falschen HOCH-Labels lagen unter einer Wahrscheinlichkeit von etwa 0,66, und diese Wahrscheinlichkeit schwankte zwischen Läufen. Ich habe die Regel festgelegt, bevor ich neue Daten angesehen habe: Jevs Label, wobei HOCH nur bei p(hoch) ≥ 0,70 bestehen bleibt (der kleinste Wert ohne falsches HOCH in allen vier Entwicklungsläufen). Auf einem eingefrorenen Holdout mit 62 neuen Fragen, in beiden Wiederholungen:

Die Auflösung kann Jevs Label nur senken: Ein HOCH unter der Schwelle wird MITTEL; ein leeres Pack ist nie HOCH; eine von den deterministischen Regeln erkannte Lücke deckelt HOCH bei MITTEL; und bei einer kontextuellen Nachfrage gilt die Obergrenze des aktuellen Zugs. Läuft Jev in das Zeitlimit (1,5 s), ist nicht erreichbar oder liefert etwas außerhalb des Vertrags, gilt das deterministische Label.

Warum abgewartet und nicht parallel. Konfidenz parallel zur Generierung zu starten wäre schneller, und ein früheres Experiment hat das erwogen. Aber das Label steht im Prompt: Es sagt dem Modell, wie bestimmt es die Antwort formulieren soll. Parallel ausgeführt, würde unter einem Label generiert und ein anderes angezeigt. Deshalb wartet jede begründende Antwort darauf – im Median etwa 0,3 s (p50 277 ms, p95 374 ms über acht Fragen durch die ganze Pipeline) bei Antworten, die rund fünf Sekunden dauern.

Haltung ist eine optionale Einschätzung. Bei einer Frage wie „Bevorzugt Vikram deterministische Absicherungen?“ können die Belege in eine Richtung weisen. Die meisten Fragen sind erklärend („wie funktioniert…“), und dann ist die ehrliche Haltung „nicht anwendbar“ – kein Chip. Früher wurde die Haltung per Regel berechnet und in den Prompt gegeben; sie aus dem Prompt zu nehmen, änderte die Antworten messbar nicht, und der Wechsel zu Jev senkte die Chips bei 40 erklärenden Fragen von 40 auf 2. In 48 Läufen auf dem Produktionspfad wurde Jev nie nach der Generierung fertig; die Haltung kostet also keine sichtbare Latenz. Fällt sie aus, fehlt der Chip, nie die Antwort.

Was gescheitert ist – und was die Evaluationen zeigten

Hybrid überall. Hypothese: Die BM25-und-semantische Fusion, die das Entscheidungs-Retrieval verbessert hatte, würde auch das Artikel-Retrieval verbessern. Ergebnis: Auf 46 eingefrorenen Fragen lag sie in jedem Teilbereich unter semantischem Retrieval allein, und lexikalisches Retrieval war auf Deutsch nahezu nutzlos. Entscheidung: semantisch plus Reranking für Abschnitte, hybrid für Entscheidungen.

Ein günstigerer Planner, eine weitere Grenze. Ein GLM-Planner hätte ein bis zwei Cent pro tausend Nachfragen gespart; er verfehlte eine vorab festgelegte Schwelle und war auf dem Nachfrage-Set im Median langsamer, wurde also nicht übernommen. Mehr Gesprächszüge an den Planner zu geben, rettete einige Nachfragen, band aber auch einige neue Fragen fälschlich an den vorigen Faden. Ausgeliefert wurde stattdessen eine engere Grenze, zusammen mit dem deterministischen Themenwechsel.

Prompt-Korrekturen, die keine waren. Zwei Prompt-Änderungen, die Antworten zur Architektur verbessern sollten, wurden gemessen und zurückgenommen: Keine hat sie verbessert.

Eine nachträgliche Schwelle. Im ersten Konfidenz-Experiment entfernte eine Regel p(hoch) < 0,6 zufällig jedes falsche HOCH. Wiederholte Läufe derselben Fragen zeigten, dass die Wahrscheinlichkeiten so stark schwankten, dass sie nicht gehalten hätte. Die ausgelieferte Schwelle wurde auf Entwicklungsdaten gewählt, mit Zeitstempel registriert und erst dann auf Fragen getestet, die sie nie gesehen hatte.

Zu den Labels. Jede Qualitätszahl in diesem Artikel stammt aus Offline-Evaluationen auf eingefrorenen Eingaben, und keine beruht auf menschlicher Ground Truth. Relevanzurteile, Erwartungen an Nachfragen und Konfidenz-Labels wurden von KI-Agenten verfasst und sind vorläufig; die Antwortqualität haben Modelle blind bewertet. Wo es ging, habe ich Verfassen und Bewerten getrennt, Regeln vorab registriert und frische Holdouts genutzt. Die menschliche Durchsicht der grenzwertigen Konfidenz-Labels und der Streitfälle des Rerankers ist die wertvollste offene Arbeit.

Sicherheit, Caching und Kosten

• Vertrauensgrenzen. Frage und zurückgeschickter Kontext sind nicht vertrauenswürdig; abgerufener Text ist Datenmaterial; nur von der Anwendung berechnete Werte sind vertrauenswürdiger Prompt-Kontext. Anfragen, die Belege pauschal abgreifen wollen, werden vor dem Retrieval abgewiesen, der Ausgabevertrag verbietet Markup, und durchgesickerte interne Kennungen werden sowohl aus der gestreamten als auch aus der finalen Antwort entfernt.
• Öffentliche Antwort. Der Browser erhält die Antwort, die Konfidenz, die optionale Haltung, Entscheidungs-IDs und geprüfte Artikelzitate – nicht die abgerufenen Elemente, die Konzepte oder die interne Herkunft des Konfidenz-Labels.
• Caching. Antworten, extrahierte Konzepte, Reranking-Reihenfolgen und die veröffentlichte Artikelansicht werden zehn Minuten im Prozess gecacht. Der Antwortschlüssel enthält eine Korpusversion, die jede Änderung an Entscheidungen oder Artikelbelegen erhöht; eine Änderung wird also nie von einer veralteten Antwort verdeckt.
• Beobachtbarkeit. Jede Anfrage erfasst Span-Attribute – Kandidatenzahlen, Ergebnisse von Reranking und Zitatprüfung, Herkunft der Konfidenz, Laufzeiten der Klassifikatoren – ohne den Text des Besuchers, dazu ein eigenes Protokoll öffentlicher Fragen und ihrer Ergebnisse.
• Kosten. Beide Jev-Aufrufe zusammen kosteten gemessen etwa 0,00023 $ pro begründender Antwort, das Entscheidungs-Reranking etwa sechs bis neun Cent pro tausend Fragen. Keins von beidem ist ein Grund, eine Absicherung zu entfernen.

Abwägungen und Grenzen

• Konservativ zu niedrige HOCH-Labels. Die Schwelle kostet korrekte HOCH-Labels: Auf dem Holdout hätte Jev ohne Schwelle 9–10 Fragen mehr richtig eingestuft. Zehn der 19 zu niedrigen Einstufungen der ausgelieferten Regel sind HOCH, angezeigt als MITTEL. Ich nehme gelegentlich ein zu bescheidenes Label in Kauf, um kein selbstsicheres zu zeigen, das die Belege nicht tragen.
• Teilweise Abdeckung wird als NIEDRIG gelesen. Acht zu niedrige Einstufungen sind teilweise dokumentierte Fragen („…und was kostet das pro Monat?“), die NIEDRIG statt MITTEL bekommen. Das unterschätzt die Abdeckung, überschätzt sie aber nie – eine echte Ungenauigkeit bleibt es.
• Konfidenz ist keine Faktentreue. Ein HOCH-Label sagt, dass die Belege eine Antwort dokumentieren, nicht, dass jeder Satz der Antwort stimmt.
• Jede Antwort wartet auf die Konfidenz. Im Median etwa 0,3 s, begrenzt auf 1,5 s.
• Namensverwechslungen bleiben. Deutsche Fragen zur Engineering-Wissensbasis können noch Vokabular aus der Wissensschicht des KI-nativen Repositorys übernehmen.
• Ein Generierungsfehler ist ein Fehler, kein Fallback. Es gibt keine deterministische Ersatzantwort; eine gescheiterte Generierung zeigt „Keine fundierte Antwort verfügbar“. Wiederholt wird nur über eine Provider-Fallback-Kette, sofern eine konfiguriert ist.
• Eine einzige Instanz. Rate Limits und Caches liegen im Prozessspeicher: richtig für eine Instanz, falsch für mehrere.
• Noch keine menschliche Ground Truth, wie oben beschrieben.

Was ich gelernt habe

Die größten Verbesserungen kamen nicht von einem besseren Antwortmodell. Sie kamen aus der Entscheidung, was das Modell sehen darf – fünf Entscheidungen, drei Abschnitte, aus zwei Indizes, die sich ihr Verfahren jeweils verdient haben –, und aus dem Trennen von Fragen, die vorher verschwommen waren: Warum gegenüber Wie, ausreichende Belege gegenüber wahrer Antwort, Konfidenz gegenüber Haltung. Einmal lag die Lösung darin, ein Modell aus einer Entscheidung herauszunehmen (Themenwechsel), einmal darin, eines hineinzunehmen – aber nur hinter einer Schwelle, die registriert war, bevor die Daten sie prüften. Das Muster dahinter ist das, zu dem ich immer wieder zurückkehre: Das Modell übernimmt die Sprache, und alles, worauf es sich stützt, muss überprüfbar sein.

Weiterlesen

Engineering Ask zitiert die anderen Architekturartikel als Belege. Am nächsten verwandt sind der Fotografie-Assistent, der dieselben Prinzipien der Fundierung auf ein Fotoarchiv anwendet, und das KI-native Repository, dessen Wissensschicht ein anderes System ist als die hier beschriebene Wissensbasis der Entscheidungen. Probier es selbst aus: Die „Engineering“-Insel findest du auf der Startseite.