Google फ़ाइल सर्च टूल ट्यूटोरियल: Gemini API के साथ RAG एप्लिकेशन बनाएँ

इस ट्यूटोरियल में, मैं आपको Google File Search के साथ एक मेडिकल डॉक्यूमेंटेशन असिस्टेंट बनाना सिखाऊँगा। आप देखेंगे कि इसे कैसे सेट करें, क्वेरी कैसे चलाएँ, और कस्टम चंकिंग तथा मेटाडेटा फ़िल्टरिंग जैसी उन्नत सुविधाओं का उपयोग कैसे करें। अंत तक, आप समझेंगे कि मैनेज्ड RAG कब उपयुक्त है और कब अपना स्टैक बनाना बेहतर होता है।

Google File Search Tool क्या है?

RAG एप्लिकेशन बनाते समय आमतौर पर वेक्टर डेटाबेस, एम्बेडिंग पाइपलाइनों और भारी इन्फ्रास्ट्रक्चर से जूझना पड़ता है। नवंबर 2025 में जारी Google का File Search टूल इस जटिलता को दूर करता है क्योंकि यह पूरी तरह से मैनेज्ड RAG सिस्टम सीधे Gemini API में उपलब्ध कराता है।

यह टूल आपके लिए जटिल हिस्सों को संभालता है: दस्तावेज़ों की चंकिंग, एम्बेडिंग बनाना, और Pinecone या ChromaDB जैसे बाहरी टूल की आवश्यकता के बिना सैमंटिक सर्च मैनेज करना। वर्कफ़्लो सीधा है—फ़ाइलें अपलोड करें, स्टोर बनाएँ, और क्वेरी करना शुरू करें। आपको बिल्ट-इन सिटेशंस भी मिलते हैं, जो यह सत्यापित करने देते हैं कि उत्तर कहाँ से आया है।

RAG को समझना और Google इसे कैसे सरल बनाता है

Gemini File Search खुद को एक मैनेज्ड RAG सिस्टम के रूप में प्रस्तुत करता है। RAG को समझना आपको इस टूल का बेहतर उपयोग करने और यह तय करने में मदद करता है कि यह आपके उपयोग केस में फिट बैठता है या नहीं।

मूल रूप से, रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) भाषा मॉडलों को बाहरी ज्ञान से जोड़ता है। उत्तर जनरेट करने से पहले, मॉडल आपके दस्तावेज़ों से प्रासंगिक जानकारी रिट्रीव करता है, ताकि जवाब केवल ट्रेनिंग डेटा पर निर्भर रहने के बजाय आपके वास्तविक डेटा में ग्राउंडेड हों।

DIY RAG की चुनौती

हालाँकि अवधारणा में RAG सीधा लगता है, अपनी RAG पाइपलाइन बनाना कई घटकों को मैनेज करना होता है:

• वेक्टर डेटाबेस: Pinecone, ChromaDB या Weaviate जैसी सेवाओं को सेटअप और मेंटेन करना ताकि एम्बेडिंग्स स्टोर की जा सकें
• एम्बेडिंग पाइपलाइंस: दस्तावेज़ों को संख्यात्मक वेक्टर में बदलना और कंटेंट बदलने पर अपडेट संभालना
• चंकिंग रणनीतियाँ: दस्तावेज़ों को ऐसे हिस्सों में बाँटना जो संदर्भ और रिट्रीवल की शुद्धता के बीच संतुलन बनाएँ
• इन्फ्रास्ट्रक्चर: प्रदर्शन की मॉनिटरिंग, पैरामीटर ट्यूनिंग, और डेटा बढ़ने पर स्केलिंग संभालना

हर घटक के लिए विशेषज्ञता और लगातार मेंटेनेंस चाहिए। आप चाहे विश्वसनीय प्रोडक्शन सिस्टम बना रहे हों या तेज़ी से प्रोटोटाइप, इन्फ्रास्ट्रक्चर का ओवरहेड समान बाधा बना रहता है।

मैनेज्ड RAG क्यों महत्वपूर्ण है

Google File Search जैसी मैनेज्ड सेवाएँ इस बाधा को दूर करती हैं। रिट्रीवल ट्यून करने के बजाय, आप क्वेरी लिखते हैं। एम्बेडिंग पाइपलाइन डिबग करने के बजाय, आप परिणाम वैलिडेट करते हैं। इन्फ्रास्ट्रक्चर बैकग्राउंड में चलता है और आप एप्लिकेशन लॉजिक पर ध्यान देते हैं।

