Ollama Embedding in der Praxis: Lokale Vektorsuche und RAG aufbauen

Durch über 200 PDF-Dokumente auf dem Rechner blättern, um Details eines vor sechs Monaten gelesenen Technikkonzepts zu finden. Stichwortsuche? Nutzlos – Sie erinnern sich an die Bedeutung, nicht an die exakten Formulierungen. Fast eine Stunde später hatten Sie es – und dachten: Wäre da nur ein Tool, das semantisch sucht.

Noch unangenehmer: Diese Dokumente betreffen interne Unternehmensarchitektur. In die Cloud für Vektorsuche? Undenkbar. Datenschutz ist nicht verhandelbar.

Ollamas Embedding-Funktion löst genau dieses Problem. Lokal ausführen, Daten bleiben drinnen, semantische Suche möglich. Nach ein paar Tagen Tests mit mxbai, nomic und Qwen3 Embedding plus Vektordatenbank-Vergleich: Die Fallstricke sind real – falsches Modell bedeutet schlechtes Retrieval, zu kleine Datenbank später mühsame Migration.

Dieser Artikel fasst die Erfahrungen zusammen. Nach dem Lesen bauen Sie ein lokales RAG-System – von der Dokumentverarbeitung bis zur semantischen Suche, mit vollständigem Code.

Ollama Embedding-Modelle im Überblick

Ollama unterstützt mehrere Embedding-Modelle – am Anfang wusste ich nicht, welches passt. Die Doku behauptet, mxbai übertrifft OpenAI text-embedding-3-large – klingt beeindruckend, aber wie gut ist es wirklich? Nach Tests hier die direkte Antwort.

Zuerst die Vergleichstabelle:

mxbai-embed-large nutze ich am häufigsten. Warum? Einfach, stabil. 1024 Dimensionen reichen in den meisten Szenarien. Auf der MTEB (Massive Text Embedding Benchmark)-Liste weit vorne – tatsächlich etwas besser als OpenAI text-embedding-3-large. Für Dokumentensuche, Code-Suche und ähnliches: solide Wahl.

nomic-embed-text punktet mit 8192 Tokens Kontext. Ganze Artikel oder lange Chat-Protokolle? Dann relevant. Kleiner (274M), schneller als mxbai. 768 Dimensionen – theoretisch etwas schwächer in der Semantik. In Tests: bei Kurztexten kaum Unterschied, bei Langtexten nomic oft besser.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Qwen3 Embedding von Alibaba, April 2026. Chinesische Texte liefern spürbar bessere Treffer – „verteiltes Fehlertoleranz-Design” und „Fault-Tolerance-Design” matchen, mxbai hakt da eher. Primär chinesische Inhalte? Qwen3 testen.

Empfehlung: Einsteiger starten mit mxbai. Langtext → nomic. Chinesisch → Qwen3. Alle drei in einer halben Stunde testen – gemessene Qualität zählt.

Leitfaden zur Vektordatenbank-Auswahl

Modell steht – wo speichern? Vektordatenbank-Wahl birgt mehr Fallstricke als die Modellwahl. Zu klein: spätere Skalierung schmerzhaft. Zu groß: Ressourcenverschwendung. Drei gängige Optionen im Vergleich:

ChromaDB ist meine Einstiegsempfehlung. Installation: pip install chromadb. Freundliche API – Speichern und Abfragen in wenigen Zeilen. HNSW-Index (Hierarchical Navigable Small World), für kleine Datenmengen schnell genug. Nachteil: Single-Machine, ab ca. 100.000 Einträgen Performance-Einbruch.

FAISS – Meta-Open-Source-Klassiker. Reines C++, wirklich schnell. Bei 500.000 Einträgen blieb die Latenz im Millisekundenbereich. Eher Vektor-Suchbibliothek als vollständige Datenbank – Speicher und Index selbst verwalten. Für Tüftler oder Performance-kritische Szenarien.

Milvus zielt auf Produktion: verteilte Bereitstellung, Persistenz, mehrere Indextypen, Cloud-Variante (Zilliz Cloud). Konfiguration aufwendiger, höhere Deploy-Kosten. Millionen Datensätze, High Availability, Team-Betrieb – dann lohnt sich der Aufwand.

Strategie: Persönliche Experimente → ChromaDB, schnell lauffähig. Forschung, Performance → FAISS. Produktion → Milvus oder Cloud. Nicht auf spätere Migration von ChromaDB zu Milvus setzen – Formate und APIs unterscheiden sich, Migration ist teuer.

Vollständiger RAG-Workflow in der Praxis

Theorie reicht nicht – hier der komplette lokale RAG-Code: PDF bis semantische Suche mit Ollama + ChromaDB.

Umgebung vorbereiten

Abhängigkeiten installieren:

pip install ollama chromadb langchain langchain-community pypdf

Ollama muss laufen, Modelle heruntergeladen:

ollama pull mxbai-embed-large
ollama pull qwen2.5:7b  # für Antwortgenerierung

Code-Implementierung

import ollama
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
import chromadb

# 1. PDF laden
loader = PyPDFLoader("./your_document.pdf")
docs = loader.load()

# 2. Dokument chunken – chunk_size beeinflusst Retrieval-Qualität stark
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,      # 800 Zeichen pro Chunk
    chunk_overlap=100,   # 100 Zeichen Überlappung, Grenzinformationen erhalten
)
chunks = splitter.split_documents(docs)

