Prompt Engineering بالأرقام: ما الذي يغيّر المخرجات

قبل القياسات، هناك حقيقة واحدة تفسر بهدوء نصف ما يلي.

النموذج لا يملك ذاكرة. بين نداءين لا يحتفظ بأي شيء — لا بسؤالك الأخير، ولا بإجابته الأخيرة، ولا بالملف الذي أرفقته، ولا بحقيقة أنك سألته مرتين بالفعل. يبدأ كل نداء من آلة فارغة، والشيء الوحيد الذي تعرفه تلك الآلة هو تسلسل الـ tokens الذي سلّمته لها للتو.

ما يبدو ذاكرة في واجهة محادثة هو أن عميلك يعيد إرسال المحادثة كاملة، كل دور، من البداية. يقرأ النموذج كل ذلك من الصفر مرة أخرى، في كل مرة. قاس الفصل 13 تكلفة إعادة القراءة تلك في forward pass؛ ويحولها الفصل 16 إلى سطر على فاتورة. ما يهم هنا هو نتيجة التصميم: الـ prompt ليس رسالة إلى نظام لديه حالة. إنه الحالة.

هذا ينهي عائلة من الالتباسات. «نسي النموذج ما قلته له» تعني عادةً أن ذلك لم يُرسَل إليه أصلًا. «تجاهل تعليمتي السابقة» تعني عادةً أن التعليمة خرجت من النافذة عندما قُصَّ التاريخ. «تصرف بشكل مختلف في الإنتاج» تعني عادةً أن الإنتاج يجمّع prompt مختلفًا عن الذي اختبرته. لا شيء من هذا مشكلة نموذج، ولا يُصلَح أي منه بإعادة صياغة شيء.

القول إن «هذا prompt أفضل» هو قول عن توزيع، ولا يمكنك رؤية توزيع بالنظر إلى مخرج واحد. ما تحتاجه ممل: حالات ذات إجابات معروفة، وN من التنويعات، وفاصل.

الـ harness خمسون سطرًا من TypeScript بالشكل نفسه مثل العميل في الفصل 14 — طلب، وموعد نهائي، وبعض التوازي، وعدّاد. يظهر مجددًا في الفصل 19 لتقييم مسترجِع، وفي الفصل 29 بوصفه المجموعة الذهبية.

export type Case = { input: string; expected: string };
export type Variant = { name: string; build: (c: Case) => ChatMessage[] };

async function pooled<T, R>(xs: T[], n: number, f: (x: T) => Promise<R>) {
  const out: R[] = new Array(xs.length);
  let i = 0;
  await Promise.all(
    Array.from({ length: n }, async () => {
      while (i < xs.length) {
        const k = i++;
        out[k] = await f(xs[k]);
      }
    }),
  );
  return out;
}

export async function runVariant(v: Variant, cases: Case[], concurrency = 6) {
  const hits = await pooled(cases, concurrency, async (c) => {
    const answer = await complete(v.build(c));      
    return answer.trim().toLowerCase() === c.expected;
  });
  return { name: v.name, hits, k: hits.filter(Boolean).length, n: cases.length };
}

الرقم الذي يعود ليس النتيجة. هذه هي:

/** 95 % Wilson score interval for a proportion. Chapter 4 derives it. */
export function wilson(k: number, n: number, z = 1.96) {
  const p = k / n;
  const d = 1 + (z * z) / n;
  const centre = (p + (z * z) / (2 * n)) / d;
  const half = (z * Math.sqrt((p * (1 - p)) / n + (z * z) / (4 * n * n))) / d;
  return [Math.max(0, centre - half), Math.min(1, centre + half)] as const;
}

قدّم الفصل 4 الحجة، وهذا الفصل يصرفها. سبعة عشر صحيحًا من عشرين تساوي 85 %، ويمتد فاصلها عند 95 % من 64 % إلى 95 %. تنويعة تسجل 13 من 20 — أي 65 %، وهو ما يبدو أسوأ بوضوح — لها فاصل من 43 % إلى 82 %. هذان الفاصلان يتداخلان على معظم طولهما تقريبًا. عشرون حالة لا تستطيع تمييز prompt جيد من آخر متوسط، ومعظم نصائح prompt المنشورة صُدِّقت على أقل من ذلك.