Gemini File Search तकनीकी जटिलता संभालता है जबकि आप मुख्य बातों को नियंत्रित करते हैं: किन दस्तावेज़ों को इंडेक्स करना है, उन्हें कैसे क्वेरी करना है, और परिणामों का उपयोग कैसे करना है। जब आपको ऑपरेशनल ओवरहेड के बिना प्रोडक्शन क्वालिटी चाहिए, तब यह संतुलन अच्छी तरह काम करता है। RAG की बुनियादी जानकारी के लिए, मैं DataCamp का एजेंटिक RAG पर ट्यूटोरियल देखने की सलाह देता हूँ।

Google File Search को समझने का सबसे अच्छा तरीका है—इसे इस्तेमाल करना। अगले भाग में, आप एक पूरा मेडिकल डॉक्यूमेंटेशन असिस्टेंट बनाएँगे जो दस्तावेज़ अपलोड से लेकर सिटेशंस के साथ ग्राउंडेड जवाब तक का पूरा वर्कफ़्लो दिखाता है।

Google File Search के साथ मेडिकल डॉक्यूमेंटेशन असिस्टेंट बनाना

अस्वीकरण: यह ट्यूटोरियल केवल शैक्षिक उद्देश्यों के लिए FDA दवा लेबल का उपयोग करके File Search की क्षमताएँ दिखाता है। जो असिस्टेंट आप बनाएँगे, वह नैदानिक उपयोग, रोगी देखभाल निर्णय, या चिकित्सा निदान के लिए नहीं है। चिकित्सा सलाह के लिए हमेशा योग्य स्वास्थ्य पेशेवरों से परामर्श लें। स्रोत दस्तावेज़ों में ग्राउंडिंग होने पर भी AI सिस्टम गलत जानकारी जनरेट कर सकते हैं।

इस अनुभाग में आप File Search का उपयोग करके एक पूरा मेडिकल डॉक्यूमेंटेशन असिस्टेंट बनाएँगे। आप तीन सामान्य दवाओं के FDA लेबल्स के साथ काम करेंगे, और ऐसा सिस्टम बनाएँगे जो दवा इंटरैक्शन, साइड इफेक्ट्स, और कंट्रा-इंडिकेशंस से जुड़े प्रश्नों का उत्तर देता है। असिस्टेंट स्रोत दस्तावेज़ों के विशिष्ट अंशों का हवाला देकर सत्यापन योग्य उत्तर देता है।

File Search दो चरणों में काम करता है: आप अपने दस्तावेज़ों को एक बार इंडेक्स करते हैं, फिर उन्हें बार-बार क्वेरी करते हैं। आप पहले इंडेक्सिंग इन्फ्रास्ट्रक्चर सेट करेंगे, फिर पूरी तरह से प्रश्न पूछने और ग्राउंडेड उत्तरों की व्याख्या पर ध्यान देंगे।

चरण 1: API इंस्टॉल करें और ऑथेंटिकेशन कॉन्फ़िगर करें

आपको Python 3.9 या बाद का संस्करण चाहिए। Google Generative AI SDK और निर्भरताएँ इंस्टॉल करें:

pip install google-genai python-dotenv

अपनी API कुंजी Google AI Studio से प्राप्त करें। इसे अपनी प्रोजेक्ट डायरेक्टरी में .env फ़ाइल में सहेजें:

GOOGLE_API_KEY=your_api_key_here

अपने इम्पोर्ट सेट करें और क्लाइंट इनिशियलाइज़ करें:

from google import genai
from google.genai import types
import time
from dotenv import load_dotenv

load_dotenv()
client = genai.Client()

genai.Client() आपके एनवायरनमेंट वेरिएबल का उपयोग कर ऑथेंटिकेशन स्वतः संभालता है। आप File Search की सभी ऑपरेशंस के लिए इसी क्लाइंट ऑब्जेक्ट का उपयोग करेंगे।

चरण 2: एक File Search स्टोर बनाएँ

अपने इंडेक्स किए गए दस्तावेज़ों के लिए एक स्टोर बनाएँ:

file_search_store = client.file_search_stores.create(
    config={"display_name": "fda-drug-labels"}
)
print(f"Created store: {file_search_store.name}")

File Search स्टोर आपके इंडेक्स किए गए दस्तावेज़ों के लिए कंटेनर की तरह काम करता है। 48 घंटे बाद समाप्त होने वाले अस्थायी फ़ाइल अपलोड्स के विपरीत, स्टोर्स अनिश्चित काल तक बने रहते हैं। इसका अर्थ है कि आप दस्तावेज़ों को एक बार इंडेक्स करते हैं और बिना पुनः-अपलोड या री-प्रोसेसिंग के उन्हें हज़ारों बार क्वेरी कर सकते हैं।

