اختبارات أداء نموذج لغوي كبير لـ Cognee المضيف الذاتي

اختبار Cognee مع نماذج LLM المحلية - نتائج حقيقية

Page content

Cognee هي إطار عمل بلغة Python لبناء مخططات المعرفة من الوثائق باستخدام LLMs. لكن هل يعمل مع النماذج المضيفة محليًا؟

لقد اختبرته مع عدة نماذج LLM محليًا لمعرفة ذلك.

cognee معالجة pdf مع procelist

هذا صفحة PDF لقائمة أسعار جربت معالجتها.

TL;DR

Cognee يعمل على الأرجح بشكل جيد مع LLMs ذكية بعشرات المليارات من المعلمات، ولكن بالنسبة لحالات RAG المضيفة محليًا المتوقعة لاستخراج البيانات تلقائيًا من ملفات PDF (مثل قوائم الأسعار)، فشل في تسليم النتائج على معداتي. الاعتماد الثقيل لم-framework على الإخراج المهيكل يجعل من الصعب على النماذج المحلية الصغيرة أداءً موثوقًا.

ما هو Cognee؟

Cognee هو إطار عمل مفتوح المصدر بلغة Python تم تصميمه لبناء مخططات المعرفة من الوثائق غير المهيكلة باستخدام LLMs. على عكس أنظمة RAG التقليدية التي تقوم فقط بتقسيم وتجسيد الوثائق، يحاول Cognee إنشاء فهم معنوي من خلال استخراج الكيانات والعلاقات والمفاهيم إلى قاعدة بيانات الرسوم. هذا النهج يتوافق مع معمارية RAG المتقدمة مثل GraphRAG، والتي تعد بتحسن في استرجاع السياق.

يدعم الإطار عدة خوادم:

  • قواعد بيانات المتجهات: LanceDB (الافتراضي)، مع دعم لقواعد بيانات المتجهات الأخرى
  • قواعد بيانات الرسوم: Kuzu (الافتراضي)، مما يسمح باستعلامات علاقات معقدة
  • مزوّجو النماذج: OpenAI، Anthropic، Ollama، وغيرها
  • إطارات الإخراج المهيكل: BAML و Instructor لإنتاج محدود

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

لماذا يهم الإخراج المهيكل

يعتمد Cognee بشكل كبير على الإخراج المهيكل لاستخراج المعلومات من الوثائق بتنسيق ثابت. عند معالجة وثيقة، يجب على النموذج أن يعيد JSON مُنسقًا يحتوي على الكيانات والعلاقات والبيانات الوصفية. هذا هو المكان الذي تواجه فيه النماذج الصغيرة صعوبة.

إذا كنت تعمل مع الإخراج المهيكل في مشاريعك الخاصة، فإن فهم هذه القيود أمر حيوي. الصعوبات التي واجهتها مع Cognee تشبه المشكلات الأوسع في نظام LLM عند العمل مع النماذج المحلية.

إعداد التكوين

إليك تكويني العامل مع Cognee و Ollama. لاحظ الإعدادات المفتاحية التي تمكّن التشغيل المحلي:

TELEMETRY_DISABLED=1

# STRUCTURED_OUTPUT_FRAMEWORK="instructor"
STRUCTURED_OUTPUT_FRAMEWORK="BAML"  

# إعدادات النموذج
LLM_API_KEY="ollama"  
LLM_MODEL="gpt-oss:20b"
LLM_PROVIDER="ollama"  
LLM_ENDPOINT="http://localhost:11434/v1"
# LLM_MAX_TOKENS="25000"


# إعدادات التمثيل
EMBEDDING_PROVIDER="ollama"  
EMBEDDING_MODEL="avr/sfr-embedding-mistral:latest"  
EMBEDDING_ENDPOINT="http://localhost:11434/api/embeddings"  
EMBEDDING_DIMENSIONS=4096  
HUGGINGFACE_TOKENIZER="Salesforce/SFR-Embedding-Mistral"  

# إعدادات BAML
BAML_LLM_PROVIDER="ollama"  
BAML_LLM_MODEL="gpt-oss:20b" 

BAML_LLM_ENDPOINT="http://localhost:11434/v1"


# إعدادات قاعدة البيانات (الافتراضية)
DB_PROVIDER="sqlite"  
VECTOR_DB_PROVIDER="lancedb"  
GRAPH_DATABASE_PROVIDER="kuzu"

# المصادقة
REQUIRE_AUTHENTICATION=False
ENABLE_BACKEND_ACCESS_CONTROL=False

خيارات التكوين المهمة

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

مزوّج النموذج: استخدام نقطة النهاية المتوافقة مع OpenAI من Ollama (/v1) يسمح لـ Cognee بالتعامل معها كخدمة OpenAI من نوع آخر.

نموذج التمثيل: نموذج SFR-Embedding-Mistral (4096 أبعاد) يوفر تمثيلات عالية الجودة. لمزيد من المعلومات حول اختيار نماذج التمثيل وأدائها، توفر نماذج Qwen3 التمثيلية خيارات ممتازة بقدرات متعددة اللغات.

قواعد البيانات: SQLite للمعلومات، LanceDB للمتجهات، و Kuzu لمخططات المعرفة تترك كل شيء محليًا دون اعتماد خارجي.

تثبيت Cognee

تثبيت Cognee سهل باستخدام uv (أو pip). أوصي باستخدام uv لحل الاعتماديات بشكل أسرع:

uv venv && source .venv/bin/activate
uv pip install cognee[ollama]
uv pip install cognee[baml]
uv pip install cognee[instructor]

uv sync --extra scraping
uv run playwright install
sudo apt-get install libavif16

الخيارات [ollama]، [baml]، و [instructor] تثبيت الاعتماديات الضرورية للتشغيل المحلي والنماذج المهيكلة. الخيار الإضافي scraping يضيف قدرات تصفح الويب، بينما Playwright يمكّن معالجة الصفحات التي تتضمن JavaScript.

مثال على الكود واستخدامه

إليك تدفق العمل الأساسي لمعالجة الوثائق مع Cognee. أولاً، نضيف الوثائق وننشئ مخطط المعرفة:

msy-add.py:

import cognee
import asyncio

async def main():

    # إنشاء بيئة نظيفة لـ cognee -- إعادة تعيين البيانات وحالة النظام
    await cognee.prune.prune_data()
    await cognee.prune.prune_system(metadata=True)
    
    # إضافة محتوى عينة
    await cognee.add(
        "/home/rg/prj/prices/msy_parts_price_20251224.pdf",
        node_set=["price_list", "computer_parts", "2025-12-24", "aud"]
    )
    
    # معالجة باستخدام LLMs لبناء مخطط المعرفة
    await cognee.cognify()

if __name__ == '__main__':
    asyncio.run(main())

المعلمة node_set توفر علامات معنوية تساعد في تصنيف الوثيقة في مخطط المعرفة. ودالة cognify() هي حيث يحدث السحر (أو المشكلات) - حيث ترسل قطع الوثيقة إلى النموذج لاستخراج الكيانات والعلاقات.

msy-search.py:

import cognee
import asyncio

async def main():

    # البحث في مخطط المعرفة
    results = await cognee.search(
        query_text="ما المنتجات الموجودة في قائمة الأسعار؟"
#       query_text="ما هو متوسط سعر ذاكرة 32GB (2x16GB modules)؟"
    )
    
    # طباعة النتائج
    for result in results:
        print(result)

if __name__ == '__main__':
    asyncio.run(main())

على عكس البحث المتجهي التقليدي في أنظمة RAG، يسأل Cognee مخطط المعرفة، مما يسمح نظريًا بإجراء استرجاع أكثر تعقيدًا بناءً على العلاقات. هذا مشابه لطريقة عمل معمارية RAG المتقدمة، لكنه يتطلب نجاح بناء المخطط أولاً.

نتائج الاختبار: أداء النماذج

لقد اختبرت Cognee مع حالة استخدام واقعية: استخراج معلومات المنتج من ملف PDF لقائمة أسعار قطع الحاسوب. بدا هذا مثل سيناريو مثالي - بيانات منظمة بتنسيق جداول. إليك ما حدث مع كل نموذج:

النماذج التي تم اختبارها

1. gpt-oss:20b (20 مليار معلمة)

  • النتيجة: فشل مع أخطاء في ترميز الحروف
  • المشكلة: عادت إخراج مهيكل مع ترميز حروف خاطئ
  • ملاحظة: على الرغم من تصميمه خصيصًا للتوافق مع النماذج المفتوحة المصدر، إلا أنه لم يتمكن من الحفاظ على تنسيق JSON متسق

2. qwen3:14b (14 مليار معلمة)

  • النتيجة: فشل في إنتاج إخراج مهيكل
  • المشكلة: النموذج سيولد النص ولكن ليس في المخطط JSON المطلوب
  • ملاحظة: تؤدي نماذج Qwen بشكل جيد عادة، ولكن هذه المهمة تجاوزت قدراتها على الإخراج المهيكل

3. deepseek-r1:14b (14 مليار معلمة)

  • النتيجة: فشل في إنتاج إخراج مهيكل
  • المشكلة: مشابه لـ qwen3، لم يتمكن من الالتزام بمتطلبات BAML
  • ملاحظة: لم تساعد قدرات التفكير في الامتثال للتنسيق

4. devstral:24b (24 مليار معلمة)

  • النتيجة: فشل في إنتاج إخراج مهيكل
  • المشكلة: حتى مع عدد معلمات أكبر، لم يتمكن من إنتاج JSON صالح باستمرار
  • ملاحظة: النموذج المتخصص في البرمجة لا يزال يواجه صعوبة في الالتزام الصارم بالتنسيق

5. ministral-3:14b (14 مليار معلمة)

  • النتيجة: فشل في إنتاج إخراج مهيكل
  • المشكلة: النموذج الأصغر من Mistral لم يتمكن من التعامل مع متطلبات الإخراج المهيكل

6. qwen3-vl:30b-a3b-instruct (30 مليار معلمة)

  • النتيجة: فشل في إنتاج إخراج مهيكل
  • المشكلة: لم تساعد القدرات البصرية في استخراج الجداول من ملفات PDF في هذا السياق

7. gpt-oss:120b (120 مليار معلمة)

  • النتيجة: لم يكتمل المعالجة بعد أكثر من 2 ساعة
  • المعدات: مجموعة معالجة متوسطة
  • المشكلة: كان النموذج كبيرًا جدًا للاستخدام المحلي العملي، حتى لو قد يعمل في النهاية

العثورات الرئيسية

قيود حجم القطعة: يستخدم Cognee قطعًا بحجم 4k توكين عند معالجة الوثائق مع Ollama. بالنسبة للوثائق المعقدة أو النماذج ذات النوافذ الأكبر، يبدو هذا مفرطًا في القيود. لا يوفر الإطار طريقة سهلة لتغيير هذا المعلمة.

متطلبات الإخراج المهيكل: لا تكمن المشكلة في ذكاء النموذج، بل في الامتثال للتنسيق. يمكن للنماذج فهم المحتوى، لكن الحفاظ على تنسيق JSON متسق خلال عملية الاستخراج يثبت صعوبته. هذا يتوافق مع التحديات الأوسع في جعل النماذج المحلية تلتزم بقيود الإخراج.

اعتبارات الأجهزة: حتى عندما يكون نموذجًا كافيًا كبيرًا (مثل gpt-oss:120b)، فإن متطلبات الأجهزة تجعله غير عملي لمعظم حالات الاستضافة المحلية. ستحتاج إلى ذاكرة GPU كبيرة وقوة معالجة.

مقارنة مع أفضل الممارسات في الإخراج المهيكل

تعزز هذه التجربة دروسًا من العمل مع الإخراج المهيكل عبر مزودي LLM المختلفة. غالبًا ما تحتوي واجهات برمجة التطبيقات التجارية من OpenAI وAnthropic وGoogle على آليات مدمجة لفرض نماذج الإخراج، بينما تتطلب النماذج المحلية نهجًا أكثر تعقيدًا مثل العينات القائمة على القواعد أو عمليات التحقق المتعددة.

