Ask HN: Wie implementiert ihr RAG lokal?

• Auf Hacker News fragt ein Nutzer, wie andere Retrieval-Augmented Generation (RAG) in einer lokalen Umgebung implementieren
• Bei lokalem RAG zeigt sich deutlich die Tendenz, dass es auch ohne Vektor-DB mit Textsuche wie SQLite FTS5, BM25 oder grep gut funktioniert
• Für die Codesuche berichten viele aus Erfahrung, dass Embeddings langsam sind und viel Rauschen erzeugen; mehrere Stimmen halten keyword-basierte Ansätze wie BM25 + Trigramme für besser
• Selbst wenn Vektorsuche benötigt wird, lösen viele das mit leichtgewichtigen Setups wie Postgres + pgvector, dem Speichern von Vektor-BLOBs in SQLite oder dem Laden von FAISS in den Speicher
• Die Suchqualität lässt sich durch hybride Suche aus BM25 + Vektoren sowie Kombinationen wie RRF (Reciprocal Rank Fusion), Reranking und Multi-Query-Expansion verbessern
• Statt RAG pauschal mit einer Vektor-DB gleichzusetzen, zeigt sich eine Tendenz zur Auswahl je nach Dokumenttyp, Größenordnung und Betriebsaufwand: einfache Suche → hybrid → agentisch

---

Gemeinsame Schlussfolgerungen zur Suchphase

• Viele gehen nicht von der Voraussetzung aus, dass eine Vektor-DB oder ein Graph zwingend nötig ist, sondern starten möglichst einfach passend zu bestehender Infrastruktur, Dateitypen und Leistungsanforderungen
• Es wird erwähnt, dass agentische Ansätze, bei denen ein Agent direkt Dateisystem oder APIs abfragt, bei Einrichtung und Wartung einfacher sind, aber etwas langsamer sein können
• Die Einsicht, dass „RAG dem LLM nur kurze Textausschnitte aus Suchtreffern übergibt“, verlagert den Fokus für Performance-Verbesserungen auf die Suchqualität
• Zur „Definition von RAG“ gibt es sowohl die Reaktion, dass retrieval + generation auch ohne Vektor-DB bereits RAG ist, als auch die Ansicht, dass der Begriff üblicherweise oft mit einer Vektor-DB verbunden wird

Embedding-Modelle und Vektorsuche

• Das bei MongoDB entwickelte Embedding-Modell mdbr-leaf-ir läuft nur auf der CPU und erreichte in mehreren Leaderboards für diese Modellgröße Platz 1
  • Auf einem Standardserver mit 2 vCPUs lassen sich etwa 22 Dokumente pro Sekunde und 120 Queries pro Sekunde verarbeiten
  • Im BEIR-Benchmark erreicht es 53,55 Punkte (all-MiniLM-L12-v2: 42,69 Punkte)
• Statische Wort-Embeddings wie model2vec/minish sind bei der Inferenz schneller, liefern aber geringere Suchgenauigkeit
  • Da nur Tokenisierung + Lookup-Tabelle + Mittelwertbildung ausgeführt werden, sind sie schneller als transformerbasierte Modelle
• Genutzt wird auch ein Ansatz, bei dem mit Meta-Llama-3-8B pro Text-Chunk Vektoren erzeugt, in einer SQLite-BLOB-Spalte gespeichert und dann mit FAISS durchsucht werden
  • Bei 5 Millionen Chunks werden rund 40 GB Speicher benötigt
  • faiss-gpu ist auf einer A6000 sehr schnell; faiss-cpu auf einem M1 Ultra ist langsamer, reicht aber für einige Queries pro Tag aus

Empfehlungen zur Codesuche

• Für Code wird eher von Vektor-Datenbanken abgeraten; empfohlen wird die Kombination BM25 + Trigramme
  • Embeddings sind langsam und für Code ungeeignet
  • Ohne Reranker entsteht viel Rauschen, und die Reindexierung von Dateien ist aufwendig
  • Die Suchantworten sind schnell und die Ergebnisqualität hoch
• In PostgreSQL lässt sich BM25-Suche mit plpgsql_bm25 umsetzen
  • Unterstützt auch hybride Suche in Kombination mit pgvector sowie Reciprocal Rank Fusion
• Gute Ergebnisse sind möglich, wenn auf Dateipfade + Signaturen Embeddings angewendet und diese dann mit BM25 fusioniert werden
• Effektiv ist auch ein agentischer Ansatz, bei dem gpt-oss 20B zusammen mit ripgrep in einer while-Schleife läuft

Datenbankbasierte Lösungen

