Designing for Growing Intelligence | Levan Kvirkvelia at Agent Conf 2026

Watch on YouTube

Now Playing

Transcript

749 segments

0:23

شكراً للجميع. يسعدني

0:25

جداً أن أكون هنا،

0:26

وأشكر Callstack على هذه

0:28

الفرصة. سنتحدث اليوم

0:30

عن كيفية تصميم

0:32

الوكلاء (Agents) وحتى

0:33

المنتجات القائمة على

0:35

الذكاء المتنامي. اسمي

0:37

ليور، وأنا شريك مؤسس

0:38

في شركة Roar، ونحن

0:40

نبتكر تطبيقات جوال

0:41

باستخدام الذكاء

0:42

الاصطناعي. هناك في

0:44

الواقع آلاف

0:44

التطبيقات على متجر

0:46

التطبيقات App Store و Google

0:47

Play تم إنشاؤها عبر Roar،

0:49

وبعضها يحقق عشرات

0:50

الآلاف من الدولارات

0:51

شهرياً. هذه التطبيقات

0:53

يتم إنشاؤها بواسطة

0:54

مؤسسين منفردين،

0:55

وشركات صغيرة، وحتى

0:57

شركات كبيرة. أود أن

0:59

آخذكم في جولة عبر

1:01

رحلتنا. كيف بدأنا في

1:03

تصميم الوكلاء، وما هي

1:05

نقطة التحول عندما

1:07

بدأنا بالتشكيك في

1:09

جميع نهج التصميم

1:10

لدينا، وكيف نصممها

1:12

الآن. وفي النهاية،

1:15

سأشارك معكم ثلاث

1:16

قواعد تصميم يمكنكم

1:18

أخذها معكم لتحسين

1:20

منتجاتكم. أود فقط طرح

1:22

سؤال سريع هنا. من منكم

1:24

يعمل على منتجات تعتمد

1:26

على الذكاء الاصطناعي

1:27

(AI native)، أي بناء شيء

1:29

يمكن استضافته على

1:30

نطاق ينتهي بـ dot AI؟

1:32

فقط ارفعوا أيديكم.

1:34

حسناً، ليس الكثيرون،

1:36

لكنكم أنتم من سيحصل

1:37

على أكبر فائدة من هذا

1:39

الحديث، وإذا كان أي

1:41

شخص سيعمل على منتج

1:42

ذكاء اصطناعي قريباً،

1:44

وهو أمر سيحدث غالباً،

1:46

فسيمكنكم تطبيق هذه

1:47

القواعد. إذاً، لنعد

1:50

إلى البدايات. بدأنا

1:52

العمل منذ عامين

1:53

تقريباً عندما كان

1:54

نموذج "سونا 3.5" هو

1:56

النموذج الأحدث

1:57

والأفضل. وكان نموذج "

1:59

سونا 3.5" جيداً حقاً في

2:00

التعامل مع الويب. لقد

2:02

كان في الواقع أول

2:03

نموذج بدأ يحظى بتبنٍ

2:05

هائل في مجال الذكاء

2:06

الاصطناعي. مثل أندريه

2:08

كارباثي الذي كان يغرد

2:10

عن "كيرسر" مع "سونا 3.5"،

2:11

وكان الجميع يقولون: "

2:13

يا إلهي، هذا جنوني".

2:15

لكننا أردنا بناء

2:16

تطبيقات جوال. وكان "

2:18

سونا 3.5" في الحقيقة لا

2:20

يعمل بشكل جيد مع "

2:22

ريآكت نيتيف"، أما مع

2:24

Swift و Kotlin فكان لا يعمل

2:26

على الإطلاق. لذا

2:27

قررنا اعتماد "ريآكت

2:29

نيتيف"، وكان ذلك هو

2:30

الخيار الأفضل حينها.

2:32

كانت هناك الكثير

2:33

والكثير من المشاكل.

2:34

هذا التطبيق يحتوي على

2:35

ثلاثة ترويسات،

2:36

وعلامات تبويب معطلة.

2:38

وهذا التطبيق يحتوي

2:39

على تصميم معطل.

2:41

والسبب وراء قيامي

2:42

بالتقاط صور لهذه

2:43

التطبيقات هو أنها

2:44

كانت من بين أفضل

2:45

التطبيقات، ولهذا

2:46

السبب احتفظت بها في

2:47

معرض الصور الخاص بي.

2:48

وبالطبع، أردنا من

2:50

مستخدمينا بناء

2:51

تطبيقات حقيقية تصل

2:52

إلى متجر التطبيقات،

2:54

وليس مجرد نماذج أولية

2:56

. لذلك، بدأنا في بناء

2:57

طبقات وطبقات وطبقات

2:59

من الحواجز الوقائية (

3:00

Guardrails). لذا اخترنا React

3:02

Native كإطار عمل رئيسي

3:04

لنا لأنه يعتمد على

3:05

JavaScript، وكان Sonnet

3:06

بارعاً في JavaScript. ولكن

3:08

أيضاً، لحل كل تلك

3:09

المشاكل المتعلقة

3:10

بالعناوين وعلامات

3:11

التبويب، اضطررنا

3:12

لبناء أداة فحص برمجية

3:14

(Linter) خاصة بنا. ستقوم

3:15

تلك الأداة باكتشاف

3:16

الأخطاء الأكثر

3:17

شيوعاً التي يقع فيها

3:18

التطبيق عادةً، وتقدم

3:20

ملاحظات للذكاء

3:21

الاصطناعي. على سبيل

3:22

المثال، إحدى أكثر

3:23

المشكلات شيوعاً

3:24

والتي كانت غير صحيحة

3:26

تماماً هي قدرتهم على

3:27

إنشاء تطبيق بعلامة

3:28

تبويب واحدة فقط. هذا

3:29

الأمر لا يبدو منطقياً

3:31

. أنت لا تصنع تطبيقات

3:32

بعلامة تبويب واحدة

3:33

فقط. ما تفعله هو إما

3:34

إضافة علامة تبويب

3:36

أخرى ليصبح لديك

3:36

اثنتان، أو إزالة

3:37

علامات التبويب

3:38

تماماً. هذه هي

3:39

الطريقة الصحيحة

3:40

الوحيدة للقيام بذلك.

3:42

كان ذلك بخصوص أداة

3:44

الفحص، لكن كان هناك

3:45

نوع آخر من الأخطاء،

3:47

وهو أن إصدار 0.95 كان

3:49

يخترع أيقونات غير

3:51

موجودة. لذا، إرسال

3:52

رسالة العودة للذكاء

3:54

الاصطناعي مثل "هل

3:55

يمكنك استخدام أيقونة

3:56

أخرى؟" كان أمراً

3:57

سيئاً. وإذا لم نقم

3:59

بإصلاحه، سيتعطل

4:00

التطبيق ولن يعجب

4:01

المستخدمين. لذا، قمنا

4:02

بإنشاء عملية معالجة

4:04

لاحقة (post-processing).

4:05

ستقوم عملية المعالجة

4:06

اللاحقة هذه بالعثور

4:07

على جميع الأيقونات

4:08

المستخدمة في التطبيق.

4:09

وبعد ذلك، سنقوم

4:11

بإصلاحها تلقائياً.

4:12

سنأخذ الأيقونة التي

4:13

لا وجود لها. سنقول: "

4:15

حسناً، أراد الذكاء

4:16

الاصطناعي القيام

4:17

بهذا.""ما هي الفكرة

4:18

الأقرب لذلك؟" وسنقوم

4:20

باستبدالها. لن نستهلك

4:21

الكثير من الرموز (tokens)

4:23

. سيكون الأمر رخيصاً

4:25

جداً وسريعاً، وسيحبه

4:26

الناس. وبإجراء عملية

4:28

حسابية سريعة، إذا

4:29

هلوس الذكاء

4:30

الاصطناعي بأيقونة

4:31

واحدة في حالة واحدة

4:32

من كل 10 حالات،

4:33

فالتطبيق العادي

4:35

يحتوي على حوالي 10

4:36

أيقونات. لذا، الواجب

4:38

المنزلي هو حساب 0.9

4:39

مرفوعة للقوة 10. وهذا

4:41

يعادل حوالي 30%، مما

4:43

يعني أن 30%فقط من

4:44

التطبيقات لن تتعطل،

4:46

وهذا أمر مروع. لا أحد

4:48

يريد ذلك. والمثال

4:50

الأخير من "حواجز

4:51

الحماية" التي بنيناها

4:54

هو النوع الذي يضيف

4:55

قدرات جديدة. كان

4:57

الذكاء الاصطناعي في

4:59

ذروة انتشاره، ولا

5:00

يزال، وأراد الناس

5:01

بناء تطبيقات تمتلك

5:03

قدرات الذكاء

