XERJ ist eine Open-Source-Suchmaschine für ein Problem, das sichtbar wird, sobald ein Coding-Agent auf ein großes, unbekanntes Repository trifft: Der Agent kann suchen, doch die billigste Suche ist oft die unbrauchbarste. Grep liefert zu viel Kontext, das Öffnen einzelner Dateien verbraucht Tokens, und Modellgedächtnis hilft nur bei bekanntem, verbreitetem und unverändertem Code. Private Repositories, interne Konventionen, generierte APIs und aktuelle Commits zeigen diese Lücke besonders schnell.

Redaktionelles Technologiefoto eines lokalen Suchsystems für einen Coding-Agenten mit Laptop, indiziertem Repository und separatem lokalen Server.

Die Antwort des Projekts ist ein Ordner, der nach der Übergabe an die Engine automatisch durchsuchbar wird. xerj autoindex scannt Code, Dokumentation, Logs, PDFs und andere unterstützte Daten, extrahiert Strukturen und schreibt Suchdatensätze. Ein Agent kann danach gerankte Passagen oder Symbole anfordern, statt den ganzen Verzeichnisbaum zu lesen. XERJ stellt außerdem eine Elasticsearch-kompatible API bereit, sodass vorhandene Clients und Dashboards als Brücke dienen können.

Das macht XERJ interessanter als eine weitere lokale Vektordatenbank, ohne es zu einer allgemeinen autonomen Coding-Plattform zu machen. Die sinnvolle Frage ist nicht, ob es jeden Such-Stack ersetzt, sondern ob private Projekte, Referenz-Repositories oder dauerhafte Agenten-Notizen ohne eigenen Ingestion-Dienst leichter abfragbar werden. Die Antwort lautet: ja, unter Bedingungen. Der Workflow ist schlüssig, die Lizenz lautet Apache 2.0, doch Kompatibilität, Korpusaufnahme, Clustering und betriebliche Ausarbeitung sind weiter in Bewegung. Ein erster Versuch sollte auf einer wegwerfbaren oder schreibgeschützten Kopie stattfinden; das Datenverzeichnis gehört außerhalb des indexierten Baums, und --insecure ist ein Schalter für lokale Entwicklung.

Was sich am Ansatz des Projekts geändert hat

Viele Suchprodukte beginnen mit einem Schema. Man definiert Felder, wählt einen Analyzer, teilt Dokumente auf, konfiguriert Embeddings, erstellt einen Index und schreibt Ingestion-Code. Für stabile Anwendungsdaten ist das vernünftig, für einen Agenten mit wechselnden Repositories aber umständlich. Die Vorbereitung wird Teil der Aufgabe, obwohl eigentlich ein Fehler behoben oder ein unbekanntes Subsystem verstanden werden soll.

XERJ beginnt stattdessen mit einem Pfad. Der Autoindexing-Workflow klassifiziert Dateien, extrahiert Inhalte, hält die Herkunft fest und erzeugt sofort abfragbare Indizes. Für Quellcode verwendet der Extractor laut Repository tree-sitter, sodass Symbole und strukturelle Informationen zusammen mit Volltext indexiert werden. Ein Treffer kann dadurch zu einer Funktion oder Definition führen und nicht nur zu einer zufällig passenden Textzeile.

Der Quickstart beschreibt den Ablauf: lokalen Knoten starten, xerj autoindex auf ein Projekt anwenden, eine Frage suchen und die Passage oder Datei-und-Zeilen-Referenz als Arbeitskontext verwenden. xerj def dient der Definitionssuche, xerj gain berichtet die Nutzung. Letzteres ist eine aufschlussreiche Entscheidung: Token-Einsparungen sollen anhand echter Verwendung und nicht als Slogan bewertet werden.

XERJ kann auch verwandte Open-Source-Repositories indexieren, damit ein Agent vor einer Neuentwicklung eine vorhandene Implementierung findet. Das ist mehr als gewöhnliche semantische Ähnlichkeit: Ein konkreter Mechanismus soll verglichen und unter Beachtung seiner Lizenz angepasst werden. Abgerufener Code bleibt lizenzierter Code; Ähnlichkeit ist keine Erlaubnis zum unkritischen Kopieren.

Das Retrieval-Modell ist umfassender als ein Vektorindex

XERJ unterstützt Volltextsuche, Vektorsuche, hybride Suche, Aggregationen und Metadatenfilter. Der eingebaute lexikalische Feature-Hashing-Embedder läuft ohne Modelldownload und externen Inference-Endpunkt. Er erfasst Vokabular und Subwort-Überschneidungen, ist daher für Identifikatoren, Fachbegriffe und wiederkehrende Namen nützlich, versteht aber Bedeutung nicht wie ein starkes neuronales Modell und überbrückt nicht zuverlässig jedes Synonym.

Ein neuronaler Modus ist für stärkere semantische Zuordnung verfügbar. Die Roadmap beschreibt einen prozessinternen MiniLM-Klasse-Encoder, der beim ersten Einsatz heruntergeladen wird, sofern kein lokales Modellverzeichnis konfiguriert ist. Damit stehen ein schlanker lexikalischer und ein schwererer lokaler semantischer Pfad zur Wahl. Speicherverbrauch, Ladezeit, gemeinsame Nutzung mehrerer Indizes und der Betrieb auf luftisolierten Maschinen bleiben praktische Fragen; ein Knoten kann mehrere Modellinstanzen im Speicher halten.

Für Code dürfte hybride Suche der sinnvollste Einstieg sein. Lexikalische Suche findet exakte Namen, Flags, Fehlermeldungen und API-Symbole. Vektorsuche hilft bei abweichender Formulierung. Ein hybrider Treffer ist aber nur ein Hinweis für den nächsten Schritt. Das Projekt beschreibt außerdem einen persistenten HNSW-Pfad für ungefilterte Nearest-Neighbour-Suchen mit exaktem Rescoring. Veröffentlicht sind perfekter Recall bei einer offiziellen Benchmark-Abfrage und ein niedrigerer mittlerer Recall über ein Probe-Setup; daraus folgt keine allgemeine Zusage für jede Arbeitslast.

AST-basiertes Indexieren kann für Symbole, Aufrufstellen, Konfigurationsschlüssel und Implementierungsgrenzen wertvoller sein als ein modisches Embedding-Modell. Bei Konzepten, die in anderer Sprache beschrieben werden, wird semantische Suche wichtiger. XERJ führt beide Wege in einer lokalen Engine zusammen und schafft damit eine konkrete Vergleichsbasis.

Elasticsearch-Kompatibilität ist eine Brücke, keine Gleichheit

XERJ implementiert wesentliche Teile der Elasticsearch-REST-Oberfläche: Indizes, Dokumente, Bulk-Operationen, Suche, Mappings, Aggregationen, K-nearest-neighbour-Abfragen, Scrolling, Reindexing und mehrere _cat-Endpunkte. Vorhandene Clients und einige Dashboards können dadurch mit einem geänderten Endpunkt getestet werden.

„Elasticsearch-kompatibel“ ist jedoch eine API-Aussage. XERJ ist kein Fork und besitzt nicht dieselbe interne Architektur. Die Maintainer veröffentlichen eine Konformitätszahl und führen offene Lücken auf. Beim Scroll-Verhalten dokumentiert XERJ ein begrenztes Snapshot-Verhalten und verweist für größere Ergebnismengen auf search_after. Ein paar interaktive Suchen können funktionieren, während ein Export mit anderen Scroll-Annahmen scheitert.

Der Vergleich mit Elasticsearch 8.13.4 weist Gewinne, Gleichstände und Verluste bei Ingest, Volltext, Aggregationen, Vektorsuche und Lesevorgängen unter konkurrierenden Schreibzugriffen aus. Verluste bei der Lese-Tail-Latenz während aktiver Schreibvorgänge werden ausdrücklich genannt. Eine Kompatibilitätsmatrix sollte Indexerstellung, Mappings, Bulk-Ingest, Löschungen, Refresh, Aggregationen, Pagination, Vektorabfragen, Dashboards, Backup, Restore und Client-Version prüfen. Reihenfolge, Summen, Fehlerverhalten und Fehlermodi zählen ebenso wie eine Antwort.

Sicherheit beginnt beim Startmodus

Der Agenten-Quickstart verwendet --insecure für einen lokalen Ablauf. Laut Projekt deaktiviert der Schalter TLS und API-Key-Authentifizierung. Jeder erreichbare Aufrufer kann dann mit weitreichenden Rechten auf den Knoten zugreifen. Loopback begrenzt die Gefahr auf einer Workstation, macht einen exponierten oder weitergeleiteten Port aber nicht sicher.

Ohne --insecure ist API-Key-Authentifizierung standardmäßig aktiviert; ein administrativer Schlüssel kann im Datenverzeichnis mit restriktiven Dateirechten erzeugt werden. TLS wird separat über Zertifikat und Schlüssel konfiguriert. In gemeinsam genutzten Umgebungen braucht es Authentifizierung, passende TLS-Konfiguration, eingeschränkte Netzreichweite sowie Backup- und Zugriffsregeln.

