أدلة ومقارنات وأحدث الأخبار عن أدوات الذكاء الاصطناعي

في يوم ما يتوقّف حساب ChatGPT أو Claude عن العمل فجأة: في 2026 تتزايد التقارير عن إيقاف الحسابات والتحذيرات، والمخيف أنه يمكن حظرك بمخالفة الشروط دون قصد حتى من دون نية سيئة. يلخّص هذا المقال ما تحتاج معرفته لتجنّب فقدان حسابك على OpenAI (ChatGPT و Codex) و Anthropic (Claude و Claude Code) بالاستناد إلى سياسات الاستخدام المنشورة والتقارير، وهو ليس دليلًا للتهرّب من الكشف بل للالتزام بالقواعد. خمسة مُحفّزات شائعة بين الشركتين: المحتوى المحظور / jailbreak، والأتمتة أو الاستخلاص غير المصرّح، ومشاركة أو إعادة بيع الحسابات ومفاتيح API، وأنماط الوصول المريبة (تغييرات متكررة في IP والدولة، واستخدام مكثّف لـ VPN)، وعدم تطابق الدفع أو الاحتيال. أكبر فخ في 2026: استخدام رموز OAuth الخاصة بالخطة الشخصية (Free/Pro/Max) في أي منتج غير التطبيق الرسمي، بما في ذلك أطر مثل Agent SDK، يُعدّ مخالفة لشروط الخدمة للمستهلك تسبّبت في موجة حظر كبيرة؛ والنهج الصحيح هو تشغيل التطبيقات والوكلاء عبر API (الدفع حسب الاستخدام). على جانب OpenAI: التحايل على قيود الأمان، والأتمتة، وإساءة مفاتيح API، والاستخدامات غير القانونية. على جانب Anthropic: إساءة رموز OAuth، والوصول غير الرسمي، وبنود مكافحة التقطير، وjailbreak. قائمة وقاية من سبع نقاط، والتحذير فرصة للتصحيح، والمخالفات الطفيفة قابلة للاعتراض بينما الجسيمة دائمة. الخطة الصحيحة، للغرض الصحيح، بأمانة.

إعادة تدريب ذكاء اصطناعي ضخم من الصفر مكلفة للغاية، لكنك تريد تعديله ليناسبك فقط؛ يحقق LoRA (Low-Rank Adaptation) هذه الأمنية بتجميد النموذج الأصلي وتدريب جزء إضافي صغير (محوّل) فقط، مقلّصًا المعاملات القابلة للتدريب بنحو 90%. يجعل LoRA عملية fine-tuning أرخص وأسرع بكثير، وهو شائع جدًا في توليد الصور مثل Stable Diffusion بوصفه ملفًا صغيرًا يضيف شخصية أو أسلوبًا. يشرح هذا المقال الفكرة عبر تشبيه الرقعة. LoRA رائد fine-tuning كفؤ المعاملات (PEFT): اترك الأوزان الأصلية الضخمة مجمّدة، وأدرج مصفوفة إضافية صغيرة في كل طبقة، ودرّب تلك فقط (W = W0 + BA). من فوائده: معاملات أقل بنحو 90% (وعلى نطاق GPT-3 أقل بمقدار 10,000x)، وذاكرة GPU أقل (نحو 3x)، وتدريب أسرع وأرخص، ودون زمن استجابة إضافي بعد دمج المحوّل، وخطر فرط تطابق أدنى. أكبر قوته هي المحوّلات القابلة للتبديل: أبقِ أساسًا مشتركًا واحدًا وبدّل ملفات LoRA الصغيرة لكل حالة استخدام فوريًا. يلتقي كثيرون بـ LoRA أولًا في توليد الصور حيث تُشارَك LoRA الخاصة بـ Stable Diffusion التي تعلّمت شخصية أو أسلوبًا. يدمج QLoRA الـ quantization، فيدرّب LoRA فوق أساس 4-bit لذاكرة أقل بنحو 4x، مما يتيح fine-tuning نماذج ضخمة على GPU استهلاكية بفقدان دقة طفيف. ومقابل fine-tuning الكامل، يكفي LoRA لمعظم العمل.

