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

رسالة «You've hit your session limit · resets 3:45pm» في Claude Code ليست خطأً، بل آلية عمل حدود استخدام الاشتراك. يسرد المرجع الرسمي أربع صيغ: session (نافذة الخمس ساعات المتدحرجة)، وweekly (النافذة الأسبوعية)، وOpus وSonnet (حدود لعائلة واحدة من النماذج)؛ ولأن حدّي الجلسة والأسبوع مشتركان بين كل النماذج، فتغيير النموذج لا يعيد الوصول. يشرح المقال معنى كل رسالة وكيف تغيّر النصّ منذ الصياغة القديمة «Claude usage limit reached»، وما الذي يستهلك الحصّة، وما الذي تفعله لحظة بلوغ السقف: تبديل النموذج عبر ‎/model مع حدّ Opus/Sonnet، أو انتظار الإعادة (تلقائياً منذ الإصدار v2.1.234)، أو أرصدة الاستخدام عبر ‎/usage-credits، أو التحوّل إلى API بنظام الدفع حسب الاستخدام، إضافةً إلى كيفية رؤية ما تبقّى عبر ‎/usage والرسائل المشابهة التي لا تعني بلوغ حدّك.

يظهر خطأ «Prompt is too long» في Claude Code عندما يتجاوز إجمالي المدخل، بما فيه السجل والملفات ونتائج الأدوات، حد السياق. يميز المقال بين تلخيص سجل طويل، وتقليل مدخل أول كبير، ومعالجة سبب فشل التلخيص مثل خطأ المصادقة. تُحمّل تعريفات MCP عند الطلب افتراضيًا، ويعتمد توفر سياق 1M على النموذج وطريقة الاتصال والخطة. ويشرح أيضًا عدّ الرموز وأسباب توقف التوليد عند استخدام API مباشرة.

عندما لا يتصل خادم MCP في Claude Code، افحص الحالة وطريقة الاتصال وتفاصيل Issue معًا. قد تشير failed إلى فشل تشغيل stdio أو فشل اتصال HTTP أو رفض ترويسة مصادقة ثابتة. يشرح المقال معنى Connection closed، ومتغيرات البيئة والمراجع غير المعرّفة، وإعدادات المشروع والموافقة، وتشغيل npx على Windows، وسجلات التصحيح، واختبار العملية المطلوبة بعد إعادة الاتصال. ويوضح أن صفر أدوات ليس بالضرورة خطأ، وأن التشغيل المستقل لا يضمن نجاح اتصال MCP.

حين تظهر كلمة «court» ووسوم <invoke>/<parameter> الخام في Claude Code دون أن تُنفَّذ الأداة، فهذه ليست مشكلة في بيئتك بل خلل من جانب النموذج يفسد رمز التحكّم في لحظة التوليد. يرفضه الهيكل بنمط fail-closed فلا خطر من تشغيل أمر خاطئ، لكن بقاء الكتلة المكسورة في السجلّ يجعل النموذج يقلّدها فيتسلسل الفشل. القاعدة: أخفِق مرتين ثم اهرب إلى جلسة جديدة (‎/clear). يشرح المقال الآلية والأسباب وإصلاحات المستخدم والمطوّر وتمييزها عن الأخطاء المشابهة والموقف الرسمي.

قد يُوقف حسابك في ChatGPT أو Claude دون نية سيئة، والعودة بحساب آخر تزيد الأمر سوءًا. قرأنا كاملةً حتى 4 أكتوبر 2026 شروط OpenAI ‏(ChatGPT وCodex) وAnthropic ‏(Claude وClaude Code) — Terms of Use وUsage Policies وConsumer Terms وUsage Policy — ومراكز المساعدة، وشرحنا: أسباب الإيقاف التي تعلنها كل شركة؛ وما لا يجب فعله مع البند الخاص بكل حالة (مشاركة الحساب، أتمتة الواجهة، كسر القيود، التحايل على الحظر، استخدام Claude من بلد غير مدعوم عبر VPN، التقطير، إعادة البيع، إنشاء الحسابات بالجملة)؛ وكيف تغيّرت صياغة Anthropic بين فبراير 2026 واليوم بشأن استخدام تسجيل دخول الخطة الشخصية في أدوات أخرى (تشغيلك أنت لـAgent SDK متوقع، وتسليم الرموز لخدمة شخص آخر محظور)؛ والتحذيرات والتحقّقات التي لا تعني مخالفة؛ والفصل بين امتلاك عدة حسابات وطريقة استخدامها (تحديث 9 أكتوبر: أداة التبديل الرسمية لدى OpenAI، وحدّ التحقق بالهاتف لدى Anthropic، ولماذا يحتاج التبديل اليدوي بعد بلوغ حدّ الاستخدام إلى إجابة عن الحالة المحددة، وكيف يختلف عن المشاركة وإعادة البيع والتحايل على الحظر)؛ وقائمة تحقق من ثماني نقاط؛ وخطوات الاعتراض (OpenAI: رابط الرسالة أو openai.com/form/appeal؛ Anthropic: تسجيل الدخول إلى claude.ai بالحساب المحظور؛ التحذيرات: usersafety@anthropic.com).