5:03

الاصطناعي، مثل تطبيق

5:05

تتبع السعرات

5:06

الحرارية حيث ألتقط

5:07

صورة للطعام ويقوم

5:08

بتتبع سعراتي. بالنسبة

5:10

لـ Sonic 3.5، فقد تم

5:11

تدريبه قبل وجود هذا

5:13

الذكاء الاصطناعي،

5:14

لذا لم يكن لديه أي

5:15

فكرة عن كيفية استخدام

5:17

تلك الميزات. لذا، كان

5:18

علينا إنشاء مجموعة

5:20

أدوات عمل الذكاء

5:21

الاصطناعي (AI toolkit)

5:22

التي كانت عبارة عن SDK

5:24

مبسط للغاية لإضافة

5:25

تلك الميزات. كان من

5:26

شأنه منع كل الأخطاء

5:28

العشرين الشائعة التي

5:29

يرتكبها الذكاء

5:30

الاصطناعي، مثل

5:31

الروابط الخاطئة،

5:33

وإصلاح البث، وما شابه

5:34

ذلك. لذا، فهذه ثلاثة

5:36

أو أربعة أنواع من

5:38

حواجز الحماية التي

5:39

بنيناها حوله. وقد نجح

5:41

الأمر نوعاً ما. لقد

5:43

نمونا بالفعل بفضل ذلك

5:45

، وكان الناس

5:45

يقارنوننا بمنتجات

5:47

أخرى ويجدون أن عملنا

5:48

يؤدي بشكل أفضل بشكل

5:50

عام. في بعض الأحيان

5:51

كانوا يغردون حول ذلك،

5:53

وتنتشر تلك التغريدات

5:54

بشكل واسع، وبسبب ذلك

5:55

الانتشار، كان مخطط "

5:57

سترايب" الخاص بنا

5:58

يلاحظ ذلك، وبالطبع

5:59

أحببنا ذلك. لكن كانت

6:00

هناك مجموعة من

6:01

الميزات الأخرى التي

6:03

لم نكن ندعمها. على

6:04

سبيل المثال، من

6:05

الواضح أننا لم نتمكن

6:06

من دعم لعبة ثلاثية

6:07

الأبعاد، أو الأنشطة

6:08

المباشرة، أو أدوات "

6:09

آي أو إس". بالنسبة

6:10

للكثير من تلك الميزات

6:11

، كنا نقول فقط: "لم

6:13

نبنِ ما يكفي من حواجز

6:14

الحماية". لذا، سنطرح

6:16

قريباً مجموعات تطوير

6:18

برمجيات مبسطة لدعم

6:19

تلك الحواجز، وستنجح

6:21

في عملها. لإنهاء

6:23

الحقبة الأولى من

6:25

تصميم الوكلاء أو

6:26

المنتجات، كان ذلك

6:28

يعني أننا قمنا فقط

6:29

بشحن حواجز حماية تمنع

6:31

الأخطاء الشائعة

6:32

وتخلق قدرات جديدة.

6:34

وقد نجح ذلك لبعض

6:36

الوقت. لذا، هذا نوع من

6:38

المخطط القائم على

6:39

الانطباعات. لقد بدأنا

6:42

بـ "سونيك 3.5". ومع كل

6:44

جيل جديد، كان نموذجنا

6:46

الخام مضافاً إليه بعض

6:47

حواجز الحماية يتفوق

6:49

على النموذج الخام

6:51

المجرد إذا استخدمته

6:52

في مكان آخر. لكن بعد

6:54

ذلك حدث تغيير كبير. تم

6:57

إصدار "أوبوس 4.5". وكان

6:59

ذلك أول نموذج جعل

7:00

الكثير من الناس

7:01

يشعرون بأن الذكاء

7:02

الاصطناعي العام قد

7:03

اقترب. لقد تسبب في

7:05

إثارة مخاوف حول سلامة

7:06

الذكاء الاصطناعي لدى

7:07

العديد من أصدقائنا.

7:08

وقد كان نموذجاً

7:09

رائعاً بحق. وبالنسبة

7:11

لنا، كان يعني أن هذا

7:12

هو أول نموذج جعل كل

7:14

حواجز الحماية الخاصة

7:15

بنا تقريباً بلا فائدة

7:16

. لم تعد تعني شيئاً

7:18

بعد الآن. كان

7:19

بإمكاننا ببساطة

7:20

إزالتها وسنكون بخير

7:22

