الملخص
OpenViking هو قاعدة بيانات سياق مفتوحة المصدر لوكلاء الذكاء الاصطناعي، تحل محل تخزين المتجهات المسطح بنموذج نظام الملفات. يقوم بتنظيم السياق (الذكريات، الموارد، المهارات) تحت معرفات الموارد الموحدة (URIs) `viking://` بثلاث طبقات: L0 (حوالي 100 رمز)، L1 (حوالي 2 ألف رمز)، L2 (المحتوى الكامل). تظهر الاختبارات المعيارية انخفاضًا بنسبة 91% في تكلفة الرموز وتحسنًا بنسبة 43% في إكمال المهام مقارنة بأنظمة RAG التقليدية.
مقدمة
وكيل الذكاء الاصطناعي الخاص بك يستمر في نسيان الأشياء. لقد طلب نفس نقطة نهاية API مرتين. تجاهل تفضيلك لبيئة الاختبار (staging). فقد تتبع أي الاختبارات نجحت بالأمس.
هذا هو واقع بناء الوكلاء اليوم. تقوم معظم الفرق بتجميع مسارات RAG، وقواعد بيانات المتجهات، وأنظمة الذاكرة المخصصة. النتيجة: سياق مجزأ، وتكاليف رموز متزايدة بشكل كبير، واسترجاع يفشل بصمت.
تدعم البيانات هذا. في الاختبارات المعيارية باستخدام مجموعة بيانات LoCoMo10، حققت أنظمة RAG التقليدية معدلات إكمال مهام تتراوح فقط بين 35-44% بينما استهلكت 24-51 مليون رمز إدخال.
OpenViking يتبنى نهجًا مختلفًا. تم إنشاؤه بواسطة فريق OpenViking في ByteDance، ويحل محل تخزين المتجهات المسطح بنموذج نظام الملفات. يعيش كل السياق تحت معرفات الموارد الموحدة (URIs) `viking://` مع تحميل هرمي L0/L1/L2. النتيجة: 52% إكمال للمهام بـ 91% رموز أقل.
في هذا الدليل، ستتعلم كيف يحل OpenViking تجزئة السياق، وسترى نموذج L0/L1/L2 قيد العمل، وستقوم بنشر أول خادم لك في 15 دقيقة.
مشكلة سياق الوكيل
يواجه وكلاء الذكاء الاصطناعي تحديات سياقية لم تتعامل معها التطبيقات التقليدية أبدًا.
تخيل وكيلًا يساعد المطورين في اختبار واجهات برمجة التطبيقات (APIs). على مدار أسبوع، يحتاج إلى تتبع:
- تفضيلات المستخدم ("بيئة الاختبار"، "curl بدلاً من Python")
- سياق المشروع (نقاط النهاية، طرق المصادقة، نتائج الاختبار السابقة)
- أنماط الأداة (نقاط النهاية التي تفشل، أخطاء المخطط الشائعة)
- سجل المهام (ما تم اختباره، الأخطاء التي ظهرت)
تقوم أنظمة RAG التقليدية بتخزين هذا كقطع مسطحة في قاعدة بيانات متجهات. عند استعلامها، تحصل على أفضل K شظايا متشابهة بدون بنية، ولا تسلسل هرمي، ولا رؤية لما تم تفويته.
خمسة تحديات أساسية
يحدد OpenViking خمس مشاكل أساسية في إدارة سياق الوكيل:
| التحدي | RAG التقليدي | حل OpenViking |
|---|---|---|
| سياق مجزأ | الذكريات، الموارد، المهارات مخزنة بشكل منفصل | نموذج نظام ملفات موحد تحت viking:// |
| طلب متزايد | المهام الطويلة تولد سياقًا هائلاً | التحميل الهرمي L0/L1/L2 يقلل الرموز بنسبة 91% |
| استرجاع ضعيف | بحث المتجهات المسطح يفتقر إلى الرؤية الشاملة | استرجاع تكراري للمجلدات مع تحليل النية |
| غير قابل للمراقبة | سلاسل استرجاع الصندوق الأسود | مسارات بحث مرئية لتصحيح الأخطاء |
| تكرار محدود | سجل تفاعل المستخدم فقط | إدارة جلسات تلقائية مع 6 فئات ذاكرة |
يمثل هذا تحولًا من "تخزين كل شيء، واسترجاع مبهم" إلى "هيكلة كل شيء، واسترجاع دقيق."
ما هو OpenViking؟
OpenViking هو قاعدة بيانات سياق مفتوحة المصدر لوكلاء الذكاء الاصطناعي، أنشأها فريق OpenViking في ByteDance بموجب ترخيص Apache 2.0.

يوحد جميع السياقات في نظام ملفات افتراضي. يتم تعيين الذكريات والموارد والمهارات إلى مجلدات تحت viking://، ولكل منها URI فريد.
viking://
├── resources/ # المعرفة الخارجية: وثائق، تعليمات برمجية، صفحات ويب
│ ├── my_project/
│ │ ├── docs/
│ │ │ ├── api/
│ │ │ └── tutorials/
│ │ └── src/
│ └── ...
├── user/ # خاص بالمستخدم: تفضيلات، عادات
│ └── memories/
│ ├── preferences/
│ │ ├── writing_style
│ │ └── coding_habits
│ └── ...
└── agent/ # قدرات الوكيل: مهارات، ذكريات المهام
├── skills/
│ ├── search_code
│ ├── analyze_data
│ └── ...
├── memories/
└── instructions/
يكتسب الوكلاء قدرات مباشرة لمعالجة السياق:
- تصفح المجلدات باستخدام
ls viking://resources/my_project/docs/ - ابحث دلاليًا باستخدام
find "authentication methods" - اقرأ المحتوى الكامل باستخدام
read viking://resources/docs/auth.md - احصل على ملخصات سريعة باستخدام
abstract viking://resources/docs/
فكر في الأمر على أنه الفرق بين البحث في محرك الأقراص الثابتة بأكمله ومعرفة المجلد الذي يحتوي على الملف بالضبط.
الميزة الأساسية 1: نموذج إدارة نظام الملفات
يحل نموذج نظام الملفات تجزئة السياق عن طريق توحيد جميع أنواع السياق تحت نموذج واحد.
ثلاثة أنواع من السياق
| النوع | الغرض | دورة الحياة | المبادرة |
|---|---|---|---|
| المورد | المعرفة الخارجية (وثائق، تعليمات برمجية، أسئلة متكررة) | طويل الأمد، ثابت | يضيف المستخدم |
| الذاكرة | إدراك الوكيل (تفضيلات، تجارب) | طويل الأمد، ديناميكي | يستخرج الوكيل |
| المهارة | قدرات قابلة للاستدعاء (أدوات، MCP) | طويل الأمد، ثابت | يستدعي الوكيل |
يعيش كل نوع في مجلده الخاص:
viking://resources/: كتيبات المنتجات، مستودعات الأكواد، التوثيقviking://user/memories/: تفضيلات المستخدم، ذكريات الكيانات، الأحداثviking://agent/skills/: تعريفات الأدوات، تكوينات MCPviking://agent/memories/: الأنماط المستفادة، دراسات الحالة
واجهة برمجة تطبيقات شبيهة بيونكس (Unix-like API)
يوفر OpenViking عمليات سطر أوامر مألوفة:
from openviking import OpenViking
client = OpenViking(path="./data")
# بحث دلالي عبر جميع أنواع السياق
results = client.find("user authentication")
# سرد محتويات المجلد
contents = client.ls("viking://resources/")
# قراءة المحتوى الكامل
doc = client.read("viking://resources/docs/auth.md")
# الحصول على ملخص سريع (طبقة L0)
abstract = client.abstract("viking://resources/docs/")
# الحصول على نظرة عامة مفصلة (طبقة L1)
overview = client.overview("viking://resources/docs/")
تعمل واجهة برمجة التطبيقات عبر حزمة تطوير برامج Python (SDK) أو خادم HTTP، وهي متوافقة مع أي إطار عمل للوكلاء.
الميزة الأساسية 2: تحميل السياق الهرمي L0/L1/L2
حشو السياق الضخم في الموجهات مكلف وعرضة للأخطاء. يقوم OpenViking تلقائيًا بمعالجة جميع السياقات إلى ثلاث طبقات هرمية:
| الطبقة | الاسم | الملف | حد الرمز | الغرض |
|---|---|---|---|---|
| L0 | الملخص | .abstract.md |
~100 رمز | بحث المتجهات، تصفية سريعة |
| L1 | نظرة عامة | .overview.md |
~2 ألف رمز | إعادة الترتيب، التنقل في المحتوى |
| L2 | التفاصيل | الملفات الأصلية | غير محدود | محتوى كامل، تحميل عند الطلب |
كيف يعمل
عند إضافة مورد (مثل ملف وثائق PDF)، يقوم OpenViking بما يلي:
- يحلل المستند إلى نص (لا توجد استدعاءات LLM بعد)
- يبني بنية شجرة مجلدات في تخزين AGFS
- يضع المعالجة الدلالية في قائمة الانتظار بشكل غير متزامن
- يولد ملخصات L0 ونظرات عامة L1 من الأسفل إلى الأعلى
النتيجة هي بنية هرمية:
viking://resources/my_project/
├── .abstract.md # L0: "وثائق API تغطي المصادقة، نقاط النهاية، حدود المعدل"
├── .overview.md # L1: ملخص مفصل مع التنقل بين الأقسام
├── docs/
│ ├── .abstract.md # كل مجلد يحتوي على L0/L1
│ ├── .overview.md
│ ├── auth.md # L2: المحتوى الكامل
│ ├── endpoints.md
│ └── rate-limits.md
└── src/
└── ...
تأثير ميزانية الرمز
يتيح هذا التسلسل الهرمي توفيرًا كبيرًا في التكاليف:
# RAG التقليدي: تحميل كل المحتوى
full_docs = retrieve_all("authentication") # 50k tokens
# OpenViking: ابدأ بـ L1، حمل L2 فقط إذا لزم الأمر
overview = client.overview("viking://resources/docs/auth/") # 2k tokens
if needs_more_detail(overview):
content = client.read("viking://resources/docs/auth/oauth.md") # تحميل L2 محدد
في الاختبارات المعيارية، قلل هذا النهج تكاليف الرموز المدخلة بنسبة 91% مقارنة بأنظمة RAG التقليدية مع تحسين معدلات إكمال المهام بنسبة 43%.
الميزة الأساسية 3: الاسترجاع التكراري للمجلدات
يعاني بحث المتجهات الفردي مع الاستعلامات المعقدة. يطبق OpenViking استراتيجية استرجاع تكراري للمجلدات:
العملية المكونة من خمس خطوات
1. تحليل النية
↓
2. تحديد المواقع الأولية (العثور على المجلدات ذات الدرجة العالية)
↓
3. الاستكشاف المحسن (البحث داخل المجلدات)
↓
4. الهبوط التكراري (التعمق في المجلدات الفرعية)
↓
5. تجميع النتائج (إرجاع السياقات المصنفة)
الخطوة 1: تحليل النية
يتم تحليل الاستعلام "كيف أقوم بمصادقة المستخدمين؟" لتحديد:
- نوع النية: سؤال إجرائي حول كيفية القيام بشيء
- الكيانات الرئيسية: "مصادقة"، "المستخدمين"
- المحتوى المتوقع: أدلة المصادقة، تدفقات OAuth
الخطوة 2: تحديد المواقع الأولية
يحدد بحث المتجهات بسرعة المجلدات ذات الدرجة العالية:
viking://resources/docs/auth/(النتيجة: 0.92)viking://resources/docs/security/(النتيجة: 0.78)
الخطوة 3: الاستكشاف المحسن
داخل المجلد العلوي، يعثر بحث ثانوي على ملفات محددة:
viking://resources/docs/auth/oauth.md(النتيجة: 0.95)viking://resources/docs/auth/jwt.md(النتيجة: 0.88)
الخطوة 4: الهبوط التكراري
إذا كانت المجلدات الفرعية موجودة (مثل auth/providers/)، تتكرر العملية بشكل تكراري.
الخطوة 5: تجميع النتائج
يتم تجميع النتائج النهائية وتصنيفها حسب الصلة، مع الاحتفاظ بآثار الاسترجاع.
تعمل استراتيجية "قفل المجلد أولاً، ثم استكشاف المحتوى" هذه على تحسين دقة الاسترجاع من خلال فهم السياق الكامل للمعلومات، وليس فقط أجزاء معزولة.
الميزة الأساسية 4: آثار الاسترجاع المرئية
RAG التقليدي هو صندوق أسود. عندما يفشل الاسترجاع، لا يمكنك معرفة ما إذا كانت المشكلة تتعلق بتشابه المتجهات، أو مشكلة في التجزئة، أو بيانات مفقودة.
بنية نظام الملفات في OpenViking تجعل الاسترجاع قابلاً للمراقبة:
تتبع الاسترجاع للاستعلام: "تحديث رمز OAuth"
├── viking://resources/docs/
│ ├── [النتيجة: 0.45] .abstract.md: تم تخطيه (صلة منخفضة)
│ └── [النتيجة: 0.89] auth/: تم اختياره (صلة عالية)
│ ├── [النتيجة: 0.92] oauth.md: تم إرجاعه
│ ├── [النتيجة: 0.34] jwt.md: تم تخطيه
│ └── [النتيجة: 0.78] providers/
│ └── [النتيجة: 0.85] google.md: تم إرجاعه
يوضح هذا التتبع:
- المجلدات التي تمت زيارتها
- لماذا تم اختيار أو تخطي ملفات معينة
- المسار الدقيق الذي سلكه الاسترجاع
لتصحيح الأخطاء، هذا لا يقدر بثمن. يمكنك معرفة ما إذا كان الوكيل قد فاته السياق لأنه كان في المجلد الخاطئ، أو كان لديه ملخص L0 ضعيف، أو انخفض عن عتبة النتيجة.
الميزة الأساسية 5: إدارة الجلسات التلقائية
يحتوي OpenViking على حلقة تكرار ذاتي للذاكرة مدمجة. في نهاية كل جلسة، يمكن للنظام استخراج الذكريات وتحديث معرفة الوكيل تلقائيًا.
ست فئات للذاكرة
| الفئة | المالك | الموقع | الوصف | استراتيجية التحديث |
|---|---|---|---|---|
| ملف شخصي | المستخدم | user/memories/.overview.md |
معلومات المستخدم الأساسية | قابل للإلحاق |
| تفضيلات | المستخدم | user/memories/preferences/ |
تفضيلات حسب الموضوع | قابل للإلحاق |
| الكيانات | المستخدم | user/memories/entities/ |
أشخاص، مشاريع، منظمات | قابل للإلحاق |
| أحداث | المستخدم | user/memories/events/ |
قرارات، معالم | لا يوجد تحديث |
| حالات | الوكيل | agent/memories/cases/ |
حالات مستفادة | لا يوجد تحديث |
| أنماط | الوكيل | agent/memories/patterns/ |
أنماط مستفادة | لا يوجد تحديث |
كيف يعمل استخراج الذاكرة
# بدء جلسة
session = client.session()
# إضافة رسائل (أدوار المحادثة)
await session.add_message("user", [{"type": "text", "text": "I prefer dark mode in the UI"}])
await session.add_message("assistant", [{"type": "text", "text": "Got it. I'll use dark mode for all future screenshots."}])
# تسجيل استخدام الأداة
await session.add_usage({
"tool": "screenshot",
"parameters": {"theme": "dark"},
"result": "success"
})
# التزام الجلسة: يؤدي إلى استخراج الذاكرة
await session.commit()
عند الالتزام، يقوم OpenViking بما يلي:
- يضغط الجلسة (يحتفظ بـ N من الأدوار الأخيرة، ويأرشف الأقدم)
- يستخرج الذكريات باستخدام تحليل LLM
- يحدث مجلدات الذاكرة المناسبة
- يولد L0/L1 لمحتوى الذاكرة الجديد
هذا يجعل الوكلاء أكثر ذكاءً مع الاستخدام: يتعلمون تفضيلات المستخدم، ويجمعون خبرة المهام، ويحسنون اتخاذ القرار بمرور الوقت.
نظرة عامة على البنية
تفصل بنية نظام OpenViking بين الاهتمامات عبر طبقات متعددة:

