تفکیک «محرک» از «اجرا»؛ راهکار جدید برای شناسایی نقاط کور عامل‌های هوش مصنوعی

تصور کنید یک عامل هوشمند ۹۰ درصد در انجام تکالیف موفق است، اما در واقعیت فقط ۶۰ درصد اوقات متوجه می‌شود که اصلاً باید آن تکلیف را شروع کند. در این حالت، تجربه کاربر بسیار بدتر از آن چیزی است که اعداد کلی گزارش می‌دهند.

به نقل از بررسی‌های فنی مفصلی که در ۲۱ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد، نادیده گرفتن فاز «محرک» (Trigger) در چرخه عمر یک مهارت، منجر به تولید معیارهای موفقیت گمراه‌کننده می‌شود. برای ارزیابی درست یک عامل (Agent) — شبیه به کارمند متخصصی که باید دقیقاً بداند چه زمانی وارد جلسه شود و چه زمانی سکوت کند — باید تفکیکی دقیق بین قصد (Intent) و اجرا (Execution) ایجاد کرد. اگر یک مهارت نرخ موفقیت در انجام تکلیف ۹۰٪ داشته باشد اما بازخوانی محرک آن تنها ۶۰٪ باشد، خروجی نهایی برای کاربر بسیار ناامیدکننده خواهد بود.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن دیدیم، تکیه بر خروجی نهایی بدون بررسی مسیر تصمیم‌گیری، ریسک‌های پنهانی را ایجاد می‌کند. این چالش در ارزیابی دقیق‌تر مدل‌ها به‌ویژه زمانی محسوس است که با وظایف پیچیده مواجه می‌شویم؛ چنان‌که در بنچمارک‌های اخیر مشاهده شد تنها درصد بسیار کمی از وظایف پیچیده اداری توسط پیشرفته‌ترین مدل‌ها حل شده است. در دنیای مهارت‌های AI، تمرکز اکثر تست‌های نرم‌افزاری تنها بر یک لایه است: «آیا کد خروجی درست را تولید کرد؟». اما این رویکرد در مهارت‌های هوش مصنوعی ناکافی است. لایه اول «محرک» است؛ یعنی آیا مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — درست تشخیص داد که ورودی خاص کاربر باید این مهارت را فعال کند؟ لایه دوم «اجرا» است؛ یعنی آیا مهارت پس از فعال شدن، تکلیف را به‌طور صحیح به پایان رساند؟ بدون بررسی هر دو لایه，ارزیابی ناقص است.

برای اثبات این موضوع، نویسنده مقاله مهارت rnd-technical-writer را که برای نوشتن مقالات فنی طراحی شده بود، مورد آزمایش قرار داد. برای این کار، یک مجموعه آزمون متوازن شامل ۲۰ مورد طراحی شد: ۸ مورد «مثبت واقعی» (True Positives) که شامل درخواست‌های صریح برای آموزش‌ها، بررسی‌های عمیق یا مقالات بود؛ ۸ مورد «منفی واقعی» (True Negatives) مانند درخواست کمک برای کدنویسی، برنامه‌ریزی سری مقالات یا سوالات general؛ و ۴ مورد «مرزی» (Edge cases) برای تست ابهام‌های معنایی و سیگنال‌های مختلط.

معیارهای ارزیابی محرک

کیفیت محرک با استفاده از سه معیار اصلی که از یک ماتریس اشتباه (Confusion Matrix) استخراج می‌شوند، سنجیده می‌شود:

• بازخوانی (Recall) = TP / (TP + FN): از بین تمام ورودی‌هایی که «باید» مهارت را فعال می‌کردند، چند درصد واقعاً فعال شدند؟
• دقت (Precision) = TP / (TP + FP): از بین تمام ورودی‌هایی که باعث فعال شدن مهارت شدند، چند مورد درست بود؟
• امتیاز F1: میانگین هارمونیک این دو معیار که با فرمول ۲ × (Recall × Precision) / (Recall + Precision) محاسبه می‌شود.

در تست‌های انجام شده روی rnd-technical-writer، این مهارت به نرخ صحت کلی ۹۵٪ (۱۹ مورد درست از ۲۰ مورد) دست یافت، در حالی که میزان بازخوانی ۱۰۰٪، دقت ۹۲٪ و امتیاز F1 آن ۰.۹۶ بود.

برای اتوماسیون این روند، نویسنده از یک پرامپت ساختاریافته به نام TRIGGER_EVAL_PROMPT استفاده کرد. در این روش، توصیف مهارت و ورودی کاربر به یک LLM ارسال می‌شود. مدل سپس وضعیت محرک را پیش‌بینی کرده و یک شیء JSON شامل یک «پیش‌بینی» (trigger یا no_trigger) و یک «استدلال» تک‌جمله‌ای برمی‌گرداند.

