بطاقات العمل دون سحابة: تسريع PaddleOCR في React Native من 7.8 إلى 3 ثوانٍ

يبدو ماسح بطاقات العمل مهمة تنجز في أمسية واحدة: تلتقط صورة، وترسلها إلى واجهة API، فتحصل على الاسم ورقم الهاتف. لكن البطاقة لا تخصّك، بل تخص شخصًا غريبًا. فاسمه ورقمه ومنصبه تصل إلى الخادم دون علمه، وفي الممارسة الروسية يصطدم ذلك بالقانون 152-FZ. وقد اختار الفريق الذي يتحدث عنه كاتب المقال على موقع Habr حلًا جذريًا: الصورة لا تغادر الهاتف إطلاقًا.

ما الذي بُني ولماذا دون LLM

البنية التقنية كالتالي: PaddleOCR v5 يعمل عبر ONNX Runtime داخل تطبيق React Native على أندرويد. أي أن نموذج التعرف موجود على الجهاز، ولا حاجة إلى الشبكة لمعالجة الصورة.

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

مثال بسيط. يصوّر المستخدم البطاقة، فيعثر OCR على كتل النص ويقرؤها، ويقرر التطبيق بالقوالب أين الهاتف وأين البريد وأين الاسم. كل ذلك يجري محليًا، وفي النهاية يرى المستخدم بطاقة جهة اتصال مكتملة.

من 7.8 إلى 3 ثوانٍ

أوضح رقم في الإعلان: تسارعت معالجة الصورة من 7.8 إلى 3 ثوانٍ. والفرق جوهري للمنتج. فانتظار قرابة ثماني ثوانٍ بعد التصوير يجعل المستخدم يظن أن التطبيق تجمّد. أما ثلاث ثوانٍ فما زالت مقبولة، وإن كانت بعيدة عن الاستجابة الفورية.

لم يذكر الإعلان كيف تحقق التسريع، ولمعرفة التفاصيل لا بد من الرجوع إلى النص الكامل. لكن لـ OCR المحلي على الهاتف مواضع تحسين معتادة: حجم الصورة المُدخلة، وعدد مرات تشغيل النماذج في السلسلة، وصيغة الأوزان، وطريقة نقل البيانات بين JavaScript والشيفرة الأصلية. وفي React Native كثيرًا ما يكون هذا البند الأخير عنق الزجاجة.

القياس عن بُعد الخفي في ONNX Runtime

أفيد تفصيل للممارسين لا يتعلق بالسرعة بل بالخصوصية. يكتب الكاتب أن ONNX Runtime يرسل افتراضيًا شيئًا ما إلى مايكروسوفت. أما ماهية ذلك وفي أي إصدارات فلم يوضح الإعلان، لذلك لا يمكن تقدير حجم التسرب بدقة. لكن الدرس نفسه مهم: عبارة «النموذج يعمل محليًا» لا تضمن أن التطبيق لا يتصل بالشبكة إطلاقًا.

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

ماذا يفعل المطور ومدير المنتج

• افحص حركة الشبكة للتطبيق على جهاز حقيقي، لا الشيفرة فقط. فوكيل مثل mitmproxy يُظهر وجهة الطلبات.
• ادرس إعدادات وإصدارات كل تبعية تتعامل مع بيانات المستخدم، خصوصًا الصور والمستندات. وعطّل كل ما لا حاجة إليه.
• ضع السرعة ضمن مقاييس المنتج. فالمعالجة المحلية شبه دائمًا أبطأ من السحابية، والفرق بين 7.8 و3 ثوانٍ يحدد ما إذا كان المستخدمون سيستعملون الميزة.
• لا تلجأ إلى LLM افتراضيًا. ففي مهمة ضيقة ذات بنية واضحة قد يتفوق OCR خفيف على الجهاز من حيث الخصوصية والتكلفة وإمكانية التنبؤ.

القيود

لقد اطلعنا على الإعلان فقط: لا يتضمن قياسات كاملة ولا طُرز الهواتف ولا دقة التعرف ولا مقارنة مع الحلول السحابية. وأرقام 7.8 و3 ثوانٍ تخص تكوين الفريق المحدد، وقد تختلف على عتاد آخر. كما أن التفسير القانوني للقانون 152-FZ يعتمد على حالتك، لذا يستحسن مناقشته مع محامٍ.

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