file_search_store.name में एक यूनिक आइडेंटिफ़ायर होता है जिसे आप क्वेरी करते समय संदर्भित करेंगे। यह fileSearchStores/fdadruglabels-abc123 जैसा दिखता है। यदि आपको किसी अन्य सत्र से स्टोर को क्वेरी करना हो, तो इस मान को सहेज लें।

चरण 3: PDF दस्तावेज़ अपलोड करें और इंडेक्स करें

इस ट्यूटोरियल के लिए, आप तीन FDA-अनुमोदित दवा लेबल्स के साथ काम करेंगे। ये PDF FDA वेबसाइट से डाउनलोड करें:

• Metformin (Glucophage) - मधुमेह की दवा
• Atorvastatin (Lipitor) - कोलेस्ट्रॉल की दवा
• Lisinopril (Zestril) - रक्तचाप की दवा

उन्हें अपनी प्रोजेक्ट डायरेक्टरी में सहेजें, फिर अपने File Search स्टोर में अपलोड करें:

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")

अपलोड के दौरान, File Search हर PDF को चंक्स में बाँटता है और इन सेगमेंट्स को gemini-embedding-001 मॉडल से एम्बेडिंग्स में बदलता है। ये एम्बेडिंग्स ऐसे संख्यात्मक रिप्रेज़ेंटेशन हैं जो सैमांटिक अर्थ को पकड़ते हैं, जिससे सिस्टम प्रासंगिक अंश ढूँढ सकता है, भले ही आपका प्रश्न दस्तावेज़ के शब्दों से हूबहू न मिलता हो।

पोलिंग पैटर्न (while not operation.done) इंडेक्सिंग की असिंक्रोनस प्रकृति को संभालता है। बड़े दस्तावेज़ों को प्रोसेस करने में अधिक समय लगता है, इसलिए API तुरंत रिटर्न करती है और आप समय-समय पर कंप्लीशन स्टेटस जाँचते हैं। प्रोडक्शन सिस्टम के लिए, अनंत लूप से बचने हेतु टाइमआउट लॉजिक जोड़ने पर विचार करें।

प्रत्येक चंक मेटाडेटा को सुरक्षित रखता है जो उसे उसके स्रोत दस्तावेज़ और पोज़ीशन से जोड़ता है। बाद में सिटेशंस एक्सेस करते समय यह मेटाडेटा महत्वपूर्ण हो जाता है।

चरण 4: एकल दस्तावेज़ से जानकारी क्वेरी करें

अब अपने इंडेक्स किए गए दस्तावेज़ों को क्वेरी करें:

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)

यह जनरेट किया गया उत्तर प्रिंट करता है:

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

File Search आपके दस्तावेज़ों में सबसे सैमांटिक रूप से मिलते-जुलते चंक्स रिट्रीव करता है और उन्हें gemini-2.5-flash को संदर्भ के रूप में देता है, जो उत्तर जनरेट करता है। tools एरे कॉन्फ़िगरेशन मॉडल को जेनरेशन के दौरान File Search उपयोग करने को कहता है। आप उसी रिक्वेस्ट में File Search को अन्य टूल्स जैसे कोड एग्ज़ीक्यूशन या Google Search के साथ संयोजित कर सकते हैं।

चरण 5: सिटेशंस और ग्राउंडिंग मेटाडेटा एक्सेस करें

यह जानें कि किन दस्तावेज़ों ने उत्तर को सूचित किया:

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}")

आउटपुट:

Sources used:
  [1] metformin
  [2] atorvastatin

ग्राउंडिंग मेटाडेटा में प्रत्येक चंक में स्रोत दस्तावेज़ का शीर्षक और वह विशिष्ट पाठ्यांश शामिल होता है जिसने उत्तर को सूचित किया। यह जनरेटेड उत्तर से लेकर आपके मूल दस्तावेज़ों तक एक सत्यापन पथ बनाता है—यह चिकित्सा, कानूनी या वित्तीय अनुप्रयोगों में आवश्यक है जहाँ सटीकता मायने रखती है।

grounding_chunks एरे में सभी रिट्रीव्ड पैसेज शामिल होते हैं, प्रासंगिकता के अनुसार क्रमित। भले ही क्वेरी विशेष रूप से मेटफॉर्मिन के बारे में पूछती है, File Search ने एटोरवास्टेटिन दस्तावेज़ से भी कंटेंट रिट्रीव किया, संभवतः क्योंकि उसमें संबंधित कंट्रा-इंडिकेशन सूचना है। यह सैमंटिक रिट्रीवल दृष्टिकोण को दर्शाता है: सिस्टम केवल कीवर्ड मैच नहीं, बल्कि अवधारणात्मक रूप से संबंधित कंटेंट ढूँढता है।

