Divinci AI تنضم إلى Cloudflare Workers Launchpad Cohort #6

يسعدنا أن نشارككم أن Divinci AI قد تم قبولها في Cloudflare Workers Launchpad Cohort #6! يدعم برنامج التسريع هذا الشركات الناشئة المبتكرة التي تبني على منصة الحوسبة الطرفية من Cloudflare، ونحن نشعر بالفخر لكوننا جزءًا من هذه الدفعة الاستثنائية.

لماذا Cloudflare Workers؟

في Divinci AI، نبني الجيل القادم من أدوات التعاون بالذكاء الاصطناعي للمؤسسات مع التركيز على الموثوقية والأمان والأداء. كانت منصة الحوسبة الطرفية من Cloudflare أساسية في تحقيق هذه الأهداف، مما يمكننا من تقديم قدرات ذكاء اصطناعي متطورة بأدنى زمن استجابة عبر العالم.

النشر العالمي على الحافة يمكّن الذكاء الاصطناعي بسرعة الفكر

بنيتنا التحتية المدعومة بـ Cloudflare

قمنا بتصميم منصتنا بالكامل حول مجموعة منتجات Cloudflare، مما أنشأ بنية تحتية قوية وقابلة للتطوير تدعم خطوط أنابيب RAG (التوليد المعزز بالاسترجاع) المتقدمة لدينا:

Cloudflare Workers & Workflows

العمود الفقري لمنصتنا، Cloudflare Workers تشغل طبقة الحوسبة بدون خادم لدينا، مع معالجة ملايين الطلبات بأوقات استجابة أقل من ميلي ثانية. نستخدم Cloudflare Workflows لتنسيق خطوط أنابيب RAG المعقدة متعددة الخطوات التي تسترجع وتعالج وتجمع المعلومات بذكاء من مصادر متعددة.

D1 لتخزين أجزاء RAG

نستفيد من Cloudflare D1، قاعدة البيانات SQL الموزعة، لتخزين والاستعلام عن أجزاء RAG بكفاءة. تضمن هندسة D1 القائمة على الحافة تخزين أجزاء المستندات بالقرب من مستخدمينا، مما يقلل بشكل كبير من زمن استرجاع ويحسن جودة استجابات الذكاء الاصطناعي لدينا.

Vectorize للبحث الدلالي

تعمل Cloudflare Vectorize كأحد خيارات قاعدة بيانات المتجهات لدينا، مما يتيح بحثًا دلاليًا سريعًا للغاية عبر ملايين تضمينات المستندات. يسمح هذا لأنظمة الذكاء الاصطناعي لدينا بالعثور على السياق الأكثر صلة لأي استعلام، بغض النظر عن كيفية صياغته.

Workers AI للنماذج مفتوحة المصدر

ندمج Cloudflare Workers AI لتوفير الوصول إلى نماذج لغة مفتوحة المصدر متطورة من Hugging Face، بما في ذلك Llama 3 و Mistral ونماذج أخرى حديثة. يمنح هذا عملاءنا من المؤسسات المرونة في اختيار النموذج المناسب لحالات الاستخدام المحددة مع الحفاظ على خصوصية البيانات والتحكم.

R2 لتخزين الوسائط

يتعامل Cloudflare R2 مع جميع احتياجات تخزين الصوت ومعالجة الفيديو وتحميل ملفات المستخدمين. مع عدم وجود رسوم خروج وواجهات برمجة تطبيقات متوافقة مع S3، يوفر R2 تخزين كائنات على مستوى المؤسسات يتوسع بسلاسة مع قاعدة عملائنا المتنامية.

API Shield للأمان

مع استعدادنا لإطلاق واجهات برمجة التطبيقات العامة لدينا، يوفر Cloudflare API Shield الحماية الأساسية ضد سوء الاستخدام وتحديد المعدل والتحقق من المخطط. يضمن هذا بقاء واجهات برمجة التطبيقات لدينا آمنة وأدائية وموثوقة لجميع شركاء التكامل لدينا.

التجربة مع Cloudflare Containers

نستكشف أيضًا Cloudflare Containers بينما نعمل على نقل بنيتنا التحتية بالكامل لتكون قائمة بشكل أساسي على Cloudflare. سيمكننا هذا من تشغيل أحمال عمل أكثر تعقيدًا على الحافة مع الحفاظ على الأداء والموثوقية التي يتوقعها عملاؤنا.

كيف تستخدم Divinci فعلًا منصة Cloudflare — منظومة الإنتاج

تجنّبنا هنا فخّ “النثر التسويقي بنكهة Cloudflare”. ما يلي هو المنظومة الفعلية كما تُشحن في monorepo الخاص بنا: 29 Worker إنتاجي، و3 Worker Workflows، و5 نماذج Workers AI، و4 حاويات R2، و6 أنواع من Queues، وHyperdrive على Postgres، وحاويات مدعومة بـ Durable Objects لمعالجة PDF والصوت، و36 tail consumer تبثّ سجلات منظّمة إلى الرصد والمراقبة. القطع مسمّاة وفق روابطها الفعلية ونطاقات مساراتها حتى يتمكن المهندسون الذين يقرؤون هذا من البحث عنها بـ grep.

الطبقة 1 — خمسة عمال أساسيون على الحافة

كل طلب HTTP يصل إلى أحد خمسة عمال بنطاقات مخصّصة:

• divinci-api على api.divinci.app — حدّ REST: المصادقة، التحقق من JWT، حلّ المسارات، التوزيع على العمال الداخليين. تشمل الروابط حاوية R2 المسماة FILES، وفضاء KV المسمى CACHE، وقاعدة بيانات D1 لعناصر المستندات، وWorkers AI، وHyperdrive، وAnalytics Engine، وأربع قوائم انتظار مسمّاة. هذا هو العامل الذي يرى الطلب أولًا.
• web-client-r2-server على chat.divinci.app — الواجهة الأمامية الثابتة، تُقدَّم مباشرةً من R2 عبر عامل خفيف يتولى إعادة الكتابة جانب العامل والتوجيه إلى الـSPA.
• divinci-agent — منسّق تأليف الإجابات. يسحب السياق من D1 و KV و R2، ويقرّر أيّ نموذج Workers AI سيُستدعى (أو ما إذا كان سيُفوَّض الأمر إلى واجهة برمجة خارجية عبر Hyperdrive)، ويؤلّف الاستجابة.
• chunks-workflow على rag-workflow.divinci.app — نقطة دخول Worker Workflows؛ تُستدعى عندما يلزم تشغيل خط أنابيب RAG طويل الأمد.
• connector-sync-worker — عامل الاستيعاب الخارجي الذي يزامن من Dropbox / Drive / موصلات الطرف الثالث المماثلة إلى خط أنابيب RAG.

هناك 24 عاملًا إضافيًا خلف هؤلاء الخمسة (مستهلكو tail، خدمات مصغّرة داخلية) — الخمسة أعلاه هم ما يظهر للإنترنت العامة.

الطبقة 2أ — Worker Workflows (ثلاثة خطوط أنابيب غير متزامنة متعددة الخطوات)

استبدلت Cloudflare Workflows مشغّلات المهام القديمة المعتمدة على Durable Objects العام الماضي. ثلاثة مسارات عمل تعمل في الإنتاج اليوم، وكلها تستخدم نمط نقطة الفحص step.do("name", async () => {…}) بحيث تُعاد كل خطوة بشكل مستقل عند الفشل دون إعادة تشغيل خط الأنابيب بأكمله:

• ReindexWithVersionWorkflow — يعيد تضمين مجموعة المستندات الخاصة بالعميل بأكملها عند تغيّر إصدار نموذج التضمين. يُصدِر الفهرس الناتج بإصدار حتى يكون التراجع مجرّد تبديل ربط واحد.
• BrowserExtractionWorkflow — يستخرج النص من المستندات المرفوعة عبر حاوية Durable Object المسمّاة openparse-cf، ثم يقسّم النص ويضع الأجزاء في طوابير للتضمين.
• AudioToRagWorkflow — يحوّل الصوت إلى نص باستخدام Workers AI Whisper، ويشغّل تشخيص المتحدثين عبر حاوية audio-services، ويقسّم النص الصوتي، ويضعه في طوابير للتضمين.

كل الثلاثة مُعرَّفون في wrangler.toml على النحو التالي:

[[env.production.workflows]]
name = "reindex-with-version"
binding = "REINDEX_WITH_VERSION"
class_name = "ReindexWithVersionWorkflow"

الطبقة 2ب — ست قوائم انتظار مضبوطة لحد الكاتب الواحد في D1

يتدفّق العمل غير المتزامن عبر ست قوائم Queues مسمّاة، لكل منها قيم max_batch_size وmax_concurrency وmax_retries مضبوطة وفق الاختناق الموجود في الخدمة النهائية. تعمل قائمتا chunking وapi-jobs بمعدل دفعة 10/تزامن 5 لأنهما تكتبان إلى D1 (الذي يستخدم كاتبًا واحدًا لكل شارد)؛ وتعمل قائمتا vectorize وreindex بمعدلات أعلى 25/10 لأنهما تستدعيان واجهات تضمين خارجية. تتولى قائمة d1-sync تسلسل عمليات الكتابة على شاردات D1 لكل متّجه حتى لا تتسابق سيرورتان على الصفّ نفسه.

الدرس الذي نتمنى لو تعلّمناه باكرًا: قوائم الانتظار هي الشيء الوحيد الذي يحافظ على استقامة نظام D1 المُجزّأ لكل عميل. بدونها، قد يستولي مستأجر واحد بتحميل كبير على شارد بأكمله ويحرم البقية حتى تنتهي مهلة الطلب.

الطبقة 3 — R2 و D1 و KV و Hyperdrive

تنقسم طبقة التخزين عبر أربع بدائيات، كل واحدة مختارة لنمط وصول مختلف.

R2 (أربع حاويات لكل بيئة) — الروابط هي FILES (مستندات RAG)، وAUDIO_FILES (الصوت المصدر لخطوط النسخ)، وPUBLIC_UPLOADS (مرفقات المحادثة المقدَّمة عبر نقاط نهاية بروابط موقّعة)، وTEMP_UPLOADS (منصة الهبوط للرفع الموقّع مسبقًا). صفر رسوم خروج هي السبب الظاهر، لكن السبب الأعمق هو أن العامل نفسه يستطيع توقيع رابط، واستقبال رفع بحجم عدة ميغابايت، وإطلاق BrowserExtractionWorkflow، وتقديم سياق RAG الناتج — كل ذلك دون مغادرة حافة Cloudflare.

D1 (مُجزّأ لكل مستأجر) — كل عميل يحصل على قاعدة بيانات D1 خاصة به، مع الأجزاء والبيانات الوصفية في جداول عادية وجدول افتراضي FTS5 للبحث النصي فقط. كان التجزيء بالعميل الطريقة الوحيدة لتجنّب اختناق الكاتب الواحد على المستأجرين النشطين. التكلفة هي أننا ندير التوزيع عبر الشاردات في طبقة التطبيق؛ والفائدة أن ارتفاع حمل مستأجر واحد لا يستطيع تجويع قراءات مستأجر آخر.

KV (ثلاثة فضاءات أسماء) — CACHE يحمل نتائج التحقق من JWT وإعدادات المستأجر؛ وEMBEDDING_CACHE هو خريطة هاش-المحتوى → بايتات-التضمين بمدّة TTL تبلغ 30 يومًا (هذا أكبر تخفيض تكلفة قمنا به — تخزين التضمينات حسب هاش المحتوى خفّض فاتورة واجهة التضمين اليومية بمقدار رتبة)؛ وVECTORIZE_CACHE هو طبقة التغليف التي يستخدمها عامل vectorize-cache لتخزين عمليات البحث المتّجهية.

Hyperdrive — تجميع اتصالات Postgres على الحافة. يتيح ربط HYPERDRIVE للعامل فتح اتصال Postgres دون دفع تكلفة مصافحة TCP والمصادقة في كل طلب. نستخدمه للجزء الصغير من البيانات العلائقية (حالة الاشتراك، قوائم التحكم بالوصول على مستوى المنظمة) الذي لا يتلاءم مع نموذج D1 المُجزّأ.

الطبقة 4أ — Workers AI (خمسة نماذج في الإنتاج)

Workers AI هو طبقة الاستدلال داخل المنصة؛ نستخدمها حيث يكون النموذج صغيرًا بما يكفي ليصبح الانتقال إلى مزوّد خارجي غير مجدٍ من حيث زمن الاستجابة أو التكلفة:

للتوليد على نطاق النماذج الرائدة (من فئة Claude و GPT-4)، ما زلنا نوجّه إلى مزوّدين خارجيين عبر Hyperdrive — فهرس Workers AI ينمو لكنه لا يشمل بعد أكبر النماذج التي نحتاجها للاستفسارات الأصعب.

الطبقة 4ب — Containers والبريد والتحليلات ومستهلكو Tail

حاويات Durable Object هي أحدث قطعة في المنظومة: صور Docker كاملة تعمل على وقت تشغيل Workers، محصورة لكل نسخة DO. نشغّل اثنتين:

• openparse-cf محلّل PDF بلغة Python مغلّف كحاوية، يُستدعى من BrowserExtractionWorkflow لتقسيم المستندات.
• audio-services-container يشغّل ffmpeg + pyannote-audio لتشخيص المتحدثين، ويُستدعى من AudioToRagWorkflow. المستوى الذاكري standard-2 (6 GB) ليُحمَّل النموذج الأثقل دون نفاد الذاكرة.

