نموذج ذهني واضح لكيفية توليد الذكاء الاصطناعي للكود والقرارات في التطبيقات — التوكنات، النافذة السياقية، الأدوات، والاختبارات — بالإضافة إلى حدود ونصائح عملية للتوجيه.
عندما يقول الناس "الذكاء الاصطناعي يفكر" عادةً يقصدون شيئًا مثل: يفهم سؤالك، يستدل، ثم يقرر إجابة.
بالنسبة لنماذج اللغة الحديثة، نموذج ذهني أكثر فائدة أبسط: النموذج يتنبأ بما ينبغي أن يأتي من النص بعده.
قد يبدو ذلك مخيبًا للآمال—حتى ترى إلى أي مدى يمكن أن يصل "النص التالي". إذا تعلّم النموذج أنماطًا كافية أثناء التدريب، فإن توقع الكلمة التالية (ثم التالية) يمكن أن ينتج شروحات، خططًا، كودًا، ملخصات، وحتى بيانات منظمة يمكن لتطبيقك استخدامها.
لا تحتاج أن تتعلم الرياضيات الأساسية لبناء ميزات ذكاء اصطناعي جيدة. ما تحتاجه فعلاً هو طريقة عملية لتوقع السلوك:
هذه المقالة هي ذلك النوع من النماذج: ليست مبالغة، ليست ورقة تقنية عميقة—بل المفاهيم التي تساعدك تصمم تجارب منتج موثوقة.
من منظور مطور التطبيق، "تفكير" النموذج هو النص الذي ينتجه ردًا على المدخل الذي تقدمه (البروبت، رسائل المستخدم، قواعد النظام، وأي محتوى مسترجع). النموذج لا يتحقق من الحقائق بشكل افتراضي، ولا يتصفح الويب، ولا "يعرف" ما في قاعدة بياناتك ما لم تمرّره له.
ضع التوقعات حسب ذلك: نماذج اللغة مفيدة جدًا لصياغة النصوص، تحويلها، وتصنيفها، ولإنتاج مخرجات شبيهة بالكود. لكنها ليست محركات حقائق سحرية.
سنبني النموذج الذهني على بعض الأجزاء:
بهذه الأفكار، يمكنك تصميم بروبتات وواجهات وحواجز تجعل ميزات الذكاء الاصطناعي تبدو متسقة وجديرة بالثقة.
عندما يقول الناس أن الذكاء الاصطناعي "يفكر"، يسهل تخيل أنه يستدل مثل الإنسان. نموذج ذهني أكثر فائدة أبسط: إنه يكمل النص بسرعة فائقة—جزءًا صغيرًا في كل مرة.
التوكين هو قطعة من النص يعمل بها النموذج. أحيانًا تكون كلمة كاملة ("تفاحة"), أحيانًا جزءًا من كلمة ("تفا" + "حة"), أحيانًا ترقيمًا، وأحيانًا حتى مسافة. التقسيم الدقيق يعتمد على محلل التوكنات للنموذج، لكن الخلاصة: النموذج لا يعالج النص كجمل منظمة—بل كتوكنات.
حلقة النموذج الأساسية هي:
هذا كل شيء. كل فقرة، وكل قائمة نقطية، وكل سلسلة استدلال تراها مبنية على تكرار هذا التنبؤ بالتوكين.
لأن النموذج شهد كميات هائلة من النص أثناء التدريب، يتعلم أنماطًا مثل كيف تتدفق الشروحات عادةً، ما شكل البريد المهذب، أو كيف يُوصف تصحيح خطأ. عند سؤالك، يولّد إجابة "تناسب الأنماط" التي تعلّمها وتتوافق مع السياق الذي قدمته.
لهذا يمكن أن يبدو واثقًا ومتماسكًا حتى عندما يكون خاطئًا: فهو يهدف إلى ما ينبغي أن يأتي بعده في النص—لا إلى التحقق من الواقع.
الكود ليس شيئًا خاصًا للنموذج. JavaScript وSQL وJSON ورسائل الأخطاء كلها مجرد تسلسلات من التوكنات. يمكن للنموذج إنتاج كود مفيد لأنه تعلّم أنماط الترميز الشائعة، لا لأنه "يفهم" تطبيقك بنفس طريقة مهندس في فريقك.
عندما يسأل الناس "من أين حصل النموذج على تلك الإجابة؟"، النموذج الذهني الأكثر فائدة هو: تعلّم الأنماط من كم هائل من الأمثلة، والآن يعيد تركيبات تلك الأنماط لتنبؤ تسلسل نصي جديد.
أثناء التدريب، يُعرض النموذج على كثير من مقتطفات النص (كتب، مقالات، كود، توثيق، أسئلة وأجوبة، والمزيد). يمارس مهمة بسيطة مرارًا: بالنظر إلى نص، تنبؤ التوكين التالي. عندما يخطئ، تُعدّل معلمات النموذج بحيث يصبح أكثر احتمالًا لتنبؤ أفضل في المرة القادمة.
مع الوقت، تتراكم تلك التعديلات. يبدأ النموذج بترميز علاقات مثل:
لأنه يتعلم قوانين إحصائية—ليس نصًا محددًا واحدًا—يمكنه دمج الأنماط بطرق جديدة. إذا شاهد أمثلة كثيرة عن "شرح مفهوم" وأمثلة عن "سيناريو تطبيقك"، غالبًا ما يستطيع الدمج لتوليد استجابة مناسبة.
لهذا تستطيع نماذج اللغة كتابة بريد استقبال معقول لمنتج متخصص، أو تكييف شرح تكامل API عام إلى ستاك محدد. إنها لا تسترجع فقرة مخزنة واحدة؛ إنها تولّد تسلسلًا جديدًا يطابق الأنماط التي تعلّمتها.
حتى لو تضمن تدريب بعض البيانات حقيقة محددة (مثل خطة تسعير أو سياسة داخلية)، لا تفترض أن النموذج يستطيع "البحث" عنها بشكل موثوق لاحقًا. التدريب لا يعمل كفهرسة لقاعدة معرفة يمكنك الاستعلام منها لاحقًا. هو أقرب إلى ضغط: تُكثف أمثلة كثيرة في أوزان تؤثر على التنبؤات المستقبلية.
هذا يعني أن النموذج قد يبدو واثقًا حول تفاصيل يخمنها استنادًا إلى ما يظهر عادة في سياقات مشابهة.
التعلّم النمطي قوي لإنتاج نص سلس وذو صلة، لكن الطلاقة ليست نفس الشيء كما الحقيقة. قد:
الخلاصة للمطوِّرين: إجابات LLM عادةً تأتي من أنماط مكتسبة، لا من حقائق مُحققة. عندما تهم الدقة، أرض المخرجات ببياناتك وفحوصك الخاصة (سنغطي ذلك لاحقًا).
عندما يكتب النموذج ردًا، لا يستخرج "جملة صحيحة واحدة" من قاعدة بيانات. في كل خطوة، يتنبأ بمجموعة من التوكنات المحتملة، كلٌ له احتمال.\
لو كان النموذج يختار دائمًا التوكين الأكثر احتمالًا، لكانت الإجابات ثابتة جدًا—لكن مملة وأحيانًا متصلبة. معظم الأنظمة بدلًا من ذلك تأخذ عينات من التوزيع، ما يُدخِل عشوائية مُتحكَّمًا بها.
إعدادان شائعان يحددان مدى تنوّع المخرجات:
إذا كنت تبني تطبيقًا، هذه المقاييس ليست عن "الإبداع" فنيًا بقدر ما عن الاختيار بين:
لأن النموذج يعظّم النص المعقول، قد ينتج عبارات تبدو حازمة—حتى لو كان الادعاء الأساسي غير صحيح أو يفتقد سياقًا مهمًا. هذه هي سبب حاجة التطبيقات للتأريض (مثل الاسترجاع) أو خطوات التحقق للمهام الواقعية.
اطلب من LLM: "اكتب دالة JavaScript تزيل القيم المكررة من مصفوفة." قد تحصل على أيًا مما يلي، وكلها صالحة:
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicit
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
خيارات العيّنة المختلفة تؤدي لأنماط مختلفة (موجزة مقابل صريحة)، مقايضات مختلفة (سرعة، قراءة)، وحتى سلوكيات في حواف الحالات—كل ذلك من دون أن يغيّر النموذج "رأيه". إنه فقط يختار من بين عدة استمرارات عالية الاحتمال.
عندما يقول الناس أن النموذج "يتذكر" محادثتك، ما لديه فعليًا هو سياق: النص الذي يمكنه "رؤيته الآن"—رسالتك الأخيرة، تعليمات النظام، وأي جزء من المحادثة السابقة ما زال ضمن النافذة.
نافذة السياق حد ثابت لمقدار النص الذي يمكن للنموذج أخذه بعين الاعتبار مرة واحدة. عندما تصبح المحادثة طويلة، تسقط الأجزاء القديمة خارج تلك النافذة وتختفي عمليًا من منظور النموذج.
لهذا ترى سلوكًا مثل:
إذا استمريت في إضافة رسائل في سلسلة، فأنت تنافس على مساحة محدودة. القيود المهمة تُدفع خارج النافذة بواسطة التبادلات الأخيرة. بدون ملخص، يضطر النموذج لاستنتاج ما يهم مما بقي مرئيًا—لذا قد يبدو واثقًا بينما يفقد تفاصيل أساسية بهدوء.
إصلاح عملي هو تلخيص دوري: أعد صياغة الهدف، القرارات، والقيود في كتلة مختصرة، ثم تابع منها. في التطبيقات، يُنفَّذ هذا غالبًا كـ "ملخّص محادثة" يُحقن تلقائيًا في البروبت.
النماذج تميل إلى اتباع التعليمات التي تكون قريبة من الإخراج الذي على وشك توليده. لذا إذا كانت لديك قواعد يجب اتباعها (التنسيق، النبرة، حالات الحافة)، ضعها قرب نهاية البروبت—قبل "الآن قدّم الإجابة" مباشرة.
إذا كنت تبني تطبيقًا، عامل هذا كتصميم واجهة: قرر ما يجب أن يبقى في السياق (المتطلبات، تفضيلات المستخدم، السكيما) وتأكد من تضمينه دائمًا—إما بقَص تاريخ الدردشة أو بإضافة ملخص محكم. للمزيد عن تنظيم البروبتات، راجع /blog/prompting-as-interface-design.
نماذج اللغة ممتازة في إنتاج نص يبدو كما لو أنه صادر عن مطوّر كفء. لكن "يبدو صحيحًا" ليس مرادفًا لـ "صحيح". النموذج يتنبأ بالتوكن التالي، لا يراجع المخرجات مقابل كودك، تبعياتك، أو العالم الحقيقي.
إذا اقترح النموذج إصلاحًا أو إعادة هيكلة أو دالة جديدة، فهو لا يزال نصًا فقط. لا يشغّل تطبيقك، لا يستورد الحزم، لا يعيد استدعاء API، ولا ينسق المشروع ما لم تربطه بأداة يمكنها فعل ذلك (مثل مشغّل اختبارات، لينتر، أو خطوة بناء).
هذا هو التباين الرئيسي:
عندما يخطئ الذكاء الاصطناعي، غالبًا ما يفشل بطرق متوقعة:
قد تكون هذه الأخطاء صعبة الاكتشاف لأن الشرح المحيط عادةً ما يكون متماسكًا.
عامل مخرجات الذكاء الاصطناعي كمسودة سريعة من زميل لم يشغّل المشروع محليًا. يجب أن ترتفع الثقة بعد أن:
إذا فشلت الاختبارات، افترض أن إجابة النموذج مجرد نقطة بداية—ليست إصلاحًا نهائيًا.
نموذج اللغة ممتاز في اقتراح ما قد يعمل—لكن بمفرده يظل ينتج نصًا. الأدوات هي ما يسمح لتطبيق مدعوم بالذكاء الاصطناعي بتحويل تلك الاقتراحات إلى إجراءات مُحققة: تشغيل كود، استعلام قاعدة بيانات، جلب الوثائق، أو استدعاء API خارجي.
في سير عمل بناء التطبيقات، عادةً ما تبدو الأدوات كالتالي:
التحول المهم هو أن النموذج لم يعد يتظاهر بمعرفة النتيجة—يمكنه التحقق.
نموذج ذهني مفيد:
هذه هي الطريقة لتقليل "التخمين". إذا أعطى اللينتر تحذيرًا عن استيراد غير مستخدم، يعدّل النموذج الكود. إذا فشلت اختبارات الوحدة، يتكرر حتى تمر (أو يشرح لماذا لا يمكن).
eslint/ruff/prettier لتأكيد الاستايل والكشف عن القضايا.\الأدوات قوية—وقد تكون خطيرة. اتبع مبدأ الأقل امتيازًا:
الأدوات لا تجعل النموذج "أذكى"، لكنها تجعل ذكاء تطبيقك أكثر أرضية—لأنه يمكنه التحقق بدل السرد فقط.
نموذج اللغة رائع في الكتابة والتلخيص والاستدلال فوق النص الذي "يراه". لكنه لا يعرف تلقائيًا تغييرات منتجك الأخيرة، سياسات شركتك، أو تفاصيل حساب عميل محدد. RAG حل بسيط: اسحب أولًا الحقائق الأكثر صلة، ثم اطلب من النموذج الكتابة باستخدام تلك الحقائق.
فكر في RAG كـ "ذكاء اصطناعي بكتاب مفتوح". بدل أن تسأل النموذج أن يجيب من الذاكرة، يقوم تطبيقك أولًا بجلب مجموعة من المقاطع ذات الصلة من مخزن المحتوى الموثوق ثم يضيفها إلى البروبت. يجيب النموذج بعد ذلك مستندًا إلى المادة المقدمة.
RAG هو الافتراضي الجيد كلما كانت الدقة تعتمد على معلومات خارجة عن النموذج:
إذا كانت قيمة تطبيقك تعتمد على "الإجابة الصحيحة لعملنا"، فعادةً ما يكون RAG أفضل من الاعتماد على تخمين النموذج.
RAG جيدة بقدر جودة ما تسترجعه. إذا أعاد خطوة البحث مقاطع قديمة أو غير ذات صلة أو ناقصة، قد ينتج النموذج إجابة خاطئة بثقة—والآن "مؤسسة" على مصدر خاطئ. عمليًا، تحسين جودة الاسترجاع (التقسيم، الوسوم، الحداثة، الترتيب) غالبًا ما يحسّن الدقة أكثر من تعديل البروبت.
الوكيل هو مجرد LLM يعمل في حلقة: يضع خطة، يتخذ خطوة، ينظر لما حدث، ويقرر ما العمل بعد ذلك. بدل الإجابة مرة واحدة، يتكرر حتى يصل لهدف.
نموذج عقلي مفيد:
خطط → نفّذ → تحقق → عدّل
هذه الحلقة هي ما يحول طلبًا واحدًا إلى سير عمل صغير. ولهذا السبب تبدو الوكلاء أكثر "استقلالية" من الدردشة: النموذج لا ينتج نصًا فقط، بل يختار إجراءات ويسلسها.
الوكلاء يحتاجون قوانين واضحة لمتى يتوقفون. شروط الإيقاف الشائعة تشمل:
الضوابط هي القيود التي تُبقي الحلقة آمنة ومتوقعة: الأدوات المسموح بها، مصادر البيانات المصرح بها، خطوات موافقة بشرية، وصيغ إخراج محددة.
لأن الوكيل يمكن أن يقترح دائمًا "خطوة أخرى"، يجب أن تصمم لأوضاع الفشل. بدون ميزانيات، مهلات، وحدود خطوات، قد يدخل الوكيل في حلقة متكررة ("حاول مرة أخرى باستعلام مُعدّل") أو يتسبب بتكاليف متزايدة.
افتراضات عملية: حَدّ التكرارات، سجّل كل إجراء، اطلب تحققًا من نتائج الأدوات، وأعد الإجابة الجزئية مع ما حاول إنجازه عند الفشل. هذا أفضل غالبًا من السماح للوكيل بالتكرار إلى ما لا نهاية.
إذا كنت تبني بمنصة تطوير تفاعلية مثل Koder.ai، فإن نموذج "الوكيل + الأدوات" هذا عملي جدًا. لست فقط تدردش لأخذ اقتراحات—تستخدم سير عمل حيث المساعد يساعد في تخطيط الميزات، توليد مكونات React/Go/PostgreSQL أو Flutter، والتكرار مع نقاط تحقق (مثل لقطات واسترجاع) حتى تتحرك بسرعة دون فقدان السيطرة على التغييرات.
عادةً ما يعني ذلك أن النموذج قادر على إنتاج نص متماسك وموجه نحو الهدف يبدو وكأنه يفهم ويستدل. في الواقع، يقوم نموذج اللغة الكبيرة بتنبؤ الـ "توكين" التالي: يولد الاستمرار الأكثر احتمالًا بالنظر إلى الطلب (البروبت)، التعليمات النظامية، وأي سياق مقدم.
للمطوِّرين، الخلاصة المفيدة أن "التفكير" هو سلوك الإخراج الذي يمكنك تشكيله وتقييده—ليس ضمانًا داخليًا للحقيقة.
التوكين هو جزء من النص يعالج النموذج ويولده (كلمة كاملة، جزء من كلمة، علامة ترقيم، أو مسافة). لأن النماذج تعمل على توكنات، لا على "جمل" كاملة، فالتكاليف والقيود والاقتطاع تُقاس بتوكنات.
عمليًا:
لأن التوليد احتمالي. في كل خطوة يخصص النموذج احتمالات لعدة توكنات ممكنة، ومعظم الأنظمة تأخذ عينات من تلك التوزيعات بدلاً من اختيار أعلى خيار دائمًا.
لجعل المخرجات أكثر تكرارية:
نماذج اللغة تحسّن إنتاج نص معقول وليس التحقق من الحقائق. قد يبدو النموذج واثقًا لأن عبارات الواثق شائعة في بيانات التدريب، حتى عندما يكون الادعاء الأساسي تخمينًا.
في تصميم المنتج، اعتبر الطلاقة "كتابة جيدة" لا "صحة"، وأضف خطوات تحقق (استرجاع، أدوات، اختبارات، موافقات) عندما تكون الدقة مهمة.
نافذة السياق هي الحد الأقصى للنص الذي يمكن للنموذج أخذه بعين الاعتبار مرة واحدة (تعليمات النظام، تاريخ المحادثة، مقاطع مسترجعة، إلخ). عندما يصبح الخيط طويلاً جدًا، تتساقط المعلومات القديمة خارج النافذة ولا يمكن للنموذج رؤيتها.
تخفيفات:
ليس تلقائيًا. بشكل افتراضي، النموذج لا يتصفح الويب، ولا يقرأ قاعدة بياناتك، ولا ينفّذ كودًا. لديه الوصول فقط إلى ما تضمنه في البروبت وأي أدوات توصلها صراحة.
إذا كانت الإجابة تعتمد على حقائق داخلية أو محدثة، مرِّرها عبر الاسترجاع (RAG) أو عبر استدعاء أداة بدلاً من "الاستفسار بشكل أقوى".
استخدم الأدوات عندما تحتاج نتائج مُحققة أو إجراءات فعلية بدلًا من نص محتمل. أمثلة شائعة:
نمط جيد هو اقترح → تحقق → عدّل، حيث يتكرر النموذج اعتمادًا على مخرجات الأدوات.
RAG (التوليد المدعوم بالاسترجاع) هو "الذكاء الاصطناعي بكتاب مفتوح": يقوم تطبيقك باسترجاع مقاطع ذات صلة من مصادر موثوقة (مستندات، تذاكر، سياسات) ويُدرجها في البروبت حتى يجيب النموذج مستندًا إلى تلك الحقائق.
متى تستخدمه:
أكبر نقطة فشل هي جودة الاسترجاع—تحسين البحث، التقسيم، والحداثة غالبًا ما يفيد أكثر من تعديل البروبت.
الوكيل (agent) هو نموذج لغة يعمل في حلقة متعددة الخطوات: يخطط، ينفذ خطوة، يتحقق من النتيجة، ويعدّل الخطة. مفيد لعمليات مثل "ابحث عن معلومات → لصق مسودة → تحقق → أرسل".
للحيلولة دون التصرفات اللا منتهية:
عامل البروبتات كعقد واجهة: حدّد الهدف، المدخلات، القيود، وصيغة الإخراج حتى يستطيع تطبيقك استهلاك النتائج بثقة.
بُنّاؤُ الثقة العمليون: