बड़े PDF से टेबल कैसे निकालें और संख्याओं को कैसे सत्यापित करें

जब जटिल PDF दस्तावेज़ों—जैसे बहु-पृष्ठीय उपकरण निरीक्षण रिपोर्ट या वित्तीय विवरण—को प्रोसेस करने की बात आती है, तो एकसमान और साफ-सुथरा टेक्स्ट मिलना नियम नहीं बल्कि अपवाद होता है। वास्तविक उद्यम (enterprise) दस्तावेज़ों में, डिजिटल पृष्ठों के साथ स्कैन की गई शीटें मिली होती हैं, तालिकाओं में स्पष्ट ग्रिड बॉर्डर नहीं होते, और महत्वपूर्ण मेट्रिक्स अक्सर घने फ़ुटनोट्स में छिपे होते हैं।

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

---

1. डेटा स्कीमा: फ़ील्ड्स को निश्चित करना और Nulls की अनुमति देना

Gemini Structured Outputs तंत्र यह सुनिश्चित करता है कि मॉडल की प्रतिक्रिया घोषित स्कीमा का सख्ती से पालन करे, जिससे सिंटैक्स के रूप में मान्य JSON उत्पन्न होता है। यदि कोई प्रॉपर्टी संख्यात्मक (numeric) घोषित की गई है, तो कोई भी अनावश्यक बातचीत वाला टेक्स्ट उस मान को दूषित नहीं करेगा।

हालाँकि, सिंटैक्स स्कीमा का अनुपालन केवल संरचनात्मक त्रुटियों से बचाता है—यह अर्थ संबंधी सच्चाई (semantic truth) की गारंटी नहीं देता:

• मॉडल घनी और बिना बॉर्डर वाली तालिकाओं में आस-पास की पंक्तियों को मिला सकता है या कॉलमों को आपस में बदल सकता है;
• खराब गुणवत्ता वाले स्कैन पर, अंक 8 को आसानी से 3 पढ़ा जा सकता है, और दशमलव बिंदु अक्सर छूट जाते हैं;
• जब कोई मेट्रिक गायब या अस्पष्ट हो, तो जिस मॉडल को मान छोड़ने की स्पष्ट अनुमति नहीं होती, वह एक काल्पनिक लेकिन विश्वसनीय लगने वाली संख्या गढ़ने का प्रयास कर सकता है।

मतिभ्रम (hallucination) के जोखिम को कम करने के लिए, स्कीमा में फ़ील्ड्स को शून्य-स्वीकार्य (Optional या null) घोषित किया जाना चाहिए, साथ ही प्रॉम्प्ट में स्पष्ट निर्देश होने चाहिए कि जब भी किसी संख्या को उच्च विश्वास के साथ न समझा जा सके, तो null लौटाया जाए। यद्यपि null मानों की अनुमति देने से अनुमान लगाने का दबाव काफी कम हो जाता है, फिर भी यह अपने आप में मतिभ्रम के खिलाफ पूर्ण गारंटी प्रदान नहीं करता है।

---

2. फ़ाइल इनजेशन: Files API का चयन कब करें

आधिकारिक Gemini document processing documentation के अनुसार, प्रति PDF फ़ाइल परिचालन सीमाएँ 50 MB तक या 1,000 पृष्ठों तक निर्धारित हैं (फ़ाइल आकार और पृष्ठ संख्या दोनों सीमाएँ एक साथ लागू होती हैं, और इस बात की कोई गारंटी नहीं है कि दोनों अधिकतम सीमाएँ एक साथ प्राप्त की जा सकती हैं—जो भी सीमा पहले पूरी होगी, प्रोसेसिंग वहीं रुक जाएगी)।

ट्रांसमिशन की इष्टतम विधि दस्तावेज़ के आकार और परिचालन पैटर्न पर निर्भर करती है:

• इनलाइन डेटा पासिंग (Inline data passing) छोटे दस्तावेज़ों और एक बार के निष्कर्षण कॉल्स के लिए सबसे उपयुक्त है।
• Files API (client.files.upload) बड़ी फ़ाइलों और ऐसे मल्टी-टर्न वर्कफ़्लो के लिए डिज़ाइन किया गया है जहाँ लगातार ऑपरेशनों में एक ही दस्तावेज़ से पूछताछ की जाती है (उदाहरण के लिए, पहले अनुभाग का वर्गीकरण और उसके बाद लक्षित तालिका निष्कर्षण)। Files API का उपयोग करने से प्रत्येक कॉल के लिए संपूर्ण दस्तावेज़ पेलोड को बार-बार अपलोड करने से बचा जा सकता है।

---

3. डेटा क्वेरी करना: स्कीमा, उद्धरण संकेत और काल्पनिक प्रतिक्रिया

निकाले गए डेटा को ऑडिट करने योग्य बनाने के लिए, मॉडल को लक्षित मानों के साथ सहायक मेटाडेटा लौटाने का प्रॉम्प्ट दें: एक अनुमानित पृष्ठ संख्या (page_number) और एक संक्षिप्त, शब्दशः उद्धरण स्निपेट (evidence_quote)।

महत्वपूर्ण अंतर: page_number और evidence_quote तथ्यात्मक प्रमाण नहीं हैं; वे पूरी तरह से खोज के अनुमानी (heuristic) संकेत हैं। चूंकि मॉडल स्वयं इन फ़ील्ड्स को उत्पन्न करता है, इसलिए उद्धरण स्निपेट्स में OCR से जुड़ी त्रुटियाँ हो सकती हैं या आस-पास की पंक्तियाँ आपस में मिल सकती हैं, और रिपोर्ट की गई विज़ुअल पृष्ठ संख्या PDF कंटेनर के भौतिक शीट इंडेक्स से भिन्न हो सकती है।

काल्पनिक समस्या सेटअप

एक काल्पनिक समस्या सेटअप पर विचार करें (कोई वास्तविक PDF प्रदान नहीं किया गया, अपलोड नहीं किया गया या उसका विश्लेषण नहीं किया गया, और कोई लाइव API क्वेरी निष्पादित नहीं की गई थी): एक काल्पनिक पंप निरीक्षण रिपोर्ट से सारांश मेट्रिक्स के निष्कर्षण का मॉडलिंग करना। इस उदाहरणात्मक उदाहरण में, हम दो पंक्तियों वाली एक काल्पनिक तालिका की जांच करते हैं:

पहचानकर्ता (Identifier)	दबाव / Pressure (MPa)	कंपन / Vibration (mm/s)	स्थिति (Status)	टिप्पणियाँ (Notes)
Н-101-А	1.45	2.1	सामान्य / Normal (В норме)	अनुसूचित निरीक्षण (Scheduled inspection)
Н-102-В	(अपठनीय / illegible)	7.8	ध्यान दें / Attention (Внимание)	बढ़ा हुआ विचलन (Increased play)

नीचे Pydantic के साथ परिभाषित एक उदाहरण स्कीमा और आधिकारिक SDK के लिए निष्पादन सिंटैक्स दिया गया है:

from google import genai
from pydantic import BaseModel, Field
from typing import List, Optional

class PumpRecord(BaseModel):
    unit_id: str = Field(
        description="Идентификатор агрегата точно как в таблице"
    )
    inlet_pressure_mpa: Optional[float] = Field(
        default=None,
        description="Давление в МПа. Если значение неразборчиво или отсутствует — null"
    )
    vibration_mms: Optional[float] = Field(
        default=None,
        description="Уровень вибрации в мм/с. При отсутствии данных — null"
    )
    status: str = Field(
        description="Статус узла (например, 'В норме', 'Внимание')"
    )
    page_number: Optional[int] = Field(
        default=None,
        description="Оценочный номер страницы документа (подсказка для аудитора, не подтверждена)"
    )
    evidence_quote: Optional[str] = Field(
        default=None,
        description="Короткий фрагмент строки (до 10 слов), откуда взяты числа (подсказка, не подтверждена)"
    )

class InspectionPayload(BaseModel):
    records: List[PumpRecord]

client = genai.Client()

uploaded_file = client.files.upload(file="hypothetical_inspection.pdf")

response = client.interactions.create(
    model="gemini-3.8-flash",
    input=[
        {
            "type": "document",
            "uri": uploaded_file.uri,
            "mime_type": uploaded_file.mime_type,
        },
        {
            "type": "text",
            "text": (
                "Извлеки показатели агрегатов в соответствии со схемой. "
                "Если число неразборчиво или отсутствует, возвращай null. "
                "Для каждой записи заполни номер страницы и короткую цитату-подтверждение."
            ),
        },
    ],
    response_format={
        "type": "text",
        "mime_type": "application/json",
        "schema": InspectionPayload.model_json_schema(),
    },
)

payload = InspectionPayload.model_validate_json(response.output_text)

मॉडल से उदाहरणात्मक JSON प्रतिक्रिया