चरण 6: एकाधिक दस्तावेज़ों पर क्वेरी करें

मल्टी-डॉक्यूमेंट दवा इंटरैक्शन प्रश्न आज़माएँ:

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)

उसी API पैटर्न से अब कई दस्तावेज़ों से जानकारी ली जाती है और संयोजित की जाती है। रिट्रीव्ड टेक्स्ट स्निपेट्स एक्सेस करें:

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}")

आउटपुट दोनों दवा लेबल्स के अंश दिखाता है:

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...

File Search दोनों दस्तावेज़ों से प्रासंगिक हिस्से रिट्रीव करता है, और मॉडल उन्हें एक सुसंगत उत्तर में संयोजित करता है। retrieved_context.text एट्रिब्यूट आपको वही सटीक पैसेज देता है जिसका उपयोग हुआ, जिससे आप सुनिश्चित कर सकते हैं कि मॉडल ने जानकारी गढ़ी नहीं है।

चरण 7: क्रॉस-डॉक्यूमेंट तुलना चलाएँ

एक विश्लेषणात्मक प्रश्न पूछें जिसके लिए सभी तीन दस्तावेज़ों की तुलना चाहिए:

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}")

आउटपुट बताता है कि एटोरवास्टेटिन में मांसपेशी-संबंधी साइड इफेक्ट्स (मायल्जिया, मायोपैथी, रैबडोमायोलिसिस) होते हैं और पुष्टि करता है कि अन्य दवाओं में ऐसे प्रभाव सूचीबद्ध नहीं हैं। ग्राउंडिंग मेटाडेटा दिखाता है कि तुलना वाले प्रश्न का उत्तर देने के लिए File Search ने तीनों दस्तावेज़ों से परामर्श किया।

अब आपने एक कामकाजी मेडिकल डॉक्यूमेंटेशन असिस्टेंट बना लिया है। मूल वर्कफ़्लो समान रहता है: अपनी generate_content() कॉल में File Search टूल कॉन्फ़िगर करें, प्रतिक्रिया टेक्स्ट प्राप्त करें, और सत्यापन के लिए ग्राउंडिंग मेटाडेटा एक्सेस करें। स्टोर Google के सर्वर पर स्थायी रूप से रहता है, इसलिए आप बिना पुनः-इंडेक्सिंग के भविष्य के सत्रों से भी इसे क्वेरी कर सकते हैं।

अगले भाग में, आप कस्टम चंकिंग कॉन्फ़िगरेशन और मेटाडेटा फ़िल्टरिंग जैसी उन्नत सुविधाएँ देखें گے जो रिट्रीवल व्यवहार पर अधिक सूक्ष्म नियंत्रण देती हैं।

Google File Search Tool: उन्नत फ़ीचर्स और कस्टमाइज़ेशन

बेसिक File Search वर्कफ़्लो अधिकांश उपयोग मामलों को कवर करता है, लेकिन प्रोडक्शन सिस्टम में अक्सर रिट्रीवल व्यवहार पर अधिक सूक्ष्म नियंत्रण चाहिए। इस भाग में आप चंकिंग रणनीतियाँ कस्टमाइज़ करना, मेटाडेटा से दस्तावेज़ फ़िल्टर करना, प्रदर्शन ऑप्टिमाइज़ करना, और अलग-अलग उपयोग मामलों के लिए कई स्टोर्स मैनेज करना सीखेंगे।

कस्टम चंकिंग कॉन्फ़िगरेशन

File Search इंडेक्सिंग के दौरान दस्तावेज़ों को स्वतः चंक्स में विभाजित करता है। डिफ़ॉल्ट रूप से यह सामान्य दस्तावेज़ों के लिए ऑप्टिमाइज़्ड चंकिंग रणनीति उपयोग करता है, लेकिन आप विशिष्ट दस्तावेज़ प्रकारों के लिए इस व्यवहार को कस्टमाइज़ कर सकते हैं।

मेडिकल असिस्टेंट उदाहरण पर विचार करें। दवा लेबल्स में तालिकाओं और छोटे पैराग्राफों में सघन तकनीकी जानकारी होती है। छोटे चंक्स आपको विशिष्ट डोज़ या कंट्रा-इंडिकेशंस जैसी सटीक जानकारी रिट्रीव करने देते हैं, बिना अप्रासंगिक संदर्भ खींचे। नैरेटिव सेक्शंस, जिन्हें समझने के लिए अधिक संदर्भ चाहिए, उनके लिए बड़े चंक्स बेहतर काम करते हैं।

