Verschieben Sie Ihre Embeddings in den Client: Ein CTO‑Playbook für private, schnelle Suche

Sie senden noch immer Benutzertext per POST an eine Embeddings‑API eines Drittanbieters. 2024 hat das funktioniert. 2026 ist es nachlässig, langsam, teuer und zunehmend nicht compliant. Die Community hat gerade ein 7‑MB‑Embedding‑Modell ausgeliefert, das im Browser (WASM) läuft. Kleine, lokale Modelle gewinnen genau dort an Boden, wo das Netzwerk unzuverlässig ist. Die Zeichen stehen klar: Ein großer Teil der semantischen Suche und des RAG‑Preprocessings gehört auf den Client.

Das ist kein Reinheitsgebot. Es ist ein pragmatisches Redesign, das Inferenzkosten senkt, die Privacy‑Position stärkt und die Latenz auf „fühlt sich sofortig an“ drückt. Wenn Sie ein Engineering‑Team in einem Startup oder Scale‑up führen, brauchen Sie einen klaren Entscheidungsrahmen, wann Sie Embeddings an den Rand (Client) verlagern und wie Sie das sicher ausrollen.

Was sich seit 2024 geändert hat

• Modelle sind geschrumpft. Eine neue Welle winziger Embedding‑Modelle (zum Beispiel ein ~7 MB WASM‑Modell, auf Hacker News hervorgehoben) läuft jetzt vollständig offline im Browser. Sie brauchen keinen 200–500‑MB‑Download mehr, um brauchbare Vektoren zu erhalten.
• Laufzeitumgebungen sind gereift. WebAssembly SIMD, Threads und WebGPU haben die Decken angehoben. Auf Mittelklasse‑Laptops fühlt sich das Einbetten eines Absatzes nicht mehr an, als ob man Chromium kompiliert.
• Offline ist wieder normal. Sie sehen es bei FOSS‑Offline‑Karten und dem breiteren Trend „kleine Modelle in unzuverlässigen Netzen“. Nutzer erwarten, dass Kernfunktionen auch ohne WLAN funktionieren.
• Der Datenschutzdruck ist gestiegen. Geräte‑IDs, stille Telemetrie und Cross‑App‑Tracking sind in den Schlagzeilen. Rohtext an Embedding‑Endpunkte zu senden, lässt sich gegenüber Rechtsabteilung, Auditoren und Enterprise‑Kunden zunehmend schwerer rechtfertigen.

Wann Client‑seitige Embeddings sinnvoll sind

Nicht jede Retrieval‑Aufgabe ist gleich. Verlegen Sie die richtigen 60% in den Client und lassen Sie den Rest wie er ist.

Gute Kandidaten

• Benutzer‑spezifische Suche und RAG. Notizen, Tickets, Dokumente, Chats, CRM‑Snippets, Code‑Snippets. Denken Sie an 1–50k Einträge pro Nutzer, nicht an einen globalen Korpus.
• Zero‑Knowledge‑ oder Ende‑zu‑Ende‑verschlüsselte Daten. Wenn Ihre Server den Inhalt nicht lesen sollen, sollten sie ihn auch nicht einbetten.
• Privacy‑sensitive Domänen. Gesundheit, Finanzen, HR. Selbst wenn Sie eine Rechtsgrundlage haben, ist die Minimierung der Exponierung im Enterprise‑Vertrieb sehr wirkungsvoll.
• Latenz‑sensitive UX. Type‑ahead, „as you paste“-Vorschläge, Quick‑Open‑Suche. Sub‑100‑ms‑Gewinne sind für Endnutzer offensichtlich.
• Intermittierende Konnektivität. Feldeinsatz, ÖPNV, Luftreise, Emerging Markets. „Funktioniert offline“ bringt NPS‑Punkte.

Schlechte Kandidaten (server‑seitig belassen)

• Globale Suche über Nutzer/Mandanten hinweg. Aggregationen, Popularitätssignale und Missbrauchsabwehr benötigen in der Regel Zentralisierung.
• Strikte zentrale Audit‑Anforderungen. Wenn jede Anfrage und jeder Index‑Update zentral protokolliert und reproduzierbar sein muss, verkomplizieren reine Client‑Flows das Leben.
• Sehr große Korpora pro Nutzer. Wenn ein einzelner Nutzer routinemäßig 1M+ Einträge durchsucht, stoßen Sie an Browser‑Speicher und Arbeitsspeicher‑Grenzen.