تخزين ثنائي الطبقات
يفصل OpenViking المحتوى عن الفهرس:
| الطبقة | التقنية | يخزن |
|---|---|---|
| AGFS | نظام ملفات مخصص | محتوى L0/L1/L2، ملفات الوسائط المتعددة، العلاقات |
| فهرس المتجهات | قاعدة بيانات المتجهات | URIs، التضمينات، البيانات الوصفية (لا يوجد محتوى ملف) |
يضمن هذا الفصل ما يلي:
- أن جميع قراءات المحتوى تأتي من مصدر واحد (AGFS)
- أن فهرس المتجهات يخزن فقط المراجع خفيفة الوزن
- عدم تكرار كتل النصوص الكبيرة في تخزين المتجهات
بدء سريع: نشر أول خادم OpenViking الخاص بك
المتطلبات الأساسية
- Python: 3.10 أو أعلى
- Go: 1.22+ (لمكونات AGFS)
- مترجم C++: GCC 9+ أو Clang 11+
- نظام التشغيل: Linux، macOS، أو Windows
الخطوة 1: تثبيت OpenViking
pip install openviking --upgrade --force-reinstall
اختياريًا قم بتثبيت واجهة سطر أوامر Rust (CLI) للوصول من الطرفية:
curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/crates/ov_cli/install.sh | bash
الخطوة 2: تهيئة النماذج
يتطلب OpenViking قدرتين نموذجيتين:
- نموذج VLM: لفهم الصور والمحتوى
- نموذج التضمين (Embedding Model): للتحويل إلى متجهات والبحث الدلالي
أنشئ ~/.openviking/ov.conf:
{
"storage": {
"workspace": "/home/your-name/openviking_workspace"
},
"log": {
"level": "INFO",
"output": "stdout"
},
"embedding": {
"dense": {
"api_base": "https://api.openai.com/v1",
"api_key": "your-openai-api-key",
"provider": "openai",
"dimension": 3072,
"model": "text-embedding-3-large"
},
"max_concurrent": 10
},
"vlm": {
"api_base": "https://api.openai.com/v1",
"api_key": "your-openai-api-key",
"provider": "openai",
"model": "gpt-4o",
"max_concurrent": 100
}
}
المزودون المدعمون:
| المزود | نماذج التضمين | نماذج VLM |
|---|---|---|
| volcengine | doubao-embedding-vision | doubao-seed-2.0-pro |
| openai | text-embedding-3-large | gpt-4o, gpt-4-vision |
| litellm | عبر وكيل LiteLLM | Claude, Gemini, DeepSeek, Qwen, Ollama, vLLM |
دعم LiteLLM يعني أنه يمكنك استخدام نماذج Anthropic، Google، Ollama المحلية، أو أي نقطة نهاية متوافقة مع OpenAI.
الخطوة 3: بدء تشغيل الخادم
openviking-server
أو تشغيل في الخلفية:
nohup openviking-server > /data/log/openviking.log 2>&1 &
الخطوة 4: إضافة أول مورد لك
# استخدام واجهة سطر أوامر Rust
ov add-resource https://docs.example.com/api-guide.pdf
# أو استخدام حزمة تطوير برامج Python
from openviking import OpenViking
client = OpenViking(path="./data")
client.add_resource("https://docs.example.com/api-guide.pdf")
الخطوة 5: البحث والاسترجاع
# انتظر المعالجة الدلالية، ثم ابحث
ov find "authentication methods"
# سرد محتويات المجلد
ov ls viking://resources/
# عرض شجرة المجلدات
ov tree viking://resources/docs -L 2
# البحث عن محتوى محدد
ov grep "OAuth" --uri viking://resources/docs/
الخطوة 6: تمكين VikingBot (اختياري)
VikingBot هو إطار عمل لوكيل الذكاء الاصطناعي مبني على OpenViking:
pip install "openviking[bot]"
# بدء الخادم مع تمكين البوت
openviking-server --with-bot
# في طرفية أخرى، ابدأ دردشة تفاعلية
ov chat
اختبارات الأداء المعيارية
تم اختبار OpenViking مقارنة بأنظمة RAG التقليدية (LanceDB) وأنظمة الذاكرة الأصلية باستخدام مجموعة بيانات LoCoMo10 (1,540 حالة حوار بعيدة المدى).
معدلات إكمال المهام
| النظام | معدل الإنجاز | رموز الإدخال |
|---|---|---|
| OpenClaw (ذاكرة أصلية) | 35.65% | 24.6 مليون |
| OpenClaw + LanceDB | 44.55% | 51.6 مليون |
| OpenClaw + OpenViking | 52.08% | 4.3 مليون |
النتائج الرئيسية
- تحسن بنسبة 43% مقارنة بالذاكرة الأصلية مع تقليل الرموز بنسبة 91%
- تحسن بنسبة 17% مقارنة بـ LanceDB مع تقليل الرموز بنسبة 92%
- وجد استرجاع OpenViking الهرمي سياقًا أكثر صلة مع استهلاك عدد أقل من الرموز
تأتي هذه النتائج من دمج OpenViking كإضافة مع OpenClaw، وهو مساعد برمجة بالذكاء الاصطناعي مفتوح المصدر. استندت مجموعة بيانات الاختبار إلى حوارات طويلة المدى حيث يكون الاحتفاظ بالذاكرة أمرًا بالغ الأهمية.
دمج OpenViking مع Apidog
يمكن لمستخدمي Apidog الذين يقومون ببناء وكلاء ذكاء اصطناعي لاختبار واجهات برمجة التطبيقات الاستفادة من OpenViking للحفاظ على سياق المحادثة، وتخزين وثائق API، وتذكر تفضيلات المستخدم عبر الجلسات.