تماماً. لكننا لاحظنا

7:24

شيئاً آخر كان جنونياً

7:26

تماماً. تعلم "أوبوس 4.5"

7:28

كيفية التعامل مع لغة "

7:30

سويفت". وهذا يعني أن

7:31

تلك الميزات التي لم

7:33

نعد ندعمها، أصبحت

7:34

مدعومة خارج نطاق

7:36

عملنا. أو إذا كنا ندعم

7:37

فقط، على سبيل المثال،

7:39

إضافة نماذج أو وحدات

7:40

برمجية أصلية في "

7:42

رياكت نيتيف" وغيرها.

7:43

لذا، الرسم البياني

7:45

الحقيقي الذي حدث مع "

7:46

أوبوس" و "أوبوس 4.4" هو

7:48

أن النموذج وحده كان

7:49

يتفوق على عملنا. وكان

7:51

ذلك أمراً مروعاً.

7:53

وهذا ما يسمى "الدرس

7:54

المرير"، وقد تعلمناه

7:55

بالطريقة الصعبة. من

7:57

منكم هنا يعرف ما هو "

7:58

الدرس المرير"؟ أو قرأ

8:00

المقال المتعلق به؟

8:01

واو. شخصان فقط. حسناً،

8:04

إذاً سيكون هذا مفيداً

8:05

للغاية. حسناً، أردت

8:07

أن أقدم الملخص بنفسي،

8:09

لكن جوجل قامت بذلك

8:11

بشكل أفضل مني. الدرس

8:12

المرير هو مقال كتبه

8:14

ريتشارد ساتون. هناك

8:15

ثلاث أفكار رئيسية.

8:17

الأولى، الطرق التي

8:18

تعتمد على حوسبة ضخمة

8:20

والتعلم، وهي نماذج

8:21

اللغة الكبيرة. إنها

8:22

تتفوق على المعرفة

8:24

اليدوية المبرمجة

8:25

بمرور الوقت. هذه هي

8:26

قيودنا الحامية. الدرس

8:28

الثاني هو أن إضافة

8:29

قواعد بشرية تساعد في

8:31

البداية وتبدو فكرة

8:32

ذكية. هذا ما حدث معنا.

8:34

لقد ساعد الأمر فعلياً

8:36

. لقد نمونا بشكل أسرع

8:37

من منافسينا. أحب

8:38

الناس ذلك. لكن هذا

8:40

يعيق النمو طويل الأمد

8:41

. وهذا أيضاً ما حدث

8:42

معنا. كُتب المقال في

8:44

عام 2019 تقريباً، وقد

8:46

تنبأ بكل ما حدث لنا

8:48

خلال السنوات الست

8:49

الماضية. والدرس

8:51

الأخير، لن يعجبك.

8:52

يكره الباحثون رؤية

8:54

تصاميمهم البشرية

8:55

الذكية تهزمها قوة

8:56

الحوسبة الخام.

8:57

وصدقوني، كانت هذه

8:58

الحقيقة صعبة التجرع

9:00

للغاية. لذا، عندما

9:02

لاحظنا كل ذلك، كان

9:03

هناك سؤال كبير. كيف

9:05

نصمم منتجنا ليكون

9:07

مبنياً على مبدأ "

9:08

الدرس المرير"؟ هذا

9:10

يعني أنه عندما يظهر

9:12

نموذج جديد أفضل بكثير

9:13

، مثلاً بعشرة أضعاف

9:15

مما لدينا الآن،

9:16

سيتحسن منتجنا ببساطة.

9:18

وسنكون قادرين على

9:20

استخراج كل المعرفة

9:21

المتاحة في النموذج

9:23

ودمجها في العمل. لذا،

9:26

إحدى الأفكار كانت

9:27

تعتمد كلياً على الحدس

9:29

. مثلاً، ماذا لو سعينا

9:31

لتقديم ميزات جديدة في

9:33

العمل بدلاً من مطاردة

9:34

الموثوقية؟ ماذا لو

9:36

توقفنا تماماً عن

9:37

مطاردة الموثوقية

9:38

وبدأنا العمل على

9:40

إزالة كل الحدود التي

9:41

تواجهنا؟ بالنسبة

9:43

لتطوير تطبيقات

9:44

الهاتف، هذا يعني أننا

9:46

بحاجة لدعم Swift، حيث

9:47

يمكنك إنشاء تطبيقات

9:49

تدعم الواقع المعزز،

9:50

