TuBrief
Subscribed Channels
Videos
Community

دليل إعداد بيئة الأتمتة المحلية لبراهين Lean 4 للبحوث الرياضية

TuBrief Editorial
August 10, 2026
0
Computing/Software

Written with AI assistance from the source video. The video is the authority.

العربية한국어EnglishEspañol中文हिन्दीDeutschFrançaisPortuguêsРусскийBahasa Indonesia日本語

Related Video

OpenAI Astra يطور الرياضيات المتقدمة... بمقدار 10 أضعاف.6:03

OpenAI Astra يطور الرياضيات المتقدمة... بمقدار 10 أضعاف.

Better Stack

More from the community

사내 시스템에 llm api 붙일 때 마주하는 현실적인 한계와 대응법

September 13, 2026

레거시 백엔드에 GPT-6 Astra 붙일 때 예산 승인과 보안 통과를 먼저 끝내는 법이 있습니다

September 13, 2026

에이전트끼리 대화하다 6천만 원 청구서가 나오는 이유

September 13, 2026

사내 RAG 벡터 검색에 Okta 권한 필터를 직접 거는 방법

September 13, 2026

브라우저 에이전트에게 내 구글 계정을 통째로 넘기면 안 되는 이유

September 12, 2026

Apple Won the AI Race

September 12, 2026

Comments (0)

Log in to leave a comment

No posts yet

© 2026 . All rights reserved.

TuBrief
Subscribed Channels
Videos
Community
Log in

دليل إعداد بيئة الأتمتة المحلية لبراهين Lean 4 للبحوث الرياضية

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

بناء بيئة التحقق من براهين Lean المحلية

إن تثبيت Lean 4 يدوياً في بيئة التطوير والاعتماد على بروتوكول خادم لغة VS Code يسبب اختناقات خطيرة أثناء التحقق بواسطة الذكاء الاصطناعي واسع النطاق. إذا لم يتم تخزين الملفات الثنائية المعالجة مسبقاً لـ Mathlib4 مؤقتاً، فإن وحدة المعالجة المركزية المحلية ستقوم بإعادة تجميع مئات الآلاف من النظريات يدوياً، مما يستغرق أكثر من 180 دقيقة لمجرد إنشاء البيئة. لمعالجة عشرات أو أكثر من طلبات التحقق من الكود في الثانية، يجب الانتقال إلى خط أنابيب Kimina Lean Server القائم على FastAPI.

فيما يلي خطوات الإعداد المحددة لتقليل وقت إعداد مهمة التحقق من المسائل الرياضية طويلة الأمد من 180 دقيقة إلى أقل من 20 دقيقة:

  1. تثبيت إصدار أداة التطوير في ملف lean-toolchain في الدليل الجذر للمشروع. أدخل النص leanprover/lean4:v4.15.0 داخل الملف.
  2. افتح ملف الإعداد lakefile.lean وحدد حزمة Mathlib4 ومستودع repl الذي يتعامل مع الإدخال/الإخراج لـ JSON استناداً إلى stdio.

`lean
import Lake
open Lake DSL

package «proof_automation» {
}

require mathlib from git
"https://github.com/leanprover-community/mathlib4.git" @ "v4.15.0"

require repl from git
"https://github.com/leanprover-community/repl.git" @ "main"

@[default_target]
lean_lib «ProofAutomation» {
}

`

  1. افتح الطرفية (Terminal) ونفذ الأوامر التالية بالترتيب لتنزيل وبناء العناصر الثنائية المعالجة مسبقاً.

`bash
lake update
lake exe cache get
lake build

`

عند الانتهاء من هذه العملية، ستتلقى ذاكرة التخزين المؤقت المعالجة مسبقاً على الفور لتصبح بيئة تنفيذ REPL المحلية الكاملة جاهزة في غضون 20 دقيقة، مع القدرة على التحقق من ما يصل إلى 50 مقطع برهان في وقت واحد في الثانية.

تصميم توزيع الأدوار بين الوكيل الرئيسي والوكلاء الفرعيين

تؤدي محاولة إثبات نظريات معقدة من خلال استدعاء نموذج لغة كبير واحد إلى فقدان الأهداف الفرعية أو الدخول في حلقات لا نهائية كلما طال السياق. يجب تطبيق بنية رسم بياني موجه بلا دورات (DAG) تفصل الأدوار إلى وكيل رئيسي مسؤول عن تقسيم المشكلات ووكلاء فرعيين ينفذون تكتيكات فرعية معزولة.

من خلال اعتماد تنسيق JSON كمعيار لاتصالات الوكلاء وعزل النطاق لتمرير مطالبات (Prompts)، يمكنك تقليل استهلاك رموز API بنسبة تزيد عن 40 بالمائة. مخطط JSON المستخدم عند استدعاء الوكيل الفرعي هو كالتالي:

`json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "SubAgentProofTask",
"type": "object",
"properties": {
"task_id": { "type": "string" },
"target_hypothesis": { "type": "string" },
"current_goal_state": { "type": "string" },
"previous_failure_logs": {
"type": "array",
"items": {
"type": "object",
"properties": {
"attempted_tactic": { "type": "string" },
"error_message": { "type": "string" }
}
}
},
"sub_goal_target": { "type": "string" }
},
"required": ["task_id", "target_hypothesis", "current_goal_state", "sub_goal_target"]
}

`

