Wenn Teams zum ersten Mal ein LLM (large language model, also ein großes Sprachmodell) an ein Produkt anschließen, wirkt es oft so, als sei der schwierigste Teil schon geschafft. Das Modell beantwortet Fragen, formuliert Texte um, schreibt Entwürfe und führt Dialoge. Aber sobald das Produkt auf echte Geschäftsprozesse trifft, zeigt sich eine unangenehme Tatsache: Für sich genommen weiß das Modell fast nichts über eure Verträge, internen Richtlinien, Wissensdatenbanken, Tickets, euren Code, Produktkataloge oder neue Dokumente.

Genau deshalb sehen so viele KI-Anwendungen in Demos beeindruckend aus und enttäuschen später im produktiven Einsatz. Sie klingen souverän, können ihre Antworten aber nicht auf die tatsächlichen Unternehmensdaten stützen. RAG ist nicht als Modebegriff entstanden, sondern als praktische Antwort auf genau diese Lücke: Wie gibt man einem Modell Zugriff auf die richtigen Daten, ohne es neu zu trainieren und ohne Prompts ständig von Hand neu zusammenzubauen?

Warum ein LLM ohne eure Daten nur begrenzt nützlich ist

Ein Basismodell hat drei strukturelle Schwächen.

Erstens hat es keinen Zugriff auf die privaten Daten einer Organisation. Es kann allgemeine Themen gut erklären, weiß aber nicht, was in eurer PDF mit Einkaufsrichtlinien steht, in Confluence, in Notion, in Zendesk oder im Vertragsordner.

Zweitens gilt: Selbst wenn die relevante Information irgendwann einmal im offenen Internet existierte, muss das Modell sie nicht exakt erinnern. Ohne externe Quelle beginnt es Antworten eher probabilistisch als faktisch zu vervollständigen.

Drittens veraltet Modellwissen schnell. Für angewandte KI ist das kritisch. Nutzer fragen nicht nach abstrakter Physik, sondern nach dem aktuellen Tarif, der neuesten Version einer Richtlinie, dem Status einer Bestellung, einer internen Vorgabe oder der aktuellen API-Spezifikation.

Darin liegt das Kernproblem angewandter KI: Wenn das Modell nicht mit euren Daten verbunden ist, weiß es genau die Dinge nicht, die für das Geschäft am wichtigsten sind. NIST (das U.S. National Institute of Standards and Technology) beschreibt im GenAI-Profil ausdrücklich, dass es bei solchen Systemen nicht nur um Modellintelligenz geht, sondern um Risikomanagement, verlässliche Quellen und vertrauenswürdige Ausgaben. (1)

Was RAG in einem Absatz ist

RAG steht für Retrieval-Augmented Generation. Zuerst findet das System relevante Fragmente in euren Daten. Dann fügt es diese Fragmente in den Kontext des Modells ein. Erst danach erzeugt das LLM die Antwort. Anders gesagt: Das Modell antwortet nicht „aus dem Gedächtnis“, sondern auf Basis gefundener Belege. (2)

In einer guten RAG-Anwendung liegt der eigentliche Wert nicht im reinen LLM-Aufruf. Der Wert entsteht davor: Was soll überhaupt durchsucht werden, wo wird gesucht, wie wird Rauschen herausgefiltert, wie viele Textstücke landen im Prompt und wie sieht der Nutzer, auf welche Quellen sich die Antwort stützt?

Embeddings und Vektordatenbanken, ohne Hype

Damit RAG funktioniert, wird Text meist in Embeddings umgewandelt, also numerische Vektoren, die die Bedeutung eines Satzes oder Absatzes abbilden. So lässt sich die Anfrage eines Nutzers nicht nur nach exakten Worttreffern, sondern auch nach semantischer Nähe vergleichen. OpenAI zeigt in der Retrieval-Dokumentation ausdrücklich, dass das relevanteste Ergebnis nur wenige oder gar keine Schlüsselwörter aus der ursprünglichen Frage enthalten kann. (2)

Eine Vektordatenbank speichert diese Repräsentationen und kann ähnliche Fragmente schnell finden. Sie ist kein „magischer Speicher für KI“, sondern ein spezialisierter Index für semantische Suche. Im gehosteten Setup von OpenAI chunkt, embeddet und indexiert ein vector store hochgeladene Dateien automatisch. Mit Chroma lässt sich dieselbe Logik lokal oder direkt in der eigenen Anwendung aufbauen, bis hin zu einer eigenen Embedding-Funktion. (2 11)