إعادة تدريب ذكاء اصطناعي ضخم من الصفر مكلفة للغاية، لكنك تريد تعديله ليناسبك فقط؛ يحقق LoRA (Low-Rank Adaptation) هذه الأمنية بتجميد النموذج الأصلي وتدريب جزء إضافي صغير (محوّل) فقط، مقلّصًا المعاملات القابلة للتدريب إلى أقل من 1% من النموذج الأصلي. يجعل LoRA عملية fine-tuning أرخص وأسرع بكثير، وهو شائع جدًا في توليد الصور مثل Stable Diffusion بوصفه ملفًا صغيرًا يضيف شخصية أو أسلوبًا. يشرح هذا المقال الفكرة عبر تشبيه الرقعة. LoRA رائد fine-tuning كفؤ المعاملات (PEFT): اترك الأوزان الأصلية الضخمة مجمّدة، وأدرج مصفوفة إضافية صغيرة في كل طبقة، ودرّب تلك فقط (W = W0 + BA)؛ ويقوم على فرضية أن الرتبة المنخفضة تكفي، وقد دعمتها تجارب الورقة الأصلية (مع تقارير بأنه يتأخر عن التدريب الكامل في الرياضيات والبرمجة). من فوائده: معاملات أقل من 1% من الأصل (نحو جزء من عشرة آلاف مع GPT-3 175B في الورقة الأصلية)، وذاكرة GPU أقل أثناء التدريب (من 1.2TB إلى 350GB في التجربة نفسها)، وتدريب أسرع وأرخص، ودون زمن استجابة إضافي بعد دمج المحوّل، ونسيان أقل للقدرات الأصلية. أكبر قوته هي المحوّلات القابلة للتبديل: أبقِ أساسًا مشتركًا واحدًا وبدّل ملفات LoRA الصغيرة لكل حالة استخدام فوريًا. يلتقي كثيرون بـ LoRA أولًا في توليد الصور حيث تُشارَك LoRA الخاصة بـ Stable Diffusion التي تعلّمت شخصية أو أسلوبًا. يدمج QLoRA الـ quantization، فيدرّب LoRA فوق أساس 4-bit، مما يتيح fine-tuning نموذج 65B — الذي يتطلب أكثر من 780GB عند تدريبه بالكامل بدقة 16-bit — على GPU واحدة بسعة 48GB، ونموذج 33B على GPU استهلاكية بسعة 24GB، بنتائج مماثلة للطرق بدقة 16-bit في مقارنات الورقة (والورقة نفسها تذكر أنها لم تتحقق من مضاهاة 33B و65B للتدريب الكامل). ومقابل fine-tuning الكامل، يكفي LoRA لمعظم العمل. الأرقام مأخوذة من ظروف تجارب الورقة الأصلية وغيرها وهي إرشادية.

نموذج ضخم بحجم 70B يعمل على حاسوب منزلي واحد بدل رفّ من بطاقات GPU في مركز بيانات (مع إسناد ما لا تتسع له بطاقة 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% من الأوزان، وتفوّقه على GPTQ يختلف بحسب التقييم)، وGGUF (صيغة llama.cpp/Ollama، من Q2_K إلى Q8_0، مزج CPU+GPU، للتشغيل المحلي)، وQLoRA (أساس 4-bit مع LoRA للضبط الدقيق على GPU استهلاكي). يختلف عن التقطير (الانتقال إلى نموذج أصغر منفصل) والضبط الدقيق (إضافة معرفة المهمة)، وتُستخدم الثلاثة عادةً مجتمعة. للبدء، شغّل نموذج GGUF بـOllama بأمر واحد، واختر Q4/Q8 حسب VRAM، وتجنّب INT4 للشيفرة أو الحساب الدقيق. معظم النماذج الرئيسية تُوزَّع مُكمَّمة سلفاً فتنزّلها وتستخدمها فقط. احتفظ بالذكاء وأسقط الوزن فقط.

