researcher: أرشيف أبحاث كمية قابل للبحث للبشر ووكلاء الذكاء الاصطناعي

الأبحاث الكمية موجودة في كل مكان ولا مكان في آن واحد. الورقة التي تحتاجها على arXiv. التطبيق المرجعي على GitHub. الحدس مدفون في تدوينة كتبها أحدهم عام 2019. ومنطق الدخول/الخروج الفعلي هو سكربت Pine على TradingView حاز 400 إعجاب وبلا أي توثيق. أربع مجموعات بيانات، وأربعة صناديق بحث، وأربع مجموعات من الأعراف، وصفر إحالات متبادلة. عندما تحاول أن تقرر ما إذا كانت فكرة ما تستحق أسبوعاً من الاختبار الرجعي، فإن هذا التشتت هو الكلفة الحقيقية — ليست القراءة، بل العثور.

لذا بنينا أرشيفنا الخاص. researcher.marketmaker.cc هو أرشيف منسق ومحرك بحث لأبحاث التداول الكمي. يجمع المواد المبعثرة عادةً عبر arXiv وGitHub ومدونات الكم وTradingView في مكان واحد، ويفهرسها بالكامل للبحث النصي الكامل، و — وهذا هو الجزء الذي يهمنا أكثر من غيره — يكشف المجموعة بأكملها لوكلاء الذكاء الاصطناعي عبر نقطة نهاية Model Context Protocol (MCP) وواجهة REST API عامة. إنه أساس بحثي يمكن للإنسان أن يتصفحه بلوحة مفاتيح وللوكيل أن يستعلم عنه باستدعاء أداة، مدعوماً بالفهارس نفسها تماماً.

هذه التدوينة جولة في ما بداخله، وكيف بُني، ولماذا يحتل موقعه هذا في حزمة وكلاء الذكاء الاصطناعي لدينا.

ما الذي تحتويه المجموعة

يوحّد researcher أربع مجموعات بيانات أساسية، لكل منها فهرس نصي كامل خاص بها. الأعداد أدناه هي بتاريخ 2026-06-12، وهي تتغير — فخط معالجة arXiv يعمل يومياً ويُعاد بناء الفهرس من المصدر، لذا تنمو الأرقام.

هذا ما يزيد قليلاً عن 51,000 مستند موزعة على الفهارس الأربعة القابلة للبحث. فهرس الأوراق هو أكبر مجموعة منفردة وهو الذي بذلنا فيه أكبر جهد: إنه دفق arXiv الكمي المالي الكامل (q-fin.*) يعود إلى 1997، وليس مجموعة منتقاة يدوياً. في وقت سابق كان الموقع يشحن بضع مئات من الأوراق المنسقة فقط؛ أما الفهرس الحالي فهو مجموعة q-fin كاملة، مع دمج مصادر منسقة فوقها بحيث تحمل الورقة التي أشارت إليها أيضاً مدونة كمية محددة ذلك العزو.

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

مصدر واحد للحقيقة

الأمر الذي انكسر بهدوء لدينا في وقت مبكر — والأمر الذي نصمم الآن بقوة لتفاديه — هو عدم تطابق الأعداد. الصفحة الرئيسية تقول رقماً، والبحث يعيد رقماً آخر، وواجهة API رقماً ثالثاً. في وقت ما كانت الصفحة الأمامية تعلن عن 719 ورقة بينما كان البحث يعيد أكثر من 18,000. لا شيء أكثر تآكلاً للثقة في أداة بحثية من مجموعة لا تستطيع أن تتفق مع نفسها على حجمها.

كان الحل أن نجعل كل واجهة تقرأ من مكان واحد. بالنسبة لمجموعة الأوراق، Meilisearch هو مصدر الحقيقة. لا توجد نسخة ثانية من الأوراق تعيش في حزمة التطبيق؛ فالعدد على الصفحة الرئيسية، والعدد على /papers، والعدد الذي تعيده واجهة API، والمستندات التي تبحث فيها فعلاً، كلها الفهرس نفسه. تُبنى المجموعة ذاتها دون اتصال عبر خطوة استيعاب تأخذ مجموعة الأوراق المنسقة، وتوحّدها مع دفق arXiv (مع إزالة التكرار حسب id الخاص بـ arXiv، ودمج مصفوفات المصدر)، وترتّبها من الأحدث أولاً، وتكتب ملفاً واحداً بحجم ~25 MB يستهلكه المفهرس. هذا الملف يضم تقريباً 15,000–18,000 سجل وهو عمداً غير مضمّن في العميل — مجموعة بهذا الحجم لا شأن لها بالشحن إلى المتصفح.

