أرفق ملفات PDF والصور والتسجيلات الصوتية ومستندات Office وجداول البيانات والشرائح والملفات النصية بأي طلب إثراء أو توليد مخطط أو توليد عيّنة أو تعديل مخطط بالذكاء الاصطناعي أو ساحة تجربة. تصل الملفات إلى النموذج إمّا كوحدات بايت أصلية (للنماذج التي تدعم PDF والرؤية والصوت) أو كنص مُستخرَج من الخادم ومُضمَّن في المُوجّه — دون الحاجة إلى OCR يدوي أو نسخ نصي أو تحويل أو تقطيع.
لكل نوع MIME مدعوم وضع تسليم مُهيّأ من قبل المسؤول. يحدد الوضع كيفية وصول الملف إلى النموذج.
تُمرَّر البايتات الأصلية إلى النموذج بصيغة BinaryContent. يقرأ النموذج الملف مباشرةً — دون أي معالجة مسبقة من جانب الخادم.
يتطلب نموذجًا يحمل علامة القدرة المطابقة (supports_pdf_input لملفات PDF،supports_vision للصور،supports_audio_input للصوت). يُصفّى مُنتقي النماذج تلقائيًا لعرض النماذج المتوافقة فقط.
يعمل المستخرِج من جانب الخادم مرة واحدة عند الرفع ويخزّن النص الناتج مؤقتاً. وفي كل استدعاء لاحق لنموذج LLM يُدرَج النص المخزّن ضمن موجّه المستخدم.
لا حاجة لأي قدرة في الموديل — يعمل مع كل موديل. يتخطى النص العادي وMarkdown أداة الاستخراج ويفكّان تشفير البايتات الخام مباشرةً.
تُفعَّل 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 | .odt | binary | odfpy |
| تنسيق النص الغني | .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 |
عند إرفاق أكثر من ملف بتوليد العيّنة، يكون السؤال الأول: ما علاقة هذه الملفات ببعضها — والخطأ في ذلك يُنتج عيّنة بلا معنى دون تنبيه. لذلك يُطرح السؤال صراحةً قبل توليد أي شيء.
عقدٌ وملحقه، ومواصفةٌ وورقة بياناتها: تُقرأ الملفات معًا بوصفها كيانًا واحدًا.
عشر فواتير، وعشر سِيَر ذاتية. يُشتق أضيق نوع يغطّيها جميعًا، وتأتي قيم العيّنة من مستند واحد مختار بدل مزجها عبر المستندات العشرة — فالعيّنة المُجمَّعة من عشرة مصادر لا تصف شيئًا حقيقيًا.
تسع فواتير وصورة إجازة: بدلًا من التخمين، تتوقّف العملية وتسأل عمّا إذا كان ينبغي استبعاد الملف الشاذ. أما الملفات التي لا يجمعها أي قاسم مشترك على الإطلاق فتُفشل العملية مباشرةً، ويُذكر ذلك سببًا.
تغطي آلية التوقّف والسؤال نفسها أي التباس آخر تصادفه أداة التخطيط: تتوقّف المهمة، وتعرض أسئلتها، ثم تستأنف بإجاباتك — داخل التطبيق كمربّع حوار، وعبر API وMCP كخطوة إجابة صريحة. فمنع الافتراض الخاطئ أرخص من اكتشافه في المخطط المُولَّد.
أمر واحد لا تعفيك منه المستندات: المخطط المولَّد من ملفاتك يبدأ وفحص الالتباس فيه مُفعَّلًا، تمامًا كأي مخطط آخر. فذلك الفحص يسأل ما إذا كان اسم الخاصية يحتمل أكثر من معنى — وهو سؤال عن صياغة المخطط، لا عن مصدر قيم هذا التشغيل. لقد حسم مستندك القيم مرة واحدة؛ بينما يُعاد استخدام المخطط لاحقًا مع كيانات لم يشملها قط.
(organization_id, sha256).inline_text، يعمل المستخرِج وقت الرفع ويُخزَّن النص الناتج مؤقتاً في صف المرفق. تُعيد استدعاءات LLM اللاحقة استخدام النص المخزَّن مؤقتاً — دون أي تكلفة إعادة استخراج. أما صيغ binary فتتخطى هذه الخطوة.DELETE /api/attachments/{id} — خطوة تنظيف مفيدة بعد الإثراء. يقتصر الحذف على المؤسسة ويُرجع { success, id, filename }.يمكن رفع المرفقات وحذفها برمجيًا، وليس فقط من واجهة الويب: يرفع موصّل n8n عبر multipart الأصلي، ويرفع موصّلا Make.com وMCP عبر مسار base64 JSON، ويمكن لأي عميل استخدام REST API مباشرةً (DELETE /api/attachments/{id} للتنظيف).
عند إرفاق ملف ثنائي بمتطلب قدرة معيّن (PDF أو صورة أو صوت)، تتم تصفية منتقي النماذج لعرض النماذج التي تعلن عن تلك القدرة فقط. وإذا أرفقت عدة ملفات بمتطلبات مختلفة، تظهر فقط النماذج التي تستوفي جميع المتطلبات.
يطبّق الـ API القاعدة نفسها: فإقران نموذج غير متوافق مع مرفق ثنائي يُعيد 400 model_lacks_attachment_capability، بحيث تحصل التكاملات التي تتجاوز واجهة المستخدم على خطأ واضح قبل التنفيذ بدلاً من فشل المزوّد في منتصف المهمة. أما المرفقات النصية المضمّنة فلا تفرض أي متطلّب على الإطلاق.
| الملفات المرفقة | النماذج المؤهلة |
|---|---|
| ملف PDF واحد | supports_pdf_input |
| ملف PNG واحد | supports_vision |
| 1 MP3 | supports_audio_input |
| ملف PDF واحد + ملف PNG واحد | supports_pdf_input وsupports_vision |
| ملف DOCX واحد (الوضع الثنائي، دون قدرة) | جميع النماذج — يُفترَض الدعم الأصلي للبايتات عند عدم ضبط أي علامة قدرة |
| ملف TXT واحد أو ملف MD واحد (وضع inline_text) | جميع النماذج — يُدرَج النص ضمن المُوجّه |
تُحتسب تكلفة المرفقات باعتبارها رموز إدخال يبلّغ عنها مزوّد النموذج — لا يفرض Entity Enricher رسومًا منفصلة لكل مستند. تعتمد التكلفة على نوع الملف والنموذج المحدَّد.
تستهلك رموزًا مميزة (tokens) للإدخال خاصة بكل نموذج. يتقاضى Anthropic نحو 1700 رمز لكل صفحة PDF؛ ويسعّر OpenAI مدخلات الرؤية حسب عدد البلاطات؛ وتقيس النماذج الداعمة للصوت مُدخل الصوت بما يتناسب مع مدته. راجع بطاقة تسعير نموذجك في Models & Pricing.
يستهلك النص المستخرَج رموز الإدخال بالمعدّل القياسي للنص. تُقتصر المستندات الكبيرة على 500 كيلوبايت من النص المستخرَج — ويُقتطع المحتوى الأطول.