💰 quantitative finance

Your SaaS Is an Insurance Product: A Modeling Framework

تقترح هذه الورقة إطاراً للنمذجة يعامل منتجات البرمجيات كخدمة (SaaS) ذات استهلاك محدد بسقف معين كأدوات تأمين، وذلك عبر تطبيق مبادئ العلوم الاكتوارية مثل تفكيك التكرار والشدة ومحاكاة مونت كارلو لكفاية الاحتياطيات لتحسين التسعير وإدارة مخاطر الذيل للخدمات ذات الأقساط الثابتة والاستهلاك العشوائي ذي الذيول الثقيلة.

المؤلفون الأصليون: Caio Gomes (Magalu)

نُشر 2026-05-19

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Caio Gomes (Magalu)

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

إليك شرح لورقة البحث "برنامجك كخدمة (SaaS) هو منتج تأميني" باستخدام لغة بسيطة وتشبيهات من الحياة اليومية.

الفكرة الكبرى: أنت تدير شركة تأمين (حتى لو كنت تعتقد أنك تبيع برمجيات)

تخيل أنك تدير صالة ألعاب رياضية (جيم). أنت تبيع اشتراكاً شهرياً مقابل 50 دولاراً. وتقول للناس: "تعالوا كما تشاءون من المرات!"

لكن هنا تكمن المشكلة: إذا جاء عضو واحد واستخدم أغلى المعدات لمدة 12 ساعة متواصلة كل يوم، فقد تخسر الصالة المال بسببه. وإذا فعل 100 عضو ذلك، فستفلس الصالة.

يجادل كاتب هذه الورقة بأن شركات البرمجيات كخدمة (SaaS) - مثل روبوتات الدردشة بالذكاء الاصطناعي، أو الاستضافة السحابية، أو تطبيقات الجيم - هي في الواقع تدير شركات تأمين، رغم أنها لا تسمي نفسها كذلك.

إنهم يبيعون "بوليصة" حيث:

القسط (Premium): يدفع العميل رسماً شهرياً ثابتاً (مثلاً 20 دولاراً في الشهر).
التغطية (Coverage): يحصل العميل على قدر معين من الاستخدام (مثلاً 500 رسالة ذكاء اصطناعي).
الحد الأقصى (Limit): إذا استخدم العميل الخدمة أكثر من اللازم، تتوقف الخدمة أو تتباطأ. الشركة ترفض دفع تكلفة الاستخدام الإضافي.
المخاطرة (Risk): الشركة تراهن على أن معظم الناس سيستخدمون الخدمة أقل من الحد الأقصى، لذا فإن الأموال التي يوفرونها من المستخدمين الخفيفين ستغطي تكاليف المستخدمين الثقلاء الذين يصلون إلى الحد الأقصى.

المشكلة الجوهرية: "الذيل الثقيل" (The Heavy Tail)

في عالم البرمجيات، غالباً ما يخمن الناس الأسعار باستخدام عمليات حسابية بسيطة: "إذا كانت الرسالة الواحدة تكلفني 0.01 دولار، والمستخدم يرسل 1,000 رسالة، فسأفرض عليه 20 دولاراً".

تقول الورقة إن هذا أمر خطير؛ لأنه يتجاهل المخاطرة.

المستخدم الخفيف: يرسل 10 رسائل فقط. أنت تحقق ربحاً ضخماً منه.
المستخدم الثقيل: يرسل 100,000 رسالة. أنت تخسر ثروة.

في التأمين، يسمى هذا "الذيل الثقيل". معظم الناس طبيعيون، لكن القليل منهم متطرفون. إذا لم تخطط للمستخدمين المتطرفين، فستفلس.

الحل: العلوم الاكتوارية (علم رياضيات المخاطر)

تقترح الورقة على مهندسي البرمجيات التوقف عن استخدام "اقتصاديات الوحدة" البسيطة والبدء في استخدام العلوم الاكتوارية. وهي الرياضيات التي تستخدمها شركات التأمين منذ 100 عام لتسعير تأمين السيارات، والتأمين الصحي، والتأمين على الحياة.

إليك الأدوات الأربعة الرئيسية التي تقول الورقة إن شركات البرمجيات تحتاجها:

1. التكرار مقابل الشدة (كم مرة؟ وكيف سوء الحالة؟)

بدلاً من مجرد التخمين الإجمالي للاستخدام، قم بتقسيمه:

التكرر (Frequency): كم مرة يضغط المستخدم على الزر؟ (مثل عدد المرات التي يتعرض فيها السائق لحوادث بسيطة).
الشدة (Severity): كم يكلفك كل ضغطة زر؟ (مثل تكلفة إصلاح حادث بسيط للسيارة).
التشبيه: قد يصدم السائق 10 مرات في السنة (تكرار عالٍ) ولكن يخدش المصد فقط (شدة منخفضة). وسائق آخر قد يصدم مرة واحدة فقط (تكرار منخفض) ولكن يدمر السيارة بالكامل (شدة عالية). تحتاج شركات البرمجيات إلى نمذجة كليهما لمعرفة مخاطرها الحقيقية.

2. "السقف" هو حد البوليصة

عندما تقول شركة برمجيات: "لديك 500 رسالة، ثم نتوقف"، فهذا تماماً مثل بوليصة تأمين بـ حد دفع قدره 5,000 دولار.

إذا احتاج المستخدم إلى 600 رسالة، فإن الشركة تدفع فقط مقابل أول 500 رسالة.
يجب على المستخدم دفع تكلفة الباقي (أو التوقف عن استخدام الخدمة).
لماذا هذا مهم: هذا "السقف" يحمي الشركة من الإفلاس. إنه يحول المخاطرة غير المحدودة إلى مخاطرة يمكن إدارتها.

3. الاحتياطيات (صندوق الطوارئ)

شركات التأمين لا تحتفظ بالأرباح فحسب؛ بل تحتفظ بمبلغ ضخم من المال في البنك يسمى الاحتياطي (Reserve). يفعلون ذلك لأنهم يعلمون أنه في بعض الأحيان، سيمر الجميع بشهر سيء في نفس الوقت.

ادعاء الورقة: تحتاج شركات البرمجيات إلى حساب كمية النقد التي يجب أن تحتفظ بها في البنك للنجاة من "شهر سيء" حيث يستهلك المستخدمون الثقلاء الكثير من الموارد.
الرياضيات: يستخدمون طريقة تسمى محاكاة مونت كارلو (Monte Carlo simulation). تخيل رمي النرد 10,000 مرة لرؤية ما قد يبدو عليه أسوأ سيناريو ممكن. إذا قالت الرياضيات إنك بحاجة إلى مليون دولار للنجاة من شهر سيء، فاحتفظ بمليون دولار. إذا كنت تحتفظ بـ 100,000 دولار فقط، فأنت تقامر بحياة شركتك.

4. السلوك البشري (اندفاع نهاية الشهر)

تشير الورقة إلى سلوك بشري طريف.

تشبيه التأمين الصحي: في التأمين الصحي، إذا كان لديك "مبلغ مقتطع" (تدفع أول 1,000 دولار من جيبك)، فإن الناس يهرعون إلى الطبيب في نهاية العام لاستخدام تغطيتهم قبل أن تنتهي صلاحيتها أو تتجدد.
تشبيه البرمجيات: إذا كان لديك حد شهري قدره 500 رسالة، وقد استخدمت 490 رسالة، فستبدأ فجأة في استخدام الخدمة بشكل أكبر بكثير في الأيام الأخيرة من الشهر فقط "لتحقيق أقصى استفادة من أموالك".
المخاطرة: هذا يخلق "طفرة" في الاستخدام قبل إعادة الضبط مباشرة. تحتاج الشركات إلى نمذجة هذا السلوك، وإلا ستفاجأ بزيادة مفاجئة في التكاليف.

أمثلة من الواقع من الورقة

تنظر الورقة إلى شركات حقيقية لإثبات هذه النقطة:

Claude Code / ChatGPT: لديهم فئات "Pro" و "Max" مع حدود. إذا وصلت للحد، تتوقف الخدمة. هذا هو "الحد القاطع" (Hard Cap) لبوليصة التأمين.
Vercel / Cloudflare: لديهم حد، ولكن إذا تجاوزته، يتقاضون منك رسوماً إضافية. هذا يشبه التأمين مع "مبلغ مقتطع" و"مشاركة في التكلفة".
مزايا الجيم للشركات: تدفع الشركات رسماً ثابتاً لموظفيها لاستخدام تطبيق جيم. إذا ذهب الجميع إلى الجيم كل يوم، فستخسر الشركة المزودة للتطبيق المال. هم بحاجة لنمذجة مخاطر "مرتادي الجيم بكثافة".

"الفخ": لماذا تفشل الرياضيات البسيطة؟

تجري الورقة محاكاة تقارن بين طريقتين للتسعير:

الطريقة الساذجة: "نتوقع أن 100 مستخدم سيستخدم كل منهم 100 وحدة (token). التكلفة الإجمالية = 10,000 وحدة. سنفرض 500 دولار".
- النتيجة: يعتقدون أنهم في أمان.
الطريقة الاكتوارية: "نعلم أن 10% من المستخدمين سيصبحون مفرطين في الاستخدام ويستخدمون 10,000 وحدة. نحتاج للاحتفاظ بنقد إضافي تحسباً لذلك".
- النتيجة: يدركون أن "الطريقة الساذجة" تتركهم بدون شبكة أمان. إذا ظهر المستخدمون الثقلاء، فستخسر الشركة المال.

الملخص

الورقة لا تقول إن شركات البرمجيات بحاجة لتصبح شركات تأمين قانونية. بل تقول إنها بحاجة إلى التفكير كشركات تأمين.

توقف عن تخمين الأسعار بناءً على متوسط الاستخدام.
ابدأ في حساب مخاطر "أسوأ سيناريو".
استخدم "السقف" (Cap) للحد من مسؤوليتك المالية.
احتفظ بـ "احتياطي" (Reserve) - أي مبلغ نقدي احتياطي - للنجاة من الأشهر السيئة.
راقب البشر وهم يهرعون لاستخدام حدودهم قبل إعادة الضبط.

باستخدام أدوات رياضيات التأمين القديمة هذه، يمكن لشركات البرمجيات التوقف عن المفاجأة بالمستخدمين الثقيلين والتوقف عن إدخال أعمالهم في طريق الإفلاس عن غير قصد.

ملخص تقني: "منتج البرمجيات كخدمة (SaaS) الخاص بك هو منتج تأميني: إطار عمل للنمذجة"

بيان المشكلة
تتناول الورقة فجوة هيكلية في نمذجة منتجات البرمجيات كخدمة (SaaS) ذات الاستهلاك المحدود بسقف (capped-usage)، بما في ذلك اشتراكات النماذج اللغوية الكبيرة (مثل Claude Code وChatGPT)، والمنصات السحابية (مثل Vercel وCloudflare Workers)، ومنصات المزايا المؤسسية. تعتمد ممارسات الهندسة وعلوم البيانات الحالية عادةً على نمذجة هذه المنتجات باستخدام اقتصاديات الوحدة الساذجة: الحجم المتوقع مضروباً في التكلفة لكل وحدة. وتجادل المؤلفة بأن هذا النهج يفشل في مراعاة الطبيعة العشوائية للاستهلاك، وتوزيعات الشدة ذات الذيول الثقيلة (heavy-tailed distributions)، وديناميكيات تجميع المخاطر المحددة المتأصلة في العقود التي ينفصل فيها القسط الثابت عن الاستهلاك الفعلي.

المشكلة الجوهرية هي أن عقود الـ SaaS ذات الاستهلاك المحدود بسقف تشبه هيكلياً منتجات التأمين ذات حدود السياسة (policy-limit insurance products). في كلتا الحالتين، يتلقى البائع قسطاً ثابتاً، ويواجه طلباً تراكمياً عشوائياً، ويتعرض لمخاطر الذيل (tail risk) التي تكون محددة بسقف تعاقدي ( $K_i$ )، بينما يتحمل المشتري أي استهلاك يتجاوز ذلك السقف. وتفترض الورقة أن التعامل مع هذه المنتجات كمشكلات اقتصاديات وحدة قياسية يؤدي إلى عدم كفاية تخصيص الاحتياطيات وسوء تسعير مخاطر الذيل.

المنهجية
تقترح الورقة إطار عمل للنمذجة مستمد مباشرة من العلوم الاكتوارية، وتحديداً من تأمين غير الحياة، لإعادة صياغة مشكلة تسعير الـ SaaS. يعتمد الإطار على ثلاث ركائز تشغيلية:

