OpenOCR अब Gemini 3.1 Flash-Lite और इसके बाद आने वाले किसी भी इंजन के खाली नतीजों को पकड़ता है

8 अक्टूबर, 2026. OpenOCR अब यह पहचान लेता है कि कब किसी इंजन ने आपका पेज पढ़ा और कुछ भी वापस नहीं लौटाया। सफलता जैसा दिखने वाले खाली परिणाम के बजाय अब आपको एक स्पष्ट एरर मिलता है जो कारण बताता है। इस प्रयास के लिए प्रोवाइडर ने जितना चार्ज किया था, आप उससे अधिक कभी भुगतान नहीं करते हैं, और मल्टी-पेज PDF में पढ़ने में सफल रहे प्रत्येक पेज को सुरक्षित रखा जाता है।

यह पैटर्न Gemini 3.1 Flash-Lite से शुरू हुआ था, लेकिन यह सुरक्षा OpenOCR के हर इंजन पर लागू होती है।

हमने क्या पकड़ा

हमारी मॉनिटरिंग ने OpenOCR पर सबसे ज़्यादा इस्तेमाल होने वाले इंजनों में से एक, Google के Gemini 3.1 Flash-Lite पर एक पैटर्न को फ्लैग किया। वास्तविक दस्तावेज़ों (स्पष्ट रूप से प्रिंट किए गए टेक्स्ट वाले फ़ॉर्म, कार्ड और पत्र) के एक छोटे हिस्से पर इसने कोई टेक्स्ट वापस नहीं किया, जबकि Google के API ने रिक्वेस्ट को सफल बताया। पिछले 30 दिनों में Flash-Lite के लगभग 3 प्रतिशत पेजों पर ऐसा हुआ, और पूरे प्लेटफ़ॉर्म पर हमें जितने भी खाली नतीजे दिखे, उनमें से लगभग 97 प्रतिशत इसी के कारण थे।

कुछेक रिक्वेस्ट्स में तीन प्रतिशत को नज़रअंदाज़ करना आसान है। लेकिन बड़े पैमाने पर दस्तावेज़ों के स्तर पर, इसका मतलब यह है कि किसी वर्कफ़्लो को प्रचुर मात्रा में अच्छा टेक्स्ट मिलने के बावजूद पढ़ने योग्य पेज छूट सकते हैं। प्रोवाइडर के सफलता के सिग्नल ने उन नुकसानों को पूरे हो चुके काम जैसा बना दिया था। (वैसे भी, एक मजबूत English OCR का मतलब अच्छा Devanagari OCR होना नहीं है; जटिल भारतीय लिपियों के दस्तावेज़ों में ऐसे अनपेक्षित परिणामों का जोखिम और बढ़ जाता है।)

दोबारा कोशिश करने (retrying) से भी कोई खास मदद नहीं मिली। वही इमेज 80 से 93 प्रतिशत मामलों में फिर से खाली आई, इसलिए रिक्वेस्ट को दोहराने से ज़्यादातर समय ही बर्बाद हुआ।

स्पष्ट कारण के साथ मिले इनकार (refusal) के मामले में, अगला कदम किसी दूसरे इंजन का उपयोग करना है।

अब रिस्पॉन्स कैसा दिखता है

इस बदलाव से पहले, एक पढ़ने योग्य पेज बिना किसी निकाले गए टेक्स्ट के एक सफल जॉब बना सकता था। यहाँ प्रासंगिक फ़ील्ड्स दिखाते हुए एक संक्षिप्त उदाहरण दिया गया है:

{
  "status": "succeeded",
  "extracted_text": ""
}

अब प्रोवाइडर का इनकार (refusal) स्पष्ट होता है। यहाँ एक संक्षिप्त उदाहरण दिया गया है जहाँ Google ने उस प्रयास के लिए हमें बिल किया था, इसलिए रिक्वेस्ट पर केवल वही लागत आती है, उससे अधिक कुछ नहीं:

{
  "status": "failed_charged",
  "error_code": "provider_refused",
  "cost_debited": 0.000327,
  "provider_error": "Google declined to read this image (reason: SAFETY). Sending it to this engine again will give the same result; try a different engine."
}

जॉब अब यह दावा नहीं करता कि उपयोग योग्य OCR टेक्स्ट डिलीवर किया गया था। बिलिंग प्रोवाइडर के वास्तविक शुल्क के अनुसार होती है, जैसा कि नीचे बताया गया है।

सिर्फ एक के लिए नहीं, हर इंजन के लिए बनाया गया

हमने इसे Gemini पर पकड़ा था, लेकिन इस विफलता में ऐसा कुछ भी नहीं है जो केवल Google तक सीमित हो। कोई भी विज़न मॉडल ऐसा कर सकता है, और कुछ अन्य इंजनों में भी कभी-कभार ऐसा देखा गया। इसलिए केवल एक इंजन में पैच लगाने के बजाय, हमने यह बदल दिया कि OpenOCR किसी भी इंजन से मिलने वाले खाली उत्तर को कैसे हैंडल करता है:

