# Mit RAG als zweitem Gehirn: Keine beste Lösung, nur das passendste Szenario In den letzten zwei Jahren haben fast alle Teams, die an großen Modellen arbeiten, dasselbe getan: ihrem Modell RAG hinzugefügt. Der Grund ist einfach. Große Modelle haben zwei angeborene Schwächen – ihr Wissen hat ein Ablaufdatum und sie neigen zum Halluzinieren. RAG soll beide Probleme gleichzeitig lösen: ihm die neuesten externen Daten geben und es basierend auf diesen Daten antworten lassen. Daraus entstand ein weit verbreitetes Missverständnis: **RAG ist eine Technologie. Wenn man die richtige wählt, hat man gewonnen.** Aber die Realität ist: RAG ist keine einzelne Technologie. **RAG ist ein Überbegriff für eine Klasse von Architekturen.** Unterschiedliche Szenarien erfordern völlig unterschiedliche Architekturentscheidungen. So wie große Modelle unterschiedliche Zwecke haben – ein 4B leichtes Modell ist nicht nutzlos, es ist in Szenarien mit Edge-Inferenz, niedriger Latenz und geringen Kosten praktischer als ein Modell mit hundert Milliarden Parametern. Ein Billionen-Parameter-Modell hat starke Inferenzfähigkeiten, aber Unternehmen können es sich nicht leisten, es zu deployen. Jedes hat seinen Platz. Bei RAG-Lösungen gibt es denselben Unterschied. Keine Lösung ist absolut die beste. Es gibt nur die, die am besten zum aktuellen Szenario passt. **Dieser Artikel möchte Folgendes sagen: Im spezifischen Szenario „Notizen + Dokumente + RAG" – also dem Aufbau eines zweiten Gehirns mit KI – welche Lösung ist die optimale? Und warum.** --- ## 1. Wo die wahren Herausforderungen von RAG im Jahr 2025 liegen Ein RAG-Demo ist an einem Nachmittag erledigt. Aber die Probleme, die in der Produktion auftauchen, konzentrieren sich auf drei Dimensionen: ### Indizierung ist keine einmalige Aufgabe, sondern eine dauerhafte Belastung „Alle Dokumente in eine Vektordatenbank einbetten" klingt einfach. Aber im Betrieb: Bei einem Modell-Upgrade müssen 10 Millionen Dokumente mit etwa 5 Milliarden Tokens neu verarbeitet werden, allein die API-Kosten betragen 300-650 $. Beim Löschen von Dokumenten können veraltete Einträge in der Vektordatenbank tagelang unbereinigt bleiben. Bei Berechtigungsänderungen gibt es ein Sicherheitsfenster von mehreren Stunden, wenn der Index der Dokumente eines ausgeschiedenen Mitarbeiters nicht rechtzeitig aktualisiert wird. Bei Plattformbeschränkungen schränken Tools wie Slack und Notion bereits das massenhafte Abrufen von Daten durch Dritte ein. ### Latenz ist eine mehrstufige Kette Jede Abfrage durchläuft: Problem verstehen → Vektorsuche → Ergebnisse sortieren → Kontext zusammenfügen → KI-Antwort generieren. Wenn eine Stufe langsam ist, ist das Ganze langsam. Die LLM-Inferenz macht 60-80 % der End-to-End-Zeit aus. ### Kosten steigen mit der Datenmenge Je mehr Dokumente, desto mehr Verarbeitung. Alle drei Glieder wachsen mit. **Gemeinsame Ursache: Dokumente müssen erst indiziert werden, bevor eine Abfrage möglich ist.** Das ist „search-centric" RAG. --- ## 2. Zwei gängige Lösungsansätze ### Ansatz 1: Vektordatenbank + statischer Index Dokumente werden zerkleinert, konvertiert und in der Vektordatenbank gespeichert. Bei einer Abfrage wird der ähnlichste Inhalt aus der Datenbank gesucht. **Stärken:** Massenhafte Dokumente, statischer Inhalt. **Schwächen:** Häufig wechselnder Inhalt, jede Bearbeitung erfordert eine Neuindizierung. ### Ansatz 2: Echtzeit-Datenstrom + ereignisgesteuert Datenänderungen lösen Aktualisierungen aus, der Index wird in Echtzeit synchronisiert. **Stärken:** Sekundenaktualität. **Schwächen:** Komplexe Infrastruktur, erfordert Caching-Schicht, Ereignismechanismus, doppelte Speicherschicht. ### Es gibt eine Klasse von Szenarien, die beide Wege nicht bedienen Ein Anwalt erstellt eine Zusammenfassung eines Falles. 200 Fallnotizen, 50 Gesetzesdokumente. Während des Schreibens sucht er immer wieder – „Wie wurde der Fall zur Wettbewerbsverbot argumentiert?" Nachdem er einen Absatz geschrieben hat, ändert er den Inhalt und sucht wenige Sekunden später erneut. Der neue Inhalt sollte bereits in den Suchergebnissen sein. Die Merkmale dieses Szenarios: **Inhalt ändert sich häufig** (keine statische Bibliothek), **Abfrage und Erstellung sind verwoben** (schreiben und gleichzeitig suchen), **der Benutzer ist ein normaler Mensch** (schreibt keinen Code, versteht keine Vektordatenbank), **Daten und Privatsphäre sind eine rote Linie**. **Dies ist keine Anforderung mit „höherer technischer Komplexität". Es ist eine Anforderung, bei der „der technische Ansatz nicht so schwergewichtig sein sollte".** --- ## 3. Von Search-centric zu Memory-centric Gängige Ansätze gehen davon aus, dass **die Wissensdatenbank statisch ist**. Eine Abfrage ist ein einmaliger Suchvorgang. Dieses Paradigma wird als **search-centric RAG** bezeichnet. Modell: Wissensdatenbank = Dokumentsammlung, RAG = intelligente Suche. Aber der Aufbau eines zweiten Gehirns erfordert ein anderes Paradigma. Du schreibst, änderst, löschst täglich Notizen und importierst neue Dokumente. Das Wissen wächst und entwickelt sich ständig weiter. Du möchtest, dass die KI nicht nur „sucht", sondern **dein Wissen kontinuierlich „behält" und bei Bedarf natürlich abruft.** Das ist **memory-centric RAG**. Modell: Wissensdatenbank = sich ständig weiterentwickelndes Gedächtnis, RAG = natürlicher Zugriff. | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | Verständnis von Wissen | Statische Dokumentsammlung | Sich ständig weiterentwickelndes Gedächtnis | | Datenaktualität | Abhängig von Indexaktualisierungsfrequenz | Echtzeit, nach dem Schreiben sofort gemerkt | | Abfragemethode | Aktive Suche | Natürliches Gespräch | | Beziehung zur Erstellung | Suche und Erstellung getrennt | Verflochten – Bearbeitung ist Gedächtnisaktualisierung | | Typische Szenarien | Unternehmenssuche, Policy-FAQs | Persönliches Wissensmanagement, zweites Gehirn | **Die beiden Paradigmen ersetzen sich nicht gegenseitig. Sie dienen völlig unterschiedlichen Szenarien.** Wie eine Suchmaschine und ein persönlicher Assistent. --- ## 4. Welche Architektur braucht Memory-centric RAG? Vier Anforderungen an die Architektur: **1. Keine Abhängigkeit von Vorab-Indizierung.** Jede Bearbeitung würde eine Neuindizierung erfordern, Echtzeit ist unmöglich. Das Abfragesystem muss die Daten mit dem Editor teilen – der Inhalt ändert sich, die nächste Abfrage spiegelt dies wider. **2. Minimaler Kontextverbrauch.** Notizen sind private Daten, sie können nicht vollständig hochgeladen werden. Aber die KI muss Informationen sehen, um antworten zu können. Balance: Nur die relevantesten Sätze übertragen, Fragmente komprimieren, nach der Übertragung löschen. **3. Beste Cloud-Modelle für die Generierung.** Der Benutzer hat keinen Aufwand, der Server sieht nur den minimalen Kontext. **4. Bearbeitung ist Gedächtnisaktualisierung.** Änderungen gehen sofort ins Gedächtnis ein, die nächste Abfrage spiegelt sie wider. --- ## 5. NoteRichs Memory-centric RAG-Praxis ### Notizen bleiben immer lokal, vollständige Daten werden nicht hochgeladen Notizen werden lokal im Browser gespeichert. Weder erlaubt (Kostenexplosion) noch sinnvoll (Benutzerprivatsphäre). ### Bei Abfragen wird nur der minimal notwendige Kontext übertragen Nur die relevantesten gefundenen Sätze, komprimierte Fragmente. Nach der Verarbeitung auf dem Server sofort gelöscht – keine Speicherung, keine Aufzeichnung, kein Training. **Ein geringer Upload ist unvermeidbar, ein vollständiger Upload ist vollständig vermeidbar.** ### Keine Vorab-Indizierung, Bearbeitung ist Gedächtnis Keine vorzeitige Erstellung einer Vektordatenbank. Während des Notizenschreibens ist das Abfragesystem bereits online. Inhaltsänderungen werden in Echtzeit widergespiegelt. ### Mehrdimensionale Bewertung + Satzgenauigkeit + Zustandsloser Server Nicht nur semantische Ähnlichkeit. Rückgabe auf Satzebene, Deduplizierung und Zusammenführung. Backend speichert nicht, zeichnet nicht auf, trainiert nicht. --- ## 6. Vier Ebenen des zweiten Gehirns **Ebene 1: Gedächtnis.** Die KI „erinnert" sich an alle geschriebenen Notizen. **Ebene 2: Unterstützung bei der Erstellung.** Generiert neue Inhalte basierend auf alten Notizen. **Ebene 3: Echtzeit-Feedback.** Nach dem Schreiben eines Absatzes nimmt die KI dies sofort wahr. **Ebene 4: Bearbeitung ist Gedächtnisaktualisierung.** Änderungen an KI-generierten Inhalten gehen sofort ins Gedächtnis ein. Der Wissenskreislauf schließt sich. --- ## 7. Grenzen anerkennen und dann überwinden ### Grenze 1: Die Leistungsgrenze des Browsers Die Online-Version läuft vollständig im Browser. Getestet mit Zehntausenden von Textdokumenten und zig Millionen Zeichen – sehr flüssig. **Bis zu einigen Hunderttausend Dokumenten problemlos, darüber hinaus Leistungseinbußen.** Das ist die physikalische Grenze des Browsers. Aber persönliche Benutzer erreichen diese Grenze fast nie. Falls doch – dann hast du Unternehmensanforderungen. In der Offline-Bereitstellungslösung läuft dieselbe Architektur auf dem Server und kann nach Bedarf skaliert werden. ### Grenze 2: Multimodale Unterstützung Derzeit Fokus auf Text. Bild-OCR, Audio-Transkription, Videoanalyse – die Online-Version ist durch die Rechenleistung des Browsers eingeschränkt. Die Offline-Bereitstellung für Unternehmen kann auf dem Server individuell integriert werden. **Textgedächtnis ist die Basis, multimodales Gedächtnis ist das Upgrade.** ### Grenze 3: Komplexe schlussfolgernde Abfragen über mehrere Dokumente Mehrschrittige Schlussfolgerungen sind eine Aufgabe der Generierungsphase, nicht der Abrufphase. Der Abruf ist nur für das „Finden" zuständig, nicht für das „Ableiten". NoteRich ermöglicht es Consumer-Modellen, durch hochwertigen Kontext praktische Ergebnisse zu erzielen. ### Grenze 4: Vollständig offline Top-große Modelle können nicht auf normalen Computern laufen – das ist ein physikalisches Gesetz. Die Offline-Bereitstellungslösung kann an lokal bereitgestellte Modelle des Unternehmens angebunden werden. --- ## 8. Offline-Lösung Kanzleien, Krankenhäuser, Finanzinstitute – Daten dürfen auf keinen Fall das interne Netzwerk verlassen. Die Offline-Bereitstellung verpackt die Memory-centric-Architektur als einzelnes Backend-Komponente, Ein-Klick-Bereitstellung, verlässt während des gesamten Prozesses nicht das Unternehmensnetzwerk. --- ## 9. Die ultimative Vision **Search-centric RAG löst das Problem des „Findens".** Memory-centric RAG löst das Problem des „Behaltens". Beide stehen nicht in Konkurrenz zueinander. NoteRich hat auf dem Weg des Memory-centric RAG lediglich einige direktere Entscheidungen getroffen. **Schnell, günstig, hochwertig.** Damit normale Menschen innerhalb von 30 Sekunden beginnen können, KI zur Wissensverwaltung zu nutzen, und Unternehmen ihr volles Vertrauen hinter die Firewall legen können. **[NoteRich testen →](https://noterich.com/app/)** *Open-Source-Konzeptprojekt [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*