أحاول إعادة ملء آخر 90 يومًا. لقد نجحت في إعادة ملء حوالي 500 من أصل 2000 موضوع، ولكن التقدم توقف الآن لأنه يستمر في معالجة نفس الموضوع في كل مرة يتم فيها تشغيل المهمة (كل 5 دقائق). لا فكرة لماذا - الموضوع لديه بالفعل ملخص صالح، وليس لديه أي منشورات جديدة في الأيام الـ 12 الماضية. جدول سجلات تدقيق الذكاء الاصطناعي يظهر كل طلب ناجح. حالة Sidekiq على ما يرام. لا شيء ذي صلة في /logs. كيف يمكنني تصحيح هذا؟
SELECT request_tokens,
response_tokens,
raw_response_payload,
topic_id,
created_at AS summary_created_at,
language_model
FROM ai_api_audit_logs
WHERE raw_request_payload LIKE '%Franklin Lexington%'
ORDER BY created_at DESC
LIMIT 40
هناك 5 مشاركات مخفية أو محذوفة في هذا الموضوع. 108-103=5. هل من الممكن أنه لا يتعامل مع المشاركات المخفية والمحذوفة بشكل صحيح؟ نعم، 108 هي أعلى مشاركة، ولكن لم يتم تمرير سوى 103 مشاركة على الإطلاق، لذا يستمر في الاعتقاد بأن هناك 5 مشاركات جديدة لتلخيصها.
لدي موضوع آخر يستمر أيضًا في إعادة إنشاء الملخص. هذا الموضوع لا يحتوي على مشاركات مخفية أو محذوفة، ولكنه مثبت، مما ينشئ مشاركة “تم تثبيت هذا الموضوع عالميًا…”. لذا فإن الحد الأقصى للمشاركات هو 8، ولكن هذه المشاركة الأخيرة لا يتم تمريرها حقًا؟
شكراً لك على التحقيق في الأمر. ولتوضيح التأثير، الأمر لا يقتصر على عدم كفاءة إعادة إنشاء نفس الملخص بشكل متكرر - بل إنه يوقف عملية الملء الاحتياطي تمامًا. لنفترض أن لديك الملء الاحتياطي مضبوطًا على 24 موضوعًا في الساعة. كل 5 دقائق، يحاول موضوعين. في النهاية، يواجه كلا الموضوعين مشكلة - مواضيع محذوفة أو موضوع مثبت أو شيء آخر - ويستمر في محاولة نفس الموضوعين كل 5 دقائق. حتى أنه لا يحاول أي مواضيع أخرى.
أنا أبحث حاليًا في هذا الأمر وأحاول معرفة ما يحدث. ما أشار إليه سام صحيح - قد يتسبب عدم تضمين best_replies للمنشور الأخير في توقف المهمة. أنا على وشك الانتهاء من إصلاح لذلك وتقديم آلية أمان لتحويل المهمة إلى عملية لا تقوم بأي شيء وتسجيل خطأ إذا كان هناك خطأ في الاستعلام. هذا ليس مثاليًا ولا ينبغي أن يحدث، ولكنه أفضل من إعادة إنشاء نفس الملخص مرارًا وتكرارًا.
من ناحية أخرى، أنا أنظر إلى مثال Franklin Lexington... الذي شاركته، والذي أشك في أنه مشكلة مختلفة لأن:
لديه بالفعل ملخص (149).
يجب أن تكون UPPER(ais.content_range) < t.highest_post_number + 1 خاطئة. يجب أن تُرجع UPPER القيمة 109، والتي تساوي highest_post_number + 1.
ستحتاج نهاية فترة content_range إلى أن تكون أقل لكي تتوقف المهمة بسبب ذلك. نحن لا نهتم حقًا بالمنشورات المخفية أو المحذوفة عند تحديد ما إذا كان الملخص قديمًا؛ نريد فقط تجنب تلخيص تلك المنشورات.
هل لديك ai_summary_gists_enabled ممكّن؟ إذا كان الأمر كذلك، هل يمكنك تأكيد أن لديك ملخصين لهذا الموضوع، أحدهما من النوع 0 والآخر من النوع 1؟ أيضًا، في استعلام ai_api_audit_logs الذي شاركته، ما هي القيمة في عمود feature_name؟
لم يعد يقوم بإعادة إنشاء ملخصات للمواضيع التي كان لديها بالفعل ملخص، وهذا أمر جيد.
لكنه لا يلخص العديد من المواضيع، حتى عندما تكون هناك مشاركات جديدة، بسبب:
لذلك يعتقد “backfill” أنه قد انتهى، ولكن ربما 75٪ من أحدث المواضيع ليس لديها ملخص، على الرغم من أنها تحتوي على مشاركات جديدة، فقط لأنها تم إنشاؤها منذ أكثر من 90 يومًا. أنا متأكد من أن هذا ليس هو المقصود. يرجى تغييره أو مساعدتي في فهم السبب.
لقد قمت بعمل نسخة من مستودع الذكاء الاصطناعي حتى أتمكن من تغيير created_at إلى updated_at والمضي قدمًا. ويسرني أن أبلغكم أنه نجح في تلخيص جميع المواضيع التي كنت أتوقع أن يلخصها والتي يزيد عددها عن 400. فشل البعض في أول محاولة للترحيل، ربما لأننا تجاوزنا الحصة المخصصة لتلك الدقيقة، لكنه نجح في تلخيصها في المحاولة الثانية.
على وجه الخصوص، أصبح موضوع فرانكلين ليكسينغتون يحتوي الآن على ملخص.
مرة أخرى، لن يعمل الترحيل بشكل جيد بعد للآخرين، بسبب مشكلة created_at.
إذا كان الفرق هو تعديلات، فسأصوت لإعادة الإنشاء عند التعديلات. لدينا ويكي كأول مشاركة لكل موضوع يقوم الأعضاء بتعديلها ويكي بمعلومات مهمة يمكن أن تؤثر على الملخص.
ولكن إذا اخترت عدم القيام بذلك، يمكنني الاستمرار في تشغيل نسختي.
تستخدم وظيفة الملء الخلفي الآن last_posted_at بدلاً من created_at. لقد أجريت أيضًا تغييرات على المنطق لتحديد ما إذا كان الملخص قديمًا عن طريق التحقق مما إذا كان أي من last_revised_at للمشاركات أحدث من الملخص، لأخذ التعديلات في الاعتبار.
