- 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)
Noch keine Kommentare.