تصور کنید برنامه‌نویسی هستید که ساعت ۲ صبح با مستنداتی مواجه می‌شوید که هر صفحه‌اش حرفی متفاوت می‌زند و نمی‌دانید کدام قانون در لحظه جاری معتبر است. این دقیقاً همان نقطه‌ای است که Bot Lawyer وارد می‌شود تا به جای حدس زدن، بر اساس تاریخ اعتبار و سلسله‌مراتب منابع، حکم نهایی را صادر کند. این ابزار صرفاً به دنبال پاسخ نمی‌گردد، بلکه با نگاه به مستندات به عنوان یک کدبیس حقوقی که دارای تاریخ‌های اجرا و امتیازات اعتبار است، درباره آن‌ها حکم صادر می‌کند.
به گزارش توسعه‌دهنده این پروژه، دیسکورد سال‌هاست که اکوسیستمی تکه‌تکه از مراکز راهنما، مستندات API و نظرات کاربران در گیت‌هاب دارد که اغلب اعداد متناقضی را ارائه می‌دهند. این اصطکاک و سردرگمی در ۱۰ ژوئن ۲۰۲۶ به اوج رسید؛ زمانی که دیسکورد آستانه دسترسی به قابلیت‌های خاص (Privileged Intent) را از ۱۰۰ سرور به ۱۰,۰۰۰ کاربر منحصربه‌فرد تغییر داد. این تغییر باعث شد نیمی از مستندات رسمی دیسکورد قدیمی و متناقض شوند و توسعه‌دهندگان را در تضاد رها کنند.
حالا تصور کنید توسعه‌دهنده‌ای هستید که با ۱۰۰ سرور منتظر فعال شدن یک قابلیت است، اما مستندات API یک چیز می‌گویند و نظر یکی از کارکنان دیسکورد در گیت‌هاب چیز دیگری. Bot Lawyer دقیقاً برای حل این «استرس ساعت ۲ صبح» ساخته شده است تا یک منبع واحد و مستند برای حقیقت فراهم کند که گذر زمان و تغییر قوانین را در نظر می‌گیرد.
معماری حقیقت
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های زبانی اشاره کردیم، تکیه بر حافظه مدل برای داده‌های متغیر، ریسک توهم را بالا می‌برد. Bot Lawyer برای حل این مشکل، از تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — اما با یک چرخش ساختاری استفاده می‌کند. این رویکرد دقیقاً مشابه استراتژی‌هایی است که در پروژه پیمجو برای کاهش تیکت‌های پشتیبانی از طریق استخراج سخت‌گیرانه مستندات به کار گرفته شد تا دقت پاسخ‌ها تضمین شود.
این عامل به جای پایگاه‌داده‌های برداری سنتی، بر پایه Sanity Context و Vercel AI SDK بنا شده است. سازنده ابزار، محتوا را به‌گونه‌ای مدل‌سازی کرده که عامل بتواند روی داده‌ها استدلال کند، نه اینکه صرفاً کلمات کلیدی را جست‌وجو کند.
بر اساس مستندات فنی پروژه، این سیستم بر مجموعه‌ای از ۱۳۶ قانون استخراج‌شده از ۵۸ منبع در ۱۱ حوزه سیاستی تکیه دارد. هر قانون به عنوان یک ادعا با متادیتای مشخص تعریف شده است:
- appliesWhen: شرایطی شامل تعداد کاربر، تعداد سرور، اینتنت‌ها (Intents) و وضعیت تاییدیه (Verification State).
- effectiveFrom/To: تاریخ‌های دقیقی که بازه فعال بودن یک قانون را مشخص می‌کنند.
- Authority Score: سیستمی برای وزن‌دهی که در آن نظرات کارکنان دیسکورد در گیت‌هاب بر مقالات عمومی پشتیبانی اولویت دارند.
- Relationship Tags: برچسب‌هایی مثل
supersedes(جایگزین شد) یاconflictsWith(در تضاد است) برای مدیریت نسخه‌ها و تداخلات.
عبور از تله «۱۰۰ سرور»
در یک ساختار RAG معمولی، پرسشی درباره «۹۰ سرور و اینتنت محتوای پیام» احتمالاً جدولی قدیمی را برمی‌گرداند که آستانه ۱۰۰ سرور را تایید می‌کند. اما Bot Lawyer با بررسی تاریخ effectiveTo قانون قدیمی و دنبال کردن لینک جایگزینی (supersedes) به قانون جدید (۱۰,۰۰۰ کاربر)، از این تله می‌گریزد.
این عامل برای دقت حداکثری از دو نقطه اتصال (Endpoint) مجزا استفاده می‌کند:
۱. bot-lawyer-rules: حالتی مبتنی بر زبان GROQ که قوانین، منابع و حوزه‌های سیاستی را فیلتر کرده و حکم نهایی را صادر می‌کند.
۲. bot-lawyer-kb: یک پایگاه دانش شامل ۹۰ صفحه ثبت‌شده (Snapshot) که زمینه و متن کامل نقل‌قول‌ها را فراهم می‌کند.
فراتر از مستندات: سلیقه جامعه
علاوه بر قوانین فنی، این ابزار به عنوان یک معمار عملیاتی سرور عمل می‌کند. Bot Lawyer می‌تواند ساختارهای کامل کانال‌ها را پیشنهاد دهد — شامل ایموجی‌ها و جداکننده‌هایی مثل 👋┆welcome — در حالی که محدودیت‌های سخت‌گیرانه دیسکورد (مثل سقف ۵۰ کانال در هر دسته‌بندی و الزام حروف کوچک برای کانال‌های متنی) را رعایت می‌کند.
این عامل به‌طور صریح بین «قوانین دیسکورد» (محدودیت‌های فنی اجباری) و «سلیقه جامعه» (ترجیحات زیبایی‌شناختی و ترندها) تفکیک قائل می‌شود تا کاربران بدانند چه چیزی الزامی است و چه چیزی صرفاً یک پیشنهاد برای زیبایی است.
چالش‌های توسعه
توسعه این ابزار شکاف‌های بزرگی را در نحوه برخورد مدل‌های زبانی بزرگ (LLM) با تضادها آشکار کرد. طبق گزارش سازنده، در طول تست‌ها، مدل Claude 3 Haiku بارها نشانه‌های تضاد را نادیده گرفت و در حالی که منابع آشکارا با هم مخالف بودند، ادعا کرد که «منابع با هم موافق‌اند». این موضوع منجر به مهاجرت به مدل Claude 3.5 Sonnet و وضع یک دستورالعمل سخت‌گیرانه در پرامپت شد که مدل را مجبور می‌کند قبل از خواندن پایگاه دانش، حتماً کوئری‌های GROQ را اجرا کند.
چالش‌های فنی دیگر شامل خطاهای استقرار در Studio به دلیل تداخل نسخه‌بندی @sanity/icons و عبور از سقف پلن به دلیل پردازش اولیه بیش از ۳۰۰ سند ایندکس‌شده بود. در نهایت، توسعه‌دهنده مجموعه داده‌ها را به ۸۰ فایل باکیفیت کاهش داد تا بهینه‌تر شود.
عملکرد و اعتبارسنجی
برای تایید صحت عملکرد عامل، یک مجموعه آزمایشی ۴۰ سوالی بر اساس تضادهای شناخته‌شده طراحی شد. نتیجه، نرخ موفقیت ۳۹ از ۴۰ بود و هیچ‌کدام از ۸ سوال «تله» نتوانستند مدل را به پذیرش قانون قدیمی ۱۰۰ سرور ترغیب کنند.
تنها شکست ثبت‌شده، یک خطای ارجاع (Provenance Error) بود که در آن یک جمله خلاصه به‌جای نقل‌قول مستقیم ارائه شد. این مشکل با اجرای یک قانون سخت‌گیرانه تطبیق رشته‌ای (String Match) حل شد که در آن نقل‌قول‌ها باید دقیقاً با فیلد quote یا کلمات اصلی صفحه مطابقت داشته باشند.
هزینه دقت
اجرای این عامل روی مدل Sonnet حدود ۹ سنت برای هر پرسش هزینه دارد. برای جلوگیری از تخلیه سریع اعتبار API — پس از آنکه یک بعدازظهر به دلیل پرامپت‌های ۱۵,۰۰۰ توکنی بدون حافظه پنهان (Cache)، ۷ دلار هزینه شد — اکنون سیستم از پرامپت‌های سیستمی کش‌شده و سقف هزینه ۳ دلاری روزانه استفاده می‌کند.
این پروژه ثابت می‌کند که برای مستندات فنی حساس، یک گراف ساختاریافته از قوانین بسیار قابل‌اعتمادتر از جست‌وجوی برداری تکه‌های متن است. با کدگذاری «استدلال» در ساختار داده، عامل از حدس زدن دست می‌کشد و شروع به حکم دادن می‌کند.
اگر در حال حاضر یک جامعه دیسکورد را مدیریت می‌کنید و لیست کانال‌های شما ترکیبی آشفته از general-1 و general-2 است، اکنون می‌توانید از Bot Lawyer برای بازرسی ساختار خود در برابر قوانین رسمی و استانداردهای جامعه استفاده کنید.
گام بعدی شما
- اگر مدیر جامعه دیسکورد هستید، ساختار کانال‌های خود را با استانداردهای فعلی تطبیق دهید.
- برای پروژه‌های مشابه، به جای RAG ساده، از مدل‌سازی داده‌های ساختاریافته (Structured Data) استفاده کنید.
- در طراحی عامل‌ها، حتماً یک مجموعه داده «تله» (Trap Set) برای تست تضادها بسازید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو