الذكاء الاصطناعي

باير تطلق محركاً ذكياً متعدد الوكلاء لتحليل بيانات الزراعة

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

رضوان عبدالهاديمحرر وكاتب تقني

نُشر: 23 أكتوبر 2026 · آخر تحديث: 23 أكتوبر 2026 · 4 دقائق قراءة

باير تطلق محركاً ذكياً متعدد الوكلاء لتحليل بيانات الزراعة — الصورة: AWS Machine Learning Blog

من تشغيل النماذج إلى فهم النتائج

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

معمارية محرك القرار الوكيل (ADE)

لسد هذه الفجوة، طورت باير محرك القرار الوكيل (ADE)، وهو منصة متعددة الوكلاء تعمل كواجهة بلغة طبيعية فوق نظام CDE. يعتمد النظام على خدمة Amazon Bedrock AgentCore من أمازون ويب سيرفيسز، والتي سمحت للفريق بالتركيز على سلوك الوكلاء بدلاً من بناء طبقات استضافة وعزل جلسات خاصة بهم. تتميز هذه المنصة ببيئة تشغيل معزولة لكل مستخدم، وإدارة وصول للأدوات عبر بوابة موحدة، وتصميم غير مرتبط بإطار عمل معين، مما أتاح للفريق استخدام إطار LangGraph الخاص بهم لتنسيق العمليات.

توزيع المهام على 22 وكيلاً متخصصاً

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

تسريع التشخيص التشغيلي

توضح حالة عملية كيف يعمل النظام: عندما يسأل مربي محاصيل عن سبب فشل عملية تصنيف ظاهري، يصنف الوكيل الرئيسي الطلب ويوجهه إلى وكيل الاستكشاف. يقوم هذا الوكيل بقراءة بيانات الأداء من Amazon CloudWatch وحالة العملية من واجهة CDE، لتحديد نقطة الفشل وإرجاع التشخيص. بدلاً من قضاء أكثر من ساعة في البحث اليدوي في السجلات وانتظار دعم المهندسين، أصبحت هذه العملية تستغرق أقل من 10 دقائق. في المرحلة الأولى، يحل النظام حوالي 80 في المئة من استفسارات المستخدمين دون الحاجة لتدخل مهندس بشري.

قرارات تصميمية لضمان الإنتاجية

اتخذ فريق باير خمسة قرارات تصميمية رئيسية بالتعاون مع خبراء من AWS Unified Operations. القرار الأول كان فصل حالة التنسيق عن بيئة التشغيل؛ فبينما توفر بيئة التشغيل جلسات معزولة، يتم حفظ نقاط التفتيش الخاصة بإطار LangGraph في Amazon DynamoDB لضمان استئناف العمل بعد إعادة التشغيل أو التوسع. القرار الثاني كان فصل الهوية المؤسسية عن وصول البوابة والصلاحيات الداخلية، مما يضمن أن تبقى المصادقة والتفويض خارج كود الوكلاء نفسه، مما يعزز الأمان ويقلل التعقيد البرمجي.

الشراكة مع AWS في مرحلة ما قبل الإطلاق

لم تكن مشاركة AWS مجرد دعم تقني بعد الإطلاق، بل امتدت لتشمل مرحلة التصميم والإعداد للإنتاجية. عمل مدير الحساب التقني (TAM) ومهندس متخصص في الذكاء الاصطناعي التوليدي (DSE) كجزء من فريق ADE، حيث شاركوا في اجتماعات أسبوعية لمراجعة القرارات التصميمية. ساعد هذا النهج فريق باير على اختبار كل قرار تصميمي ضد سلوك خدمات AWS الفعلية قبل الالتزام به، مع الحفاظ على الملكية الكاملة للمعمارية. كما ساهم هذا التعاون في بناء معرفة عملية بكيفية عمل الحملات التشغيلية، مما جعل الإرشادات التقنية تتناسب مع سياق عمل باير المحدد.