दस्तावेज़ अपलोड करते समय चंकिंग पैरामीटर्स कॉन्फ़िगर करें:

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
            }
        }
    }
)

chunking_config पैरामीटर यह नियंत्रित करता है कि File Search आपके दस्तावेज़ों को कैसे बाँटे। max_tokens_per_chunk प्रत्येक चंक का अधिकतम आकार सेट करता है, जबकि max_overlap_tokens लगातार चंक्स के बीच कितना कंटेंट ओवरलैप होगा, यह निर्धारित करता है। यह ओवरलैप सुनिश्चित करता है कि चंक सीमाओं पर फैली जानकारी रिट्रीवल के दौरान खो न जाए।

यह संतुलन महत्वपूर्ण है: छोटे चंक्स अधिक सटीक रिट्रीवल देते हैं लेकिन व्यापक संदर्भ छूट सकता है, जबकि बड़े चंक्स अधिक अर्थ बनाए रखते हैं पर अप्रासंगिक जानकारी भी शामिल हो सकती है। 

स्पष्ट सेक्शन सीमाओं वाले तकनीकी दस्तावेज़ों के लिए छोटे चंक्स (150–250 टोकन) उपयोग करें। शोध पत्रों या रिपोर्ट जैसे नैरेटिव दस्तावेज़ों के लिए बड़े चंक्स (400–600 टोकन) तर्क प्रवाह और संदर्भ को सुरक्षित रखते हैं। आधिकारिक File Search दस्तावेज़ विभिन्न दस्तावेज़ प्रकारों के लिए चंक आकार चुनने पर अतिरिक्त मार्गदर्शन देता है।

मेटाडेटा फ़िल्टरिंग

जब आपके स्टोर में दर्जनों या सैकड़ों दस्तावेज़ हों, तो मेटाडेटा फ़िल्टरिंग सैमंटिक सर्च चलने से पहले रिट्रीवल का दायरा संकीर्ण करती है। इससे प्रिसीजन बेहतर होती है और प्रोसेसिंग समय घटता है।

बाद में फ़िल्टरिंग सक्षम करने के लिए दस्तावेज़ अपलोड के समय मेटाडेटा जोड़ें:

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"}
        ]
    }
)

custom_metadata पैरामीटर की-वैल्यू पेयर्स की एरे स्वीकार करता है। श्रेणियाँ या दवा वर्ग जैसे टेक्स्ट मेटाडेटा के लिए string_value उपयोग करें, और वर्षों, वर्ज़न या अन्य संख्यात्मक डेटा के लिए numeric_value।

केवल प्रासंगिक दस्तावेज़ों में खोजने के लिए मेटाडेटा फ़िल्टर के साथ क्वेरी करें:

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"
                )
            )
        ]
    )
)

metadata_filter पैरामीटर रिट्रीवल को केवल निर्दिष्ट मानदंड से मेल खाते दस्तावेज़ों तक सीमित करता है। इस उदाहरण में, File Search केवल category=diabetes वाले दस्तावेज़ों पर विचार करता है, भले ही उसी स्टोर में रक्तचाप और कोलेस्ट्रॉल की दवाएँ मौजूद हों।

यह तब महत्वपूर्ण होता है जब स्टोर्स में विविध दस्तावेज़ हों। एक मेडिकल नॉलेज बेस में दवा लेबल्स, शोध पत्र, और क्लिनिकल गाइडलाइंस शामिल हो सकते हैं। दस्तावेज़ प्रकार से फ़िल्टरिंग सुनिश्चित करती है कि डोज़ की जानकारी लेबल्स से मिले, न कि शोध सारांशों से।

आप मेटाडेटा फ़िल्टरिंग को पूर्ण सैमंटिक सर्च क्षमता के साथ संयोजित कर सकते हैं। पहले फ़िल्टर चलकर कैंडिडेट दस्तावेज़ चुनता है, फिर सैमंटिक सर्च उन्हीं दस्तावेज़ों के भीतर सबसे प्रासंगिक पैसेज ढूँढती है।

प्रदर्शन अनुकूलन

File Search का प्रदर्शन स्टोर आकार, क्वेरी जटिलता, और मॉडल चयन पर निर्भर करता है। निम्न दिशानिर्देश रिट्रीवल को तेज़ रखते हैं और लागत को प्रबंधनीय बनाते हैं।