Wichtig ist aber, die Rolle der Vektordatenbank nicht zu überschätzen. Sie ersetzt weder die primäre transaktionale Datenbank noch löst sie Zugriffsrechte, und sie macht Retrieval nicht automatisch gut. Wenn euer Parsing schwach ist, die Chunks schlecht gesetzt sind und Filter nach Tenant oder Dokumenttyp fehlen, hilft auch teure Infrastruktur nicht weiter.

Wie eine produktive RAG-Anwendung tatsächlich aussieht

In der Praxis sieht RAG fast nie so aus: „PDF hochladen, Frage stellen, Antwort bekommen.“ Ein ernsthaftes System hat normalerweise mindestens fünf Schichten: Ingestion, Parsing, Chunking, Retrieval und Generation.

Zuerst müssen Dokumente überhaupt in eine durchsuchbare Form gebracht werden. Google beschreibt das im Vertex AI RAG Engine ganz ausdrücklich als eigenen Lifecycle: Ingestion aus lokalen Dateien, Cloud Storage oder Google Drive, danach Transformation und anschließend Indexierung in ein corpus. (7) Schon das ist ein wichtiger Hinweis: Die eigentliche Schwierigkeit beginnt vor dem Modell.

Danach kommt chunking, also das Zerlegen eines Dokuments in kleinere Fragmente. Dokumente werden fast nie als Ganzes durchsucht. Sie werden in kleinere Einheiten zerlegt, damit Retrieval präziser funktioniert. Genau dort scheitern aber viele Systeme. Ist ein Chunk zu klein, verliert er Kontext. Ist er zu groß, entsteht thematischer Brei: etwas, das irgendwie ähnlich aussieht, aber zu unscharf ist, um wirklich hilfreich zu sein. In OpenAI Retrieval liegt die Standardgröße für Chunks in einem Vector Store bei 800 Tokens mit 400 Tokens Overlap, also mit teilweiser Überschneidung benachbarter Fragmente. Das ist aber nur ein Startwert und keine allgemeine Wahrheit. (2)

Danach braucht man mehr als rohe Vektorsuche. 2026 ist ein starkes Produktionsmuster nicht mehr dense-only Retrieval, sondern die Kombination aus semantischer Suche und Keyword-Suche. OpenAI bietet semantische Suche, Query Rewriting, Attribute Filtering und Ranking-Optionen. Weaviate behandelt Hybrid Search als zentrales Muster: Vector Search und BM25 (Best Matching 25, ein klassischer Ranking-Algorithmus für Keyword-Suche) laufen parallel und werden anschließend zusammengeführt. (2 10)

Danach folgt meist Reranking, also eine zusätzliche Neuordnung der gefundenen Fragmente nach Relevanz. Das ist besonders wichtig, wenn die erste Retrieval-Stufe einen breiten Kandidatensatz liefert. Anthropic zeigt in der Forschung zu Contextual Retrieval denselben Produktionspfad: Embeddings plus BM25 plus Reranker führen zu deutlich weniger Retrieval-Fehlern als Embeddings allein. (5)

Erst danach gelangt der gefundene Kontext ins LLM. Wenn das Produkt ernst genommen werden soll, muss die Ausgabe mindestens Zitate, Quellenlinks, Seitenreferenzen oder einen klaren Herkunftspfad enthalten. Sonst bekommt der Nutzer zwar schön formulierten Text, aber nichts, was sich verifizieren lässt.

Chat mit PDFs und Wissensdatenbanken: was sich in der Praxis ändert

Chat with PDF wird oft als das einfachste RAG-Beispiel dargestellt. Für eine Demo stimmt das auch: Datei hochladen, in Chunks zerlegen, Embeddings erzeugen, ähnliche Passagen finden, an das Modell geben. In einem echten Produkt beginnen die schwierigen Teile aber sofort.

Ein PDF kann ein Scan sein. Es kann Tabellen, Spalten, Diagramme, Fußnoten und eine kaputte Leserichtung enthalten. Derselbe Absatz wird nach schlechtem Parsing zu Datenmüll, der sich zwar indexieren lässt, aber schlechte Antworten produziert. Deshalb beginnt praktisches PDF-RAG fast nie mit Embeddings, sondern mit verlässlicher Extraktion und Wiederherstellung der Dokumentstruktur.