لتحليل أعمق حول اختيار النموذج الصحيح لـ Cognee على Ollama، بما في ذلك مقارنات تفصيلية بين أحجام النماذج المختلفة وخصائص أدائها، هناك دليل شامل متوفر يمكنه مساعدتك في اتخاذ قرار مُدروس.

طرق بديلة لـ RAG المضيفة محليًا

إذا كنت ملتزمًا بالاستضافة المحلية وتحتاج إلى استخراج بيانات منظمة من الوثائق، ففكر في هذه البدائل:

1. RAG التقليدي مع استخراج بسيط

بدلاً من بناء مخطط المعرفة المعقد مسبقًا، استخدم RAG التقليدي مع تقسيم الوثائق وبحث المتجهات. لاستخراج البيانات المنظمة:

  • استخدم مكتبات مثل pdfplumber أو tabula-py لتحليل الجداول مباشرة
  • استخدم تحفيزات بسيطة لا تتطلب الالتزام الصارم بالنموذج
  • قم بتنفيذ التحقق المسبق في Python بدلًا من الاعتماد على تنسيق الإخراج من النموذج

2. نماذج تمثيل متخصصة

جودة تمثيلاتك تؤثر بشكل كبير على أداء الاسترجاع. فكّر في استخدام نماذج تمثيل عالية الأداء تعمل بشكل جيد محليًا. تقدم نماذج Qwen3 الحديثة دعمًا متعدد اللغات ممتازًا ويمكن أن تحسن بشكل كبير دقة نظام RAG الخاص بك.

3. إعادة الترتيب لتحسين النتائج

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

4. استراتيجيات بحث هجينة

دمج البحث المتجهي مع البحث التقليدي عبر الكلمات المفتاحية (BM25) غالبًا ما يعطي نتائج أفضل من كل منهما بمفرده. تدعم العديد من قواعد بيانات المتجهات الحديثة البحث الهجين بشكل افتراضي.

5. فكّر في خيارات قواعد المتجهات البديلة

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

اعتبارات النشر باستخدام Docker

للمشاريع التكميلية المضيفة محليًا، يبسط تحويل نظامك RAG إلى حاويات النشر والتوسع. عند تشغيل Cognee أو إطارات مشابهة مع Ollama:

# تشغيل Ollama في حاوية
docker run -d --gpus=all -v ollama:/root/.ollama -p 114线:11434 --name ollama ollama/ollama

# سحب نماذجك
docker exec -it ollama ollama pull gpt-oss:20b

# تكوين Cognee للاتصال بنقطة النهاية في الحاوية

تأكد من تكوين ممرات GPU وتركيبات الحجم بشكل صحيح للحفاظ على النماذج.

الدروس المستفادة

1. تطابق الأدوات مع الأجهزة: تم تصميم Cognee لـ LLMs المضيفة في السحابة. إذا كنت تستخدم معدات استضافة محلية، فقد تكون المعمارات البسيطة أكثر عمليًا.

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

3. اختبر مبكرًا: قبل التزامك بإطار، اختبره مع حالة الاستخدام الخاصة بك والأجهزة. ما يعمل في العروض لا يعمل بالضرورة عند التوسع أو مع الوثائق الخاصة بك.

4. فكّر في النهج الهجين: استخدم واجهات برمجة التطبيقات التجارية لمهام الاستخراج المعقدة ونماذج محلية للاستعلامات البسيطة لموازنة التكلفة والقدرات.

القراءة ذات الصلة

الإخراج المهيكل مع LLMs

فهم الإخراج المهيكل ضروري لإطارات مثل Cognee. تتناول هذه المقالات بشكل عميق كيفية الحصول على استجابات متسقة ومتقاربة مع النماذج:

معمارية RAG وتطبيقها

للمقاربات البديلة أو المكملة لاستخراج المعرفة والاسترجاع:

التمثيل وإعادة الترتيب

تحسين جودة الاسترجاع عبر التمثيلات الأفضل وإعادة الترتيب:

الأدوات والموارد

الموارد الخارجية