कोरे जवाब के बजाय एक स्पष्ट उत्तर। किसी खाली परिणाम को दो में से किसी एक कोड के साथ विफलता (failure) के रूप में रिपोर्ट किया जाता है:

• provider_refused: प्रोवाइडर ने इनकार कर दिया और हमें कारण बताया, उदाहरण के लिए कोई सुरक्षा फ़िल्टर (safety filter)। एरर उस कारण का नाम बताता है और आपको सूचित करता है कि पेज को उसी इंजन पर दोबारा भेजने से वही परिणाम मिलेगा।
• provider_empty: मॉडल ने कुछ भी वापस नहीं लौटाया और कोई कारण भी नहीं दिया। इसे रिपोर्ट करने से पहले OpenOCR उस पेज को स्वचालित रूप से एक बार फिर पढ़ता है।

ये कोड्स आपके एप्लिकेशन को किसी ज्ञात इनकार (known refusal) और अस्पष्ट खाली उत्तर के बीच अंतर करने में सक्षम बनाते हैं। OpenOCR विफलता लौटाने से पहले अस्पष्ट उत्तर के लिए एक अतिरिक्त प्रयास करता है।

उचित बिलिंग। यदि प्रोवाइडर ने उस प्रयास के लिए हमें बिल किया, तो आप बिना किसी मार्कअप के और अपने कोट (quote) से अधिक नहीं, बिल्कुल वही लागत चुकाते हैं। यदि उसने बिल नहीं किया, तो आप कुछ भी भुगतान नहीं करते हैं। यह सीधे प्रोवाइडर को कॉल करने जैसा ही है।

PDFs अपने सही पेजों को सुरक्षित रखते हैं। यदि 30 पेजों वाले PDF का एक पेज खाली आता है, तो भी आपको बाकी 29 पेज मिलते हैं, और खाली पेज को उसके पेज नंबर के साथ चिह्नित कर दिया जाता है। कोई दस्तावेज़ केवल तभी विफल होता है जब किसी भी पेज से कोई टेक्स्ट नहीं मिलता।

मान लीजिए कि Flash-Lite को भेजा गया 30 पेजों का एक स्कैन है। पेज 1 से 11 टेक्स्ट लौटाते हैं, पेज 12 खाली आता है, और पेज 13 से 30 टेक्स्ट लौटाते हैं। OpenOCR पेज 12 का उल्लेख करने वाली चेतावनी के साथ 29 सफल पेज लौटाता है। आप उस पेज को किसी अन्य इंजन पर भेज सकते हैं या मैन्युअल रूप से जांच सकते हैं। शुल्क कभी भी कोट से अधिक नहीं होता।

हर इंजन पर नज़र रखी जाती है। अब हम प्रत्येक इंजन के खाली-परिणाम दर (empty-result rate) को लगातार ट्रैक करते हैं, ताकि यदि कोई अन्य मॉडल ऐसा करना शुरू करता है, तो हम इसे एक घंटे के भीतर देख लेंगे।

Gemini अब खुद कारण स्पष्ट करता है

Gemini 3.1 Flash-Lite अब Google के नेटिव API पर चलता है। हम पहले जिस एंडपॉइंट का उपयोग करते थे, वह इन इंकारों को केवल "other" के रूप में रिपोर्ट करता था। नेटिव API बताता है कि किसी पेज को क्यों अस्वीकार किया गया था, और वह कारण अब एरर में आप तक पहुँचता है।

अटकी हुई (stalled) रिक्वेस्ट्स भी अब तीन मिनट के बजाय 60 सेकंड के बाद टाइमआउट हो जाती हैं, ताकि आप जल्दी इंजन बदल सकें। सामान्य Flash-Lite लेटेंसी लगभग 3.6 सेकंड है, और इसका 99वाँ पर्सेंटाइल (99th percentile) लगभग 12 सेकंड है। 180-सेकंड का टाइमआउट अटकी हुई रिक्वेस्ट्स को इन देखे गए समयों से बहुत अधिक समय तक रोके रखता था; 60 सेकंड भी सामान्य सीमा से काफी अतिरिक्त समय देता है।

अब हम इस पर कैसे नज़र रखते हैं

हम प्रत्येक इंजन की खाली-परिणाम दर को प्रति घंटे ट्रैक करते हैं और इसके 5 प्रतिशत तक पहुँचने पर टीम को अलर्ट करते हैं। कोई एक मॉडल खाली उत्तर दे रहा हो, तब भी समग्र सफलता दर (overall success rate) अच्छी दिख सकती है। यह प्रति-इंजन सिग्नल हमें दिखाता है कि कहाँ जांच करने की आवश्यकता है।

डेवलपर्स के लिए