Kosten‑ und Latenz‑Mathematik (mit überschlägigen Zahlen)

CTOs kümmern sich um Dollars und Millisekunden. Hier ist das schnelle Denk‑Modell:

• Embedding‑API‑Kosten. Große Anbieter bepreisen Embeddings nach verarbeiteten Tokens. Selbst bei niedrigen einstelligen Dollarbeträgen pro Million Tokens summiert sich das Indizieren von Nutzerinhalten. Ein einzelnes Kilobyte entspricht im Schnitt ein paar Hundert Tokens. Millionen von Einträgen über Ihre Basis ergeben jährlich fünf bis sechs Stellen, und das noch vor dem Re‑Embedding bei Modell‑Upgrades.
• Round‑Trip‑Latenz. Ein Netzwerkaufruf plus Anbieter‑Inference liegt typischerweise bei 200–800 ms im Happy Path; auf Mobile schlechter. Lokale Embeddings liegen oft im Bereich 10–70 ms für einen kurzen Absatz auf einem 2023–2025‑Laptop, auf Low‑End‑Phones länger. Dafür ist es vorhersagbar und funktioniert offline.
• Speicherabdruck auf dem Gerät. Ein 384‑dimensionaler Vektor in int8 sind ~384 Byte. Bei 10k Einträgen ergeben die Rohvektoren ~3,8 MB. Fügen Sie einen Approximate‑Nearest‑Neighbor‑Index (HNSW/IVF) und etwas Metadaten hinzu, bleiben Sie dennoch im zweistelligen‑MB‑Bereich, was für moderne Browser und Mobile‑Apps in Ordnung ist, wenn Sie Cache und Quoten managen.
• Server‑Egress. Wenn Sie aufhören, Benutzertext zum Einbetten zu verschicken, reduzieren Sie Egress bei jedem Ingestion‑Ereignis. Befinden sich Ihre Clients außerhalb Ihrer Region, ist das nicht trivial.

Der Gewinn ist nicht nur Unit‑Economics. Sie können es sich leisten, bei jedem Tastendruck, jedem Paste, jeder Bearbeitung einzubetten, weil Sie die Netzwerksteuer entfernt haben.

Ein Entscheidungsrahmen, den Sie dieses Quartal anwenden können

1) Inhalt und Qualitätsziel abstecken

• Korpusgröße pro Nutzer: 1k, 10k, 100k, 1M Einträge. Browser und Mobile sind bis in die Zehntausende zufrieden, wenn Sie sorgfältig sind. Sechsstellige Bereiche sind ohne Sharding grenzwertig.
• Textlänge: kurze Titel vs. mehrteilige Absätze. Kleine lokale Modelle performen besser bei kurzem bis mittlerem Text. Für lange Dokumente client‑seitig in Chunks einbetten und bei Bedarf server‑seitig zusammenführen.
• Qualitätsziel: Definieren Sie recall@K und MRR‑Ziele auf einem repräsentativen Testset. Wenn Server‑Vektoren recall@10 von 0,90 liefern, akzeptieren Sie lokal 0,85 mit Client‑seitigem Re‑Rank? Entscheiden Sie jetzt.

2) Modell und Runtime nach Gerätekategorie auswählen

• Browser: Beginnen Sie mit einem winzigen WASM‑Embedding‑Modell (die 7‑MB‑Klasse) für universelle Abdeckung. Wo WebGPU verfügbar ist, bieten Sie optional hinter einem „Hohe Genauigkeit“-Schalter ein größeres 100–200‑MB‑Modell für Power‑User an.
• Android: Zielen Sie mit einem quantisierten Modell via TensorFlow Lite/ONNX auf NNAPI; Android 17s On‑Device‑AI‑Stack ist für diese Workloads endlich verlässlich.
• iOS: Liefern Sie eine Core ML‑Version aus und nutzen Sie die Neural Engine, wenn verfügbar; für Hintergrund‑Indexierung auf CPU zurückfallen.

Fixieren Sie Vektordimension und Normalisierungsschema. Nicht übereinstimmende Dimensionen oder Kosinus‑ vs. Punkt‑Fehler kosten Sie später einen Sprint.