جالب‌ترین یافته مربوط به تنها مورد «مثبت کاذب» (False Positive) بود. وقتی کاربر به زبان چینی پرسید: "帮我写一个解析 JSON 的 Python 函数" (برای من یک تابع پایتون برای پارس کردن JSON بنویس)، مدل مهارت «نویسندگی فنی» را فعال کرد. استدلال مدل این بود که کاربر یک قطعه کد فنی پایتون می‌خواهد و بنابراین این درخواست در محدوده هدفِ «نوشتن مقالات فنی» قرار می‌گیرد. این اتفاق یک شکاف جدی را شناسایی کرد: در مشخصات مهارت، «مثال‌های منفی» که صراحتاً فعال‌سازی را برای موارد خاص منع کنند، وجود نداشت. با افزودن یک محدودیت صریح مانند «در صورتی که کاربر درخواست قطعه-کد، تابع یا اسکریپت کرد، مهارت را فعال نکن»، این مشکل حل شد و مدل یاد گرفت که کد را مستقیماً بنویسد به‌جای اینکه مهارت نویسندگی را فراخوانی کند.

تکمیل تکلیف و داوران چندسطحی

پس از فعال شدن محرک، چارچوب ارزیابی دو سطح بررسی اجرا را اعمال می‌کند تا تضمین شود خروجی با استانداردهای کیفیت مطابقت دارد.

سطح ۲: اعتبارسنجی ساختاری

این لایه مبتنی بر قوانین (Rule-based) است و نیازی به LLM ندارد. این بخش مثل یک فیلتر اولیه عمل می‌کند تا الزامات پایه بررسی شود:

• تعداد کلمات/کاراکترها: خروجی باید از یک حد نصاب مشخص بالاتر باشد.
• بلاک‌های کد: وجود حداقل یک بلاک کد الزامی است.
• فرمت‌بندی: استفاده از حداقل یک عنوان سطح دوم (H2) ضروری است.

سطح ۳: سنجش کیفیت

در این لایه از رویکرد مدل زبانی به‌مثابه داور (LLM-as-a-Judge) با استفاده از یک قالب خاص به نام JUDGE_PROMPT استفاده می‌شود. داور در نقش یک ویراستار فنی خبره، مقاله را در مقیاس ۱ تا ۵ در چهار بعد وزن‌دار می‌سنجد:

• دقت فنی (Technical Accuracy): وزن ۳۵٪
• عمق مطلب (Depth): وزن ۲۵٪
• وضوح (Clarity): وزن ۲۰٪
• ارزش کاربردی (Practical Value): وزن ۲۰٪

در یک اجرای آزمایشی روی مقاله پیکربندی Redis TTL [T001] به زبان انگلیسی، تمام چک‌های ساختاری پاس شد و نمره میانگین وزن‌دار ۳.۹۵ از ۵ کسب کرد (دقت ۴/۵، عمق ۳/۵، وضوح ۵/۵، ارزش کاربردی ۴/۵). اما یک مقاله چینی درباره Python type hints [T002] در سطح ۲ شکست خورد؛ سیستم گزارش داد مقاله تنها ۱۶۵ کلمه دارد، در حالی که متن از نظر بصری کامل به نظر می‌رسید.

باگ «فرض زبانی» در شمارش کلمات

این شکست یک نقص مهندسی جدی را فاش کرد: استفاده از دستور word_count = len(article.split()) برای شمارش کلمات. در انگلیسی کلمات با فاصله (whitespace) جدا می‌شوند و این متد درست عمل می‌کند، اما در متن‌های چینی فاصله‌ای بین کلمات وجود ندارد. بنابراین متد .split() روی یک جمله چینی، صرف‌نظر از طول واقعی، تنها یک یا چند توکن محدود برمی‌گرداند. علاوه بر این، مدل خروجی خود را در بلاک‌های کد markdown قرار داده بود که منطق شمارش را بیشتر مختل می‌کرد. در واقع مقاله‌ای که احتمالاً بیش از ۸۰۰ کاراکتر داشت، تنها ۱۶۵ کلمه گزارش شده بود.

برای حل این مشکل، نویسنده تابعی به نام count_content_length پیاده کرد که ابتدا با استفاده از regex (re.sub(r".*?", "", text, flags=re.DOTALL)) علامت‌های کد markdown را حذف می‌کند. سپس اگر سیستم تشخیص دهد که بیش از ۵۰ کاراکتر CJK (چینی، ژاپنی، کره‌ای) وجود دارد، تعداد کاراکترها را برمی‌گرداند؛ در غیر این صورت، برای متون لاتین از روش جداسازی با فاصله استفاده می‌کند.

