Eine Architektur mit Trennung der Belange — alles in einem einzigen Binary. Routing, native Inferenz und Vektor-Speicher sind drei eigenständige Verantwortungen, die Eldric als getrennte Rollen trägt: dieselbe in sich geschlossene Plattform, die verschiedene Rollen spielt, im Cluster nach Rolle über die Knoten verteilt statt aus separaten Diensten zusammengesetzt. Diese Seite ist die technische Sicht für Power-User und Operatoren, die wissen wollen, warum der RAG-Pfad so geformt ist und wie die Teile zueinander stehen.
Wenn eine Chat-Anfrage Retrieval auslöst, beteiligen sich drei Rollen in dieser Reihenfolge — alle vom selben Eldric-Binary bereitgestellt, ob sie auf einer Maschine oder über ein Cluster verteilt laufen:
Die Chat-Completion läuft dann mit den abgerufenen Passagen als injiziertem Kontext, und die Plattform liefert die fundierte Antwort samt Zitat-Metadaten zurück, die auf die Quelle verweisen.
Würde die Routing-Rolle das Einbetten selbst erledigen, müsste jeder Knoten, der als Koordinator agiert, das Embedding-Modell geladen halten — das kostet Speicher und verlangsamt den Start. Schlimmer: In einem Cluster ist der koordinierende Knoten womöglich nicht derjenige mit GPU, also würde er auf einer CPU einbetten, während eine völlig brauchbare GPU einen Host weiter herumsteht. Bleibt Routing ein reiner Koordinator, skaliert die Embedding-Arbeit unabhängig von der Routing-Arbeit.
Das Embedding-Modell ist bewusst kompakt — es läuft komfortabel auf CPU, passt auf bescheidene Hardware bis hinunter zu einer kleinen Single-Board-Maschine und wandelt eine Seite Text in einem Bruchteil einer Sekunde in einen Vektor. Weil Eldric Modelle ohnehin nativ bereitstellt, ist die native Inferenz-Rolle der natürliche Ort, das Embedding-Modell zu beherbergen: keine zusätzliche Runtime, kein separater Dienst — einfach ein weiteres Modell, das die Plattform bereits zu bedienen weiß.
Die Daten-Rolle hält bereits die Quell-Dokumente, die Chunks, die Mandanten-Grenzen, das Audit-Protokoll und den Datei-Speicher. Vektor-Einträge neben die Chunks zu legen — statt in eine separate Vektor-Datenbank — heißt: Löschen, Neu-Einbetten, Mandanten-Isolation und Backup sind eine Operation, nicht fünf.
Diese drei Verantwortungen sind nicht drei zusammengenähte Produkte. Es sind Rollen innerhalb der einen Eldric-Plattform. Installieren Sie die Plattform einmal, und sie kann alle drei spielen; in einer größeren Installation entscheiden Sie, welche Knoten welche Rollen übernehmen, und die Plattform koordiniert über das Cluster-Netz zwischen ihnen.
Das ist das Muster in ganz Eldric: Fähigkeiten sind Module eines in sich geschlossenen Systems, kein Stack, den Sie zusammenbauen. Retrieval ist schlicht eine Stelle, an der drei dieser Rollen der Reihe nach aufmarschieren — koordinieren, einbetten, speichern —, um eine Frage in eine fundierte, zitierte Antwort zu verwandeln.
Die kompressionsbasierte Seite des Retrievals reitet auf derselben Daten-Rolle, in Eldrics kompaktem, portablem .emm-Format, abgefragt neben dem exakten Vektor-Speicher, sodass schnelle assoziative Erinnerung und präzise Nachschlage-Suche gemeinsam eintreffen.
Alles auf einem Host. Routing, native Inferenz und die Daten-Rolle werden allesamt von der einen Plattform auf der einen Maschine bedient. Das Einbetten teilt sich den Host mit der übrigen Inferenz-Arbeit; es belegt einen Bruchteil des verfügbaren Speichers und läuft ohne Streit neben größeren Modellen.
Verteilen Sie die Rollen über das Cluster. Ein kleiner Management-Knoten koordiniert; ein GPU-bestückter Knoten (oder jeder Knoten mit genug CPU-Reserve, wenn Sie dem Einbetten keine GPU widmen wollen) bedient die native Inferenz; ein Storage-starker Knoten hält die Daten-Rolle. Die Plattform ermittelt, wo jede Rolle lebt, und koordiniert automatisch zwischen ihnen — Sie weisen die Rollen in der Admin-Konsole zu, nicht über Start-Parameter.
Auf einer kleinen Edge-Box laufen alle drei Rollen auf dem einen Host — die Plattform liefert sie als Einheit. Der Edge-Knoten bettet lokal ein, indiziert lokal, fragt lokal an. Wenn ein zentraler Cluster konfiguriert ist, verschieben sich ganze Wissensbasen zwischen Edge und Zentrum, ohne neu einzubetten.
Ist die native Inferenz unerreichbar, liefert die Plattform einen strukturierten Fehler statt einer kaputten Antwort. Neue Uploads, die eingebettet werden müssen, bleiben als „in Warteschlange“ markiert und versuchen es beim nächsten Zyklus erneut, sobald die Rolle wieder da ist. Chat-Anfragen, die Retrieval ausgelöst hätten, fallen auf den reinen Chat zurück — ohne Zitate — statt die ganze Anfrage scheitern zu lassen.
Ist die Daten-Rolle unerreichbar, meldet die Vektor-Suche die Rolle als nicht verfügbar, und Chat-Anfragen fallen auf den reinen Chat zurück. Uploads puffern auf dem koordinierenden Knoten und werden geleert, sobald die Daten-Rolle zurück ist.
Ist das Embedding-Modell nicht geladen, sagt die Plattform das klar und mit einem deutlichen Hinweis. Die Admin-Konsole hat ein Lade-Steuerelement; das Modell ist auf einer Standard-Installation vorhanden, und das Einbetten läuft beim nächsten Request wieder, sobald es geladen ist.
Für die Anleitung für Endnutzer: RAG verwenden. Für die Chunking-Strategien je Inhaltstyp: Chunking-Strategien. Für die kompressionsbasierte Memory-Preview, die die Vektor-Suche bei Parallelität beschleunigt: Erweiterte Retrieval. Für die inferenzseitige Preview, die das Memory beim Eintreffen des Prompts konsultiert, statt einen Umweg zu machen: Intelligente Memory-Inferenz.
Für den Rest des Systems, in dem der RAG-Pfad sitzt: Wie es funktioniert führt durch die gesamte Architektur, von Client über Edge zu den koordinierenden, lenkenden und Daten-Rollen und der nativen Inferenz dahinter.