كيف يمكن للمرء تحديد معدل واجهة برمجة تطبيقات التضمين؟ اضطررت إلى إعادة تعيين نموذج التضمين بسبب إيقاف النموذج القديم من Gemini، لذا فهو يحاول الآن إنشاء متجهات جديدة للمنتدى بأكمله (إذا فهمت مشاركتك الأخرى بشكل صحيح). المشكلة هي أنه يفعل ذلك بسرعة كبيرة ويواجه رفض طلبات 429 كثيرة جدًا من Gemini. هل هناك طريقة لتخفيفه؟ أنا ضمن حدود RPD/TPM ولكن لوحة تحكم Gemini تظهر أن discourse يضرب واجهة برمجة التطبيقات مرات كثيرة جدًا. سأكون ممتنًا لأي نصيحة قد تكون لديك هنا (كل شيء كان يعمل بشكل جيد حتى اضطررت إلى إنشاء نموذج تضمين جديد بسبب إيقاف النموذج القديم لـ Gemini).
نعم، إنه 2048 لهذا النموذج المحدد، ولكن يمكنك تكوينه إلى قيمة أقل لتوخي الحذر نظرًا لأن واجهة برمجة تطبيقات Gemini تفتقر إلى معلمة الاقتطاع التلقائي.
إعداد موقع مخفي يسمى ai_embeddings_backfill_batch_size. حاول تعيينه إلى 50 إذا كان موفر واجهة برمجة التطبيقات الخاص بك لا يمكنه التعامل مع الإعدادات الافتراضية الخاصة بنا.
شكرًا. تم ضبطه على 50 وما زلت أحصل على آلاف الأخطاء. سأحاول خفضه إلى 20 وأرى كيف يسير الأمر.
ربما يجب التفكير في إضافة ai_embeddings_backfill_batch_size إلى شاشة تجربة المستخدم لتكوين التضمين، حيث قد يؤثر هذا على العديد من المستخدمين الذين يستخدمون خطط Gemini الأساسية للمواقع الصغيرة (وربما لموفرين آخرين).
على صعيد آخر، يبدو أن هذه هي حجم الدفعة، وعدد الطلبات في استدعاء واحد. ربما تكون المشكلة هي عدد الطلبات التي يتم إجراؤها في الدقيقة (وليس لكل دفعة). هل هناك طريقة لتحديد عدد طلبات الملء الخلفي التي يتم إرسالها في الدقيقة أو في الساعة؟
وجدت أيضًا هذا إذا كان يساعد المستخدمين الآخرين، فإن تضمين gemini الجديد يواجه مشكلات مع الحدود المعينة على 0 إذا تم تجاوزها. هناك حل مؤقت لاستخدام تضمين النص بدلاً من ذلك أو ربما الانتظار قليلاً لمعرفة ما إذا كان سيتم حل المشكلة. ومع ذلك، ما زلت أعتقد أنها فكرة جيدة لـ discourse لإضافة خيار لتحديد عدد استدعاءات واجهة برمجة التطبيقات في الدقيقة للملء الخلفي لتجنب هذه المشكلة في المقام الأول.
ملاحظة: من الرائع جدًا رؤية Google تستخدم أيضًا discourse - أتساءل ما هو الذكاء الاصطناعي الذي يستخدمونه لتشغيل بحث المنتدى الخاص بهم
