Kurs
In diesem Tutorial zeig ich dir, wie du mit Google File Search einen Assistenten für medizinische Unterlagen aufbaust. Du wirst sehen, wie du es einrichtest, Abfragen machst und erweiterte Funktionen wie benutzerdefiniertes Chunking und Metadatenfilterung nutzt. Am Ende wirst du wissen, wann ein verwaltetes RAG sinnvoll ist und wann du lieber deinen eigenen Stack aufbauen solltest.
Was ist das Google-Tool zur Dateisuche?
RAG-Anwendungen zu entwickeln heißt meistens, sich mit Vektordatenbanken, Einbettungspipelines und einer Menge Infrastruktur zu beschäftigen. Das im November 2025 veröffentlichte Dateisuchtool von Google macht Schluss mit dieser Komplexität und bietet eine vollständig verwaltete Lösung. RAG-System -System, das direkt in die Gemini API
Das Tool erledigt die komplizierten Sachen für dich: Dokumente in Teile zerlegen, Einbettungen erstellen und die semantische Suche verwalten, ohne dass du externe Tools wie Pinecone oder ChromaDB brauchst. Der Ablauf ist ganz einfach: Dateien hochladen, einen Speicher erstellen und mit der Abfrage loslegen. Du bekommst auch integrierte Quellenangaben, mit denen du überprüfen kannst, woher die Antworten kommen.
RAG verstehen und warum Google es einfacher macht
Gemini File Search wird als verwaltetes RAG-System vermarktet. Wenn du RAG verstehst, kannst du das Tool gut nutzen und entscheiden, wann es für deinen Anwendungsfall passt.
Im Grunde verbindet die Retrieval-Augmented Generation (RAG) Sprachmodelle mit externem Wissen. Bevor das Modell eine Antwort gibt, holt es sich relevante Infos aus deinen Dokumenten und stützt sich dabei auf deine tatsächlichen Daten, statt nur auf Trainingsdaten.
Die DIY-RAG-Herausforderung
Obwohl das RAG-Konzept einfach klingt, den Aufbau einer RAG-Pipeline bedeutet, dass man mehrere Teile im Griff haben muss:
- Vektordatenbanken: Richte Dienste wie Pinecone, ChromaDBoder Weaviate zum Speichern von Einbettungen
- Einbetten von Pipelines in „ “: Dokumente in numerische Vektoren umwandeln und Aktualisierungen bei Inhaltsänderungen verarbeiten
- Chunking-Strategien: Teile Dokumente in Teile auf, die den Kontext und die Genauigkeit beim Abrufen abwägen.
- Infrastruktur-: Überwache die Leistung, passe die Einstellungen an und kümmere dich um die Skalierung, wenn deine Datenmenge wächst.
Jede Komponente braucht Fachwissen und muss regelmäßig gewartet werden. Egal, ob du ein Produktionssystem baust, das zuverlässig sein muss, oder einen Prototyp, der schnell sein muss – der Infrastruktur-Overhead bleibt immer der gleiche Engpass.
Warum verwaltetes RAG wichtig ist
Managed Services wie Google File Search machen Schluss mit diesem Problem. Anstatt Suchsysteme anzupassen, schreibst du Suchanfragen. Anstatt eingebettete Pipelines zu debuggen, überprüfst du die Ergebnisse. Die Infrastruktur läuft im Hintergrund, während du dich auf die Anwendungslogik konzentrieren kannst.
Gemini File Search kümmert sich um die technischen Details, während du dich auf das Wesentliche konzentrieren kannst: welche Dokumente indexiert werden sollen, wie sie abgefragt werden sollen und wie die Ergebnisse genutzt werden sollen. Diese Balance ist super, wenn du Produktionsqualität ohne viel Aufwand willst. Für mehr Infos zu den Grundlagen von RAG schau dir am besten das Tutorial von DataCamp zu Agentic RAG.

Am besten verstehst du Google File Search, wenn du es einfach mal ausprobierst. Im nächsten Abschnitt baust du einen kompletten Assistenten für medizinische Dokumentationen, der den ganzen Arbeitsablauf vom Hochladen von Dokumenten bis hin zu fundierten Antworten mit Zitaten zeigt.
Erstellen eines medizinischen Dokumentationsassistenten mit Google File Search
Haftungsausschluss: Dieses Tutorial zeigt die Dateisuchfunktionen anhand von FDA-Arzneimitteletiketten und ist nur für Bildungszwecke gedacht. Der Assistent, den du entwickelst, ist nicht für den klinischen Einsatz, Entscheidungen zur Patientenversorgung oder medizinische Diagnosen gedacht. Frag immer qualifizierte medizinische Fachkräfte um Rat. KI-Systeme können auch dann falsche Infos liefern, wenn sie auf Quelldokumente basieren.
In diesem Abschnitt lernst du, wie du mit der Dateisuche einen kompletten Assistenten für medizinische Unterlagen erstellst. Du wirst mit den FDA-Arzneimitteletiketten für drei gängige Medikamente arbeiten und ein System erstellen, das Fragen zu Wechselwirkungen, Nebenwirkungen und Kontraindikationen von Arzneimitteln beantwortet. Der Assistent gibt dir nachprüfbare Antworten, indem er bestimmte Stellen aus den Quelldokumenten zitiert.
Die Dateisuche läuft in zwei Schritten ab: Du indizierst deine Dokumente einmal und kannst sie dann immer wieder durchsuchen. Du richtest zuerst die Indexierungsinfrastruktur ein und konzentrierst dich dann voll und ganz darauf, Fragen zu stellen und fundierte Antworten zu interpretieren.
Schritt 1: Installiere die API und richte die Authentifizierung ein.
Du brauchst Python 3.9 oder höher. Installiere das Google Generative AI SDK und die Abhängigkeiten:
pip install google-genai python-dotenv
Hol dir deinen API-Schlüssel von Google AI Studio. Speicher es in einer .env-Datei in deinem Projektverzeichnis:
GOOGLE_API_KEY=your_api_key_here
Richte deine Importe ein und starte den Client:
from google import genai
from google.genai import types
import time
from dotenv import load_dotenv
load_dotenv()
client = genai.Client()
Der Dienst „ genai.Client() “ macht die Authentifizierung automatisch über deine Umgebungsvariable. Du wirst dieses Client-Objekt für alle Dateisuche-Operationen benutzen.
Schritt 2: Erstell einen Dateisuchspeicher
Mach einen Speicherplatz für deine indizierten Dokumente:
file_search_store = client.file_search_stores.create(
config={"display_name": "fda-drug-labels"}
)
print(f"Created store: {file_search_store.name}")
Ein Dateisuchspeicher ist wie ein Container für deine indizierten Dokumente. Im Gegensatz zu temporären Datei-Uploads, die nach 48 Stunden ablaufen, bleiben Stores für immer da. Das heißt, du kannst Dokumente einmal indexieren und dann tausende Male abfragen, ohne sie nochmal hochladen oder bearbeiten zu müssen.
Die URL „ file_search_store.name “ hat eine eindeutige Kennung, die du bei der Abfrage verwenden musst. Es sieht aus wie fileSearchStores/fdadruglabels-abc123. Speicher diesen Wert, wenn du den Shop von einer anderen Sitzung aus abfragen musst.
Schritt 3: PDF-Dokumente hochladen und indexieren
Für dieses Tutorial arbeitest du mit drei von der FDA zugelassenen Arzneimitteletiketten. Lade diese PDFs von der FDA-Website runter:
- Metformin (Glucophage) – Medikament gegen Diabetes
- Atorvastatin (Lipitor) - Cholesterin-Medikament
- Lisinopril (Zestril) - Medikament gegen Bluthochdruck
Speicher sie in deinem Projektverzeichnis und lade sie dann in deinen Dateisuchspeicher hoch:
pdf_files = ["metformin.pdf", "atorvastatin.pdf", "lisinopril.pdf"]
for pdf_file in pdf_files:
operation = client.file_search_stores.upload_to_file_search_store(
file=pdf_file,
file_search_store_name=file_search_store.name,
config={"display_name": pdf_file.replace(".pdf", "")},
)
# Wait for indexing to complete
while not operation.done:
time.sleep(3)
operation = client.operations.get(operation)
print(f"{pdf_file} indexed")
Beim Hochladen zerlegt die Dateisuche jede PDF-Datei in Teile und wandelt die Segmente mit dem Modell „ gemini-embedding-001 “ in Einbettungen um. Diese„ “-Einbettungen sind numerische Darstellungen, die die Bedeutung erfassen, sodass das System relevante Stellen findet, auch wenn deine Frage nicht genau dem Wortlaut im Dokument entspricht.
Das Abfragemuster (while not operation.done) kümmert sich um die asynchrone Natur der Indizierung. Große Dokumente brauchen länger, um verarbeitet zu werden, also kommt die API sofort zurück, und du checkst regelmäßig, ob sie fertig ist. Bei Produktionssystemen solltest du überlegen, eine Timeout-Logik einzubauen, um Endlosschleifen zu vermeiden.
Jeder Chunk behält die Metadaten, die ihn mit seinem Quelldokument und seiner Position verbinden. Diese Metadaten sind wichtig, wenn du später auf Zitate zugreifst.
Schritt 4: Abfrage nach Infos zu einem einzelnen Dokument
Jetzt kannst du deine indizierten Dokumente abfragen:
query1 = "What are the contraindications for metformin?"
response1 = client.models.generate_content(
model="gemini-2.5-flash",
contents=query1,
config=types.GenerateContentConfig(
tools=[
types.Tool(
file_search=types.FileSearch(
file_search_store_names=[file_search_store.name]
)
)
]
),
)
print(response1.text)
Das gibt die erstellte Antwort aus:
Metformin is contraindicated in several conditions:
* Severe renal impairment (eGFR below 30 mL/min/1.73 m2)
* Acute or chronic metabolic acidosis
* Hypersensitivity to metformin
Die Dateisuche findet die semantisch ähnlichsten Teile in deinen Dokumenten und gibt sie als Kontext an „ gemini-2.5-flash “ weiter, das dann die Antwort generiert. Die Array-Konfiguration „ tools “ sagt dem Modell, dass es bei der Generierung die Dateisuche nutzen soll. Du kannst die Dateisuche mit anderen Tools wie der Codeausführung oder der Google-Suche in derselben Anfrage kombinieren.
Schritt 5: Zugriff auf Zitate und grundlegende Metadaten
Zusammenfassung der Dokumente, die die Antwort beeinflusst haben:
print("Sources used:")
for i, chunk in enumerate(response1.candidates[0].grounding_metadata.grounding_chunks, 1):
source_name = chunk.retrieved_context.title
print(f" [{i}] {source_name}")
Ausgabe:
Sources used:
[1] metformin
[2] atorvastatin
Jeder Abschnitt in den Metadaten enthält den Titel des Quelldokuments und die genaue Textstelle, auf die sich die Antwort bezieht. Dadurch entsteht ein Verifizierungspfad von der generierten Antwort zurück zu deinen Originaldokumenten – wichtig für medizinische, rechtliche oder finanzielle Anwendungen, bei denen es auf Genauigkeit ankommt.
Das Array „ grounding_chunks “ hat alle gefundenen Passagen, sortiert nach Relevanz. Obwohl die Anfrage speziell nach Metformin fragt, hat die Dateisuche auch Inhalte aus dem Atorvastatin-Dokument gefunden, wahrscheinlich weil es ähnliche Kontraindikationsinfos enthält. Das zeigt, wie die semantische Suche funktioniert: Das System findet nicht nur Inhalte, die mit den Suchbegriffen übereinstimmen, sondern auch solche, die inhaltlich zusammenhängen.
Schritt 6: Suche über mehrere Dokumente hinweg
Teste eine Frage zu Wechselwirkungen zwischen mehreren Medikamenten:
query2 = "Can a patient take both atorvastatin and metformin together? Are there any drug interactions?"
response2 = client.models.generate_content(
model="gemini-2.5-flash",
contents=query2,
config=types.GenerateContentConfig(
tools=[
types.Tool(
file_search=types.FileSearch(
file_search_store_names=[file_search_store.name]
)
)
]
),
)
print(response2.text)
Das gleiche API-Muster holt jetzt Infos aus mehreren Dokumenten und setzt sie zusammen. Hier kannst du auf die gefundenen Textausschnitte zugreifen:
print("Sources used:")
for i, chunk in enumerate(response2.candidates[0].grounding_metadata.grounding_chunks, 1):
source_name = chunk.retrieved_context.title
source_text = chunk.retrieved_context.text[:100] + "..."
print(f" [{i}] {source_name}")
print(f" {source_text}")
Die Ausgabe zeigt Auszüge aus beiden Arzneimitteletiketten:
Sources used:
[1] atorvastatin
Concomitant use with diabetes medications is generally safe but monitor glucose levels...
[2] metformin
Carbonic anhydrase inhibitors may increase the risk of lactic acidosis...
Die Dateisuche findet relevante Abschnitte aus beiden Dokumenten, und das Modell setzt sie zu einer zusammenhängenden Antwort zusammen. Das Attribut „retrieved_context.text” zeigt dir genau die verwendete Passage an, sodass du überprüfen kannst, ob das Modell keine falschen Infos erfunden hat.
Schritt 7: Dokumentübergreifende Vergleiche durchführen
Stell eine Frage, die einen Vergleich aller drei Dokumente erfordert:
query3 = "Which medications have muscle-related side effects?"
response3 = client.models.generate_content(
model="gemini-2.5-flash",
contents=query3,
config=types.GenerateContentConfig(
tools=[
types.Tool(
file_search=types.FileSearch(
file_search_store_names=[file_search_store.name]
)
)
]
),
)
print(response3.text)
# Check which documents were consulted
metadata = response3.candidates[0].grounding_metadata
for i, chunk in enumerate(metadata.grounding_chunks, 1):
print(f" [{i}] {chunk.retrieved_context.title}")
Das Ergebnis zeigt, dass Atorvastatin Nebenwirkungen auf die Muskeln haben kann (Muskelschmerzen, Muskelerkrankungen, Rhabdomyolyse) und bestätigt, dass die anderen Medikamente solche Nebenwirkungen nicht haben. Die Metadaten zeigen, dass die Dateisuche alle drei Dokumente durchsucht hat, um die Vergleichsfrage zu beantworten.
Du hast jetzt einen funktionierenden Assistenten für medizinische Dokumentation erstellt. Der grundlegende Arbeitsablauf bleibt gleich: Richte das Tool „Dateisuche“ in deinem Aufruf „ generate_content() “ ein, hol dir den Antworttext und schau dir die Metadaten zur Überprüfung an. Der Speicher bleibt auf den Servern von Google, sodass du ihn in zukünftigen Sitzungen abfragen kannst, ohne ihn neu indizieren zu müssen.
Als Nächstes lernst du fortgeschrittene Funktionen wie benutzerdefinierte Chunking-Konfigurationen und Metadatenfilterung kennen, mit denen du das Abrufverhalten genauer steuern kannst.
Erweiterte Funktionen und Anpassungsmöglichkeiten des Google-Dateisuchtools
Der grundlegende Workflow für die Dateisuche deckt die meisten Anwendungsfälle ab, aber Produktionssysteme brauchen oft eine genauere Kontrolle über das Abrufverhalten. Hier erfährst du, wie du Chunking-Strategien anpassen, Dokumente mit Metadaten filtern, die Leistung optimieren und mehrere Speicher für verschiedene Anwendungsfälle verwalten kannst.
Benutzerdefinierte Chunking-Konfiguration
Die Dateisuche teilt Dokumente beim Indexieren automatisch in Teile auf. Standardmäßig wird eine für allgemeine Dokumente optimierte Chunking-Strategie verwendet, aber du kannst dieses Verhalten anpassen, wenn bestimmte Dokumenttypen eine andere Behandlung brauchen.
Schau dir mal das Beispiel der medizinischen Assistenz an. Arzneimitteletiketten haben viele technische Infos in Tabellen und kurzen Absätzen. Mit kleineren Abschnitten kannst du genaue Infos wie bestimmte Dosierungen oder Gegenanzeigen finden, ohne dass du irrelevante Infos mitbekommst. Größere Abschnitte eignen sich besser für erzählerische Teile, bei denen man mehr Kontext braucht, um sie richtig zu verstehen.
Stell beim Hochladen von Dokumenten die Chunking-Parameter ein:
operation = client.file_search_stores.upload_to_file_search_store(
file="metformin.pdf",
file_search_store_name=file_search_store.name,
config={
"display_name": "metformin",
"chunking_config": {
"white_space_config": {
"max_tokens_per_chunk": 200,
"max_overlap_tokens": 20
}
}
}
)
Der Parameter „ chunking_config “ legt fest, wie die Dateisuche deine Dokumente aufteilt. Der Parameter „ max_tokens_per_chunk “ legt die maximale Größe jedes Chunks fest, während „ max_overlap_tokens “ bestimmt, wie viel Inhalt sich zwischen aufeinanderfolgenden Chunks überschneidet. Diese Überlappung sorgt dafür, dass Infos, die über mehrere Blöcke verteilt sind, beim Abrufen nicht verloren gehen.
Der Kompromiss ist wichtig: Kürzere Abschnitte sorgen für ein genaueres Auffinden, können aber den größeren Zusammenhang verfehlen, während längere Abschnitte mehr Bedeutung behalten, aber auch irrelevante Infos enthalten können.
Für technische Doks mit klaren Abschnittsgrenzen nimm lieber kleinere Teile (150–250 Token). Bei Texten wie Forschungsarbeiten oder Berichten helfen größere Abschnitte (400–600 Token) dabei, den Argumentationsfluss und den Kontext zu behalten. Die offizielle Dokumentation zur Dateisuche gibt dir noch mehr Tipps, wie du die Chunk-Größen für verschiedene Dokumenttypen auswählst.
Metadaten-Filterung
Wenn dein Shop Dutzende oder Hunderte von Dokumenten hat, schränkt die Metadatenfilterung den Suchbereich ein, bevor die semantische Suche losgeht. Das macht die Sache genauer und spart Zeit bei der Bearbeitung.
Füge beim Hochladen von Dokumenten Metadaten hinzu, damit du sie später filtern kannst:
operation = client.file_search_stores.upload_to_file_search_store(
file="metformin.pdf",
file_search_store_name=file_search_store.name,
config={
"display_name": "metformin",
"custom_metadata": [
{"key": "category", "string_value": "diabetes"},
{"key": "year", "numeric_value": 2017},
{"key": "drug_class", "string_value": "biguanide"}
]
}
)
Der Parameter „ custom_metadata “ nimmt ein Array von Schlüssel-Wert-Paaren an. Verwende „ string_value “ für Textmetadaten wie Kategorien oder Arzneimittelklassen und „ numeric_value “ für Jahre, Versionen oder andere numerische Daten.
Frag mit Metadatenfiltern, um nur relevante Dokumente zu finden:
query = "What are the common side effects?"
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=query,
config=types.GenerateContentConfig(
tools=[
types.Tool(
file_search=types.FileSearch(
file_search_store_names=[file_search_store.name],
metadata_filter="category=diabetes"
)
)
]
)
)
Der Parameter „ metadata_filter “ schränkt die Suche auf Dokumente ein, die den angegebenen Kriterien entsprechen. In diesem Beispiel sucht die Dateisuche nur nach Dokumenten mit „ category=diabetes “ und lässt die Medikamente für Blutdruck und Cholesterin links liegen, obwohl sie im selben Shop zu finden sind.
Das ist besonders wichtig, wenn die Speicher heterogene Dokumente enthalten. Eine medizinische Wissensdatenbank kann zum Beispiel Medikamentenbeipackzettel, Forschungsberichte und klinische Leitlinien enthalten. Durch das Filtern nach Dokumenttyp stellst du sicher, dass du Dosierungsinfos von Etiketten bekommst und nicht aus Forschungszusammenfassungen.
Du kannst die Metadatenfilterung mit der kompletten semantischen Suchfunktion kombinieren. Der Filter läuft zuerst, um passende Dokumente zu finden, und dann sucht die semantische Suche die relevantesten Stellen in diesen Dokumenten.
Leistungsoptimierung
Die Leistung der Dateisuche hängt von der Größe des Speichers, der Komplexität der Abfrage und der Wahl des Modells ab. Wenn du diese Tipps befolgst, bleibt der Abruf schnell und die Kosten überschaubar.
Größenbeschränkungen für Shops: Halte einzelne Speicher unter 20 GB, um die Abruflatenz optimal zu halten. Die Dateisuche speichert Einbettungen zusammen mit deinen Dokumenten, und Einbettungen brauchen ungefähr dreimal so viel Speicherplatz wie deine Originaldateien. Eine 7 GB große Sammlung von PDF-Dateien nimmt nach der Indizierung ungefähr 21 GB Speicherplatz ein und geht damit über die empfohlene Grenze hinaus.
Wenn du dich dieser Grenze näherst, richte separate Speicherorte ein, die nach Kategorie, Zeitraum oder Zugriffsmuster organisiert sind. Für die medizinische Assistenz kannst du separate Lager für verschiedene Medikamentenkategorien einrichten, anstatt alle verfügbaren Medikamente in einem einzigen Lager zu erfassen.
Kostenstruktur: Die Dateisuche kostet 0,15 $ pro 1 Million Token für die Indizierung. Sobald die Indizierung abgeschlossen ist, kannst du Tausende von Abfragen ohne zusätzliche Indizierungskosten ausführen. Dieses Preismodell ist super für Workloads, bei denen du oft dieselben Dokumente abrufst.
Modellauswahl: Für die meisten Fragen kannst du gemini-2.5-flash nutzen. Es verarbeitet Anfragen in 1–2 Sekunden und kostet deutlich weniger als gemini-2.5-pro. Benutze „ gemini-2.5-pro “, wenn du Fragen hast, die ein tiefes Verständnis mehrerer Quellen erfordern oder super komplexe Syntheseaufgaben bearbeiten musst. Bei Anwendungen mit hohem Volumen ist der Preisunterschied zwischen den Modellen wichtiger als die Indexierungskosten.
Behalte die Größe des Speichers im Auge, wenn du Dokumente hinzufügst. Du kannst das über die API checken, aber die Größenberechnung läuft im Hintergrund bei Google und wird vielleicht nicht sofort nach dem Hochladen angezeigt. Die kompletten technischen Spezifikationen und Einschränkungen findest du in der Dokumentation zur Gemini-Datei-API.
Mehrere Läden verwalten
Jedes Google Cloud-Projekt kann bis zu 10 Dateisuchspeicher haben. Mit mehreren Speichern kannst du Dokumente nach Zugriffskontrolle, Leistungsanforderungen oder logischer Organisation sortieren.
Mach dir spezielle Shops für verschiedene Anwendungsfälle:
# Create separate stores for different document categories
diabetes_store = client.file_search_stores.create(
config={"display_name": "diabetes-medications"}
)
cardio_store = client.file_search_stores.create(
config={"display_name": "cardiovascular-medications"}
)
Frage mehrere Shops mit einer einzigen Anfrage ab:
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="What medications treat both diabetes and heart disease?",
config=types.GenerateContentConfig(
tools=[
types.Tool(
file_search=types.FileSearch(
file_search_store_names=[
diabetes_store.name,
cardio_store.name
]
)
)
]
)
)
Die Dateisuche durchsucht alle angegebenen Speicherorte und fasst die Ergebnisse zusammen. Die Metadaten zeigen, aus welchem Speicher jede Quelle kommt, sodass alles nachverfolgt werden kann.
Stores bleiben ewig bestehen und müssen manuell gelöscht werden, wenn sie nicht mehr gebraucht werden. Deshalb sind sie gut für Produktionsanwendungen, wo Dokumente über verschiedene Sitzungen und Bereitstellungen hinweg abrufbar bleiben müssen.
Als Nächstes zeig ich dir, wie File Search im Vergleich zu anderen RAG-Lösungen abschneidet und wann du dich für einen verwalteten Ansatz und wann für einen DIY-Ansatz entscheiden solltest.
Google-Dateisuchtool im Vergleich zu anderen Dateisuch- und RAG-Tools
Die Dateisuche ist nicht die einzige Möglichkeit, RAG-Anwendungen zu erstellen. Wenn du weißt, wie es im Vergleich zu anderen Optionen abschneidet, kannst du das richtige Tool auswählen. Schauen wir mal, wie Googles Ansatz im Vergleich zu dem von OpenAI und den üblichen maßgeschneiderten Lösungen aussieht.
|
Feature |
Google-Dateisuche |
OpenAI-Dateisuche |
Custom RAG (LangChain) |
|
Preismodell |
0,15 $/M Token (nur Index) |
0,10/GB täglicher Speicherplatz |
Infrastruktur + Entwicklungskosten |
|
Chunking-Steuerung |
Automatisiert mit einfacher Konfiguration |
Konfigurierbar (800 Token Standard, 400 Überlappung) |
Volle Kontrolle über die Strategie |
|
Suchtyp |
Semantik (nur Vektor) |
Hybrid (Vektor + Schlüsselwort) |
Jede Methode, die du umsetzt |
|
Dateiformate |
Über 150 Typen (PDF, DOCX, Code usw.) |
6 Typen (TXT, MD, HTML, DOCX, PPTX, PDF) |
Kommt drauf an, welche Parser man benutzt |
|
Einrichtungszeit |
Protokoll |
Protokoll |
Tage bis Wochen |
|
Zitate |
Integriert mit Erdungsmetadaten |
Built-in |
Muss selbst umgesetzt werden |
|
Am besten geeignet für |
Viele Anfragen, schnelle Bereitstellung |
Suchanfragen mit vielen Keywords, mittlere Kontrolle |
Komplexe Anforderungen, komplette Anpassung |
Google-Dateisuche vs. OpenAI-Dateisuche
Beide Firmen bieten gehostete RAG an, aber sie haben unterschiedliche Ansätze bei den Preisen und Funktionen.
Preise: Google berechnet dir während der Indizierung einmalig eine Gebühr (2,50 $ pro tausend Abfragen plus 0,10 $ pro GB täglich für die Speicherung). Wenn du viele Abfragen machst, aber Dokumente nur selten aktualisierst, sparst du mit dem Modell von Google Geld. Wenn du ständig neu indexierst, wird die Rechnung interessant.
Konfigurationskontrolle: Google macht es einfach mit automatischem Chunking und wenig Konfigurationsaufwand. OpenAI gibt dir mehr Kontrolle. Du kannst die Chunk-Größe (Standardwert: 800 Tokens) und die Überlappung (400 Tokens) einstellen. OpenAI nutzt auch eine hybride Suche, die Vektor- und Stichwortabgleich kombiniert, während Google nur auf semantische Suche setzt. Das ist wichtig, wenn deine Suchanfragen bestimmte Fachbegriffe oder Produktcodes enthalten.
Dateiformate: Google kann über 150 Dateitypen verarbeiten, darunter Code-Dateien und verschiedene Dokumentformate. OpenAI unterstützt sechs: TXT, MD, HTML, DOCX, PPTX und PDF. Keiner von beiden kann gut mit strukturierten Daten wie CSV oder JSONL umgehen. Da kommen maßgeschneiderte Lösungen voll zur Geltung.
Integration: Google ist mit Gemini-Modellen und Google Cloud-Diensten verbunden. OpenAI verbindet sich mit ihrer Modellfamilie und Azure. Beide bieten dir Zitierfunktionen und Quellenverfolgung.
Der eigentliche Unterschied ist einfach: Einfachheit oder Kontrolle. Google packt alles in einen einzigen API-Aufruf. Mit OpenAI kannst du die Suche optimieren, aber das macht die Sache komplizierter. Hier gibt's keinen einzigen Gewinner. Es kommt drauf an, ob du bei deinem Projekt auf Geschwindigkeit oder Individualisierung setzen willst.
Benutzerdefinierte RAG-Funktionen
Wenn du dein eigenes RAG-System mit Tools wie LangChain aufbaust, kannst du Sachen machen, die dir bei gehosteten Diensten nicht möglich sind. DataCamp's RAG mit LangChain geht detailliert auf diesen Ansatz ein.
Maßgeschneiderte Konstruktionen ermöglichen fortgeschrittene Techniken:
- Semantische Aufteilung die erkennt, wenn sich Themen ändern, anstatt nach festen Längen zu schneiden
- Token-bewusstes Chunking , das die Kontextfenster des Modells genau berücksichtigt
- Hybride Suche Kombination von BM25-Stichwortsuche mit dichten Vektoren
- Abfrageumwandlungen wie HyDE, die hypothetische Antworten generieren, um die Suche zu verbessern
- Graph RAG Dokumente als Netzwerke von Entitäten und Beziehungen darstellen
Das Tutorial von DataCamp zur Verbesserung der RAG-Leistung zeigt diese Techniken anhand von Beispielen, die messbare Qualitätsverbesserungen zeigen. Der Nachteil ist die Komplexität des Betriebs: Du musst die Datenbankleistung überwachen, Einbettungsmodelle optimieren und Updates über mehrere Dienste hinweg verwalten.
Wann man welchen Ansatz nimmt
Nimm gehostete Tools wie die Dateisuche, wenn:
- Entwickle Prototypen oder Proof-of-Concepts, wenn es auf Schnelligkeit ankommt
- Dein Anwendungsfall passt zu den Standardmustern (Fragen und Antworten zu Dokumenten, Wissensdatenbanken, Dokumentationssuche).
- Deinem Team fehlt es an fundiertem RAG-Know-how.
- Du willst vorhersehbare Kosten und minimalen Betriebsaufwand.
Erstell eine benutzerdefinierte Version, wenn:
- Du brauchst fortgeschrittene Chunking- oder spezielle Abrufmethoden.
- Arbeiten mit strukturierten Daten oder ungewöhnlichen Dateiformaten
- Agentisches RAG Agentische RAG Systeme, die mehrere Strategien kombinieren
- Die Optimierung der Kosten in großem Maßstab macht Investitionen in die Technik sinnvoll.
- Die Einhaltung von Vorschriften braucht bestimmte Infrastrukturen oder Modelle.
Die meisten Projekte fangen mit gehosteten Lösungen an und wechseln nur dann zu maßgeschneiderten Lösungen, wenn es die Anforderungen brauchen. Die Techniken aus dem benutzerdefinierten RAG (Smart Chunking, Hybrid Search, Query Optimization) beeinflussen immer noch, wie du gehostete Tools nutzt. Wenn du die ganze Situation verstehst, kannst du bessere Entscheidungen treffen, wenn sich deine Bedürfnisse ändern.
Fazit
Du hast mit dem Google File Search Tool ein komplettes RAG-System aufgebaut, von der Indizierung von FDA-Arzneimitteletiketten bis hin zur Abfrage mit Zitaten. Der medizinische Assistent zeigt dir, wie Managed Services die Infrastruktur verwalten, während du dich auf die Anwendungslogik konzentrieren kannst.
Die Dateisuche ist super, wenn du ein zuverlässiges RAG brauchst, ohne Vektordatenbanken oder Einbettungspipelines verwalten zu müssen. Die kostenlosen Speicher- und Abfrage-Einbettungen machen die Kosten überschaubar. Persistente Speicher machen das erneute Indizieren überflüssig, sodass du Abfragen skalieren kannst, ohne die Infrastrukturwartung zu erhöhen.
Bevor du das Ding in der Produktion einsetzt, solltest du ein paar wichtige Sicherheitsmaßnahmen einbauen, die im Tutorial aus Platzgründen weggelassen wurden. Führ eine Fehlerbehandlung mit Zeitüberschreitungen für Upload-Vorgänge und Try-Catch-Blöcken um API-Aufrufe herum ein. Denk an die Datenschutzauswirkungen, wenn du Dokumente auf die Server von Google hochlädst, vor allem bei sensiblen Inhalten. Füge eine Überprüfung hinzu, um sicherzustellen, dass die Metadaten vorhanden sind, bevor auf Zitate zugegriffen wird. Teste das Modell gründlich mit Fachleuten, um Fälle zu finden, in denen das Modell trotz Fundierung plausible, aber falsche Antworten liefert.
Als Nächstes kannst du versuchen, deinen Assistenten um Metadatenfilterung zu erweitern, um Dokumente nach Kategorien zu sortieren. Probier verschiedene Chunk-Größen aus, um sie an deine Dokumenttypen anzupassen. Die Techniken, die du hier gelernt hast, kannst du überall anwenden, egal ob du Support-Bots, Dokumentationssuchfunktionen oder Wissensassistenten entwickelst.
FAQs
Muss ich neu indexieren, wenn sich ein Dokument ändert?
Ja. Um eine Datei zu aktualisieren oder zu ersetzen, musst du sie nochmal hochladen, damit die Einbettungen den neuen Inhalt zeigen.
Kann ich den Zugriff auf bestimmte Dokumente regeln?
Noch nicht auf einer detaillierten Ebene. Du kannst Metadatenfilter nutzen, um die abgefragten Dokumente einzuschränken, aber Berechtigungen auf Benutzerebene werden momentan nicht unterstützt.
Was sind die Beschränkungen für Datei- und Speichergröße?
Einzelne Dateien können bis zu etwa 100 MB groß sein, und die Speicherstufen reichen bis zu ungefähr 1 TB. Wenn du die Speicher unter 20 GB hältst, geht das Abrufen meistens schneller.
Wie zuverlässig sind die Zitate?
Die Dateisuche fügt Metadaten hinzu, die zeigen, welche Teile des Dokuments zu einer Antwort geführt haben. Diese Zitate machen die Sache übersichtlicher, sollten aber trotzdem auf ihre Richtigkeit überprüft werden.
Benutzt die Dateisuche Stichwörter oder Vektorabfrage?
Es nutzt eine semantische (vektorbasierte) Suche. Wenn du eine exakte Keyword-Übereinstimmung brauchst, musst du eine benutzerdefinierte oder hybride Suchkonfiguration einrichten.

Ich bin ein Data Science Content Creator mit über 2 Jahren Erfahrung und einem der größten Follower auf Medium. Ich schreibe gerne ausführliche Artikel über KI und ML mit einem etwas sarkastischen Stil, denn man muss etwas tun, damit sie nicht so langweilig sind. Ich habe mehr als 130 Artikel verfasst und einen DataCamp-Kurs gemacht, ein weiterer ist in Vorbereitung. Meine Inhalte wurden von über 5 Millionen Augenpaaren gesehen, von denen 20.000 zu Followern auf Medium und LinkedIn wurden.

