في كثير من أقسام الباثولوجي، يبدأ نقاش AI من مكان تقني أكثر من اللازم: أي GPU نحتاج؟ هل نرفع WSI إلى cloud؟ كم يستغرق تحليل الحالة؟ هذه أسئلة مهمة، لكنها تصل إلى طبيب الباثولوجي متأخرة. السؤال اليومي داخل المختبر أبسط: هل يمكن للنموذج أن يدخل مسار العمل من غير أن يضيف خطوة نقل جديدة، أو محطة انتظار جديدة، أو عبئاً جديداً على الفريق؟
ورقة arXiv الجديدة بعنوان Multi-Teacher Contrastive Distillation for Edge-Efficient Pathology Foundation Models تذهب مباشرة إلى هذه النقطة. الفريق يقترح MuCoDi، وهي طريقة تدريب تضغط تمثيلات نماذج Pathology Foundation الكبيرة إلى نماذج أصغر موجهة للتشغيل على أجهزة محدودة. الفكرة تضع Raspberry Pi في حجمه الصحيح: جهاز اختبار يوضح أن مسار AI في الباثولوجي يحتاج طبقة محلية خفيفة تستطيع قراءة tile بسرعة قرب مكان إنتاج الصورة، مع بقاء المنصة التشخيصية الكاملة مسؤولة عن الحوكمة والتكامل.
المشكلة ليست الدقة وحدها
نماذج Pathology Foundation مثل Virchow2 وUNI2 وH-Optimus-1 أعطت أداء قوياً في تحليل WSI، لكنها كبيرة. بعضها يحتوي مئات الملايين من parameters، وبعضها يتجاوز المليار. هذا الحجم يفرض عادة بنية تشغيل ثقيلة: خوادم GPU، نقل ملفات، جدولة jobs، مراقبة زمن الانتظار، وسياسات صارمة لحركة بيانات المرضى.
طبيب الباثولوجي لا يرى هذه التفاصيل كأرقام على ورقة مواصفات. يراها كتعطل في اليوم التشخيصي. حالة تصل إلى worklist، ثم تنتظر تحليل AI خارج محطة القراءة. WSI تُنقل إلى مكان آخر. النتيجة ترجع بعد مدة غير ثابتة. إذا كان الهدف triage أو prescreening أو فرز حالات biomarker، فإن التأخير يضعف قيمة النموذج حتى لو كان أداؤه جيداً في الورقة.
لذلك تأتي أهمية الاتجاه الذي تختبره MuCoDi. الورقة لا تقدم اختباراً سريرياً جاهزاً للاعتماد، لكنها تسأل سؤالاً عملياً: ما مقدار أداء نماذج Pathology Foundation الذي يمكن حفظه داخل encoder صغير بما يكفي للتشغيل المحلي؟
كيف تعمل MuCoDi؟
الطريقة تستخدم ثلاثة نماذج كبيرة كمعلمين: Virchow2 وUNI2 وH-Optimus-1. بدلاً من تدريب نموذج صغير على label واحد أو على مخرجات معلم واحد، تحفظ MuCoDi embeddings من هذه النماذج الكبيرة ثم تدرب encoders أصغر من عائلات RepViT وMobileOne. التدريب يعتمد contrastive distillation، أي أن النموذج الصغير يتعلم بناء تمثيل قريب من تمثيلات المعلمين، مع الحفاظ على قابلية التشغيل السريع.
قاعدة التدريب في الورقة كبيرة بما يكفي لتكون مفيدة للنقاش: 14.3 مليون tile من TCGA، مأخوذة من 11.8 ألف WSI. بعد ذلك قيّم الباحثون encoders المتجمدة على 23 مهمة تصنيف منظمة سريرياً، مع مقارنة داخلية وخارجية. هذه التفاصيل مهمة لأن طبيب الباثولوجي لا يحتاج وعداً عاماً عن نموذج أصغر. يحتاج أن يعرف إن كان الضغط حافظ على إشارات morphology بما يكفي عند الانتقال إلى بيانات خارجية.
الأرقام التي تهم المختبر
في التقييم الخارجي، حقق Virchow2 قيمة AUROC قدرها 71.8. نماذج MuCoEdge-R2.3 وMuCoEdge-R1.5 وصلت إلى 71.0، أي بفارق 0.8 نقطة مئوية عن أفضل معلم في هذا القياس. MuCoEdge-R2.3 كان بحجم 22.4 مليون parameters، وMuCoEdge-R1.5 بحجم 13.6 مليون. الأهم أن MuCoEdge-R1.0 وصل إلى 70.9 AUROC مع 6.4 مليون parameters و1.12 GFLOPs لكل tile بحجم 224 في 224.
هذه الأرقام لا تكفي وحدها لاتخاذ قرار شراء أو اعتماد. قيمتها أنها تغير طريقة السؤال داخل قسم الباثولوجي. بدلاً من حصر AI في خادم مركزي لكل شيء، يمكن تخيل طبقة أولية قريبة من scanner أو image management system تقرأ tiles بسرعة، تضع أولوية للحالات، أو تحضر features للنظام التالي. الطبيب يبقى صاحب القرار، لكن جزءاً من الحساب لا يحتاج مغادرة البيئة المحلية كل مرة.
اختبار Raspberry Pi 5 في الورقة يوضح الفكرة أكثر. الباحثون قاسوا latency على جهاز دون inference accelerator، وبوضع CPU أحادي الخيط. نماذج MobileOne الأصغر من مليون parameter حققت تسريعاً في قراءة tile واحد يصل إلى 605 مرة مقارنة بـ Virchow2، مع AUROC خارجي بين 66.5 و66.9. هذا الأداء أقل من نماذج RepViT الأكبر، لكنه يضع سقفاً عملياً جديداً للنقاش: هناك مساحة بين نموذج ضخم على GPU ونموذج بسيط لا يحمل قيمة كافية.
أين يدخل هذا في workflow؟
أقرب استخدام واقعي ليس إصدار تشخيص آلي. الاستخدام الأقرب هو حساب features سريعاً قرب مسار WSI، ثم تمريرها إلى خطوات أكثر تخصصاً. في مختبر مزدحم، يمكن لهذه الطبقة أن تساعد في ترتيب worklist، اختيار الحالات التي تحتاج مراجعة مبكرة، أو تشغيل فحص أولي لحالات معينة قبل فتح slide على محطة الطبيب.
قد تكون الفائدة أوضح في المواقع التي لا تمتلك cluster محلياً أو اتصالاً ثابتاً مع cloud. كثير من مختبرات الباثولوجي بدأت scanner وWSI قبل أن تبني فريق MLOps كامل. نموذج خفيف يعمل على workstation عادية أو جهاز قريب من scanner يعطي هذه المختبرات فرصة لاختبار AI من دون بناء بنية تشغيل كبيرة منذ اليوم الأول.
لكن هذا المسار يضيف مسؤوليات. إذا أصبح التحليل قريباً من scanner، يجب ربطه مع patient ID، accession number، جودة WSI، ونسخة النموذج. يجب أن تظهر نتيجة AI داخل سياق case، لا كملف منفصل على مجلد shared drive. كما يحتاج الفريق إلى audit trail واضح: أي نموذج عمل؟ على أي slide؟ بأي إصدار؟ ومن راجع المخرج قبل دخوله في القرار؟
ما الذي لا تثبته الورقة؟
الورقة تقيس encoders على مهام تصنيف، ولا تثبت صلاحية سريرية مباشرة في تقرير مريض. لا توجد هنا موافقة تنظيمية، ولا دراسة reader study داخل routine sign-out، ولا قياس لتأثير النموذج على زمن turnaround أو معدل إعادة الفحص. لذلك يجب قراءة النتائج كدليل تقني قوي على إمكانية الضغط، لا كمنتج جاهز للاستخدام التشخيصي.
هناك أيضاً فرق بين سرعة tile وسرعة case كاملة. WSI واحدة قد تحتوي آلاف tiles، ويجب أن يتعامل النظام مع tissue detection، artifacts، focus، stain variation، وpatch aggregation. طبيب الباثولوجي يحتاج قياساً على مستوى الحالة، مع زمن واضح من دخول WSI إلى ظهور نتيجة قابلة للمراجعة.
ما الأسئلة التي يطرحها طبيب الباثولوجي على البائع أو فريق AI؟
النتائج تجعل قائمة الأسئلة أكثر دقة. عند عرض نموذج مبني على Pathology Foundation، اسألوا عن حجم encoder، مكان تشغيله، زمن التحليل لكل WSI، وحاجة النظام إلى GPU. اسألوا أيضاً عن الأداء الخارجي، لأن الفارق بين TCGA وبيانات مختبركم قد يظهر بسرعة بسبب scanner، fixation، thickness، وstaining protocol.
السؤال الثاني يتعلق بالحوكمة. هل تحفظ المنصة نسخة النموذج داخل LIS أو image management system؟ هل يمكن تتبع كل نتيجة إلى slide وcase ووقت التشغيل؟ هل يستطيع طبيب الباثولوجي تجاهل المخرج أو طلب إعادة التحليل عند وجود artifact؟ هذه التفاصيل تحدد إن كان AI سيخدم القراءة اليومية أو يصبح قناة إضافية للمراجعة اليدوية.
أما السؤال الثالث فهو حدود الاستخدام. نموذج خفيف قد يناسب triage أو prescreening، وقد لا يناسب قراراً تشخيصياً نهائياً. هذه الحدود يجب أن تكون مكتوبة في protocol المحلي، مع خطة validation على حالات من المختبر نفسه. الضغط الناجح للنموذج لا يلغي الحاجة إلى validation، لكنه قد يجعل تنفيذها أقل كلفة وأكثر قرباً من workflow الحقيقي.
سبب اهتمام المختبرات بـ MuCoDi
قيمة الورقة أنها تنقل نقاش AI في الباثولوجي من حجم الخادم إلى نقطة العمل. إذا أمكن حفظ قدر كبير من تمثيلات النماذج الكبيرة داخل encoder صغير، فسيصبح تصميم النظام أهم من استعراض القوة الحاسوبية. طبيب الباثولوجي سيهتم حين يرى النتيجة في المكان الصحيح، في الوقت الصحيح، وبصيغة يستطيع مراجعتها.
هذا لا يجعل النماذج الصغيرة حلاً كاملاً. لكنه يفتح طريقاً عملياً: AI قريب من WSI، مرتبط بالهوية الصحيحة للحالة، خاضع للتتبع، ومحدود بوظيفة واضحة. عندها يصبح السؤال داخل المختبر أكثر نضجاً: أي جزء من الحساب يجب أن يحدث محلياً، وأي جزء يحتاج منصة أكبر، وكيف نحافظ على قرار الطبيب داخل المسار؟