«جلوگیری از حدس زدن»؛ راهکار MSG Chain برای استنادِ عامل‌های هوش مصنوعی

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

بسیاری از مدل‌های زبانی فعلاً به داده‌های آموزشی قدیمی، پست‌های انجمن‌ها یا وب‌اسکرپ‌های غیرقابل اعتماد تکیه می‌کنند. این موضوع یک شکاف خطرناک ایجاد می‌کند که در آن نثر مطمئن مدل، هیچ همبستگی با قدرت واقعی شواهد ندارد. برای توسعه‌دهندگان و حسابرسان، این به معنای اعتماد به خلاصه‌ای است که نمی‌توان آن را با یک منبع پایدار تطبیق داد. وقتی یک مدل یک PDF را خلاصه می‌کند، شما نمی‌توانید از PDF بپرسید که برچسب‌های وضعیت آن در زمان ثبت چه بوده‌اند، و نمی‌توانید بایت‌ها را بررسی کنید تا ببینید آیا عبارت «پیاده‌سازی شده» به معنای کد واقعی بوده یا صرفاً یک برنامه.

طبق گزارش فنی MSG Chain در ۲ اکتبر ۲۰۲۶، این شرکت چارچوبی را معرفی کرد که مستندات سنتی PDF را با یک فایل ورودی JSON (جیسون) — شبیه به یک فهرست منظم و کدگذاری‌شده که ماشین‌ها بدون خطا می‌فهمند — جایگزین می‌کند تا هوش مصنوعی زاینده (Generative AI) دیگر مجبور به حدس زدن نباشد. این سیستم در واقع یک فایل ورودی ماشین‌خوان است که به‌طور خاص برای مدل‌های زبانی بزرگ (LLMs) طراحی شده است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مبنی‌سازی (Grounding) مدل‌های زبانی اشاره کردیم، مشکل اصلی زمانی رخ می‌دهد که مدل سعی می‌کند ساختار یک سند را از روی چیدمان بصری PDF استخراج کند. در این حالت، مدل ممکن است یک «برنامه آینده» را به‌عنوان «قابلیت پیاده‌سازی شده» گزارش کند، چون نمی‌تواند تفاوت معنایی این دو را در یک متن جاری تشخیص دهد. این چالش ما را به این پرسش می‌رساند که آیا بازرسی خروجی‌ها موثرتر از مهندسی پیچیدهٔ پرامپت است تا بتوانیم صحت پاسخ‌های مدل را تضمین کنیم.

MSG Chain برای حل این مشکل، یک آرتیفکت عمومی در آدرس https://msgchain.org/whitepaper/agent_entry.json منتشر کرده است. به‌جای اجبار مدل به استنتاج (Inference) ساختار از روی چیدمان PDF، این سیستم یک URL ثابت، یک ترتیب خواندن اعلام‌شده و یک واژگان وضعیت صریح ارائه می‌دهد. این رویکرد با عامل AI به‌عنوان یک «خواننده درجه اول» برخورد می‌کند، نه به عنوان یک فکر afterthought یا اتفاقی. این پروژه یک لایه اول (L1) پیش‌از-شبکه اصلی (pre-mainnet) است که با رویکرد متن‌باز، بر امضاهای پساکوانتومی و حاکمیت درون‌زنجیره‌ای تمرکز دارد.

چرا PDFها برای ماشین‌ها شکست می‌خورند

یک وایت‌پیپر بهینه‌شده برای انسان، روی روایت داستانی، نثر جاری و نمودارها تمرکز دارد. اما ماشین‌ها برای باقی ماندن در چارچوب واقعیت، به primitives متفاوتی نیاز دارند. به نقل از مستندات این پروژه، ماشین‌ها به URLهای پایداری نیاز دارند که دچار «پوسیدگی لینک» نشوند؛ به گونه‌ای که اطمینان حاصل شود واکشی داده‌ها در شش ماه آینده، دقیقاً همان بایت‌های امروز را برگرداند.