स्टोर आकार सीमाएँ: बेहतर रिट्रीवल लैटेंसी के लिए व्यक्तिगत स्टोर्स को 20GB से कम रखें। File Search आपके दस्तावेज़ों के साथ एम्बेडिंग्स भी स्टोर करता है, और एम्बेडिंग्स का आकार मूल फ़ाइलों के लगभग तीन गुना होता है। 7GB PDFs का संग्रह इंडेक्स होने पर लगभग 21GB डेटा बनाता है, जो अनुशंसित सीमा से अधिक है।

जब आप इस सीमा के पास पहुँचें, तो श्रेणी, समय अवधि, या एक्सेस पैटर्न के अनुसार अलग-अलग स्टोर्स बनाएँ। मेडिकल असिस्टेंट के लिए, आप सभी दवाओं को एक ही स्टोर में इंडेक्स करने के बजाय अलग-अलग दवा श्रेणियों के लिए अलग स्टोर बना सकते हैं।

कॉस्ट स्ट्रक्चर: File Search इंडेक्सिंग के लिए प्रति 1 मिलियन टोकन $0.15 चार्ज करता है। एक बार इंडेक्स हो जाने पर, आप बिना अतिरिक्त इंडेक्सिंग लागत के हज़ारों क्वेरियाँ चला सकते हैं। यह प्राइसिंग मॉडल उन वर्कलोड्स के लिए अनुकूल है जहाँ आप समान दस्तावेज़ों को बार-बार क्वेरी करते हैं।

मॉडल चयन: अधिकांश क्वेरियों के लिए gemini-2.5-flash उपयोग करें। यह 1–2 सेकंड में रिक्वेस्ट प्रोसेस करता है और gemini-2.5-pro की तुलना में काफी सस्ता है। gemini-2.5-pro को तभी रखें जब कई स्रोतों पर गहन तर्क या अत्यधिक जटिल सिन्थेसिस कार्यों की आवश्यकता हो। उच्च-वॉल्यूम एप्लिकेशंस के लिए मॉडल्स के बीच लागत का फर्क इंडेक्सिंग लागत से अधिक मायने रखता है।

जैसे-जैसे आप दस्तावेज़ जोड़ते हैं, स्टोर आकार की मॉनिटरिंग करें। आप इसे API से जाँच सकते हैं, हालाँकि आकार की गणना Google के बैकएंड पर होती है और अपलोड के तुरंत बाद परिलक्षित नहीं हो सकती। पूर्ण तकनीकी स्पेसिफ़िकेशंस और सीमाओं के लिए Gemini File API दस्तावेज़ देखें।

एकाधिक स्टोर मैनेज करना

प्रत्येक Google Cloud प्रोजेक्ट में अधिकतम 10 File Search स्टोर्स सपोर्ट होते हैं। कई स्टोर्स आपको दस्तावेज़ों को एक्सेस कंट्रोल, प्रदर्शन आवश्यकताओं, या तार्किक संगठन के अनुसार अलग करने देते हैं।

विभिन्न उपयोग मामलों के लिए विशेष स्टोर्स बनाएँ:

# 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"}
)

एक ही रिक्वेस्ट में कई स्टोर्स को क्वेरी करें:

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
                    ]
                )
            )
        ]
    )
)

File Search सभी निर्दिष्ट स्टोर्स से रिट्रीव करता है और परिणामों को संयोजित करता है। ग्राउंडिंग मेटाडेटा दिखाता है कि कौन-सा सिटेशन किस स्टोर से आया, जिससे पूरी ट्रेसएबिलिटी बनी रहती है। 

स्टोर्स अनिश्चित काल तक बने रहते हैं और जब आवश्यकता न हो तो इन्हें मैन्युअली डिलीट करना पड़ता है, इसलिए वे प्रोडक्शन एप्लिकेशंस के लिए उपयुक्त हैं जहाँ दस्तावेज़ सत्रों और डिप्लॉयमेंट्स के पार क्वेयरेबल बने रहते हैं।

अगला, आप देखेंगे कि File Search अन्य RAG समाधानों की तुलना में कैसा है और कब मैनेज्ड बनाम DIY दृष्टिकोण चुनना चाहिए।

Google File Search Tool बनाम अन्य फ़ाइल सर्च और RAG टूल्स

RAG एप्लिकेशन बनाने के लिए File Search अकेला विकल्प नहीं है। विकल्पों की तुलना समझना सही टूल चुनने में मदद करता है। आइए Google के दृष्टिकोण की तुलना OpenAI के ऑफ़रिंग और पारंपरिक कस्टम बिल्ड्स से करें।

Google File Search बनाम OpenAI File Search

दोनों कंपनियाँ होस्टेड RAG देती हैं, लेकिन प्राइसिंग और क्षमताओं पर उनका दृष्टिकोण अलग है।

प्राइसिंग: Google इंडेक्सिंग के दौरान एक बार शुल्क लेता है ($2.50 प्रति हज़ार क्वेरियाँ प्लस स्टोरेज के लिए प्रति दिन $0.10 प्रति GB)। यदि आप बहुत सारी क्वेरियाँ चलाते हैं लेकिन दस्तावेज़ों को शायद ही कभी अपडेट करते हैं, तो Google का मॉडल पैसे बचाता है। यदि आप लगातार री-इंडेक्सिंग करते हैं, तो गणित दिलचस्प हो जाता है।

कॉन्फ़िगरेशन नियंत्रण: Google ऑटोमेटेड चंकिंग और सीमित कॉन्फ़िगरेशन के साथ चीज़ों को सरल रखता है। OpenAI अधिक नियंत्रण देता है। आप चंक आकार (डिफ़ॉल्ट 800 टोकन) और ओवरलैप (400 टोकन) सेट कर सकते हैं। OpenAI हाइब्रिड सर्च (वेक्टर + कीवर्ड) चलाता है, जबकि Google केवल सैमंटिक सर्च पर निर्भर करता है। जब आपकी क्वेरियों में विशिष्ट तकनीकी शब्द या प्रोडक्ट कोड होते हैं, तब यह फर्क मायने रखता है।

फ़ाइल फॉर्मैट्स: Google 150+ फ़ाइल प्रकार संभालता है, जिनमें कोड फ़ाइलें और विविध दस्तावेज़ फ़ॉर्मैट्स शामिल हैं। OpenAI छह प्रकार सपोर्ट करता है: TXT, MD, HTML, DOCX, PPTX, और PDF। कोई भी CSV या JSONL जैसी स्ट्रक्चर्ड डेटा को अच्छी तरह नहीं संभालता। यहीं कस्टम बिल्ड्स चमकते हैं।

इंटीग्रेशन: Google, Gemini मॉडल्स और Google Cloud सेवाओं से जुड़ता है। OpenAI अपने मॉडल परिवार और Azure से। दोनों सिटेशंस और स्रोत ट्रैकिंग देते हैं।

मूल अंतर सादगी बनाम नियंत्रण पर आकर रुकता है। Google सब कुछ एक API कॉल में समेटता है। OpenAI आपको अधिक ट्यूनिंग देता है, जिसकी कीमत अधिक जटिलता है। एकल विजेता नहीं है—यह इस पर निर्भर करता है कि आपके प्रोजेक्ट के लिए स्पीड चाहिए या कस्टमाइज़ेशन।

कस्टम RAG क्षमताएँ

LangChain जैसे टूल्स से अपना RAG सिस्टम बनाना ऐसी क्षमताएँ खोलता है जो होस्टेड सेवाएँ नहीं देतीं। DataCamp का RAG with LangChain कोर्स इस दृष्टिकोण को विस्तार से समझाता है।

कस्टम बिल्ड्स उन्नत तकनीकों को सक्षम करते हैं:

• सैमंटिक स्प्लिटिंग जो फिक्स्ड लंबाइयों पर काटने के बजाय टॉपिक शिफ्ट्स को पहचानती है
• टोकन-अवेयर चंकिंग जो मॉडल कॉन्टेक्स्ट विंडो का सटीक सम्मान करती है
• हाइब्रिड रिट्रीवल जो BM25 कीवर्ड सर्च को डेंस वेक्टर्स के साथ मिलाती है
• क्वेरी ट्रांसफ़ॉर्मेशंस जैसे HyDE, जो सर्च सुधारने के लिए काल्पनिक उत्तर जनरेट करते हैं
• ग्राफ RAG जो दस्तावेज़ों को एंटिटीज़ और रिलेशनशिप्स के नेटवर्क के रूप में प्रस्तुत करता है

DataCamp का RAG प्रदर्शन सुधारने पर ट्यूटोरियल इन तकनीकों को उदाहरणों के साथ एक्सप्लोर करता है जो मापनीय गुणवत्ता सुधार दिखाते हैं। ट्रेड-ऑफ ऑपरेशनल जटिलता है: आप डेटाबेस प्रदर्शन मॉनिटर कर रहे हैं, एम्बेडिंग मॉडल्स ट्यून कर रहे हैं, और कई सेवाओं में अपडेट संभाल रहे हैं।

कब किस दृष्टिकोण का उपयोग करें

File Search जैसे होस्टेड टूल चुनें जब:

