المكاسب:
- يمكن تصميم البنية الشاملة التي تنقل ميزة LLM من الفكرة إلى الإنتاج
- إنشاء طبقات من إنفاذ التحقق والموافقة البشرية والتتبع (التسجيل/المقاييس)
- تترجم الحدود مبادئ الأخلاق والخصوصية إلى قرارات الإنتاج
في الوحدات العشر السابقة، تعلمنا الأجزاء واحدًا تلو الآخر: هيكل الطلب، واقتصاديات الرمز المميز، والتدفق، وموجه النظام، واختيار النموذج، وذاكرة التخزين المؤقت، والدُفعة، وإدارة الأخطاء، والمفتاح الآمن، والأتمتة. في هذه الوحدة الأخيرة، نقوم بدمج الأجزاء وإنشاء البنية الشاملة التي تحمل ميزة LLM من الفكرة إلى الإنتاج. يختلف الإنتاج عن "العرض العملي": فالتحقق إلزامي، ويجب مراقبة المخرجات، ويجب تضمين الحدود والمبادئ الأخلاقية في القرارات. هذه الوحدة هي العمود الناقل للوحدة؛ كل ما سبق يجتمع هنا.
طبقات هندسة الإنتاج
يتكون مؤهل LLM القوي من خمس طبقات تقريبًا:
- طبقة الإدخال: جمع البيانات، وتنظيفها، وإخفاء المناطق الحساسة، ونقل ما هو ضروري فقط.
- طبقة النموذج: حدد النموذج الصحيح (الوحدة 5)، وقم بتعيين موجه النظام والمعلمات (الوحدة 4)، وذاكرة التخزين المؤقت (الوحدة 6).
- طبقة التحقق من الصحة: تحقق من المخرجات مقابل المخطط/القاعدة والمصدر والموافقة البشرية إذا لزم الأمر.
- طبقة الإجراء: تنفيذ الإجراء بمخرجات تم التحقق من صحتها؛ التقاط إجراءات عالية التأثير.
- طبقة المراقبة: تسجيل وقياس كل مكالمة وتكلفة وخطأ وجودة.
هذه الطبقات عبارة عن خط أنابيب. كل واحد يتحقق من إخراج السابق.
لماذا التحقق مطلوب؟
يمكن أن تنتج LLM مخرجات بطلاقة ولكنها غير دقيقة في بعض الأحيان. وهذا ما يسمى الهلوسة: قد يقوم النموذج بتلفيق معلومات تبدو صحيحة ولكنها ليست كذلك. في لعبة الدردشة هذا أمر مقبول. لا يمكن التسامح معها في نظام الإنتاج (الفاتورة، الصحية، القانونية، المالية). لذلك اتضح أنه غير موثوق به بشكل أعمى. تم تأكيده.
طبقات التحقق (تتزايد حسب التأثير):
- التحقق من صحة التنسيق/المخطط: هل يتوافق الإخراج مع مخطط JSON المتوقع؟ (الناتج المنظم يضمن ذلك إلى حد كبير.)
- التحقق من القاعدة/المنطق: هل القيم معقولة؟ (هل المبلغ سالب، هل التاريخ في المستقبل، هل الفئة صالحة؟)
- التحقق من المصدر: هل تستند المطالبة إلى الوثائق المقدمة؟ هل يقول النموذج شيئًا غير موجود في المستند؟
- الموافقة البشرية: يقوم أحد الخبراء بمراجعة القرارات ذات التأثير الكبير أو الغامضة.
تحذير: "النموذج جيد جدًا، ولا حاجة لمزيد من التحقق" هي أخطر مغالطة في الإنتاج. وبغض النظر عن مدى جودة النموذج، فإن طبقة التحقق تشكل شبكة أمان في القرارات عالية التأثير. حتى قرار تلقائي خاطئ واحد يمكن أن يسلب كل الوقت الذي تم توفيره.
الإنسان في الحلقة
ليس كل قرار يجب أن يكون تلقائياً بالكامل. في نهج الإنسان في الحلقة، يقوم النموذج بتسريع العمل ويوافق عليه الإنسان. يعتمد التوازن الصحيح على تأثير القرار وموثوقية النموذج في تلك المهمة.
تأثير القرار
النهج
منخفض (اقتراح التسمية، مسودة)
أتمتة كاملة الخطأ رخيص وقابل للعكس
متوسط (التوجيه، تحديد الأولويات)
الأتمتة + التحكم في أخذ العينات
عالية (المال، العقد، الصحة، الحذف)
موافقة الإنسان إلزامية؛ النموذج يوحي فقط
المراقبة: لا يمكنك إدارة ما لا تراه
في الإنتاج، يجب عليك مراقبة كل مكالمة. بدون المراقبة، لا يمكنك تحسين التكلفة أو الجودة أو اكتشاف المشكلة مبكرًا. المقاييس الرئيسية للتسجيل:
- الاستخدام/التكلفة: لكل طلب وإجمالي الرموز المميزة وتوزيع النماذج والإنفاق اليومي.
- زمن الاستجابة: متوسط وقت الاستجابة وأسوأ الحالات.
- معدل الخطأ: معدلات 429/500، وإعادة المحاولة، والهجر.
- الجودة: معدل الإخراج المرفوض في طبقة التحقق، ومعدل التصحيح عند موافقة الإنسان، وتعليقات المستخدم.
نصيحة: لا تكتب بيانات حساسة (معلومات شخصية، مفاتيح) لسجلات المراقبة. النظر في السجلات ضمن نطاق السرية؛ سجل عن طريق الإخفاء إذا لزم الأمر (الوحدة 9).
الأخلاق والحدود
تعد المسؤولية الأخلاقية جزءًا من قرار الإنتاج بقدر ما تمثل الدقة الفنية:
- الشفافية: يجب أن يعرف المستخدم ما إذا كان يتحدث إلى ذكاء اصطناعي أم إلى إنسان.
- الإنصاف والتحيز: قد يحمل النموذج تحيزًا من البيانات التي تم تدريبه عليها؛ مراقبة العواقب التمييزية في القرارات عالية التأثير (التوظيف والائتمان).
- المسؤولية: إذا تسبب القرار الآلي في حدوث ضرر، فأنت مسؤول؛ "النموذج قال ذلك" ليس دفاعا.
- قبول الحدود: لا يستطيع النموذج أداء بعض المهام بشكل موثوق؛ عدم أتمتتها هو أيضًا قرار التصميم.
قوالب قابلة للنسخ
# قائمة التحقق من الصحة (بعد إنشاء المخرجات) 1) هل المخطط صالح؟ (التحقق من صحة الإخراج المنظم)2) هل القيم منطقية؟ (التحقق من القاعدة: النطاق والتاريخ والتعداد)3) هل تعتمد المطالبة على المصدر؟ (ارفض إن لم يكن في الوثيقة)4) هل التأثير كبير؟ → إرسال للحصول على موافقة الإنسان 5) إذا تم تمرير كل شيء → السماح بالإجراء، وحفظه
# موجه النظام الذي يفرض الاعتماد على المصدر فقط على المعلومات الواردة في المستند المقدم. لا تقم بإضافة أي شيء غير موجود في المستند. إذا لم تكن هناك معلومات في المستند، فاكتب "غير موجودة في المستند". لا تخمن أو تختلق الأشياء أبدًا.
# عتبة الموافقة البشرية (قاعدة القرار)إذا كان نوع القرار في [المال، العقد، الحذف، الصحة] → الموافقة البشرية إلزاميةIF model_trust < العتبة أو التحقق من الصحة "غير مؤكد" → إرسال إلى الموافقة البشريةOTHER → تطبيق تلقائي + التحكم في أخذ العينات
# قالب سجل التتبع (كتابة البيانات الحساسة){ "time":...", "model":":..., "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":...", "authentication":passed|rejected|human", "cost_usd":... } // لا تتم كتابة البيانات الشخصية والمفتاح مطلقًا
موجه ضعيف / موجه قوي (موثوقية الإنتاج)
# ضعيف (لا يوجد تحقق، لا يوجد مصدر، ينطبق تلقائيًا) قم بتقييم هذا الطلب، واتخاذ قرار استرداد الأموال والتقديم.
# قوي (يعتمد على المصدر، وينشئ التوصية، ويترك للموافقة البشرية)قم بتقييم طلب الإرجاع هذا بناءً على وثيقة سياسة الإرجاع فقط. يوصي بالقرار مع تبريره ولكن لا ينفذه: {"recommendation": "approve|reject"، "reason":..."، "policy_clause": "..."}. إذا لم يكن هناك أساس واضح في وثيقة السياسة، فاكتب "غير واضح". وسيقوم ممثل بالموافقة على القرار النهائي.
نسخة قوية؛ فهو يعزو القرار إلى المصدر، ويضع النموذج باعتباره "مقترحًا" وليس "فاعلًا"، ويضع الخطوة عالية التأثير وراء موافقة الإنسان. هذا هو جوهر موثوقية الإنتاج.
ثلاث حالات صغيرة
الحالة 1 - اليوم الذي حفظت فيه طبقة التحقق. كانت شركة التكنولوجيا المالية لديها نموذج لتصنيف أوصاف المعاملات وإنشاء سجلات محاسبية تلقائية. لقد أضافوا التحقق من صحة القاعدة: بمجرد أن يقوم النموذج بإخراج المبلغ بشكل غير صحيح (12500 بدلاً من 1250 في المستند)، فإن قاعدة "المبلغ لا يتطابق مع المستند" ترفض الإخراج ويسقط السجل على عاتق الإنسان. إذا لم يتم التحقق، فسيدخل السجل غير الصحيح إلى النظام بصمت.
الحالة 2 - القبض على الهارب عن طريق المراقبة. قام فريق SaaS بإنشاء لجنة مراقبة؛ في صباح أحد الأيام تضاعفت التكلفة اليومية ثلاث مرات. وقد تبين من السجلات أن العميل دخل في حلقة وأرسل نفس الطلب آلاف المرات. لقد أضافوا نظام الحصص وإلغاء البيانات المكررة؛ وتم حل المشكلة خلال ساعات. وبدون تتبع، سيكون مشروع القانون مفاجأة في نهاية الشهر.
الحالة 3 - قبول الحد. كانت إحدى الشركات الناشئة في مجال الرعاية الصحية تخطط لتقديم توصية تشخيصية بشكل تلقائي بالكامل وإظهارها للمريض. وفي مراجعة للأخلاقيات والمسؤولية، قرروا أن هذا محظور: النموذج يقدم فقط ملخصًا ونقاطًا محتملة للطبيب، والطبيب هو الذي يقوم بالتشخيص. يعد عدم أتمتة الوظيفة أيضًا قرارًا ناضجًا للتصميم.
الأخطاء الشائعة
- تخطي التحقق من الصحة: تطبيق المخرجات بشكل أعمى، مع قول "النموذج جيد".
- أتمتة القرار عالي التأثير: موافقة الإنسان ضرورية في المال/الصحة/القانون.
- عدم المراقبة: يتم اكتشاف مشاكل التكلفة والجودة في وقت متأخر.
- كتابة البيانات الحساسة في السجلات: انتهاك الخصوصية؛ احفظه عن طريق إخفاءه.
- عدم محاولة الاعتماد على المصدر: قد يشكل النموذج ما هو غير موجود في الوثيقة.
- تجاهل الحدود: عدم أتمتة بعض المهام هو القرار الصحيح؛ الشفافية والمسؤولية لكم.
أعمق: إدارة الإصدار، والتراجع، والنشر المتزايد
لا يعني استخدام ميزة LLM في الإنتاج إعدادها ونسيانها؛ هو تعديل النظام المباشر بأمان مع مرور الوقت. لها ثلاث ركائز.
الإصدار. تتغير قواعد النظام واختيار النموذج والتحقق بمرور الوقت. يتم تغيير كل إصدار بشكل كبير وتسجيل الإصدار المباشر. إذا انخفضت الجودة في يوم من الأيام، "ماذا تغيرنا؟" يجب أن تكون قادرًا على الإجابة على السؤال خلال دقائق. في نظام بدون إصدار، يستغرق العثور على السبب الجذري للانحدار أيامًا.
التراجع. إذا كان سلوك الموجه أو النموذج الجديد أسوأ من المتوقع في البث المباشر، فيجب أن تكون قادرًا على العودة بسرعة إلى الإصدار السابق والمعروف. إن التغيير دون خطة التراجع هو قبول أعمى للمخاطرة الحية. "لقد قمت بتغيير شيء ما، لقد أصبح سيئًا، لا أستطيع العودة" هو السيناريو الأكثر تكلفة للإنتاج.
الطرح التدريجي. بدلاً من تطبيق التغيير على جميع الزيارات مرة واحدة، يمكنك توزيعه على نسبة مئوية صغيرة (على سبيل المثال 5%) أولاً ومراقبة المقاييس (الجودة والتكلفة والأخطاء). إذا كانت جيدة تزيد النسبة؛ إذا كانت سيئة، فسوف تستعيدها مع جزء صغير فقط متأثر. وهذا يحد بشكل كبير من المخاطر.
تجمع هذه الممارسات الثلاث بين تقنيات من جميع الوحدات السابقة: التقييم (الوحدة 5) يقيس التغيير مقدمًا، والمراقبة (هذه الوحدة) تعطي إنذارًا مبكرًا أثناء النشر، وتلتقط طبقة التحقق المخرجات الخاطئة قبل أن تصبح قابلة للتنفيذ. الإنتاج ليس إعدادًا واحدًا صحيحًا؛ إنه نظام مستمر يقيس ويراقب ويمكن أن يتغير بثقة. الوحدة بأكملها مخصصة لك لتأسيس هذا الانضباط.
باختصار
يعد الإنتاج أكثر من مجرد عرض عملي: فهو عبارة عن خط أنابيب من طبقات المدخلات والنماذج والتحقق والعمل والمراقبة. لا يمكن الاعتماد على المخرجات دون التحقق منها؛ وترتبط القرارات عالية التأثير بموافقة الإنسان؛ تتم مراقبة كل مكالمة لمعرفة التكلفة والأخطاء والجودة. تعتبر الأخلاق والشفافية والسيطرة على التحيز والمساءلة وقبول الحدود جزءًا لا يتجزأ من القرارات الفنية. كل قطعة تم تعلمها في هذه الوحدة تأتي معًا في هذا التصميم الشامل.
مهمة التطبيق
تصميم ميزة LLM من البداية إلى النهاية. (1) املأ الطبقات الخمس (الإدخال، النموذج، التحقق، الإجراء، المراقبة) لمهمتك المحددة. (2) ضع علامة حسب التأثير على القرارات التي ستتطلب موافقة الإنسان. (3) اكتب على الأقل ثلاث عمليات تحقق من الصحة (المخطط، القاعدة، المصدر). (4) حدد المقاييس الرئيسية التي ستتتبعها وما لن تقوم بتسجيله. (5) اكتب حدًا ومبدأ أخلاقيًا تقبله في هذه الميزة.
قائمة مرجعية
- [ ] يمكنني تصميم خمس طبقات من خط أنابيب الإنتاج.
- [ ] يمكنني التحقق من صحة الإخراج مقابل المخطط والقاعدة والمصدر.
- [ ] يمكنني تحديد حد الموافقة البشرية بناءً على تأثير القرار.
- [ ] أراقب التكلفة والخطأ والجودة وأتدرب على عدم كتابة البيانات الحساسة في السجلات.
- [ ] أستطيع تحويل الأخلاق والمسؤولية والحدود إلى قرارات إنتاجية.
امتحان الوحدة
1. ما الذي يفعله دور "النظام" في واجهة برمجة تطبيقات دردشة LLM؟
- أ) يعطي النموذج تعليمات دائمة وقواعد سلوك تنطبق طوال المحادثة بأكملها✔
- ب) يحتفظ بالسؤال الأخير الذي كتبه المستخدم
- ج) يخزن الاستجابة التي ينتجها النموذج
- د) تشفير مفتاح API
الوصف: يمنح دور النظام النموذج تعليمات وشخصية وقواعد مستمرة يتم تطبيقها طوال المحادثة بأكملها؛ إنها عملية إعادة توجيه عالية المستوى، منفصلة عن رسائل المستخدم.
2. لماذا يتم إرسال سجل المحادثات (الرسائل السابقة) مرة أخرى في كل مرة في طلب API؟
- أ) من الضروري إجراء نسخ احتياطي حيث يقوم الخادم بحذف السجل
- ب) استدعاءات API عديمة الحالة؛ ✔ يتم إعادة إرسال السياق عند كل طلب لأن النموذج لا يتذكر التاريخ
- ج) مطلوبة فقط للفوترة، وليس لها أي تأثير على النموذج
- د) إرسال التاريخ إلزامي لتجنب إبطاء الاستجابة
توضيح: استدعاءات LLM API عديمة الحالة؛ لا يتذكر النموذج الجولات السابقة، لذلك تتم إعادة إرسال كل السجل ذي الصلة عند كل طلب للحفاظ على السياق.
3. ما هو "الرمز المميز" في تسعير LLM؟
- أ) كلمة المرور المستخدمة لمرة واحدة لتسجيل الدخول إلى واجهة برمجة التطبيقات (API).
- ب) رسم ثابت يدفع على كل طلب
- ج) أصغر وحدة يعالج فيها النموذج النص؛ يتوافق عادةً مع جزء الكلمة ✔
- د) وحدة تقيس طول المخرج فقط
الوصف: الرمز المميز هو أصغر وحدة يعالج فيها النموذج النص؛ وهو يتوافق عادة مع جزء من الكلمة، ويتم احتساب كل من الإدخال والإخراج بناءً على عدد الرموز المميزة.
4. لماذا تكون رموز الإخراج أكثر تكلفة من رموز الإدخال لدى معظم موفري LLM؟
- أ) تكون رموز الإخراج دائمًا أطول من رموز الإدخال
- ب) رموز الإدخال مجانية
- ج) يتم إرسال رموز الإخراج مرتين عبر الإنترنت
- د) تكلفة الوحدة أعلى لأن توليد المخرجات يتطلب حسابات إضافية لكل رمز ✔
الوصف: يتطلب كل من الرموز المميزة للإخراج أن يقوم النموذج بإجراء عملية إنشاء (حساب) خطوة بخطوة؛ تكلفة الإنتاج هذه أعلى من معالجة المدخلات دفعة واحدة، وبالتالي فإن سعر وحدة الإخراج عادة ما يكون أعلى.
5. في أي موقف يكون استخدام البث أكثر فائدة؟
- أ) في الإجابات الطويلة؛ يقلل من التأخير الملحوظ ويمنع انتهاء المهلة ✔
- ب) فقط في إجابات قصيرة جدًا مكونة من كلمة واحدة
- ج) تخفيض التكلفة إلى الصفر
- د) لإخفاء مفتاح API
الوصف: في الاستجابات الطويلة، يقلل الدفق من زمن الاستجابة المتصور عن طريق جعل الكلمات الأولى تظهر على الفور ويمنع انتهاء مهلات HTTP عند قيم max_tokens الكبيرة.
6. ما الذي يؤثر بشكل عام على زيادة معامل "الجهد" في النماذج الحديثة؟
- أ) اختصر الإجابة دائمًا
- ب) يقوم بتدوير مفتاح API تلقائيًا
- ج) إنه يقلل فقط من سعر رمز الإدخال
- د) يزيد من عمق التفكير والإنفاق الرمزي؛ قد يؤدي ذلك إلى تحسين الجودة، ولكنه يزيد أيضًا من زمن الوصول والتكلفة ✔
الوصف: تضبط معلمة الجهد مدى عمق تفكير النموذج في المهمة وعدد الرموز المميزة التي سينفقها؛ قد تؤدي الترقية إلى تحسين الجودة، ولكنها تؤدي أيضًا إلى زيادة زمن الوصول والتكلفة. بالنسبة للمهام البسيطة، فإن الجهد المنخفض يكفي.
7. ما هو النهج الأكثر فعالية من حيث التكلفة بشكل عام لمهمة تصنيف بسيطة وكبيرة الحجم؟
- أ) استخدم دائمًا الطراز الأغلى والأقوى
- ب) استدعاء جميع النماذج في نفس الوقت لكل طلب
- ج) اختيار النموذج الأخف/الأرخص الذي ينجز المهمة من خلال التحقق منه بقليل من التقييم✔
- د) الحفاظ على قيمة max_tokens مرتفعة جدًا دون داعٍ
توضيح: إذا لم تكن المهمة معقدة، فإن اختيار نموذج أسرع وأرخص ينجز المهمة بسهولة (مثل فئة Haiku) بدلاً من استخدام النموذج الأكثر تكلفة والقوة سوف يقلل التكلفة بشكل كبير.
8. في أي سيناريو يؤدي التخزين المؤقت الفوري إلى تقليل التكلفة إلى أقصى حد؟
- أ) عند استخدام سياق كبير وثابت بشكل متكرر عبر العديد من الطلبات✔
- ب) عندما يتم إرسال نص مختلف تمامًا مع كل طلب
- ج) عندما يتم تقديم طلب واحد فقط
- د) لتقليل رموز الإخراج
الوصف: التخزين المؤقت عبارة عن مطابقة بادئة؛ في الحالات التي يتم فيها إعادة استخدام سياق كبير غير قابل للتغيير (موجه النظام، المستندات) عبر العديد من الطلبات، تكون القراءة من ذاكرة التخزين المؤقت جزءًا صغيرًا (~0.1x) من السعر الكامل.
9. كيف يمكنني تعديل المطالبة بحيث تصل ذاكرة التخزين المؤقت للمطالبة؟
- أ) وضع محتوى متغير في البداية ومحتوى ثابت في النهاية
- ب) قم بتضمين التاريخ والوقت الحاليين في موجه النظام لكل طلب
- ج) وضع محتوى ثابت (موجه النظام، المستندات) في البداية ومحتوى متغير في النهاية✔
- د) تغيير ترتيب قائمة الأدوات مع كل طلب
Explanation: بما أن ذاكرة التخزين المؤقت هي تطابق بادئة، تتم تهيئة المحتوى الثابت/غير المتغير (موجه النظام، المستندات)؛ يتم وضع المحتوى المتغير (التاريخ، سؤال المستخدم، معرف الطلب) في النهاية. حتى أن تغيير بايت واحد في البداية سيؤدي إلى إبطال ذاكرة التخزين المؤقت.
10. ما هو نوع عبء العمل الذي يناسب المعالجة المجمعة بشكل أفضل؟
- أ) الدردشة المباشرة حيث يتوقع المستخدم استجابة فورية على الشاشة
- ب) سؤال واحد قصير فقط
- ج) إنشاء مفتاح API
- د) الوظائف التي تتحمل التأخير وكبيرة الحجم ولا تتطلب نتائج فورية✔
الوصف: المعالجة المجمعة مناسبة للكميات الكبيرة من المهام التي لا تتطلب استجابة فورية وتتحمل التأخير؛ يتم تسليم النتائج بعد مرور بعض الوقت، ولكن تكلفة الوحدة عادة ما تكون أقل.
11. ما الذي يتم استخدامه لمطابقة الطلب الذي تنتمي إليه النتائج بشكل موثوق في الدفعة؟
- أ) إرسال أمر (موقف) الطلبات
- ب) طول الإجابات
- ج) آخر 4 أرقام من مفتاح API
- د) معرف مخصص فريد يُعطى لكل طلب ✔
ملاحظة: قد يتم إرجاع النتائج المجمعة بترتيب مختلف عن ترتيب التقديم؛ لذلك من الضروري مطابقة النتائج حسب المعرف، وليس الموقع، مع معرف مخصص فريد لكل طلب.
12. ما هو السلوك الموصى به عندما تتلقى خطأ 429 (حد السعر) من واجهة برمجة التطبيقات؟
- أ) الإجبار عن طريق إرسال العديد من الطلبات في نفس الوقت
- ب) المحاولة مرة أخرى مع التراجع الأسي، بعد العنوان "إعادة المحاولة بعد" ✔
- ج) إلغاء الطلب بالكامل وإظهار الخطأ على أنه عطل للمستخدم
- د) تغيير مفتاح API
توضيح: 429 خطأ قابل لإعادة المحاولة؛ النهج الصحيح هو المحاولة مرة أخرى مع التراجع الأسي، مع احترام رأس إعادة المحاولة بعد. تقوم معظم حزم SDK الرسمية بذلك تلقائيًا.
13. أي من رموز خطأ HTTP التالية تعتبر قابلة لإعادة المحاولة بشكل عام؟
- أ) 400 (طلب غير صالح)
- ب) 401 (خطأ في المصادقة)
- ج) 529 (الخادم مثقل) ✔
- د) 404 (غير موجود)
توضيح: 429 (حد السرعة)، 500 (خطأ في الخادم) و529 (التحميل الزائد) هي أخطاء مؤقتة ويمكن إعادة المحاولة عن طريق التراجع. أخطاء مثل 400 و401 هي مشكلات تتعلق بالطلب/الهوية؛ المحاولة مرة أخرى لن تحل المشكلة.
14. أي مما يلي هو الطريقة الآمنة لإدارة مفاتيح API؟
- أ) التخزين في متغير البيئة/المدير المخفي، وعدم تضمينه في الكود وتدويره بانتظام ✔
- ب) اكتب المفتاح مباشرة في الكود المصدري وأرسله إلى المستودع
- ج) وضع المفتاح في جانب العميل (المتصفح) JavaScript
- د) مشاركة مفتاح واحد مع الفريق بأكمله عبر البريد الإلكتروني
الوصف: لا تتم كتابة المفاتيح أبدًا إلى الكود المصدري أو المستودع؛ ويتم تخزينها في متغير بيئة أو أداة إدارة مخفية، ويتم منحها بأقل قدر من الامتيازات، ويتم تدويرها بانتظام.
15. ما هو أفضل نهج لتكامل LLM مع أداة التشغيل الآلي (n8n، Zapier، Make) من حيث الخصوصية؟
- أ) إرسال جميع البيانات الأولية إلى النموذج حتى لو لم تكن ضرورية
- ب) كتابة مفتاح API بنص عادي داخل خطوة التدفق
- ج) تقليل وإخفاء البيانات الحساسة وتخزين المفتاح كبيانات اعتماد سرية ✔
- د) الاحتفاظ بالبيانات الشخصية بشكل دائم في سجل التدفق
الوصف: نظرًا لأن أتمتة إدخال البيانات تمر عبر أنظمة ونماذج تابعة لجهات خارجية، فيجب تقليل البيانات الحساسة/الشخصية وإخفائها وإرسال الحقول المطلوبة فقط؛ يتم أيضًا تخزين مفتاح API كبيانات اعتماد سرية داخل الأداة.
16. لماذا يعد التحقق من صحة المخرجات أمرًا إلزاميًا في ميزة الإنتاج القائمة على LLM؟
- أ) مطلوب التنسيق فقط لأن النموذج لا يرتكب أخطاء أبدًا
- ب) لأن النموذج يمكن أن ينتج بشكل سلس ولكن في بعض الأحيان بشكل غير صحيح؛ يجب مراجعة المخطط/القاعدة بموافقة الموارد والبشر ✔
- ج) ينبغي تجنب التحقق من الصحة لأنه يزيد التكلفة فقط
- د) التحقق هو فقط لتقليل عدد الرموز
الوصف: يمكن أن تنتج LLM مخرجات بطلاقة ولكن في بعض الأحيان غير دقيقة (هلوسة)؛ فخرجت بقرارات عالية التأثير؛ وينبغي تدقيقها عن طريق فحص المخطط/القواعد، والتحقق من صحة المصدر، والموافقة البشرية عند الضرورة.