Eine eigene Suchmaschine für das Modell, ohne Konten bei Zwischenhändlern
Ein Sprachmodell kennt die Welt bis zu dem Tag, an dem sein Training endete. Damit es Fragen zu heutigen Dingen beantworten kann, muss es suchen können. Wir haben dafür eine eigene Suchmaschine auf derselben Maschine gebaut – und bei der Gelegenheit gemessen, wie viel Arbeit es kostet, bis die Ergebnisse in der eigenen Sprache kommen.
Wie das Modell überhaupt sucht
Anders als man denkt, hat das Modell keinen Zugang zum Internet. Es funktioniert anders, und das sollte man verstehen, denn es betrifft die Privatsphäre der ganzen Lösung.
Das Modell erfährt zu Beginn, dass es zwei Werkzeuge gibt: Eines liefert eine Liste von Suchergebnissen, das andere holt den Inhalt einer angegebenen Seite. Wenn es zu dem Schluss kommt, dass die Frage frische Daten verlangt, führt es nichts selbst aus – es schreibt eine Bitte auf: „rufe die Suche mit der Phrase X auf“. Das Programm auf Nutzerseite führt diese Bitte aus, fragt unsere Suchmaschine ab und fügt die Ergebnisse zurück ins Gespräch ein. Das Modell liest sie wie gewöhnlichen Text und formuliert die Antwort.
Der gesamte Verkehr läuft also über unsere Maschine. Kein Modellanbieter sieht die Frage – und auch nicht, was mit der Antwort geschehen ist.
Was darunter steckt
Die Suchschicht ist SearXNG – eine offene Metasuchmaschine, die wir bei uns betreiben. Sie fragt eine externe Quelle ab (bei uns das offizielle API der Suchmaschine Brave, mit Schlüssel) und liefert eine vereinheitlichte Ergebnisliste. Der externe Anbieter sieht die Anfrage, aber weder wer fragt, noch wozu, noch was vorher im Gespräch geschah. Es gibt hier kein Nutzerkonto, keine Historie und kein Profiling.
Eine Konfigurationsfalle ist erwähnenswert, denn sie hat uns etwas Zeit gekostet: Wir haben eine Engine gewählt, die das offizielle API nutzt, und nicht das automatische Auslesen der Ergebnisseite. Der zweite Weg ist in ähnlichen Installationen manchmal der Standard und fängt sich nach gut einem Dutzend Anfragen eine Sperre ein.
Ergebnisse auf Polnisch verlangen zwei Einstellungen, nicht eine
Standardmäßig antwortet eine solche Installation mit englischsprachigen Ergebnissen, selbst auf eine polnische Anfrage. Wir haben das an einer technischen Phrase gemessen und die polnischen Ergebnisse unter den ersten zwanzig gezählt – für Ihre Sprache gilt dasselbe, etwa bei „de“ gegenüber „de-DE“:
| Spracheinstellung | Polnische Ergebnisse von 20 |
|---|---|
| keine / „alle“ | 0 |
| nur der Sprachcode („pl“) | 10 |
| volle Locale („pl-PL“) | 17 |
Der Unterschied zwischen „pl“ und „pl-PL“ ist keine Kosmetik, sondern sieben Ergebnisse von zwanzig. Einstellen muss man dabei zwei Ebenen: den Standardwert des Servers und die Parameter, die an die Engine selbst übergeben werden. Nur eine davon zu ändern reicht nicht, denn die andere wird vom Client überschrieben.
Das Modell kann das bei einer einzelnen Anfrage übersteuern – und tut das vernünftig, indem es auf Englisch wechselt, wenn es technische Dokumentation sucht.
Das Standardergebnis war zu mager – wir haben die Engine verbessert
Die Standardversion der Engine übernimmt aus jedem Ergebnis nur eine kurze Beschreibung – zwei Sätze, oft mitten im entscheidenden Satz abgeschnitten. Dabei liefert der Anbieter nebenbei zusätzliche Fragmente aus dem Seiteninhalt, um die niemand gebeten hatte und die schlicht weggeworfen wurden.
Wir haben dieses Stück durch eine eigene Version ersetzt, die diese Fragmente zusammenklebt und dem Ergebnis beilegt. Der Effekt: rund 4,7-mal mehr Text pro Ergebnis. Das Modell bekommt echten Inhalt statt eines Anrisses und antwortet deshalb öfter sofort, ohne ganze Seiten zu laden.
Die zweite Änderung ist klein, löst aber ein häufiges Problem: Vor jedes Ergebnis kleben wir das Veröffentlichungsdatum. Ohne dieses Datum kann das Modell einen fünf Jahre alten Ratgeber nicht von einem diesjährigen unterscheiden und hat regelmäßig Softwareversionen verwechselt.
Wann das Modell tiefer geht
In der Systeminstruktion haben wir eine Regel: Wenn die Fragmente abgeschnitten oder widersprüchlich sind oder das gesuchte Detail nicht enthalten – lade die ganze Seite. Das löst die Situationen, in denen die bloße Ergebnisliste eine Antwort vortäuscht, sie aber nicht enthält.
Ein Detail, das sich nachzuahmen lohnt: Wir beschreiben die Regel über die Rolle des Werkzeugs, nicht über seinen Namen („nimmt eine Adresse an, liefert Inhalt“). Verschiedene Programme nennen dieses Werkzeug unterschiedlich, und eine Instruktion, die sich auf den Namen beruft, funktioniert nach einem Client-Wechsel nicht mehr.
Was das an Kontext kostet
Frische Daten sind nicht gratis – sie belegen Platz im Gedächtnis des Gesprächs:
- eine Suche mit vollen Fragmenten: rund 4.000 Token,
- das Laden einer ganzen Seite: sogar über zehntausend.
Bei einem Kontext von 262.000 Token ist das eine komfortable Lage: Ein gutes Dutzend Suchen in einem Gespräch fällt nicht ins Gewicht. Auf einer Maschine mit kleinem Kontext würde genau hier der Spaß enden – und das ist einer der Gründe, warum es sich lohnte, um die Kontextkapazität zu kämpfen.
Was das in der Praxis bringt
Drei Dinge, geordnet nach ihrer Bedeutung für den Heimnutzer:
Aktualität. Das Modell hört auf, bei Fragen zu neuen Dingen zu fantasieren, denn es kann nachschlagen.
Privatsphäre. Die Anfragen bauen kein Werbeprofil und keine an ein Konto geknüpfte Historie auf. Das Haus verlässt nur der Suchbegriff selbst, ohne den Kontext des Gesprächs.
Unabhängigkeit. Die Suchmaschine ist austauschbar – die Quelle lässt sich wechseln, ohne die Modelle anzurühren und ohne darauf zu warten, bis der Anbieter seine Meinung zu Preisliste oder Nutzungsbedingungen ändert.
Eigene Konfiguration, auf derselben Maschine wie die Modelle. Die Messungen der Ergebnissprache wurden auf unserer Instanz durchgeführt.