Bei einer unternehmensweiten Wissensdatenbank ist es noch schwieriger. Dort geht es nicht nur um Relevanz, sondern genauso um Berechtigungen, Aktualität und Quellqualität. Ein Nutzer soll die internen Runbooks seines Teams sehen, aber nicht Dokumente aus HR oder Legal. Schon eine einzige veraltete Datei im Index kann mehr Vertrauen zerstören, als zehn gute Antworten wieder aufbauen.

Deshalb enthält ein funktionierendes RAG-System für Wissensdatenbanken fast immer:

Filter nach Quelle, Tenant, Abteilung oder Dokumenttyp;
Reindexierung bei Inhaltsänderungen;
Logs der tatsächlich gefundenen Chunks;
Offline-Evals, also Testsätze zur Prüfung von Retrieval- und Antwortqualität;
eine explizite Fallback-Strategie, wenn keine relevanten Belege gefunden wurden.

Genau deshalb beginnt in angewandter KI die eigentliche Arbeit dort, wo die Demo endet.

Werkzeuge 2026: Pinecone, Weaviate, Chroma, Qdrant, pgvector

Die Wahl des Werkzeugs sollte sich nicht an Mode, sondern am tatsächlich geplanten Retrieval-Layer orientieren.

Pinecone bleibt eine starke Managed-Option für Teams, die keinen eigenen Such-Stack betreiben wollen. In der Pinecone-Dokumentation stehen die serverlose Architektur, die Trennung von Control Plane und Data Plane, unabhängige Skalierung von Lese- und Schreibpfaden sowie Namespaces im Vordergrund. Das ist attraktiv, wenn man einen berechenbaren Managed Service mit wenig Ops-Aufwand will. (9)

Weaviate ist stark, wenn Hybrid Search von Anfang an eingebaut sein soll und nicht später angeflanscht wird. In der Dokumentation ist Hybrid Search kein Workaround, sondern ein Kernmuster: Vector Search und BM25 laufen parallel und werden über relativeScoreFusion oder rankedFusion zusammengeführt. Über alpha lässt sich zusätzlich das Verhältnis zwischen semantischem und keywordbasiertem Signal steuern. Für wissenslastige Systeme ist das ein sehr praktischer Kompromiss zwischen Recall und Precision. (10)

Chroma ist ein bequemer, leichter Startpunkt, vor allem für Prototypen, Evaluations-Pipelines und kleinere Anwendungen. Es bringt eine eingebaute Embedding-Funktion auf Basis von all-MiniLM-L6-v2 mit und lässt sich bei Bedarf schnell mit OpenAI, Google, Mistral, Ollama, Jina und anderen Providern verbinden. Damit lässt sich ein Retrieval-Layer schnell aufbauen, ohne schwere Infrastruktur mitzuschleppen. Für hoch belastete Multi-Tenant-Produktivsysteme wird es allerdings meist deutlich kritischer bewertet. (11)

Qdrant wird oft gewählt, wenn Metadata Filtering, Hybrid Search und ein eigenständig evolvierender Retrieval-Layer im Vordergrund stehen. Bezeichnend ist, dass selbst Qdrants eigener Vergleich mit pgvector nicht auf „magische Geschwindigkeit“ setzt, sondern auf filterbares HNSW (Hierarchical Navigable Small World, eine verbreitete Indexstruktur für die schnelle Approximation nächster Nachbarn), Hybrid Search und auf Szenarien, in denen Vektoren zu einer eigenen Schicht werden statt nur ein weiteres Feld in Postgres zu sein. (12)

pgvector bleibt ein vernünftiger Einstieg, wenn ihr ohnehin Postgres betreibt, euer Korpus eher klein ist und die Suchlogik eng mit relationalen Daten gekoppelt bleibt. Die praktische Regel ist aber simpel: Wenn ihr mit starker Filterung, BM25 oder Hybrid Retrieval, wachsendem Embedding-Volumen und einer eigenständig weiterentwickelten Retrieval-Pipeline rechnet, solltet ihr früh so designen, dass ein Wechsel in einen dedizierten Vector Store später nicht schmerzhaft wird. (12)

Managed RAG von Modellanbietern: OpenAI File Search und Vertex AI RAG Engine