محدودیت‌های امتیازدهی LLM

یک مقایسه A/B روی پرامپت‌ها نشان داد که داوران LLM دارای «تفکیک‌پذیری درشت» (Coarse Resolution) هستند. دو نسخه بررسی شدند:

• نسخه A: پرامپت سیستمی اصلی.
• نسخه B: پرامپت بهبود یافته شامل یک قلاب (Hook) بر اساس نقاط درد توسعه‌دهندگان و یک چک‌لیست الزامی شامل حداقل دو مثال کد حاشیه‌نویسی شده.

با وجود این تغییرات ساختاری مشهود، هر دو پرامپت نمرات یکسانی (۴/۴/۵/۴ در چهار بعد) گرفتند که منجر به تساوی ۴.۲۰ از ۵ شد. این نشان می‌دهد که برای مدل مورد استفاده (GLM-4-Flash)، تفاوت‌های کیفی که یک انسان به‌راحتی می‌بیند، در فاصله نمره ۴ تا ۵ جذب شده و تشخیص داده نمی‌شوند.

برای کاهش این اثر، چارچوب سه تغییر راهبردی را پیشنهاد می‌کند:

• مقایسه نرخ پیروزی (Win-Rate Comparison): به‌جای امتیاز تک‌شات، از مقایسه‌های چندباره (۵+ بار اجرا) استفاده کنید، جایی که نرخ پیروزی بالای ۶۰٪ معنادار تلقی شود.
• بازخورد کیفی (Qualitative Feedback): از داور بخواهید مزایای خاص هر نسخه را لیست کند، به‌جای اینکه فقط یک عدد اختصاص دهد.
• سلسله‌مراتب مدل‌ها (Model Hierarchy): همواره از مدلی برای «داور» استفاده کنید که از مدل «اجراکننده» قوی‌تر باشد تا از خودارزیابی‌های غیرقابل‌اعتماد جلوگیری شود.

نقشه راه پیاده‌سازی

نویسنده برای توسعه‌دهندگانی که می‌خواهند این چارچوب را پیاده کنند، یک برنامه سه هفته‌ای را پیشنهاد می‌دهد:

• هفته اول: ساخت یک مجموعه آزمون کامل برای مهارت با بالاترین اولویت با نسبت ۸:۸:۴ (مثبت:منفی:مرزی). اجرای دستی این موارد برای تعیین خط مبنای بازخوانی (Recall) و دقت (Precision).
• هفته دوم: یکپارچه‌سازی ارزیابی تکمیل تکلیف (سطح ۲ ساختاری + سطح ۳ داور LLM). اعمال اصلاحیه شمارش کلمات چینی و ثبت نمرات در مستندات مهارت.
• هفته سوم: اصلاح مهارت بر اساس شکست‌ها، استفاده از چارچوب برای تأیید بهبود، و مستندسازی یک چرخه کامل «اصلاح $\rightarrow$ ارزیابی $\rightarrow$ نتیجه‌گیری».

این رویکرد تمرکز را از تعقیب امتیازات بالای F1 به تحلیل شکست‌های خاص تغییر می‌دهد. یک نقطه شکست واحد، مانند مورد مثبت کاذب در پارس کردن JSON، اطلاعات کاربردی بیشتری برای اصلاح توصیفات مهارت فراهم می‌کند تا یک نرخ صحت ۹۵٪. چک‌لیست نهایی این سیستم تضمین می‌کند که داور قوی‌تر از سوژه باشد، مثال‌های منفی صراحتاً در توصیفات ذکر شوند و چک‌های ساختاری محیط‌های چندزبانه را پشتیبانی کنند.

گام بعدی شما

• برای هر مهارت اولویت‌دار، یک مجموعه آزمون با نسبت ۸:۸:۴ (مثبت:منفی:مرزی) بسازید تا خط مبنای بازخوانی و دقت را پیدا کنید.
• لایه اعتبارسنجی ساختاری را پیش از داوری LLM قرار دهید تا هزینه‌های استنتاج کاهش یابد.
• در توصیفات مهارت‌ها، حتماً «مثال‌های منفی» (مواردی که نباید فعال شوند) را به‌صورت صریح لیست کنید.

اما چالش واقعی زمانی شروع می‌شود که بخواهید این داوران را برای مدل‌های چندوجهی مقیاس‌بندی کنید؛ در تحلیل بعدی ما به بررسی استانداردهای ارزیابی Vision-Language Models خواهیم پرداخت.