https://virgool.ir/feed/@beh.bakhtiarifa2026-11-11 07:12:05https://files.virgool.ir/upload/users/107987/avatar/V88kvR.jpghttps://virgool.ir/@beh.bakhtiarihttps://virgool.ir/@beh.bakhtiari/به-یک-داور-بی-طرف-نیازمندیم-td5ueg8tteknچند روز پیش در ایکس (توییتر سابق) پستی دیدم با این مضمون:کاربری از یک ایجنت خواسته بود یک اپ را پیاده‌سازی کند و صراحتاً تأکید کرده بود که در پیاده‌سازی بخشی از آن، چند متد خاص را به کار نبرد. پس از ساعت‌ها کار و تولید ده‌ها هزار خط کد، کاربر دوباره برای اطمینان پرسیده بود: «مطمئنی از آن متدهای اشاره‌شده استفاده نکردی؟»ایجنت با اطمینان پاسخ داده بود که نکرده است. اما کاربر پس از صرف چند ساعت برای بررسی متوجه شده بود که ایجنت دقیقاً از همان متدها استفاده کرده است. این ماجرا من را به یاد «سوگیری تاییدی» (Confirmation Bias) انداخت. دامی که ما انسان‌ها هم بارها در آن می‌افتیم. فرض کنید از شما خواسته شده برای مشکلی در یک کسب‌وکار راه‌حلی پیدا کنید و آن را پیاده‌سازی کنید. چند هفته برای طراحی و اجرای راه‌حل وقت می‌گذارید و سپس ارائه‌ای آماده می‌کنید تا نتیجه را به تیم نشان دهید. به احتمال زیاد، در این ارائه بیشتر از داده‌ها، اطلاعات و دیدگاه‌هایی استفاده خواهید کرد که راه‌حل شما را تأیید می‌کنند و شواهد مخالف را کمتر جدی خواهید گرفت.مدل‌های زبانی نیز گاهی مانند ما رفتار می‌کنند و دچار سوگیری‌های شناختی می‌شوند. اطلاعات، تصمیم‌ها و استدلال‌هایی که ایجنت در جریان انجام کار تولید کرده، در Context Window قرار دارند. وقتی از همان ایجنت می‌خواهیم نتیجهٔ کار خودش را بررسی کند، ممکن است به‌جای آغاز ارزیابی از صفر، همان مسیر قبلی را ادامه دهد و با مراجعه به Context Window استدلال‌هایی تولید کند که نشان دهند تصمیم‌هایش درست بوده و تمام خواسته‌ها به بهترین شکل برآورده شده‌اند.اما چگونه می‌توان احتمال وقوع این مشکل را کاهش داد؟برای یک ارزیابی بی‌طرفانه‌تر، به یک داور نیاز داریم. داوری که هیچ اطلاعاتی از گفتگوها و استدلال‌های پیشین را ندارد. این داور را می‌توانیم با استفاده از ساب‌ایجنت‌ها بسازیم.یکی از مهم‌ترین مزیت‌های ساب‌ایجنت‌ها این است که می‌توانند در فضایی مستقل از گفت‌وگوی اصلی کار کنند. ساب‌ایجنت‌، مسئله و معیارهای لازم را دریافت می‌کند، بدون درگیرشدن با تمام پیش‌فرض‌ها و استدلال‌های قبلی آن را بررسی می‌کند و در پایان، نتیجه یا خلاصهٔ ارزیابی خود را به ایجنت اصلی بازمی‌گرداند. این ویژگی در هر کاری که به یک نگاه تازه و ارزیابی مستقل نیاز دارد، مفید است.بازبینی کد یکی از نمونه‌های روشن این کاربرد است. فرض کنید یک ایجنت کدنویسی طی چندین رفت‌وبرگشت قابلیتی را پیاده‌سازی کرده است. اگر از همان ایجنت بخواهیم کار خودش را بازبینی کند، ممکن است همچنان تحت‌تأثیر تصمیم‌ها و استدلال‌های قبلی خود باشد. در مقابل، می‌توان این وظیفه را به یک ساب‌ایجنت‌ بازبین سپرد و کد را طوری در اختیارش قرار داد که گویی شخص دیگری آن را نوشته است.ساب‌ایجنت‌ بازبین، الزامات اولیه، محدودیت‌ها و استانداردهای پروژه را دریافت می‌کند، خروجی git diff و فایل‌های تغییریافته را می‌خواند، تست‌ها را اجرا می‌کند و با استناد به شواهد بررسی می‌کند که آیا کد، علاوه بر نداشتن خطا، تمام خواسته‌های اولیه را نیز رعایت کرده است یا نه.همچنین می‌توان معیارهای تخصصی بازبینی هر پروژه را در دستورالعمل این ساب‌ایجنت‌ تعریف کرد. به این ترتیب، کد تمام اعضای تیم بر اساس معیارهایی یکسان و منسجم ارزیابی خواهد شد.هرچند این روش احتمال خطا را به صفر نمی‌رساند، اما مرزی روشن میان «انجام کار» و «ارزیابی کار» ایجاد می‌کند. درست همان‌طور که در یک تیم مهندسی، برنامه‌نویس نباید تنها تأییدکنندهٔ PR خودش باشد، در دنیای ایجنت‌ها نیز جداسازی این دو نقش کلید رسیدن به سیستمی قابل‌اعتمادتر است.» بهروز بختیاریبهروز بختیاریSun, 16 Aug 2026 15:31:15 +0330