السكرتيرة الذكية «ليزا بيتروفنا» تنفق $77 شهرياً: DeepSeek يقدّم 88% من الإجابات

نشر صاحب مشروع «ليزا بيتروفنا»، وهي سكرتيرة ذكية في Telegram وMAX، أرقاماً من الخادم الفعلي على Habr. منذ 30 مايو تلقّى البوت 8568 طلباً من 118 شخصاً. وبلغت تكلفة النماذج اللغوية لجميع الوكلاء خلال آخر 30 يوماً $77. يقدّم DeepSeek معظم الإجابات، أي 88%. أما النموذج الغالي Opus فيتلقى نحو 7% من الطلبات، لكنه يستهلك قرابة ثلاثة أرباع الميزانية.

كيف تعمل السكرتيرة

تعمل «ليزا بيتروفنا» بوصفها موزِّعاً للمهام. يكتب المستخدم في تطبيق المراسلة، وتقرر السكرتيرة أي وكيل ستسند إليه المهمة. يعد المؤلف بأن يعرض في النسخة الكاملة من مقاله شيفرة اختيار النموذج، وأن يشرح آلية الذاكرة المبنية على pgvector، أي البحث المتجهي داخل Postgres. ويتضح من الإعلان المنشور الأمر الأهم: النظام لا يمرّر كل الطلبات عبر نموذج واحد غالٍ، بل يوزعها بحسب درجة التعقيد. ولا يتضمن الإعلان تفاصيل التوجيه (routing)، ولذلك يلزم الرجوع إلى المقال الأصلي.

ثمة تفصيل آخر يخص الطلبات نفسها. فالتقويم، وهو ما يرتبط عادةً بالسكرتير، يشكّل أقل من 5% من الطلبات. أما ما يفعله الناس في الـ95% المتبقية فيكشفه المؤلف في النص الرئيسي.

أين تذهب الأموال

لنحسب استناداً إلى البيانات المنشورة. $77 شهرياً تعادل نحو $2,6 يومياً. وثلاثة أرباع الميزانية، أي ما يقارب $58، تذهب إلى Opus. ويتبقى نحو $19 لكل ما عداه، بما في ذلك DeepSeek الذي يقدّم 88% من الإجابات.

إذا حُسبت حصص الطلبات والنفقات على الأساس نفسه، فالتقدير التقريبي أن متوسط تكلفة الطلب إلى Opus يزيد بنحو 40 ضعفاً على متوسط تكلفة الطلب إلى بقية النماذج. وهذا تقدير مبني على النسبتين المئويتين الواردتين في الإعلان، وليس قيمة مقيسة. لكن حجم الفارق دالّ. فالتوفير لا يأتي من المساومة على سعر الرمز (token)، بل من تحديد الطلبات المسموح لها أصلاً بالوصول إلى النموذج الغالي.

المؤشرات الرئيسية للمشروع:

• الفترة منذ 30 مايو: 8568 طلباً من 118 شخصاً؛
• نفقات LLM لجميع الوكلاء خلال 30 يوماً: $77؛
• حصة إجابات DeepSeek: 88%؛
• حصة الطلبات إلى Opus: نحو 7%، وحصة النفقات: نحو 75%؛
• الطلبات المتعلقة بالتقويم: أقل من 5%؛
• الذاكرة: pgvector؛
• القنوات: Telegram وMAX.

ما الذي يمكن الاستفادة منه

لهذه الحالة حدودها. فهي بيانات مؤلف واحد، وجمهورها 118 شخصاً، وليست مقارنة لجودة النماذج. ولا يمكن أن نستنتج منها أن DeepSeek يحل محل Opus. يمكن فقط أن نستنتج أن معظم الإجابات في تدفق فعلي من الطلبات اليومية لا تحتاج إلى نموذج غالٍ.

وبالنسبة إلى من يبنون وكلاء مشابهين، يمكن تلخيص ذلك في بضع خطوات عملية:

• احسبوا التكلفة لكل فئة من الطلبات، لا بالمتوسط العام. فنمط مثل «7% من الطلبات تستهلك 75% من الأموال» يسهل إغفاله إذا اقتصر النظر على الفاتورة الإجمالية.
• اجعلوا النموذج الرخيص الخيار الافتراضي، ولا تستدعوا النموذج الغالي إلا بمؤشر صريح على التعقيد.
• راقبوا ما يطلبه المستخدمون فعلاً. فإذا كان التقويم يشكّل أقل من 5%، فالأجدر تحسين سيناريوهات أخرى.
• لا حاجة بالضرورة إلى قاعدة بيانات متجهية منفصلة للذاكرة. يعمل pgvector داخل Postgres المألوف، وهذا يكفي بهذا الحجم.
• وثّقوا الأخطاء بصراحة. يخصص المؤلف جزءاً مستقلاً للمواضع التي ما زالت السكرتيرة تخطئ فيها، وهذا القسم أنفع من العروض التوضيحية الجذابة.

ووجود MAX إلى جانب Telegram إشارة بحد ذاته: فالبوتات الروسية تتجه بتزايد إلى عدة تطبيقات مراسلة في آن واحد، ويصبح توجيه النماذج طبقة مشتركة بين جميع القنوات.