أما مجموعات البيانات الثلاث الأخرى (الشيفرة، والمقالات، وسكربتات Pine) فتُقرأ من جانب الخادم من ملفات JSON الخاصة بها وتُفهرس من الملفات نفسها، مع كون الترحيل نحو اعتماد Meili مصدراً هو الخطوة التالية المخطط لها. القاعدة في كل الأحوال: اقرأ البيانات على الخادم، ولا تستورد (import) أبداً مجموعة بيانات بحجم عدة ميغابايت إلى حزمة العميل، ودع الفهرس والأعداد المعروضة يأتيان من المصدر نفسه. عندئذٍ يصبح عدم التزامن مستحيلاً بنيوياً.

البحث: نصي كامل، متسامح مع الأخطاء المطبعية، متعدد الأوجه

محرك البحث هو Meilisearch، يعمل على الخادم نفسه الذي يعمل عليه التطبيق ومرتبط بـ localhost — وهو غير مكشوف للعموم. نستخدمه بوصفه محرك بحث نصي كامل، لا مخزن متجهات. لا تضمينات، ولا سحر تشابه دلالي. للسؤال "ابحث لي عن الأوراق والمستودعات التي تذكر هذا المفهوم"، فإن البحث المعجمي المتسامح مع الأخطاء المطبعية عبر العناوين والملخصات والأوصاف والمؤلفين والوسوم سريع، ويمكن التنبؤ به، وقابل لتتبع الأخطاء بطريقة لا يتيحها فهرس التضمينات. يخزّن كل فهرس المستند الأصلي الكامل بالإضافة إلى _id مضاف، بحيث يعيد البحث سجلات مكتملة الترطيب يمكن للتطبيق عرضها مباشرةً — دون جلب ثانٍ لإعادة ترطيب النتائج.

بعض التفاصيل التي تهم عملياً:

• التسامح مع الأخطاء المطبعية وترتيب الصلة يأتيان مجاناً من Meilisearch. البحث عن momentm لا يزال يجد أوراق الزخم؛ والنتائج مرتبة، لا مُرشّحة فقط.

• التصفية متعددة الأوجه. الأوراق تُصفّى حسب category على arXiv (q-fin.PM، q-fin.TR، …)، والمستودعات حسب language وstars، والمقالات حسب source وdate، وسكربتات Pine حسب category. تبني صفحة /papers قائمتها المنسدلة للفئات من التوزيع الحي للأوجه في الفهرس، بحيث تعكس خيارات التصفية دائماً ما هو موجود فعلاً في المجموعة.

• تقسيم camelCase. يجزّئ Meilisearch على المسافات وعلامات الترقيم لكن ليس على camelCase. وهذا يعني أن مستودعاً اسمه حرفياً TradingAgents سيكون رمزاً واحداً، يتعذر الوصول إليه بالاستعلام الطبيعي "trading agents". أثناء الفهرسة نشتق حقل name_split — TradingAgents ← TradingAgents Trading Agents، وai-hedge-fund ← ai-hedge-fund ai hedge fund — ونضيفه إلى السمات القابلة للبحث. يُحفظ الرمز الأصلي أولاً بحيث تظل مطابقات الاسم الدقيقة في أعلى الترتيب، ولا يُعاد الحقل المشتق أبداً إلى العملاء. إنه أمر صغير يصنع الفرق بين العثور على المستودع الرئيسي وعدمه.

• التصفح = الأحدث أولاً. الاستعلام الفارغ ليس خطأً؛ إنه مسار التصفح. على /papers يرتّب الاستعلام الفارغ حسب published تنازلياً، بحيث تعمل الصفحة أيضاً كتغذية بترتيب زمني عكسي لأحدث أبحاث q-fin.

• فهرس جانبي للتجميعات. بعض الأرقام لا يستطيع Meilisearch حسابها بثمن زهيد وقت الاستعلام — إجمالي النجوم عبر جميع المستودعات، وإجمالي ملفات Python، وإجمالي الدفاتر. بدلاً من مسح المجموعة كاملةً عند كل تحميل للصفحة، يكتب المفهرس تلك المجاميع مرةً واحدة، وقت الفهرسة، في فهرس صغير اسمه researcher_meta يحتوي مستنداً واحداً لكل مجموعة بيانات. وتقرأها نقطة نهاية stats مباشرةً. الأعداد التي لا تتغير إلا عند إعادة الفهرسة تُحسب فقط عند إعادة الفهرسة.

• سقف ترقيم صفحات قابل للاستخدام فعلاً. يرفع فهرس الأوراق قيمة maxTotalHits في Meilisearch إلى 50,000 ويحدد published قابلاً للفرز، بحيث يمكنك التصفح عميقاً في مجموعة قوامها ~18 ألف مستند وفرز كل شيء من الأحدث أولاً — لا مجرد الصفحة الأولى من نتائج الصلة.

المفهرس متكافئ العمليات (idempotent): فهو ينشئ كل فهرس إن لم يكن موجوداً، ويعيد تطبيق الإعدادات، ويُحدِّث/يُدرج كل مستند على دفعات من 2,000 مُفتاحة بـ _id (الأوراق تشتق مفتاحها من معرّف arXiv، والمستودعات والمقالات من تجزئة (hash) للرابط). ولأن الفهرس بأكمله قابل لإعادة البناء من الملف المصدر، فلا توجد نسخة احتياطية تُدار — والتراجع ليس سوى إعادة فهرسة. إعادة تشغيله آمنة بحكم التصميم.

متاح للوكلاء: MCP وواجهة API عامة

ها هو الجزء الذي يربط researcher ببقية ما نفعله. المجموعة ليست مجرد موقع بصندوق بحث — إنها أداة يمكن لوكيل ذكاء اصطناعي أن يستدعيها.

نقطة نهاية MCP

يكشف researcher خادم Model Context Protocol عند /api/mcp عبر Streamable HTTP. أي وكيل متوافق مع MCP — Claude، أو وكيل مخصص في حزمتنا الخاصة، أو أي شيء يتحدث البروتوكول — يمكنه الاتصال واستدعاء أدوات للقراءة فقط على المجموعة الحية. هناك 13 أداة، مجمّعة حسب مجموعة البيانات، وتتبع شكلاً متسقاً من search / get / list:

كُتبت مخططات الأدوات لمنفعة الوكيل، لا الإنسان. على سبيل المثال، search_papers يقدّم نفسه بوصفه بحث صلة مرتب ومتسامح مع الأخطاء المطبعية عبر العنوان والملخص والمؤلفين، مع مرشح category اختياري (مثل q-fin.PM) وحدّ للنتائج — ويخبر الوكيل باستدعاء get_paper للحصول على الملخص الكامل بمجرد أن يضيّق نطاق الأمور. يعيد search نتائج مدمجة بحجم مقتطفات بحيث يستطيع الوكيل مسح نتائج كثيرة بثمن زهيد؛ ويعيد get السجل الكامل بمجرد أن يختار واحداً. هذا الشكل من خطوتين يمنع نافذة سياق الوكيل من الغرق في ملخصات لا يحتاجها.

عملياً، يمكن لوكيل يحقق في، لنقل، التنفيذ الأمثل أن يشغّل search_papers("optimal execution", category: "q-fin.TR") للحصول على قائمة مختصرة مرتبة من العناوين والمقتطفات، وsearch_repos("optimal execution", language: "Python") للعثور على التطبيقات مرتبةً حسب الصلة وقابلة للتصفية حسب النجوم، وsearch_pine("VWAP") ليرى كيف تظهر الفكرة نفسها كاستراتيجية منشورة على TradingView — ثلاثة استدعاءات أدوات على ثلاث مجموعات كانت، قبل ساعة، ثلاثة مواقع مختلفة. ثم يسحب get_paper واحد الملخص الكامل لتلك التي بدت واعدة. لا يغادر الوكيل البروتوكول قط، وكل نتيجة سجل حقيقي مكتمل الترطيب لا بقايا نتيجة بحث عليه أن يعيد جلبها.

