تصور کنید یک فهرست فنی دارید که در آن کاربر نمی‌تواند ورودی مورد نیاز خود را پیدا کند، مگر اینکه از قبل پاسخ را بداند؛ در چنین حالتی، آن ابزار عملاً بی‌فایده است. این شکست بنیادین در دسترسی به اطلاعات، در ۲۴ سپتامبر ۲۰۲۶ طی یک تست کور روی کاتالوگ خطاهای تاییدشده‌ای که توسط Tirthahq منتشر شده بود، توسط کاربر mansio@ افشا شد.
بسیاری از مستندات هوش مصنوعی از یک شکاف زبانی بنیادین رنج می‌برند. مهندسان فهرست‌ها را بر اساس «تشخیص نهایی» — یعنی علت فنی و ریشه‌ای یک باگ — می‌نویسند، در حالی که کاربران با یک «شکایت» درباره رفتار سیستم وارد می‌شوند. اگر فهرست شما بر اساس تشخیص کلیدگذاری شده باشد، به‌جای اینکه ابزاری برای کشف راهکار باشد، تبدیل به واژه‌نامه‌ای برای متخصصان می‌شود که از پیش می‌دانند به دنبال چه هستند.
برای درک بهتر، فرض کنید در حال عیب‌یابی یک عامل (Agent) — شبیه دستیاری که می‌تواند کارهای پیچیده را به‌جای شما انجام دهد — هستید. شما با این فکر شروع نمی‌کنید که «من مشکلی در نویز رتبه‌بندی در یک اجرای واحد (single-run ranking noise) در دمای صفر دارم»، بلکه می‌گویید «عامل من از ابزارهای سطح بالا استفاده نمی‌کند». اگر فهرست راهنما فقط شامل عبارت اول باشد، کاربر با وجود اینکه پاسخ در مستندات موجود است، همچنان سردرگم می‌ماند و در بن‌بست قرار می‌گیرد.
همان‌طور که در تحلیل‌های قبلی ما درباره تجربه توسعه‌دهندگان (DX) اشاره کردیم، فاصله میان دانش فنی و نحوه جست‌وجوی کاربر می‌تواند کل بهره‌وری یک سیستم را نابود کند.
نتایج تست کور
به گزارش mansio@، برای سنجش دقیق این موضوع، تستی سخت‌گیرانه طراحی شد که شامل ۱۱ اجرا روی سه مدل مختلف بود. او از یک لیست منجمد (frozen list) شامل ۱۰ علامت خطا و ۶ مورد کنترلی در هر اجرا استفاده کرد. موارد کنترلی شامل سه بازنویسی (paraphrase) از ورودی‌های موجود (که باید شناسایی می‌شدند) و سه علامت خارج از دامنه (out-of-domain) بود که باید نتیجه «پیدا نشد» (NONE) را برمی‌گرداندند.
نتایج این آزمایش تضاد شدیدی را بین «پوشش فنی» و «قابلیت یافتن» نشان داد:
- پوشش واقعی بود: خانواده‌های حالت‌های شکست (failure modes) به‌اندازه کافی گسترده بودند تا مشکلات را در بر بگیرند و از نظر تئوریک پاسخ‌ها موجود بودند.
- جست‌وجو شکست خورد: عبارت خاص «عامل من از ابزارهای سطح بالا استفاده نمی‌کند» در ۱۰ مورد از ۱۰ بار اجرا در هر سه مدل، نتیجه NONE داد.
- خطرات استدلال: در یک اجرا، مدلی با تنظیمات استدلال پایین، به‌طور متقاعدکننده‌ای علائم خارج از دامنه را به ورودی‌های واقعی متصل کرد؛ این ثابت کرد که «اشتباه با اطمینان» بسیار خطرناک‌تر از سکوت یا عدم پاسخ است. این چالش با خطاهای «چاپلوس» در سامانه‌های ارزیابی شباهت دارد، جایی که مدل‌ها با اطمینان کاذب، نتایج نادرست را ارائه می‌دهند.
- خلاهای واقعی: یک مورد مربوط به فرآیند متوقف‌شده‌ای (hung process) که باعث نشت دستگیره‌های فایل (file handles) می‌شد، در تمام اجراها نتیجه NONE داد، زیرا هیچ خانواده یا دسته‌بندی موجودی نشت‌های سطح سیستم‌عامل (OS-level leaks) را پوشش نمی‌داد.
ریشه زبانی شکست
طبق بررسی‌های تیم Tirthahq پس از تحلیل شکست‌ها، مشخص شد که تک‌تک خطوط علائم در کاتالوگ از یک «ابزار» یا «مصنوع فنی» (artifact) به‌عنوان فاعل دستوری استفاده کرده بودند. کلماتی مثل «مجموعه» (the suite)، «فایل» (the file)، «حفاظ» (the guard) یا «نرخ نمونه‌برداری» (the sampling rate) بر متن غالب بودند.
در کل کاتالوگ، تعداد خطوطی که فاعل آن‌ها «رفتار یک بازیگر یا کاربر» بود، صفر بود. تیم ۱۳ فایل مختلف را برای یافتن «واژگان ورود» (arrival vocabulary) — کلماتی مثل «نادیده می‌گیرد» (ignores)، «استفاده نمی‌کند» (won't use) یا «تنبلی می‌کند» (lazy) — جست‌وجو کرد و تنها یک مورد را یافت که آن هم در اعماق متن دفن شده بود.
این یعنی فهرست فرض کرده بود که خواننده پیش از جست‌وجو، مشکل را در یک ابزار خاص مکان‌یابی کرده است. در واقع سیستم انتظار داشت کاربر در وضعیتی باشد که بعد از حفاری فنی و عیب‌یابی به آن می‌رسد، نه وضعیتی که هنگام مواجهه اول با باگ و احساس سردرگمی دارد. این نوع نقص در شناسایی دقیق باگ‌ها یادآور گزارش‌های مثبت کاذب در بازرسی حفاظ‌هاست که نشان می‌دهد چگونه ابزارهای تشخیص می‌توانند در تفکیک خطاهای واقعی از نویز دچار مشکل شوند.
راهکار: لایه ورود (Arrival Layer)
برای رفع این نقص، تیم یک «لایه ورود» پیاده کرد. این لایه مجموعه‌ای از جملات است که با واژگان «شکایت» (complaint vocabulary) نوشته شده و کاربر را به دسته‌های فنی مربوطه ارجاع می‌دهد.
برای تضمین صداقت و عدم سوگیری در طراحی، یک شرط سخت‌گیرانه اعمال شد: لایه ورود باید توسط کسی نوشته شود که هرگز ورودی‌های فنی را نخوانده است. این کار مانع از آن می‌شود که نویسنده به‌طور ناخودآگاه زبان فنی کاتالوگ را تقلید کند، زیرا تقلید ناخودآگاه باعث می‌شود همان نقص قبلی صرفاً با فونتی جدید تکرار شود. این رویکرد سخت‌گیرانه برای حذف سوگیری، مشابه پروتکل سه-مرحله‌ای MonkeyCode است که برای توقف باگ‌های پنهان در کدهای تولید شده توسط AI طراحی شده است.
پس از این اصلاح، mansio@ دوباره همان لیست منجمد را اجرا کرد و نتایج به‌شدت تغییر کرد:
- علامت «عدم استفاده از ابزارها» این بار در ۱۰ مورد از ۱۰ بار اجرا، به‌درستی با یک خانواده فنی تطبیق یافت.
- موارد کنترلی با دقت ۶ از ۶ ثابت ماندند و پایداری سیستم حفظ شد.
- تنها یک مورد مثبت کاذب (false positive) جدید ظاهر شد که در آن شکایتی درباره فاصله‌گذاری (spacing) به‌اشتباه به علامت رندرینگ رابط کاربری (UI rendering) متصل شد.
تحلیل تحریریه
این تمرین یک نقطه کور بحرانی در تجربه توسعه‌دهندگان (DX) هوش مصنوعی را برجسته می‌کند. ما اغلب «داشتن اطلاعات» را با «در دسترس کردن اطلاعات» اشتباه می‌گیریم. یک معیار واحد برای «پوشش» (coverage) می‌تواند یک سیستم جست‌وجوی کاملاً غیرقابل استفاده را پنهان کند.
برای کسانی که پلتفرم‌های هوش مصنوعی یا ابزارهای داخلی می‌سازند، درس روشن است: اعتبار یک فهرست علائم به «بودجه استدلالی» (reasoning budget) خواننده بستگی دارد. اگر کاربر مجبور باشد برای پیدا کردن یک مقاله راهنما، یک ترجمه ذهنی پیچیده از «رفتار» به «ابزار» انجام دهد، آن فهرست شکست خورده است.
علاوه بر این، خطر تطبیق‌های «اشتباه اما مطمئن» در مدل‌های با استدلال پایین نشان می‌دهد که مستنداتی که توسط هوش مصنوعی ارائه می‌شوند باید با احتیاط مدیریت شوند. وقتی یک سیستم یادداشتی را به‌عنوان یک حقیقت قطعی ارائه می‌دهد، در واقع حالت‌های شکستِ توانایی استدلال مدل زیربنایی را به ارث می‌برد.
اگر در حال فهرست‌بندی یک سیستم پیچیده هستید، باید فهرست خود را قبل از نوشتن ورودی‌ها بنویسید، یا این وظیفه را به کسی بسپارید که هرگز محتوا را ندیده است. خواندن متریالی که قصد فهرست‌بندی آن را دارید، دقیقاً همان چیزی است که شما را از فهرست‌بندی درست آن سلب صلاحیت می‌کند.
گام بعدی شما
- اگر برای تیم خود مستندات فنی می‌نویسید، یک «لایه ورود» با زبان غیرفنی ایجاد کنید.
- برای تست مستندات، از افرادی بخواهید که با جزئیات پیاده‌سازی آشنا نیستند تا سعی کنند مشکل خود را پیدا کنند.
- در طراحی سیستم‌های بازیابی اطلاعات، تفاوت بین «وجود داده» و «قابلیت دسترسی به داده» را با تست‌های کور بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو