معماری Dhi: نقشه راه ساخت IDE هوش مصنوعی کاملاً متن‌باز

اگر شما یک توسعه‌دهنده هستید که از هزینه‌های اشتراکی یا محدودیت‌های حریم‌خصوصی در IDEهای ابری خسته شده‌اید، باید بدانید که دیگر نیازی به وابستگی به غول‌های فناوری نیست. پروژه Dhi (به معنای «عقل خالص» در مانترای گایاتری) ثابت کرد که می‌توان یک محیط برنامه‌نویسی پیشرفته را تنها با قطعات متن‌باز و بدون حتی یک درخواست به APIهای بسته ساخت. این پروژه نشان می‌دهد که می‌توان فاصله میان «تصور برنامه‌نویس» و «کد نهایی» را به حداقل رساند و یک الگوی کاملاً قابل تکثیر برای سیستم‌های هوش مصنوعی ارائه داد.

طبق مستنداتی که در ۲۳ ژوئن ۲۰۲۶ منتشر شد، این معماری با هدف حفظ قابلیت‌های با عملکرد بالا و در عین حال حذف وابستگی به اکوسیستم‌های بسته طراحی شده است.

نمای کلی معماری

IDEهای مدرن هوش مصنوعی معمولاً به عنوان لایه‌های ارکستراسیون برای چندین جزء کلیدی عمل می‌کنند: سرورهای زبان (Language Servers)، جستجوی برداری (Vector Search)، مدل‌های زبانی با قابلیت فراخوانی ابزار (Tool-calling LLMs) و محیط‌های اجرای ایزوله (Sandboxed Execution). سیستم Dhi به صورت یک برش عمودی از لایه‌هایی طراحی شده که هر کدام به طور مستقل قابل استقرار هستند و از طریق یک گذرگاه محلی JSON-RPC با هم ارتباط دارند؛ پروتکلی که دقیقاً مشابه استاندارد مورد استفاده در VS Code برای پروتکل سرور زبان (LSP) است.

جریان داده در این سیستم از رابط کاربری (IDE Frontend) شروع شده و از طریق یک هسته ارکستراسیون مبتنی بر JSON-RPC/WebSocket (که شامل LangGraph، یک مسیریاب ابزار یا Tool Router و یک جمع‌کننده زمینه یا Context Assembler است) به موتورهای تخصصی منتقل می‌شود. این موتورها عبارتند از: موتور تکمیل کد (FIM)، موتور چت (Chat)، موتور عامل (Agent) و سندباکس اجرا (Execution Sandbox). این موتورها توسط یک لایه مدل (شامل Ollama, vLLM, StarCoder2, DeepSeek) و یک لایه هوشمندی مخزن (شامل Tree-sitter, Chroma, LSP) پشتیبانی می‌شوند.

لایه ۱: درک مخزن کد (Repo Understanding)

بسیاری از تلاش‌های متن‌باز در زمینه IDEهای هوش مصنوعی به دلیل استفاده از روش‌های ساده و ابتدایی تکه‌بندی فایل‌ها (Naive File-splitting) شکست می‌خورند. Dhi این مشکل را با بهره‌گیری از Tree-sitter حل می‌کند. این ابزار قادر است درخت‌های نحو concrete (CST) را برای بیش از ۴۰ زبان برنامه‌نویسی در زمان کمتر از ۵ میلی‌ثانیه برای هر فایل ایجاد کند. به جای اینکه کدها را بر اساس تعداد کاراکترها تکه تکه کند، آن‌ها را بر اساس مرزهای معنایی مانند توابع، کلاس‌ها و بدنه متدها تقسیم می‌کند تا تکه‌تکه‌شدن معنای کد (Context Fragmentation) رخ ندهد.

خط لوله بازیابی داده‌ها (Retrieval Pipeline) مسیر دقیقی را طی می‌کند: ابتدا فایل‌های منبع دریافت می‌شوند $ o$ توسط Tree-sitter (متناسب با هر زبان) تحلیل می‌شوند $ o$ به تکه‌های معنایی تبدیل می‌شوند $ o$ لایه‌ای از متاداده‌ها (مانند مسیر فایل، محدوده خط و نام نماد) به آن‌ها اضافه می‌شود $ o$ توسط مدل nomic-embed-text-v1.5 (با ۷۶۸ بُعد که به صورت محلی اجرا می‌شود) برداری می‌شوند $ o$ و در نهایت در Chroma (برای محیط توسعه) یا Qdrant (برای محیط عملیاتی) ذخیره می‌شوند.

برای مدیریت روابط ساختاری، سیستم یک «لایه گراف فراخوانی» (Call Graph Layer) را پیاده‌سازی کرده است. جستجوی برداری خالص می‌تواند کدهای مشابه از نظر معنایی را پیدا کند، اما وابستگی‌های کد را نادیده می‌گیرد. با ساخت یک گراف ارجاع نمادها از طریق فراخوانی‌های textDocument/references در LSP و ذخیره آن به صورت یک لیست مجاورت در SQLite، سیستم می‌تواند پیمایش‌های گراف را برای یافتن تمام توابعی که با یک میان‌افزار (Middleware) خاص در ارتباط هستند انجام دهد، به جای اینکه تنها به جستجوهای تقریبی یا Fuzzy Search تکیه کند.

لایه ۲: موتور تکمیل خودکار (Autocomplete Engine)

تکمیل خودکار در Dhi از منطق Fill-in-the-Middle یا FIM استفاده می‌کند. در این روش، مدل یک <fim_prefix> (شامل ۳ تکه بازیابی شده برتر و خطوط از ابتدا تا مکان‌نما) و یک <fim_suffix> (خطوط از مکان‌نما تا انتهای فایل) را می‌بیند تا بتواند دقیق‌ترین <fim_middle> یا همان تکمیل کد را تولید کند.

• مشخصات مدل‌های مورد استفاده:
  • StarCoder2-3B: دارای ۳ میلیارد پارامتر، پشتیبانی داخلی از FIM، قابل اجرا بر روی Apple M2 یا GPU با ۸ گیگابایت حافظه.
  • Qwen2.5-Coder-7B: دارای ۷ میلیارد پارامتر، پشتیبانی داخلی از FIM، قابل اجرا بر روی GPU با ۱۶ گیگابایت حافظه.
  • DeepSeek-Coder-V2-Lite: دارای ۱۶ میلیارد پارامتر، پشتیبانی داخلی از FIM، قابل اجرا بر روی GPU با ۲۴ گیگابایت حافظه.
  • CodeLlama-13B: دارای ۱۳ میلیارد پارامتر، پشتیبانی داخلی از FIM، قابل اجرا بر روی GPU با ۲۴ گیگابایت حافظه.
• اهداف عملکردی: هدف برای تأخیر (Latency) زیر ۱۵۰ میلی‌ثانیه برای P50 و زیر ۴۰۰ میلی‌ثانیه برای P95 است.
• منطق سرویس‌دهی: در محیط عملیاتی از vLLM برای بهره‌مندی از PagedAttention (که حافظه را تا حدود ۴۰٪ کاهش می‌دهد) و دسته‌بندی مداوم (Continuous Batching) برای حذف صف‌های انتظار استفاده می‌شود.

برای افزایش بیشتر سرعت، Dhi از رمزگشایی گمانه‌زنانه (Speculative Decoding) بهره می‌برد. در این روش، یک مدل پیش‌نویس کوچک (StarCoder2-1B) با یک مدل تأییدکننده بزرگ جفت می‌شود. مدل پیش‌نویس K توکن را تولید می‌کند و مدل تأییدکننده آن‌ها را در یک پاس رفت (Forward Pass) پذیرفته یا رد می‌کند. این مکانیسم توان عملیاتی موثر را ۳ تا ۵ برابر افزایش می‌دهد.