واجهة REST API العامة

بالنسبة للمستهلكين غير المتعاملين مع MCP، ثمة سطح REST موازٍ تحت /api/v1/: papers، وrepos، وarticles، وpine، وتجميع stats. يتحدث JSON بسيطاً مع المعطيات q، وcategory، وlimit، وoffset، ويعيد الإجمالي الحقيقي وتوزيع الأوجه إلى جانب كل صفحة، وهو مُفعَّل لـ CORS. GET /api/v1/papers?q=optimal+execution&category=q-fin.TR سطر واحد من أي مكان. وتقود نقطة النهاية نفسها صفحة /papers الخاصة بالموقع — فالمتصفح ليس سوى عميل API آخر.

الفشل بنزاهة

خلفية بحث تكذب أسوأ من خلفية معطلة. اتخذنا موقفاً متعمداً بشأن ما يحدث عندما يتعذر الوصول إلى Meilisearch. طبقة البيانات ترمي (throw) عند الفشل بدلاً من إعادة نتائج فارغة بصمت — والمستدعون يقررون كيف يتعاملون مع ذلك. بالنسبة لمجموعات البيانات التي ما زالت تحتفظ بنسخة في الذاكرة، تلجأ الأدوات إلى .filter() بسيط على تلك النسخة، بحيث يبقى الموقع قائماً. أما الأوراق، حيث يكون Meilisearch هو مصدر الحقيقة ولا توجد نسخة ثانية، فتعيد الأدوات وواجهة API خطأً صريحاً (تستجيب واجهة API بـ 503) بدلاً من تقديم بيانات قديمة أو جزئية. لكل استدعاء بحث مهلة قصيرة بحيث لا يستطيع فهرس معلّق أن يعطّل أداة. المبدأ: تدهور بصوت عالٍ، ولا تسلّم أبداً إجابات خاطئة بهدوء.

كيف تدخل البيانات

تتغذى المجموعة من خط أنابيب من المُجمِّعات (scrapers)، تعمل جميعها على مصادر مجانية وعامة.

• الأوراق تأتي من واجهة arXiv Atom API. يسحب حاصد المجموعة q-fin الكاملة إلى JSONL، وتوحّدها خطوة بناء مع المجموعة المنسقة (إزالة تكرار حسب معرّف arXiv، ودمج المصدر)، وتُسلّم النتيجة إلى المفهرس. كما أن للحاصد وضع "أثرِ هذه المعرّفات المحددة" لبذر البيانات من قوائم قراءة خارجية.
• الشيفرة هي زحف لمستودعات GitHub ذات الصلة بالكم، مُلتقطة مع البيانات الوصفية المهمة للتصفية — النجوم، والتفريعات (forks)، واللغة الأساسية، والموضوعات، وأعداد ملفات Python والدفاتر.
• المقالات تُكشط من مدونات الكم والمجمّعات، مع نسخ الأفضل منها محلياً بحيث تنجو من تعفّن الروابط. وتشير الصفحة الرئيسية إلى المقالات التي حفظنا منها نسخة محلية.
• الاستراتيجيات هي سكربتات Pine على TradingView مع بياناتها الوصفية — المؤلف، والفئة، والوسوم، والإعجابات، وما إذا كان المُدرَج يتضمن شيفرة، أو رسماً بيانياً، أو تحليلاً.
• مقاطع الفيديو تفهرس قنوات YouTube ذات الصلة بحيث تكون الأحاديث والشروحات قابلة للاكتشاف إلى جانب المواد المكتوبة.

تجري إعادة الفهرسة في الإنتاج عبر نفق SSH إلى Meilisearch المرتبط بـ localhost، لأن المحرك ليس مكشوفاً للإنترنت قط. الحلقة بأكملها — الحصاد، والبناء، والنشر، والفهرسة — مصممة لإعادة التشغيل بتكافؤ العمليات، وهو بالضبط ما يفعله الـ cron اليومي.

الوصول والاستضافة

