Welche Einbettung braucht das Gedächtnis eines KI-Agenten?
Die eingebaute Einbettung von covey misst Wortüberlappung. Was ein selbst betriebenes Modell, ein fremder Dienst und ein späterer Wechsel bedeuten.
Ein Agent hat vor zwei Wochen eine Wikiseite angelegt, auf der steht, was zu tun ist, wenn die Pipeline rot ist. Heute bekommt er ein Ticket mit dem Satz „Der CI-Build schlägt fehl“, der dasselbe meint und mit dem Satz auf der Seite kein einziges Wort teilt. Ob der Agent die alte Seite in seinem Gedächtnis wiederfindet oder die Lösung ein zweites Mal erarbeitet und auf eine zweite Seite schreibt, entscheidet zu einem guten Teil die Einbettung.
Wer Agenten selbst betreibt, steht deshalb vor einer Frage, die im März 2026 auf Hacker News in ihrer Alltagsform gestellt wurde. Unter dem Namen asim beschrieb jemand als Problem, dass die Einbettungen des eigenen Projekts an der OpenAI-Schnittstelle hingen. Der Versuch mit dem Modell nomic-embed-text unter Ollama war auf der eigenen günstigen virtuellen Maschine ohne Grafikkarte nach eigener Aussage recht langsam. Covey bietet für diese Wahl vier Werte an, die über die Variable COVEY_EMBEDDING_PROVIDER in der .env der Installation gesetzt werden: builtin, ollama, voyage und openai.
Die eingebaute Einbettung misst Wortüberlappung
Die Vorgabe builtin braucht weder einen Schlüssel noch einen zusätzlichen Container. Der HashEmbedder verteilt Wörter und Wortpaare per Feature Hashing auf einen Vektor mit 256 Dimensionen, arbeitet deterministisch und ohne Netz. Er misst damit, welche Wörter zwei Texte teilen, wobei er den Text klein schreibt, an jedem Zeichen trennt, das weder Buchstabe noch Ziffer ist, und Füllwörter wie jedes andere Wort mitzählt. Da „was zu tun ist, wenn die Pipeline rot ist“ und „Der CI-Build schlägt fehl“ kein Wort teilen, ergibt das für das Paar dieses Beispiels eine Ähnlichkeit von null.
Daran hängen drei Stellen des Gedächtnisses gleichzeitig. Die Suche beim Aufgreifen einer Aufgabe gibt dem Agenten die fünf nächsten Seiten des aktiven Modells ohne Mindestwert mit, sodass die alte Seite dabei ist, solange weniger als fünf andere mindestens so nah liegen. Daneben sieht er den Index seines Wikis, der von der Einbettung unabhängig ist. Die Zuordnung einer neuen Erkenntnis an eine bestehende Seite greift erst ab einer Ähnlichkeit von 0,80, und der Wartungslauf führt Seiten erst ab 0,93 zusammen. Covey schreibt deshalb beim Start eine Warnung ins Protokoll, solange die eingebaute Einbettung aktiv ist, und die Dokumentation nennt sie für den echten Betrieb ausdrücklich unzureichend.
Selbst betrieben bleibt der Wikiinhalt in der Installation
Den selbst betriebenen Weg empfiehlt die Dokumentation, da die Inhalte des Wikis dabei im eigenen Haus bleiben. Dafür stehen in der .env zwei Zeilen, COMPOSE_PROFILES=embeddings und COVEY_EMBEDDING_PROVIDER=ollama, und nach docker compose up -d laufen zwei weitere Container aus dem Image ollama/ollama. Der Dienst embeddings beantwortet die Anfragen, während der einmalige Auftrag embeddings-init das Modell herunterlädt, weil Ollama ein fehlendes Modell bei einer Einbettungsanfrage nicht von selbst nachlädt.
Vorgabe ist EmbeddingGemma mit 308 Millionen Parametern, mehrsprachig und auf der CPU lauffähig. Ein anderes Modell lässt sich über COVEY_EMBEDDING_MODEL setzen, sofern es mindestens die 256 Dimensionen liefert, die das Datenbankschema erwartet. Liefert es mehr, behält covey die ersten 256 Werte und normiert den Vektor neu, was bei Matryoshka-trainierten Modellen der vorgesehene Weg ist und einmal je Prozess im Protokoll vermerkt wird. Liefert es weniger, bricht der Aufruf mit einem Fehler ab, da sich ein zu kurzer Vektor nicht ergänzen lässt.
Zur Geschwindigkeit von EmbeddingGemma auf einer bestimmten Maschine schweigt die Dokumentation. Die Frage von asim bleibt damit für jede Installation eine eigene Messung.
Ein fremder Dienst bekommt Titel und Text jeder Seite
Die Alternative ist ein Einbettungsdienst von außen, voyage mit dem Vorgabemodell voyage-3.5-lite oder openai mit text-embedding-3-small. Beide verlangen COVEY_EMBEDDING_API_KEY, und fehlt der Schlüssel, bricht der Start der Control Plane mit einer Fehlermeldung ab. Über COVEY_EMBEDDING_URL lässt sich der Endpunkt ersetzen, etwa durch einen Proxy, eine Azure-Instanz oder einen kompatiblen Dienst.
Der Preis dieses Wegs liegt im Inhalt der Anfragen. Beim Schreiben einer Seite gehen ihr Titel und ihr Text an den Dienst, gekürzt auf 8000 Zeichen, und bei jeder Suche die Suchanfrage selbst. Die Dokumentation sagt es im Gedächtniskapitel ausdrücklich: Das Wiki verlässt die Installation nur dann, wenn jemand bewusst einen fremden Einbettungsdienst einrichtet.
Ein Wechsel bettet den Bestand neu ein
Vektoren zweier Modelle lassen sich nicht miteinander vergleichen, weshalb jede Seite den Fingerabdruck ihres Modells in der Spalte embed_model trägt, etwa ollama:embeddinggemma:256. Suche, Zuordnung und Wartungslauf berücksichtigen allein Seiten des aktiven Modells. Nach einem Wechsel bettet die Control Plane beim nächsten Start den Bestand im Hintergrund neu ein, in Paketen zu 50 Seiten, und bis dahin findet die Suche die betroffenen Seiten nicht, ohne dass sie verloren wären.
Lädt der selbst betriebene Dienst beim ersten Start noch sein Modell, versucht covey es jede Minute erneut, höchstens 30 Mal. Ein stiller Rückfall auf die eingebaute Einbettung ist dagegen bewusst ausgeschlossen, sodass eine fehlerhafte Konfiguration den Start abbricht. Die Spezifikation begründet das damit, dass ein gemischter Index schlechter wäre als ein durchgehend schwacher.
Für den Agenten mit der roten Pipeline bedeutet das, dass die Wahl einmal für die ganze Installation fällt und für jeden Agenten dieselbe ist. Wer später wechselt, zahlt dafür eine Neueinbettung des gesamten Bestands, bei einem fremden Dienst einschließlich aller Seiten, die bis dahin nie das Haus verlassen haben.