• SQLite FTS5: gut geeignet für dokumentbasierte Markdown-Dateien; RAG ist auch ohne Vektor-DB möglich
  • Jedes File erhält ein kurzes Beschreibungsfeld, und die Dokumente werden per Keyword-Suche durchsucht
  • Möglich ist auch ein Design, bei dem fp16-Vektoren als BLOB in SQLite gespeichert werden, zunächst per Filter eine Teilmenge gebildet wird und die Ähnlichkeitsberechnung dann im Speicher erfolgt
  • Weitere Optionen sind sqlite-vec, sqlite-vector, vec0 und bm25 in SQLite
  • „SQLite funktioniert erstaunlich gut“
• PostgreSQL + pgvector: vorhandenes Postgres-Wissen lässt sich weiterverwenden, und die Übergabe an Betriebsteams ist einfacher
  • Es gibt auch die Bibliothek llmemory, die hybrides BM25, Multi-Query-Expansion und Reranking unterstützt
• LanceDB: als eingebettete Vektor-DB komfortabel nutzbar
  • Wird zusammen mit Ollamas Embedding nomic-embed-text verwendet
• DuckDB: bietet Erweiterungen für Vektor-Ähnlichkeitssuche und eignet sich für kleine Projekte unter 3 GB
• Meilisearch, Typesense, Manticore: betrieblich einfacher als Elasticsearch/OpenSearch

Hybride und agentische Suche

• nori(usenori.ai): kombiniert semantische und wortbasierte Suche mit SQLite + vec0 + fts5
• Turbopuffer: unterstützt hybride Suche aus Vektoren + BM25
• Schon die Kombination aus agentischer Suche und Textsuche liefert recht gute Ergebnisse
  • Durch zusätzliche Vektorsuche und Graph-RAG sind leichte Verbesserungen bei Geschwindigkeit und Qualität möglich
• Claude Code/Codex verwendet intern ripgrep
• Auch Embeddings auf Dateipfaden sind wirksam; mit BM25 fusioniert verbessert sich das Ergebnis weiter

Praxisbeispiele für BM25

• shebe: CLI/MCP-Tool zum Indexieren und Durchsuchen von Codebasen auf Basis von BM25
  • Besonders nützlich in Refactoring-Workflows (z. B. zum Auflisten aller Stellen, die bei einem Istio-Upgrade geändert werden müssen)
• In 85 % der Fälle reicht Matching über Tags auch ohne Vektor-DB aus
  • Betreiber fügen sowohl Eingaben als auch Dokumenten Tags hinzu und erreichen so 100 % Matching
• Nach Ansicht einiger sind die meisten Vektor-DBs ein „Hammer für das Problem, etwas nicht finden zu können“

Spezielle Tools und Bibliotheken

• qmd: CLI-Tool zum Durchsuchen von Markdown-Dateien; liefert bessere Fuzzy-Query-Ergebnisse als fzf
• ck: semantisches grep-Tool auf Rust-Basis
• Kiln: Dateien per Drag-and-drop hinzufügen und verschiedene Konfigurationen vergleichen
  • Unterstützt den Vergleich von Extraktionsmethoden, Embedding-Modellen und Sucharten (BM25, hybrid, Vektor)
  • Mit Funktionen zur Bewertung der Suchgenauigkeit und zur automatischen Erzeugung von Evaluierungsdatensätzen
• libragen: CLI/MCP-Server zum Erzeugen versionsverwalteter RAG-Content-Bibliotheken
  • Kann GitHub-Repositories in RAG-Datenbanken umwandeln
• piragi: einfache Python-RAG-Bibliothek mit Unterstützung für verschiedene Quellen wie lokal/S3/API
• ragtune: CLI-Tool zum Debugging und Benchmarking lokaler RAG-Suche

Dokumentverarbeitung und OCR

• discovery: Dokument-OCR mit Qwen-3-VL-8B, Vektorspeicherung mit ChromaDB
  • Implementiert hybrides RAG aus BM25 + Embeddings
• docling: Tool zur Dokumentextraktion, das in mehreren RAG-Projekten eingesetzt wird
• Bei der PDF-Konvertierung sind Tabellen, mehrspaltige Layouts und tabellenübergreifende Seiten schwierig zu verarbeiten
  • Das OCR-Modell von Mistral liefert die besten Ergebnisse (proprietäres Modell)

Speicher- und Kontextverwaltung

• RAG übergibt an das LLM nur kurze Strings aus Suchtreffern
  • Bei kleinen Modellen liegt die Grenze oft bei etwa TOP_K=5; darüber hinaus tritt Kontextvergessen auf
• Verbesserungen sind möglich, indem Dateien und Ordner vorab zusammengefasst werden
• Verwendet wird auch ein Ansatz, bei dem mit Sonnet + 1M-Kontextfenster einfach der gesamte Inhalt in den Kontext gelegt wird
• Es gibt ein Beispiel für ein Memory-System für Claude Code auf Basis semantischer Suche über Session-Dateien