Ein klarer Trend der letzten Jahre ist gehostetes RAG direkt bei den Modellanbietern. Das ist wichtig, weil die Anbieter nicht mehr nur sagen: „Hier ist das LLM, baut den Rest selbst.“ Sie übernehmen Schritt für Schritt auch die Retrieval-Schicht.

OpenAI bietet dafür file_search und vector stores. Dateien lassen sich in eine Knowledge Base hochladen, der Dienst chunkt, embeddet und indexiert sie automatisch, und anschließend kann File Search als Tool in der Responses API aktiviert werden. Ergebnisse lassen sich begrenzen, Metadaten filtern, Queries umschreiben, Ranking-Optionen anpassen und Zitate in die Antwort einbauen. Für viele interne Assistenten ist das ein sehr schneller Weg zu produktivem Nutzen. (2 4)

Google besetzt mit Vertex AI RAG Engine eine ähnliche Rolle. Der Dienst wird ausdrücklich als Data Framework für context-augmented LLM-Anwendungen beschrieben: Ingestion, Transformation, Indexing, Retrieval und Generation. Zusätzlich legt Google großen Wert auf Grounding, also die Bindung der Antwort an überprüfbare Quellen, und auf die Check grounding API, mit der sich prüfen lässt, ob eine Antwort tatsächlich durch die gefundenen Fakten gedeckt ist. (7)

Der Preis für diesen Komfort ist offensichtlich: weniger Kontrolle über die Retrieval-Pipeline, mehr Plattformabhängigkeit und weniger Freiheit bei tiefergehender Optimierung von Parsing, Indexing und Reranking. Für viele Teams ist das trotzdem ein völlig rationaler Tausch, wenn das Ziel eine nützliche Anwendung ist und kein maßgeschneiderter Forschungs-Stack.

Was OpenAI, Anthropic und Google tatsächlich empfehlen

Wenn man nicht auf das Marketing rund um RAG schaut, sondern auf die Empfehlungen der Anbieter selbst, wirkt das Bild erstaunlich nüchtern.

OpenAI sagt im Kern: Retrieval muss wie ein Suchsystem behandelt werden, nicht wie „magischer Kleber für ein LLM“. In der Dokumentation finden sich Query Rewriting, Attribute Filtering, Ranker- und Score-Threshold-Tuning, Ergebnislimits und Batch-Ingestion für höheren Durchsatz. Das ist eine sehr technische, nicht romantische Sicht auf RAG. (2)

Anthropic geht noch weiter und zeigt direkt, wo klassisches RAG scheitert. Das Argument ist einfach: Ein Chunk ohne Kontext verliert oft die Verbindung zum Ursprungsdokument. Deshalb schlagen sie Contextual Retrieval vor: jedem Chunk vor dem Embedding und vor dem Aufbau des BM25-Index einen kurzen situierenden Kontext voranzustellen. Laut Anthropic senken Contextual Embeddings die Zahl der Retrieval-Fehler um 35%, Contextual Embeddings plus Contextual BM25 um 49%, und der komplette Stack mit Reranking um 67%. (5)

Google wiederum betont sehr konsequent das Thema Grounding. Praktisch heißt das: Retrieval dient nicht nur dazu, „bessere Antworten“ zu erzeugen. Es soll die Generierung an überprüfbare Quellen binden. Das ist vermutlich die gesündeste Perspektive auf die gesamte RAG-Schicht: Retrieval ist wichtig, nicht weil der Text dadurch klüger klingt, sondern weil das Ergebnis überprüfbarer wird. (7)

Wann RAG zu viel ist: Long Context vs. Retrieval

2026 lässt sich über RAG nicht mehr ernsthaft sprechen, ohne auch Long Context zu erwähnen, also ein sehr großes Kontextfenster des Modells. Anthropic hat offiziell 1M Tokens Kontext für Claude Sonnet 4 eingeführt und schreibt in der Contextual-Retrieval-Forschung zusätzlich: Wenn eure Wissensbasis kleiner als 200.000 Tokens ist, also ungefähr 500 Seiten umfasst, kann es sinnvoller sein, RAG ganz zu überspringen und den kompletten Korpus direkt in den Prompt zu legen. Mit Prompt Caching, also der Wiederverwendung eines bereits vorbereiteten großen Kontexts, kann das die Latenz um mehr als das Doppelte senken und die Kosten um bis zu 90% reduzieren. (5)