الذكاء الاصطناعي الضخم وعالي الأداء ذكي لكنه ثقيل ومكلف؛ ويحل تقطير النماذج (تقطير المعرفة) ذلك بنقل معرفة نموذج معلّم كبير إلى نموذج طالب صغير، مع الحفاظ على أداء قريب من المعلّم بحجم أصغر بكثير وسرعة أكبر. يشرح المقال ذلك بتشبيه المعلّم والطالب. المفتاح هو الـ soft labels: التدريب العادي يُعلّم فقط «الجواب قطة» (hard label)، بينما يمرّر التقطير توزيع الاحتمالات الكامل للمعلّم مثل «90% قطة، 8% كلب، 2% ثعلب»، حيث تحمل درجة التردد معلومات غنية؛ ويقوم معامل temperature بتليين الاحتمالات لكشف العلاقات الدقيقة (مثال واقعي: ميزة OpenAI في واجهتها البرمجية عام 2024 لتدريب نماذج صغيرة على مخرجات نماذج كبيرة). الفوائد: سريع ورخيص، أصغر بكثير مع أداء قريب من المعلّم (TinyBERT أصغر بـ7.5 مرة مع أكثر من 96.8%)، يعمل على الـ edge، وقوي في التخصص. منهجان: white-box (وصول كامل للأوزان والتمثيلات الداخلية، نقل أعمق؛ لنماذجك أو نماذج OSS) و black-box (المخرجات/استجابات API فقط؛ استخدام API شركة أخرى كمعلّم قد يخالف الشروط). ويختلف عن quantization (ضغط دقة أوزان النموذج نفسه) و fine-tuning (مواصلة تدريب نموذج موجود لمهمة) — فالتقطير ينقل المعرفة إلى نموذج صغير منفصل، والثلاثة قابلة للدمج. كان الواقع القانوني وشروط الخدمة قضية كبيرة في 2026: التقنية مشروعة، لكن لدى OpenAI و Anthropic و xAI بنود منع تقطير منافس تحظر استخدام المخرجات لبناء نماذج منافسة. نزاع OpenAI ضد DeepSeek يُظهر أن التقييم يعتمد على شروط API مَن تنطبق، وتحوّل Claude Fable 5/Mythos 5 الطلبات المُصنّفة كتقطير إلى نموذج Opus أقل قدرة. نصائح: استخدم نماذجك أو نماذج 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 قبل الإطلاق. للأنظمة متعددة الوكلاء المراقبة ضرورية لأن الإخفاقات تختبئ في سلاسل متعددة الخطوات.

الجزء العملي التالي لمقال «ما هو نظام الوكلاء المتعددين؟». القاعدة الأساسية: ابنِ بوكيل واحد أولاً ولا تُضِف وكلاء إلا بأقل قدر بعد الاصطدام بحدّ فعلي (وجدت دراسة من Google Research أن جميع تكوينات الوكلاء المتعددين كانت أسوأ بنسبة 39–70% في مهمة تسلسلية صارمة، وتذكر Anthropic أن أنظمة الوكلاء المتعددين تستهلك نحو 15 ضعف رموز المحادثة). الشكل الأساسي هو نمط supervisor: الوكلاء الفرعيون في Claude Agent SDK، وagents as tools في OpenAI Agents SDK. إلى جانب الخطوات الخمس (التقسيم، تعريف الـ workers، تصميم الـ supervisor، التسليم، القياس)، يقدّم المقال شيفرة مصغّرة للحزمتين وفق وثائقهما الرسمية (supervisor واحد مع باحث ومراجع)، وطريقة تقييد أدوات كل دور، وحدوداً في ثلاث طبقات (maxTurns وmax_turns والإنفاق)، ومتى تختار التسليم، والتقسيم الجيد والسيئ للأدوار، وإخفاقات واجهتها Anthropic فعلاً (50 وكيلاً فرعياً لسؤال بسيط، بحث مكرر) مع حلولها.

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