ما هي صيغة JSONL؟ وكيف تختلف JSONL عن JSON و CSV؟ ولماذا يُعد ضبط نماذج الذكاء الاصطناعي (Fine-Tuning) مستحيلاً بدون JSONL!

Sat, 01 Aug 2026 14:05:42 +0800

جميعنا يعرف صيغتي JSON و CSV جيدًا، ولكن هل واجهت يومًا استهلاكًا مفرطًا للذاكرة أدى إلى انهيار البرنامج أثناء معالجة ملف JSON ضخم بحجم عدة جيجابايت؟ أو وجدت أن الترميز الخاص (escaping) أثناء تسجيل البيانات المتداخلة متعددة المستويات في CSV أمر في غاية الصعوبة؟

في مجال تدريب الذكاء الاصطناعي الحديث ومعالجة البيانات الضخمة، هناك صيغة بيانات أصبحت بهدوء المعيار الرئيسي، وهي JSONL (JSON Lines).

القيمة الجوهرية لـ JSONL: حل المشكلتين الكبريين في JSON التقليدي (عدم القدرة على القراءة التدفقية) و CSV (عدم دعم الهياكل المتداخلة)!

ما هي JSONL؟ افهم التعريف الأساسي “كائن JSON واحد في كل سطر” في دقيقة واحدة

الاسم الكامل لـ JSONL هو JSON Lines (ويُطلق عليها أحيانًا NDJSON اختصارًا لـ Newline Delimited JSON). مفهومها الأساسي مباشر جدًا: كل سطر عبارة عن كائن JSON مستقل وكامل.

في ملفات JSON التقليدية، يحتوي المستوى الخارجي عادةً على أقواس مربعة ضخمة [] تغلف جميع البيانات، ويجب الفصل بين الكائنات بفواصل ,. بينما تتخلى JSONL تمامًا عن الأقواس المربعة والفواصل الخارجية، وتستخدم رمز السطر الجديد \n للفصل بين كل سجل.

مقارنة بين 3 صيغ بيانات شائعة

لتوضيح الفكرة بشكل أكثر إدراكًا، لنقارن بين JSONL و JSON و CSV معًا:

صيغة البيانات	هيكل التنسيق	دعم البيانات المتداخلة	القراءة/الكتابة التدفقية (Streaming)	السيناريو المناسب
JSON	تسلسل هرمي شجري فردي، يجب تحميله دفعة واحدة	دعم أصلي	صعب (يتطلب تحميل الملف بالكامل)	نقل `Web API`، ملفات التكوين
CSV	جدول مستوٍ ثنائي الأبعاد، تفصل الأعمدة بفواصل	صعب (يتطلب ترميزًا خاصًا)	دعم أصلي	تقارير Excel، البيانات المستوية
JSONL	كائن JSON مستقل في كل سطر، يفصل بسطر جديد	دعم أصلي	ممتاز جدًا (قراءة وإضافة سطر بسطر)	مجموعات بيانات تدريب الذكاء الاصطناعي، سجلات `Log` الضخمة

لماذا يفضل تدريب نماذج الذكاء الاصطناعي و ETL للبيانات الضخمة صيغة JSONL؟

في السنوات الأخيرة، مع صعود نماذج اللغة الكبيرة (LLMs) مثل OpenAI و Anthropic، أصبحت JSONL الخيار الأول للضبط الدقيق (Fine-tuning) وإعداد مجموعات البيانات. ويرجع ذلك إلى ميزتين رئيسيتين:

1. استهلاك منخفض جدًا للذاكرة (يدعم المعالجة التدفقية Streaming)

عندما تصل قاعدة بيانات التدريب الخاصة بك إلى 50 جيجابايت، إذا كانت ملف JSON تقليديًا، يجب على البرنامج قراءة ملف 50 جيجابايت بالكامل في الذاكرة لتحليل شجرة بناء الجملة، مما يتسبب فورًا في خطأ نفاد الذاكرة (OOM).

في المقابل، تدعم JSONL القراءة التدفقية سطرًا بسطر (Line-by-line Streaming). يحتاج البرنامج فقط إلى قراءة سطر واحد في كل مرة (قد يكون بضعة كيلوبايت فقط)، وتحرير الذاكرة بعد المعالجة، ثم قراءة السطر التالي.

  flowchart TD
    subgraph TraditionalJSON["طريقة قراءة JSON التقليدية"]
        A1["قراءة ملف JSON بحجم 50 جيجابايت"] --> A2["تحليل شجرة القواعد للملف بالكامل"]
        A2 --> A3["تحميل 50 جيجابايت في الذاكرة دفعة واحدة"]
        A3 -->|مخاطرة عالية| A4["انهيار بسبب نفاد الذاكرة (OOM)"]
    end

    subgraph JSONLStreaming["طريقة قراءة JSONL التدفقية"]
        B1["فتح ملف JSONL بحجم 50 جيجابايت"] --> B2["قراءة السطر 1 (5 كيلوبايت)"]
        B2 --> B3["تحليل ومعالجة سجل واحد"]
        B3 --> B4["تحرير الذاكرة وقراءة السطر التالي"]
        B4 --> B5["إكمال معالجة البيانات الضخمة باستقرار وكفاءة"]
    end

بالنسبة للبيانات الضخمة، تخفض JSONL استهلاك الذاكرة من O(N) إلى O(1)!

2. دعم الإضافة بدون قفل (Append-Only Logging)

في الأنظمة الموزعة أو سيناريوهات تجميع السجلات، إذا كنت تريد إضافة بيانات في نهاية الملف:

JSON التقليدي: يجب قراءة الملف بالكامل، وإزالة القوس ] في النهاية، وإضافة فاصلة ,، وكتابة البيانات الجديدة ثم إعادة إغلاق القوس ].
JSONL: يمكنك ببساطة إلحاق (append) السلسلة النصية مباشرة مع رمز السطر الجديد \n في نهاية الملف لإكمال الكتابة.

3. المعالجة المتوازية للبيانات الضخمة (Parallel Processing)

نظرًا لأن كل سطر في JSONL هو كائن JSON مستقل، يمكن تقسيم الملفات الكبيرة عند أي رمز سطر جديد إلى كتل أصغر وإرسالها إلى معالجات متعددة أو نود حسابية للمعالجة المتوازية دون أن تتداخل مع بعضها البعض.

5 قواعد تنظيمية صارمة في JSONL يجب على كل مطور معرفتها

رغم أن JSONL تتمتع بمرونة عالية، إلا أنه لضمان قدرة المحللات البرمجية على قراءتها بسلاسة، حددت المواصفات الرسمية (jsonlines.org) 5 قيود تنظيمية صارمة:

شرح تفصيلي للمواصفات

رقم القاعدة	البند الصارم	الشرح والتطبيق الصحيح
القاعدة 1	يجب أن يكون كل سطر JSON صالحة	يجب أن يكون كل سطر يتم استخراجه بشكل مستقل قابلًا للتحليل بواسطة `JSON.parse()` القياسي.
القاعدة 2	يحظر وجود سطور جديدة غير مسبوقة برمز هروب	إذا نصت السلسلة على سطر جديد، يجب تحويلها إلى `\n`؛ ويحظر التنسيق متعدد السطور.
القاعدة 3	يحظر استخدام الأقواس الخارجية	يمنع تمامًا استخدام الأقواس المربعة الخارجية `[]`، ولا يجوز وضع فواصل `,` بين السطور.
القاعدة 4	ترميز UTF-8 بدون BOM	يجب استخدام ترميز `UTF-8` بصرامة ولا يجوز أن يحتوي على رأس BOM.
القاعدة 5	لا تحتوي على أسطر فارغة افتراضيًا	يجب أن يحتوي كل سطر على بيانات صالحة؛ ويُسمح فقط للسطر الأخير في الملف بسطر فارغ نهائي.

التحليل العلمي: كيف تكتب كود قراءة JSONL عالي الدفاعية؟

في التطوير المحلي، نظرًا لأن JSONL تفتقر إلى هيكل ثابت (Schema-less)، قد تختلف المفاتيح (Keys) تمامًا في السطور المختلفة. عند كتابة كود التحليل، يُوصى باتباع المبادئ الدفاعية التالية:

مثال لكود دفاعي (Python)

import json

def process_jsonl_file(file_path):
    with open(file_path, "r", encoding="utf-8") as f:
        for line_num, line in enumerate(f, 1):
            # 1. تخطي السطور الفارغة تلقائيًا (لمنع فشل التحليل)
            line = line.strip()
            if not line:
                continue
            
            try:
                data = json.loads(line)
                
                # 2. استخراج القيم بدفاعية: استخدام .get() لتجنب KeyError
                user_id = data.get("id")
                user_name = data.get("name", "Unknown")
                
                # 3. تحديد نوع الحقل (معالجة البيانات متعددة الأشكال)
                doc_type = data.get("type", "default")
                
                print(f"Line {line_num}: [{doc_type}] {user_id} - {user_name}")
                
            except json.JSONDecodeError as e:
                print(f"Error parsing line {line_num}: {e}")

# تنفيذ القراءة
process_jsonl_file("dataset.jsonl")

نصيحة دفاعية رئيسية: استخدام strip() لإزالة المسافات في البداية والنهاية، واستخدام .get() بدلاً من الوصول المباشر للمفاتيح يمنع أكثر من 90% من انهيارات وقت التشغيل!

دليل اختيار السيناريو بين JSONL و JSON و CSV

بعد التعرف على الميزات القوية لـ JSONL، هل يجب تحويل جميع البيانات إلى JSONL؟ الإجابة هي: يعتمد ذلك على سيناريو الاستخدام!

متطلبات السيناريو	الصيغة الموصى بها	سبب الاختيار
نقل API بين واجهة المستخدم والخلفية	JSON	دعم المتصفح الأصلي عالي، وحجم البيانات في النقل الموحد مناسب.
تصدير البيانات لغير التقنيين / التسويق	CSV	يمكن فتحها وعرضها مباشرة باستخدام `Excel`.
الضبط الدقيق لنماذج الذكاء الاصطناعي (Fine-tuning)	JSONL	الصيغة الرسمية المحددة لتدريب واجهات برمجة تطبيقات `OpenAI` / `Anthropic`.
تسجيل السجلات الضخمة للنظام	JSONL	تكلفة كتابة منخفضة، وتدعم الإضافة غير المحدودة ومراقبة ذاكرة منخفضة للغاية.
خطوط أنابيب البيانات الضخمة ETL	JSONL	مريحة للتقسيم الموزع والمعالجة المتوازية.

طالما أنك تتقن خصائص كل صيغة وتختار الأداة المناسبة للسيناريو الصحيح، ستتحسن كفاءة معالجة البيانات لديك بشكل كبير!

JSON on Dev TLDRLSS