مقدمة: سيناريو المشكلة الذي نعيشه يومياً
تخيل أن مطوراً جديداً انضم لفريقك اليوم، وسألك: “كيف نحسب عدد المستخدمين النشطين أسبوعياً من جدول الأحداث (Event Stream)؟”. غالباً ما ستكون إجابتك رحلة استكشافية: ستقوم بإرسال رابط لتوثيق قديم في Notion أو Confluence (ربما لم يُحدث منذ عام)، ثم ستطلب منه النظر في تعليقات ملف SQL معين، وفي النهاية قد تضطر للبحث في رسائل Slack قديمة لتشرح له “الاستثناءات” التي لم تُكتب في أي مكان.
الآن، تخيل أنك تحاول بناء AI Agent (وكيل ذكاء اصطناعي) ليقوم بهذه المهمة نيابة عنك. إذا كان البشر يجدون صعوبة في تجميع هذا السياق المشتت، فكيف للنماذج اللغوية الكبيرة (LLMs) أن تفعل ذلك بدقة دون “هلوسة”؟ هنا تكمن المشكلة: المعرفة التقنية في شركاتنا تعيش في صوامع (Silos) متنافرة؛ كتالوجات بيانات بـ APIs معقدة، ملفات Markdown مبعثرة، وعقول المهندسين الأقدم.
هذا هو التحدي الذي جاءت جوجل كلاود لتحله عبر إطلاق Open Knowledge Format (OKF).
ما هو Open Knowledge Format (OKF)؟
ببساطة، Open Knowledge Format (OKF) هو مواصفة مفتوحة (Open Specification) ومحايدة للموردين (Vendor-neutral)، تهدف إلى تحويل المعرفة المؤسسية إلى تنسيق يمكن للبشر قراءته وللآلات معالجته بسهولة. يعتمد التنسيق بشكل كامل على ملفات Markdown مع ترويسة YAML (YAML Frontmatter)، مما يجعله قابلاً للنقل والتخزين في أي مستودع كود (Git) دون الحاجة لـ SDK خاص أو منصة معقدة.
الإصدار الحالي OKF v0.1 لا يقدم تقنية ضغط جديدة أو وقت تشغيل (Runtime) معقداً، بل يضع “اتفاقية” (Convention) موحدة لكيفية تنظيم ملفات المعرفة لضمان توافقها بين مختلف الأدوات والوكلاء الذكيين.
لماذا يهمك Open Knowledge Format (OKF) كمطور؟
كمطور، أنت تعلم أن بناء RAG (Retrieval-Augmented Generation) ليس حلاً سحرياً. في أنظمة RAG التقليدية، يتم تقطيع المستندات إلى أجزاء (Chunks) وتخزينها كمتجهات (Vectors). عندما يسأل المستخدم سؤالاً، يبحث النظام عن أقرب الأجزاء تشابهاً. المشكلة؟ النظام يفتقر لـ “الفهم الهيكلي”. هو لا يعرف أن “جدول الطلبات” مرتبط بـ “جدول العملاء” إلا إذا ورد ذلك صراحة في الجزء المسترجع.
يوفر Open Knowledge Format (OKF) حلولاً لهذه الفجوات:
- المعرفة ككود (Knowledge as Code): يمكنك تخزين توثيق الجداول والـ
APIsوالسياسات بجانب الكود المصدري ومراجعتها عبرPull Requests. - الاستقلالية عن المنصة: لا تحتاج للاعتماد على
Notion APIأو أدواتSaaSمغلقة. ملفاتك هي ملكك، تعمل علىGitHubأو حتى على جهازك الشخصي. - تحويل المعرفة إلى رسم بياني (Knowledge Graph): من خلال الروابط التقليدية في
Markdownبين الملفات، يتحول مجلد المعرفة إلى شبكة مترابطة يفهم الوكيل الذكي مساراتها.
كيف تبدأ؟ الهيكل العملي لـ OKF
تنسيق Open Knowledge Format (OKF) يعتمد على مفهوم “الحزمة” (Bundle)، وهي عبارة عن مجلد يحتوي على ملفات Markdown تمثل “المفاهيم” (Concepts).
1. هيكل المجلدات المقترح
إليك كيف يبدو تنظيم المعرفة لفريق بيانات باستخدام OKF:
sales_project/
├── index.md
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md
│ └── customers.md
└── metrics/
├── index.md
└── weekly_active_users.md
2. تشريح ملف المفهوم (Concept File)
كل ملف في OKF يجب أن يبدأ بكتلة YAML تحتوي على حقول محددة. الحقل الإلزامي الوحيد هو type.
---
type: BigQuery Table
title: Orders
description: جدول يحتوي على تفاصيل طلبات العملاء المكتملة.
resource: https://console.cloud.google.com/bigquery?t=orders
tags: [sales, revenue]
timestamp: 2026-06-20T10:00:00Z
---
# Schema (مخطط البيانات)
| Column | Type | Description |
|---------------|--------|------------------------------------------|
| `order_id` | STRING | المعرف الفريد للطلب. |
| `customer_id` | STRING | مفتاح أجنبي يربط بجدول العملاء. |
# Joins (الارتباطات)
يمكن ربط هذا الجدول بجدول `customers` باستخدام حقل `customer_id`.
[اقرأ المزيد عن جدول العملاء](../tables/customers.md)
شرح المكونات:
- type (النوع): يحدد ماهية هذا الملف (مثلاً:
APIأوMetricأوPlaybook). - resource (المورد): رابط للمصدر الفعلي (رابط قاعدة البيانات أو لوحة التحكم).
- Body (المتن): يكتب بلغة
Markdownبسيطة ليشرح التفاصيل التي يحتاجها الوكيل أو المطور.
مقارنة عملية: OKF مقابل الحلول الحالية
| المعيار | Open Knowledge Format (OKF) | RAG التقليدي | التوثيق (Wiki) |
|---|---|---|---|
| طريقة التخزين | ملفات Markdown بسيطة | قاعدة بيانات متجهات (Vector DB) | منصات SaaS مغلقة |
| سهولة القراءة | عالية جداً (بشر وآلات) | منخفضة (متجهات رقمية) | عالية للبشر فقط |
| التنقل | عبر روابط Markdown (Graph) | عبر التشابه الدلالي فقط | عبر محركات بحث داخلية |
| الإصدارات | يدعم Git بشكل طبيعي | صعب التتبع | يدعم تاريخ التعديلات داخلياً |
نصائح ومزالق يجب تجنبها عند استخدام OKF
أثناء تبنيك لـ Open Knowledge Format (OKF)، تذكر أن الهدف هو مساعدة الذكاء الاصطناعي على مساعدتك. إليك بعض النصائح:
- لا تبالغ في الحشو: الوكلاء الذكيون يفضلون “المفاهيم الذرية” (Atomic Concepts). بدلاً من كتابة ملف واحد ضخم لكل قاعدة البيانات، قم بتقسيمه إلى ملف لكل جدول.
- استخدم الروابط النسبية: دائماً اربط المفاهيم ببعضها باستخدام مسارات نسبية مثل
../metrics/wau.md. هذا يسمح للوكيل “بالمشي” عبر الرسم البياني للمعرفة. - تجنب المصطلحات الغامضة: عند كتابة الوصف، كن مباشراً. بدلاً من “هذا الجدول رائع للتحليل”، اكتب “هذا الجدول يحتوي على بيانات المبيعات الخام قبل الخصومات”.
- أتمتة التوليد: لا تكتب كل شيء يدوياً. استخدم سكربتات بسيطة لاستخراج
Schemaمن قواعد بياناتك وتحويلها إلى تنسيق OKF، ثم اترك للبشر مهمة إضافة “السياق النوعي” (Qualitative Context).
الأسئلة الشائعة حول Open Knowledge Format (OKF)
هل يحتاج OKF إلى نموذج ذكاء اصطناعي محدد؟
لا، هذا هو جمال الموضوع. بما أنه مجرد ملفات نصية، يمكنك استخدامه مع GPT-4 أو Claude أو Gemini أو حتى النماذج المحلية مثل Llama 3.
كيف يكتشف الوكيل الذكي ملفات OKF؟
يمكنك الإشارة إلى حزمة OKF في ملف llms.txt الخاص بموقعك، أو ببساطة تزويد الوكيل بمسار المجلد إذا كان يعمل محلياً.
هل OKF بديل لـ RAG؟
ليس بالضرورة. يمكن اعتباره “طبقة تنظيم” فوق RAG. بدلاً من البحث في نصوص عشوائية، يبحث الـ RAG الخاص بك في مفاهيم منظمة وموثوقة بصيغة OKF.
ما هو نمط “LLM-wiki” الذي تشير إليه جوجل؟
هو نمط اقترحه الباحث “أندريه كارباتي” (Andrej Karpathy)، حيث يرى أن الوكلاء الذكيين لا يملون من تحديث المراجع المتبادلة وتدقيق الملفات، لذا فإن أفضل طريقة لتخزين المعرفة هي “ويكي” يديره البشر والذكاء الاصطناعي معاً.
الخلاصة والرأي
إن Open Knowledge Format (OKF) ليس مجرد محاولة من جوجل لفرض معيار جديد، بل هو اعتراف بأن “السياق” (Context) هو العملة الأغلى في عصر الذكاء الاصطناعي. إذا كنت تبني أنظمة تعتمد على وكلاء أذكياء، فإن الاستمرار في الاعتماد على التوثيق المشتت سيعيقك حتماً.
رأيي الشخصي هو أن OKF يستحق التجربة الآن لأنه “قليل المخاطر، عالي العائد”. لن تخسر شيئاً بتحويل توثيقك إلى Markdown منظم، بل ستحصل على هيكل جاهز للمستقبل، سواء استخدمت أدوات جوجل أو غيرها.
ابدأ اليوم بتحويل أهم 5 جداول بيانات أو 5 سياسات هندسية في فريقك إلى ملفات بتنسيق Open Knowledge Format (OKF)، وضعها في مجلد /docs/okf في مستودع الكود الخاص بك. راقب كيف ستتحسن إجابات الوكلاء الذكيين عند تزويدهم بهذا المجلد كمرجع أساسي.