نموذج ضخم بحجم 70B يعمل على جهاز ألعاب منزلي واحد بدل رفّ من بطاقات GPU في مركز بيانات، وما يجعل هذا ممكناً هو التكميم الذي يخفض الدقة العددية لأوزان النموذج لتقليص الحجم والذاكرة بشكل كبير. بينما ينقل تقطير النماذج المعرفة إلى نموذج أصغر منفصل، يجعل التكميم النموذج نفسه أخف. يشرح المقال الفكرة عبر تشبيه ضغط الصور: يستبدل التكميم الأوزان المخزَّنة بصيغة FP16/FP32 بأعداد صحيحة INT8 أو INT4، فيقلل البايتات لكل وزن (FP32=4، INT8=1، INT4=0.5)؛ ومثل ضغط صورة RAW إلى JPEG تضحي بقليل من الدقة مقابل تخفيف كبير، والمفاجأة هي قلة ما تتنازل عنه. على صعيد الذاكرة، يستخدم 4-bit نحو ربع FP16: ينخفض نموذج 70B من نحو 140GB إلى 35GB، ونموذج 8B بـ4-bit يصبح نحو 4.5-5GB، فيتسع في GPU متوسط بذاكرة 8GB للاستخدام المحلي (دمقرطة LLM). على صعيد الدقة، INT8 شبه خالٍ من الفقد وINT4 يتدهور أقل من 4% في مهام المعرفة العامة، لكن الفقد أوضح في الرياضيات وتوليد الشيفرة والاستدلال الصعب (يظهر كارتفاع طفيف في perplexity)، فاختر عدد البتات للمهمة. الطرق الرئيسية: GPTQ (رائد 4-bit الدقيق)، وAWQ (يحمي أهم ~1% من الأوزان، وغالباً أدق بنسبة 1-2% وأسرع)، وGGUF (صيغة llama.cpp/Ollama، من Q2_K إلى Q8_0، مزج CPU+GPU، للتشغيل المحلي)، وQLoRA (أساس 4-bit مع LoRA للضبط الدقيق على GPU استهلاكي). يختلف عن التقطير (الانتقال إلى نموذج أصغر منفصل) والضبط الدقيق (إضافة معرفة المهمة)، وتُستخدم الثلاثة عادةً مجتمعة. للبدء، شغّل نموذج GGUF بـOllama بأمر واحد، واختر Q4/Q8 حسب VRAM، وتجنّب INT4 للشيفرة أو الحساب الدقيق. معظم النماذج الرئيسية تُوزَّع مُكمَّمة سلفاً فتنزّلها وتستخدمها فقط. احتفظ بالذكاء وأسقط الوزن فقط.

الذكاء الاصطناعي الضخم وعالي الأداء ذكي لكنه ثقيل ومكلف؛ ويحل تقطير النماذج (تقطير المعرفة) ذلك بنقل معرفة نموذج معلّم كبير إلى نموذج طالب صغير، مع الحفاظ على أكثر من 95% من أداء المعلّم بعُشر الحجم وبسرعة أكبر. يشرح المقال ذلك بتشبيه المعلّم والطالب. المفتاح هو الـ soft labels: التدريب العادي يُعلّم فقط «الجواب قطة» (hard label)، بينما يمرّر التقطير توزيع الاحتمالات الكامل للمعلّم مثل «90% قطة، 8% كلب، 2% ثعلب»، حيث تحمل درجة التردد معلومات غنية؛ ويقوم معامل temperature بتليين الاحتمالات لكشف العلاقات الدقيقة (مثال واقعي: GPT-4o mini مُقطَّر من GPT-4o). الفوائد: سريع ورخيص، أصغر بنحو 10x مع الحفاظ على أكثر من 95% من الأداء، يعمل على الـ edge، وقوي في التخصص. منهجان: white-box (وصول كامل للأوزان والتمثيلات الداخلية، نقل أعمق؛ لنماذجك أو نماذج OSS) و black-box (المخرجات/استجابات API فقط؛ استخدام API شركة أخرى كمعلّم قد يخالف الشروط). ويختلف عن quantization (ضغط دقة أوزان النموذج نفسه) و fine-tuning (مواصلة تدريب نموذج موجود لمهمة) — فالتقطير ينقل المعرفة إلى نموذج صغير منفصل، والثلاثة قابلة للدمج. كان الواقع القانوني وشروط الخدمة قضية كبيرة في 2026: التقنية مشروعة، لكن لدى OpenAI و Anthropic و Mistral و xAI بنود منع تقطير منافس تحظر استخدام المخرجات لبناء نماذج منافسة. نزاع OpenAI ضد DeepSeek يُظهر أن التقييم يعتمد على شروط API مَن تنطبق، وأُفيد بأن Claude Fable 5/Mythos 5 تُقيّد الردود على الأعمال المُصنّفة كتقطير. نصائح: استخدم نماذجك أو نماذج OSS مرخّصة كمعلّم، وتحقق من بنود منع التقطير قبل استخدام API تجاري. الأرقام مقتبسة من مواد عامة وتوجيهية.