تفكيك التكرار والشدة مع الرقابة (Frequency–Severity Decomposition with Censoring):
- التكرار ( $N_i$ ): لا يتم نمذجته كعملية بواسون بسيطة، بل باستخدام توزيعات تأخذ في الاعتبار التشتت الزائد (overdispersion) والتدخل الصفري (zero-inflation) (مثل التوزيعات ثنائية الحد السالب، أو نماذج Hurdle) لالتقاط الطبيعة ثنائية النمط لتفاعل المستخدمين (المستخدمون الخفيفون مقابل المستخدمون الكثيفون).
- الشدة ( $S_{ij}$ ): يتم نمذجة التكلفة لكل حدث (مثل التوكنز، عرض النطاق الترددي، أو استدعاءات الدوال). توضح الورقة أن شدة النماذج اللغوية الكبيرة يمكن تفكيكها بشكل تراكمي (توكنز المدخلات + توكنز المخرجات $\times$ مضاعف النموذج + تكاليف الأدوات)، وهي ميزة هيكلية مقارنة بمطالبات التأمين التقليدية.
- الرقابة (Censoring): تُعرف التكلفة الإجمالية لكل مستخدم ( $C_i$ ) بأنها $C_i = \min(K_i, \sum S_{ij})$ . يخلق السقف $K_i$ توزيعاً خاضعاً للرقابة من جهة اليمين (right-censored). وتجادل الورقة بأن تقدير الاحتمال الأقصى (MLE) الساذج على البيانات المرصودة يقلل من تقدير معاملات الذيل الحقيقية؛ وبدلاً من ذلك، تدعو إلى استخدام تقدير الاحتمال الأقصى لنموذج Tobit الخاضع للرقابة أو تقنيات تحليل البقاء لاستعادة توزيع الشدة الأساسي.
إجمالي خسائر المحفظة وكفاية الاحتياطي:
- تُعامل خسارة المحفظة $L = \sum C_i$ كمجموع لمتغيرات عشوائية مركبة مستقلة (مبدئياً) وخاضعة للرقابة.
- كفاية القسط: يجب أن تغطي الأقساط الإجمالية الخسارة المتوقعة بالإضافة إلى هامش أمان ( $\eta$ ).
- كفاية الاحتياطي: تعرف الورقة الاحتياطي المطلوب $R$ ليس كعامل أمان استرشادي، بل ككمية (quantile) لتوزيع الخسارة الإجمالية. وتحديداً، $R = \text{VaR}_{1-\alpha}(L) - \sum P_i$ أو، بشكل أكثر اتساقاً مع الذيول الثقيلة، باستخدام قيمة المخاطرة عند الذيل (Tail-Value-at-Risk - TVaR). وهذا يوفر إجابة مبدئية على سؤال "كم مقدار الهامش الذي يجب الاحتفاظ به لمواجهة شهر سيء".
التوسعات السلوكية والهيكلية:
- الطلب المستحث (Induced Demand): يدمج إطار العمل الاقتصاد السلوكي، مشيراً إلى أن المستخدمين يسرعون الاستهلاك مع اقترابهم من السقف (بشكل مشابه للوصول إلى الحد الأقصى للمصاريف النثرية في التأمين الصحي) أو مع اقتراب تاريخ إعادة الضبط (بسبب منطق التكلفة الغارقة).
- تباين الأنظمة (Regime Variations): تم تكييف النموذج لثلاثة أنظمة تعاقدية:
  - السقف الصارم (Hard Cap): تتوقف الخدمة عند $K_i$ (مثل حد Claude Code الأقصى).
  - التدهور الناعم (Soft Degradation): تستمر الخدمة عند مستوى أدنى أو بنسبة تكلفة $\rho$ .
  - الاستهلاك المضمن بالإضافة إلى التجاوز (Included-Plus-Overage): يتم فوترة الاستخدام فوق $K_i$ بسعر هامشي (مثل Vercel Pro)، مما ينقل التركيز من كفاية الاحتياطي إلى كفاية تسعير التجاوز.

النتائج الرئيسية والتوضيحات
تتحقق الورقة من صحة إطار العمل من خلال رسم خرائط لمنتجات من الواقع ومحاكاة مونت كارلو:

الربط بالواقع: يربط الجدول 1 منتجات مثل Claude Code وChatGPT وVercel وSupabase بالبدائيات الاكتوارية ( $P, N, S, K, T$ )، مما يوضح أن التوقيع الهيكلي عالمي عبر المجالات المختلفة.
أمثلة عملية من محاكاة مونت كارلو:
- السيناريو الأساسي: مقارنة نموذج "ساذج" لاقتصاديات الوحدة مقابل التوزيعات المركبة (Poisson-Gamma وNB-LogNormal). يتجاهل النموذج الساذج التباين، مما يبالغ في تقدير الهامش التشغيلي. وتكشف النماذج المركبة أنه حتى مع وجود سقف، فإن مخاطر الذيل تؤدي إلى تآكل الهامش بنسبة 2-6% عند أحجام المحافظ النموذجية ( $n=10,000$ ).
- سيناريو الضغط: تمت محاكاة مجتمع من المستهلكين الكثيفين (الاستهلاك المتوقع غير المحدود هو 15 ضعف القسط) تحت أربعة أنظمة سياسات. تظهر النتائج أن نظام "بلا سقف" غير مستقر هيكلياً، بينما يحول "السقف الصارم" المسؤولية غير المحدودة إلى مسؤولية محدودة، مما يسمح بتحقيق الملاءة المالية من خلال تعديلات التسعير بدلاً من امتصاص مخاطر ذيل لانهائية.
- عدم التجانس (Heterogeneity): تظهر عمليات المحاكاة لمجتمعات مختلطة (مستخدمون خفيفون مقابل مستخدمون أقوياء) أنه بينما يركز الاختيار العكسي المخاطر، فإن السقف الصارم يقلص التعرض الفردي بفعالية، مما يجعل تأثير الاحتياطيات على مستوى المحفظة (TVaR) أصغر من خطوط التأمين التقليدية، بشرط أن يكون السقف ضيقاً.
قياس التحيز: تظهر دراسة حول تحيز الرقابة أن تجاهل السقف أثناء ضبط المعلمات يؤدي إلى تقليل تقدير معلمات الشدة بشكل كبير (معدل رقابة بنسبة 20% يمكن أن يؤدي إلى تقليل تقدير الانحراف المعياري بنسبة ~35% في نموذج LogNormal).

المساهمات الرئيسية
تؤطر الورقة مساهمتها صراحةً على أنها تشغيلية وليست نظرية. فهي لا تقترح نظريات جديدة بل:

المصطلحات والأدوات: تقدم مفردات اكتوارية (التكرار-الشدة، التوزيعات المركبة الخاضعة للرقابة، IBNR، كفاية الاحتياطي عبر TVaR) لمجتمع هندسة الـ SaaS، وتجادل بأن هذه الأدوات غائبة حالياً عن ممارسات cs.LG وstat.ML.
الهوية الهيكلية: تثبت أن الـ SaaS ذو الاستهلاك المحدود بسقف ليس مجرد "مشابه" للتأمين، بل هو "منتج تأميني" من حيث إدارة المخاطر التشغيلية، بغض النظر عن التصنيف القانوني.
الأساس الصحيح: تجادل بأن تفكيك التكرار-الشدة مع الرقابة الواعية بالسقف هو الأساس الصحيح لنمذجة التكلفة، وهو متفوق على نموذج "التكلفة المتوقعة لكل وحدة مضروبة في الحجم" الساذج.
النمذجة السلوكية: تحدد "الانكسار" في جدول الأسعار (السقف وإعادة الضبط) كمصدر للاستبدال بين الفترات الزمنية، وتقترح ميزات نمذجة محددة (متغيرات الوقت المتبقي لإعادة الضبط) لالتقاط الطلب المستحث.

الأهمية والادعاءات
تدعي الورقة أن صناعة الـ SaaS تقوم حالياً بـ "إعادة اختراع" هذه الأدوات من خلال قواعد استرشادية عشوائية، مما يؤدي إلى تسعير غير مثالي وإدارة غير كافية للاحتياطيات. ومن خلال اعتماد الآليات الراسخة لعلم الاكتوارية:

تحديد حجم الاحتياطي: يمكن للشركات الانتقال من هوامش الأمان التعسفية إلى متطلبات رأس مال قائمة على أسس رياضية مرتبطة بمخاطر الذيل (VaR/TVaR).
استراتيجية التسعير: يوضح إطار العمل المقايضة بين السقف الصارم (نقل المخاطر إلى المستخدم) وتسعير التجاوز (الاحتفاظ بالمخاطر من قبل البائع)، مما يوضح كيفية معايرة معدلات التجاوز لتغطية التكاليف الهامشية في مجموعات المستخدمين الكثيفين.
الكفاءة: تقترح توجيه جهود النمذجة من اقتصاديات الوحدة نحو تفكيك التكرار-الشدة، مما يقلل من دورة "إعادة الاختراع" لاستراتيجيات التسعير التي تُرى في 2025–2026 (مثل حدود الأسبوع من Anthropic أو بوابات الفئات من OpenAI).

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