3) Eine Indexierungsstrategie wählen

• Kleine Korpora (<10k Einträge): Brute‑Force Kosinus/L2 auf optimierten Arrays ist ausreichend. Nutzen Sie Web Workers und SIMD.
• Mittlere Korpora (10k–200k): HNSW (hierarchische Graphen) oder IVF (Inverted File), client‑seitig gebaut oder als vorgebaute Shards ausgeliefert. hnswlib hat WASM‑Ports; messen Sie den Speicher‑Overhead.
• Hybrid: Der Server führt grobe Filterung (nach Metadaten/Zeit) durch, der Client macht exaktes oder graphbasiertes Reranking auf einigen Tausend Kandidaten. Das bewahrt Privatsphäre und hält Abfragen schnell.

4) Privacy und Governance von Anfang an berücksichtigen

• Kein „Phone Home“ mit Rohtext. Telemetrie sollte Zeiten und Zähler erfassen, nicht Inhalte. Wenn Sie Such‑Analytics brauchen, aggregieren Sie on‑device und melden Sie differenziell private Zusammenfassungen.
• Vektoren als sensibel behandeln. Vektoren können Semantik leaken. Verschlüsseln Sie sie nach Möglichkeit at rest auf dem Gerät; mandantenweise in separaten Namensräumen. Wenn Sie Vektoren synchronisieren, verschlüsseln Sie Ende‑zu‑Ende oder rotieren Sie bei Modell‑Upgrades.
• Modellversionierung. Taggen Sie jeden Vektor mit einer model_id und normalize_version. Mischen Sie niemals Vektoren inkompatibler Modelle. Rollen Sie per Hintergrund‑Re‑Embedding vorwärts.

5) Fallbacks nach Fähigkeit ausliefern

• Fähigkeiten erkennen: Beim Start verfügbare Rechenleistung, Speicher und Storage‑Quota messen. Ordnen Sie den Nutzer einer von drei Bändern zu: Local‑Fast, Local‑Okay oder Remote.
• Remote‑Fallback: Halten Sie Ihren server‑seitigen Embedding‑Pfad für Low‑End‑Geräte und stark abgeschottete Browser am Leben. Pro Mandant konfigurierbar machen.
• Sanfte Degradation: Wenn ein Gerät heiß läuft oder der Akku knapp ist, drosseln Sie die Hintergrund‑Indexierung und verlassen Sie sich auf Metadaten‑Filter plus zuletzt bekannte Vektoren.

Drei Referenzarchitekturen

1) Nur Client, Metadaten synchronisieren

Einsatz, wenn: Zero‑Knowledge‑Positionierung, persönliche Datenspeicher, hohe Datenschutzanforderungen.

• Alle Texte bleiben lokal. Der Client berechnet Vektoren, baut einen lokalen ANN‑Index auf und persistiert in IndexedDB/SQLite (Mobile).
• Der Server synchronisiert nur Item‑IDs, Zeitstempel und optionale verschlüsselte Blobs. Die Suche läuft vollständig auf dem Gerät.
• Trade‑off: keine geräteübergreifende Suche ohne verschlüsselte Vektor‑Sync; höherer anfänglicher Download fürs Modell.

2) Hybrides Rerank

Einsatz, wenn: mittlere Korpora, Multi‑Device‑UX, Compliance benötigt eine Server‑Spur.

• Client embed­det Anfragen und Items. Der Server speichert verschlüsselte Vektoren für Sync und grobe Kandidatenselektion pro Anfrage (z. B. nach Projekt/Zeit/Eigentümer).
• Der Client lädt die Vektoren der Top‑N‑Kandidaten, führt exaktes Kosinus‑Reranking aus und rendert Ergebnisse. Rohtext muss das Gerät nicht verlassen.
• Trade‑off: Sie müssen einen Vektor‑Sync‑Service betreiben und Metadaten gut verschlüsseln.

3) Server grob + Client‑Embeddings

Einsatz, wenn: Sie bestehende Server‑Suchinfrastruktur dieses Quartal nicht ersetzen können.

