أعاد فريق تطوير مشترك من مايكروسوفت ونوفو نورديسك تنفيذ وكيل ذكاء اصطناعي يستخدمه الخبراء الطبيون لاستكشاف بيانات التجارب السريرية الخاصة بشركة نوفو نورديسك، ونقله إلى Microsoft Foundry بوصفه وكيلًا مستضافًا. وفي مقال نُشر على Command Line، يقول المؤلفون إن هذا التحول بسّط العمليات، وعزّز الفصل بين جلسات المستخدمين، وربط الوكيل مباشرةً بأدوات التتبع والتقييم والتحسين في Foundry.
ما الذي يفعله الوكيل
يدعم الوكيل التحليل الثانوي، أي العمل الذي يتجاوز بروتوكول التجربة، مثل اختبار فرضية أو مقارنة مجموعات المرضى. وبحسب الفريق، فإن أداته المحورية هي شيفرة برمجية يكتبها ويشغّلها في بيئة خاضعة للتحكم، ثم يعيد بعد ذلك ملخصًا ورسمًا بيانيًا. وقد نشأ المشروع من مهمة هندسية بنظام الفرق المنتشرة لدى العميل (forward-deployed engineering). وكانت نسخته الأولى في الإنتاج تعمل على Azure Container Apps، مع تخزين المحادثات في PostgreSQL، بينما توفر جلسات Azure Container Apps الديناميكية بيئات معزولة (sandboxes) لتشغيل الشيفرة. وبذلك ظل الفريق مسؤولًا عن التوسع ودورات حياة الجلسات والعزل والشبكات والقياس عن بُعد.
وفي ظل الترتيب الجديد، يقول المؤلفون إنهم ما زالوا يختارون النماذج والأدوات ويقررون كيف ينسّق الوكيل عمله. أما Foundry فتتولى الآن تشغيل نقطة الاتصال وهوية الوكيل، وتوفّر قدرة حوسبية لكل جلسة، وتحفظ الحالة، وتتولى التوسع.
إبقاء الجلسات منفصلة
من التغييرات التي يبرزها المؤلفون طريقة الفصل بين الجلسات. فكل جلسة تعمل الآن في بيئة معزولة مخصصة على مستوى الجهاز الافتراضي، تُطلقها Foundry عند الطلب وتزيلها بعد انقضاء فترة خمول محددة. ويقول الفريق إن هذا مهم لأن الشيفرة التي يولّدها الوكيل نفسه تعمل على بيانات سريرية حساسة. كما تتيح خدمة Foundry Agent Service شبكات خاصة، ويقول المؤلفون إنها تمكّنهم من التحكم في حركة البيانات الواردة والصادرة للبيانات التي يجب أن تبقى ضمن نطاق معتمد.
ويشدد الفريق على أن المنصة لا تتحمل مسؤولية الأمان أو الجودة. فقد كان عليهم مع ذلك ضبط ضوابط الوصول، وحماية بيانات القياس عن بُعد وتقليصها، واختبار الوكيل على حالة الاستخدام الخاصة بهم، وفحص كل نظام يمكن للوكيل استدعاؤه.
خطّطوا للشبكة مبكرًا
يرى المؤلفون أنه ينبغي حسم مسألة الشبكات الخاصة في مرحلة التصميم. فالجلسات تستهلك عناوين IP، ولا يمكن تغيير الشبكة الفرعية المرتبطة بحساب Foundry لاحقًا، ولذلك فإن نطاقًا أصغر مما ينبغي قد يحوّل زيادة اعتيادية في السعة إلى عملية ترحيل أوسع للبنية التحتية. ويستشهدون بإرشادات Foundry الحالية: شبكة فرعية بحجم /24 للإنتاج، على أن يكون /27 أصغر حجم مدعوم للنشرات الأصغر.
التتبع وفحوص الجودة
يعتمد التتبع في Foundry على OpenTelemetry ويحتفظ بالبيانات في Azure Monitor Application Insights؛ وخلال مرحلة الانتقال أرسل الفريق التتبعات أيضًا إلى Langfuse. ولأن التتبع قد يسجّل المطالبات والمخرجات ومدخلات الأدوات ونتائجها، يقول المؤلفون إن بيانات القياس السريرية عن بُعد تستحق المعاملة نفسها التي تحظى بها بقية بيانات الإنتاج الحساسة، بما في ذلك الحجب والتقليل إلى الحد الأدنى وحدود الاحتفاظ وتقييد الوصول.
وترك الفريق عقود الواجهة الخلفية دون تغيير، فتمكّن إطار التقييم القائم لديه من الوصول إلى الوكيل المعاد بناؤه دون تعديل وتقييمه باستخدام مجموعة الاختبار والمقيّمين أنفسهم، بما في ذلك المقارنات مع إجابات مرجعية من خبراء في المجال. ويقول المؤلفون إن هذه الدرجات شكّلت خط أساس للترحيل وفحصًا لرصد أي تراجع.
والمقال هو رواية فريق المشروع نفسه وليس تقييمًا مستقلًا.