Das Datenverzeichnis darf nicht in einem indexierten Ordner liegen. Sonst kann der Autoindex-Lauf seine eigenen Dateien entdecken, Duplikate erzeugen und den Index aufblasen. Die Issue-Historie zeigt außerdem einen Startfehler, bei dem ein Knoten Erfolg meldete, bevor jeder Listener gebunden war; ein Folgebefehl konnte dadurch mit einem anderen Dienst sprechen. Vor privater Indexierung sind Prozess, Adresse, Produktidentität und Datenpfad zu überprüfen.

Ein Index kann Quellcode, Logs, versehentlich eingecheckte Zugangsdaten, Incident-Notizen, Verträge, extrahierten Text, Metadaten und Embeddings enthalten. Lokal heißt nicht harmlos. Berechtigungen, Verschlüsselung, Aufbewahrung und Löschung brauchen dieselbe Sorgfalt wie bei den Originaldateien.

Agenten-Gedächtnis verändert die Vertrauensgrenze

XERJ bietet eine namensbasierte Memory-API auf gewöhnlichen Indizes. Ein Agent kann Notizen speichern, sie per Text- oder Vektorsuche finden und über Sitzungen hinweg behalten. Das passt zu Architekturentscheidungen, Testbefehlen und bekannten Fehlerbildern und vermeidet einen zusätzlichen Notizdienst.

Der Preis ist Persistenz. Eine Unterhaltung verschwindet; ein Memory-Namespace bleibt, bis er gelöscht oder abgelaufen ist. Notizen sollten deshalb Herkunft, Gültigkeitszeitraum und möglichst Commit oder Dokument enthalten und zwischen beobachteten Fakten und Debugging-Schlussfolgerungen unterscheiden. Sonst bewahrt das System veraltete Annahmen besonders zuverlässig auf.

Die Dokumentation zum „zweiten Gehirn“ beschreibt Graphbeziehungen zwischen Dokumenten und Notizen. Das erleichtert Navigation, erhöht aber die Folgen falscher Indexierung. Zu testen sind widersprüchliche Notizen, umbenannte Komponenten, gelöschte Dateien und zwischen Releases veränderte Fakten. Auch MCP-Werkzeuge haben relevante Autorität: Pfade begrenzen, Schreibrechte nur bei Bedarf vergeben und wichtige Abfragen sowie Mutationen protokollieren. Ein schreibgeschützter Workflow über eine kuratierte Kopie ist meist der sicherste Anfang.

Was die Einschränkungen über die Reife aussagen

Repository und Issue-Tracker zeigen offene Kanten bei Korpus-Wiederherstellung, JSON-Datensätzen ohne passagefähigen Text, Korpus-Durchsatz, hybrider Suche, Speicherdruck und Clustering. Das sind keine Gründe zur Ablehnung, sondern Hinweise darauf, dass das Produkt seine Grenzen noch festlegt.

Ein Verzeichnis strukturierter JSON-Datensätze kann gültig sein, während ein passagenorientierter Befehl nichts liefert, wenn das erwartete Textfeld fehlt. Abflachen oder Rendern in durchsuchbaren Text kann helfen; automatische Indexierung beseitigt aber nicht jede Entscheidung über das Inhaltsmodell.

Die Roadmap trennt den Nutzen eines einzelnen Knotens von verteilter Reife. Replikation, Leader Election, Shard-Verschiebung, Failover, Backup-Verifikation und Observability müssen separat geprüft werden. Eine Cluster-API beweist keine produktionsreife verteilte Speicherung. Viele kleine Datensätze können Scheduling-Overhead erzeugen; ein Repository unterscheidet sich von fünfzehn Repositories, einem Monorepo mit generierten Artefakten oder Hunderttausenden JSON-Dateien.

Die inkrementelle Indexierung bleibt vielversprechend: Unveränderte Dateien werden gehasht und ihr Ergebnis übernommen. Getestet werden sollten Umbenennungen, Löschungen, generierte Verzeichnisse, Symlinks, ignorierte Dateien und unterbrochene Läufe. Wertvoll ist ein Index, der sich nach einem chaotischen Entwicklungstag vorhersehbar erholt.

Wer es jetzt ausprobieren sollte

XERJ passt zu Entwicklern mit privatem oder spezialisiertem Code, mehreren verwandten Repositories, Compliance-Anforderungen für lokale Suche oder Interesse an Agenten-Gedächtnis ohne separate Vektordatenbank. Der erste Versuch sollte klein bleiben: wegwerfbare Kopie, Datenpfad außerhalb, Loopback, authentifizierter Modus bei möglichem Fremdzugriff und zunächst nur benötigter Quellcode sowie Dokumentation. Exakte Namen, Konzeptfragen, Definitionssuchen und schwierige Abfragen sollten gegen Grep, Language Server und unbeeinflusste Modellantworten verglichen werden. Maßgeblich ist die Zeit bis zum brauchbaren Kontext.

