Agentic AI FinOps: إدارة التكلفة، وزمن الاستجابة، والسعة

مدير خدمات مشتركة يرى أن النموذج التجريبي (pilot) لمعالجة استثناءات الحسابات الدائنة (AP) يعمل بسلاسة. تبدو التكلفة لكل معاملة في لوحة المعلومات صغيرة، وزمن الاستجابة (latency) معقول، والفريق سعيد لانخفاض عبء العمل. بعد ستة أشهر، عندما يرتفع الحجم عشرة أضعاف، تنتفخ فاتورة السحابة، ويبدأ المستخدمون في الشكوى من البطء، ويجد فريق تقنية المعلومات صعوبة في مواكبة السعة. ماذا حدث؟

غالبًا ما يخفي النموذج التجريبي الذي يبدو رخيصًا التكاليف الحقيقية. سير العمل العاملي (Agentic workflow) ليس مجرد استدعاء نموذج بسيط. يمكن أن يشمل عدة خطوات من الاستدلال (reasoning)، واسترجاع (retrieval) من طبقة المعرفة، واستدعاء أدوات (tool calls) إلى أنظمة المؤسسة، وإعادة المحاولات (retries)، والتقييم، والتسجيل (logging)، وأحيانًا تنسيق عدة وكلاء (agents) في وقت واحد. عندما يُنقل هذا النمط إلى نطاق المؤسسة، تتغير اقتصادياته (economics) بالكامل.

هنا تحتاج الشركات إلى البدء في التفكير في Agentic AI FinOps. ليس فقط لتوفير الرموز (tokens)، بل لإدارة ثلاثة أشياء في وقت واحد: ما هي التكلفة الحقيقية لإنتاج نتيجة ناجحة، ومدى سرعة تقديم الوكيل لنتيجة لا تزال قابلة للاستخدام، وما إذا كانت المنصة (platform)، والنموذج، وواجهة برمجة التطبيقات (API)، وفريق العمليات قادرين على التعامل مع الحجم والارتفاعات المفاجئة في الحمل.

لماذا يخدعك النموذج التجريبي غالبًا في الاقتصاديات

الخطأ الأكثر شيوعًا هو حساب تكلفة الوكيل فقط من سعر النموذج لكل رمز (token) أو لكل طلب (request). في سير عمل المؤسسة، يمكن أن تتكون النتيجة الواحدة من مكونات عديدة. خذ مثال معالجة استثناءات الحسابات الدائنة: يتلقى الوكيل حالة، ويجلب السياق من نظام تخطيط موارد المؤسسة (ERP) وقاعدة المعرفة، ويستدعي النموذج للتصنيف، ويستدعي أداة للتحقق من حالة الفاتورة وإشعار الاستلام، وقد يقوم بإعادة المحاولة إذا كانت البيانات غير كاملة، ثم يعد توصية أو تصعيدًا. للوهلة الأولى، تبدو كل خطوة رخيصة. لكن التكلفة الحقيقية تظهر من التراكم.

نفس الشيء يحدث في عمليات خدمة العملاء. قد يقرأ وكيل استرداد الأموال تاريخ العميل، ويتحقق من الأهلية، ويجلب السياسة، ويصوغ توصية، ويطلب الموافقة لحالات معينة، ثم يسجل النتيجة في نظام إدارة علاقات العملاء (CRM). إذا كان حجم الحالات اليومي مرتفعًا، فإن التكلفة الصغيرة لكل خطوة ستصبح جوهرية. خاصة إذا كان الوكيل يقوم في كثير من الأحيان بحلقات (loops)، أو إعادة محاولات (retries)، أو استدعاء نموذج كبير جدًا لمهمة بسيطة في الواقع.

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

لهذا السبب، المقياس الأكثر دقة ليس التكلفة لكل موجه (cost per prompt) أو التكلفة لكل رمز (cost per token)، بل التكلفة لكل نتيجة ناجحة (cost per successful outcome). ما يجب حسابه ليس فقط تكلفة الاستدلال (inference)، بل تكلفة إنتاج نتيجة ذات قيمة حقيقية. على سبيل المثال، التكلفة لكل استثناء تم تصنيفه وتوجيهه بنجاح، التكلفة لكل استرداد منخفض المخاطر تم إكماله دون إعادة عمل، أو التكلفة لكل حادث تم فرزه بشكل صحيح. إذا كان الوكيل رخيصًا ولكن معدل التصحيح (correction rate) مرتفعًا، أو معدل التصعيد (escalation rate) مفرطًا، أو كان لا بد من إعادة العديد من الحالات، فإن اقتصادياته سيئة في الواقع.

ستة محركات للتكلفة غالبًا ما يتم تجاهلها

لإدارة الاقتصاديات بشكل جيد، تحتاج الشركات إلى فهم من أين تأتي التكاليف حقًا. في الأنظمة العاملة (agentic systems)، هناك ستة محركات رئيسية.

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