والـ LiDAR، والألعاب

9:52

ثلاثية الأبعاد،

9:53

والأدوات المصغرة،

9:55

وكل ما تتخيله. يمكنك

9:56

ببساطة البناء

9:58

باستخدام Swift. وحتى لو

10:00

عملت باستخدام React Native

10:02

، فأنت تحتاج لما يسمى

10:04

بـ "جاك"(jack) للدخول إلى

10:06

طبقة Swift. لكن بالنسبة

10:08

للمنتج، هذا يعني أننا

10:10

بحاجة لإعادة صياغة

10:11

الأمر برمته. تعتبر React

10:13

Native رائعة لأنها تعتمد

10:15

على JavaScript، وعند العمل

10:17

في المتصفح، يمكنك

10:18

ببساطة عرض JavaScript

10:20

مباشرة هناك. هذا هو

10:22

مدى روعة React Native. لكن

10:24

بالنسبة لـ Swift، لا

10:25

يمكنك تشغيل تطبيق Swift

10:27

داخل المتصفح. لجعل

10:28

هذا يعمل، كان علينا

10:30

استخدام مجموعة من

10:32

أجهزة ماك تعمل في

10:33

السحابة، وتشغيل

10:35

محاكي iOS هناك، وبث

10:36

شاشة المحاكي مباشرة

10:38

إلى متصفح جميع

10:40

مستخدمينا. وكان علينا

10:41

القيام بذلك بزمن

10:42

انتقال منخفض للغاية

10:43

ليشعر المستخدم وكأنه

10:45

يعمل مباشرة داخل

10:46

متصفحه. وعندما تستخدم

10:47

الفأرة للنقر في مكان

10:49

ما، نرسل هذا الإجراء

10:50

مجددًا إلى المحاكي،

10:52

ونعرض لك ما حدث نتيجة

10:54

لذلك. وبالنسبة للوكيل

10:55

، كان هذا يعني أنه كان

10:57

يعمل سابقًا على لينكس

10:59

، لكن الآن يجب أن يعمل

11:00

على ماك، لأنه عند

11:02

بناء تطبيق، لا يمكنك

11:03

بناء تطبيق iOS على نظام

11:05

لينكس. الأمر ببساطة

11:06

لا يعمل بهذه الطريقة.

11:08

في React Native، الأمر يعمل

11:10

. لكنه لا يعمل في

11:11

تطوير تطبيقات iOS

11:13

باستخدام Swift. لذا، كان

11:15

ذلك رهانًا قائمًا على

11:16

الحدس، وفكرنا: "حسنًا

11:18

، ماذا لو لم نكن نعرف

11:19

الآن ما إذا كان الناس

11:21

سيحبون هذا النهج غير

11:22

المحدود الأقل

11:23

موثوقية؟ فمن الواضح

11:25

أن طرح العديد من

11:26

الميزات وجعل كل شيء

11:27

متاحًا، كما في Opus 4.5،

11:29

لم يكن ذكاءً

11:29

اصطناعيًا عامًا." كان

11:31

مجرد نموذج أفضل بكثير

11:32

. ماذا لو أعجبهم أو لم

11:34

يعجبهم؟ لم نكن نعرف.

11:35

لكن يا إلهي، لقد

11:37

أحبوه. أطلقنا Work Max

11:38

وحصلنا على 8 أو 9

11:39

ملايين مشاهدة. كان

11:40

الأمر واسع الانتشار

11:42

للغاية. كان تويتر

11:43

بأكمله يتحدث عن ذلك،

11:44

وضاعفنا إيراداتنا

11:45

السنوية المتكررة في

11:47

غضون أيام قليلة. كنا

11:48

نحقق مليون دولار

11:49

كإيرادات سنوية

11:50

متكررة كل يوم. كان

11:52

شعورًا لا يصدق تمامًا

11:53

. لكن من الناحية

11:55

التقنية، السبب في

11:56

كونه مذهلاً...حسنًا،

11:58

تلك الفيديوهات لا

12:00

تعمل. حسنًا، السبب في

12:02

كونه مذهلاً هو أن كل

12:04

ذلك كان لا يزال

12:05

مبنيًا على Opus. كان

12:07

الأمر محدودًا فقط في

12:08

العمل. لم نكن نسمح

12:10

للناس ببناء كل تلك

12:11

الأشياء. لذا، بنى

12:13

الناس أشياء مثل

12:14

بوكيمون جو، وصب واي

12:16

