لباسِ اجماع: چرا تأییدِ صحتِ عاملها به تزریقِ خطا نیاز دارد
عامل هوش مصنوعی شما ممکن است درباره دقتِ خودش به شما دروغ بگوید.
اخیراً شاهد بودم که یک همکار هوش مصنوعی سه بار متوالی شکست خورد. او در سطوح مختلف، در یک مشکلِ مربوط به حقیقت دچار خطا شد. با لحنی اشتباه نوشت. یک مدلِ بازبین، هر بار که همان خطا را میخواند، امتیاز بالاتری به آن میداد. او حتی در شمارشِ فکتها دربارهی «انحرافِ حقیقت» (fact drift) دچار اشتباه شد.
من فقط به این دلیل متوجه این خطاها شدم که خارج از چرخه (loop) حضور داشتم.
این موضوع نشاندهندهی یک مشکل بزرگ در پشتهی عاملها (agent stack) است. اکثر سیستمهای تأییدِ صحت، فرض را بر استقلال میگذارند. آنها از رایگیریِ چندعاملی، الگوهای سازنده/بازبین (maker/checker) یا پرامپتهای مجموعهای (ensemble prompts) استفاده میکنند. آنها فرض میکنند که مسیرهای مختلف، چیزهای متفاوتی را مشاهده خواهند کرد.
اما اغلب، این مسیرها از یک منبعِ مشترک استفاده میکنند.
وقتی یک بازبین از همان منبعی میخواند که نویسنده میخواند، شما دو دیدگاه ندارید؛ بلکه یک دیدگاه را دارید که با دو کلاهِ متفاوت نمایش داده میشود. این یک «نقطه شکستِ واحد» است که لباسِ اجماع به تن کرده است.
اگر مسیرها یک منبعِ بالادستیِ مشترک داشته باشند، روی یک فکتِ غلط یا یک توهمِ مشابه توافق خواهند کرد. سیستم سالم به نظر میرسد چون خروجیها متنوع به نظر میرسند، اما هر بار که منبع دروغ بگوید، سیستم شکست میخورد.
برای رفع این مشکل، باید از تزریقِ خطا (fault injection) استفاده کنید.
فقط این را اندازه نگیرید که آیا عاملها با هم اختلاف نظر دارند یا خیر. اندازه بگیرید که آیا میتوانید با از کار انداختن بخشی از سیستم، آنها را مجبور به اختلاف نظر کنید یا خیر.
در اینجا نحوهی تست کردنِ پشتهی خود آمده است:
- تزریق یک حافظهی بد: یک فکتِ جعلی را در یکی از مسیرهای بازیابی (retrieval path) قرار دهید. اگر هر دو مسیر فکتِ جعلی را برگرداندند، مسیرهای شما به هم وابسته (coupled) هستند.
- تغییر یک قانون: یک قانون را بهصورت آفلاین تغییر دهید. اگر سازنده و بازبین هر دو بدون گزارشِ عدم تطابق، از قانون جدید پیروی کنند، یعنی آنها در حال استفاده از یک حافظهی پنهان (cache) مشترک هستند.
- کاشتنِ تلمتریِ غلط: یک شناسه مدل (model ID) جعلی را ثبت کنید. اگر بررسی با موفقیت انجام شد، یعنی بازبین دارد همان رکوردِ نویسنده را میخواند.
سیستمهای توزیعشده سالها پیش این مشکل را حل کردند. آنها از مهندسی آشوب (chaos engineering) و تستهای پارتیشنبندی (partition tests) استفاده میکنند. آنها با تماشای اجرای خوبِ سیستم، به آن اعتماد نمیکنند؛ بلکه با ایجادِ شکست، به آن اعتماد میکنند.
معماریهای عاملها باید این انضباط را اتخاذ کنند.
استقلال، ویژگیای نیست که یک بار برقرار کنید؛ بلکه ویژگیای است که باید مدام دوباره آن را تأیید کنید. یک حافظهی پنهانِ مشترک یا یک بهروزرسانیِ مدل میتواند استقلالِ شما را یکشبه از بین ببرد.
از اعتماد به رایهای متفقالقول دست بردارید. تزریقِ خطا را شروع کنید.
Source: https://dev.to/jugeni/a-quorum-costume-why-agent-verification-needs-fault-injection-kbh
Optional learning community: https://t.me/GyaanSetuAi