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

رسم الحدود
الخطأ الشائع هو التوجيه بناءً على ثقة النموذج: شغّل محليًا، وإذا كان النموذج المحلي غير متأكد، صعّد. هذا مغري لأنه سهل القياس، وهو خاطئ لسببين. أولًا، درجات الثقة من النماذج الصغيرة المكممة تكون معايرة بشكل سيئ، لذا يفعّل محفز التصعيد بشكل غير متوقع. ثانيًا، والأهم، أنه يوجه بناءً على المتغير الخاطئ. ما إذا كان يمكن للحمولة أن تغادر الجهاز هو خاصية للبيانات، وليس لمدى صعوبة السؤال.
وجّه حسب فئة البيانات بدلًا من ذلك. عرّف الفئات صراحةً وخصص لكل منها موقع تنفيذ مسموح:
class examples locus
--------------- -------------------------------- ------------------
regulated-pii identifiers, health notes local only
device-private raw sensor frames, local files local only
user-content drafts, transcripts, messages local default,
remote on consent
derived embeddings, redacted summaries remote allowed
public docs, reference material remote preferred
تتم خطوة التصنيف قبل الاستدلال، على الإدخال، وهي حتمية حيثما أمكن: فحوصات المخطط، والوسوم على مستوى الحقل، ومصدر البيانات. حيثما يحتاج التصنيف إلى نموذج، استخدم مصنفًا محليًا صغيرًا مهمته الوحيدة إصدار تسمية فئة — وليس الإجابة على المستخدم.
نمط مفيد هو إبقاء الاستدلال محليًا واستدعاء الأدوات بعيدًا حيث تكون الحمولة خاصة. يقرر النموذج المحلي ما يجب فعله وبأي وسائط؛ ولا يحمل الاستدعاء البعيد سوى الحد الأدنى من مجموعة الوسائط، وليس السياق الكامل أبدًا. يحتاج البحث في التقويم إلى نطاق تاريخ، وليس المحادثة التي أنتجته. يحتاج استدعاء الاسترجاع إلى سلسلة استعلام ومساحة أسماء، وليس مسودة المستخدم. هذا يحافظ على قدرة الخدمات البعيدة للأجزاء التي تستفيد منها — البيانات الطازجة، والفهارس الكبيرة، والحوسبة الثقيلة — بينما تبقى المواد الخاصة على الجهاز.
هنا تكمن المقايضة الصادقة. فصل الاستدلال عن استدعاء الأدوات يكلفك قدرة النموذج البعيد على رؤية السياق الكامل، وهو بالضبط ما يجعل النماذج البعيدة جيدة في المهام الغامضة متعددة الخطوات. أنت تقايض بعض جودة الإجابة مقابل سطح خروج أصغر. يجب أن تُتخذ هذه المقايضة عن قصد، لكل فئة، وأن تُسجل.
صمم للتشغيل المتدهور كحالة من الدرجة الأولى، وليس كمسار خطأ.
ent:

- أي الطلبات تُخدم محليًا بجودة منخفضة؛
- أيها تُوضع في قائمة انتظار وتُعاد عند عودة الاتصال، وكيف يتفاعل الإعادة مع الالتزام بالتكرار (idempotency)؛
- أيها تُرفض تمامًا، برسالة توضح السبب؛
- ماذا توصل واجهة المستخدم، حتى يتمكن المستخدم من التمييز بين المخرجات المتدهورة والمخرجات الكاملة.
النظام الذي ينتج إجابات أسوأ بصمت دون اتصال، دون الإشارة إلى ذلك، أصعب في الثقة من نظام يقول إنه لا يستطيع فعل شيء الآن.
قياس الانقسام
بمجرد وجود الحدود، تحتاج إلى أدوات قياس. ثلاث قياسات تحمل معظم الوزن.
أولًا، نسبة الخدمة المحلية: حصة الطلبات التي تُخدم بالكامل على الجهاز، مقسمة حسب فئة البيانات. رقم إجمالي واحد يخفي ما يهمك، لأن نسبة محلية عالية مدفوعة بطلبات تافهة لا تقول شيئًا عن ما إذا كانت الفئات الحساسة تبقى محلية فعلاً. تتبعها لكل فئة، وتتبعها عبر إصدارات النموذج والتطبيق، لأن تغيير الـ prompt يمكن أن يغير التوجيه.
ثانيًا، فرق الجودة لكل فئة. لكل فئة، احتفظ بمجموعة تقييم صغيرة وشغّلها على المسارين المحلي والبعيد. يخبرك الفرق بما تكلفه الحدود في جودة الإجابة. إذا كان الفرق في فئة ما ضئيلًا، يمكن توسيع المسار المحلي. إذا كان كبيرًا، لديك سبب موثق للانقسام الحالي — ومرشح للتحسين المستهدف بدلًا من التصعيد الشامل.
ثالثًا، زمن الذهاب والعودة المقاس من طرف إلى طرف، بما في ذلك تسلسل السياق. هنا تخطئ مقارنات المحلي مقابل البعيد في أغلب الأحيان. الاستدعاء البعيد ليس مجرد وقت شبكة؛ إنه تجميع الـ prompt، والترميز، والتسلسل، والنقل، والانتظار في نقطة النهاية، والتعبئة المسبقة (prefill)، وفك التشفير، وفك التسلسل. الاستدعاء المحلي له تكاليفه الخاصة: تحميل النموذج، وضغط الذاكرة، وتكلفة التنافس مع بقية التطبيق. قس كليهما من نفس نقطة البداية — لحظة توفر الإدخال — وإلا كانت المقارنة بلا معنى.
ثم راقب التصعيد الصامت. هذا هو نمط الفشل حيث يقوم احتياطي محلي، في ظل ظرف ما، بإعادة توجيه الـ prompt الكامل إلى نقطة نهاية بعيدة. يظهر عادةً عبر إحدى آليات قليلة: غلاف إعادة محاولة يعيد إرسال الحمولة الأصلية بدلًا من المخفضة؛ مسار تسجيل أو تتبع يشحن المدخلات الخام إلى خلفية مراقبة؛ محول استدعاء أدوات يمرر المحادثة بأكملها كسياق لأن واجهة برمجة التطبيقات البعيدة تتوقع قائمة رسائل؛ أو علامة ميزة تقلب فئة من محلي إلى بعيد دون تغيير مقابل في سياسة الخروج.
الدفاع هو جعل الخروج صريحًا وقابلًا للتدقيق. يجب أن تُبنى كل حمولة صادرة بواسطة مكون واحد يعرف فئة البيانات ولا يمكنه إلا إصدار الحقول المسموح بها لتلك الفئة. أكد على ذلك في الاختبارات: بمدخل regulated-pii، يجب ألا تحتوي الحمولة الصادرة على أي حقل من المجموعة المحظورة. سجل الفئة وأسماء الحقول التي غادرت، وليس القيم. إذا فُرضت السياسة عند نقطة اختناق واحدة بدلًا من كل موقع استدعاء، يصبح التصعيد الصامت فشل اختبار بدلًا من حادث إنتاجي.
الملخص العملي: صنف المدخلات حسب الحساسية، ووجه بناءً على ذلك التصنيف، وأبقِ الحمولات الخاصة على الجهاز مع استعارة القدرة البعيدة للأجزاء التي تحتاجها، وعرّف السلوك دون اتصال لكل فئة، وقس الانقسام بحيث تكون النسبة المحلية وفرق الجودة وسطح الخروج كلها مرئية. زمن الاستجابة هو الفائدة التي يلاحظها المستخدمون. خروج البيانات هو ما يقرر ما إذا كان النظام قابلًا للنشر على الإطلاق.