Enterprise- und großskalige Nutzung

• Bei 300.000 Kundeninteraktionen pro Tag sind Latenz und Präzision entscheidend
  • Verwendet wird ein hybrider Ansatz aus Embeddings + Volltextsuche + IVF-HNSW
  • Eine Herausforderung ist das Management der Informationsverbreitung über rund 600 verteilte Systeme
• Mit einem KAG-Ansatz (Knowledge Augmented Generation) wird experimentell versucht, Business-Regeln zu mappen
• Für mehr als 500.000 Nachrichtenartikel wurde erfolgreich ein vollständig lokales RAG mit einer Postgres-Vektor-DB umgesetzt

Weitere Tools und Ansätze

• AnythingLLM: enthält ein gebündeltes Vektor-DB-Setup für Dokumente
• LibreChat: enthält ebenfalls ein gebündeltes Vektor-DB-Setup für Dokumente
• ChromaDB: wird als Obsidian-Erweiterung für semantische/hybride Suche verwendet
• SurrealDB: wird in Kombination mit lokaler Vektorisierung eingesetzt
• OData-Query-Interface: wirksam, wenn es dem LLM als Tool bereitgestellt wird; kann die Analyse von Excel-Dateien mit 40.000 Zeilen ermöglichen
• Nextcloud MCP Server: verwendet Qdrant als Vektor-DB und bietet semantische Suche über persönliche Dokumente
• LSP (Language Server Protocol): wurde zu Claude Code hinzugefügt, weist derzeit aber Bugs auf
  • TreeSitter könnte nützlicher sein (Abruf per Symbolname, Navigation zu Definitionen/Verwendungen)

[GN⁺]

Hacker-News-Kommentare

• Unser Team betreibt eine Q&A-Datenbank.
  Fragen und Antworten werden sowohl mit Trigramm-Indizes als auch mit Embeddings indexiert und in Postgres gespeichert.
  Bei der Suche verwenden wir pgvector zusammen mit Trigramm-Suche und führen die Ergebnisse über einen Relevanz-Score zusammen.

• Für die Retrieval-Phase haben wir ein CPU-freundliches, hocheffizientes Text-Embedding-Modell entwickelt.
  Es handelt sich um das Modell MongoDB/mdbr-leaf-ir, das unter Modellen derselben Größe Platz 1 auf dem Leaderboard belegt.
  Es ist kompatibel mit Snowflake/snowflake-arctic-embed-m-v1.5.
  Über die search-sensei-Demo kann man semantische Suche vs. BM25 vs. hybrid vergleichen.
  Zum Beispiel erkennt das Embedding-Modell, dass „j lo“ „Jennifer Lopez“ bedeutet.
  Außerdem haben wir das Trainingsrezept veröffentlicht, und das Training ist auch mit durchschnittlicher Hardware problemlos möglich.

  • Mich würde interessieren, wie sich die Embedding-Geschwindigkeit und der Recall dieses Modells im Vergleich zu statischen Wort-Embeddings wie minish oder model2vec verhalten.

• Ich erzeuge seit April 2024 Vektoren mit Meta-Llama-3-8B.
  Ich habe Python und Transformers auf einer RTX-A6000 verwendet; schnell, aber mit viel Lärm und Hitzeentwicklung.
  Danach bin ich auf einen M1 Ultra umgestiegen und nutze Apples MLX-Bibliothek; ähnlich schnell, aber deutlich leiser.
  Das Llama-Modell hat 4k Dimensionen, also 8 KB pro Chunk bei fp16, und ich speichere das mit numpy.save() in einer BLOB-Spalte von SQLite.
  Bei der Suche lade ich alle Vektoren aus SQLite, wandle sie in ein numpy.array um und suche dann mit FAISS.
  faiss-gpu auf der RTX6000 ist extrem schnell, und faiss-cpu auf dem M1 Ultra ist für meinen Anwendungsfall (ein paar Queries pro Tag) ebenfalls schnell genug.
  Bei 5 Millionen Chunks liegt der Speicherverbrauch bei etwa 40 GB, was beide Systeme problemlos handhaben können.

• Die meisten komplexeren Dokumente sind Markdown-Dateien.
  Ich empfehle das einfache CLI-Tool tobi/qmd.
  Früher hatte ich einen auf fzf basierenden Workflow, aber dieses Tool bietet bessere Fuzzy-Suche.
  Für Code-Suche nutze ich es nicht.

  • Nach der Vorstellung dachte ich, es sei ein in golang geschriebenes grep-Ersatztool, und hatte Funktionen wie eine Gewichtung von Markdown-Überschriften erwartet.