لایه ۳: چت در ویرایشگر (Chat-in-Editor)

تمرکز بخش چت بر روی «جمع‌آوری زمینه» (Context Assembly) است. جمع‌کننده زمینه (Context Assembler) داده‌ها را در شش جایگاه (Slot) مشخص سازماندهی می‌کند تا با محدودیت‌های مدل سازگار شود:
۱. پرامپت سیستمی (حدود ۵۰۰ توکن)
۲. فایل فعال + بخش انتخاب شده (حدود ۲,۰۰۰ توکن)
۳. تشخیص‌های LSP یا همان خطاها و هشدارها (حدود ۵۰۰ توکن)
۴. تکه‌های بازیابی شده RAG (حدود ۴,۰۰۰ توکن)
۵. تاریخچه گفتگو (حدود ۲,۰۰۰ توکن)
۶. پیام کاربر (باقی‌مانده بودجه توکن‌ها)

در بک‌اند از مدل‌های تنظیم شده برای دستورالعمل‌ها (Instruction-tuned) مانند Qwen2.5-Coder-32B-Instruct، DeepSeek-V3 یا Llama-3.3-70B-Instruct استفاده می‌شود که توسط Ollama یا vLLM سرویس‌دهی می‌شوند. یک نکته حیاتی در تجربه کاربری (UX)، استریم کردن توکن‌ها به پنل چت در زمان واقعی از طریق SSE است، اما بلوک‌های کد بافر می‌شوند تا تنها زمانی که بلوک کامل رسید در ویرایشگر اعمال شوند تا از لرزش یا پرش صفحه (Flickering) جلوگیری شود.

لایه ۴: ویرایش عامل چندفایله (Multi-File Agent Editing)

ویرایش چندین فایل به طور همزمان از یک حلقه «برنامه‌ریزی-اقدام-مشاهده» (Plan-Act-Observe) استفاده می‌کند که توسط LangGraph پشتیبانی می‌شود. این سیستم فرآیند را به عنوان یک گراف جهت‌دار از گره‌ها مدل می‌کند: (تفکر $ o$ اقدام $ o$ مشاهده $ o$ برنامه‌ریزی $ o$ تایید).

• مجموعه ابزارهای عامل:
  • read_file(path): محتویات فایل را برمی‌گرداند.
  • write_file(path, content): تغییرات (diffs) را اعمال می‌کند.
  • search_codebase(query): جستجوی ترکیبی برداری و کلمات کلیدی.
  • run_command(cmd): دستور را در یک شل ایزوله اجرا می‌کند.
  • list_directory(path): درخت فایل‌ها را مشاهده می‌کند.
  • get_diagnostics(): خطاها و هشدارهای LSP را بازیابی می‌کند.
  • get_references(symbol): جستجو در گراف فراخوانی‌ها.
  • create_file / delete_file: مدیریت فایل‌ها با قابلیت پشته بازگشت (Undo Stack).

قابلیت Checkpointing در LangGraph حیاتی است، زیرا به سیستم اجازه می‌دهد وضعیت را روی دیسک سریالیزه کند و بازنویسی‌های طولانی که ده‌ها فایل را در بر می‌گیرد، پس از وقفه دوباره از سر بگیرد.

لایه ۵: طراحی سیستم و استدلال

سوالات در سطح معماری توسط یک سازنده خلاصه مخزن (Repo Summary Builder) مدیریت می‌شوند. این ابزار برای هر دایرکتوری یک خلاصه تک‌پارگرافی توسط LLM می‌سازد که در نهایت منجر به ایجاد یک نقشه پروژه با حدود ۸ هزار توکن می‌شود. این نقشه توسط مدل‌های استدلالی (Reasoning Models) مانند DeepSeek-R1 یا QwQ-32B پردازش شده تا نمودارها را در قالب Mermaid یا PlantUML خروجی دهد. برای حفظ کارایی، خلاصه یک بار ساخته شده و سپس به صورت افزایشی و با استفاده از git diff برای بازخوانی تنها ماژول‌های تغییر یافته، به‌روزرسانی می‌شود.

