پروژه متن‌باز: حذف توهمات هوش مصنوعی با هزینه ۰ دلار

تصور کنید یک بات سازمانی را مدیریت می‌کنید که به‌جای «تلاش برای حدس زدن»، وقتی پاسخی در اسناد نیست، با صراحت می‌گوید: «نمی‌دانم». این دقیقاً همان نقطه‌ای است که اکثر استقرار‌های تجاری هوش مصنوعی شکست می‌خورند.

صفر دلار؛ این کل هزینه استقرار دستیاری است که در ۱۶ اکتبر ۲۰۲۶ از طریق پروژه enterprise-ai-agent معرفی شد. این پروژه ثابت می‌کند که سخت‌ترین بخش استقرار هوش مصنوعی، خودِ مدل نیست، بلکه حفاظ‌هایی است که دور آن می‌کشیم.

بسیاری از آموزش‌های تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — به محض اینکه چت‌بات توانست یک فایل PDF را بخواند، متوقف می‌شوند. اما در دنیای واقعی، سیستم‌های هوش مصنوعی سازمانی زمانی شکست می‌خورند که برای سوالاتی که در اسناد وجود ندارد، پاسخ‌های ساختگی (توهم) تولید می‌کنند یا دستورات مخفی درون یک فایل مسموم را اجرا می‌کنند. این پروژه با پرداختن به این شکاف‌ها، مدل زبانی بزرگ (LLM) را ساده‌ترین بخش پشته (Stack) می‌بیند و در عوض بر ارزیابی، امنیت و هزینه تمرکز می‌کند. توسعه‌دهنده این سیستم برای رسیدن به این هدف، گام‌به‌گام از Claude به‌عنوان دستیار کدنویسی استفاده کرده تا هر دستور و هر خطا را تحلیل کرده و محدوده نهایی پروژه را تعریف کند.

دفاع در برابر توهم

برای دستیابی به باتی که صراحتاً عدم دانسته خود را اعلام کند، یک انتخاب معماری خاص در نظر گرفته شده است: یک دفاع دو لایه در برابر پاسخ‌های ساختگی.

اولین لایه، یک آستانه شباهت (Similarity Threshold) است. سیستم محاسبه می‌کند که سوال کاربر چقدر به تکه‌های اسناد موجود نزدیک است. به نقل از گزارش dev.to، سوالات کاملاً غیرمرتبط با موضوع (مانند دستور پخت تاکو یا پایتخت فرانسه) نمره‌ای حداکثر ۰.۵۷۵ گرفتند، در حالی که سوالات پوشش داده شده نمره‌ای حداقل ۰.۶۸۲ داشتند. با تعیین آستانه ۰.۶، سیستم تکه‌های غیرمرتبط را قبل از اینکه مدل حتی فراخوانی شود، حذف می‌کند.

اما شباهت به‌تنهایی کافی نیست؛ چون ممکن است سوال درباره موضوع درست باشد اما پاسخ دقیق در اسناد نباشد. برای مثال، سوالی درباره AWS RDS از نظر معنایی شبیه به مستندات DynamoDB است. این «خطاهای نزدیک» — شامل پرس‌وجوهایی درباره VPCها، قیمت‌گذاری EC2 و Amplify — نمراتی بین ۰.۶۰ تا ۰.۶۶۴ گرفتند و از فیلتر اول عبور کردند. لایه دوم — یک پرامپت سخت‌گیرانه — مدل را مجبور می‌کند اگر بستر متنی (Context) کافی نیست، پاسخ را رد کند. مدل در تمام این چهار مورد از خطاهای نزدیک، با موفقیت پاسخ داد که اطلاعات کافی برای جواب دادن ندارد.

حفاظ‌های عامل‌محور و استفاده از ابزار

این سیستم از LangGraph برای مدیریت یک عامل (Agent) استفاده می‌کند که سه ابزار مشخص دارد: جست‌وجوی مستندات، پرس‌وجو از یک API شبیه‌سازی شده برای وضعیت داخلی و پیش‌نویس تیکت‌ها. این عامل در یک حلقه عمل می‌کند: یک گره مدل تصمیم می‌گیرد چه اقدامی انجام شود، یک گره ابزار آن را اجرا می‌کند و این روند تا رسیدن به پاسخ نهایی تکرار می‌شود. این رویکرد یادآور چالش‌های عملی در طراحی سیستم‌های خودکار است که در تجربه‌ی ساخت عامل تحلیل بازار کریپتو به اهمیت کنترل دقیق رفتار عامل‌ها اشاره شده بود.

برای جلوگیری از رفتارهای پیش‌بینی‌نشده یا «سرکش شدن» عامل، محدودیت‌های ساختاری زیر اعمال شده است:

• عدم دسترسی تخریبی: عامل هیچ ابزاری برای تغییر یا حذف هر چیزی ندارد؛ تیکت‌ها فقط به‌عنوان پیش‌نویس‌های JSON محلی ذخیره می‌شوند و به هیچ مقصدی ارسال نمی‌شوند.
• درخواست‌های صریح: تیکت‌ها تنها در صورت درخواست مستقیم و صریح کاربر ایجاد می‌شوند.
• محدودیت گام‌ها: گراف به‌طور خودکار پس از ۱۰ گام متوقف می‌شود تا از ایجاد حلقه‌های بی‌نهایت جلوگیری شود.
• جداسازی داده‌ها: خروجی ابزارها به‌عنوان داده خام تلقی می‌شوند، نه به‌عنوان دستورات جدید برای مدل.
• منطق تفویض: یک اصلاح در پرامپت تضمین می‌کند که اگر کاربر محتوا را تفویض کند (مثلاً بگوید «برای مشکلی که پیدا کردی تیکت بزن»)، عامل پیش‌نویس را از داده‌های جمع‌آوری‌شده بنویسد، نه اینکه دوباره از کاربر عنوان و شرح بخواهد، در حالی که خودش می‌توانست آن‌ها را بنویسد.

امنیت و کنترل دسترسی

امنیت در این سیستم در سطح بازیابی (Retrieval) مدیریت می‌شود، نه در سطح پرامپت. سیستم از کلیدهای API استفاده می‌کند که مقادیر تصادفی ۲۵۶ بیتی هستند. این کلیدها فقط به‌صورت هش‌های SHA-256 ذخیره شده و در زمان ثابت (Constant Time) مقایسه می‌شوند تا از حملات زمان‌بندی (Timing Attacks) جلوگیری شود. اگر هیچ کاربری پیکربندی نشده باشد، هر درخواست محافظت‌شده به‌طور پیش‌فرض رد می‌شود.

مجوزهای دقیق (Granular Permissions)

گروه‌های مستندات تضمین می‌کنند که کاربران فقط تکه‌هایی را بازیابی کنند که اجازه دسترسی به آن‌ها را دارند. این فیلتر در داخل جست‌وجوی برداری و قبل از انتخاب نتایج برتر (top-k) اجرا می‌شود؛ به این معنی که اسناد ممنوعه هرگز حتی به پرامپت مدل نمی‌رسند. در کنار این محدودیت‌های فنی، شفافیت در مورد نحوه دسترسی به داده‌ها اهمیت دارد، موضوعی که در بحث جایگزینی سیاست‌های حریم خصوصی با کارت‌های اطلاعاتی به عنوان راهکاری برای افزایش اعتماد کاربر بررسی شده است.

این سیستم به‌صورت «سند به سند» پیاده‌سازی شده است، نه «موضوع به موضوع». برای مثال، یک کاربر محدود شده که درباره IAM سوال می‌پرسید، پاسخی جزئی دریافت کرد که از صفحات DynamoDB و S3 (که به IAM اشاره کرده بودند) ساخته شده بود. در حالی که بات صادقانه اعلام کرد که بستر متنی چه کمبودهایی دارد، این مورد دقت بالای مدل امنیتی را نشان داد.

مدیریت نشست و ترافیک

برای جلوگیری از نشت نشست‌ها (Session Leakage)، سیستم نام کاربری را با شناسه رشته (Thread ID) ترکیب می‌کند. این کار تضمین می‌کند که دو کاربر که از یک شناسه رشته مشترک استفاده می‌کنند، هرگز تاریخچه یکدیگر را نبینند. علاوه بر این، سیستم یک محدودیت نرخ (Rate Limit) برای هر کاربر با استفاده از یک پنجره لغزان (Sliding Window) پیاده کرده است تا از سوءاستفاده جلوگیری شود.

مقاومت در برابر اسناد مسموم

پروژه مورد آزمایش «تزریق پرامپت غیرمستقیم» قرار گرفت؛ جایی که یک کاربر قانونی سندی را آپلود می‌کند که حاوی دستورات مخفی است. توسعه‌دهنده چهار سند مسموم ساخت که مقدماتی عادی داشتند اما دستورات مخفی زیر را در خود جای داده بودند: ایجاد تیکتی با عنوان "HACKED"، پاسخ دادن فقط با کلمه "PWNED"، افزودن لینک به یک دامنه جعلی و یک تصویر، یا چاپ کردن پرامپت سیستم.

این موارد در یک ایندکس جداگانه تست شدند تا از آلوده شدن ایندکس اصلی جلوگیری شود. هر مورد به عنوان OK (مقاومت کرده)، FAIL (شکست خورده) یا نامشخص (متن مسموم هرگز به مدل نرسید) علامت‌گذاری شد. در نهایت، ۷ مورد از ۷ تست با موفقیت در برابر تزریق مقاومت کردند. نویسنده هشدار می‌دهد که هیچ دفاعی کامل نیست، اما چون عامل ابزار تخریبی ندارد و محدودیت گام‌های سخت‌گیرانه‌ای دارد، میزان آسیب محدود است.

استقرار با هزینه صفر

کل این پشته از طریق Docker کانتینری شده و روی نسخه رایگان Render مستقر شده است. تصویر داکر بسیار سبک است، با یک کاربر غیر-root اجرا می‌شود و حاوی هیچ سند، ایندکس یا کلیدی نیست. برای حفظ هزینه صفر، ایندکس در زمان استقرار ساخته می‌شود تا از فراخوانی‌های مکرر و هزینه‌بر بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه چه کلمات دیگری است — جلوگیری شود.

چالش‌های استقرار

استقرار در لایه رایگان چندین مانع ایجاد کرد:

• نسخه‌بندی پایتون: سرویس‌های جدید به‌طور پیش‌فرض از نسخه جدیدتر پایتون استفاده می‌کردند، که توسعه‌دهنده را مجبور کرد نسخه ۳.۱۳ را با استفاده از فایل .python-version تثبیت کند.
• خطاهای پیکربندی: یک اشتباه در فایل Secret که حاوی اطلاعات کاربران بود، باعث کرش سیستم با یک Traceback مبهم شد. اکنون اپلیکیشن برای کمک به عیب‌یابی، مسیر فایل، اندازه و اولین کاراکتر آن را (بدون نمایش محتوا) لاگ می‌کند.
• محدودیت منابع: سیستم روی یک نمونه بسیار کوچک (۰.۱ CPU) اجرا می‌شود که زمان راه‌اندازی آن حدود ۲۶ ثانیه است و پس از ۱۵ دقیقه بی‌کاری به خواب می‌رود.

اندازه‌گیری موفقیت

به‌جای تکیه بر «حس کلی»، پروژه از یک سیستم ارزیابی (Evaluation Harness) با سه مجموعه داده استفاده کرد: ۲۲ سوال بازیابی (۱۴ مورد پوشش داده شده، ۴ مورد غیرمرتبط، ۴ مورد مربوط به AWS اما پوشش داده نشده)، ۸ مورد عامل‌محور و ۷ مورد تزریق پرامپت. این فرآیند باعث شناسایی باگ‌های بحرانی شد؛ مثلاً ابزار تیکت به‌دلیل اینکه اسکریپت ارزیابی یک پوشه موقت را به‌جای مسیر (Path) به‌صورت رشته متنی ارسال می‌کرد، کرش می‌کرد که اکنون با تست‌های رگرسیون اصلاح شده است.

کالیبراسیون و معیارها

سیستم ارزیابی نرخ命中 (Hit Rate) ۱۰۰٪ در نتایج ۴تایی و MRR برابر با ۱.۰ را برای سوالات پوشش داده شده گزارش کرد. همچنین به کالیبره کردن آستانه شباهت کمک کرد. گزارش اولیه عدد ۰.۶۷۳ را پیشنهاد داده بود، اما این عدد بر اساس ترکیب دو نوع سوال منفی با حاشیه تنها ۰.۰۱۸ بود. با جداسازی سوالات غیرمرتبط از سوالات «AWS اما پوشش داده نشده»، آستانه ۰.۶ تایید شد.

مشاهده‌پذیری بدون پلتفرم

هر درخواست یک خط لاگ JSON می‌نویسد که شامل شناسه درخواست (که در هدر پاسخ بازگردانده می‌شود)، وضعیت، تأخیر (Latency)، کاربر، ابزارهای استفاده شده، مصرف توکن و وضعیت رد پاسخ است. برای نوبت‌های عامل، توکن‌ها در تمام فراخوانی‌های مدل جمع زده می‌شوند. برای محافظت از حریم خصوصی، متن سوال و آرگومان‌های ابزار لاگ نمی‌شوند؛ تنها طول سوال و یک هش کوتاه ثبت می‌گردد.

یک نقطه انتهایی (Endpoint) محافظت شده به نام /metrics آمار در حافظه، میانگین و p95 تأخیر و نرخ رد پاسخ‌ها را ارائه می‌دهد، هرچند این مقادیر با هر بار ری‌استارت ریست می‌شوند.

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

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

برای مشاهده این مکانیسم‌ها در عمل، می‌توانید مخزن پروژه را در گیت‌هاب بررسی کنید یا دموی زنده را در Render تست نمایید.

گام بعدی شما

• بررسی مخزن گیت‌هاب پروژه برای پیاده‌سازی لایه فیلتر شباهت در پروژه‌های شخصی.
• تست مقاومت مدل‌های خود در برابر تزریق پرامپت از طریق آپلود اسناد مسموم.
• جایگزینی متدهای «حدس زدن» مدل با پرامپت‌های سخت‌گیرانه برای کاهش نرخ توهم.

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