قلنا في "كيف تبني نظامًا متعدد الوكلاء" إنه يجب تجهيز القياس لكل عملية تسليم قبل إضافة الوكلاء؛ والتقنية التي تشغّل هذا القياس في الإنتاج هي AI observability. فهي تُظهر ما تفعله LLMs والوكلاء فعليًا في الإنتاج (أي نموذج وبأي prompt، وأي أدوات وعمليات بحث، وما الذي أُعيد، وكم استغرق وكلّف) حتى تتبّع رجوعًا إلى السبب. الفرق الحاسم عن مراقبة التطبيقات العادية: قد يعيد الذكاء الاصطناعي 200 OK في 50ms ومع ذلك يهلوس بثقة، فمعظم الإخفاقات إخفاقات جودة (هلوسة، استرجاع ضعيف، إجابات غير آمنة، مهام غير مكتملة) لا إخفاقات بنية تحتية. تقوم الـobservability على ثلاث ركائز: traces (طلب واحد كشجرة spans) وmetrics (زمن الاستجابة والتكلفة والـtokens) وlogs. والمعيار OpenTelemetry GenAI يلتقط الـprompts والاستجابات والـtokens واستدعاءات الأدوات بمخطط محايد قابل للتغذية في Datadog/Grafana. الفرق الأكثر خلطًا هو observability مقابل evals: الأولى تُظهر ما حدث، والثانية تقيس جودة الإجابة (الدقة وgroundedness والأمان). تنقسم المقاييس إلى تشغيلية (تكلفة، زمن استجابة، tokens) وجودة (هلوسة، groundedness الأهم لـRAG، أمان، إتمام المهمة)، مع كشف الهلوسة عبر LLM-as-a-judge ودرجات groundedness. الأدوات الرئيسية: LangSmith وLangfuse وArize Phoenix وMLflow وAgentOps وOpenTelemetry. ابدأ بالتقاط traces ثم صوّر المقاييس واربط evals قبل الإطلاق. للأنظمة متعددة الوكلاء المراقبة ضرورية لأن الإخفاقات تختبئ في سلاسل متعددة الخطوات.

بعد استيعاب المفهوم في «ما هو نظام الوكلاء المتعددين؟»، هذا هو الجزء العملي التالي. باستخدام نمط supervisor المعياري لعام 2026، يرشد المبتدئين عبر بناء من 5 خطوات. المبدأ الأساسي: ابنِ بوكيل واحد أولاً وأضِف الوكلاء بأقل قدر فقط بعد بلوغ حد ما (نحو 80% من الحالات تكفيها واحد؛ واستخدام نظام متعدد لعمل بسيط أحادي المسار يضخّم التكلفة 3-10x ويخفض الدقة -39-70% في المهام التسلسلية حسب أبحاث Google). ثلاث علامات للانتقال: فصل التخصصات، التوازي، فصل القرار. نمط supervisor (يتلقى المهمة الكلية، يقسّمها، يفوّضها إلى workers متخصصين، ويجمّع النتائج) هو ما تقاربت عليه وكلاء Claude Code الفرعيون وLangGraph Supervisor وOpenAI Agents SDK، لأوسع دعم ونمط فشل معروف وسهولة التدقيق. الخطوات الخمس: التقسيم، تعريف الـ workers، تصميم الـ supervisor، التسليم، القياس مع حدود قصوى وعمليات تقييم وحواجز أمان. الدرس: الموجّهات والأدوات وحزمة التقييم تحدد النجاح أكثر من إطار العمل.