• Der Server beantwortet Metadaten‑Only‑Anfragen schnell (Keyword, Filter). Der Client embed­det nur den Nutzerkontext und die Anfrage und rerankt die Top‑N‑Treffer des Servers lokal.
• Trade‑off: Qualität hängt von der Server‑Recall ab; Meta‑Leakage‑Risiko bleibt, wenn Filter zu grob sind.

Qualitätsfallen und wie Sie sie vermeiden

• Domänen‑Mismatch. Winzige General‑Purpose‑Modelle können bei Code, Medizin‑ oder Rechtstexten unterperformen. Erwägen Sie eine leichte Domänenanpassung oder einen kuratierten Synonym‑Wortschatz client‑seitig.
• Chunking‑Strategie. Bei langen Dokumenten sind Chunk‑Größe, Stride und Title‑Boosting wichtiger als das letzte Prozent aus dem Modell zu pressen. Standardisieren und testen.
• Index‑Drift. Hintergrundänderungen müssen re‑embedden und den ANN‑Graphen atomar aktualisieren. Verwenden Sie ein Write‑Ahead‑Log und versionierte Indexsegmente.
• RAG‑Halluzinationen. Lassen Sie lokale Retrievals Ihrem Generator nicht stillschweigend Müll zuführen. Hängen Sie Provenienz an und erzwingen Sie Answerable‑by‑Context‑Checks vor Modellaufrufen.

Speicher‑ und Performance‑Engineering im Browser

• Wo speichern: IndexedDB für strukturierte Blobs, OPFS (Origin Private File System) für große Binär‑Shards in modernen Chromium‑basierten Browsern, SQLite via WASM für vorhersagbare Performance in Electron/Tauri oder Mobile.
• Kompression: int8‑Vektoren reduzieren den Speicher 4× ggü. float32 mit geringem Recall‑Einfluss. Produktquantisierung kann weitere 2–4× bringen, wenn Sie kleine Genauigkeitsverluste tolerieren.
• ANN‑Speicher: HNSW lädt Kanten in den Arbeitsspeicher; planen Sie 2–3× Vektorgrößen‑Overhead ein, wenn vollständig resident. Begrenzen Sie Parallelität und wärmen Sie Teilmengen nach Namespace vor.
• Workers: Verschieben Sie Embedding‑ und ANN‑Arbeit immer in Web Workers. Halten Sie den UI‑Thread unter dem 16‑ms‑Frame‑Budget.
• Thermik: Steuern Sie Hintergrund‑Indexierung nach Akku und CPU‑Temperatur, wo verfügbar. Auf Mobile beim Laden oder kürzlich aktiv indexieren.

Compliance, Verträge und Sales Enablement

Wenn Sie an Enterprises verkaufen, sind Client‑seitige Embeddings ein Geschenk für Ihren Security‑Fragebogen‑Flow.

• Datenresidenz: „Kein Nutzerinhalt verlässt das Gerät für die Suche“ nimmt der Hälfte der Residenz‑Debatte den Wind aus den Segeln.
• DPIAs und DSRs: Die Minimierung der server‑seitigen Verarbeitung personenbezogener Daten reduziert Ihre Exposure in Datenschutz‑Folgenabschätzungen und Betroffenenanfragen.
• Vendor Risk: Sie entfernen einen Drittanbieter‑Embeddings‑Provider von der „Sub‑Prozessor“-Liste für dieses Feature. Das beschleunigt den Einkauf.

Rollout‑Plan: 30 / 60 / 90 Tage

Tag 0–30: Beweisen Sie es

• Wählen Sie ein benutzer‑spezifisches Feature (z. B. Workspace‑Suche) und implementieren Sie einen reinen Client‑Pfad hinter einem Feature Flag.
• Integrieren Sie ein kleines WASM‑Modell und messen Sie Cold‑Start, Embedding‑Zeit pro Absatz und recall@10 vs. Ihrer Server‑Baseline auf einem 1k‑Query‑Testset.
• Definieren Sie Fähigkeitsbänder und implementieren Sie einen Remote‑Killswitch und Server‑Fallback.
>

Tag 31–60: Produktisieren

• Fügen Sie lokalen ANN für Korpora über 10k Einträge hinzu. Persistieren Sie in OPFS/IndexedDB mit versionierten Segmenten.
• Instrumentieren Sie Telemetrie ohne Inhalte: Zeiten, Fehlercodes, Modellversion, Geräteband. In ein separat datenschutz‑gesteuertes Sink routen.
• Schreiben Sie die Sicherheitsnotiz: Vektoren sind sensibel, Modellversionen sind festgezurrt, Verschlüsselung at rest wo unterstützt, und E2EE, wenn Sie Vektoren synchronisieren.

Tag 61–90: Skalieren

• Rollout auf 25–50% der Nutzer auf fähigen Geräten. Beobachten Sie Crash‑Raten, Cold‑Starts und Recall‑Deltas pro Mandant.
• Bieten Sie ein optionales „Hohe Genauigkeit“-Modell für WebGPU‑fähige Desktops an. Behalten Sie das kleine Modell als Default.
• Planen Sie Ihre nächste Migration: Client‑seitiges Rerank für Ihre globale Suche oder On‑Device‑Zusammenfassungen für Top‑Treffer.

Trade‑offs, die Sie im Raum offen ansprechen sollten

• Genauigkeit: Ein 7‑MB‑Modell wird einen 500‑MB‑Frontier‑Embedder auf Nischendomänen nicht schlagen. Aber mit gutem Chunking und Rerank merken Nutzer es vielleicht nicht. Testen Sie mit Ihren Daten, nicht mit denen von Twitter.
• Komplexität: Sie führen einen zweiten Retrieval‑Stack und Fähigkeitsdetektion ein. Halten Sie es hinter einer dünnen Abstraktion und seien Sie fanatisch bei der Modellversionierung.
• Speicherquoten: Browser sind besser als früher, aber Quoten und Eviktionsrichtlinien variieren. Entwerfen Sie für partielle Indizes und schnelle Rebuilds.
• Gerätevielfalt: Rechnen Sie mit einem 10×‑Spread im Durchsatz. Ihr Produkt muss sich sowohl auf einem zwei Jahre alten Android als auch auf einem neuen M‑Series‑Mac gut anfühlen.

Warum das für Nearshore‑Teams zählt (und für Ihre Roadmap)

Client‑seitige Embeddings lassen verteilte Teams spürbare Geschwindigkeit für Nutzer ausliefern—ohne teure Infra‑Änderungen. Für US‑LATAM‑Produktorgs gibt es einen Bonus: Robuste Rust‑to‑WASM‑Pipelines, On‑Device‑Indizes und hybride Retrieval‑Schichten zu bauen, ist genau die Art von Systemarbeit, in der Senior‑Nearshore‑Ingenieure glänzen, mit 6–8 Stunden Overlap für enge Iteration. Sie investieren Zeit in Produkt‑UX statt in einen weiteren Vector‑Cluster.

Fazit

Sie müssen nicht alle Retrievals in den Client verlagern. Aber wenn Sie gar nichts verlagern, zahlen Sie mehr als nötig, warten länger als Ihre Nutzer wollen und tragen mehr Privacy‑Risiko, als Ihr Vertrieb verteidigen kann. Starten Sie mit einem benutzer‑spezifischen Feature. Shippen Sie ein kleines Modell. Messen Sie. Dann ausbauen.

Kernpunkte

• Kleine Embedding‑Modelle laufen jetzt im Browser; ein ~7 MB WASM‑Modell reicht für viele benutzer‑spezifische Suchen.
• Verschieben Sie Embeddings client‑seitig für benutzer‑spezifische, privacy‑sensitive, latenzkritische Features; behalten Sie globale Suche server‑seitig.
• Rechnen Sie mit Vektoren um 384 Byte pro Eintrag bei int8; 10k Einträge passen komfortabel aufs Gerät mit einem moderaten ANN‑Index.
• Taggen Sie jeden Vektor mit einer Modellversion; mischen Sie niemals inkompatible Embeddings; verschlüsseln Sie Vektoren at rest und während des Syncs.
• Nutzen Sie Fähigkeitsdetektion zur Bändelung von Geräten und halten Sie einen Server‑Fallback vor; instrumentieren Sie Telemetrie ohne Inhalte.
• Hybride Architekturen (Server grob, Client Rerank) bewahren Privatsphäre und vermeiden Qualitätsklippen.
• Planen Sie einen 90‑Tage‑Rollout: beweisen, produktisieren, dann mit optionalen High‑Accuracy‑Modellen auf fähiger Hardware skalieren.