Danach Änderungen einführen: Datei umbenennen, Symbol löschen, Konfiguration ändern, generiertes Verzeichnis hinzufügen und Lauf unterbrechen. Prüfen, ob alte Datensätze verschwinden, Datei und Zeile stimmen und ein Fehlschlag reparierbar bleibt. Für Referenz-Coding sollten zwei oder drei Projekte mit vergleichbarer Aufgabe indexiert werden. Der Agent soll Mechanismus, Datei, Lizenz und Übertragbarkeit nennen.

Wer besser wartet

Teams mit einem großen, verteilten Elasticsearch-Einsatz sollten erst nach eigenen Kompatibilitäts- und Fehlertests migrieren. Das gilt auch für Organisationen mit Anforderungen an Flottenverwaltung, auditierte Backups, Mandantentrennung oder ein etabliertes Betriebsökosystem. Das öffentliche Material ist derzeit am stärksten bei lokaler Suche, Agenten-Workflows und gemessenem Single-Node-Verhalten.

Wer hochwertige semantische Suche benötigt, sollte den neuronalen Modus mit dem vorhandenen Embedding-Dienst vergleichen. Der lexikalische Standard ist nützlich, weil er offline und bescheiden ist, nicht weil er semantische Suche allgemein löst. Recall muss mit echter Sprache, Abkürzungen und Fachvokabular gemessen werden. Auch weniger Tokens sind kein ausreichender Adoptionsgrund: Die begrenzte Referenz-Coding-Studie berichtet geringeren Output-Tokenverbrauch bei gleicher Lösungsrate, während die Dokumentation den Nutzen vor allem bei privaten, internen, speziellen oder nach dem Trainingsstichtag entstandenen Inhalten sieht. Das ist eine prüfbare Hypothese, kein allgemeines Gesetz.

Fazit

XERJ gehört zu den fokussierteren Open-Source-Suchprojekten für das Agenten-Zeitalter, weil es Indexierung als Teil der Nutzererfahrung behandelt. Die stärkste Idee ist der Ablauf, der mit einem Ordner beginnt, daraus einen strukturierten lokalen Korpus macht und einem Agenten die genaue Passage oder das benötigte Symbol liefert.

Das Projekt ist einen Versuch wert, wenn private Codebasen, wiederholte Repository-Erkundung, lokale Suche oder leichtgewichtiges Agenten-Gedächtnis das Problem sind. Apache-2.0-Lizenz, Benchmarks, Kompatibilitätstests und sichtbarer Issue-Tracker ermöglichen eine Prüfung statt bloßer Bewunderung.

Die richtige Haltung ist experimentell und diszipliniert: Datenpfad trennen, Wirkung von --insecure verstehen, den gebundenen Dienst prüfen, exakte und semantische Suche separat testen, Lizenzen kontrollieren, Gedächtnis als persistente Daten behandeln und gegen bestehende Werkzeuge messen. Wenn XERJ besteht, senkt es den Kontextbedarf eines Agenten und bewahrt zugleich die Belege, die Vertrauen ermöglichen. Wenn es scheitert, sollte das an Kompatibilitätsfällen, korpusspezifischen Tests, Logs und reproduzierbaren Benchmarks sichtbar werden.

Praktische Start-Checkliste

  • Eine wegwerfbare Kopie eines Repositories verwenden.
  • XERJ-Daten außerhalb jedes indexierten Verzeichnisses speichern.
  • Den Knoten an Loopback binden und --insecure nur lokal kontrolliert verwenden.
  • Lexikalische, strukturelle, hybride und semantische Abfragen getrennt testen.
  • Nach Umbenennungen, Löschungen und unterbrochenen Läufen erneut indexieren.
  • Mit Grep, Language Server und bestehendem Such-Stack vergleichen.
  • Abgerufenen Code als lizenziertes Material behandeln und die Quelle festhalten.
  • Produktionsreife nicht allein aus Elasticsearch-Kompatibilität ableiten.

Quellen

Das Repository, die Installationsanleitung, der Agenten-Quickstart und die Sicherheitsdokumentation bilden die Grundlage für eine erste Evaluierung. Die Designbegründung, die Roadmap und der Issue-Tracker sind ebenso wichtig wie die Feature-Liste, weil sie zeigen, wo die Ansprüche des Projekts enden. Zusätzlich ist die Apache-Lizenz 2.0 für die rechtliche Einordnung maßgeblich.