للحكم على تجربة مساعد ذكاء اصطناعي داخلي، قارن المخرجات المقبولة والتكلفة الإجمالية بخط أساس قِسته قبل الإطلاق. والمخرجات المقبولة هي النتائج التي يستخدمها الناس كما هي أو بتعديل طفيف. أما التكلفة الإجمالية فتتجاوز استهلاك النموذج بكثير: التكامل، والتقييم، ووقت المراجعة، والدعم، وتحديث المصادر. وأعداد الاستخدام ودرجات الرضا تضيف سياقًا لكنها لا تثبت القيمة وحدها. اتفق مع فريقك مسبقًا على النتيجة التي تبرر التوسع أو التعديل أو التوقف، ولا تعِد بعائد قبل أن تقيسه التجربة.
هذا المقال عن القياس. وإن كنت ما زلت تختار مسار العمل الذي يستحق مساعدًا أصلًا، فابدأ بدليلنا عن اختيار حالات استخدام المساعد الداخلي.
قبل أن تبني شيئًا، اكتب خطة التجربة في صفحة واحدة: المهمة، والمستخدمون، واتجاه التغيير المتوقع، والمقاييس، والقرار الذي ستقود إليه كل نتيجة محتملة. مثال: «في المسودات الأولى لردود العملاء لدى فريق الدعم، نتوقع وقتًا أقل لكل رد دون زيادة في تصحيحات قادة الفريق. وإن لم توفّر المسودات المقبولة وقتًا بعد المراجعة، نتوقف». وليتفق مالك العمل على عتبات النجاح مع مسؤولي التشغيل والهندسة والأمن والشؤون القانونية. ومهما كبرت القيمة التجارية، فهي لا تعفي من متطلبات الأمن والخصوصية والقانون الإلزامية.
ولا تكتب كلمة «العائد» في الخطة قبل أن تحسب التكاليف. فالتجربة اختبار، ومن نتائجها المشروعة أن المساعد لا يستحق التشغيل.
لا يمكنك إثبات تحسّن دون صورة «قبل». قِس العملية الحالية مدة كافية لترى تفاوتها الطبيعي:
- الوقت لكل مهمة، من أنظمة السجلات حيثما أمكن، وإلا فمن توقيت ذاتي لعينات.
- الجودة: إعادة العمل، وتصحيحات المراجعين، والتصعيدات أو الشكاوى المرتبطة بالمهمة.
- الإنتاجية والتراكم: كم مهمة تُنجز، وكم تنتظر.
- زمن الدورة: المدة من وصول الطلب حتى إنجازه.
وثّق طريقة قياس خط الأساس لتستخدم التجربة الطريقة نفسها. قارن مهام متقاربة في الصعوبة وخبرة المستخدمين، واستعن بمجموعة مقارنة متزامنة أو توزيع عشوائي متى أمكن. واذكر حجم العينة وتفاوت النتائج؛ فالفرق بين ما قبل التجربة وما بعدها وحده لا يثبت السببية. وإذا تغيّرت العملية خلال التجربة لأسباب أخرى، كموظفين جدد أو سياسة جديدة، فسجّل ذلك، وإلا حصل المساعد على فضل أو لوم لا يستحقه.
شكل 1: قِس خط أساس منصفًا. قارن مهام ومستخدمين متقاربين.
يدل الاستخدام على التفاعل، لكنه لا يثبت القيمة وحده. سجّل لكل ناتج في التجربة ما حدث له: قُبل كما هو، أو قُبل بعد تعديل، أو رُفض. واطلب من المراجعين سببًا موجزًا عند الرفض أو التعديل الكبير، وأضف أمثلة مسموحًا بها ومقلّصة البيانات إلى مجموعة اختبار بضوابط مناسبة؛ ويشرح دليلنا عن تقييم هلوسة نماذج اللغة كيف تصنّفها باتساق.
ومن هذا السجل تأتي المقاييس المفيدة: نسبة المخرجات المقبولة، والوقت لكل ناتج مقبول بما فيه المراجعة، وهل حافظت الجودة على مستواها بمقياس التصحيحات والتصعيدات نفسه الذي استُخدم في خط الأساس. ووقت المراجعة جزء من التكلفة؛ فالمسودة التي يستغرق فحصها وقت كتابتها لا تثبت توفيرًا زمنيًا بهذا المقياس، وأي تحسّن في الجودة أو الإنتاج يحتاج دليلًا مستقلًا. احتسب وقت المحاولات المرفوضة والإعادات والعمل اليدوي البديل. وحدّد مقام كل نسبة وميّز التعديل الطفيف من إعادة العمل الكبيرة كي لا يخفي معدل قبول مرتفع جهدًا إضافيًا.
تختلف حصة رسوم النموذج أو الواجهة البرمجية بحسب عبء العمل؛ فقِسها بدل افتراض أنها تهيمن على الفاتورة أو أنها هامشية. أما الحساب المنصف فيشمل:
- أعمالًا لمرة واحدة: التكامل مع أنظمة المصادر والهوية، وإعداد البيانات، ومجموعة التقييم، ومراجعة الأمن والخصوصية، وإرشاد المستخدمين.
- تكاليف متكررة: استهلاك النموذج أو استضافته، والبنية التحتية، والمراقبة، وإعادة التقييم بعد التغييرات، ووقت المراجعة البشرية، والدعم، وتحديث التعليمات والمصادر والفهارس.
- تكاليف التغيير: تدريب الموظفين، وتحديث الإجراءات، وإدارة الموردين.
وقرارات التصميم تحرّك هذه الأرقام. فإرشادات Anthropic الهندسية لبناء الوكلاء تشير إلى أن الأنظمة الوكيلية كثيرًا ما تبادل زمن الاستجابة والتكلفة بأداء أفضل في المهمة، وتوصي بإضافة هذا التعقيد عند الحاجة فقط؛ ومسار صياغة بسيط أرخص تشغيلًا وأسهل قياسًا من وكيل في الغالب.
ويصلح إطار AWS Well-Architected قائمة فحص لهذه المراجعة، إذ ينظّم أسئلة البنية في ست ركائز: التميز التشغيلي، والأمن، والاعتمادية، وكفاءة الأداء، وتحسين التكلفة، والاستدامة. وتفيد مبادئ كثيرة منه خارج AWS أيضًا، مع ضرورة تكييف التوصيات الخاصة بخدماتها، وتساعد في كشف تكاليف تنساها التجارب عادة، كالدعم المناوب واختبار الاستعادة.
اعرض الوقت الموفّر بوصفه طاقة عمل متاحة ما لم ينخفض الإنفاق أو تتحقق قيمة قابلة للقياس من إنتاج إضافي. ولتقدير العائد المالي خلال فترة محددة، احسب الفوائد الإضافية المتحققة ناقص التكاليف الإضافية، مقسومًا على التكاليف الإضافية حين تكون موجبة. افصل الاستثمار الأولي عن المصروفات المستمرة، ولا تحتسب وفر العمل نفسه فائدةً وخفضًا للتكلفة معًا. ووضّح الافتراضات وحساسية النتيجة بدل تعميم تجربة صغيرة على المؤسسة كما هي.
شكل 2: احسب التكلفة كاملة. أدخل المراجعة والصيانة.
على المساعد أن يتفوق على الوضع الحالي وعلى أفضل بديل بسيط معًا. قبل التوسع، اسأل: هل يحقق بحث أفضل في المستندات نفسها، أو مجموعة قوالب، أو تغيير في الإجراء، أو ميزة ذكاء اصطناعي في برنامج ترخّصه بالفعل، معظم الفائدة بتكلفة ومخاطر أقل؟ ويساعدك إطارنا للمفاضلة بين SaaS والبرمجيات المخصصة على تنظيم هذه المقارنة بين البناء والشراء.
ضع أرقام التجربة بجانب خط الأساس: الوقت لكل ناتج مقبول، ومقاييس الجودة، والتكلفة الإجمالية لفترة التجربة، مع تقدير لتغيّر كل منها عند التوسع الكامل. ثم اتخذ أحد ثلاثة قرارات:
- التوسع إذا وفّرت المخرجات المقبولة وقتًا ذا قيمة دون خفض الجودة، وكانت التكلفة الإجمالية، بما فيها المراجعة، مبررة.
- التعديل إذا أشار نمط الرفض إلى سبب قابل للإصلاح، كمصادر ناقصة أو تعليمات غامضة، ثم إجراء جولة ثانية مقيسة.
- التوقف إذا استهلك وقت المراجعة ما وفّره المساعد أو تراجعت الجودة. وهذه نتيجة مفيدة أيضًا، لأنها منعت استثمارًا أكبر في المكان الخطأ.
قراءة توضيحية: لنفترض أن معظم المسودات في تجربة فريق الدعم قُبلت بعد تعديل، وأن التعديلات تتركز في خط منتجات واحد وثائقه قديمة. الوقت الموفَّر في المنتجات الأخرى حقيقي، لكن التوسع الآن سينشر الأخطاء نفسها إلى فرق أكثر. فالقرار هنا هو التعديل: حدّث تلك الوثائق، وأضف الحالات المتعثرة إلى مجموعة الاختبار، وأجرِ جولة ثانية مقيسة.
وقبل التوسع، راجع الجاهزية التشغيلية: المراقبة، والدعم، وضوابط الوصول، والاستعادة. وسجّل القرار مع أدلته حتى تبدأ التجربة التالية مما تعلمته.
هذه التوصيات إرشادات من تكنوستاك، لا متطلبات من AWS أو Anthropic، ولا تعني أي عائد بعينه. وإن أردت تخطيط تجربة مقيسة، فيمكن لفريق خدمة أتمتة الذكاء الاصطناعي أن يعدّ معك خط الأساس والتسجيل ونموذج التكلفة.
- Amazon Web Services. AWS Well-Architected Framework: أسئلة لمراجعة البنية عبر التميز التشغيلي والأمن والاعتمادية وكفاءة الأداء وتحسين التكلفة والاستدامة.
- Anthropic. Building effective agents: تشير إلى أن الأنظمة الوكيلية كثيرًا ما تبادل زمن الاستجابة والتكلفة بأداء أفضل، وتوصي بإضافة التعقيد عند الحاجة فقط، وتصف أمثلتها المنشورة في ديسمبر 2024 بأنها تاريخية.
