Möchten Sie lokales RAG aufbauen?

• Skald wurde mit dem Ziel entwickelt, ein vollständig selbst hostbares RAG-System bereitzustellen, ohne Daten an Dritte zu senden
• Die RAG-Komponenten sind in Vektordatenbank, Embedding-Modell, LLM, Reranker und Dokumentparser unterteilt; für jedes Element werden Open-Source-Alternativen vorgestellt
• Der lokale Standard-Stack von Skald besteht aus Postgres+pgvector, Sentence Transformers, Docling und einem benutzerdefinierten LLM
• In den Benchmark-Ergebnissen wurde das Cloud-basierte Modell (Voyage+Claude) mit durchschnittlich 9,45 Punkten bewertet, das vollständig lokale GPT-OSS 20B mit 7,10 bis 8,63 Punkten
• Der Ansatz zeigt, dass sich leistungsfähiges RAG aufbauen lässt, ohne die Datenprivatsphäre aufzugeben

---

RAG-Komponenten und Open-Source-Alternativen

• Ein grundlegendes RAG besteht aus Vektordatenbank, Embedding-Modell und LLM; zusätzlich können Reranker und Dokumentparser enthalten sein
  • Jede Komponente kann statt durch SaaS durch lokale Alternativen ersetzt werden
• In der Beispieltabelle genannte Alternativen
  • Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
  • Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
  • LLM: GPT, Claude → Llama, Mistral, GPT-OSS
  • Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
  • Document Parsing: Reducto → Docling
• Skald zielt auf einen vollständig Open-Source-Stack ab und führt jede Komponente lokal aus

Aufbau des lokalen Stacks von Skald

• Vector DB: Einsatz von Postgres + pgvector
  • Lässt sich leicht in bestehende Infrastruktur integrieren und kann bis zu mehrere Hunderttausend Dokumente verarbeiten
• Vector Embeddings: Standardmäßig Sentence Transformers (all-MiniLM-L6-v2)
  • Nur für Englisch, mit ausgewogener Balance zwischen Geschwindigkeit und Retrieval-Leistung
  • Das Modell bge-m3 (mit Unterstützung für mehrere Sprachen) wurde ebenfalls getestet
• LLM: Keine Standardauswahl enthalten, wird vom Benutzer selbst betrieben
  • In den Tests lief GPT-OSS 20B auf EC2
• Reranker: Standardmäßig Sentence Transformers Cross-Encoder, als mehrsprachiges Modell ist unter anderem bge-reranker-v2-m3 nutzbar
• Document Parsing: Einsatz von Docling, ausgeführt über docling-serve

Performance- und Deployment-Ergebnisse

• Die Bereitstellung einer Skald-Produktionsinstanz einschließlich des gesamten Stacks dauerte 8 Minuten
  • Einschließlich Postgres, Embedding- und Reranking-Services sowie Docling
  • Das LLM läuft separat (mit llama.cpp)
• Der Testdatensatz bestand aus Inhalten der PostHog-Website (rund 2.000 Dokumente) und einem eigens erstellten Frage-Antwort-Set
• Experiment-Setup
  • Vector search topK=100, Reranking topK=50, Query rewriting=Off
  • Bewertet wurde mit Fokus auf Genauigkeit

Vergleich der Benchmark-Ergebnisse

• Voyage + Claude (Cloud-Konfiguration)
  • Durchschnittswert 9,45, alle Antworten korrekt
• Voyage + GPT-OSS 20B (teilweise lokal)
  • Durchschnittswert 9,18, überwiegend korrekt, aber teils mit fehlenden Informationen