• Für Code-Suche wird empfohlen, keine Vektordatenbank zu verwenden.
  Embeddings sind langsam und für Code ungeeignet.
  Die Kombination BM25 + Trigramm liefert bessere Ergebnisse und reagiert auch schneller.

  • Auch in Postgres ist hybride Suche möglich.
    Siehe das Projekt plpgsql_bm25.
    Es enthält Beispiele und Jupyter-Notebooks, in denen BM25 und pgvector mit Reciprocal Rank Fusion kombiniert werden.
  • Dem stimme ich zu. Ich habe früher hybride Suche in einem grep-Ersatztool ausprobiert, aber das ständige Reindexieren war lästig.
    Wenn man kein speziell für Code ausgelegtes Modell verwendet, erzeugt die Vektorsuche viel Rauschen.
    Inzwischen ist es viel schneller und genauer, gpt-oss 20B in einer Schleife zusammen mit ripgrep laufen zu lassen.
  • Ich frage mich, ob jemand einen einfachen Service oder ein Docker-Image kennt, das BM25 und Vektorsuche zusammen anbietet.
  • Bei Dateipfaden oder Signaturen habe ich gute Ergebnisse erzielt.
    In Kombination (Fusion) mit BM25 wird es noch besser.
  • Mich interessiert, wie ihr den Einsatz von RAG für Dokumentensuche seht.

• Für lokale RAG-Experimente habe ich local-LLM-with-RAG gebaut.
  Die Embeddings werden mit Ollamas „nomic-embed-text“ erzeugt, und LanceDB dient als Vektor-DB.
  Kürzlich habe ich es auf „agentic RAG“ aktualisiert, aber für kleine Projekte könnte das übertrieben sein.

  • Ich mache etwas Ähnliches. Ich verwende lance-context, eine deutlich einfachere Version.
  • Danke, dass du erklärt hast, wofür „RAG“ steht. Beim Lesen dieses Threads war ich verwirrt.

• Ich speichere fp16-Vektoren als BLOB in SQLite, lade sie nach dem Filtern in den Speicher und berechne die Ähnlichkeit per Matrix-Vektor-Multiplikation (matvec).
  Wenn numpy oder torch Multithreading/BLAS/GPU nutzen, ist das sehr schnell.
  Falls es zum Flaschenhals wird, plane ich eine Migration zu sqlite-vector.
  Da sich die Datenmenge durch Filter wie Datum oder Ort stark reduziert, ist das effizient.
  Das Backend ist hinter einer austauschbaren Schnittstelle verborgen.

• 95 % meiner Dokumente sind kleine Markdown-Dateien, daher verwende ich mit SQLite FTS5 einen normalen Volltext-Suchindex.
  Den Index hatte ich ohnehin schon und habe ihn einfach direkt an einen mastra agent angeschlossen.
  Jede Datei hat ein kurzes Beschreibungsfeld; nach der Keyword-Suche lade ich das vollständige Dokument, wenn die Beschreibung passt.
  Die Einrichtung hat etwa eine Stunde gedauert und funktioniert sehr gut.

  • Eigentlich ist genau das RAG (Retrieval-Augmented Generation).
    Embedding-basierte Suche ist zwar verbreiteter, aber im Kern ist es dasselbe.

• Wir kennen uns gut mit Postgres aus und haben deshalb mit PGVector angefangen.
  Später haben wir festgestellt, dass unser Inhalt zu 100 % zu den halbstrukturierten Feldern im Prompt passt.
  Das lag daran, dass die Operatoren begonnen hatten, sowohl Eingaben als auch Dokumente mit Tags zu versehen (etwa 50 Dokumente).
  Deshalb durchsuchen wir zuerst die Felder, fügen die passende Datei in den Prompt ein und führen erst danach die Embedding-Suche aus.
  Im Ergebnis braucht man in 85 % der Fälle keine Vektordatenbank.

  • Die meisten Vektor-DBs wirken wie ein Hammer auf der Suche nach einem Problem.

• Ich habe llmemory entwickelt und nutze es sowohl lokal als auch in unseren Firmen-Apps.
  Es basiert auf PostgreSQL + pgvector und bietet hybrides BM25, Multi-Query-Expansion und Reranking.
  Ich veröffentliche es gerade erst, daher kann es noch ein paar Bugs geben.
  Mit der Performance bin ich ziemlich zufrieden.

[ryj0902]

Wenn ich die Leistung unseres primitiven internen RAG-Systems sehe und dann so einen Post lese, ändert sich meine Perspektive tatsächlich Stück für Stück.

[tensun]

Ich bin mir nicht sicher, ob Koreanisch gut unterstützt wird.