سيرفرز، وماينكرافت.

12:19

ولو لم ندعم كل ذلك،

12:21

لكنا وضعنا سقفًا

12:22

للقدرات ولن ينجح

12:24

الأمر. لذا، همم.

12:32

السؤال هو: كيف تستفيد

12:34

من هذه الدروس

12:35

المستفادة من إزالة

12:37

القيود وتصميم منتج

12:39

جاهز للذكاء المتنامي

12:41

؟ فهذا مجرد مثال واحد

12:44

، كيف تجد أشياء أخرى

12:47

في منتجك؟ حسنًا، هناك

12:49

ثلاث قواعد للتصميم.

12:50

أود أن أقول إنها تقع

12:52

في مكان ما بين الحدس

12:53

والواقع، لأنه من

12:54

الواضح أنه قد يظهر

12:56

نموذج جديد ويجعل كل

12:57

شيء قديمًا، ولكن هناك

12:59

ثلاث قواعد. أولاً،

13:00

توقف عن مطاردة

13:01

الموثوقية. انسَ ذلك

13:03

تمامًا. الموثوقية هي

13:05

الشيء الوحيد الذي

13:06

يأتي مجانًا بمجرد

13:07

انتظار النموذج

13:08

التالي. أعرف أن هناك

13:09

بعض الشركات الناشئة

13:11

في مجال الذكاء

13:12

الاصطناعي تبدأ

13:13

خطابها بـ "الذكاء

13:14

الاصطناعي سيء في كذا،

13:15

ولهذا نقوم بهذا". وهذا

13:17

لا يشبه تدريب نموذج

13:18

جديد. بل يبدو الأمر

13:19

كأنهم يقولون: "أوه،

13:20

نحن فقط نبني مجموعة

13:21

من الضوابط". هذه شركة

13:22

ناشئة فاشلة تمامًا،

13:24

يجب أن تتوقف عن فعل

13:25

ذلك، وعن القلق بشأن

13:26

الموثوقية لأنها

13:27

ستأتي مجانًا.

13:28

القاعدتان الأخريان

13:29

هما تحديد هدف كبير

13:30

ومنح الذكاء

13:31

الاصطناعي صلاحية

13:32

الوصول الكامل.

13:33

سنتناول ذلك الآن.

13:35

إذًا، تحديد هدف كبير.

13:37

بالنسبة لنا في Work،

13:39

كان سؤالاً بسيطًا. هل

13:41

يمكن للمستخدم بناء

13:42

تطبيق مثل أوبر في Work؟

13:44

يبدو الأمر مجنونًا.

13:45

لماذا قد يذهب شخص

13:46

أنهى دراسته للتو

13:48

لبناء تطبيق مثل أوبر؟

13:49

لكن إذا كنت تؤمن حقًا

13:51

بأن الذكاء الاصطناعي

13:52

سيكون متطورًا غدًا أو

13:54

الأسبوع المقبل، فهذا

13:55

أمر سيكون صعبًا، لا

13:56

أدري. سأقوم بذلك

13:58

بضغطة واحدة من خلال

13:59

الذكاء الاصطناعي. لذا

14:01

، اسأل نفسك هذا

14:02

السؤال وسترى على

14:03

الفور كل تلك الأماكن

14:05

التي لا يسمح فيها

14:07

منتجك أو وكيلك الذكي

14:08

بالاستفادة من كامل

14:10

ذكاء النموذج. ويمكن

14:13

تطبيق ذلك بسهولة على

14:14

أي منتج آخر يعتمد على

14:16

الذكاء الاصطناعي. على

14:17

سبيل المثال، إذا كنت

14:18

تبني محرر فيديو

14:19

بالذكاء الاصطناعي،

14:20

اسأل نفسك سؤالاً

14:22

بسيطًا. هل يمكن

14:23

لكريستوفر نولان أن

14:24

يأتي إلى منتجك ويبني

14:25

فيلمًا بجودة هوليوود

14:27

باستخدام منتجك؟

14:28

والسبب في استخدامي

14:29

لاسم كريستوفر نولان

14:31

هو أنه يمتلك قدرة

14:32

فائقة على فهم ما

14:33

يريده. لذا، هو لا

14:35

يحتاج حقًا إلى نموذجك

14:37

. هذا يزيل ذكاء

14:38

النموذج من المعادلة،

14:40

ويجب أن يظهر لك بسرعة

14:42

أين سينهار منتجك،

14:44

