Eine KI-Sucharchitektur von Grund auf aufbauen – welche Komponenten braucht man wirklich?

Ich habe diesen Stack schon mehrfach aufgebaut. Hier ist das Framework, das ich nutze:

Kernarchitektur (RAG-Muster):

Benutzeranfrage
    ↓
Query-Embedding (Embedding-Modell)
    ↓
Vektorsuche (Vektor-DB)
    ↓
Kandidaten-Retrieval
    ↓
Reranking (Cross-Encoder)
    ↓
Kontextzusammenstellung
    ↓
LLM-Generierung
    ↓
Antwort

Komponentenempfehlungen für eure Skalierung (500K Dokumente):

Budget-Realität:

Bei 500K Dokumenten rechnet ihr mit:

• Vektor-DB: 100–500 $/Monat (managed)
• Embedding-Kosten: Einmalig ~50–100 $, um den Korpus zu embedden
• LLM-Kosten: Nutzungsabhängig, plant 500–2000 $/Monat ein

Für 2 Ingenieure sind Managed Services auf jeden Fall lohnenswert.

Wir betreiben KI-Suche seit 18 Monaten produktiv. Was ich anders machen würde:

Unsere Fehler:

1. Mit selbst gehosteter Vektor-DB gestartet – 3 Monate an Infrastruktur vergeudet. Hätten von Anfang an Managed nehmen sollen.

2. Billiges Embedding-Modell gewählt – 20 $/Monat gespart, aber viel Retrieval-Qualität verloren. Gute Embeddings lohnen sich.

3. Anfangs keine Hybridsuche – Reine Vektorsuche hat exakte Treffer verpasst. Hybrid (Vektor + BM25) hat das gelöst.

4. Monitoring unterschätzt – Schwer zu debuggen, wenn man keine Retrieval-Qualitätsmetriken sieht.

Unser heutiger Stack:

• Pinecone (Vektor) + Elasticsearch (BM25) hybrid
• OpenAI-Embeddings (ada-002, bald auf 3)
• Cohere Reranker
• Claude für Generierung
• Eigenes Monitoring-Dashboard für Retrieval-Metriken

Latenz-Aufteilung:

• Embedding: 30 ms
• Hybridsuche: 40 ms
• Rerank: 60 ms
• LLM: 800 ms (Streaming verbessert UX)

Die gefühlte Latenz ist ok, weil wir das LLM-Output streamen.

Noch die Data-Pipeline-Perspektive, die oft vergessen wird:

Dokumentenverarbeitung ist EXTREM wichtig:

Bevor etwas in die Vektor-DB kommt, braucht ihr:

1. Chunking-Strategie – Wie teilt ihr Dokumente auf?
2. Metadaten-Extraktion – Welche Attribute werden erfasst?
3. Cleaning-Pipeline – Boilerplate entfernen, Text normalisieren
4. Update-Mechanismus – Wie kommen neue/geänderte Dokumente durch die Pipeline?

Chunking-Tipps:

Die Falle:

Leute verbringen Wochen mit der Auswahl der Vektor-DB und Tage mit Chunking. Es sollte umgekehrt sein. Schlechtes Chunking = schlechtes Retrieval, egal wie gut die Vektor-DB ist.

Vektordatenbanken-Vergleich basierend auf deinen Anforderungen:

Für 500K Docs + 2 Ingenieure + <200 ms:

Pinecone:

• Vorteile: Voll gemanaged, sehr gute Doku, kalkulierbare Kosten
• Nachteile: Vendor-Lock-in, begrenzte Anpassung
• Fazit: Perfekt für eure Rahmenbedingungen

Qdrant:

• Vorteile: Sehr gute Performance, gute Hybrid-Unterstützung, Cloud oder Self-Host
• Nachteile: Managed-Angebot noch neu
• Fazit: Gute Option, falls Hybrid gebraucht wird

Weaviate:

• Vorteile: Sehr gute Hybridsuche, eingebaute Vektorisierung
• Nachteile: Komplexerer Setup
• Fazit: Besser für größere Teams

Milvus:

• Vorteile: Skalierbar, komplett Open Source
• Nachteile: Infrastruktur-Knowhow notwendig
• Fazit: Für eure Skalierung zu viel, lieber nicht