• Vollständig lokal + GPT-OSS 20B
  • Standard-Englischmodell (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : Durchschnitt 7,10
    • Präzise bei englischen Anfragen, aber Schwächen bei mehrsprachigen, mehrdeutigen Anfragen und bei der Aggregation über mehrere Dokumente
  • Mehrsprachiges Modell (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : Durchschnitt 8,63
    • Verarbeitete portugiesische Anfragen erfolgreich, ließ bei der Aggregation über mehrere Dokumente aber teils Informationen aus
• Die wichtigste Einschränkung ist die integrierte Verarbeitung von Informationen, die über mehrere Dokumente verstreut sind
  • Cloud-Modelle gleichen dies mit hoher Leistung aus, in lokalen Umgebungen sind dafür jedoch zusätzliche Verfahren nötig

Nächste Schritte

• Skald plant, die Leistung von lokalem RAG weiter zu verbessern und Benchmarks für Open-Source-Modelle zu veröffentlichen
• Ziel ist es, eine Lösung für Unternehmen bereitzustellen, die AI-Tools in Air-Gap-Umgebungen betreiben müssen
• Wer mitmachen möchte, kann über GitHub(skaldlabs/skald) oder die Slack-Community zusammenarbeiten

[iolothebard]

Wer hat eigentlich in die Welt gesetzt, dass man für RAG eine Vektor-DB braucht …

[aer0700]

Ob Vektor-DB oder was auch immer: Eigentlich müsste es doch reichen, einfach nur die Suche zu implementieren ...

[dkmin]

Gemini:
Ja, die Verwendung einer Vektordatenbank (Vector Database) in RAG (Retrieval-Augmented Generation) hat ihre konzeptionelle Grundlage seit der ersten Veröffentlichung einschlägiger Arbeiten im Jahr 2020.
RAG kombiniert grundsätzlich Retrieval und Generation, wobei in diesem Retrieval-Schritt Vektor-Embeddings und eine Vektordatenbank, die diese effizient speichert und durchsucht, eine unverzichtbare Rolle spielen.
💡 Ausgangspunkt von RAG und Vector DB
Die Idee, dass RAG eine Vector DB benötigt, geht von den folgenden zentralen Arbeiten und Konzepten aus.

1. Die Entstehung von RAG: die Arbeit von Lewis et al. (2020)

• Titel der Arbeit: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"
• Kerngedanke: In dieser Arbeit wurden der Begriff und das Framework von RAG erstmals vorgestellt.
• Rolle des Retrievers: Das in der Arbeit vorgeschlagene RAG-Modell besteht aus Retriever und Generator. Der Retriever durchsucht große Datensätze wie Wikipedia nach zur Anfrage passenden Dokumenten (latent documents).
• Verwendung eines Vektorindex: Dieses frühe RAG-Modell nutzte zum Durchsuchen von Dokumenten einen Vektorindex (Vector Index) im Datensatz, damit ein vortrainierter Retriever (pretrained retriever) Dokumente abrufen konnte.
• Fazit: Da der zentrale Retrieval-Schritt von RAG die Ähnlichkeit auf Basis der Vektorrepräsentationen von Anfrage und Dokumenten berechnet, war das Konzept eines Vector Store oder Vektorindex für effiziente Suche implizit unverzichtbar.

2. Vektor-Embeddings und Ähnlichkeitssuche
   Der grundlegende Grund, warum eine Vektordatenbank zu einem wesentlichen Bestandteil von RAG geworden ist, ist folgender.

• Embedding: In einem RAG-System werden sowohl externes Wissen (Dokumente, Texte) als auch die Benutzeranfrage (Frage) in mathematische Repräsentationen namens Vektoren (Vector) umgewandelt. Diese Vektoren stellen die Bedeutung von Text als dichte Zahlenarrays in einem hochdimensionalen Raum dar.
• Similarity Search: Im Vektorraum bedeutet das Finden der Dokumentvektoren mit dem geringsten Abstand zum Anfragevektor, die semantisch relevantesten Dokumente zu finden.
• Rolle der Vector DB: Eine Vektordatenbank ist eine spezialisierte Datenbank, die eine große Anzahl solcher Dokumentvektoren speichert und für einen gegebenen Anfragevektor die ähnlichsten Vektoren schnell und effizient findet. Daher ist sie essenziell, um die Retrieval-Leistung von RAG zu maximieren.
  Zusammenfassung: Warum eine Vector DB nötig ist
  Damit ein LLM auf aktuelles oder domänenspezifisches Wissen zugreifen kann, das es nicht gelernt hat, muss es Informationen nicht über bloßes Keyword-Matching (traditionelle Suche), sondern auf Basis semantischer Ähnlichkeit finden. Die Vector DB ist eine zentrale Technologie, die sich deshalb auf natürliche Weise in das RAG-Framework integriert hat, um diese semantisch basierte Suche effizient auszuführen.

[aer0700]

Eigentlich braucht man für RAG vor allem eine Suchfunktion, und das Einbetten als dichte Vektoren, das Pushen in eine VectorDB und die Cosinus-Ähnlichkeitssuche sind nur eine von mehreren Möglichkeiten, eine Suchmaschine zu implementieren … Es gibt also keinen besonderen Grund, keine VectorDB zu verwenden, aber wenn man fragt, ob sie wirklich unverzichtbar ist, runzle ich doch etwas die Stirn, weil es viele Suchmaschinenalgorithmen gibt, die seit Langem gut im Einsatz sind.

[ztaka]

Weil es günstig ist und die meisten produktiven LLMs es verwenden.
Wenn man es genau nimmt, gilt das auch für Webserver: Wenn man Infrastruktur-Funktionen hinzufügt, ist alles komplett auf der Festplatte möglich, also braucht man auch kein DBMS, haha.

[gcback]

Es stimmt, dass man für eine Art Ähnlichkeits-/semantische Suche, bei der der Embedding-Wert (Vektor) der Benutzeranfrage als Key dient, eine Datenbank braucht. Und weil der Key die Form eines Vektors hat, ist eine Vektor-Datenbank ebenfalls passend.

[GN⁺]

Hacker-News-Kommentar

• Ich würde dazu raten, beim Aufbau solcher Systeme nicht auf Vektordatenbanken oder Embeddings zu fixiert zu sein
  Volltextsuche oder Tools wie grep/rg sind viel schneller und günstiger, und man muss keinen Index pflegen
  Wenn man einem guten LLM Suchwerkzeuge gibt, kann es selbst Queries wie „dog OR canine“ erzeugen und iterativ verbessern
  Außerdem muss man so das Chunking-Problem gar nicht erst lösen

  • Ich habe eine kleine App gebaut, die im Browser den Unterschied zwischen embeddingbasierter („semantischer“) und BM25-Suche zeigt
    Zu sehen unter Search Sensei
    Beim ersten Laden werden etwa 50 MB Modellgewichte und die ONNX-Runtime heruntergeladen, danach läuft es flüssig
    BM25 versteht zum Beispiel nicht, dass „j lo“ und „jlo“ Jennifer Lopez meinen, während embeddingbasierte Suche mit solchen Tippfehlern oder Aliasen gut umgehen kann
    Gesucht wird in 1.000 Nachrichtenartikeln aus den Jahren 2016 bis 2024
  • Laut der Studie zu Anthropics contextual retrieval lieferte die Kombination Embeddings + BM25 die besten Ergebnisse
    Schade ist allerdings, dass die Leistung von BM25 allein nicht veröffentlicht wurde
    In meinen kleinen Tests gab es Fälle, in denen Embeddings Seiten übersehen haben, auf denen die Query-Wörter wörtlich vorkamen — am Ende gewinnt Ctrl+F
  • Meiner Erfahrung nach versteht man semantische vs. lexikalische Suche am besten als Trade-off zwischen Präzision (precision) und Recall
    Lexikalische Suche hat hohe Präzision, aber niedrigen Recall, semantische Suche liegt auf der entgegengesetzten Seite
  • In Google Maps hatte ich beim Suchen nach „billiards“ ein Synonymproblem: Es kamen nur Ergebnisse zu Swimmingpools und Ziegen
    Ich hatte das Gefühl, dass ein „NOT“-Operator mehr helfen würde. Ich möchte über RAG auch noch mehr lernen
  • Ich frage mich, ob man bei solcher Suche einen Standard-Prompt verwendet
    Ich habe gesehen, dass einige agentische Tools solche Queries automatisch erzeugen, weiß aber nicht, ob das promptgesteuert ist oder Standardverhalten

• Einer der Gründe für die schwache Leistung könnte fehlendes semantisches Chunking sein
  Wenn man das gesamte Dokument einbettet, vermischen sich mehrere Konzepte und die Genauigkeit sinkt
  Man sollte mit Tools wie Spacy nach Bedeutungseinheiten aufteilen, dann zusätzlichen Kontext dazugeben, an welcher Stelle im Dokument sich jeder Chunk befindet, und erst dann einbetten
  Der Ansatz aus Anthropics contextual retrieval war in RAG-Systemen sehr effektiv
  Für die Kontexterzeugung reicht ein GPT OSS 20B-Modell

  • Nicht der Autor, aber wir machen bereits semantisches Chunking
    Es gab wohl ein Missverständnis, weil wir mit Fragen getestet haben, die den Kontext aus mehreren Dokumenten aggregieren müssen

• Ich frage mich, warum semantische Suche als überlegen gegenüber lexikalischer Suche vorausgesetzt wird
  Als ich 2023 mit Tantivy (BM25) verglichen habe, war der Unterschied in den Ergebnissen minimal
  Selbst wenn es etwas mehr Recall gibt, weiß ich nicht, ob sich dieser komplexe Aufbau lohnt

  • Das hängt von der Art der Tests ab
    In Entwickler-Tests lagen wir bei 90 % Recall, bei echten Nutzertests fiel das aber auf etwa 30 %
    Nutzer kennen die exakten Begriffe in der Dokumentation nicht, daher reicht rein lexikalische Suche nicht aus
    Man kann einen Agenten darüberlegen, aber dadurch steigt die Latenz, was die Nutzerzufriedenheit senkt
  • Das hängt vom Charakter der App ab
    Bei Wanderfugl findet semantische Suche auch Stellen gut, die einen niedrigen BM25-Score haben
    Am Ende könnte hybrides Ranking die Antwort sein
  • Ein Vorteil ist, dass sich Queries wie „ein Gespräch zwischen zwei Wissenschaftlern“ verarbeiten lassen
    Letztlich hängt es vom Anwendungsfall ab

• Ich suche ein Open-Source-Tool, mit dem man lokal und offline alle Daten aus E-Mails, Slack, GDrive, Code, Wiki usw. abfragen kann
  Ich möchte ungern selbst etwas bauen oder stark anpassen; gute Defaults und Modell-Empfehlungen wären ideal

  • Deshalb habe ich einen Nextcloud-MCP-Server gebaut
    GitHub-Link
    Er unterstützt grundsätzlich CRUD und bettet Dokumente oder Notizen ein, wenn man Vektorsuche aktiviert
    Ollama und OpenAI werden als Embedding-Anbieter unterstützt
    Der MCP-Server bietet sowohl semantische + BM25-Suche (qdrant fusion) als auch Antwortgenerierung über MCP Sampling
    Der Server selbst generiert keine Antworten und lässt sich mit jedem LLM-/MCP-Client verbinden
    Dieses MCP-Sampling/RAG-Muster ist sehr leistungsfähig, und es ist gut möglich, dass verallgemeinerte Open-Source-Versionen auch für andere Datenquellen erscheinen

• Das Tool, das wir verwenden, ist haiku.rag
  Es bietet entwicklerfreundlichen Python-Code, eine auf pydantic-ai basierende Struktur, Benchmarks und erweiterte Zitierfunktionen
  Es unterstützt Deep-Research-Agenten und ist ein echtes Open-Source-Projekt, das langfristig gepflegt wird

• Als Standard-Embedding-Modell verwenden wir Sentence Transformers (all-MiniLM-L6-v2), haben aber gemerkt, dass es nur für Englisch gedacht ist und beim Aufbau eines deutschen RAG problematisch sein könnte
  Mich würde interessieren, wie gut nicht-englische Modelle abschneiden

  • Dafür kann man das MTEB-Leaderboard heranziehen
    Relevant sind im Abschnitt „Retrieval“ die Einträge RTEB Multilingual oder RTEB German
    Wenn man CPU-basiert selbst hostet, sollte man am besten nach Modellen mit unter 100 Mio. Parametern filtern
  • Viele Modelle zeigen bei nicht-englischen Sprachen einen Leistungsabfall
    Deutsch hat aber vergleichsweise viele Trainingsdaten, und es gibt ausreichend mehrsprachige Modelle
    Vor allem kommerzielle API-basierte Modelle unterstützen meist mehrere Sprachen
  • Wir haben früher ebenfalls ein mehrsprachiges Embedding-Modell verwendet
    Das zugehörige Paper findet sich hier: Springer-Link

• Zur Zeit von GPT-4 (8K context) habe ich ein Skript gebaut, das ganze Bücher in Chunks zerlegt und in GPT-4 steckt, um relevante Passagen zu finden
  Damals kostete eine Suche etwa 1 Dollar, heute ist das deutlich günstiger
  Auch im Artikel zu Anthropics contextual retrieval heißt es, dass man Dokumente, wenn sie vollständig in den Kontext passen, besser einfach direkt hineingibt statt RAG zu verwenden
  Mit längerem Kontext sinkt allerdings die Qualität, und auch Kosten und Geschwindigkeit werden zum Problem
  Heute kann man ein ganzes Buch für etwa 1 Cent in den Kontext legen

• Der schwierigste Teil bei RAG ist das Parsen von Dokumenten
  Mit reinem Text geht es noch, aber bei Tabellen, mehrseitigen Tabellen, Diagrammen, Inhaltsverzeichnissen oder Fußnoten bricht die Genauigkeit stark ein
  Um das zu verbessern, gibt es Ansätze wie das RAPTOR-Muster, bei denen ein LLM Inhalte zusammenfasst und Fragen dazu formuliert, bevor sie in der Vektor-DB gespeichert werden
  Aber eine universelle RAG-Pipeline, die in allen Fällen funktioniert, bleibt weiterhin schwierig

  • Als Anfänger bei Vektor-Embeddings wusste ich nicht, dass Tabellen so große Probleme verursachen
    Mich würde auch interessieren, ob Vektor-DBs mit langen Textgruppen oder mit Tabellenformaten besser zurechtkommen

• Diese neue Perspektive auf Volltextsuche in RAG fand ich interessant
  Besonders die Einblicke in agentische Tool-Loops und den Umgang mit Fuzzy Search haben Eindruck gemacht

• Ich frage mich, ob es für solche Systeme standardisierte Evaluierungs-Datensätze gibt
  Es wäre gut, Benchmarks mit Dokumenten- und Fragensätzen zu haben, bei denen bestimmte Dokumente oder Chunks als relevanteste Ergebnisse erscheinen sollten

  • Dafür kann man sich die haiku-rag-Benchmarks und Evaluierungs-Sets ansehen