Email Workers — عامل إشعارات معاملاتية يرسل بريد المنتج، وعامل توجيه يدير البريد الوارد على email.divinci.app/verified-emails. كلاهما يستخدم بدائية Email Routing من Cloudflare بدلًا من واجهة بريد خارجية.

Analytics Engine — مجموعة بيانات Workers Analytics Engine هي مصرف الأحداث المنظّمة لتحليلات المنتج. كل ما كنّا سنرسله سابقًا إلى Segment/Amplitude يهبط هنا أولًا ثم يُمرَّر لما بعده.

مستهلكو Tail (36 عاملًا) — كل عامل إنتاجي مهيّأ بقائمة tail_consumers تحتوي على مستهلك مخصّص *_tail. يحلّل كل مستهلك سجلات استدعاءات العامل ويمرّر أحداثًا منظّمة إلى خط أنابيب الرصد. هذا التوزيع هو ما يجعل بنية الخدمات المصغّرة ذات الثمانية عمال قابلة للتشخيص.

مشغّلات Cron — يشغّل الإنتاج وظيفة تنظيف يتامى كل 30 دقيقة؛ ويعمل الـstage كل 10 دقائق لاستجابة أسرع أثناء التكرار على منطق التنظيف.

ملاحظة بشأن Vectorize — ما لا نستخدمه ولماذا

قيّمنا Cloudflare Vectorize أثناء عملية النقل، ولم نعتمده في النهاية مخزنًا متّجهيًا أساسيًا. لم يكن القرار له علاقة بـVectorize ذاته — فقد تحسّن بشكل ملحوظ خلال 2025–2026. السبب الذي قادنا إلى D1 FTS5 + خدمة تضمين خارجية هو أن بنية الاسترجاع لدينا هجينة (لفظية + دلالية مع مُعيد ترتيب مُعاير فوقهما)، وقدّم لنا FTS5 في D1 الشقّ اللفظي مجانًا، وعلى الشارد نفسه الذي يحتوي البيانات الوصفية للمستند. كان إضافة Vectorize ستُدخل نموذج اتساق ثانٍ — فهرس منفصل عليه أن يبقى متزامنًا مع D1 — مقابل تحسّن هامشي في الاستدعاء على الأحجام التي نتعامل معها. اسم فضاء VECTORIZE_CACHE في KV هو بقايا من فترة التقييم؛ العامل خلفه الآن يخزّن عمليات بحث التضمين لا نتائج Vectorize.

إذا تحوّل نموذج الاسترجاع لدينا نحو استرجاع كثيف فقط على نطاق ضخم جدًا، فإن Vectorize هو الخطوة التالية الطبيعية. الإجابة الصادقة تتفوّق على ادّعاء تسويقي.

ما يعنيه هذا لعملائنا

كوننا جزءًا من مسرّع Workers Launchpad يعني أنه سيكون لدينا تعاون أعمق مع فريق هندسة Cloudflare، ووصول مبكر إلى ميزات جديدة، والموارد لدفع حدود ما هو ممكن مع الحوسبة الطرفية والذكاء الاصطناعي.

بالنسبة لعملائنا، هذا يترجم إلى:

• استجابات ذكاء اصطناعي أسرع مع النشر العالمي على الحافة
• موثوقية محسّنة من خلال اتفاقية مستوى الخدمة 99.99% من Cloudflare
• خصوصية بيانات أفضل مع المعالجة على الحافة
• ميزات مبتكرة مدعومة بمنتجات Cloudflare المتطورة
• بنية تحتية قابلة للتطوير تنمو مع احتياجاتك

النظر إلى المستقبل

نحن متحمسون بشكل لا يصدق لهذه الشراكة والفرص التي تجلبها. بينما نواصل بناء مستقبل التعاون المؤسسي المدعوم بالذكاء الاصطناعي، ستبقى منصة Cloudflare في قلب بنيتنا التحتية، مما يمكننا من تقديم تجارب استثنائية للفرق حول العالم.

الابتكار عبر العصور: بناء المستقبل بمبادئ خالدة

هل تريد معرفة المزيد عن كيفية تحويل Divinci AI لسير عمل الذكاء الاصطناعي لفريقك؟ احجز عرضًا توضيحيًا لرؤية منصتنا قيد العمل.

حول Cloudflare Workers Launchpad

Workers Launchpad هو برنامج Cloudflare للشركات الناشئة الذي يوفر التمويل والدعم التقني وموارد الوصول إلى السوق للشركات التي تبني على منصة Workers. تعرف على المزيد حول الدفعة رقم 6 والشركات المبتكرة الأخرى التي تنضم إلى هذا البرنامج.