الدور والنطاق
صُمّمت وبُنيت بالكامل، وما زالت تُطوَّر باستمرار منذ ذلك الحين: منصة PIM متعددة المستأجرين مع عزل بينهم (مشرف عام، ومشرف مستأجر، ومستخدم)، وسير عمل مسودة/نشر يضمن مراجعة كل تغيير قبل ظهوره، وتسجيل تدقيق كامل بلقطات لما قبل التغيير وما بعده.
- مزامنة تعطي الأولوية لـ Shopify، إلى جانب تكامل مع NetSuite ERP وتصدير إلى Amazon وأسواق أخرى عبر ChannelEngine.
- إثراء بالذكاء الاصطناعي للعناوين والأوصاف ونصوص السيو والترجمات — مع خطوة مراجعة قبل نشر المحتوى المولَّد.
- مساعد RAG مدمج يتيح لفريق المنتج البحث والعمل داخل الكتالوج عبر المحادثة: بحث شعاعي في بيانات المنتجات، مع استدعاءات أدوات للإجراءات التي يجب أن يوافق عليها المستخدم أولًا.
- إضافة مستقلة لمتصفح Chrome تتيح للفريق دفع المنتجات من صفحات الأسواق مباشرةً إلى طابور الإثراء.
- وحدة امتثال لنظام GPSR الأوروبي، ووحدة سيو مع التحقق من حجم البحث عن الكلمات المفتاحية، ومهام خلفية (مزامنة شعاعية، وإثراء، ومجدول) عبر طابور بإعادة محاولات.
الأثر
- أكثر من 3,400 منتج نشط في السوق الأساسية، مع تدفقات تصدير إلى مئات القوائم الإضافية في أسواق مثل Amazon.
- جرى التراجع عن مسار ترجمة بالذكاء الاصطناعي كان يستبدل عناوين URL للفئات بصمت، واستُبدل بنسخة تنشئ عمليات إعادة توجيه وتسجّل كل شيء في سجل تدقيق.
- عولج بنيويًا خلل في المزامنة كان كل ربط بـ NetSuite يستبدل معه المحتوى المولَّد بالذكاء الاصطناعي وتعديلات Shopify، بدل إصلاحه يدويًا في كل مرة.
- أكثر من 350 التزامًا برمجيًا خلال ثمانية أشهر من التطوير المتواصل — ليس تسليمًا لمرة واحدة بل نظامًا ينمو مع تشكيلة المنتجات.
البنية التقنية
مستودع أحادي بـ Turborepo يضم واجهة خلفية بـ NestJS وواجهة أمامية بـ Next.js 14 (App Router)، مع حزمة قاعدة بيانات Prisma مشتركة وأنواع مشتركة. ويخزّن PostgreSQL مع امتداد pgvector بيانات المنتجات والتضمينات معًا، فيعمل البحث الشعاعي والاستعلامات العادية على قاعدة البيانات نفسها. أما العمل في الخلفية (المزامنة الشعاعية، والإثراء بالذكاء الاصطناعي، ومزامنة الأسواق) فيجري عبر طوابير معتمدة على Redis مع إعادة محاولات تلقائية وتراجع أسّي، منفصلة عن الواجهة حتى لا تعطّل مزامنة بطيئة مع أحد الأسواق بقية المنصة.
اختيار النموذج
المساعد المدمج القائم على RAG متعدد المزوّدين عن قصد: تمر المهام المختلفة عبر نماذج مختلفة (من نموذج منخفض التكلفة للمحادثات الاعتيادية إلى إصدارات أثقل من Claude وGPT لمهام الإثراء الأعقد)، مع تتبّع أسعار الرموز لكل نموذج بحيث تكون كلفة كل محادثة ظاهرة لا صندوقًا مغلقًا. أما المحتوى المولَّد (العناوين والأوصاف والترجمات) فيمر دائمًا بخطوة مراجعة أولًا — النموذج يقترح والإنسان يوافق؛ وهو السبب نفسه الذي يجعل منطق التسعير في مشاريع أخرى لا يمر مباشرة عبر نموذج لغوي.
التكلفة وزمن الاستجابة
- تُتتبَّع كلفة الرموز لكل محادثة على مستوى كل نموذج، فتُستخدم النماذج الأغلى بوعي ووضوح لا بشكل افتراضي.
- تعمل المهام الخلفية (المزامنة الشعاعية والإثراء) بشكل غير متزامن بحد أقصى 3 محاولات إعادة وتراجع أسّي، حتى لا يؤدي عطل مؤقت في أحد الأسواق إلى فقدان البيانات فورًا.
- يعمل البحث الشعاعي واستعلامات المنتجات العادية على نسخة PostgreSQL نفسها (pgvector)، ما يغني عن قاعدة بيانات شعاعية منفصلة وطبقة المزامنة المرافقة لها.
الدروس المستفادة
كان مسار الترجمة بالذكاء الاصطناعي يستبدل عناوين URL للفئات دون تحذير بمجرد إعادة توليد الترجمة — وهو أمر يبدو في ظاهره مفيدًا للسيو، لكنه كان يكسر الروابط الخارجية القائمة. عولج ذلك باستعادة العناوين القديمة وإضافة عمليات إعادة توجيه وبناء سجل تدقيق يُظهر مثل هذه التغييرات قبل نشرها. وثمة خلل ثانٍ: كانت كل مزامنة مع NetSuite تستبدل المحتوى المولَّد بالذكاء الاصطناعي وتعديلات Shopify بمجرد ربط المنتج بـ NetSuite — ولم يكن ذلك حادثًا عارضًا بل نمطًا بنيويًا، فعولج بإعادة النظر في اتجاه المزامنة بدل الإصلاح اليدوي في كل مرة. وثالث أصغر لكنه دال: كان مسار الترجمة يترجم اختصارات المواد مثل "RVS" (الفولاذ المقاوم للصدأ) ترجمة خاطئة، وحُلّت المسألة بقاعدة صريحة في قائمة المصطلحات بدل الاتكال على تخمين النموذج للمعرفة المتخصصة.