Meine Empfehlung:

Startet mit Pinecone. Es ist langweilig (im besten Sinne). Ihr habt später noch Zeit, Alternativen zu evaluieren, sobald ihr euren tatsächlichen Bedarf besser kennt.

Vergesst MLOps und Observability nicht:

Was ihr tracken müsst:

1. Retrieval-Metriken

   • Precision@K (Sind die Top-K relevant?)
   • Recall (Werden alle relevanten Docs gefunden?)
   • Latenzverteilung

2. Generierungs-Metriken

   • Antwort-Relevanz (passt die Antwort zur Anfrage?)
   • Groundedness (ist die Antwort durch Kontext gedeckt?)
   • Halluzinationsrate

3. Systemmetriken

   • Query-Latenz p50/p95/p99
   • Fehlerraten
   • Kosten pro Anfrage

Tools:

• Weights & Biases für Experiment-Tracking
• Datadog/Grafana für System-Monitoring
• LangSmith für LLM-Observability
• Eigenes Dashboard für Businessmetriken

Das sagt dir niemand:

Ihr verbringt mehr Zeit mit Monitoring und Debugging als mit dem initialen Aufbau. Plant das von Anfang an ein.

Startup-Realitätscheck:

Wenn ihr das fürs Business (nicht Forschung) baut, bedenkt:

Build vs Buy:

• RAG selbst bauen: 2–3 Monate Entwicklungszeit
• Existierende RAG-Plattform nutzen: In Tagen produktiv

Plattformen, die das bündeln:

• LlamaIndex + gemanagte Vektor-DB
• Vectara (komplettes RAG-as-a-Service)
• Cohere RAG-Endpunkte

Wann Custom-Build?

• Wenn extreme Anpassung nötig ist
• Daten-Sensitivität gefordert wird
• Skaleneffekte es lohnen
• Core-Kompetenz soll differenzieren

Wann Plattform?

• Time-to-Market zählt
• Kleines Team
• RAG ist nicht euer Produkt, sondern ein Enabler

Für die meisten Unternehmen gewinnt die Plattform-Variante, bis es Skalierungsgrenzen gibt.

Sicherheitsaspekte, die niemand erwähnt hat:

Datenthemen:

1. Welche Daten schickt ihr an externe Embedding-APIs?
2. Welche Daten gehen zu LLM-Providern?
3. Wo wird eure Vektor-DB gehostet?

Optionen für sensible Daten:

• Selbst gehostete Embedding-Modelle (Sentence Transformers)
• Selbst gehostete Vektor-DB (Qdrant, Milvus)
• On-Premise LLM (Llama, Mixtral)
• Managed Services im VPC

Compliance-Checkliste:

• Datenresidenz-Anforderungen erfüllt
• Verschlüsselung im Ruhezustand und bei Übertragung
• Zugriffskontrollen und Audit-Logging
• Datenaufbewahrungsrichtlinien
• PII-Handling-Prozesse

Nehmt nicht an, dass Managed Services eure Compliance-Anforderungen erfüllen. Prüft das explizit.

Dieser Thread war extrem wertvoll. Hier mein aktualisierter Plan:

Architektur-Entscheidung:

Wir setzen auf Managed Services für Geschwindigkeit und Teamgröße:

• Pinecone für Vektorspeicherung
• OpenAI text-embedding-3 für Embeddings
• Cohere Reranker
• Claude für Generierung
• LangChain für Orchestrierung

Wichtige Learnings:

1. Chunking-Strategie ist genauso wichtig wie die Wahl der Vektor-DB – investieren hier Zeit
2. Reranking ist High-ROI – von Anfang an dabei
3. Hybridsuche für Abdeckung – Vektor + BM25 implementieren
4. Monitoring ab Tag 1 – Observability wird von Anfang an gebaut, nicht nachträglich
5. Früher Security-Check – Compliance vor Go-Live sicherstellen

Zeitplan:

• Woche 1–2: Datenpipeline und Chunking
• Woche 3–4: Kern-RAG-Implementierung
• Woche 5: Monitoring und Optimierung
• Woche 6: Security-Review und Produktion

Danke an alle für die ausführlichen Insights. Diese Community ist Gold wert.