يعمل researcher على خادمنا Server 1 ككومة Docker Compose صغيرة: حاوية Next.js خلف Traefik وحاوية Meilisearch مرتبطة بـ localhost. يقرأ تطبيق Next.js مجموعات بياناته من جانب الخادم ويتحدث إلى Meilisearch عبر الشبكة الداخلية.

الوصول مُبوَّب عبر auth.marketmaker.cc، خدمة الهوية المشتركة لدينا. الرموز هي JWTs من نوع RS256 يُتحقق منها مقابل JWKS الخاص بخدمة المصادقة — كل قرار تفويض يفحص التوقيع (مع فحوص صارمة للمُصدِر والخوارزمية، يفشل بإغلاق آمن إذا تعذر الوصول إلى نقطة نهاية المفتاح)، ولا يُستخدم مسار فك الترميز غير المتحقق منه إلا لواجهة تجميلية مثل عرض بريدك الإلكتروني في شريط التنقل. تصدر خدمة المصادقة أدواراً لكل خدمة؛ وعلى researcher يبوّب دور admin منطقة الإدارة الداخلية (حيث نشغّل المُجمِّعات ونراقبها)، والصفحة الرئيسية العامة لا تحتاج أي رمز على الإطلاق. إنه نسيج المصادقة نفسه الذي يتصدر أدواتنا الداخلية الأخرى، بحيث يحمل تسجيل دخول واحد عبر المنظومة كاملةً.

أين يقع في حزمة Marketmaker

researcher بنية تحتية، لا وجهة. المغزى ليس الموقع — بل أننا الآن نملك عرضاً قابلاً للاستعلام للمجال يتشاركه البشر والوكلاء.

بالنسبة لنا كبشر، إنه المكان الذي يأتي منه كثير من هذه المدونة نفسها. عندما نراجع أداة مثل VectorBT أو نشرّح إطار عمل مثل TradingAgents أو Fincept Terminal، تكون نقطة الانطلاق غالباً بحثاً عبر researcher: على أي أوراق يبني هذا، وأي مستودعات أخرى تحل المشكلة نفسها، ومن كتب عنها. الأرشيف هو القُمع؛ وتدوينات المدونة هي ما يتساقط منه.

بالنسبة لـ وكلاء الذكاء الاصطناعي لدينا، فالأمر أكثر بنيوية. أساس بحثي يمكن الوصول إليه عبر MCP يعني أن وكيلاً يعمل على الاستراتيجيات لا يحتاج إلى كشط arXiv حياً، أو التلاعب بأربع واجهات API مختلفة، أو التخمين بشأن ما هو متاح — بل يستدعي search_papers، وsearch_repos، وsearch_pine على مجموعة موحدة ومنزوعة التكرار ومفهرسة بالفعل. هذا هو الاتجاه نفسه الذي تسلكه أدوات الأمر والتشغيل (cmdop) وأدوات الوكلاء لدينا: امنح الوكلاء أدوات مكتوبة الأنواع، للقراءة فقط، حسنة التوثيق على بيانات حقيقية، وافشل بصوت عالٍ عند تعذر الوصول إلى الخلفية، ودع خلفية مشتركة واحدة تخدم واجهة الإنسان وواجهة الآلة من فهارس متطابقة. الإنسان يتصفح والوكيل يستعلم — لكنهما ينظران إلى الأرشيف نفسه، وهذه هي الفكرة برمتها.

الخاتمة

بدأ researcher بوصفه حلاً لمشكلة صغيرة ومزعجة — وهي أن الأبحاث الكمية مبعثرة عبر أربعة أماكن لا تتحدث إلى بعضها — وتحوّل إلى شيء نعتمد عليه يومياً. ما يقارب 51,000 مستند موزعة على الأوراق والشيفرة والمقالات والاستراتيجيات، كلها خلف محرك بحث نصي كامل واحد، كلها قابلة للوصول من قِبل إنسان بمتصفح ومن قِبل وكيل بعميل MCP. إنه عمداً غير برّاق: بحث نصي كامل، لا تضمينات؛ ومصدر واحد للحقيقة، لا ذاكرة تخزين مؤقت ذكية؛ وأدوات ترمي أخطاءً نزيهة، لا أدوات تتستر على الأعطال.

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