Claude وOllama ساعدا بائعًا على Ozon في معالجة الشهادات خلال يوم واحد وإعادة أكثر من 1000 SKU

بدأت Ozon مبكرًا بفحص شهادات السكاكين قبل دخول المتطلبات الجديدة حيز التنفيذ، وانتهى الأمر لدى أحد البائعين بحظر شبه كامل لمنتجاته. وبدلًا من شهور من التحميل اليدوي للمستندات، بنى البائع بمساعدة Claude وOllama خط معالجة عمليًا عالج مئات الملفات في يوم واحد، وساعد على إعادة أكثر من 1000 SKU إلى البيع.

لماذا توقّف كل شيء

يبيع صاحب هذه الحالة السكاكين على Ozon منذ أكثر من ست سنوات، ويصف شهادات الجودة بأنها مصدر إزعاج دائم. فالمنصة تغيّر متطلباتها باستمرار: في بعض الحالات تكون المستندات إلزامية، وفي أخرى لا تُطلب إلا عند الطلب، والآن قررت Ozon الاستعداد مسبقًا للقواعد الجديدة التي تدخل حيز التنفيذ في 1 أكتوبر 2026. وفي يوم واحد حظر المتجر نحو 1000 SKU بسبب غياب المستندات المطلوبة.

كانت المشكلة تُحل سابقًا يدويًا: الدخول إلى قسم الشهادات في Ozon Seller، وتحميل الملف، ثم ربط المنتجات به واحدًا تلو الآخر. وهذا مزعج لكنه محتمل مع بضع بطاقات منتجات. أما مع ألف SKU فيتحول السيناريو إلى شهور من العمل الرتيب. وزاد الوضع سوءًا أن المستندات لم تكن محفوظة بصيغة PDF، بل كصور JPEG على Google Drive، ولذلك تعذّر استخراج أرقام الشهادات وتواريخها وأرقام الأصناف منها بسرعة بالأدوات المعتادة.

كيف بُني خط المعالجة

لتجنب استنفاد حدود الاستخدام في النموذج السحابي على مئات الصور، نقل البائع عملية التعرف إلى النموذج المحلي qwen3-vl:8b عبر Ollama. وأدّى Claude في هذا المخطط دور المهندس المرشد: ساعد في تصميم البنية، وكتب السكربتات، وشرح خطوات التشغيل، واقترح طريقة ربط OCR بـ Ozon Seller API. وجاء التبسيط الأهم بعد مراجعة الوثائق: تبيّن أنه لا حاجة إلى نشر الصور عبر روابط أو استضافتها بشكل منفصل.

«الاكتشاف الرئيسي: واجهة

Ozon API تقبل الملفات مباشرة عبر multipart/form-data».

وفي النتيجة جاء السيناريو العملي على النحو التالي:

• فُرز المجلد المحلي الذي يضم الشهادات وملاحقها إلى أزواج من الملفات؛
• تعرّف Ollama على رقم الشهادة وتواريخها وأرقام الأصناف من الصور؛
• حمّل السكربت الملفات نفسها إلى Ozon عبر طريقة إنشاء الشهادة؛
• جلب طلب منفصل المطابقة بين offer_id وproduct_id؛
• ربطت الخطوة الأخيرة الشهادات بالمنتجات وحفظت تقريرًا بصيغة CSV.

أين اضطُرّ إلى التبسيط

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

وبعد عدة جولات تخلّى البائع، بالتعاون مع Claude، عن الأتمتة المفرطة في تعقيدها وبسّط المهمة. فبدلًا من الربط الدقيق لكل منتج داخل الشهادة، تقرر تجميع المنتجات حسب العلامة التجارية وتمرير شهادة واحدة إلى Ozon مع ملاحقها، وترك جزء من التحقق على عاتق المنصة. وقد سرّع هذا الحل الوسط خط المعالجة فورًا: ووفق تقدير Claude، انخفض زمن التعرف على 225 زوجًا من الملفات وعدة مستندات متعددة الصفحات من أكثر من خمس ساعات إلى ما بين ساعتين وثلاث تقريبًا.

وأكد التشغيل الفعلي النهائي أن المخطط يعمل خارج الاختبار أيضًا. فقد استغرق التعرف على 231 شهادة 3 ساعات و23 دقيقة بمتوسط 52 ثانية للمستند الواحد، واستغرق التحميل إلى Ozon 34 دقيقة أخرى. ولم يُتمكَّن من التعرف إلا على 228 شهادة، إذ فشل التعرف على 3 شهادات فقط، أي أقل من 1,3% من الإجمالي. وإذا مرّت المراجعة بنجاح، يعيد البائع أكثر من 1000 منتج إلى البيع وينهي مهمة كانت ستمتد سابقًا لشهور.

ماذا يعني ذلك

تُظهر هذه الحالة بوضوح الدور العملي لوكلاء الذكاء الاصطناعي في العمليات الروتينية: لم يحلّ Claude هنا محل النموذج المحلي، بل صمّم العملية وساعد في إصلاح الأخطاء، وأوصل مستخدمًا لا يملك مهارات برمجية إلى نتيجة عملية. وبالنسبة إلى البائعين والفرق الصغيرة، هذه إشارة إلى أن الجمع بين التعرف البصري المحلي وأتمتة API بات قادرًا على حل مهام تشغيلية فعلية، لا مجرد عروض توضيحية.