كيفية تقييم وكالة تطوير AI: 12 سؤالًا تطرحها قبل التوقيع

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

إليك اثنا عشر سؤالًا يستحق طرحها قبل التوقيع على أي شيء، وما الذي يبدو عليه الجواب الجيد لكل واحد منها.

أسئلة حول البناء الفعلي

1. ماذا يفعل نظامكم عندما لا يكون واثقًا؟

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

2. كيف تتعاملون مع الحالات الاستثنائية، وليس فقط مع المسار المثالي؟

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

3. هل يمكنكم أن تروني نظامًا بنيتموه وما زال يعمل في الإنتاج بعد عام؟

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

4. ما عملية الاختبار لديكم قبل إطلاق أي شيء؟

الفريق الجاد يستطيع شرح كيفية التحقق من الدقة مقابل أمثلة حقيقية لا منتقاة بعناية، وكيفية اختبار الانحدارات عند تغيير نموذج أو prompt، وكيفية اكتشاف الأعطال قبل المستخدمين. عبارة عامة مثل «نختبر بشكل شامل» من دون تفاصيل تستحق المتابعة بالسؤال.

أسئلة حول الملكية والارتباط المقيد

5. من يملك الكود وprompts وخط أنابيب البيانات عندما ينتهي التعاون؟

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

6. ماذا يحدث إذا غيّر مزوّد النموذج الأساسي الأسعار، أو أوقف نموذجًا، أو تعرض لانقطاع؟

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

7. كيف تُوثَّق سلوكيات النظام للفريق الذي سيتسلمه؟

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

أسئلة حول التكلفة والنطاق

8. ما الذي لا يشمله هذا العرض، وما الذي يظهر عادةً كتغيير في النطاق؟

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

9. كيف تسعّرون تكاليف النموذج والبنية التحتية المستمرة، منفصلة عن أتعابكم؟

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

10. كيف يبدو الجدول الزمني الواقعي، بما في ذلك الأجزاء غير اللامعة؟

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

أسئلة حول المساءلة

11. ماذا يحدث عندما يخطئ النظام في الإنتاج؟

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

12. هل يمكنني التحدث إلى عميل يشبه مشروعه مشروعي من حيث النطاق؟

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

بعض الإشارات الأهدأ التي تستحق المراقبة

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

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

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

ما الذي تكشفه الإجابات، مجتمعة، فعلًا

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

كيف نجيب نحن عن هذه الأسئلة

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

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