وتحتاج لإصلاح كل تلك

14:46

الأشياء. لإعطاء مثال

14:48

على كيفية تغيير ذلك

14:50

لتصميماتنا، بدأنا

14:51

بمشاريع React Native فقط

14:53

والآن نقوم بمشاريع

14:54

متعددة التطبيقات. في

14:56

أوبر هناك بالفعل

14:57

تطبيقان، أحدهما

14:59

للسائق والآخر

15:00

للمستخدم، بالإضافة

15:02

إلى تطبيق أندرويد

15:04

والويب. لذا، من

15:05

الواضح أننا بحاجة

15:06

لدعم كل ذلك، وقد

15:07

فعلنا ذلك وهو أمر

15:09

رائع. نقضي في الواقع

15:10

وقتًا أطول بكثير في

15:12

التفكير في الواجهة

15:13

الخلفية التي يجب أن

15:15

ندعمها لمستخدمينا،

15:16

فالسوق بأكمله حتى

15:18

يومنا هذا يستخدم إحدى

15:19

هذه الواجهات سهلة

15:21

الاستخدام، مثل Superbase

15:22

أو Convex أو Instant DB. تُعد

15:24

Convex أفضل في التعامل

15:25

مع البيانات اللحظية،

15:27

ولهذا السبب يفضلها

15:28

الناس أحيانًا. تعتبر

15:30

Superbase حلاً أكثر

15:31

اختباراً، ولكن عندما

15:33

تسأل نفسك سؤالاً: كيف

15:35

يمكن لمستخدمي بناء

15:37

تطبيق مثل Uber؟ لا أحد

15:38

سيبني تطبيق Uber

15:39

باستخدام Superbase.

15:41

الإجابة بسيطة، أنت

15:41

فقط تمنح الذكاء

15:42

الاصطناعي السحابة

15:43

بأكملها. وهذا بالضبط

15:44

ما فعلناه. لقد منحنا

15:46

مستخدمينا إمكانية

15:47

الوصول إلى مجموعة

15:48

فرعية من ميزات Cloudflare.

15:49

وبشكل مجاني تماماً،

15:51

تمكن مستخدمونا من

15:53

بناء بديل لخدمة Google

15:54

Meet للمكالمات. لقد

15:56

تمكنوا من بناء ألعاب

15:57

متعددة اللاعبين. لقد

15:58

تمكنوا من بناء أشياء

16:00

لم نكن لنتخيلها حتى.

16:01

لأن هذه هي الفكرة

16:03

الأساسية. أنت لا

16:04

تتخيل، بل تمنح حق

16:05

الوصول إلى أكثر

16:06

الأشياء جوهرية

16:07

لتحقيق الهدف الأكبر.

16:09

وستفاجأ في كل مرة

16:10

يظهر فيها نموذج جديد

16:12

أفضل. القاعدة الثالثة

16:14

هي منح الذكاء

16:15

الاصطناعي حق الوصول

16:16

إلى الجذور. بمعنى آخر

16:18

، السماح للذكاء

16:19

الاصطناعي بتجاوز

16:20

الطبقات الوسيطة التي

16:22

تبنيها باستمرار في

16:23

منتجك وأدواتك. وهي في

16:25

بعض الأحيان يصعب

16:26

العثور عليها. على

16:27

سبيل المثال، في

16:29

حالتنا كان الأمر

16:30

يتعلق بـ React Native،

16:31

فعندما قمنا ببناء هذه

16:33

الحزمة البرمجية (SDK)

16:35

المبسطة لاستخدام

16:36

ميزات الذكاء

16:37

الاصطناعي، كان الحل

16:39

الصحيح هو منح جميع

16:40

مستخدمينا وصولاً

16:41

مباشراً إلى Vercel AI Gateway

16:43

. وهذا أمر مهم للغاية

16:45

لأننا توقفنا عن دعم

16:46

أي شيء يحيط بالحزمة

16:47

البرمجية. لسنا بحاجة

16:49

لأن تركز الشركة

16:50

بأكملها على بناء

16:51

الحزمة البرمجية. إذا

16:52

ظهر نموذج جديد أو

16:54

ميزة جديدة، يتم دعمها

16:55

تلقائياً من قبلنا.

16:57

إذا ظهر نموذج جديد،

16:58

فإنه يصبح جاهزاً في

16:59

بيئة الإنتاج فوراً

17:01

لأننا نقوم فقط بتوجيه

17:02

كل شيء عبر Vercel Gateway.

