← Alle Insights
10 Min. Lesezeit · KI · Januar 2030

RAG-Systeme für Trader: eigene Wissensbasis mit LLMs.

Über die Jahre sammelt sich an: hunderte Strategie-Notizen, archivierte Earnings-Calls, Research-PDFs, eigene Backtest-Reports, Compliance-Dokumente. Niemand liest das je wieder vollständig durch. Ein RAG-System macht aus diesem Friedhof eine durchsuchbare Wissensbasis — wenn man es richtig aufsetzt.

Was RAG eigentlich ist — und was nicht.

Retrieval-Augmented Generation kombiniert zwei Komponenten: ein Retrieval-System (meist eine Vector-DB mit Embeddings), das die relevantesten Dokument-Chunks zu einer Frage findet, und ein LLM, das auf Basis dieser Chunks eine Antwort formuliert.

RAG ist nicht Fine-Tuning. Sie trainieren das Modell nicht um. Sie geben ihm zur Laufzeit den passenden Kontext. Das hat zwei Konsequenzen, die viele unterschätzen: erstens, das Modell weiß nur, was es im retrievten Kontext sieht — und das Retrieval ist der Engpass. Zweitens, neue Dokumente müssen nur neu eingelesen werden, nicht ein neues Training auslösen.

Use-Cases, die im Trading wirklich tragen.

  1. Strategie-Dokumentation durchsuchen: „Welche Strategien habe ich je gegen VIX-Spikes gebaut? Was waren die Ergebnisse?" Das ist die häufigste produktive Anwendung in Mandaten, die ich begleite — Wissen, das nicht verloren geht, wenn der Lead-Quant das Unternehmen verlässt.
  2. Earnings-Call-Archive: 5–10 Jahre Earnings-Calls für 50 Beobachtungs-Werte sind 10.000+ Dokumente. „Wann hat Adobe das letzte Mal Margen-Druck angekündigt — und was ist danach passiert?" — diese Frage in 30 Sekunden statt drei Stunden.
  3. Research-Notizen und Trade-Journals: eigene Notizen zu jedem Trade, jedem Market-Regime. RAG macht den eigenen Erfahrungsschatz wieder zugänglich.
  4. Regulatorische Dokumente: MiFID-II-Texte, ESMA-Q&As, BaFin-Rundschreiben. Compliance-relevante Fragen mit Quellen-Verweis statt freier LLM-Antwort.
  5. Backtest-Report-Archiv: „Welche Strategien hatte ich mit Sharpe > 1.5 und max DD < 10 % im Bond-Sektor?" — wenn Reports strukturiert abgelegt und embedded sind, beantwortbar.

Stack: drei Komponenten, mehr nicht.

Ein RAG-System besteht im Kern aus drei Teilen:

Konkretes Setup — LangChain oder eigener Code.

Die ehrliche Antwort, nach Jahren in Mandaten: in 80 % der Fälle ist eigener Code besser. LangChain ist hilfreich für schnelle Prototypen, aber in Produktion sind die Abstraktionen oft im Weg. Für ein Trader-RAG mit ~100k Dokumenten reicht ein 300-Zeilen-Python-Modul. Ein minimales Beispiel: 

import anthropic, openai, psycopg
from pgvector.psycopg import register_vector

oa = openai.OpenAI()
an = anthropic.Anthropic()
conn = psycopg.connect("postgresql://...")
register_vector(conn)

def embed(text: str) -> list[float]:
    r = oa.embeddings.create(
        model="text-embedding-3-large",
        input=text, dimensions=1024)
    return r.data[0].embedding

def ingest(doc_id: str, source: str, chunks: list[str]):
    with conn.cursor() as cur:
        for i, c in enumerate(chunks):
            cur.execute(
                "INSERT INTO rag_chunks "
                "(doc_id, chunk_idx, source, text, embed) "
                "VALUES (%s, %s, %s, %s, %s)",
                (doc_id, i, source, c, embed(c)))
        conn.commit()

def ask(question: str, k: int = 12) -> str:
    qv = embed(question)
    with conn.cursor() as cur:
        cur.execute("""
            SELECT source, text
            FROM   rag_chunks
            ORDER  BY embed <=> %s
            LIMIT  %s""", (qv, k))
        hits = cur.fetchall()
    context = "\n\n".join(
        f"[{src}]\n{txt}" for src, txt in hits)
    msg = an.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        system=("Beantworte die Frage AUSSCHLIESSLICH "
                "auf Basis des Kontextes. "
                "Wenn der Kontext nicht reicht: sage das."),
        messages=[{"role":"user",
                   "content":f"Kontext:\n{context}\n\n"
                             f"Frage: {question}"}])
    return msg.content[0].text

Was hier fehlt und in Produktion dazukommen muss: Chunking-Strategie (Token-basiert mit Overlap, oder semantisch über Section-Header), Hybrid-Search (BM25 + Vector), Re-Ranking mit einem Cross-Encoder, Quellen-Zitate im Output, Logging, Token-Budgetierung.

Self-hosted vs. Cloud — der Datenschutz-Punkt.

Trader-Wissensbasen enthalten oft Material, das nicht in fremde Hände gehört: eigene Strategie-Logik, Positions-Größen, Mandanten-Informationen. Drei Konfigurationen, die ich in der Praxis sehe:

Praxis-Beispiel: eigene Quant-Research-Bibliothek.

Ein Setup, das ich letztes Jahr für einen Mandanten gebaut habe: ca. 2.400 Research-PDFs (eigene Studien, externe Broker-Notes, akademische Papers) plus ein Markdown-Archiv mit ~600 Trade-Journal-Einträgen.

Pipeline: nächtlicher Cron-Job liest neue Dokumente aus einem S3-Bucket, extrahiert Text via Unstructured.io, chunked auf 800 Tokens mit 120 Overlap, embedded mit text-embedding-3-large auf 1024 Dimensionen, schreibt in pgvector. Eine kleine Web-UI (FastHTML, ein einziger Endpoint) erlaubt Fragen mit Quellen-Verweis.

Ergebnis nach drei Monaten: das Team nutzt die Suche täglich. Häufigste Fragen sind nicht „was ist Mean-Reversion?" — das weiß das Team — sondern „in welchem unserer eigenen Reports haben wir das schon behandelt, und mit welchem Resultat?" Genau dort ist RAG unschlagbar.

Kosten — realistisch durchgerechnet.

Ein typisches Setup mit ~100k Chunks und ~50 Anfragen pro Tag:

Was ich gelernt habe — und was nicht funktioniert.

RAG-Systeme klingen einfach und sind in der Demo immer beeindruckend. In Produktion ist das Retrieval der Punkt, an dem die meisten Setups scheitern. Drei Lektionen:

Sie wollen Ihre eigene Trader-Wissensbasis RAG-durchsuchbar machen? Erstgespräch buchen — wir prüfen Datenlage, Datenschutz-Anforderungen und Stack-Wahl.