ترتيب التحكم خطوة بخطوة لمنع الحلقات اللانهائية الناتجة عن هلوسة الوكيل وتشغيل بنية هرمية مستقرة هو كما يلي:

  1. عند ربط موجه الإدخال بالوكيل الفرعي، قم بإزالة سجل المحادثة بالكامل وتكوين الموجه بحيث يرسل 3 عناصر أساسية فقط: الفرضية، حالة الهدف (Goal State)، وسجلات الفشل السابقة.
  2. قم بتجزئة (Hashing) سلسلة proofState المُرجعة من Lean REPL باستخدام خوارزمية SHA-256 وحفظها في الذاكرة. إذا تم اكتشاف تكرار نفس تجزئة الحالة 3 مرات أو أكثر، فقم بتقليم فرع البحث هذا.
  3. اضبط مهلة زمنية مدتها 5 ثوانٍ لعملية تكتيكية واحدة و120 ثانية للبحث الكامل للوكيل الفرعي، وعند تجاوزها، أرسل إشارة SIGKILL لإعادة تنظيم عملية REPL على الفور.

استراتيجية إدارة السياق للتحكم في تكلفة رموز API

في مهام البحث عن البراهين التي تستغرق عدة ساعات، يؤدي إرسال سجل المحادثة بالكامل إلى واجهة برمجة التطبيقات للخلفية مع كل طلب إلى زيادة هائلة في استخدام الرموز (Tokens). يجب بناء طبقة التخزين المؤقت المستندة إلى LeanExplore وVector DB، والتحكم في النفقات العامة لرموز الإدخال عن طريق تلخيص نتائج التكتيكات الوسيطة التي تم التحقق منها مسبقاً وعكسها في الرسم البياني للذاكرة في شكل نظريات مساعدة.

قم بتسجيل معرف البيئة لجلسة REPL في خادم الخلفية لإزالة عبارات import Mathlib المتكررة في أعلى المطالبات. وحدها هذه الخطوة يمكنها تقليل رموز الإدخال بنسبة 50 إلى 70 بالمائة على الفور. إجراءات تنفيذ خط أنابيب التحكم لمنع انفجار تكاليف API بسبب تجاوز الحد الأقصى للميزانية هي كالتالي:

  1. أنشئ مسارات .leanflow/cache/ و .leanflow/workflow-state/ في دليل البيئة المحلي.
  2. اكتب وحدة CostMonitor المستندة إلى Python لتتبع وحساب الرموز والتكاليف المستهلكة أثناء استدعاءات API في الوقت الفعلي.
  3. عند الوصول إلى المبلغ الحدسي، قم بتشغيل نص برمجي يحفظ ملف لقطة نقطة التحقق (Checkpoint) ويوقف العملية بأمان.

`python
import sys
import json
import logging

class CostMonitor:
def init(self, max_budget_usd: float, token_cost_per_1k: float):
self.max_budget = max_budget_usd
self.cost_per_1k = token_cost_per_1k
self.total_tokens_used = 0
self.current_cost = 0.0

def track_usage(self, prompt_tokens: int, completion_tokens: int):
    tokens_in_call = prompt_tokens + completion_tokens
    self.total_tokens_used += tokens_in_call
    self.current_cost += (tokens_in_call / 1000.0) * self.cost_per_1k
    
    logging.info(f"[TELEMETRY] Used Tokens: {tokens_in_call} | Total Cost: ${self.current_cost:.4f}")
    
    if self.current_cost >= self.max_budget:
        self.trigger_safe_pause()

def trigger_safe_pause(self):
    logging.warning("[WARNING] Target budget threshold reached. Pausing workflow...")
    with open(".leanflow/workflow-state/checkpoint.json", "w") as f:
        json.dump({"status": "PAUSED_BUDGET_EXCEEDED", "tokens": self.total_tokens_used}, f)
    sys.exit(0)

`

تنفيذ حلقة التصحيح التلقائي لأخطاء كود البرهان

إن الطريقة التي يقوم فيها وكيل الذكاء الاصطناعي بتوليد الكود ثم مراجعة الأخطاء يدوياً تشكل عنق زجاجة قاتلاً للبحث بأكمله. يجب ربط بيانات تحليل JSON التي يصدرها مترجم Lean REPL (مثل أخطاء بناء الجملة، وعدم تطابق الأنواع، والأهداف التي لم تُحل) مباشرة كمدخلات تغذية مرجعية للوكيل.

طريقة عمل حلقة تحكم التصحيح التلقائي التي تحل محل المراجعة اليدوية وتضاعف سرعة البحث بأكثر من الضعف هي كالتالي:

  1. استلام استجابة JSON المُرجعة من Lean REPL واستخراج موقع الخطأ، رسالة خطأ النوع، والأهداف المتبقية كبيانات مهيكلة من خلال محلل Python التالي:

`python
def parse_lean_repl_output(repl_response_json: str):
data = json.loads(repl_response_json)
parsed_diagnostics = {
"has_error": False,
"errors": [],
"open_sorries": []
}

if "messages" in data:
    for msg in data["messages"]:
        if msg.get("severity") == "error":
            parsed_diagnostics["has_error"] = True
            parsed_diagnostics["errors"].append({
                "line": msg["pos"]["line"],
                "column": msg["pos"]["column"],
                "data": msg["data"]
            })
            
if "sorries" in data:
    for sorry in data["sorries"]:
        parsed_diagnostics["open_sorries"].append({
            "goal": sorry["goal"],
            "proof_state": sorry["proofState"],
            "line": sorry["pos"]["line"]
        })
        
return parsed_diagnostics

`

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

يتم تمرير الكود النظيف الذي تم التحقق منه بالكامل عبر أدوات التحويل doc-gen4 و paperproof ليتم إنشاؤه تلقائياً في صورة تصور للرسم البياني المنطقي وسياق LaTeX يمكن إدراجهما فوراً في ورقة البحث.

`bash
lake build LeanAutomation:docs
lean-graph extract --input Main.lean --output proof_dependency.json

`