17:03

الشيء الوحيد الذي

17:04

نقوم به هو تتبع

17:06

الاستخدام ومحاسبة

17:07

المستخدم. والشيء

17:08

الثالث، وهو الأكثر

17:10

شيوعاً فيما يتعلق

17:11

بالقيود الخفية، هو

17:13

عندما تبني سير عمل

17:14

وتمنحه للذكاء

17:16

الاصطناعي كأداة.

17:17

بالنسبة لنا، كان هذا

17:18

المثال هو النشر على

17:20

متجر التطبيقات (App Store)

17:21

. تبين أن النشر على

17:23

المتجر لم يكن مجرد

17:24

دالة برمجية واحدة

17:25

تستدعيها ليظهر

17:26

التطبيق في المتجر.

17:27

هناك الكثير من

17:28

الحالات الاستثنائية،

17:30

إنه أمر جنوني. أمم،

17:31

عندما تقوم بإطلاق

17:32

تطبيق ما، توجد عناصر

17:33

تحكم عائلية، وقوانين

17:34

الاتحاد الأوروبي،

17:36

وما إلى ذلك. لذا، ما

17:37

قمنا به هو تقسيم سير

17:38

العمل الذي كان لدينا

17:39

إلى خطوات، إلى

17:40

إجراءات موجودة

17:41

بالفعل في سير العمل،

17:42

ومنحنا الذكاء

17:43

الاصطناعي حق الوصول

17:45

إلى تلك الإجراءات.

17:46

الأشياء الجوهرية

17:47

التي نقوم بها في سير

17:48

العمل. وجعلنا الذكاء

17:50

الاصطناعي ينفذ سير

17:51

العمل من داخله. فأصبح

17:53

الذكاء الاصطناعي هو

17:54

من يقرر الترتيب، وما

17:56

هي الوظائف التي يجب

17:57

استدعاؤها. وتم

17:58

استبدال سير العمل

17:59

بالكامل بملف مهارات

18:01

مكتوب بلغة إنجليزية

18:03

بسيطة. ختاماً، أود أن

18:06

أقول إن القيام بذلك

18:08

سيكون صعباً للغاية،

18:10

لأن عقوداً من ثقافة

18:12

الهندسة علمتنا بناء

18:14

شيء يعمل اليوم. عندما

18:17

ترى مخرجات ذكائك

18:19

الاصطناعي وتجدها

18:20

سيئة، تفكر: "يجب أن

18:22

أبني كل هذه الطبقات

18:24

من الحماية لضمان

18:26

نتائج عالية الجودة

18:27

بأفضل ما يمكن حالياً".

18:29

لكن عليك التخلي عن

18:31

ذلك والقول: "لا بأس،

18:32

سيكون هناك نموذج أفضل

18:34

غداً، أو الأسبوع

18:36

القادم، أو الشهر

18:37

القادم، وسأستبدله

18:38

بنموذج أفضل، وسيتحسن

18:40

ذاتياً". وهكذا يجب أن

18:42

تصمم منتجاتك. والذكاء

18:44

الاصطناعي العام أصبح

18:45

قريباً. وإذا لم تقم

18:47

بإعداد منتجك للذكاء

18:48

الاصطناعي العام، فلن

18:49

تستطيع تغيير

18:50

المستقبل. وعليك بناء

18:52

المنتجات من أجل تغيير

18:54

المستقبل. أجل. شكراً

18:56

جزيلاً لكم.

19:22

>> ممم.

Interactive Summary

Ask follow-up questions or revisit key timestamps.

يتناول الفيديو رحلة شركة Roar في بناء تطبيقات جوال تعتمد على الذكاء الاصطناعي. يناقش المتحدث كيف بدأوا بوضع الكثير من "حواجز الحماية" (Guardrails) حول النماذج الذكية لضمان جودة التطبيقات، وكيف اكتشفوا لاحقاً أن هذا النهج يعيق النمو على المدى الطويل وفقاً لمبدأ "الدرس المرير" (The Bitter Lesson). يقدم المتحدث ثلاث قواعد أساسية لتصميم منتجات الذكاء الاصطناعي المستقبلية: التوقف عن مطاردة الموثوقية اليدوية، تحديد أهداف كبيرة تمنح النموذج حرية الوصول الكامل، ومنح الذكاء الاصطناعي صلاحية التعامل مع الجذور مباشرةً بدلًا من الاعتماد على طبقات وسيطة.