Das ist eine wichtige Korrektur für die Branche. Nicht jeder Dokumentbestand braucht Embeddings, eine Vektordatenbank und eine eigene Retrieval-Pipeline. Wenn der Korpus klein, stabil und selten aktualisiert wird, kann Long Context einfacher, robuster und günstiger in der Wartung sein.

Die Kehrseite ist aber genauso offensichtlich. Sobald die Datenmenge wächst, sich Inhalte häufig ändern, Berechtigungen nötig werden, Metadatenfilter gebraucht werden, mehrere Quellen zusammenkommen oder Latenz wichtig wird, ist Long Context keine universelle Antwort mehr. Den gesamten Korpus bei jeder Anfrage mitzuschicken, ist teuer, langsam und operativ unhandlich.

Die praktische Regel lautet:

kleiner, stabiler Korpus: zuerst Long Context testen;
großer oder schnell veränderlicher Korpus: sehr wahrscheinlich braucht ihr RAG;
komplexes Reasoning über großem Korpus: meistens funktioniert ein Hybrid am besten, erst Retrieval, dann Long Context.

RAG ist eine Disziplin, keine Bibliothek

Das größte Missverständnis rund um RAG lautet ungefähr so: „Wir hängen Pinecone, Weaviate oder Chroma dran, und die KI spricht plötzlich aus unseren Daten.“ In der Praxis ist es fast umgekehrt. Die Vektordatenbank ist wichtig, aber zweitrangig. Die Qualität bricht meist an schwachem Parsing, schlechtem Chunking, fehlender Hybrid Search, einem schwachen Reranker, unsauberen Quellen und komplett fehlenden Evals, also Testsätzen und Prüfungen für Retrieval- und Antwortqualität.

Darum ist es hilfreicher, RAG nicht als Modul, sondern als Disziplin im Umgang mit Organisationswissen zu verstehen. Gutes RAG findet den richtigen Kontext, setzt Zugriffsgrenzen durch, zeigt Quellen an, verkraftet Dokumentupdates und kann ehrlich sagen: „Ich weiß es nicht“, wenn keine belastbaren Belege gefunden wurden.

In genau diesem Sinn bleibt RAG zentral für angewandte KI. Nicht weil ein LLM ohne RAG buchstäblich gar nichts beantworten könnte. Sondern weil ohne Retrieval, Grounding und Quellenprüfung die meisten KI-Anwendungen eine elegante Demo bleiben und kein belastbares Werkzeug.

Was RAG ist und warum KI-Anwendungen ohne RAG Spielzeug bleiben

Wenn Teams zum ersten Mal ein LLM an ein Produkt anschließen, wirkt es oft so, als sei der schwierigste Teil schon geschafft. Das Modell beantwortet Fragen, formuliert Texte um, schreibt Entwürfe und führt Dialoge. Aber sobald das Produkt auf echte Geschäftsprozesse trifft, zeigt sich eine unangenehme Tatsache: Für sich genommen weiß das Modell fast nichts über eure Verträge, internen Richtlinien, Wissensdatenbanken, Tickets, euren Code, Produktkataloge oder neue Dokumente.

Warum ein LLM ohne eure Daten nur begrenzt nützlich ist

Ein Basismodell hat drei strukturelle Schwächen.

Darin liegt das Kernproblem angewandter KI: Wenn das Modell nicht mit euren Daten verbunden ist, weiß es genau die Dinge nicht, die für das Geschäft am wichtigsten sind. NIST beschreibt im GenAI-Profil ausdrücklich, dass es bei solchen Systemen nicht nur um Modellintelligenz geht, sondern um Risikomanagement, verlässliche Quellen und vertrauenswürdige Ausgaben. (1)

Was RAG in einem Absatz ist

Embeddings und Vektordatenbanken, ohne Hype

Wie eine produktive RAG-Anwendung tatsächlich aussieht

Danach kommt das Chunking. Dokumente werden fast nie als Ganzes durchsucht. Sie werden in kleinere Einheiten zerlegt, damit Retrieval präziser funktioniert. Genau dort scheitern aber viele Systeme. Ist ein Chunk zu klein, verliert er Kontext. Ist er zu groß, entsteht thematischer Brei: etwas, das irgendwie ähnlich aussieht, aber zu unscharf ist, um wirklich hilfreich zu sein. In OpenAI Retrieval liegt die Standardgröße für Chunks in einem Vector Store bei 800 Tokens mit 400 Tokens Overlap. Das ist aber nur ein Startwert und keine allgemeine Wahrheit. (2)