الخطوة 1: إعداد خادم OpenViking
اتبع دليل البدء السريع أعلاه لنشر OpenViking مع نماذج VLM والتضمين المفضلة لديك.
الخطوة 2: استيراد وثائق Apidog API
# أضف وثائق مشروع Apidog الخاصة بك كمورد
ov add-resource https://docs.apidog.com/overview
ov add-resource https://docs.apidog.com/api-testing
يقوم هذا باستيراد وثائق Apidog إلى viking://resources/ مع معالجة L0/L1/L2 التلقائية.
الخطوة 3: تخزين تفضيلات المستخدم
from openviking import OpenViking
client = OpenViking(path="./apidog-agent-data")
session = client.session()
# تسجيل تفضيل المستخدم الافتراضي للبيئة
await session.add_message("user", [{
"type": "text",
"text": "Always use the staging environment for API tests"
}])
await session.commit() # يستخرج ذاكرة التفضيل تلقائيًا
الخطوة 4: استعلام السياق أثناء الاختبار
# البحث عن نقاط نهاية API ذات الصلة قبل تشغيل الاختبارات
results = client.find("authentication endpoints")
for ctx in results.resources:
print(f"Found: {ctx.uri}")
# استرجاع تفضيل بيئة المستخدم
prefs = client.find("staging environment preference", target_uri="viking://user/memories/")
الخطوة 5: الاتصال بإطار عمل الوكيل الخاص بك
يقدم OpenViking كلاً من حزمة تطوير برامج Python (SDK) وواجهة برمجة تطبيقات HTTP (API):
# حزمة تطوير برامج Python (SDK)
from openviking import OpenViking
client = OpenViking(path="./data")
# أو واجهة برمجة تطبيقات HTTP (API)
import httpx
response = httpx.post(
"http://localhost:1933/api/v1/search/find",
json={"query": "authentication endpoints"},
headers={"X-API-Key": "your-api-key"}
)
تقنيات متقدمة وأفضل الممارسات
نصائح احترافية لعمليات النشر في الإنتاج
1. التسخين المسبق للسياق الذي يتم الوصول إليه بشكل متكرر
قم بتحميل الوثائق الهامة إلى L0/L1 خلال ساعات الذروة لتقليل زمن الاستجابة أثناء عمليات الوكيل.
# تشغيل المعالجة الدلالية على الفور
ov add-resource https://docs.example.com --wait
2. تنفيذ انتهاء صلاحية السياق
قم بإعداد تنظيف تلقائي لبيانات الجلسة القديمة:
# أرشفة الجلسات الأقدم من 7 أيام
await session.archive(max_age_days=7)
3. مراقبة صحة فهرس المتجهات
تتبع حجم الفهرس وزمن استجابة الاستعلام:
ov debug stats
أخطاء شائعة يجب تجنبها
- تحميل محتوى L2 مبكرًا: ابدأ دائمًا بـ L0/L1 لتوفير الرموز
- تخطي التزامات الجلسة: لا يحدث استخراج الذاكرة إلا عند الالتزام
- تحميل مجلدات فردية بشكل زائد: قسم الموارد الكبيرة إلى مجلدات فرعية قائمة على الموضوع
- تجاهل آثار الاسترجاع: استخدم الآثار المرئية لتصحيح الأخطاء في النتائج الضعيفة
تحسين الأداء
| السيناريو | التوصية |
|---|---|
| حجم استعلام مرتفع | تشغيل OpenViking كخادم HTTP مع تجميع الاتصالات |
| مستندات كبيرة | قسمها إلى أجزاء قائمة على الموضوع قبل الاستيراد |
| احتياجات زمن استجابة منخفض | توليد L0/L1 مسبقًا للمحتوى الذي يتم الوصول إليه بشكل متكرر |
| إعداد متعدد المستأجرين | استخدم مساحات عمل منفصلة لكل مستأجر |
أفضل ممارسات الأمان
- تخزين مفاتيح API في متغيرات البيئة أو مديري الأسرار (لا تضعها أبدًا في ملفات التكوين)
- تمكين HTTPS لجميع عمليات نشر خوادم HTTP
- تطبيق تحديد المعدل على نقاط النهاية العامة
- استخدم مفاتيح API منفصلة للتطوير والإنتاج
حالات الاستخدام الواقعية
1. مساعدو البرمجة بالذكاء الاصطناعي
قام فريق تطوير بدمج OpenViking مع مساعد البرمجة الداخلي الخاص بهم. أصبح الوكيل الآن:
- يتنقل في بنية المشروع عبر
viking://resources/my_project/src/ - يتذكر تفضيلات المستخدم للبرمجة (اتفاقيات التسمية، أطر عمل الاختبار)
- يسترجع وثائق API ذات الصلة أثناء توليد الكود
النتيجة: انخفاض بنسبة 67% في سلوكيات الوكيل "النسيان"، وتوفير 43% في تكلفة الرموز.
2. وكلاء دعم العملاء
قامت شركة SaaS بنشر OpenViking لروبوت الدردشة الخاص بالدعم:
- وثائق المنتج مخزنة في
viking://resources/product/ - سجل محادثات العملاء في
viking://user/memories/past_issues/ - كتيبات الدعم كمهارات في
viking://agent/skills/
النتيجة: تحسن حل المشكلات من أول اتصال من 52% إلى 71%.
3. مساعدو البحث
يستخدم مختبر أبحاث OpenViking لتنظيم الأوراق والملاحظات:
- الأوراق مصنفة حسب الموضوع (
viking://resources/papers/nlp/) - منهجيات البحث مخزنة كمهارات
- استخراج تلقائي للنتائج الرئيسية إلى الذاكرة
النتيجة: يجد الباحثون الأوراق ذات الصلة أسرع بـ 3 مرات باستخدام البحث الدلالي.
البدائل والمقارنات
OpenViking ليس الحل الوحيد لإدارة السياق. إليك كيف يقارن بالبدائل:
OpenViking مقابل قواعد بيانات المتجهات التقليدية
| الجانب | RAG التقليدي (Pinecone, LanceDB) | OpenViking |
|---|---|---|
| نموذج التخزين | قطع متجهات مسطحة | نظام ملفات هرمي |
| الاسترجاع | التشابه أعلى K | استرجاع تكراري للمجلدات + تحليل النية |
| قابلية المراقبة | صندوق أسود | آثار بحث مرئية |
| كفاءة الرموز | تحميل الكل أو الاقتطاع | تحميل تدريجي L0/L1/L2 |
| تكرار الذاكرة | يدوي أو لا يوجد | إدارة جلسات تلقائية |
| أنواع السياق | مستندات فقط | موارد، ذكريات، مهارات موحدة |
| تصحيح الأخطاء | تخمين | سجلات اجتياز المجلدات |
OpenViking مقابل ذاكرة LangChain
| الجانب | ذاكرة LangChain | OpenViking |
|---|---|---|
| الاستمرارية | مخزن مؤقت للمحادثة فقط | نظام ملفات كامل مع L0/L1/L2 |
| قابلية التوسع | محدود بنافذة السياق | تحميل هرمي، لا يوجد حد صارم |
| الاسترجاع | بحث خطي | استرجاع تكراري للمجلدات + دلالي |
| أنواع الذاكرة | مخزن مؤقت واحد | 6 فئات (ملف شخصي، تفضيلات، أحداث، إلخ.) |
متى يجب التفكير في البدائل
استخدم قواعد بيانات المتجهات التقليدية إذا:
- كنت بحاجة إلى زمن استجابة استرجاع أقل من 100 مللي ثانية
- كانت حالة الاستخدام الخاصة بك بحثًا بسيطًا عن الكلمات المفتاحية
- كان لديك بالفعل مسار RAG فعال ولا توجد لديك مشاكل
استخدم OpenViking إذا:
- كنت تبني محادثات وكلاء طويلة الأمد
- كنت بحاجة إلى سياق متعدد الأنواع (وثائق + تفضيلات + أدوات)
- كان تحسين تكلفة الرموز مهمًا
- كنت تريد استرجاعًا قابلاً للمراقبة والتصحيح
مقارنة مع RAG التقليدي
| الجانب | RAG التقليدي | OpenViking |
|---|---|---|
| نموذج التخزين | قطع متجهات مسطحة | نظام ملفات هرمي |
| الاسترجاع | التشابه أعلى K | استرجاع تكراري للمجلدات + تحليل النية |
| قابلية المراقبة | صندوق أسود | آثار بحث مرئية |
| كفاءة الرموز | تحميل الكل أو الاقتطاع | تحميل تدريجي L0/L1/L2 |
| تكرار الذاكرة | يدوي أو لا يوجد | إدارة جلسات تلقائية |
| أنواع السياق | مستندات فقط | موارد، ذكريات، مهارات موحدة |
| تصحيح الأخطاء | تخمين | سجلات اجتياز المجلدات |
النشر في بيئة الإنتاج
لبيئات الإنتاج، قم بتشغيل OpenViking كخدمة HTTP مستقلة:
البنية التحتية الموصى بها
- السحابة: Volcengine ECS أو ما يعادله
- نظام التشغيل: veLinux أو Ubuntu 22.04+
- التخزين: وحدة تخزين مدعومة بـ SSD لـ AGFS
- الشبكة: اتصال بزمن استجابة منخفض بواجهات برمجة تطبيقات النموذج
اعتبارات الأمان
- تخزين مفاتيح API في متغيرات البيئة أو مدير الأسرار
- تمكين المصادقة لنقاط نهاية HTTP
- استخدام HTTPS لجميع اتصالات العميل والخادم
- تطبيق تحديد المعدل لمنع إساءة الاستخدام
المراقبة
يدعم OpenViking التسجيل والمقاييس:
{
"log": {
"level": "INFO",
"output": "file",
"path": "/var/log/openviking/server.log"
}
}
راقب:
- عمق قائمة انتظار المعالجة الدلالية
- زمن استجابة بحث المتجهات
- عمليات قراءة/كتابة AGFS
- معدلات نجاح استخراج الذاكرة
القيود والاعتبارات
القيود الحالية
- تتمحور حول Python: حزمة تطوير البرامج الأساسية هي Python؛ تتطلب اللغات الأخرى دمج HTTP
- تبعيات النموذج: تتطلب نماذج VLM وتضمين خارجية (لا يوجد استدلال مدمج)
- منحنى التعلم: نموذج نظام الملفات يختلف عن قواعد بيانات المتجهات التقليدية
- مرحلة مبكرة: المشروع قيد التطوير النشط؛ قد تتغير واجهات برمجة التطبيقات
متى تستخدم OpenViking
مناسب بشكل جيد:
- محادثات الوكلاء طويلة الأمد التي تتطلب ذاكرة
- سياق متعدد الأنواع (وثائق + تفضيلات + أدوات)
- الحاجة إلى استرجاع قابل للمراقبة والتصحيح
- تحسين تكلفة الرموز مهم
فكر في البدائل:
- تطبيقات الأسئلة والأجوبة البسيطة لمرة واحدة
- كان لديك بالفعل مسار RAG فعال ولا توجد لديك مشاكل
- كنت بحاجة إلى زمن استجابة استرجاع أقل من 100 مللي ثانية (يضيف OpenViking عبئًا معالجة إضافيًا)
الطريق إلى الأمام
OpenViking في مرحلة مبكرة من التطوير (الإصدار 0.1.x اعتبارًا من أوائل عام 2025). تتضمن خارطة الطريق:
- دعم متعدد المستأجرين: مساحات عمل معزولة للفرق
- تحليلات متقدمة: مقاييس جودة الاسترجاع، لوحات معلومات استخدام الذاكرة
- نظام بيئي للمكونات الإضافية: تكاملات جاهزة مع أطر عمل الوكلاء الشائعة
- النشر على الحافة: وضع خفيف الوزن للتطبيقات المحلية أولاً
- دعم MCP محسن: دمج بروتوكول سياق النموذج الأصلي
يسعى الفريق وراء OpenViking بنشاط إلى مساهمين من المجتمع. المشروع مفتوح المصدر بموجب ترخيص Apache 2.0، مع توفر الوثائق.
الخلاصة
يمثل OpenViking تحولًا في كيفية إدارة وكلاء الذكاء الاصطناعي للسياق. من خلال تنظيم المعلومات كنظام ملفات بدلاً من قطع مسطحة، فإنه يحل مشكلة التجزئة وهدر الرموز واسترجاع الصندوق الأسود التي تعاني منها أنظمة RAG التقليدية.
النقاط الرئيسية
- نموذج نظام الملفات يوحد السياق: جميع الذكريات والموارد والمهارات تحت معرفات الموارد الموحدة (URIs)
viking:// - تحميل L0/L1/L2 يقلل الرموز بنسبة 91%: تحميل تدريجي بدلاً من إلقاء كل شيء في الموجهات
- الاسترجاع التكراري للمجلدات يعزز الدقة: قفل المجلدات ذات الدرجة العالية أولاً، ثم استكشاف المحتوى
- الآثار المرئية تمكن من تصحيح الأخطاء: شاهد بالضبط المسارات التي سلكها الاسترجاع
- إدارة الجلسات التلقائية تمكن التعلم: يستخرج الوكلاء الذكريات من كل محادثة