ثانيًا، طول السياق (context length). طول السياق هو قاتل التكلفة الذي غالبًا ما يكون غير مرئي. كلما زاد عدد المستندات والنصوص والتواريخ والبيانات الوصفية التي يتم إدخالها في الموجه (prompt)، زادت تكلفة الاستدلال وبطئه. غالبًا ما تظهر هذه المشكلة عندما لا تكون المنظمة منضبطة في بناء استرجاع (retrieval) دقيق. ونتيجة لذلك، يُعطى الوكيل الكثير من السياق "احتياطًا". ترتفع التكلفة، ويسوء زمن الاستجابة، وقد لا تكون الجودة أفضل بالضرورة لأن النموذج يغرق في الضوضاء (noise).

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

رابعًا، استدعاءات الاسترجاع (retrieval calls) واستدعاءات الأدوات (tool calls). كل استدعاء استرجاع إلى مخزن المتجهات (vector store)، أو الرسم البياني المعرفي (knowledge graph)، أو منتج البيانات (data product) له تكلفة حسابية وزمن استجابة. كل استدعاء أداة إلى نظام تخطيط موارد المؤسسة (ERP)، أو إدارة علاقات العملاء (CRM)، أو نظام معلومات الموارد البشرية (HRIS)، أو نظام إدارة خدمات تقنية المعلومات (ITSM) له أيضًا تكلفة، سواء بشكل مباشر أو غير مباشر: استهلاك واجهة برمجة التطبيقات (API)، وعبء الوسيطة (middleware)، ومعالجة الأحداث، وأحيانًا تكاليف الترخيص أو المنصة. في المؤسسة، غالبًا ما تكون استدعاءات الأدوات أكثر تكلفة من الناحية التشغيلية مما يبدو على مستوى تطبيق الذكاء الاصطناعي.

خامسًا، تكرار التقييم (evaluation) وقابلية الملاحظة (observability). للتسجيل (logging)، والتتبع (tracing)، وتخزين التدقيق (audit storage)، والتقييم بعد الإنتاج تكاليف أيضًا: تخزين النصوص والتتبعات، ومعالجة القياس عن بعد (telemetry)، ولوحات المعلومات والتنبيهات، ومراجعة العينات، والاختبارات الانحدارية (regression testing) الدورية. كلما نضجت الحوكمة (governance)، زادت تكلفة التحكم. هذا ليس سببًا لتقليل قابلية الملاحظة، بل سبب لإدراجها في نموذج التكلفة منذ البداية.

سادسًا، تنسيق الوكلاء المتعددين (multi-agent orchestration). يمكن للهندسة المعمارية متعددة الوكلاء أن تزيد من النمطية (modularity)، ولكنها يمكن أن تؤدي أيضًا إلى تفاقم الاقتصاديات. إذا كان يجب أن يمر طلب واحد عبر المنسق (orchestrator)، ثم اثنين أو ثلاثة وكلاء مهام، فإن التكلفة لكل نتيجة ترتفع بسرعة. هذا النمط مناسب إذا كان يوفر بالفعل جودة أو تحكمًا أفضل. ولكن بالنسبة لحالات الاستخدام البسيطة، غالبًا ما يكون تعدد الوكلاء رفاهية معمارية غير اقتصادية.

خمس روافع للتحسين دون الإضرار بالنتيجة

لا يعني التمويل التشغيلي السليم (FinOps) دائمًا اختيار الخيار الأرخص. الهدف هو إيجاد المزيج الأكثر منطقية من التكلفة والجودة والمخاطر لحالة استخدام معينة.

توجيه النموذج (Model routing) هو الرافعة الأكثر أهمية. استخدم نموذجًا صغيرًا للمهام البسيطة ونموذجًا أقوى فقط للاستدلال المعقد، والحالات الغامضة، والقرارات عالية المخاطر، أو التوليف عبر مصادر متعددة. في إقفال الحسابات المالية (finance close)، على سبيل المثال، نموذج خفيف لاستخراج محركات التباين (variance drivers) من البيانات المنظمة، ونموذج أقوى لصياغة تعليق أولي (draft commentary) يجمع بين الأرقام والسياسة والسرد التجاري. المفاضلة (trade-off) واضحة: التوجيه يضيف تعقيدًا للهندسة المعمارية والتقييم. ولكن بدون توجيه، ستصبح التكاليف خارجة عن السيطرة بسرعة.

قلل من تضخم السياق (context bloat). الكثير من تكلفة الذكاء الاصطناعي العاملي هي في الواقع تكلفة السياق المفرط. ثلاث تقنيات عملية أكثر: استرجاع أكثر دقة، والتلخيص (summarization) قبل الاستدلال الرئيسي، والتخزين المؤقت (caching) للسياق المستخدم بشكل متكرر. في عمليات خدمة العملاء، لا يحتاج الوكيل دائمًا إلى حمل تاريخ العميل بالكامل في الموجه. يكفي ملخص ذي صلة بالحالة النشطة، بالإضافة إلى الوصول عند الطلب إذا كانت هناك حاجة لتفاصيل إضافية. ومع ذلك، فإن التلخيص والتخزين المؤقت يحملان أيضًا مخاطر. يمكن أن يفقد الملخص الفروق الدقيقة المهمة، ويمكن أن يصبح التخزين المؤقت قديمًا. هذه التقنية أكثر ملاءمة للمجالات ذات أنماط المعلومات المستقرة نسبيًا والمخاطر المنخفضة إلى المتوسطة.

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

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

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

زمن الاستجابة (Latency): الدقة وحدها لا تكفي

تركز العديد من الفرق كثيرًا على جودة الإجابة وتنسى أن الوكيل البطيء جدًا لن يُستخدم. في المؤسسة، يؤثر زمن الاستجابة على تبني المستخدم، واتفاقيات مستوى الخدمة (SLA) للعملية، وإنتاجية الفريق، وتصور الثقة في الوكيل. وكيل خدمة العملاء الدقيق جدًا ولكنه بطيء سيجعل الوكلاء البشريين يعودون إلى الطرق القديمة. وكيل المشتريات الذي يستغرق وقتًا طويلاً لتقديم توصية الاستقبال سيعتبر معيقًا للعملية.

أهم قرار في التصميم هو التمييز بين سير العمل المتزامن (synchronous) وغير المتزامن (asynchronous). الوضع المتزامن مناسب للتفاعلات التي تتطلب استجابة سريعة أمام المستخدم، مثل الأسئلة والأجوبة الداخلية، والتصنيف الأولي، والمسودات القصيرة، أو التوصيات البسيطة. لهذا الوضع، يجب أن يكون سير العمل خفيفًا: سياق محدود، والحد الأدنى من استدعاءات الأدوات، وتراجع (fallback) واضح إذا كانت العملية طويلة جدًا.

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

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

السعة (Capacity): لا تنتظر حتى يحدث الاختناق

بالإضافة إلى التكلفة وزمن الاستجابة، يجب أن يفكر التمويل التشغيلي للذكاء الاصطناعي العاملي (Agentic AI FinOps) أيضًا في السعة. السؤال ليس فقط كم تكلفة المعاملة، ولكن أيضًا ما إذا كانت بوابة النموذج (model gateway) قادرة على التعامل مع الارتفاعات المفاجئة في الحمل، وما إذا كانت واجهات برمجة التطبيقات (APIs) للأنظمة الأساسية قادرة على تحمل استدعاءات الأدوات الإضافية، وما إذا كانت طبقة مخزن المتجهات والاسترجاع لا تزال سريعة الاستجابة، وما إذا كان طابور الموافقة البشرية يصبح عنق زجاجة (bottleneck).

في إقفال نهاية الشهر المالي أو مواسم الذروة لعمليات خدمة العملاء، يمكن أن يرتفع الحجم بشكل كبير في أوقات معينة. إذا لم يتم التخطيط للسعة، ستشهد الشركة ارتفاعًا حادًا في زمن الاستجابة، وزيادة في حالات انتهاء المهلة (timeouts)، وزيادة في إعادة المحاولات، وارتفاعًا في التكاليف، وتدهورًا في تجربة المستخدم. يجب أن يغطي تخطيط السعة للأنظمة العاملة السلسلة بأكملها: استدلال النموذج، والاسترجاع، وطبقة التكامل، ومحرك سير العمل، وسعة الموافقة البشرية.

من المسؤول عن هذه الاقتصاديات؟

لن ينجح التمويل التشغيلي للذكاء الاصطناعي العاملي (Agentic AI FinOps) إذا تم اعتباره مجرد لوحة معلومات تقنية. يجب أن يكون لكل وكيل إنتاجي مالك تجاري (business owner)، ومالك تقني (technical owner)، وميزانية أو حد إنفاق (spending envelope)، وتنبيه بالتكلفة (cost alert)، وتحليلات استخدام (usage analytics)، وهدف نتيجة واضح. بدون مالك واضح، ستصبح التكاليف "تكلفة منصة مشتركة" لا يتم محاسبتها حقًا.

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

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

في النهاية، لا يتعلق التمويل التشغيلي للذكاء الاصطناعي العاملي (FinOps for agentic AI) بخفض التكاليف إلى أدنى حد ممكن. الهدف هو ضمان قدرة الشركة على توسيع نطاق الوكلاء دون الإضرار بالاقتصاديات، أو تجربة المستخدم، أو التحكم التشغيلي. في المؤسسة، هذا هو الشرط لكي يستمر التحول العاملي (agentic transformation) حقًا، وليس فقط أن يبدو مثيرًا للإعجاب في مرحلة النموذج التجريبي.