Danach braucht man mehr als rohe Vektorsuche. 2026 ist ein starkes Produktionsmuster nicht mehr dense-only Retrieval, sondern die Kombination aus semantischer Suche und Keyword-Suche. OpenAI bietet semantische Suche, Query Rewriting, Attribute Filtering und Ranking-Optionen. Weaviate behandelt Hybrid Search als zentrales Muster: Vector Search und BM25 laufen parallel und werden anschließend zusammengeführt. (2 10)

Danach folgt meist Reranking. Das ist besonders wichtig, wenn die erste Retrieval-Stufe einen breiten Kandidatensatz liefert. Anthropic zeigt in der Forschung zu Contextual Retrieval denselben Produktionspfad: Embeddings plus BM25 plus Reranker führen zu deutlich weniger Retrieval-Fehlern als Embeddings allein. (5)

Chat mit PDFs und Wissensdatenbanken: was sich in der Praxis ändert

Deshalb enthält ein funktionierendes RAG-System für Wissensdatenbanken fast immer:

Filter nach Quelle, Tenant, Abteilung oder Dokumenttyp;
Reindexierung bei Inhaltsänderungen;
Logs der tatsächlich gefundenen Chunks;
Offline-Evals mit repräsentativen Fragen;
eine explizite Fallback-Strategie, wenn keine relevanten Belege gefunden wurden.

Genau deshalb beginnt in angewandter KI die eigentliche Arbeit dort, wo die Demo endet.

Werkzeuge 2026: Pinecone, Weaviate, Chroma, Qdrant, pgvector

Die Wahl des Werkzeugs sollte sich nicht an Mode, sondern am tatsächlich geplanten Retrieval-Layer orientieren.

Qdrant wird oft gewählt, wenn Metadata Filtering, Hybrid Search und ein eigenständig evolvierender Retrieval-Layer im Vordergrund stehen. Bezeichnend ist, dass selbst Qdrants eigener Vergleich mit pgvector nicht auf „magische Geschwindigkeit“ setzt, sondern auf filterbares HNSW, Hybrid Search und auf Szenarien, in denen Vektoren zu einer eigenen Schicht werden statt nur ein weiteres Feld in Postgres zu sein. (12)

Managed RAG von Modellanbietern: OpenAI File Search und Vertex AI RAG Engine

Google besetzt mit Vertex AI RAG Engine eine ähnliche Rolle. Der Dienst wird ausdrücklich als Data Framework für context-augmented LLM-Anwendungen beschrieben: Ingestion, Transformation, Indexing, Retrieval und Generation. Zusätzlich legt Google großen Wert auf Grounding und auf die Check grounding API, mit der sich prüfen lässt, ob eine Antwort tatsächlich durch die gefundenen Fakten gedeckt ist. (7)

Was OpenAI, Anthropic und Google tatsächlich empfehlen

Wenn man nicht auf das Marketing rund um RAG schaut, sondern auf die Empfehlungen der Anbieter selbst, wirkt das Bild erstaunlich nüchtern.

Wann RAG zu viel ist: Long Context vs. Retrieval

2026 lässt sich über RAG nicht mehr ernsthaft sprechen, ohne auch Long Context zu erwähnen. Anthropic hat offiziell 1M Tokens Kontext für Claude Sonnet 4 eingeführt und schreibt in der Contextual-Retrieval-Forschung zusätzlich: Wenn eure Wissensbasis kleiner als 200.000 Tokens ist, also ungefähr 500 Seiten umfasst, kann es sinnvoller sein, RAG ganz zu überspringen und den kompletten Korpus direkt in den Prompt zu legen. Mit Prompt Caching kann das die Latenz um mehr als das Doppelte senken und die Kosten um bis zu 90% reduzieren. (5)

Die praktische Regel lautet:

kleiner, stabiler Korpus: zuerst Long Context testen;
großer oder schnell veränderlicher Korpus: sehr wahrscheinlich braucht ihr RAG;
komplexes Reasoning über großem Korpus: meistens funktioniert ein Hybrid am besten, erst Retrieval, dann Long Context.