# 3. Embeddings generieren und in ChromaDB speichern
client = chromadb.Client()
collection = client.create_collection("my_docs")

for i, chunk in enumerate(chunks):
    response = ollama.embed(
        model="mxbai-embed-large",
        input=chunk.page_content,
    )
    embedding = response["embeddings"][0]

    collection.add(
        ids=[str(i)],
        embeddings=[embedding],
        documents=[chunk.page_content],
        metadatas=[{"source": chunk.metadata.get("source", "unknown")}],
    )

print(f"{len(chunks)} Dokumentfragmente gespeichert")

# 4. Semantische Suche
query = "Was ist die Fehlertoleranz in verteilten Systemen?"
query_embedding = ollama.embed(
    model="mxbai-embed-large",
    input=query,
)["embeddings"][0]

results = collection.query(
    query_embeddings=[query_embedding],
    n_results=3,  # 3 relevanteste Fragmente
)

# 5. Antwort aus Retrieval-Ergebnissen generieren
context = "\n\n".join(results["documents"][0])
response = ollama.chat(
    model="qwen2.5:7b",
    messages=[
        {
            "role": "system",
            "content": "Beantworten Sie Fragen auf Basis der folgenden Dokumentinhalte. Wenn keine relevanten Informationen vorhanden sind, sagen Sie das ehrlich.",
        },
        {"role": "user", "content": f"Dokumentinhalt: {context}\n\nFrage: {query}"},
    ],
)

print(f"Antwort: {response['message']['content']}")

Ausprobieren lohnt sich. Der Ablauf ist überschaubar: Chunking → Vektoren → Speichern → Abfrage → Antwort zusammenstellen.

Typische Fallstricke:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Erstens: chunk_size nicht willkürlich setzen. Bei 200 Zeichen pro Chunk lieferte die Suche Fragmente ohne zusammenhängende Antworten. 500–1000 Zeichen ist meist stabil.

Zweitens: Batch-Verarbeitung. Bei vielen Dokumenten wird Einzelaufruf der Ollama API langsam. Batches bündeln:

# Batch-Embeddings – deutlich schneller
batch_texts = [chunk.page_content for chunk in chunks[:50]]
batch_embeddings = ollama.embed(
    model="mxbai-embed-large",
    input=batch_texts,
)["embeddings"]

Drittens: Ähnlichkeitsschwelle. ChromaDB liefert standardmäßig n_results Treffer – auch irrelevante. Filter nach Distanz:

# Nach Distanzschwelle filtern
results = collection.query(
    query_embeddings=[query_embedding],
    n_results=10,
)
# Nur Ergebnisse mit Distanz < 0,3 (kleiner = ähnlicher)
filtered = [
    doc for doc, dist in zip(results["documents"][0], results["distances"][0])
    if dist < 0.3
]

Nach diesem Code haben Sie Ihr lokales RAG. PDF und query anpassen – der Rest bleibt.

Performance-Tuning und Praxisempfehlungen

System läuft – jetzt optimieren. Diese Parameter beeinflussen das Ergebnis direkt.

chunk_size – welche Größe?

500–1000 Zeichen aus Erfahrung. Zu klein: unvollständige Semantik – ein Satz halbiert, passt nicht zur Frage. Zu groß: Rauschen – ein Chunk mit mehreren Themen, unscharfe Grenzen.

Unterschiede nach Dokumenttyp: Technische Docs nach Absätzen; Chat-Protokolle eher 500 Zeichen. Testen – keine Universalformel.

Batch-Verarbeitung beschleunigt

Einzelaufruf = Netzwerk-Roundtrip pro Eintrag. 50–100 Einträge pro Batch: mehrfache Beschleunigung. Nicht zu groß – Embedding-Modelle haben Eingabelimits.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Ähnlichkeitsschwelle festlegen

0,7–0,85 je nach Präzisionsanspruch. Hoch (0,85): nur sehr relevante Treffer, niedrige Recall. Niedrig (0,7): mehr Treffer, evtl. Rauschen. Saubere Bibliothek, klare Frage → höher; vage Frage → niedriger.

Praxis-Tipp: Zuerst 50–100 Einträge testen, Retrieval bewerten, dann Parameter festlegen. Vollständige Datenmenge vor dem Tuning einzuspielen kostet Zeit. Iterativ optimieren.

Fazit

Kernpunkte in Kürze:

Modell nach Szenario – Allround mxbai, Langtext nomic, Chinesisch Qwen3. Datenbank: Einstieg ChromaDB, Performance FAISS, Produktion Milvus. Vollständiger Code zum Anpassen und Starten.

Vorteile: lokale Bereitstellung, Datenschutz, kostenlose Ollama-Modelle, einfaches ChromaDB. Nachteile: Single-Machine-Grenzen, ab Millionen Datensätzen Upgrade nötig.

Code aus dem Artikel ausführen, 50 Dokumente testen. Retrieval-Qualität und Antwortgenauigkeit zeigt erst der Praxistest. Parameter stimmen → dann skalieren.

Mehr zu LangChain und Ollama in komplexeren Anwendungen: unser Artikel „LangChain + Ollama: Integrationsleitfaden in der Praxis” – dort Dialogketten und Tool-Calling; hier Vektorsuche. Beide zusammen: vollständiger Pfad für lokale LLM-Anwendungen.