किसी भी enrichment, schema जनरेशन, सैंपल जनरेशन, AI schema एडिट या playground रिक्वेस्ट में PDF, इमेज, ऑडियो रिकॉर्डिंग, Office डॉक्युमेंट, स्प्रेडशीट, स्लाइड और टेक्स्ट फ़ाइलें attach करें। फ़ाइलें model तक या तो नेटिव बाइट्स के रूप में पहुँचती हैं (PDF-, विज़न- और ऑडियो-सक्षम models के लिए) या सर्वर-द्वारा निकाले गए टेक्स्ट के रूप में prompt में इनलाइन कर दी जाती हैं — किसी मैनुअल OCR, ट्रांसक्रिप्शन, कन्वर्ज़न या चंकिंग की आवश्यकता नहीं।
प्रत्येक समर्थित MIME प्रकार का एक एडमिन द्वारा कॉन्फ़िगर किया गया डिलीवरी मोड होता है। यह मोड निर्धारित करता है कि फ़ाइल model तक कैसे पहुँचती है।
मूल बाइट्स मॉडल को BinaryContent के रूप में पास किए जाते हैं। मॉडल फ़ाइल को सीधे पढ़ता है — कोई सर्वर-साइड प्रीप्रोसेसिंग नहीं।
मिलान करने वाले कैपेबिलिटी फ़्लैग वाले model की आवश्यकता होती है (PDF के लिए supports_pdf_input, इमेज के लिए supports_vision, ऑडियो के लिए supports_audio_input)। model पिकर स्वचालित रूप से केवल संगत models दिखाने के लिए फ़िल्टर हो जाता है।
एक सर्वर-साइड एक्सट्रैक्टर अपलोड के समय एक बार चलता है और परिणामी टेक्स्ट को कैश कर लेता है। हर बाद के LLM कॉल पर कैश किया गया टेक्स्ट user prompt में इनलाइन कर दिया जाता है।
किसी model क्षमता की आवश्यकता नहीं — हर model के साथ काम करता है। Plain text और Markdown एक्सट्रैक्टर को छोड़कर सीधे raw bytes को डिकोड करते हैं।
19 फ़ॉर्मेट डिफ़ॉल्ट रूप से सक्षम आते हैं। सिस्टम एडमिनिस्ट्रेटर किसी भी फ़ॉर्मेट को binary और inline_text मोड के बीच बदल सकते हैं, उसका लेबल बदल सकते हैं, या उसे Model Management → Document policies से पूरी तरह अक्षम कर सकते हैं।
| फ़ॉर्मैट | एक्सटेंशन | डिफ़ॉल्ट मोड | क्षमता / एक्सट्रैक्टर |
|---|---|---|---|
| PDF दस्तावेज़ | binary | supports_pdf_input | |
| PNG इमेज | .png | binary | supports_vision |
| JPEG छवि | .jpg, .jpeg | binary | supports_vision |
| MP3 ऑडियो | .mp3 | binary | supports_audio_input |
| WAV ऑडियो | .wav | binary | supports_audio_input |
| M4A ऑडियो | .m4a | binary | supports_audio_input |
| OGG ऑडियो | .ogg, .oga | binary | supports_audio_input |
| FLAC ऑडियो | .flac | binary | supports_audio_input |
| सादा टेक्स्ट | .txt | inline_text | रॉ डिकोड |
| Markdown | .md, .markdown | inline_text | रॉ डिकोड |
| Word (लीगेसी .doc) | .doc | binary | docx2txt |
| Word (.docx) | .docx | binary | python-docx |
| OpenDocument text | .odt | binary | odfpy |
| Rich Text Format | .rtf | binary | striprtf |
| EPUB ईबुक | .epub | binary | ebooklib |
| HTML | .html, .htm | binary | beautifulsoup |
| CSV | .csv | binary | csv (stdlib) |
| स्प्रेडशीट (.xlsx) | .xlsx | binary | openpyxl |
| प्रेज़ेंटेशन (.pptx) | .pptx | binary | python-pptx |
जब आप सैंपल जनरेशन में एक से ज़्यादा फ़ाइल अटैच करते हैं, तो पहला सवाल यही होता है कि उनका आपस में क्या रिश्ता है — और यह गलत समझ लेने पर चुपचाप बेतुका सैंपल बन जाता है। इसलिए कुछ भी जनरेट होने से पहले यह स्पष्ट रूप से पूछा जाता है।
एक अनुबंध और उसका संशोधन, एक स्पेसिफ़िकेशन और उसकी डेटाशीट: फ़ाइलें एक ही एंटिटी के रूप में एक साथ पढ़ी जाती हैं।
दस इनवॉइस, दस CV। इन सबको कवर करने वाला सबसे संकुचित टाइप निकाला जाता है, और सैंपल की वैल्यू सभी दस को मिलाकर बनाने के बजाय किसी एक चुने हुए दस्तावेज़ से आती हैं — दस स्रोतों को जोड़कर बनाया गया सैंपल किसी वास्तविक चीज़ का वर्णन नहीं करता।
नौ इनवॉइस और एक छुट्टी की तस्वीर: अनुमान लगाने के बजाय जॉब रुक जाता है और पूछता है कि बेमेल फ़ाइल को बाहर रखना है या नहीं। जिन फ़ाइलों में आपस में कुछ भी समान न हो, वे जॉब को सीधे विफल कर देती हैं, और यही कारण दर्ज होता है।
यही रुककर-पूछने वाला तंत्र प्लानर के सामने आने वाली हर दूसरी अस्पष्टता पर भी लागू होता है: जॉब रुक जाता है, अपने सवाल सामने रखता है, और आपके जवाबों के साथ आगे बढ़ता है — ऐप में एक डायलॉग के रूप में, और API तथा MCP पर एक स्पष्ट answer स्टेप के रूप में। गलत अनुमान को रोकना, उसे जनरेट हुए स्कीमा में खोजने से सस्ता पड़ता है।
एक चीज़ से दस्तावेज़ आपको छूट नहीं देते: आपकी फ़ाइलों से जनरेट हुआ स्कीमा भी बाकी सबकी तरह अस्पष्टता जाँच चालू रहते ही शुरू होता है। वह जाँच यह पूछती है कि किसी प्रॉपर्टी नाम से एक से ज़्यादा अर्थ निकलते हैं या नहीं — यह सवाल इस बारे में है कि स्कीमा किन शब्दों में लिखा गया है, न कि इस बारे में कि इस रन की वैल्यू कहाँ से आईं। आपके दस्तावेज़ ने वैल्यू एक बार तय कर दीं; स्कीमा आगे ऐसी एंटिटी पर दोबारा इस्तेमाल होता रहता है जिन्हें उसने कभी कवर नहीं किया।
(organization_id, sha256) है।inline_text फ़ॉर्मैट के लिए, एक्सट्रैक्टर अपलोड के समय चलता है और परिणामी टेक्स्ट attachment पंक्ति पर कैश हो जाता है। बाद की LLM कॉल कैश किए गए टेक्स्ट का पुनः उपयोग करती हैं — कोई पुनः-एक्सट्रैक्शन लागत नहीं। binary फ़ॉर्मैट यह चरण छोड़ देते हैं।DELETE /api/attachments/{id} से हटा दें — enrichment के बाद का एक सुविधाजनक क्लीनअप कदम। हटाना org-scoped होता है और { success, id, filename } लौटाता है।अटैचमेंट को केवल वेब UI से ही नहीं, बल्कि प्रोग्रामेटिक रूप से भी अपलोड और डिलीट किया जा सकता है: n8n कनेक्टर नेटिव multipart के ज़रिए अपलोड करता है, Make.com और MCP कनेक्टर base64 JSON रूट के ज़रिए अपलोड करते हैं, और कोई भी क्लाइंट सीधे REST API का उपयोग कर सकता है (क्लीनअप के लिए DELETE /api/attachments/{id})।
जब आप कोई कैपेबिलिटी आवश्यकता वाली बाइनरी फ़ाइल (PDF, इमेज या ऑडियो) अटैच करते हैं, तो मॉडल पिकर फ़िल्टर होकर केवल वही मॉडल दिखाता है जो उस कैपेबिलिटी की घोषणा करते हैं। यदि आप अलग-अलग आवश्यकताओं वाली कई फ़ाइलें अटैच करते हैं, तो केवल सभी आवश्यकताओं को पूरा करने वाले मॉडल ही दिखते हैं।
API भी यही नियम लागू करता है: किसी असंगत model को binary attachment के साथ जोड़ने पर 400 model_lacks_attachment_capability लौटता है, इसलिए जो integrations UI को बायपास करते हैं उन्हें job के बीच में provider failure के बजाय एक स्पष्ट प्री-फ्लाइट error मिलता है। Inline-text attachments कभी कोई आवश्यकता नहीं थोपते।
| अटैच की गई फ़ाइलें | योग्य models |
|---|---|
| 1 PDF | supports_pdf_input |
| 1 PNG | supports_vision |
| 1 MP3 | supports_audio_input |
| 1 PDF + 1 PNG | supports_pdf_input और supports_vision |
| 1 DOCX (बाइनरी मोड, कोई क्षमता नहीं) | सभी मॉडल — जब कोई क्षमता फ़्लैग सेट नहीं होता तो नेटिव बाइट समर्थन मान लिया जाता है |
| 1 TXT या 1 MD (inline_text मोड) | सभी मॉडल — टेक्स्ट को प्रॉम्प्ट में इनलाइन किया जाता है |
अटैचमेंट का बिलिंग मॉडल प्रोवाइडर द्वारा रिपोर्ट किए गए इनपुट टोकन के रूप में किया जाता है — Entity Enricher प्रति-दस्तावेज़ कोई अलग शुल्क नहीं लेता। लागत फ़ाइल प्रकार और चयनित मॉडल पर निर्भर करती है।
model-विशिष्ट इनपुट टोकन खर्च करते हैं। Anthropic प्रति PDF पेज लगभग 1700 टोकन चार्ज करता है; OpenAI विज़न इनपुट की कीमत टाइल संख्या के अनुसार लेता है; ऑडियो-सक्षम models ऑडियो इनपुट को उसकी अवधि के अनुपात में मीटर करते हैं। अपने model का प्राइसिंग कार्ड Models & Pricing में देखें।
एक्सट्रैक्ट किया गया टेक्स्ट स्टैंडर्ड टेक्स्ट रेट पर इनपुट टोकन खर्च करता है। बड़े डॉक्युमेंट 500 KB एक्सट्रैक्टेड टेक्स्ट तक सीमित होते हैं — इससे लंबा कंटेंट ट्रंकेट कर दिया जाता है।