لایه ۶: حلقه اجرای کد ایمن

برای جلوگیری از اینکه کدهای تولید شده توسط LLM باعث به خطر افتادن سیستم میزبان شوند، Dhi یک سندباکس اجرایی سخت‌گیرانه با استفاده از Docker، gVisor یا Firecracker (میکرو-VMها) پیاده‌سازی کرده است.

• محدودیت‌های سندباکس:
  • ایزولاسیون: عدم دسترسی به سیستم فایل میزبان، شبکه یا متغیرهای محیطی.
  • ناپایداری (Ephemeral): کانتینرها پس از هر بار اجرا تخریب می‌شوند.
  • محدودیت منابع: ۵۱۲ مگابایت حافظه و زمان انتظار (Timeout) ۳۰ ثانیه.
  • امنیت: محدود کردن syscallها از طریق seccomp و استفاده از Bind Mountهای فقط‌خواندنی برای فایل‌های پروژه (فقط دایرکتوری /tmp قابل نوشتن است).

این ساختار یک حلقه خودبهبود ایجاد می‌کند: نوشتن کد $ o$ اجرای تست‌ها $ o$ شکست $ o$ مشاهده stderr $ o$ برنامه‌ریزی مجدد $ o$ نوشتن کد. این چرخه معمولاً برای باگ‌های ساده در ۲ تا ۳ تکرار به نتیجه می‌رسد.

پشته کامل متن‌باز (Open-Source Stack)

چالش‌های پیاده‌سازی

علیرغم در دسترس بودن ابزارهای متن‌باز، سه مشکل سخت باقی مانده است. اول، تأخیر در سیستم‌های با VRAM کم: یک مدل ۳۲ میلیارد پارامتری روی GPU با ۲۴ گیگابایت حافظه تنها به سرعت ۱۵-۲۰ توکن در ثانیه می‌رسد. این امر نیاز به کوانتش (GGUF Q4) یا رمزگشایی گمانه‌زنانه برای کاهش اثرات منفی دارد. دوم، باطل کردن کش پرامپت (Prompt Cache Invalidation) در vLLM بدون داشتن یک ارائه‌دهنده مدیریت‌شده، پیاده‌سازی دشواری است. سوم، تازگی اندکس‌ها (Index Freshness) نیازمند بازسازی افزایشی با تأخیر (Debounced Incremental Re-indexing) است تا ذخیره‌ساز برداری با ضربات کلید فعال کاربر همگام بماند.

در نهایت، امنیت همچنان یک ریسک است. در حالی که سندباکس تست‌ها را مدیریت می‌کند، عامل‌هایی که دسترسی write_file به تنظیمات CI یا اسرار (Secrets) دارند، خطرناک هستند. Dhi توصیه می‌کند از یک لیست سفید (Allowlist) برای مسیرها و تأیید دستی توسعه‌دهنده برای نوشتن فایل‌ها خارج از دایرکتوری کاری استفاده شود.

این معماری نشان می‌دهد که مزیت رقابتی برای IDEهای هوش مصنوعی دیگر در ابزارهای پایه نیست، بلکه در سال‌ها تکرار و بهبود تجربه کاربری (UX) نهفته است. توسعه‌دهندگان می‌توانند پیاده‌سازی این سیستم را در github.com/sochaty/dhi بررسی کنند.

گام بعدی شما

• معماری Dhi را در GitHub بررسی کنید تا با نحوه پیاده‌سازی لایه ارکستراسیون با LangGraph آشنا شوید.
• اگر از مدل‌های محلی استفاده می‌کنید، ترکیب vLLM و مدل‌های StarCoder را برای تجربه تکمیل کد سریع‌تر تست کنید.
• برای ایمن‌سازی اجرای کدهای تولید شده توسط AI، استراتژی سندباکسینگ با gVisor را مطالعه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.