ستون حالة، وهو ما يستخدمه هذا الفصل، لا تزال ليست كثيرة. لكنها تكفي لرؤية التأثيرات الكبيرة، وصادقة بما يكفي لتعترف عندما لا تستطيع رؤية التأثيرات الصغيرة — وستعترف بذلك عدة مرات أدناه.

ثلاث كتل — القواعد R، والتذكرة T، والتعليمة I — جُمعت في رسالة مستخدم واحدة. كل التبديلات الستة، بمحتوى مطابق على مستوى البايت، وستون حالة لكل منها.

من الأفضل إلى الأسوأ 28.3 نقطة، والفواصل لا تتداخل، لذا فهذه ليست قصة عن الضوضاء. وبما أن كل ذراع يُقيَّم على العناصر الستين نفسها، فالسؤال الأدق هو السؤال المقترن: في الحالات التي يختلف فيها ذراعان، إلى أي حد يميل الانقسام؟ الانتقال من أسوأ ترتيب إلى أفضل ترتيب قلب 21 حالة إلى صحيحة و4 إلى خاطئة — احتمال مقترن دقيق 0.0009.³

اقرأ الجدول لشكلِه لا لفائزه. الصفان الأفضل كلاهما ينتهيان بالتذكرة؛ والصفان الأسوأ كلاهما يدفنان التعليمة في الوسط أو يتركانها بعد البيانات. إنها الظاهرة نفسها التي سمّاها Liu وآخرون Lost in the Middle: المادة عند حواف prompt تُستخدم باعتمادية أكبر من المادة في الوسط.⁴ يسعّر الفصل 16 النافذة، ويقيس الفصل 24 التأثير كما ينبغي عند الطول، حيث ينهار الوسط كما وُصف ولا تظهر عودة التحسن في النهاية تمامًا. هنا تخرج القاعدة العملية وحدها: المهمة في الأعلى، البيانات في الأسفل، ولا شيء مهم في الوسط.

الآن انقل الكلمات نفسها بين الأدوار. أثبت الفصل 11 أن chat template ليس زخرفة حول النموذج بل جزء منه — <|im_start|>system و<|im_start|>user هما tokens حقيقية رآها النموذج ملايين المرات أثناء fine-tuning، في تلك المواضع تحديدًا. لذلك ينبغي أن يهم أي جانب من تلك العلامات تهبط عليه تعليماتك، وهذا يحدث فعلًا:

نقل القواعد والتعليمة عبر حدّ القالب منح 21.7 نقطة — 19 حالة كسبت، و6 خسرت، واحتمال مقترن 0.0146 — من دون تغيير حرف واحد منها. هذه هي الإجابة الملموسة عن system prompt مقابل user prompt: إنهما ليسا طريقتين لقول الشيء نفسه. إنهما موضعان مختلفان للـ tokens في بنية تدرّب عليها النموذج، وموضع النظام هو حيث تنتمي التعليمات التي تنطبق على المحادثة كلها.

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

الـ prompt نفسه، بأفضل موضع، وستون حالة. الشيء الوحيد الذي يتغير هو ما يحيط بنص التذكرة.

انتشار بثماني عشرة نقطة من علامات ترقيم. لكن انظر إلى الفاصلين المتطرفين: [73.9, 91.9] و[54.1, 77.3]. إنهما يتداخلان. بالقراءة الخام — قارن أشرطة الخطأ، وإذا لامست بعضها فلا تقل شيئًا — لا يثبت هذا الجدول أي شيء.

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

ثم الاختبار نفسه يفرّغ العنوان من الهواء. تغلب وسم XML على تسمية Ticket: العادية بـ8.3 نقاط، وهو الرقم الذي كان منشور مدونة سيضعه في عنوانه. مقترنًا: 6 مكاسب، 1 خسارة، احتمال 0.1250. غير مثبت. سبع حالات فقط هي ما يستند إليه ذلك التحسن الشهير.

إذًا هناك سؤالان بأداتين مختلفتين، وخلطهما هو ما يجعل نصائح prompt تخطئ في الاتجاهين معًا:

النتيجة العامة — أن النماذج حساسة بقوة وبصورة غير قابلة للتنبؤ لاختيارات تنسيق لا تحمل أي محتوى دلالي — ليست جديدة. غيّر Sclar وآخرون الفواصل والمسافات وحالة الأحرف فقط عبر عشرات المهام، ووجدوا انتشارات في الدقة واسعة بما يكفي لعكس ترتيبات النماذج المنشورة.⁵ النتيجة العملية ليست «استخدم وسوم XML». إنها أن التنسيق hyperparameter، وأن مسحه لا يكلف شيئًا، وأن أي مقارنة بين نموذجين تثبّت تنسيقًا واحدًا تقارن التنسيقات بقدر ما تقارن النماذج.

In-context learning — إظهار أمثلة محلولة للنموذج داخل prompt وجعله يعمم منها من دون أي تحديث للأوزان — هي القدرة التي جعلت GPT-3 مشهورًا.⁶ السؤال العملي ليس أبدًا هل تعمل. بل كم مثالًا يستحق أن تدفع ثمنه.

تدخل الأمثلة كأدوار سابقة حقيقية، بالتناوب بين المستخدم والمساعد، لأن هذه هي البنية التي تدرّب عليها القالب. شُغّل كل k مع خمس سحوبات عشوائية مختلفة من مجموعة منفصلة من ست عشرة تذكرة موسومة:

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

العمود الأهم هو الأخير. عند k = 8، أي ثمانية أمثلة صادف أنك اخترتها حرّكت الدقة 10 نقاط — أكبر من كامل المكسب من الانتقال من مثالين إلى ثمانية. والصف الأخير هو النسخة الأوضح: عند k = 16 تكون المجموعة قد نُفدت، لذلك تحتوي التشغيلات الخمس كلها على الأمثلة الستة عشر نفسها تمامًا، ولا تختلف إلا في ترتيب ظهورها. الترتيب وحده حرّك الدقة 8.3 نقاط.

هذه هي النتيجة التي أبلغ عنها Lu وآخرون، وهي تصمد أينما بُحث عنها: ترتيب الأمثلة hyperparameter حقيقي بتأثيرات تقارن بعدد الأمثلة.⁷ لذلك فالنصيحة الصادقة عن few-shot prompting ليست رقمًا. إنها:

والآن الفولكلور. كل واحدة من هذه جملة واحدة تسبق system prompt مطابقًا فيما عدا ذلك، على الحالات الستين نفسها.

أربع من الخمس لم تفعل شيئًا. ليس «فعلت قليلًا»؛ بل لا شيء تستطيع ستون حالة مقترنة رؤيته. persona الخبير والرشوة سجلا كلاهما أقل من baseline غير الممسوس، وحتى هذان الانخفاضان يفشلان في الاختبار المقترن — إنها ضوضاء تشير إلى الأسفل.

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

ثم التهديد، وهو الجملة الوحيدة التي حرّكت المؤشر وحرّكته 35 نقطة إلى الأسفل، فقلبت 24 حالة من صحيحة إلى خاطئة. ليس هذا أثر تقريب؛ إنه سلوك نموذج مختلف. الدرس ليس «لا تهدد نموذجًا أبدًا». بل إن التأطير العاطفي ليس خاملًا. إنه يزيح التوزيع، أحيانًا بقوة، في اتجاه لا يستطيع أحد التنبؤ به من قراءة الجملة — وهذا تحديدًا سبب وجوب قياسه لا الاستدلال عليه.

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

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

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

الآلية ليست غامضة عندما تتذكر الفصل 8. يختار النموذج next token من توزيع مشروط بكل ما قبله، والنهي يضع الشيء الممنوع داخل ذلك الشرط. لا يوجد عامل للنفي؛ يوجد سياق تظهر فيه كلمة الآن.

وهذا يمكن قياسه مباشرة. خذ baseline prompt وأضف سطرًا واحدًا: Do not use the shipping queue for software problems. ثم انظر فقط إلى التذاكر الخمس والأربعين التي ليست تذاكر شحن:

تسمية قائمة انتظار بهدف استبعادها جعلت النموذج يختارها ثلاث مرات أكثر، وكادت تضاعف كتلة الاحتمال التي أسندها إليها ثلاث مرات، وكلّفت 25 نقطة من الدقة الإجمالية — 16 حالة خاسرة مقابل 1 كاسبة، واحتمال مقترن 0.0003.

لا تفكر في فيل، لكن مقاسًا. إعادة الكتابة واحدة دائمًا: استبدل النهي بالقاعدة الإيجابية التي تجعله غير ضروري. ليس «لا تستخدم الشحن لمشاكل البرمجيات» بل «استخدم الشحن فقط عندما تكون هناك طرد مادي معني».

بنى الفصل 12 chain of thought كما ينبغي — كتقنية prompting أولًا،⁹¹⁰ ثم كشيء دُرّب عليه بمكافآت قابلة للتحقق — وانتهى بتحذير أجّله إلى هذا الفصل: إخبار نموذج بأن يفكر خطوة بخطوة يتوقف عن المساعدة عندما يكون النموذج يستدل من تلقاء نفسه، وقد يضر. إليك ذلك التحذير وتحته جدول، في مهمة يسهل افتراض أن المزيد من التفكير فيها لا بد أن يكون أفضل.

يُقرأ الذراعان بالأداة نفسها وفي الموضع نفسه. الفارق الوحيد هو ما إذا كانت chain of thought كتبها النموذج نفسه موجودة أولًا في السياق.

انخفضت الدقة وارتفعت التكلفة، وتنطبق قاعدة هذا الفصل نفسها على نتيجة هذا الفصل نفسها: الانخفاض هو 7 حالات كاسبة مقابل 10 خاسرة، واحتمال مقترن 0.629، أي غير مثبت. ما ثبت هو أنه أنتج ثمانية وتسعين output tokens إضافية لكل نداء ولم يشترِ بها شيئًا قابلًا للقياس. عدم اليقين كله في جانب الفائدة. الفاتورة مؤكدة.

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

1. Check if the issue persists on Monday.
2. Verify if there are any updates or changes in your Slack setup that
   might affect message posting.
3. If no update has been made since Tuesday, check for any recent system
   restarts or downtime affecting Slack functionality.
4. If you have recently installed new software or updated your
   environment, ensure it's compatible with Slack version.
5. Contact Slack support for further assistance or troubleshooting steps.

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

نتيجتان عمليتان. أولًا، بالنسبة إلى نموذج دُرّب على الاستدلال — نماذج RLVR في الفصل 12 — تكون التعليمة أسوأ من الزائدة: يمكنها أن تستبدل السلسلة الطويلة التي كان النموذج سينتجها بسلسلة قصيرة على شكل prompt. وأخذ عينات من عدة سلاسل والتصويت، وهو ما تفعله self-consistency،¹¹ لا يستطيع إنقاذ مهمة لا يوجد فيها شيء يُختلف عليه: إنه يضاعف التكلفة بعدد العينات لكسر تعادلات غير موجودة. قاس الفصل 12 تلك المفاضلة حيث تنطبق. ثانيًا، لاحظ تكلفة هيكل المقارنة نفسه. فرض الإجابة في سطر Final queue: أنزل ذراع عدم الاستدلال من 76.7 % إلى 61.7 %. خمس عشرة نقطة دُفعت لجعل الذراعين قابلين للمقارنة. البنية الموجودة لراحتك ليست مجانية أيضًا.

قياس أخير، لأنه السؤال الذي يطرحه الجميع بعد أول نتيجة مفاجئة. ستون prompt، وgreedy decoding، تُشغَّل مرارًا:

• النداء نفسه عند تكراره مع تثبيت كل شيء أعاد احتمالات مطابقة على مستوى البت. حتمي.
• النداء نفسه مجمعًا مع جيران مختلفين — أحجام دفعات 1 و4 و12 و30 و60 — أعاد احتمالات تختلف حتى 0.0128. لم يتغير الوسم المختار أبدًا، في 0 من 60 حالة.