निम्नलिखित JSON इस अनुरोध पर एक काल्पनिक मॉडल प्रतिक्रिया को दर्शाता है। हम इस बात पर बल देते हैं: यह आउटपुट केवल एक काल्पनिक संरचनात्मक चित्रण (hypothetical structural illustration) के रूप में कार्य करता है, न कि किसी वास्तविक API निष्पादन या वास्तविक भौतिक माप का परिणाम है:

{
  "records": [
    {
      "unit_id": "Н-101-А",
      "inlet_pressure_mpa": 1.45,
      "vibration_mms": 2.1,
      "status": "В норме",
      "page_number": 12,
      "evidence_quote": "Н-101-А 1.45 2.1 В норме"
    },
    {
      "unit_id": "Н-102-В",
      "inlet_pressure_mpa": null,
      "vibration_mms": 7.8,
      "status": "Внимание",
      "page_number": 12,
      "evidence_quote": "Н-102-В [пятно] 7.8 Внимание"
    }
  ]
}

इस काल्पनिक प्रतिक्रिया में, दोनों page_number: 12 उदाहरणों और दोनों evidence_quote मानों को असत्यापित संकेत (unverified hints) का दर्जा प्राप्त है। यद्यपि मॉडल ने दूसरी इकाई पर अपठनीय दबाव आंकड़े के लिए सही ढंग से null लौटाया, फिर भी निकाले गए किसी भी गुण को स्वतः ही पुष्ट तथ्य नहीं माना जाता है।

---

4. विज़ुअल मूल दस्तावेज़ के साथ मिलान और निर्यात के नियम

निकाले गए रिकॉर्ड्स को बिना सत्यापन के सीधे डाउनस्ट्रीम डेटाबेस में नहीं लिखा जा सकता। स्रोत PDF पृष्ठ के विज़ुअल रेंडरिंग के विरुद्ध प्रत्येक फ़ील्ड की तुलना करते हुए एक शुरू से अंत तक (end-to-end) ऑडिट आवश्यक है।

उदाहरण के संबंध में महत्वपूर्ण स्पष्टीकरण: दो पंक्तियों वाली तालिका, पृष्ठ 12, भौतिक 14वीं शीट का ऑफ़सेट, कंप्रेसर विभाग और विज़ुअल सत्यापन वर्कफ़्लो पूरी तरह से प्रक्रिया का एक काल्पनिक चित्रण प्रस्तुत करते हैं। कोई भी वास्तविक PDF दस्तावेज़ प्रदान या निरीक्षण नहीं किया गया था, और नीचे वर्णित चरण यह दर्शाते हैं कि एक समीक्षक (reviewer) व्यवहार में क्या सत्यापित करेगा, और यदि विज़ुअल रेंडरिंग बताए गए मानों की पुष्टि करती है तो क्या सशर्त निर्णय तैयार किए जाएंगे।

चरण-दर-चरण रिकॉर्ड सत्यापन: एक समीक्षक क्या जांचेगा

1. इकाई Н-101-А:

   • पृष्ठ और स्थानीयकरण (Page and Localization): मॉडल ने page_number: 12 का संकेत दिया। समीक्षक पृष्ठ 12 के विज़ुअल रेंडरिंग की जांच करेगा (या यदि शुरुआती पृष्ठों के कारण भौतिक ऑफ़सेट हुआ है, तो 14वीं शीट) और लक्षित कंप्रेसर विभाग तालिका का पता लगाएगा।
   • पहचानकर्ता (Identifier): पहले कॉलम में, समीक्षक सटीक मिलान के लिए पहचानकर्ता Н-101-А की जांच करेगा।
   • दबाव और इकाइयाँ (Pressure and Units): इनलेट प्रेशर कॉलम के अंतर्गत, समीक्षक यह सत्यापित करेगा कि मान 1.45 स्पष्ट रूप से पढ़ने योग्य है और इंजीनियरिंग इकाइयाँ स्कीमा की अपेक्षाओं (МПа / MPa) से मेल खाती हैं।
   • कंपन और इकाइयाँ (Vibration and Units): कंपन के अंतर्गत, समीक्षक 2.1 की जांच करेगा और इकाई के संकेतन (мм/с / mm/s) का सत्यापन करेगा।
   • स्थिति (Status): परिचालन स्थिति के अंतर्गत, समीक्षक В норме (Normal / सामान्य) स्थिति की उपस्थिति की पुष्टि करेगा।
   • सशर्त निर्णय (Conditional Decision): यदि रेंडर किया गया पृष्ठ सभी फ़ील्ड्स, मानों और भौतिक इकाइयों को मान्य करता है, तो पंक्ति को निर्यात के लिए अनुमोदित किया जाएगा (Export / Accepted)।

2. इकाई Н-102-В:

   • पृष्ठ और स्थानीयकरण (Page and Localization): उसी काल्पनिक तालिका में, समीक्षक दूसरी पंक्ति की ओर आगे बढ़ेगा।
   • पहचानकर्ता (Identifier): समीक्षक पहचानकर्ता Н-102-В की उपस्थिति की पुष्टि करेगा।
   • कंपन और स्थिति (Vibration and Status): समीक्षक विज़ुअल लेयर के साथ कंपन मान 7.8 और स्थिति Внимание (Warning / Attention) का मिलान करेगा।
   • दबाव (Pressure): मॉडल ने null लौटाया। समीक्षक पृष्ठ रेंडरिंग पर संबंधित सेल की जांच करेगा: यदि किसी रीडिंग के स्थान पर एक गहरा, फैला हुआ धब्बा (स्कैनिंग दोष) देखा जाता है, तो यह null लौटाने के मॉडल के निर्णय को मान्य करता है, फिर भी एक महत्वपूर्ण भौतिक माप अनुपस्थित रहता है।
   • सशर्त निर्णय (Conditional Decision): चूंकि विज़ुअल पुष्टि यह स्थापित करती है कि एक महत्वपूर्ण दबाव रीडिंग गायब है, इसलिए पंक्ति को स्वचालित निर्यात से अवरुद्ध किया जाएगा और मैनुअल समीक्षा (Hold for manual review) में रखा जाएगा, जिसके लिए परिचालन पुनः स्कैन या बैकअप रखरखाव लॉग के साथ मिलान की आवश्यकता होगी।

सत्यापन के बाद जाँचा गया आउटपुट (Checked Output)

सारांश तालिका विस्तार से बताती है कि समीक्षक वास्तव में क्या निरीक्षण करेगा और विज़ुअल पुष्टि होने पर सत्यापन पाइपलाइन क्या सशर्त रूटिंग निर्णय ट्रिगर करेगी:

इकाई (Unit)	दबाव / Pressure (MPa)	कंपन / Vibration (mm/s)	स्थिति (Status)	समीक्षक क्या जांचेगा (काल्पनिक सत्यापन)	पाइपलाइन का सशर्त निर्णय (यदि रेंडरिंग मानों की पुष्टि करती है)
Н-101-А	1.45	2.1	В норме (Normal)	रेंडरिंग के विरुद्ध पहचानकर्ता मिलान, संख्यात्मक मान और इकाइयों (MPa, mm/s) को सत्यापित करेगा	Export approved (Ready for ingestion / लोड करने के लिए तैयार)—सभी फ़ील्ड्स की पूर्ण विज़ुअल पुष्टि की शर्त पर
Н-102-В	null (छूटा हुआ)	7.8	Внимание (Warning)	दबाव सेल में स्कैन दोष (धब्बा) की पुष्टि करेगा और कंपन मान का मिलान करेगा	Held for manual review (Operator triage / ऑपरेटर द्वारा मैनुअल समीक्षा)—एक महत्वपूर्ण मीट्रिक की पुष्ट अनुपस्थिति के कारण

आर्किटेक्चरल वैलिडेशन पैटर्न

एक मजबूत दस्तावेज़ इनजेशन पाइपलाइन संसाधित रिकॉर्ड्स को दो अलग-अलग धाराओं में रूट करती है:

• ग्रीन कॉरिडोर / Green Corridor (Verified Export): विशेष रूप से उन पंक्तियों के लिए आरक्षित जहाँ प्रत्येक अनिवार्य फ़ील्ड को स्रोत पृष्ठ रेंडरिंग के विरुद्ध विज़ुअल रूप से पुष्ट किया जाता है और सभी भौतिक इकाइयों को स्कीमा मानकों के अनुसार सामान्यीकृत किया जाता है।
• समीक्षा कतार / Review Queue (Quarantine): महत्वपूर्ण फ़ील्ड्स में null, माप की परस्पर विरोधी इकाइयों या अस्पष्ट उद्धरणों वाले किसी भी रिकॉर्ड को मानव ऑपरेटर द्वारा मैनुअल समीक्षा के लिए क्वारंटाइन (quarantine) किया जाता है।

---

आधिकारिक दस्तावेज़ और मार्गदर्शिकाएँ

• Document processing with Gemini API (limits and supported formats)
• Structured outputs (schema enforcement and validation)