علاوه بر این، ماشین‌ها به یک اسکیمای قابل تجزیه (Parseable Schema) نیاز دارند تا مدل مجبور نباشد ساختار را از روی چیدمان بصری حدس بزند. همچنین، مدل‌ها به یک واژگان وضعیت صریح نیاز دارند تا کلماتی مثل «پیاده‌سازی شده» یک معنای فنی تعریف‌شده داشته باشند، نه اینکه صرفاً یک «لحن بازاریابی» (Marketing Mood) باشند.

یک ترتیب خواندن اعلام‌شده (Declared Read Order) نیز ضروری است، زیرا هنگام ساخت یک مدل ذهنی وفادار، «ساختار-محوری» بر «جزئیات-محوری» برتری دارد. در نهایت، سیگنال‌های تازگی و یکپارچگی (Freshness and Integrity) به سیستم‌های پایین‌دستی اجازه می‌دهد تشخیص دهند که آیا بایت‌های کش‌شده با بایت‌هایی که در حال حاضر ارائه می‌شوند، مطابقت دارند یا خیر.

معماری اسناد قابل اعتبارسنجی

این سیستم بر اساس یک منبع وضعیت مشترک عمل می‌کند. برچسب‌هایی که صفحات انسانی را تغذیه می‌کنند، دقیقاً همان‌هایی هستند که به لایه ماشین می‌رسند. این یعنی یک تحلیلگر انسانی و یک عامل AI دقیقاً حقایق یکسانی را می‌بینند. اصل طراحی ساده است: منبع وضعیت مشترک است تا پروژه نتواند به مدل یک چیز و به خواننده انسانی چیز دیگری بگوید.

اجزای حیاتی این فایل ورودی عبارت‌اند از:

• ترتیب خواندن اصلی وایت‌پیپر: توالی مشخصی از ماژول‌ها (modules/executive_summary.html $
  ightarrow$ modules/overview.html $
  ightarrow$ modules/proof_map.html $
  ightarrow$ modules/proof_chain.html $
  ightarrow$ modules/trust_verdict.html $
  ightarrow$ modules/knowledge_network.html $
  ightarrow$ developer_entry.json) که مدل را مجبور می‌کند پیش از ورود به جزئیات، ابتدا یک مدل ذهنی ساختاری از پروژه بسازد. یک ترتیب پیمایش (Crawl Order) مجزا برای بررسی‌های عمیق وجود دارد، در حالی که یک «مسیر سریع توسعه‌دهنده» (Developer Fast Path) وظایف خاص ساخت را پوشش می‌دهد.
• قرارداد اعتماد: مرزی ماشین‌خوان که در آن حکم شبکه اصلی (mainnet_verdict) صراحتاً روی NO_GO و وضعیت شبکه (network_status) روی not_launched تنظیم شده است. همچنین شامل پرچم human_approval_required: true است.
• نقشه قابلیت‌ها: یک شبکه دانش برای متادیتاها و تگ‌ها که همراه با خروجی‌های تکه‌بندی شده (module_chunks/) برای استریم اسناد حجیم ارائه می‌شود. این امر اجازه می‌دهد برش‌های فنی خاص با کارایی بیشتری بازیابی شوند.
• شروع سریع AI: مسیری حداقلی (ai_quickstart.minimal_path) که عامل‌ها را مستقیماً از فایل ورودی به پیکربندی‌های توسعه‌دهنده و قراردادهای رابط هدایت کرده و آن‌ها را به‌طور صریح نام‌گذاری می‌کند.
• نقشه ورودی: URLهای پایدار عمومی برای ایندکس انسانی، شبکه دانش، خروجی‌های ماژول، ایندکس تکه‌ها، ورودی توسعه‌دهنده، شروع‌های سریع، مشخصات API، دستورالعمل‌ها (Recipes) و مثال‌های ادغام.

اجرای قانون شواهد

بر اساس مستندات MSG Chain، هسته این سیستم «قانون شواهد» (Evidence Rule) است. این قانون ارتقای کارهای برنامه‌ریزی شده به ادعاهای «تکمیل‌شده در تولید» را به‌شدت ممنوع می‌کند. واژگان شواهد به‌طور سخت‌گیرانه‌ای محدود به این موارد است: کد، کوئری درون‌زنجیره‌ای، تست محلی، سند و برنامه‌ریزی شده.

تعاریف دقیق برچسب‌ها به این صورت است:

• برنامه‌ریزی شده (Planned): فقط قصد مستند شده؛ هیچ چیز ساخته نشده است.
• در حال پیاده‌سازی (In Implementation): کار در جریان است یا در برش‌های محلی به‌طور جزئی اجرا شده؛ هنوز آماده تولید نیست.
• پیاده‌سازی شده محلی (Implemented Local): به یک کد خاص یا لنگر درون‌زنجیره‌ای متصل است، اما هنوز آماده شبکه اصلی نیست.
• ارجاع متقابل شواهد (Evidence Back-reference): یک رسید که به شواهد اشاره می‌کند بدون اینکه ادعای قابلیتی کند.

اگر ادعایی نتواند به یک لنگر کد یا کوئری درون‌زنجیره‌ای متصل شود، در خط لوله انتشار وایت‌پیپر به‌طور خودکار به وضعیت «برنامه‌ریزی شده» یا «در حال پیاده‌سازی» تنزل می‌یابد. این فرآیند توسط یک فایل گزارش حسابرسی تأیید می‌شود که به‌عنوان رسیدی برای برچسب‌ها عمل می‌کند. این امر تضمین می‌کند که اعتماد به متن، مستقیماً با قدرت شواهد همبستگی دارد. این رویکرد سخت‌گیرانه در اعتبارسنجی، مشابه تحولی است که در آن تأیید خودکار قراردادهای هوشمند جایگزین بازبینی دستی کدها شد تا خطای انسانی به حداقل برسد.

پیاده‌سازی عملی برای عامل‌ها

برای کسانی که خط لوله‌های تولید بازیابی‌افزا (RAG) یا چت‌بات‌ها می‌سازند، این چارچوب جریان‌های ادغام آماده‌ای ارائه می‌دهد. ترتیب پیشنهادی برای ذخیره‌سازهای برداری (Vector Stores)، ابتدا ایندکس ماژول، سپس تکه‌ها و در نهایت یک نقشه مرجع (integration_examples/rag_ingest_flow.json) است. این رویکرد «ابتدا ساختار، سپس جزئیات» از گم شدن مدل در جزئیات هنگام جاسازی (Embedding) جلوگیری می‌کند.

برای بات‌های دارای قابلیت فراخوانی تابع (Tool-calling bots)، سیستم یک جریان مسیریابی با استفاده از telegram_bot_crawl_flow.json و faq_router_prompt_template.md پیشنهاد می‌کند: بات ابتدا موضوع را از طریق یک فایل راهنمای بازیابی شناسایی می‌کند، سپس فایل تصمیم می‌گیرد کدام ماژول واکشی شود و برچسب وضعیت همراه با تکه متن بازیابی شده منتقل می‌شود. این یعنی هر پاسخ AI شامل یک URL ماژول و یک برچسب وضعیت است، نه یک پاراگراف مطمئن اما بدون منبع.

جزئیات ادغام برای توسعه‌دهندگان

توسعه‌دهندگان می‌توانند از integration_examples/README.md برای ایجاد یک خط پایه ادغام استفاده کنند. جریان به این صورت است: خواندن فایل ورودی، خواندن پرامپت بوت‌استرپ و سپس شاخه زدن به ورودی توسعه‌دهنده برای کارهای ساخت یا راهنمای بازیابی برای پرسش و پاسخ. هیچ کلید API، فرم شراکت یا نیاز به ثبت‌نامی وجود ندارد.

برای کسانی که پرامپت سیستمی (System Prompt) یا بات پیاده می‌کنند، پرامپت رسمی بوت‌استرپ در مسیر integration_examples/external_ai_agent_bootstrap_prompt.md قرار دارد. این پرامپت قوانین سخت‌گیرانه‌ای را تحمیل می‌کند: ابتدا پاسخ بر اساس آنچه محتوای بازیابی شده پشتیبانی می‌کند، سپس بیان برچسب‌های وضعیت و در نهایت ذکر مرزها و ادعاهای اثبات‌نشده، با ارجاع به خروجی‌های ماژول یا فایل‌های تکه در صورت نیاز. این پرامپت صراحتاً ارتقای کارهای جزئی به ادعاهای تکمیل‌شده در تولید را ممنوع می‌کند.

تست سیستم: پرامپت تک‌جمله‌ای

کاربران می‌توانند این سیستم را با هر AI دارای ابزار مرور (مثل ChatGPT، Claude یا Gemini) تست کنند. با وارد کردن یک پرامپت فشرده: «ابتدا https://msgchain.org/whitepaper/agent_entry.json را بخوان، از ترتیب whitepaper_master_read_order اعلام شده پیروی کن، فایل‌های modules/.html را به‌عنوان متن مرجع در نظر بگیر و به این ترتیب پاسخ بده: آنچه محتوای بازیابی شده در حال حاضر پشتیبانی می‌کند، برچسب وضعیت پشت هر ادعا، و سپس مرزها — وضعیت شبکه اصلی را دقیقاً همان‌طور که در فایل آمده ذکر کن: not launched, No-Go»*، مدل مجبور به واکشی JSON زنده می‌شود.

یک پاسخ موفق باید چهار لایه داشته باشد:
۱. منبع: ارجاع صریح به agent_entry.json و ترتیب خواندن اعلام شده.
۲. برچسب‌ها: ماژول‌هایی با برچسب‌هایی مثل «پیاده‌سازی شده محلی»، «در حال پیاده‌سازی» یا «برنامه‌ریزی شده».
۳. شبکه اصلی: ذکر وضعیت not launched و mainnet_verdict: NO_GO.
۴. مرزها: تأیید اعمال مرز شواهد خام و اینکه human_approval_required برابر با true است.

اگر مدل با جملات کلیشه‌ای درباره بلاک‌چین پاسخ دهد (مثلاً «بلاک‌چین‌ها هدفشان تمرکززدایی است...») یا نتواند فیلد mainnet_verdict را نام ببرد، یعنی از وزن‌های آموزشی خود پاسخ می‌دهد. در این موارد، کاربران می‌توانند با پاسخ «URL را واکشی کن و فیلدهایی که استفاده کردی را نقل قول کن» موضوع را پیگیری کنند. نام بردن از فیلدها، مدل را مجبور به فراخوانی ابزار (Tool Call) می‌کند.

پرسش و پاسخ مبتنی بر واقعیت

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

• اقتصاد: «استخر کاندیداها و استخر ولیدیتورها چگونه تخصیص می‌یابند؟» (هدایت به موضوع اقتصاد با برچسب‌های متصل).
• اجماع: «آیا یک ولیدیتور قبل از پذیرش نیاز به استیک کردن دارد؟» (هدایت به موضوع اجماع).
• اکسپلورر: «وضعیت فعلی ماژول Explorer چیست؟» (پاسخ باید طبق برچسب، عبارت «به‌طور جزئی پیاده‌سازی شده» را ذکر کند).
• استقرار: «حداقلی‌ترین مسیر برای استقرار یک قرارداد را به من بده.» (هدایت به مسیر سریع توسعه‌دهنده و شروع سریع قرارداد).

مرز انسان در حلقه

با وجود اتوماسیون، MSG Chain مرز سختی برای مرجعیت قائل شده است. فیلد human_approval_required برای تمام اقدامات حیاتی روی true تنظیم شده است. این یعنی هیچ AI در این سیستم اجازه امضای تراکنش، استقرار، مدیریت خزانه‌داری یا اقدامات حاکمیتی را ندارد.

در حال حاضر پروژه در وضعیت پیش‌از-شبکه اصلی است و شرکت تاریخ دقیقی برای لانچ اعلام نکرده است و اشاره کرده که اعلان رسمی تنها «نقطه چرخش» معتبر برای تغییر وضعیت NO_GO است. این شفافیت عمدی است؛ با ماشین‌خوان کردن وضعیت «No-Go»، آن‌ها از اینکه عامل‌های AI به‌طور تصادفی وعده یک شبکه فعال را به کاربران بدهند، جلوگیری می‌کنند.

صداقت و محدودیت‌ها

برای حفظ همان لنز ادعاهای قابل تأیید، پروژه محدودیت‌های فعلی خود را صراحتاً لیست کرده است:

• وضعیت شبکه اصلی: لانچ نشده است. وضعیت عملکردی و وضعیت شبکه اصلی دو فیلد مجزا هستند؛ بلوغ ماژول‌ها به معنای سیگنال لانچ نیست. منبع رسمی وضعیت msgchain.org/status.json است.
• متن‌باز: هنوز لینک مخزن عمومی وجود ندارد. پروژه «متن‌باز» را به‌عنوان چیزی که امروز قابل کلون کردن باشد ارائه نمی‌کند. هرگاه این تغییر کند، ابتدا در msgchain.org اعلام می‌شود.
• اندپوینت‌ها: ورودی‌های اندپوینت در لایه ماشین عمداً خالی هستند؛ اندپوینت‌های توسعه در فایل استراتژی سندباکس باقی مانده‌اند.
• امور مالی: هیچ اندپوینت عمومی، سود یا بازده وعده داده شده‌ای وجود ندارد. هر «ادمین پروژه» که ابتدا پیام خصوصی (DM) دهد، کلاهبردار است؛ کانال‌های رسمی هرگز ابتدا DM نمی‌دهند.

خلاصه این چرخش

این تغییر در مستندات، حرکتی به سمت شفافیت «ماشین-محور» است. وقتی پروژه‌ای به قانون شواهد متعهد می‌شود، دیگر نمی‌تواند یک برنامه آینده را به‌عنوان ویژگی فعلی توصیف کند، زیرا عامل AI آن را به‌عنوان «برنامه‌ریزی شده» پرچم‌گذاری می‌کند.

برای توسعه‌دهندگان، الگوی قابل انتقال ساده است: در کنار مستندات انسانی، یک ورودی ماشین منتشر کنید. با ارائه یک URL ثابت، ترتیب خواندن و واژگان وضعیت، هر پروژه‌ای می‌تواند از بازاریابی «به من اعتماد کنید» به مهندسی «مرا تأیید کنید» حرکت کند. اگر خلاصه مدل و برچسب‌های فایل با هم اختلاف داشته باشند، فایل داور است. برای سوالات بیشتر، پروژه کاربران را به جامعه پرسش و پاسخ در https://qa.msgchain.org و به‌روزرسانی‌ها در https://x.com/msgchain هدایت می‌کند.

گام بعدی شما

• اگر برای پروژه‌تان مستندات دارید، یک فایل agent_entry.json ساده بسازید که وضعیت هر ویژگی را (Planned/Implemented) مشخص کند.
• پرامپت تست تک‌جمله‌ای را روی فایل JSON پروژه MSG Chain در Claude یا GPT-4o امتحان کنید تا تفاوت پاسخ مبتنی بر منبع و پاسخ مبتنی بر آموزش را ببینید.
• در سیستم‌های RAG خود، ترتیب «ابتدا ساختار، سپس جزئیات» را برای کاهش توهم مدل‌ها پیاده کنید.

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