صمد الوسم لأن لديه هامشًا: عبر الحالات الستين كان أضيق فرق بين أعلى قائمتَي انتظار 0.0459، أي ثلاثة أضعاف ونصف الانجراف. لم يكن الاستقرار خاصية للخوارزمية. كان هامشًا، والهوامش تنفد. الفصل 17 هو حيث يعيش السبب الحسابي، وحيث تُفكك مقابض العيّنة التي توسع تلك الفجوات وتضيقها. سبب زرعه هنا هو أنه يحدّد ما يمكن أن يعنيه أي قياس prompt: تقيس منصة القياس نظامًا لا يُعاد إنتاجه إلا ضمن سماحية، وفرق نقطتين بين تنويعات يقع داخل تلك السماحية في يوم سيئ.

كل ما سبق هو إنسان يختار تنويعة وآلة تصححها. الخطوة التالية البديهية هي ترك الآلة تختار التنويعات أيضًا.

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

DSPy يذهب أبعد، وهو الفكرة الأكثر فائدة للمنتج.¹² تصرّح بما تأخذه كل خطوة في pipeline وما تعيده، ويجمع الإطار ذلك في prompts، منتقيًا demonstrations ومحسنًا التعليمات مقابل مقياسك. غيّر النموذج فتُعيد التجميع بدل إعادة الكتابة. يتوقف الـ prompt عن كونه source code يضبطه شخص يدويًا، ويصبح artefact مولّدًا مقابل مقياس، وهذا ما كان ينبغي أن يكون عليه منذ البداية.

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

يبقى الانضباط. تنتمي prompts إلى version control، في ملفات، بجانب الكود الذي يرسلها — لا في صف قاعدة بيانات عدّله شخص يوم الثلاثاء. تحتاج إلى معرّف نسخة مخزن بجانب كل مخرج أنتجته، وإلا في اليوم الذي يتراجع فيه شيء لن تستطيع معرفة ما تغيّر. تحتاج إلى منصة القياس في continuous integration، لأن prompt هو الجزء الوحيد من نظامك الذي يستطيع بائع إبطاله بصمت بإطلاق نموذج جديد. وتحتاج إلى حالات: لا مئة حالة ذكية، بل العشرون المملة التي انكسرت في الربع الماضي، محفوظة إلى الأبد. منصة القياس هي deliverable. الـ prompt ناتج جانبي لها.

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

الـ system prompt الذي اشترى 21.7 نقطة يُرسَل في كل نداء، إلى الأبد. المثالان اللذان اشتريا سبع نقاط يُرسلان في كل نداء، إلى الأبد. الستة عشر التي اشترت اثنتي عشرة نقطة تُرسل في كل نداء، إلى الأبد، وهي تقريبًا عشرة أضعاف طول السؤال الذي طرحه المستخدم فعلًا. chain of thought التي لم تشترِ شيئًا أنتجت ثمانية وتسعين token إضافيًا لكل طلب، وoutput tokens هي النوع المكلف.

لا يظهر شيء من ذلك في جدول دقة، وكلّه يظهر على فاتورة.

الفصل 16 عن الوحدة التي تُقوَّم بها هذه القرارات فعلًا. الـ token كوحدة فوترة، والـ context window كميزانية لا كذاكرة، ولماذا تكلف محادثة من أربعين دورًا أكثر بكثير من أربعين ضعف الدور الأول، وما الذي يدفع عنه prompt caching وما الذي لا يدفع عنه، ولماذا يقرر ترتيب prompt هل تصيب cache أصلًا — وهو ما يتضح أنه سبب اقتصادي ثانٍ تمامًا لوضع المادة الثابتة أولًا والمادة المتغيرة أخيرًا.

أُنتجت منصة القياس وكل جدول باستخدام Qwen/Qwen2.5-0.5B-Instruct تحت greedy decoding، لذلك تُعاد إنتاجها بالضبط. توثيق Hugging Face حول chat templates هو المرجع لما تتوسع إليه علامات القالب في الفصل 11 فعلًا، ولحقيقة أن شحن نموذج بالقالب الخطأ إخفاق حقيقي ومتكرر. أما تأثيرات الموضع والتنسيق على نطاق الإنتاج لا المختبر، فالمراجع أعلاه هي المصادر الأساسية؛ وأدلة prompting لدى البائعين مفيدة لأمثلتها وينبغي قراءتها مع العلم بأن أيًا منها لا ينشر فاصلًا.