تصور کنید یک عامل هوش مصنوعی بر اساس سه پست ساده، گزارشی بسیار روان مینویسد اما در نهایت بهطور نادرست ادعا میکند که این سه پست، استراتژی کامل یک حساب کاربری را نمایندگی میکنند. برای حل این مشکل که «گسترش پنهان محدوده» (hidden scope expansion) نام دارد، در ۱۳ اوت ۲۰۲۶ پروژهای متنباز به نام xhs-creator-distill منتشر شد که عاملها را مجبور میکند پیش از هرگونه نتیجهگیری، یک دفتر کل پوشش (Coverage Ledger) را بهروزرسانی کنند.
بسیاری از عاملهای هوش مصنوعی (AI Agents) — شبیه دستیارهایی که هر پاسخی را میگیرند و بدون چک کردن منبع، آن را حقیقت مطلق میپندارند — امروز دچار شکاف اعتماد هستند؛ آنها یک پاسخ موفق از سرور (HTTP response) را بهمنزلهی یک مجموعه داده کامل میبینند. در دنیای واقعی، خواندن یک پست با داشتن تاریخچه کامل حساب کاربری متفاوت است. این مشکل در پلتفرمهایی مثل Xiaohongshu (RedNote) شدیدتر است، جایی که محدودیتهای ورود و صفحهبندی (pagination)، بخش بزرگی از محتوای تولیدکننده را از دید عاملهای خودکار پنهان میکند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت و قابلیت اطمینان مدلهای زبانی اشاره کردیم، تکیه بر خروجیهای بدون منبع، بزرگترین نقطه ضعف سیستمهای عاملمحور است. این چالش با الگوهای شکست در آزمونهای هوش مصنوعی همسو است که در آنها سیستمها علیرغم تایید ظاهری، در واقعیت دچار خطا هستند.
زمینه: دفتر کل پوشش
به نقل از راهنمای فنی dev.to، سامانه xhs-creator-distill دفتری را پیاده میکند که چهار شمارشگر مشخص را ردیابی میکند: موارد کشفشده، موارد با موفقیت تجزیهشده، مواردی که محتوای کافی برای تحلیل دارند و مواردی که برای تحلیل عمیق انتخاب شدهاند. این سازوکار مانع از آن میشود که عامل در صورت نبود داده، شروع به حدس زدن کند.
این دفتر کل همچنین بهطور صریح شرایط توقف، موارد تکراری، ورودیهای کمارزش، موارد شکستخورده یا نادیده گرفته شده و مطالبی که همچنان کشف نشدهاند را ثبت میکند. به این ترتیب، تفاوت بین یک «پاسخ موفق شبکه» و یک «حساب کاربری کامل و خواندهشده» بهوضوح حفظ میشود. این رویکرد در واقع پاسخی به این واقعیت است که قواعد خودارزیابی در عاملهای هوش مصنوعی اغلب نمیتوانند خطاهای تثبیتشده در تحلیل دادهها را شناسایی کنند.
سیستم محدوده سه-حالته
این جریان کاری از سه حالت متمایز برای تعریف محدوده ادعاهای گزارش استفاده میکند. در اینجا یک «حالت» صرفاً یک انتخاب در پیادهسازی نیست، بلکه ادعاهای قانونی گزارش نهایی را تعریف میکند:
- QUICK_SET: تحلیل عمیق ۳ تا ۸ پست ارسالی کاربر بدون دسترسی به شبکه. در این حالت، هر مورد ارسالی حتماً در گزارش گنجانده میشود.
- PUBLIC_SAMPLE: بررسی محتوای عمومی و فهرست کردن یک محدوده محدود. این حالت نمونهها را بهصورت شفاف انتخاب میکند و هرگز نباید بهعنوان پوشش کامل حساب معرفی شود.
- ACCOUNT_PACKAGE: ابتدا یک بسته خروجی (Export) ارسالی کاربر را تحلیل کرده و سپس ۳ تا ۸ مورد را برای بررسی عمیق برمیگزیند. ادعاها در اینجا فقط محدود به همان بسته است، نه یک خروجی مستقل و تأیید شده از پلتفرم.
لایههای شواهد قابل حسابرسی
برای اینکه نتایج قابل ردیابی باشند، سیستم شواهد را به سه لایه تقسیم میکند:
- S-IDs (Sxxx): شناسهی مواردی که در فهرست اولیه حساب یا بسته یافت شدهاند.
- N-IDs (Nxx): شناسهی موارد کاملی که برای تحلیل عمیق انتخاب شدهاند.
- A-IDs (Axx): شناسهی مقادیر تجمیعی که از فیلدهای فهرست تجزیهشده محاسبه شدهاند و شامل صورت، مخرج و موارد حذفشده است.
این معماری مانع از آن میشود که عاملها از یک تاریخ ساده یا تعداد لایکها بهعنوان دلیلی برای اثبات قصد نویسنده یا سبک نگارش او استفاده کنند. برای ادعاهایی با اطمینان متوسط یا بالا، سیستم باید به چندین مورد مستقل Nxx ارجاع دهد. تضادها و مثالهای متضاد بهجای میانگینگیری و حذف شدن، بهصورت شفاف نمایش داده میشوند. این تاکید بر مستندات متنی دقیق، با یافتههایی همخوانی دارد که نشان میدهد متنهای مستند در نتایج جستوجوی AI نسبت به فرمتهای دیگر برتری دارند.
مدیریت دادههای ناکافی
اگر شواهد کافی نباشد، سیستم بهجای حدس زدن، وضعیت HOLD (توقف) را برمیگرداند. در واقع خروجیها فقط به دو حالت سطح بالا تقسیم میشوند: PASS (پشتیبانیشده توسط پوشش اعلامشده) و HOLD. وضعیت HOLD خروجی صحیح برای محتوای گمشده، هویت مبهم، محدودیتهای دسترسی، ورودیهای ناامن یا شواهد ناکافی است.
بر اساس مستندات پروژه، در یک تست مرزی واقعی روی Xiaohongshu، عامل با یک صفحه عمومی مواجه شد و بهدرستی تعداد حسابهای شناساییشده، پستهای قابل شناسایی، بدنه کامل پستها و موارد تحلیلشده را صفر گزارش کرد. نتیجه این شد که سیستم وضعیت HOLD را صادر کرد و بهجای تولید یک تحلیل توهمآمیز، سعی نکرد با استفاده از کوکیها یا دور زدن مرزها، بهزور نتیجهای تولید کند.
تست و اعتبارسنجی (v0.2.1)
در نسخه v0.2.1، لایههای اعتبارسنجی متعددی گنجانده شده است:
- ۱۳ مورد رفتاری مصنوعی: شامل تزریق پرامپت (prompt injection)، جعل سبک، شواهد متضاد، آرشیوهای ناامن، خروجیهای چندزبانه، نمونهبرداری از حساب و تخطی از محدوده.
- ۵ تست رگرسیون آفلاین: برای بررسی خط پایه (baseline)، URLهای تاییدنشده، هدرهایی با شکل اعتبارنامهها، ساختارهای خام وبپیج و پیوندهای نمادین (symlinks).
- تستهای پروتکل: یک تست توسط نگهدارنده پروژه با استفاده از ۵ مقاله عمومی CC BY-SA از یک نویسنده، که تمام معیارهای ردیابی شواهد، صداقت در محدوده و ایمنی دادهها را پاس کرد.
- سوابق مرز دسترسی: رکوردهای مجزا برای نقاط ورود X و Xiaohongshu.
این الگو فرض بنیادی پژوهشهای عاملمحور را تغییر میدهد: اولویت از «عامل چه الگوهایی یافت؟» به «واقعاً چه چیزهایی قابل کشف بود؟» تغییر میکند. با صریح کردن مخرج کسرِ دادهها، ماهیت «جعبه سیاه» در خلاصهسازیهای هوش مصنوعی از بین میرود.
این مکانیزم فراتر از تحلیل تولیدکنندگان محتوا کاربرد دارد و میتواند الگویی برای هر عاملی باشد که یک مجموعه داده ناقص را خلاصه میکند؛ مثلاً تیکتهای پشتیبانی کوتاه شده، مقالات پژوهشی پشت دیوار پرداخت، حسابرسی مخازن کد با فایلهای تولیدشده حذفشده، یا تحلیل بازخوردهای مشتریان در خروجیهای ناقص.
توسعهدهندگان اکنون میتوانند این رویکرد را از طریق مخزن لایسنس MIT تست کنند، هرچند نگهدارنده پروژه اشاره کرده که ارزیابی کیفیت معنایی هنوز به بررسی دستی یا یک عامل مستقل نیاز دارد. در حال حاضر پروژه در حال دریافت بازخورد درباره این است که آیا دفتر کل پوشش، حجم اضافی خروجی را توجیه میکند یا خیر و کدام آداپتور خروجی (JSON، CSV یا Markdown) باید زودتر ساخته شود.
گام بعدی شما
- اگر از عاملهای هوش مصنوعی برای تحلیل دادههای وب استفاده میکنید، مکانیزم «ثبت مخرج داده» (تعداد کل در برابر تعداد تحلیلشده) را در پرامپتهای خود بگنجانید.
- مخزن xhs-creator-distill را برای بررسی نحوه پیادهسازی لایههای S-ID و N-ID مطالعه کنید تا گزارشهایتان قابلحسابرسی شوند.
- در تحلیلهای خود، وضعیت HOLD را جایگزین حدسهای مدل در زمان نبود داده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو