التصنيف: ezformatter

فشل استدعاء الـ API للتو مع JSONDecodeError: Expecting property name enclosed in double quotes. الوقت يدق. البيانات قادمة من LLM، وفي مكانٍ ما داخل ذلك الرد المكوّن من 2000 رمز، فاصلة زائدة واحدة ألحقت كامل خط المعالجة لديك.

حتى مايو 2026، أسرع طريقة لـ إصلاح ملفات JSON التالفة هي استخدام مكتبات آلية مثل json_repair (لـ Python) أو jsonrepair (لـ npm). صُمّمت هذه الأدوات خصيصًا لإصلاح أخطاء الصياغة الناتجة عن LLM فورًا. أما الإصلاحات اليدوية، فالمتهمون المعتادون هم الفواصل الزائدة، أو علامات الاقتباس المفردة، أو المفاتيح غير المقتبة — وهي أكثر ثلاثة انتهاكات شيوعًا لمعيار RFC 8259.

الإصلاح الأسرع: json_repair لمخرجات LLM

المحلّلات القياسية مثل json.loads() في Python صارمة بالتصميم. حرفٌ واحد في غير موضعه يطلق JSONDecodeError ويتوقف كل شيء. هذه مشكلة يومية في عام 2026 لأن نماذج LLM غالبًا ما تلفّ JSON داخل نصٍّ حواري، أو تقطع الاستجابة في منتصف الجملة، أو تنثر تعليقات تكسر المواصفات.

مكتبة json_repair هي الحل المفضل. وفقًا لـ GitHub، حصد هذا المشروع أكثر من 4700 نجمة حتى عام 2026. تعمل عبر “تخمين” نيّة السلسلة النصية — إغلاق الأقواس المفقودة، وإضافة علامات الاقتباس، وإزالة النصوص الزائدة حول كتلة JSON.

Python: قبل وبعد

التثبيت: pip install json-repair

الإدخال التالف:

import json_repair

bad_json = '{"user": "Alice", "status": tru'
decoded_object = json_repair.loads(bad_json)

ماذا حدث خلف الكواليس: أدرك json_repair أن tru كانت على الأرجح true، وأضاف القوس المغلق المفقود، وأرجع قاموسًا صالحًا في Python. تدخّل يدوي صفري.

وضع الإنقاذ: عندما تكون البيانات سيئة حقًّا

للحالات الأصعب، تتضمّن json_repair (الإصدار v0.59.5+) Salvage Mode (وضع الإنقاذ). كما هو موضّح في وثائق المشروع، بُني هذا الوضع تحديدًا للاستجابات المقطوعة للذكاء الاصطناعي أو السجلات التالفة. يمكنه تحويل المصفوفات قسرًا إلى كائنات أو حذف العناصر التي يستحيل إنقاذها، مما يضمن ملاءمة المخرجات لمخطّطك.

import json_repair

# Salvage mode for severely truncated data
result = json_repair.loads(
    '{"items": [{"id": 1, "name": "Widget"}, {"id": 2, "na',
    salvage_mode=True
)
# Result: {'items': [{'id': 1, 'name': 'Widget'}, {'id': 2}]}
# Dropped the incomplete 'na' but saved everything else

بديل npm

لمشاريع Node.js، تقوم أداة jsonrepair CLI بنفس المهمة:

# Fix a file in place
npx jsonrepair broken.json > fixed.json

# Fix a string in a script
const { jsonrepair } = require('jsonrepair');
const fixed = jsonrepair('{"name": "test",}');

التصحيح اليدوي: العثور على ما كسر المواصفات

عندما لا تكفي الأتمتة، عليك تحديد الموضع الذي ينتهك فيه الملف RFC 8259 بدقة. JSON أقل تساهلًا بكثير من YAML أو JavaScript. كما يشرح فريق تشخيص JSONParser: “يفشل المحلّل عند أول حرف لا يستطيع فهمه، وهو غالبًا عرضٌ ناتج لمشكلة تقع قبل ذلك بأسطر.”

قتلة JSON الثلاثة

القاتل 1: الفواصل الزائدة

وفقًا لـ DEV Community، الفواصل الزائدة هي السبب الأول لفشل التحليل. لا بأس بها في JavaScript لكنها غير قانونية بعد العنصر الأخير في مصفوفة أو كائن JSON.

// BROKEN - trailing comma after "active"
{
  "name": "Alice",
  "status": "active",
}

// FIXED - no comma before closing brace
{
  "name": "Alice",
  "status": "active"
}

القاتل 2: علامات الاقتباس المفردة

يتطلّب JSON علامات اقتباس مزدوجة (") لكلٍّ من المفاتيح وقيم السلاسل النصية. كثير من مطوّري Python و JavaScript يستخدمون عن طريق الخطأ علامات اقتباس مفردة ('). كما يلخّص TidyCode، هذا تصحيح إلزامي.

// BROKEN - single quotes
{'name': 'Alice'}

// FIXED - double quotes
{"name": "Alice"}

القاتل 3: المفاتيح غير المقتبة

في JavaScript يمكنك كتابة { name: "Alice" }. أما في JSON، فكل مفتاح يحتاج إلى علامتي اقتباس مزدوجتين.

// BROKEN - unquoted key
{name: "Alice"}

// FIXED - quoted key
{"name": "Alice"}

خطأ “Unexpected Token”

عندما يُبلغ مدقّق عن “Unexpected Token”، فهذا يعني أن المحلّل صادف NaN أو Infinity أو undefined — وهي ثوابت JavaScript لا يدعمها JSON. يسمح JSON فقط بـ null و true و false والأرقام.

// BROKEN - NaN is not valid JSON
{"score": NaN, "result": Infinity}

// FIXED - replace with null or valid values
{"score": null, "result": null}

التحليل الصارم مقابل تحليل الإصلاح: متى تستخدم كلًّا منهما

النهج الصحيح يعتمد على مصدر بياناتك. ملفات الإعداد التي يحرّرها البشر تستحق تحليلًا صارمًا لإجبار الكاتب على إصلاح أخطائه. أمّا البيانات المولّدة آليًا من LLM أو سجلات API فتحتاج تحليلًا قائمًا على الإصلاح.

الميزة	صارم (json.loads)	إصلاح (json_repair)
الفواصل الزائدة	يطلق JSONDecodeError	تُزال تلقائيًا
علامات الاقتباس المفردة	يفشل	تُحوَّل إلى علامات مزدوجة
البيانات المقطوعة	يفشل	يُغلق الأقواس/الاقتباسات المفتوحة
التعليقات	يفشل	تُزال تلقائيًا
أفضل حالة استخدام	ملفات إعداد يحرّرها البشر	مخرجات LLM، سجلات API

إصلاحات موجَّهة بالمخطّط باستخدام Pydantic

يمكنك توجيه عملية الإصلاح باستخدام Pydantic v2 أو JSON Schema. بإعطاء json_repair مخطّطًا، تقوم الأداة بأكثر من مجرد إصلاح الصياغة — يمكنها تصحيح الأنواع (تحويل السلسلة "1" إلى الرقم 1) وملء الحقول المطلوبة المفقودة بقيم افتراضية.

from pydantic import BaseModel
import json_repair

class User(BaseModel):
    id: int
    name: str
    active: bool = True

# Broken JSON with wrong types
raw = '{"id": "42", "name": "Alice"}'
repaired = json_repair.loads(raw)

# Validate against schema
user = User(**repaired)
# user.id is now int(42), user.active defaults to True

كما أشار Stefano Baccianella في إسناده للمشروع عام 2025، تم تحسين هذا النهج لـ JSON “الصحيح في معظمه لكنه غير صالح تقنيًا” والذي تميل نماذج اللغة إلى إنتاجه.

التعامل مع ملفات بحجم غيغابايت دون انهيار

إصلاح مقطع بحجم 10KB أمر سهل. أمّا إصلاح ملف بحجم 2GB فيتطلّب استراتيجية لن تستهلك ذاكرتك كلها. تحميل الملف بأكمله في الذاكرة يسبّب أخطاء نفاد الذاكرة (OOM).

الاستراتيجية 1: البثّ باستخدام ijson

للبيانات الضخمة، استخدم ijson لمعالجة البيانات قطعة بقطعة. كما يذكر Scrapfly، يعالج ijson البيانات بشكل تزايدي. اقرنه بنص برمجي للتنظيف يصلح المشاكل سطرًا بسطر قبل التحليل.

import ijson

# Stream through a large JSON file
with open('huge_broken.json', 'r') as f:
    for item in ijson.items(f, 'records.item'):
        # Process each item individually
        process(item)

الاستراتيجية 2: أنبوب CLI لأقصى كفاءة

النهج الأوفر للذاكرة مع الملفات الكبيرة هو استخدام jsonrepair CLI وتوجيه المخرجات مباشرةً إلى ملف جديد:

# Streams repair, never loads full file into memory
jsonrepair large_broken.json > fixed.json

هذا أوفر للذاكرة بكثير من تحميل الملف إلى Python أو متصفّح.

الخاتمة

إصلاح JSON التالف لم يعد مهمة يدوية بفضل المكتبات المدركة للذكاء الاصطناعي مثل json_repair. ما زلت بحاجة لفهم أساسيات RFC 8259 — لا فواصل زائدة، ولا علامات اقتباس مفردة، ولا مفاتيح غير مقتبة — لكن الأتمتة هي النهج العملي الوحيد مع البيانات في حجم عام 2026.

سير العمل بسيط: جرّب مكتبة إصلاح أولًا. إن فشلت، استخدم مدقّقًا لتحديد خطأ الصياغة بالضبط. هذا يبقي تطبيقاتك قيد التشغيل حتى حين تكون البيانات الواردة أقل من الكمال.

الأسئلة الشائعة

هل يدعم JSON رسميًا التعليقات أو علامات الاقتباس المفردة؟

لا. يمنع معيار RFC 8259 التعليقات بصرامة. علامات الاقتباس المفردة غير صالحة أيضًا — يُسمح فقط بعلامات الاقتباس المزدوجة للمفاتيح والسلاسل النصية. ومع ذلك، يمكن لأدوات مثل json_repair إزالة التعليقات وتحويل علامات الاقتباس تلقائيًا لجعل الملفات قابلة للتحليل بالمكتبات القياسية.

كيف أتعامل مع ملفات JSON تالفة وكبيرة جدًّا دون انهيار؟

استخدم محلّلًا تدفقيًا مثل ijson لمعالجة البيانات في أجزاء. تجنّب تحميل السلسلة التالفة بأكملها في متغيّر واحد. للحصول على أسرع النتائج، استخدم أدوات إصلاح CLI التي توجّه المخرجات مباشرةً إلى ملف جديد على القرص دون الاحتفاظ بكل شيء في الذاكرة.

ما الفرق بين JSON التالف و JSON غير الصالح؟

JSON التالف ينتهك قواعد الصياغة — أقواس مفقودة، مفاتيح غير مقتبة، فواصل زائدة — مما يجعل تحليله مستحيلًا. أما JSON غير الصالح فيتبع كل قواعد الصياغة لكنه يفشل في مطابقة JSON Schema محدّد (مثلًا، حقل نصي بينما يتوقّع المخطّط عددًا صحيحًا). إصلاح JSON التالف هو إصلاح بنيوي؛ وإصلاح JSON غير الصالح يتعلّق بسلامة البيانات.

هل يمكنني استخدام json_repair مع التحقق من Pydantic؟

نعم. شغّل json_repair.loads() أولًا لإصلاح أخطاء الصياغة، ثم مرّر القاموس المُصلَح إلى نموذج Pydantic للتحقق من الأنواع وفرض المخطّط. هذا النهج من خطوتين يعالج كلًّا من المشاكل البنيوية والمعنوية.

ماذا عن JSON مع تعليقات بأسلوب JavaScript؟

JSON القياسي لا يدعم التعليقات، لكن json_repair يمكنه إزالة تعليقات // و /* */ تلقائيًا. إن كنت تحتاج تعليقات في ملفات الإعداد، فكّر في استخدام صيغة JSONC (JSON مع تعليقات) ومحلّل متوافق مثل json5 لـ Python.

تعرف ذلك الشعور المخيب عندما تبدو مخرجات الذكاء الاصطناعي لا تشبه أبدًا ما طلبته؟ ملف JSON تالف، والنبرة خاطئة، ونصف تعليماتك تم تجاهلها. المشكلة ليست في النموذج — بل في كيفية تنسيقك للتوجيه.

لإتقان كيفية كتابة توجيهات الذكاء الاصطناعي باستخدام مُنسِّق، طبِّق إطار عمل RTCCO (الدور Role، المهمة Task، السياق Context، القيود Constraints، المخرجات Output) باستخدام فواصل منظَّمة مثل XML أو JSON. يعامل هذا التوجيهات كأصول برمجية معيارية، مما يمكن أن يقلل هلوسة النموذج بنسبة تصل إلى 60% ويختصر وقت المعالجة اليدوية بنسبة 75% وذلك حتى مايو 2026.

لماذا تفشل التوجيهات الفقرية باستمرار

بحلول عام 2026، تحوَّل العمل المهني بالذكاء الاصطناعي من «الدردشة» إلى التوجيه-ككود (Prompt-as-Code، PaC). تكمن مشكلة التوجيهات الفقرية — تلك الكتل النصية الطويلة غير المنظَّمة — في أن النماذج تكافح لفصل تعليماتك الفعلية عن بيانات الخلفية أو متطلبات المخرجات المختلطة معها.

تُظهر بيانات PromptOT أن التحول إلى الهندسة المنظَّمة يمكن أن يقلل الأخطاء بنسبة 60% ويسرِّع المعالجة اليدوية بنسبة 75%. يصف Alex Ostlovskxx التوجيهات المضمَّنة في الكود بأنها «المكافئ الحديث للأرقام السحرية في الشيفرة المصدرية» — أنظمة هشة يستحيل تقريبًا تحديثها دون كسر شيء ما.

قبل وبعد: فارق التنسيق

قبل (غير منظَّم):

You are a helpful coding assistant. Please write a Python function that validates
email addresses. Make sure it handles edge cases like plus signs and subdomains.
The output should be in JSON format with a valid boolean and the cleaned email.
Also make sure you add proper error handling and don't forget logging.

بعد (RTCCO + فواصل XML):

<system_instructions>
  <role>Senior Python engineer specializing in input validation</role>
  <primary_objective>Write a production-grade email validator</primary_objective>
</system_instructions>

<context>
  Must handle: plus addressing ([email protected]), subdomains,
  internationalized domains. Target: Python 3.11+.
</context>

<task_requirements>
  <rules>
    - Use only stdlib (no regex shortcuts)
    - Return structured JSON
    - Include type hints
  </rules>
  <steps>
    1. Parse the input string
    2. Validate format per RFC 5322
    3. Return JSON with "valid" boolean and "cleaned_email"
  </steps>
</task_requirements>

<output_format>
  {"valid": bool, "cleaned_email": str, "error": str | null}
</output_format>

الهدف ذاته، لكن بنتائج مختلفة جذريًا. النسخة المنسَّقة لا تترك للنموذج أي مساحة للغموض.

إطار عمل RTCCO: هيكل توجيهك

استقرَّت الصناعة على RTCCO باعتباره بنية التوجيه القياسية. يتفكَّك كل توجيه إلى خمسة أجزاء:

العنصر	الغرض	مثال
R الدور (Role)	مَن هو الذكاء الاصطناعي؟	«مهندس خلفية أول»
T المهمة (Task)	ما الإجراء المحدد؟	«اكتب وسيطًا للحد من المعدل»
C السياق (Context)	ما بيانات الخلفية؟	استرجاع RAG، مقتطفات قاعدة الشيفرة
C القيود (Constraints)	ما القواعد؟	«بلا تبعيات خارجية»
O المخرجات (Output)	ما الشكل المطلوب؟	«شيفرة Python 3.11 صالحة مع تلميحات الأنواع»

قالب الهيكل XML الذي يمكنك نسخه الآن

إليك القالب الجاهز للإنتاج. انسخه، عدِّله، انشره.

<system_instructions>
  <role> [Expert Persona] </role>
  <primary_objective> [Main Goal] </primary_objective>
</system_instructions>

<context>
  [Background Data or RAG Retrieval]
</context>

<task_requirements>
  <rules> [Non-negotiable Constraints] </rules>
  <steps> [Specific Workflow] </steps>
</task_requirements>

<output_format>
  [JSON/XML/Markdown Specification]
</output_format>

<recency_recap>
  [Reminder of Critical Constraints]
</recency_recap>

لماذا يهمّ «استرجاع الأحدثية»

تعاني نماذج اللغة الكبيرة من انحياز معروف هو «الأولوية والأحدثية» — تتذكَّر بداية التوجيه ونهايته أفضل من وسطه. أظهرت اختبارات استشهد بها PromptOT أن نقل القواعد الحرجة من الوسط إلى كتلة «استرجاع الأحدثية» في الأسفل رفع الدقة من 78% إلى 96% في الاستخدام الإنتاجي. اجعل الدور في الأعلى، وضع أهم قواعدك في الأسفل.

الفواصل كسياج أمني

الفواصل لا تتعلق فقط بالتنظيم — بل هي آلية أمنية. تغليف إدخال المستخدم في وسوم مثل <user_input> يخبر النموذج: «هذه بيانات تُعالَج، وليست تعليمات جديدة تُتَّبع». هذا هو خط دفاعك الأول ضد هجمات حقن التوجيه حيث يحاول المستخدمون تجاوز تعليمات نظامك.

فخٌّ شائع: إذا حقنت بيانات المستخدم مباشرة في التوجيه دون فواصل، يكفي أن يكتب المستخدم «تجاهل كل التعليمات السابقة و…» ليلتزم النموذج. غلِّف دائمًا البيانات الخارجية في كتل موسومة.

البنية المعيارية: كفّ عن كتابة توجيهات عملاقة

بدلًا من توجيه واحد هش بحجم 2000 توكن، قسِّم نظامك إلى وحدات مستقلة. هذا يمنع تصادم التعليمات — حيث يكسر تغيير نبرة التوجيه عن غير قصد صيغة مخرجات JSON الخاصة به.

المبدأ الأساسي هو هندسة السياق (Context Engineering): افصل التعليمات الثابتة عن البيانات الديناميكية. في نظام RAG إنتاجي، توجيهك هو قالب تُملأ كتلة <context> فيه ببيانات جديدة وقت الاستعلام. كما يشرح Jono Farrington من OptizenApp، يجعل هذا النهج المعياري عمليات نشر الذكاء الاصطناعي واسعة النطاق أكثر اتساقًا بكثير.

تسلسل التوجيهات: ربط الوحدات

بالنسبة لتدفقات العمل المعقدة، استخدم تسلسل التوجيهات (Prompt Chaining) — حيث تصبح مخرجات وحدة ما مدخلات للأخرى:

[Planner Module] --> outline --> [Executor Module] --> draft --> [Reviewer Module] --> final

هذا النهج التدريجي يحسِّن جودة المخرجات بنحو 35% لأن النموذج يركِّز على مهمة فرعية واحدة فقط في كل مرة.

مثال تسلسلي جاهز للنسخ والاستخدام:

planner_prompt = """
<system_instructions>
  <role>Technical architect</role>
  <task>Create a step-by-step plan for: {user_request}</task>
</system_instructions>
<output_format>JSON array of steps</output_format>
"""

executor_prompt = """
<system_instructions>
  <role>Senior developer</role>
  <task>Implement step: {step_from_planner}</task>
</system_instructions>
<context>{previous_outputs}</context>
<output_format>Code block with inline comments</output_format>
"""

إضافة سلسلة الأفكار للمسائل الصعبة

حين تتضمَّن مهمتك منطقًا معقدًا، أضِف كتلة <thought_process>. هذا يجبر النموذج على التفكير خطوة بخطوة قبل تقديم الإجابة، مما يقلل الأخطاء بشكل كبير في الرياضيات والبرمجة والاستدلال متعدد الخطوات.

<task_requirements>
  <rules>Reason inside <thought> tags before answering</rules>
</task_requirements>

<output_format>
  <thought> [Your step-by-step reasoning here] </thought>
  <answer> [Final JSON output here] </answer>
</output_format>

وفقًا لـ Zencoder، فإن تقنيات مثل شجرة الأفكار (Tree-of-Thoughts، ToT) تمدِّد ذلك إلى أبعد، إذ تطلب من النموذج تقييم مسارات حل متعددة في آنٍ واحد واختيار الأفضل. هذا ذو قيمة خاصة للقرارات المعمارية حيث لا توجد إجابة صحيحة واحدة.

تحذير بشأن تكلفة التوكنات

الاستدلال المنظَّم يستهلك توكنات أكثر. تضيف كتلة <thought_process> النموذجية 200–500 توكن لكل طلب. على نطاق واسع، يعني هذا تكاليف API أعلى. المقايضة هي الدقة: تدفع أكثر لكل طلب لكنك تحتاج إلى إعادة محاولات أقل وتصحيح يدوي أقل.

الجاهزية للإنتاج: الإصدارات والاختبار و CI/CD

الخطوة الأخيرة هي معاملة التوجيهات كبرمجيات. استخدم الإصدار الدلالي (Semantic Versioning) (مثل v1.0.0) حتى يتمكن فريقك من تتبُّع التغييرات والتراجع فورًا حين تتدهور نسخة توجيه جديدة.

تُشير تقارير PromptOT إلى أن الشركات التي تدير أكثر من 50 توجيهًا يمكنها توفير ما يصل إلى 400,000 دولار سنويًا عبر المركزية الإدارة وتقليل الوقت الذي يقضيه المهندسون في الضبط اليدوي.

إعداد خط أنابيب CI/CD للتوجيهات

# .github/workflows/prompt-tests.yml
name: Prompt Quality Gate
on: [push]
jobs:
  test-prompts:
    runs-on: ubuntu-latest
    steps:
      - name: Run Golden Dataset Tests
        run: |
          # Test against 50-200 curated cases
          python scripts/eval_prompts.py \
            --dataset golden_dataset.json \
            --judge-model gpt-4 \
            --min-score 0.85

      - name: Regression Check
        run: |
          # Compare new version vs. production
          python scripts/compare_versions.py \
            --staging v2.1.0 \
            --production v2.0.3 \
            --threshold 0.05

لا يُرقَّى التوجيه من Staging إلى Production إلا بعد اجتيازه بوابات الجودة هذه التي يسجِّلها «LLM-بوصفتِه-حَكَم».

الخاتمة

لم تعد هندسة التوجيهات المنظَّمة مع المُنسِّقات خيارًا — بل هي خط الأساس لأي شخص يبني أدوات ذكاء اصطناعي موثوقة. إطار RTCCO، وفواصل XML، والبنية المعيارية هي مجموعتك لتحويل مخرجات LLM غير المتوقعة إلى نتائج إنتاجية متسقة وموثوقة.

ابدأ بأكثر توجيهاتك استخدامًا وأعد هيكلتها في إطار RTCCO باستخدام قالب XML أعلاه. ضعها تحت التحكم في الإصدارات، وأسِّس نظام تقييم أساسي، وستحصل على بنية تحتية للتوجيهات قابلة للتوسُّع.

الأسئلة الشائعة

كيف أحوِّل توجيهاتي الفقرية الحالية إلى صيغة كتل RTCCO؟

حدِّد أولًا المهمة الأساسية وافصلها عن السياق. غلِّف التعليمات في وسوم <rules> وقدِّم 3–5 أمثلة في وسوم <examples>. يمكنك حتى الاستعانة بنموذج لغوي — وجِّهه بـ «أعد تحليل هذا النص غير المنظَّم إلى إطار RTCCO باستخدام فواصل XML» وسيقوم بالعمل الشاق.

هل أستخدم فواصل XML أم JSON أم Markdown؟

XML هو المعيار الذهبي الحالي لفصل التعليمات عن المحتوى الطويل في نماذج مثل Claude و GPT-5 بفضل تسلسله الهرمي الصارم. JSON أفضل حين تحتاج إلى إدخال/إخراج برمجي لتكاملات API. يعمل Markdown مع التوجيهات البسيطة القابلة للقراءة البشرية، لكنه يفتقر إلى تعريف الحدود الصارم الذي تحتاجه التوجيهات الإنتاجية المعقدة متعددة الطبقات.

كيف أُطبِّق اختبارات CI/CD المؤتمتة للتوجيهات؟

أنشئ مجموعة اختبار تحتوي على «مجموعة بيانات ذهبية» (50–200 حالة اختبار منتقاة) و«LLM-بوصفتِه-حَكَم» لتسجيل المخرجات وفق معايير محددة. ادمج هذه الاختبارات في خط أنابيب GitHub Actions أو Jenkins بحيث يُتحقَّق من أي تغيير في التوجيه من حيث الدقة والنبرة قبل النشر.

ما الخطأ الأكثر شيوعًا عند التحول إلى التوجيهات المنظَّمة؟

إرهاق كتلة <context> بالكثير من المحتوى. يملأ المطورون السياق بقواعد شيفرة أو مستندات كاملة، مما يُبدِّد انتباه النموذج. أبقِ السياق مركَّزًا فقط على ما يتعلق مباشرة بالمهمة. إذا احتجت إلى الإشارة إلى مستندات كبيرة، استخدم استرجاع RAG لجلب الأقسام ذات الصلة فقط.