• आप प्रोटोटाइप या प्रूफ़-ऑफ़-कॉन्सेप्ट बना रहे हैं जहाँ गति मायने रखती है
• आपका उपयोग केस मानक पैटर्न (दस्तावेज़ों पर Q&A, नॉलेज बेस, डॉक्यूमेंटेशन सर्च) में फिट बैठता है
• आपकी टीम में गहरी RAG विशेषज्ञता नहीं है
• आपको पूर्वानुमेय लागत और न्यूनतम ऑप्स ओवरहेड चाहिए

कस्टम बनाएं जब:

• आपको उन्नत चंकिंग या विशेष रिट्रीवल मेथड्स चाहिए
• आप स्ट्रक्चर्ड डेटा या असामान्य फ़ाइल फ़ॉर्मैट्स के साथ काम कर रहे हैं
• आप एजेंटिक RAG सिस्टम बना रहे हैं जो कई रणनीतियाँ संयोजित करते हैं
• भारी पैमाने पर लागत का अनुकूलन इंजीनियरिंग निवेश को उचित ठहराता है
• अनुपालन में विशिष्ट इन्फ्रास्ट्रक्चर या मॉडल्स की आवश्यकता होती है

अधिकांश प्रोजेक्ट होस्टेड समाधानों से शुरू होते हैं और केवल तब कस्टम बिल्ड्स पर स्विच करते हैं जब आवश्यकताएँ इसकी मांग करती हैं। कस्टम RAG की तकनीकें (स्मार्ट चंकिंग, हाइब्रिड सर्च, क्वेरी ऑप्टिमाइज़ेशन) फिर भी होस्टेड टूल्स के उपयोग को सूचित करती हैं। पूरा परिदृश्य समझना आपकी आवश्यकताओं के विकसित होने पर बेहतर विकल्प चुनने में मदद करता है।

निष्कर्ष

आपने Google File Search Tool का उपयोग करके एक पूरा RAG सिस्टम बनाया—FDA दवा लेबल्स को इंडेक्स करने से लेकर सिटेशंस के साथ क्वेरी करने तक। यह मेडिकल असिस्टेंट दिखाता है कि कैसे मैनेज्ड सेवाएँ इन्फ्रास्ट्रक्चर संभालती हैं जबकि आप एप्लिकेशन लॉजिक पर ध्यान देते हैं।

File Search तब अच्छी तरह काम करता है जब आपको वेक्टर डेटाबेस या एम्बेडिंग पाइपलाइनों को मैनेज किए बिना विश्वसनीय RAG चाहिए। फ्री स्टोरेज और क्वेरी एम्बेडिंग्स लागत को पूर्वानुमेय बनाते हैं। स्थायी स्टोर्स री-इंडेक्सिंग ओवरहेड खत्म कर देते हैं, जिससे आप इन्फ्रास्ट्रक्चर मेंटेनेंस बढ़ाए बिना क्वेरियों को स्केल कर सकते हैं।

प्रोडक्शन में डिप्लॉय करने से पहले, वे महत्वपूर्ण सेफ़गार्ड्स जोड़ें जिन्हें संक्षिप्तता के लिए ट्यूटोरियल में छोड़ा गया था। अपलोड ऑपरेशंस के लिए टाइमआउट सहित एरर हैंडलिंग लागू करें और API कॉल्स के आसपास try-catch ब्लॉक्स जोड़ें। विशेष रूप से संवेदनशील कंटेंट के लिए दस्तावेज़ Google के सर्वर पर अपलोड करते समय डेटा गोपनीयता निहितार्थों पर विचार करें। सिटेशंस एक्सेस करने से पहले ग्राउंडिंग मेटाडेटा मौजूद है, यह सत्यापित करने के लिए वैलिडेशन जोड़ें। डोमेन विशेषज्ञों के साथ अच्छी तरह परीक्षण करें ताकि वे मामले पकड़े जा सकें जहाँ मॉडल ग्राउंडिंग के बावजूद संभावित लेकिन गलत उत्तर जनरेट करता है।

अगले चरणों के लिए, श्रेणी के अनुसार दस्तावेज़ व्यवस्थित करने हेतु मेटाडेटा फ़िल्टरिंग के साथ अपने असिस्टेंट का विस्तार करें। अपने दस्तावेज़ प्रकारों के अनुसार चंक आकारों के साथ प्रयोग करें। आपने यहाँ जो तकनीकें सीखी हैं, वे सपोर्ट बॉट्स, डॉक्यूमेंटेशन सर्च, या नॉलेज असिस्टेंट्स बनाने में समान रूप से लागू होती हैं।