تصور کنید یک گزارش پژوهشی با ساختاری بی‌نقص و لحنی متقاعدکننده پیش روی شماست، اما یک تاریخ کلیدی در آن اشتباه است و یک منبع جعلی ذکر شده است. خطر ذاتی یک گزارش پژوهشی با فرمت زیبا این است که برخلاف کد، نثر هیچ «وضعیت شکست» (Failing State) بصری ندارد. وقتی یک عامل کدنویسی دچار خطا می‌شود، بازخورد فوری است: یک بیلد شکست‌خورده، یک تست قرمز یا یک صفحه خالی. اما یک عامل پژوهشی می‌تواند یک ارجاع را توهم بزند یا یک ذینفع را به تیم اشتباهی نسبت دهد، بدون اینکه هیچ هشدار بصری فعال شود. این امر ریسکی بحرانی ایجاد می‌کند که در آن اشتباه خاموشِ یک ابزار، در طول فرآیند تدوین، به لغزش در قضاوت انسان تبدیل شود.
ریسک خط لوله مستندسازی
این چالش در گردش‌کاری که در فوریه پیاده‌سازی شد، نمایان گشت؛ جایی که یک دستور سفارشی برای خودکارسازی مرحله پژوهش در تیکت‌های مستندسازی ساخته شد. این ابزار با دریافت یک شناسه تیکت (Ticket ID) و اجرای چندین گام عمل می‌کرد:
- استخراج تیکت به همراه تمام نظرات مرتبط با آن.
- پیگیری مسائل مهندسی (Engineering Issues) متصل به تیکت.
- جست‌وجو در ویکی داخلی برای یافتن اسناد نیازمندی‌های محصول (PRD) یا مشخصات فنی.
- مطالعه صفحات منتشرشده موجود برای ارائه یک خلاصه ساختاریافته که پرسش‌های باز در انتهای آن قرار داشت.
به نقل از گزارش‌های فنی این پروژه، با وجود اینکه این ابزار ساعت‌ها کلیک دستی بین ابزارهای مختلف را حذف کرد و بر موتور جست‌وجوی بسیار ضعیفِ ویکی داخلی غلبه نمود، اما یک آسیب‌پذیری سیستماتیک را آشکار کرد. این مشکل به‌ویژه زمانی تشدید می‌شود که مستندات قدیمی و به‌روزنشده باعث بروز باگ در کدهای تولیدشده توسط عامل‌ها شوند. خلاصه یا Brief، زیربنای تمام مراحل بعدی است. شما خلاصه را می‌خوانید، پیش‌نویس را می‌نویسید و آن پیش‌نویس به دست مهندسی می‌رسد که نثر شما را بررسی می‌کند، نه فرآیند بازیابی اطلاعات را. از آنجا که شما به دلیل عدم تسلط پیشین بر موضوع، خلاصه را می‌خوانید، در واقع در حال بررسی یک بازنویسی هستید، پیش از آنکه منابع اصلی را بخوانید؛ یعنی دقیقاً در لحظه‌ای که کمترین توانایی را برای تشخیص موارد حذف‌شده یا اشتباه دارید.
پیاده‌سازی گذرگاه تخاصمی
برای رفع این نقص، اکنون یک عامل دوم «تخاصمی» (Adversarial Agent) وارد چرخه می‌شود که به محض تولید خلاصه فعال می‌گردد. به جای اجرای یک بازبینی کلی در انتهای کار، این عامل بلافاصله ایجاد می‌شود تا پیش از آنکه متن به دست انسان برسد، به خلاصه «حمله» کند. این رویکرد تک‌عاملی در واقع تکامل‌یافته‌ی سیستم‌هایی است که مانند کتابخانه engineering-docs مستندات فنی را با مهارت‌های تخصصی خودکار می‌کنند.
طبق مستندات این روش، این عامل دوم نمی‌پرسد «آیا این متن خوب است؟»، بلکه یک گذرگاه شک‌گرایانه و محدود را اجرا می‌کند که بر چهار معیار سخت‌گیرانه متمرکز است:
- ردیابی (Traceability): آیا هر ادعا دقیقاً به چیزی که واقعاً بازیابی شده است، باز می‌گردد؟
- سازگاری (Consistency): آیا بخشی از خلاصه با بخش دیگری از همان متن در تضاد است؟
- به‌روز بودن (Recency): آیا اطلاعات به‌روز هستند یا بر اساس صفحه‌ای قدیمی و رها شده از سال‌ها پیش نوشته شده‌اند؟
- شفافیت (Transparency): آیا نقاط کور و نبودِ اطلاعات، صراحتاً به عنوان «خلاء» علامت‌گذاری شده‌اند؟
این محدودیت‌ها مانع از آن می‌شود که هوش مصنوعی پاسخی «صاف و صیقلی» و کامل به نظر برساند، در حالی که پاسخ صادقانه باید این باشد که «در ویکی هیچ مطلبی در این باره نیست، بروید از یک شخص بپرسید». از آنجا که عامل‌ها برای ارائه خلاصه‌ها طراحی شده‌اند، آن‌ها اغلب ترجیح می‌دهند یک پاسخ کامل را ابداع کنند تا اینکه سه-چهارم یک پاسخ را بازگردانند.
موازنه دقت و سرعت
این تغییر نشان می‌دهد که دقت در پژوهش‌های هوش مصنوعی تنها با مهندسی پرامپت (Prompt Engineering) — یعنی هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — به دست نمی‌آید، بلکه نیازمند یک تغییر ساختاری است. مدل‌های زبانی بزرگ (LLMs) در ایجاد ساختار واقعاً خوب هستند اما در دقت ضعیف‌ترین عملکرد را دارند. در این معماری، عامل اول برای «سنتز و ترکیب» بهینه شده و عامل تخاصمی برای «شک‌گرایی».
اگرچه این فرآیند کندتر است و ممکن است برای گردش‌کاری که برای سرعت ساخته شده متناقض به نظر برسد، اما هنوز از جست‌وجوی دستی در چهل صفحه ویکی سریع‌تر عمل می‌کند. این انتظار توجیه‌پذیر است زیرا واقعاتی را که هیچ منبعی ندارند، ادعاهایی که بر شواهد ضعیفی استوارند و حفره‌هایی که با جملات روان پوشانده شده‌اند را شکار می‌کند.
برای کسانی که در حال ساخت خط لوله‌های پژوهشی یا مستندسازی خودکار هستند، درس مشهود است: هزینه یک گردش‌کار کندتر با دو عامل، بسیار کمتر از هزینه انتشار دروغ‌های با اعتمادبه‌نفس است. این گذرگاه شک‌گرایانه تضمین می‌کند که وقتی پیش‌نویس در نهایت به دست ذینفعی می‌رسد که سیستم را بهتر از شما می‌شناسد، شما با باورهای کمتر (اما درست‌تر) وارد آن گفتگو شوید.
گام بعدی شما
برای پیاده‌سازی این مدل، زنجیره عامل‌محور خود را به‌گونه‌ای تنظیم کنید که یک نمونه «منتقد» (Critic) مجزا ایجاد کند. این منتقد باید:
- هیچ دسترسی به «قصد» (Intent) پرامپت اولیه نداشته باشد تا دچار سوگیری تأییدی نشود.
- دسترسی کامل به اسناد منبع بازیابی‌شده داشته باشد تا بتواند ادعاها را مستقیماً چک کند.
اما داستان سخت‌افزاری مدیریت این حجم از استنتاجات موازی حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو