قام نظامنا بشيء واحد وقام به بشكل جيد: تحويل أسئلة اللغة الطبيعية إلى استدعاءات واجهة برمجة التطبيقات (API).
وكان من بين المستخدمين المحللين ومديري الحسابات ومديري العمليات. لقد كانوا يعرفون البيانات التي يحتاجون إليها، ولكن تجميعها يدويًا يتطلب أربع لوحات معلومات، وأداتين لذكاء الأعمال، وأداة لإعداد تقارير Salesforce. لقد أدخلوا الطلب باللغة الإنجليزية البسيطة في نظامنا. تمت ترجمة طلب مثل “تجميع تقرير حجم المبيعات من يناير إلى مارس 2026 للمنطقة الشمالية الشرقية حسب المدينة” إلى استدعاء واجهة برمجة التطبيقات (API) التي يمكن للنظام التصرف بناءً عليها:
json
{
“description”: “طلب المستخدم حجم مبيعات لنطاق زمني محدد، إليك استدعاء واجهة برمجة التطبيقات للحصول على الرد”،
“api_call”: “/api/sales_volume”,
“post_body”: {
“تاريخ_البدء”: “01-01-2026″،
“تاريخ_الانتهاء”: “31-03-2026″،
“المنطقة”: “الشمال الشرقي”
}
}
تم إنشاء الجزء المتبقي من خط الأنابيب باستخدام التكنولوجيا التقليدية. قام النظام بتوجيه المكالمة إلى الواجهة الخلفية المناسبة – أجرينا عمليات تكامل مع بوابات إعداد التقارير الداخلية وSalesforce والعديد من خدماتنا الخاصة – وقمنا بتطبيق نموذج لغة كبير (LLM) (تم إنشاء استعلام JSON لتصفية الاستجابة وتشكيلها، ثم تسليمها عبر البريد الإلكتروني، كمستند Drive، أو عرضها كمخطط في المتصفح.
وبحلول منتصف عام 2025، كان النظام يُصدر عدة مئات من التقارير شهريًا. واستخدمت الإدارة والمحللون هذه التقارير وتم توزيعها على أصحاب المصلحة الخارجيين. أصبحت هذه هي الطريقة الافتراضية التي تقوم بها معظم الفرق بسحب البيانات المخصصة.
كان العقد بين LLM وبقية النظام عبارة عن كائن JSON منظم، كما هو موضح في المثال أعلاه.
json
{
“description”: “طلب المستخدم حجم مبيعات لنطاق زمني محدد، إليك استدعاء واجهة برمجة التطبيقات للحصول على الرد”،
“api_call”: “/api/sales_volume”,
“post_body”: {
“تاريخ_البدء”: “01-01-2026″،
“تاريخ_الانتهاء”: “31-03-2026″،
“المنطقة”: “الشمال الشرقي”
}
}
لقد بنيناه على Claude Sonnet 3.5 في أوائل عام 2025. وقمنا بالترقية إلى 3.7 بدون حوادث وإلى 4.0 بدون حوادث. بحلول الوقت الذي تم فيه إصدار Sonnet 4.5، أصبحنا راضين عن استقرار LLM وإمكانية التنبؤ به في حل ما اعتقدنا أنه مشكلة بسيطة. لقد أصبح تحديث النماذج أمرًا روتينيًا، مثل إسقاط نسخة أصغر من مكتبة جيدة التصرف.
ثم قدمنا الإصدار 4.5. بالنسبة لنسبة كبيرة من الطلبات، بدأ النموذج في طي محتوى post_body في حقل الوصف. حدث وضعان للفشل.
أولاً، لم تصل معلمات التصفية مطلقًا إلى واجهة برمجة التطبيقات (API). نظامنا قرأها post_body كمصدر الحقيقة لحمولة الطلب وعاد هذا الحقل فارغًا. تم إجراء استدعاء واجهة برمجة التطبيقات (API) بدون نطاق زمني ومرشح للمنطقة. اعتمادًا على واجهة برمجة التطبيقات المحددة التي تم استدعاؤها، إما أن تقوم الواجهة الخلفية بإرجاع حجم المبيعات لجميع الأوقات أو لجميع المناطق، أو إرجاع خطأ 500.
ثانياً، بدأ النموذج بطرح أسئلة توضيحية في إجابته. كان هذا جديدا. بذلت الإصدارات السابقة دائمًا قصارى جهدها للطلبات الغامضة وأرجعت كائنًا منظمًا. نظرًا لأن Sonnet 4.5 أكثر حذرًا، فقد أجاب أحيانًا بسؤال بدلاً من ذلك. لم يكن لدى نظامنا طريق لذلك. تم إنشاؤه مع افتراض أن كل استدعاء نموذج سيؤدي إلى استدعاء واجهة برمجة التطبيقات (API). لم يكن هناك مكون بشري في الحلقة أو حالة يمكن فيها تخزين طلب مكتمل جزئيًا. وقد تسبب هذا في فشل أنظمة المصب بطرق متعددة.
لقد عدنا إلى الإصدار 4.0. كان هذا أصعب مما ينبغي: بين الإصدارين 4.0 و4.5، أضاف فريقنا عمليات تكامل جديدة لواجهة برمجة التطبيقات (API)، وكلها مؤهلة للإصدار 4.5. كان عكس النموذج يعني إعادة تدريب كل منهم من الإصدار 4.0 تحت ضغط الوقت.
لماذا يفشل الانضباط الهندسي التقليدي هنا
تعتمد هندسة البرمجيات على القدرة على الحد من تأثيرات التغيير. عندما تقوم بتحديث برنامج تشغيل أو مكتبة، فإنك تقرأ ملاحظات الإصدار لمعرفة ما إذا كان بإمكانك توقع أي تغييرات مهمة. تصف اختبارات الوحدة ما قد يكون قد تحرك. يمكن استغلال الخاصية التالية: النظام الذي يتم تغييره حتمي بدرجة كافية بحيث يمكن التنبؤ بسلوكه، أو على الأقل أخذ عينات منه بكثافة كافية لتوفير اليقين. نصف قطر الانفجار محدود بالهيكل.
الأنظمة التي يدعمها LLM تحطم هذا الافتراض. المكون الذي ينتج الإخراج ليس تحت سيطرتك. لا يمكنك التفريق بين إصدار النموذج من 4.0 إلى 4.5. يعد هذا بديلاً بالجملة للوظائف التي يعتمد عليها نظامك.
وهذا ما نعنيه نصف قطر الانفجار لانهائي: تغيير لا يمكن حساب تأثيراته النهائية مسبقًا لأن مساحة الإدخال (اللغة الطبيعية) وأنماط الفشل (كل شيء يمكن للنموذج القيام به بشكل مختلف) غير محدودة.
تشريح الفشل
أظهر تشريح الجثة أن تلميحاتنا كانت دائمًا غير دقيقة. لقد طلبنا من النموذج إرجاع كائن JSON بثلاثة حقول. لقد وصفنا ما هو كل مجال ل. لم نذكر صراحة أن الوصف يجب أن يكون سلسلة لغة طبيعية ولا يمكن أن يحتوي على تمثيلات متسلسلة لحقول أخرى.
استنتجت الإصدارات السابقة من النموذج هذا القيد من السياق. Sonnet 4.5، على ما يبدو أكثر “مفيدة” مع خيارات التنسيق، قررت أن طلب التوضيح أو تقديم محتوى الطلب في الوصف يزيد من فائدة الاستجابة. ومن وجهة نظر النموذج، كان هذا تفسيرًا معقولًا لتعليمات غامضة. ومع ذلك، فإن هذا ينتهك الافتراضات التي بني عليها نظامنا.
الخطأ لم يكن موجودا في النموذج. كان الخطأ في افتراضنا أن النموذج سيستمر في سد فجوات المواصفات كما كان الحال دائمًا. لقد علمتنا ثلاثة تحديثات ناجحة أن نعتقد أن هذه الثغرات الأمنية آمنة.
ستكتشف أوضاع الإخراج المنظمة وواجهات برمجة تطبيقات الأدوات هذا الفشل المحدد على مستوى المخطط. ولم نستخدمها لأسباب هندسية خارجة عن نطاق هذه المقالة. لكن المخططات تحد فقط من بناء الجملة، وليس الدلالات. لا يمكن للمخطط أن يحدد أن سؤال التوضيح يجب ألا يظهر في النظام دون مسار للتوضيح أو أن نطاق التاريخ يجب ألا يكون افتراضيًا طوال الوقت. الرسوم البيانية تحل النصف الأسهل من المشكلة.
تقييم العمارة الأولى
ويتلخص النظام الذي يسد هذه الفجوة في التعامل مع حزمة التقييم ــ وليس الموجه ــ باعتبارها مواصفات رسمية للنظام. التلميح هو هذا تطبيق تحديد. النموذج هناك مترجم. قيم التقييم هي المواصفات نفسها وأي تغيير في النموذج أو المطالبة يكون صالحًا إذا وفقط إذا تم اجتيازه.
من الناحية العملية، يكون التقييم ثلاثي الأبعاد: الإدخال، والخاصية التي يجب أن تلبيها النتيجة، ووظيفة التسجيل. في نظامنا، يبدو التقييم الذي سيحقق انحدارًا قدره 4.5 كما يلي:
بيثون
def test_description_contains_no_serialized_payload(response):
تنازلي = استجابة(“الوصف”).lower()
ممنوع = (“curl”، “post_body”، “{“، “http://”، “https://”)
تأكيد لا شيء (الرمز المميز في الوصف للرمز المميز المحظور)، \
f”وصف محتوى البنية المسربة: {response(‘description’)}”
بضع مئات من هذه الخصائص، بعضها مكتوب بخط اليد للثوابت المعروفة والمهمة، والبعض الآخر تم إنشاؤه من خلال اختبار الانحدار من حركة الإنتاج الحقيقية، والبعض الآخر تم تقييمه بواسطة LLM كحكم على الخصائص الأكثر ضبابية مثل درجة الصوت، تصبح البوابة. يجب التعامل مع ترقيات النموذج والتغييرات الفورية على أنها طلبات سحب يجب أن تحول الحزمة إلى اللون الأخضر قبل الدمج.
التقييمات مكلفة للبناء والصيانة. إنهم ينجرفون مع تغييرات المنتج. يقدم تسجيل LLM-as-قاضي تباينًا خاصًا به في النتائج. ويمكن للمجموعة فقط التقاط أوضاع الفشل التي تختار تحديدها – لا يمكنك تقييم طريقك إلى الأمان لفئة الفشل التي لم تتخيلها أبدًا. لقد تعلمنا هذا الدرس بالطريقة الصعبة: لم يكتب أحد في فريقنا أبدًا بيانًا يقول “لا ينبغي أن يحتوي حقل الوصف على أمر طي” لأنه لم يعتقد أحد أن النموذج سيضعه هناك.
التقييمات ليست رصاصة فضية. إنها تمنحك القدرة على الحد من نصف قطر الاندفاع للتغيير بالطريقة الوحيدة المتاحة عندما تكون الوظيفة الأساسية عبارة عن صندوق أسود: عن طريق أخذ عينات كثيفة من استجابة الإدخال/الإخراج التي تهتم بها حقًا، ورفض النشر عندما يتغير هذا السلوك.
خطة العمل
لم يقم المجتمع الهندسي بعد بتطوير مجموعة من المعرفة لكتابة تقييمات فعالة. لا توجد معايير مقبولة عالميًا لما تعنيه “التغطية” في مساحات إدخال اللغة الطبيعية. لم يتم إنشاء أنظمة CI/CD لبوابة نتائج الاختبار الاحتمالية. ومع قيام الوكلاء بمزيد من العمل المستقل – كتابة التعليمات البرمجية، وتحويل الأموال، وتخطيط تغييرات البنية التحتية – فإن الانفصال بين “النموذج اجتاز اختبارات الدخان” و”نحن نعرف ما سيفعله هذا النظام في الإنتاج” سيصبح مشكلة هندسية كبرى في السنوات القليلة المقبلة.
والفرق التي ستملأ هذه الفجوة هي تلك التي ستتوقف عن التعامل مع التقييمات التقييمية باعتبارها مسألة ضمان الجودة وتبدأ في التعامل معها باعتبارها مواصفات فعلية لماهية نظامها.
Vijay Sagar Gullapalli هو مهندس الذكاء الاصطناعي المؤسس في Adopt AI ومخترع حاصل على براءة اختراع من USPTO.
سارات ماهافراتاياجولا هو أحد كبار مهندسي البرمجيات في شركة شيروين ويليامز.
مرحبًا بك في مجتمع VentureBeat!
في برنامج نشر الضيوف الخاص بنا، يشارك خبراء التكنولوجيا الأفكار ويقدمون معلومات محايدة ومتعمقة حول الذكاء الاصطناعي والبنية التحتية للبيانات والأمن السيبراني وغيرها من التقنيات المتطورة التي تشكل مستقبل المؤسسات.
اقرأ المزيد من برنامج نشر الضيوف لدينا – وتحقق من موقعنا المبادئ التوجيهية إذا كنت مهتمًا بالمساهمة في مقالتك الخاصة!