«قسّم مهمة معقدة لا يقدر عليها وكيل ذكاء اصطناعي واحد على عدة وكلاء» هي الفكرة وراء الأنظمة متعددة الوكلاء. يشرح هذا الدليل المبسّط للمبتدئين الآلية والأنماط الرئيسية وأبرز أطر العمل، والأهم القاعدة الواقعية لاتخاذ القرار حول متى تستخدم عدة وكلاء ومتى يكفي وكيل واحد بلا مبالغة. يعمل في النظام متعدد الوكلاء عدة نماذج ذكاء اصطناعي بأدوار مختلفة معاً على مهمة كبيرة واحدة؛ فمقابل وكيل واحد يتولى كل شيء (يكفي لنحو 80% من حالات الاستخدام، رخيص وسهل التصحيح)، يقسّم العمل حسب التخصص للتنفيذ المتوازي والتدقيق المتبادل، مع تكلفة تنسيق واستهلاك رموز أعلى. الأنماط الأربعة المهيمنة للتنسيق هي: orchestrator-worker (قائد يفكّك ويوزّع العمال بالتوازي ثم يجمع؛ الأوسع استخداماً مع أثر قابل للتدقيق)، والتسليم المتسلسل (تمرير السياق للوكيل التالي)، والمحادثة الجماعية (تتناقش الوكلاء في خيط واحد مع مُحدِّد لمن يتحدث؛ مفيد للتحقق المتبادل)، وآلة الحالة الرسومية (الوكلاء عُقد والانتقالات حواف وحالة صريحة؛ قوي في التفرّعات ونقاط التحقق). تقلّصت أطر العمل في 2026 إلى LangGraph (الأوسع حضوراً في الإنتاج)، وCrewAI (أقل منحنى تعلّم، للنماذج الأولية)، وAutoGen/AG2 (النقاش والتحقق، للبحث)، وOpenAI Swarm (عمليات التسليم الخفيفة). لكنه ليس دواءً لكل داء: المهام المعقدة متعددة المجالات تشهد حتى +23% في معايير الاستدلال، لكن في المهام المتسلسلة أحادية المسار وجدت أبحاث Google −39-70% مقابل وكيل واحد، وغالباً ما يضاهي وكيل واحد بنفس القدرة الحوسبية أو يتفوّق، و7 من كل 10 عمليات نشر أضافت تكلفة دون عائد عند استهلاك ~15x من الرموز (متوسط العائد 2.5-3.5x، الربع الأعلى 4-6x عند التوجيه الجيد). المسار الموصى به: ابنِ بواحد أولاً، حدّد سقفاً ملموساً (أدوار متداخلة، عمل قابل للتوازي)، ثم أضف فريق نمط القائد بأدنى حدّ من 2-3 وكلاء مع حدّ أقصى للتكلفة والتسجيل، وقِس ما إذا كان مكسب الدقة يبرّر الزيادة. A2A (بروتوكول التواصل) وMCP (ربط الأدوات) تقنية أساسية تدعم متعدد الوكلاء. واحد لـ 80%، وتعدّد للأجزاء الصعبة فقط. الأرقام مقتبسة من استطلاعات وأبحاث ومرتبطة بالظروف، اتجاهية.

بعد أن أصبح وكلاء الذكاء الاصطناعي أمرًا شائعًا، صار التحدي التالي هو كيفية جعل الوكلاء يتعاونون فيما بينهم. إذا كان MCP يربط الوكيل بأدواته، فإن A2A (Agent2Agent) يربط الوكيل بوكيل آخر — معيار مفتوح يتيح لأنظمة الذكاء الاصطناعي المبنية على مزوّدين وأُطر عمل مختلفة أن تكتشف بعضها وتتواصل وتتعاون عبر اصطلاح مشترك. أطلقته Google في أبريل 2025، وتبرّعت به لمؤسسة Linux Foundation في يونيو، ووصل إلى الإصدار v1.0 في 2026. يغطّي هذا الدليل للمبتدئين ما هو A2A (بتشبيه آداب الشراكة التجارية)، ولماذا نحتاجه (وكلاء متخصّصون يتناوبون العمل — وكيل تخطيط ثم وكيل حجز فنادق ثم وكيل دفع)، وكيف يختلف عن MCP (MCP عمودي، الوكيل ↔ الأدوات؛ وA2A أفقي، الوكيل ↔ الوكيل؛ والجمع بينهما هو الإعداد القياسي ذو الطبقتين)، وكيف يعمل (تُستخدم بطاقة وكيل — ملف JSON يشبه «بطاقة العمل» عند /.well-known/agent-card.json — لاكتشاف القدرات، ثم تحمل المهمة (Task) الطلب عبر حالات مثل working وinput-required وcompleted، وتُعيد النتيجة (Artifact) المُخرَج، كل ذلك عبر HTTP وServer-Sent Events وJSON-RPC 2.0، مع إبقاء الوكلاء دواخلهم خفيّة)، ووضعه الحالي والتطبيق (حتى أبريل 2026: 150+ مؤسسة في بيئة الإنتاج، 22,000+ نجمة على GitHub، وحِزم تطوير بخمس لغات — Python وJavaScript وJava وGo و.NET — بمشاركة Microsoft وSalesforce وSAP وServiceNow). القاعدة المساعدة على التذكّر: الاتصال بالأدوات = MCP، والاتصال بالأنداد = A2A.

بنيت نظام RAG لكن جودة البحث متوسطة — وهنا بالضبط تساعد إعادة الترتيب. تعيد إعادة الترتيب تقييم المرشحين الذين جُمعوا بشكل تقريبي عبر البحث بالتضمين (المتجهات) حسب صلتهم بالاستعلام، ثم تعيد ترتيبهم وتُبقي الأفضل فقط؛ وهذه الخطوة الواحدة قد تُغيّر جذريًا جودة إجابات نظام RAG. يغطي هذا الدليل للمبتدئين ما هي إعادة الترتيب (بتشبيه الفرز الأولي والمقابلة النهائية)، ولماذا نحتاجها (البحث بالتضمين يحوّل الاستعلام والمستندات إلى متجهات بشكل منفصل، فيحكم على الصلة بخشونة فقط، والترتيب السيئ يخفض جودة الإجابة مباشرةً — وتذكر الأبحاث مكسبًا في دقة RAG يبلغ نحو 40% من إضافة إعادة الترتيب، وأصبح طبقها فوق البحث الهجين معيار 2026)، وكيف يعمل الاسترجاع على مرحلتين ("اجمع بسعة" بالبحث بالتضمين السريع من أجل الاستدعاء، ثم "صفِّ بذكاء" بالمُعيد للترتيب من أجل الدقة، ثم سلِّم الأعلى إلى نموذج اللغة الكبير)، ولماذا يكون المُعيد للترتيب أدق (المُرمِّز الثنائي bi-encoder يحوّل الاستعلام والمستند إلى متجهين على حدة وهو سريع لكنه تقريبي؛ والمُرمِّز المتقاطع cross-encoder يُدخلهما معًا ويُخرج درجة صلة 0–1، دقيق لكنه ثقيل — لذا تجمع بالمُرمِّز الثنائي السريع وتصفّي بالمُرمِّز المتقاطع الدقيق)، ثم النماذج والتنفيذ (نوع الـ API مثل Cohere Rerank وVoyage وJina؛ ومفتوح المصدر مثل BGE reranker وmixedbread وFlashRank؛ والتقييم بنموذج لغة كبير مثل RankLLM — فقط استرجع 50–100 وصفِّ إلى أعلى 5). المبدأ: اجمع بسعة، صفِّ بذكاء، واضبط الأعداد بتقييمات الذكاء الاصطناعي.

بعد أن تتمكّن من بناء تطبيقات الذكاء الاصطناعي، تأتي المرحلة التالية وهي تشغيلها بأمان. يمكن خداع نماذج اللغة الكبيرة بمدخلات خبيثة، أو تسريب بيانات سرية، أو الجزم بهراء بثقة؛ والآلية الأمنية التي تمنع ذلك هي حواجز الأمان للذكاء الاصطناعي، التي أصبحت جزءاً أساسياً من الإنتاج في 2026 مع وقوع حوادث وكلاء الذكاء الاصطناعي فعلياً. حواجز الأمان قواعد ومرشّحات تكبح المدخلات الخطيرة والمخرجات غير المرغوبة، فتفحص مدخلات المستخدم قبل أن تصل إلى النموذج والإجابة قبل أن تعود — طبقة أمان مستقلة منفصلة عن النموذج نفسه. التهديدات الرئيسية هي حقن الأوامر (الأكبر) وكسر القيود وتسريب البيانات (البيانات السرية، PII، موجّه النظام) والهلوسة أو المخرجات الضارة. تعمل الحماية على طبقتين: حواجز الإدخال (كشف الحقن وكسر القيود، كشف/إخفاء PII، تقييد المواضيع، التعقيم) وحواجز الإخراج (تصفية المحتوى الضار، منع التسريب، فحص الهلوسة، التحقق من التنسيق). حقن الأوامر — المصنّف الأكثر خطورة على OWASP LLM Top 10 — يأتي بصيغة مباشرة (يكتب المستخدم «تجاهل كل التعليمات السابقة») وغير مباشرة (أوامر مخفية في صفحة ويب أو مستند RAG)، والحقن غير المباشر لا يحجبه RAG وحده، لذا تحتاج المستندات المسترجعة إلى فحص خاص بها. يغطّي هذا الدليل للمبتدئين أيضاً الأدوات (LLM Guard، Guardrails AI، NeMo Guardrails، Llama Guard، وميزات الأمان السحابية من Azure وAWS وOpenAI) والمبادئ العملية للدفاع المتعمّق وأقل امتياز والموافقة البشرية والمراقبة المستمرة.

يعتمد RAG والبحث الدلالي والتوصيات جميعًا على بطل خفي: embedding (التضمين / المتجه). embedding هو معنى النص (أو الصورة) مُحوَّلًا إلى سلسلة من الأرقام — أي متجه. تصبح كلمة «كلب» قائمة من مئات إلى آلاف الأرقام تعمل بوصفها «إحداثيات للمعنى»، فتقع الكلمات المتقاربة في المعنى قرب بعضها (كلب وجرو متقاربان؛ كلب وسيارة متباعدان)، ويُقاس القرب بمقاييس مثل cosine similarity. مثال شهير: «ملك − رجل + امرأة ≈ ملكة». ولذلك يمكن للآلة أن تحكم على قرب المعنى حتى عندما لا تتطابق الحروف. يغطي هذا الدليل للمبتدئين ما هو embedding («خريطة للمعنى»)، ولماذا يقيس القرب المعنى (الأبعاد وcosine similarity)، وفيمَ يُستخدم (RAG والبحث الدلالي والتصنيف وإزالة التكرار والتوصيات والوسائط المتعددة)، وكيف تختار نموذج embedding (نوع API مثل OpenAI text-embedding-3 وCohere وGemini وVoyage؛ ونوع مفتوح المصدر مثل BGE-M3 وNomic وQwen3؛ إضافةً إلى Matryoshka التي يمكنها تقليص 3,072 بُعدًا إلى 1,024 مع الحفاظ على نحو 95% من الجودة بثلث التكلفة تقريبًا)، وقواعد بيانات المتجهات (Pinecone وWeaviate وQdrant وChroma وpgvector) مع بداية من ثلاث خطوات (اختر نموذجًا، حوّل الوثائق إلى متجهات وخزّنها، حوّل السؤال إلى متجه وابحث). التضمينات هي أساس تنفيذ RAG.

صقلت مطالباتك، وأضفت معرفة عبر RAG، وربما أجريت الضبط الدقيق — فكيف تتأكد أنه تحسّن فعلًا؟ هنا تتصدّر تقييمات الذكاء الاصطناعي المشهد، وبحلول 2026 صار التقييم جوهريًا إلى حدّ تسميته "بنية تحتية". تعني تقييمات الذكاء الاصطناعي قياس جودة مخرجات LLM بشكل منهجي (الدقة، الهلوسات، الالتزام بالصيغة، النبرة) على مقياس ثابت بدل الإحساس؛ وبدونها يبقى التحسين مجرد حدس. هناك طريقتان: التقييم القائم على الكود للعناصر القابلة للقياس آليًا (المطابقة التامة، الصيغة، الكلمات المطلوبة أو المحظورة — سريع ورخيص ومستقر)، وLLM-as-judge للعناصر الذاتية (استخدام نموذج LLM قوي بوصفه حَكَمًا لمنح درجات للمخرجات، عبر المقارنة الزوجية أو تسجيل مخرج واحد). والمبدأ: قِس بالكود كل ما يستطيع الكود قياسه. لـ LLM-as-judge تحيّزات الإطناب والموضع وتفضيل الذات؛ وحلولها استخدام عائلة نماذج مختلفة كمُقيّم، وتبديل الترتيب والتقييم مرتين، ووضع الإيجاز في معيار التصحيح، والمعايرة مقابل الحكم البشري. المقاييس الخشنة (pass/fail أو 1–3) تتفوّق على الدقيقة 1–10. وفي الممارسة، شغّل ثلاث طبقات — فحوصات كود فورية عند كل تغيير، واختبارات تراجع ليلية بـ LLM-as-judge، ومراقبة إنتاج مستمرة — مستخدمًا أدوات مثل DeepEval وPromptfoo وRAGAS لـ CI إضافةً إلى Braintrust وLangSmith وArize للمراقبة. ابدأ بجمع 10 مخرجات جيدة و10 سيئة وتقييمها.