आपके इंटीग्रेशन में कुछ भी नहीं टूटेगा। आपको बस खाली सफलताएं (empty successes) मिलना बंद हो जाएंगी। यदि आप विफलताओं को दोबारा आज़माते हैं, तो एरर कोड की जांच करें: provider_refused वाले पेज को दोहराने के बजाय उसे किसी दूसरे इंजन पर रूट करें। एक ही OpenOCR API की (key) और एक ही बैलेंस के तहत दर्जनों इंजनों की उपलब्धता के साथ, यह बस engine फ़ील्ड में केवल एक शब्द बदलने जितना आसान है।

PDFs के लिए, लौटाए गए टेक्स्ट के साथ पेज की चेतावनी को भी बनाए रखें ताकि आप अंतर (gap) की पहचान कर सकें और तय कर सकें कि उस पेज के साथ क्या करना है।

आपके संभावित सवाल

क्या मेरा इंटीग्रेशन टूट जाएगा? नहीं। बिना किसी निकाले गए टेक्स्ट वाला पेज अब सफल OCR परिणाम जैसा नहीं दिखेगा। यदि आपका कोड प्रत्येक विफलता पर दोबारा प्रयास करता है, तो उसी इंजन पर provider_refused रिक्वेस्ट को दोहराने से बचने के लिए error_code का उपयोग करें।

क्या मैं अस्वीकृत (refused) पेजों के लिए भुगतान करता हूँ? केवल उसी सीमा तक जहाँ तक प्रोवाइडर ने उस प्रयास के लिए OpenOCR को बिल किया है। आप बिना किसी मार्कअप के और कभी भी कोटेशन से अधिक नहीं, सटीक लागत का भुगतान करते हैं। यदि प्रोवाइडर ने हमें बिल नहीं किया, तो आप कुछ भी भुगतान नहीं करते हैं।

इंजनों को स्वचालित रूप से क्यों नहीं बदला जाता? आपने जानबूझकर मॉडल चुना था। किसी अन्य इंजन की कीमत या आउटपुट अलग हो सकता है। हम आपको बताते हैं कि क्या हुआ और फैसला आप पर छोड़ते हैं।

कौन से इंजन प्रभावित हैं? हमने यह पैटर्न मुख्य रूप से Gemini 3.1 Flash-Lite पर पाया, जो पिछले 30 दिनों में प्लेटफ़ॉर्म के खाली परिणामों में से लगभग 97 प्रतिशत के लिए ज़िम्मेदार था। कुछ अन्य इंजनों में भी कभी-कभार ऐसा देखा गया। डिटेक्शन और रिपोर्टिंग अब हर इंजन को कवर करती है।

खाली सेपरेटर (separator) पेजों का मुझे क्या करना चाहिए? ज्ञात सेपरेटरों को अपने दस्तावेज़ वर्कफ़्लो के हिस्से के रूप में हैंडल करें। कोरी शीटों या स्कैन के पीछे के खाली हिस्सों के लिए, उन पेजों हेतु एक समर्पित OCR इंजन का उपयोग करें। हम इसका भी परीक्षण कर रहे हैं कि विज़न मॉडल उन पर कब मनगढ़ंत टेक्स्ट जोड़ते हैं।

आगे: गढ़े हुए टेक्स्ट (invented text) को मापना

इस रिलीज़ का परीक्षण करते समय हमने Gemini 3.1 Flash-Lite को पूरी तरह से कोरा सफ़ेद पेज दिया। इसने ऐसा नहीं किया कि कुछ न लौटाया हो। चारों बार, इसने मनगढ़ंत टेक्स्ट गढ़ा: व्यवसाय के बारे में एक पैराग्राफ, एक गणितीय प्रमाण (maths proof), एक ग्राहक पत्र, और "THE END OF THE CHAPTER"। ऐसा Google के दोनों एंडपॉइंट्स पर होता है, इसलिए यह समस्या खुद मॉडल की है।

मनगढ़ंत टेक्स्ट बनाने वाले इंजन को पकड़ना कुछ भी न लौटाने वाले इंजन की तुलना में अधिक कठिन होता है, क्योंकि आउटपुट वास्तविक दिखता है। हम OpenOCR बेंचमार्क में HallucinationBench नाम से एक कोरे-पेज का परीक्षण जोड़ रहे हैं: एक सार्वजनिक परीक्षण कि कौन से OCR मॉडल खाली पेज पर भी टेक्स्ट देखते हैं। इसके नतीजे एक घोस्ट (ghost) आइकन के साथ OpenOCR रैंकिंग में आ रहे हैं, ताकि प्रत्येक इंजन के गढ़े हुए टेक्स्ट की दर को मापा जा सके और उसकी सटीकता (accuracy) के बगल में प्रकाशित किया जा सके। तब तक, यदि आपके दस्तावेज़ों में सेपरेटर पेज या स्कैन के पीछे के खाली पन्नों जैसी कोरी शीट शामिल हैं, तो उन पेजों के लिए एक समर्पित OCR इंजन का उपयोग करें।