SYS// BRSTD-2026
UPLINK // AUTH_OK
LAT 24.86°N
LNG 67.00°E
ATELIER // v3.04
SIG ▮▮▮▮▮
PWR 98.4%
TEMP 36.6°C
FREQ 2400.0 MHz
PING 012 ms
PKTS 000000
RNG 000.0m
VEC 0.000,0.000
ID 0x000000
brainiac/studio

Digital Studio

brainiac/studiobrainiac/studio
ذكاء اصطناعي

إطلاق وكلاء ذكاءاصطناعي لا يُحرجونك

مارس 20267 دقائق readbrainiac/studio
الذكاء الاصطناعي وتعلّم الآلةتعمّق في الهندسةالنمو والتسويقأنظمة التصميماستراتيجية المنتجمشاريع Shopifyسرعة المواقعالظهور في جوجل والمحتوىمدير تقني عند الطلبأدوات المطورينتسليم سريعآراء صريحةالذكاء الاصطناعي وتعلّم الآلةتعمّق في الهندسةالنمو والتسويقأنظمة التصميماستراتيجية المنتجمشاريع Shopifyسرعة المواقعالظهور في جوجل والمحتوىمدير تقني عند الطلبأدوات المطورينتسليم سريعآراء صريحة

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

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

ثم تأتي الاختبارات (evals) قبل أي عمل على تجربة المستخدم. نكتب 100–300 حالة اختبار تغطي المسار السليم، والحالات الحدّية، والحالات التي يجب أن يعتذر فيها الوكيل بلباقة. ونمنحها درجات. ذلك الرقم يصبح المعيار — وكل تغيير بعده إما أن يرفعه أو نتراجع عنه. ومن دون هذا الأساس المرجعي، أنت تطلق منتجًا اعتمادًا على الانطباعات، وستشعر بالعواقب في الثانية صباحًا.

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

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

مشكلة الثقة هي الأصعب. نماذج اللغة فصيحة، وهي تُخرج الإجابات الخاطئة بالنبرة الواثقة نفسها التي تُخرج بها الصحيحة. والعلاج ليس أن تطلب من النموذج أن يقول «لست متأكدًا» — فهذا لا ينجح باطّراد. العلاج هو التأريض بالاسترجاع، وقياس درجة الثقة، وتضييق النطاق: ألّا يجيب الوكيل إلا في مجالات قِسْتَ دقته فيها ووجدتها مقبولة.

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

— الكاتب

بقلم فريق brainiac/studio. ننشر أعمالًا أصلية يكتبها المهندسون والمصممون والمسوّقون الذين ينفّذون العمل بأنفسهم — ولا نُسندها أبدًا إلى مصنع محتوى.

— قراءات إضافية

مقالات ذات صلة.

— جاهزون

Want this kind of work shipped in your product?

Tell us what you're building. We'll tell you how we'd help.