ارزیابی رفتار در برابر اعتبارسنجی کد در تست عامل‌های هوش مصنوعی

تصور کنید کدی را اجرا می‌کنید که بدون خطا کار می‌کند، اما سیستم در عمل هیچ هدفی را پیش نمی‌برد؛ برای عامل‌های هوش مصنوعی، تأییدهای قطعی کد دیگر برای تضمین قابلیت اطمینان کافی نیستند. این چرخش از اعتبارسنجی کد به ارزیابی رفتار احتمالی سیستم، محوریت تحلیل فنی منتشر شده در ۱۷ اوت ۲۰۲۶ در وب‌سایت dev.to بود.

تست‌های سنتی نرم‌افزار بر این فرض استوارند که رفتار سیستم توسط مسیرهای کد قطعی و پیکربندی‌ها هدایت می‌شود. در این مدل، فرض بر این است که یک ورودی مشخص، در ترکیب با یک پیکربندی خاص و نسخه‌ای مشخص از کد، همیشه خروجی یکسانی تولید می‌کند. این رویکرد برای APIهای استاندارد و قوانین کسب‌وکار که فضای حالت آن‌ها قابل شمارش و پیش‌بینی است، عالی عمل می‌کند. در چنین سیستم‌هایی، رفتار در متدها، APIها، تنظیمات و وابستگی‌های خارجی کپسوله‌سازی شده است. حتی در سیستم‌های بسیار پیچیده، خروجی یک درخواست را می‌توان مانند یک فرمول ریاضی دید: خروجی ≈ ورودی × پیکربندی × زیرساخت × وابستگی‌ها × نسخه کد.

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

فروپاشی قطعیت

یک گردش کار را تصور کنید که زمانی از مجموعه‌ای از قوانین ثابت برای پیشنهاد محصول استفاده می‌کرد. این فرآیند تنظیمات را از یک ذخیره‌ساز پیکربندی می‌خواند، API پروفایل مشتری و API قیمت را فراخوانی می‌کرد، قوانین قطعی کسب‌وکار را اعمال می‌کرد و در نهایت یک پیشنهاد صادر می‌کرد. تست این سیستم نسبتاً ساده است: شما می‌توانید APIها را شبیه‌سازی (Mock) کنید، حالت پیکربندی را کنترل کنید، موارد خاص (Edge Cases) را فهرست کنید و خروجی‌ها را تأیید کنید. اگرچه سیستم‌های توزیع شده چالش‌هایی مانند تأخیر شبکه، شکست گره‌ها و قطعی‌های جزئی را ایجاد می‌کنند، اما تکنیک‌های تثبیت‌شده‌ای مانند مهندسی آشوب (Chaos Engineering) اعتماد لازم را در این شرایط ایجاد می‌کنند.

حالا این قوانین قطعی کسب‌وکار را با یک برنامه‌ریز مبتنی بر LLM جایگزین کنید. APIها، ابزارها و داده‌ها بدون تغییر باقی می‌مانند، اما حالا گردش کار باید در مورد موارد زیر تصمیم بگیرد:

• کدام ابزارها فراخوانی شوند؟
• ترتیب فراخوانی آن‌ها چگونه باشد؟
• آیا اطلاعات بیشتری مورد نیاز است یا خیر؟
• ابهام‌ها چگونه مدیریت شوند؟
• پاسخ نهایی چگونه فرموله شود؟

مزیت این تغییر بدیهی است: سیستم به‌شدت منعطف می‌شود و می‌تواند سناریوهایی را مدیریت کند که هرگز به‌طور صریح برای آن‌ها برنامه‌نویسی نشده‌اند. اما نقطه ضعف این است که سطح تست‌ها به‌طور انفجاری گسترش می‌یابد. محرک رفتار دیگر فقط کد نیست؛ بلکه اکنون یک سیستم استدلال احتمالی است که در داخل خودِ اپلیکیشن عمل می‌کند. حتی استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی و نه دوره‌ی آموزش آشپز — با دمای صفر (Temperature-0) هم به دلیل به‌روزرسانی‌های مدل، تفاوت‌های زیرساختی و جزئیات پیاده‌سازی، خروجی‌های کاملاً تکرارپذیر را در محیط تولید تضمین نمی‌کند. نتیجه، سیستمی است که پیش‌بینی رفتار آن سخت‌تر، محدود کردن آن دشوارتر و در نتیجه تست آن پیچیده‌تر است. این پیچیدگی در مدیریت قصد (Intent) مدل‌ها، ما را به سمت روش‌های جدیدی برای بازبینی هدایت می‌کند؛ برای مثال، استفاده از جلسات کامل عامل به جای بررسی‌های ساده Diff می‌تواند به جلوگیری از انحراف قصد مدل در طول زمان کمک کند.

۶ بُعد صحت در عامل‌ها

طبق گزارش dev.to، ارزیابی یک عامل نیازمند اندازه‌گیری ۶ بُعد مجزا است تا مشخص شود آیا سیستم مناسب رفتار کرده است یا خیر. ما دیگر نمی‌پرسیم آیا یک تابع مقدار درست را برگرداند، بلکه می‌پرسیم آیا رفتار کلی پذیرفتنی بود؟ یک پاسخ می‌تواند از نظر واقعیت درست باشد اما ناقص باشد، دستورالعمل‌ها را نقض کند یا از طریق یک توالی اقدامات ناکارآمد یا ریسکی به جواب درست برسد.

• معیارهای نتیجه (Outcome): تمرکز بر این است که آیا عامل وظیفه را با موفقیت به پایان رساند یا خیر. معیارهای کلیدی شامل «کامل بودن پاسخ» (آیا عامل به کل درخواست پاسخ داد یا فقط بخشی از آن؟) و «صحت پاسخ» (آیا جواب از نظر واقعیت دقیق است، بر اساس بستر داده‌های موجود است و با دستورالعمل‌ها مطابقت دارد؟) است.
• معیارهای عملیاتی (Operational): ارزیابی کارایی سیستم. این شامل «زمان اجرا و تأخیر» (عامل با چه سرعتی پاسخ می‌دهد و کارش را تمام می‌کند؟) و «بهره‌وری هزینه» (چه تعداد توکن، فراخوانی مدل و منابع خارجی برای تکمیل وظیفه مورد نیاز بود؟) می‌شود.
• معیارهای قابلیت اطمینان (Reliability): اندازه‌گیری رفتار در زمان بروز مشکل. تمرکز بر «مدیریت شکست» است؛ یعنی آیا عامل می‌تواند به‌طور مناسب از شکست ابزارها، تایم‌اوت‌ها، ورودی‌های بدساخت و داده‌های مفقود بازیابی شود؟
• معیارهای کیفی (Quality): تمرکز بر کاربردی بودن و نحوه ارائه خروجی نهایی. این بخش «کیفیت پاسخ» را ارزیابی می‌کند تا اطمینان حاصل شود خروجی شفاف، موجز، دارای ساختار مناسب و متناسب با مخاطب است.
• معیارهای حاکمیتی (Governance): اطمینان از اینکه سیستم در چارچوب‌های پذیرفته شده عمل می‌کند. این بخش «امنیت و ایمنی» را تست می‌کند، به‌ویژه تاب‌آوری در برابر تزریق پرامپت (Prompt Injection)، جیل‌بریک‌ها (Jailbreaks)، تلاش برای استخراج داده‌ها و سایر ورودی‌های خصمانه.
• معیارهای رفتاری (Behavioral): ارزیابی فرآیند، نه فقط نتیجه. تمرکز بر «کیفیت مسیر» (Trajectory Quality) است؛ آیا عامل مسیری منطقی را برای رسیدن به پاسخ طی کرد یا تلاش خود را صرف استدلال‌های غیرضروری و فراخوانی‌های بیهوده ابزارها کرد؟

فراتر از تأییدهای سخت

از آنجا که این ابعاد معنایی هستند و نه محاسباتی، مهندسان نمی‌توانند از دستورات ساده‌ای مثل assert calculate_tax(100) == 18 استفاده کنند. سوالاتی مثل «آیا لحن حرفه‌ای بود؟» یا «آیا پاسخ به بستر داده‌ها وفادار بود؟» به تست‌های سخت تبدیل نمی‌شوند. صنعت اکنون به سمت سه مکانیسم اصلی اندازه‌گیری حرکت می‌کند:

۱. معیارهای ریاضی: استفاده از تکنیک‌های آماری برای کمی کردن رفتار. برای مثال، چارچوب RAGAS «ارتباط پاسخ» (Answer Relevancy) را در بازه ۰ تا ۱ محاسبه می‌کند تا ببیند پاسخ چقدر با قصد ورودی کاربر مطابقت دارد، بدون اینکه صحت واقعیت را بسنجد. این معیار پاسخ‌هایی را که ناقص هستند یا جزئیات غیرضروری دارند، جریمه می‌کند. این محاسبه از طریق مراحل زیر انجام می‌شود:

• تولید مجموعه‌ای از سوالات مصنوعی (به‌طور پیش‌فرض ۳ مورد) بر اساس پاسخ برای بازتاب محتوای آن.
• محاسبه شباهت کسینوسی (Cosine Similarity) بین بردار معنایی (Embedding) ورودی کاربر (E_u) و بردار هر یک از سوالات تولید شده (E_q).
• میانگین‌گیری از این امتیازات: Answer Relevancy = (1/N) Σ cosine_similarity(E_q, E_u).

۲. مدل‌های تخصصی: استقرار مدل‌های یادگیری ماشین اختصاصی که برای کارهای طبقه‌بندی یا امتیازدهی خاص آموزش دیده‌اند. مثال‌هایی از این مدل‌ها، مدل‌های بهینه‌شده برای تشخیص داده‌های حساس (PII)، تحلیل احساسات یا تشخیص سوگیری (Bias Detection) هستند. در این حالت، ارزیاب خود یک مدل است که برای یک وظیفه امتیازدهی خاص بهینه شده است.

۳. مدل زبانی به‌مثابه داور (LLM-as-a-Judge): استفاده از یک مدل برتر برای نمره دادن به خروجی عامل بر اساس یک دستورالعمل یا روب ریک (Rubric) تعریف‌شده. به جای مقایسه خروجی‌ها با مقادیر دقیق مورد انتظار، مدل ارزیاب بررسی می‌کند که آیا پاسخ، معیارهای روب ریک را برآورده می‌کند یا خیر. چارچوب‌هایی مثل DeepEval و RAGAS این تکنیک‌ها را در قالب معیارهای قابل استفاده مجدد بسته‌بندی کرده‌اند. برای مثال، یک مهندس به جای ساخت سیستم امتیازدهی وفاداری از صفر، می‌تواند از from deepeval.metrics import FaithfulnessMetric برای اعمال یک معیار پیش‌ساخته در مجموعه تست خود استفاده کند.

حفظ لایه‌ی قطعی

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

• تست‌های واحد (Unit Tests): اعتبارسنجی بلوک‌های سازنده مانند کلاینت‌های API، پارسرها و منطق تلاش مجدد (Retry Logic).
• تست‌های یکپارچگی (Integration Tests): تأیید قراردادهای ابزارها و اتصالات به پایگاه‌داده‌ها یا ذخیره‌سازهای برداری (Vector Stores).
• تست‌های عملکردی/پایان-به-پایان (E2E): اعتبارسنجی نتایج برای اطمینان از اینکه عامل با ورودی X و محیط Y به هدف Z می‌رسد.
• تست‌های آشوب و عملکرد: اطمینان از اینکه سیستم در سطح عملکردی مناسب باقی می‌ماند و پس از قطعی ابزارها یا تایم‌اوت‌ها به‌طور مناسب بازیابی می‌شود.

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

طراحی تست‌های تکرارپذیر

برای جلوگیری از تست‌های ناپایدار (Flaky)، گزارش مذکور رویکردی ساختاریافته را برای «واحد تست» پیشنهاد می‌کند. یک تست درست برای عامل باید حول یک سناریو یا رفتار متمرکز باشد و شامل موارد زیر باشد:

• تعریف سناریویی که رفتار مورد ارزیابی را توصیف می‌کند.
• یک پرامپت ورودی که سناریو را فعال می‌کند.
• یک محیط کنترل‌شده شامل پاسخ‌های ابزارها، پیکربندی و مجموعه‌داده‌ها.
• مجموعه‌ای از تأییدها (Assertions) برای ارزیابی نتیجه.

کنترل محیط حیاتی است. پاسخ ابزارها و وابستگی‌های خارجی باید تا حد امکان شبیه‌سازی (Mock) یا ثابت شوند. از آنجا که LLM خود متغیر است، اجازه دادن به تغییر محیط باعث می‌شود تشخیص این موضوع غیرممکن شود که آیا شکست ناشی از رفتار عامل بوده یا تغییر در یک وابستگی خارجی.

مهندسان همچنین باید بین «تأییدهای سخت» و «تأییدهای نرم» تمایز قائل شوند.

تأییدهای سخت در مقابل نرم

• تأییدهای سخت (Hard Assertions): این‌ها غیرقابل مذاکره هستند و باید بلافاصله باعث شکست تست شوند. مثال‌ها شامل طرح‌های (Schema) نامعتبر، مقادیر محاسباتی غلط، نبود فیلدهای اجباری یا عدم استفاده از یک ابزار ضروری است.
• تأییدهای نرم (Soft Assertions): این‌ها ذاتاً ذهنی هستند و بهتر است به صورت امتیاز یا آستانه (Threshold) نمایش داده شوند. مثال‌ها شامل کامل بودن، شفافیت، لحن، وفاداری به متن و کیفیت مسیر است.

در عمل، اکثر تست‌های عامل ترکیبی از هر دو هستند. علاوه بر این، چون رفتار LLM احتمالی است، یک بار اجرا کافی نیست. قابلیت اطمینان باید به عنوان «نرخ موفقیت» در چندین بار اجرا اندازه‌گیری شود، نه به صورت یک نتیجه دوتایی (قبول/رد).

نقش مشاهده‌پذیری (Observability)

چارچوب‌های مدرنی مثل LangSmith، Arize و DeepEval به سمت مدلی از مشاهده‌پذیری مستمر حرکت می‌کنند. آن‌ها بر سه قابلیت اصلی متمرکز شده‌اند: ثبت رفتار، ارزیابی آن از طریق معیارهای قابل استفاده مجدد و ذخیره‌سازی ارزیابی‌ها در طول زمان.

با ثبت ردپای اجرا (Execution Traces) — یعنی توالی فراخوانی ابزارها، اسناد بازیابی شده، تصمیمات میانی و تعاملات مدل — توسعه‌دهندگان می‌توانند داده‌های محیط تولید را به مجموعه‌های تست رگرسیون تبدیل کنند. برای مثال، DeepEval به توسعه‌دهندگان اجازه می‌دهد با استفاده از دکوراتور @observe اپلیکیشن‌ها را ابزارگذاری کنند تا ردپاها برای بررسی‌های بعدی جمع‌آوری شوند:

from deepeval.tracing import observe

@observe
def retrieve_documents(query):
    ...

زمانی که رفتار مشاهده شد، می‌توان آن را با استفاده از انتزاع‌ها ارزیابی کرد. به جای نوشتن تأیید روی خروجی‌ها، مهندسان روی کیفیت‌های رفتاری تأیید می‌نویسند. یک تست معمولی در DeepEval ممکن است شامل ایجاد یک LLMTestCase با ورودی، خروجی واقعی و بستر بازیابی باشد و سپس تأیید کند که نمره FaithfulnessMetric بیشتر از ۰.۸ است:

from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

metric = FaithfulnessMetric()
test_case = LLMTestCase(
    input="What is Kubernetes?",
    actual_output=response,
    retrieval_context=context
)
metric.measure(test_case)
assert metric.score > 0.8

تست رگرسیون و آینده

پایداری (Persistence) رکن نهایی است. تغییرات در پرامپت‌ها، ارتقای مدل‌ها، تغییرات در گردش کار و بهبودهای بازیابی همگی می‌توانند رگرسیون‌های غیرمنتظره ایجاد کنند. یک مورد تست پایدار به یک مصنوع قابل استفاده مجدد تبدیل می‌شود که شامل ورودی‌ها، بستر، رفتار مورد انتظار و معیارهای ارزیابی است. این مجموعه‌داده‌ها به مجموعه‌های تست رگرسیون تبدیل می‌شوند که به‌طور مکرر در طول توسعه و استقرار اجرا می‌گردند.

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

برای پیاده‌سازی این موضوع در امروز، با بازرسی گردش کارهای فعلی خود برای شناسایی «اتلاف مسیر» (Trajectory Waste) شروع کنید؛ جایی که عامل به جواب درست می‌رسد اما مسیری گران یا غیرمنطقی را طی کرده است. این اغلب اولین سیگنالی است که نشان می‌دهد سیستم شما به جای اعتبارسنجی ساده خروجی، به معیارهای رفتاری نیاز دارد.

پر کردن شکاف بین تست و تولید

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

این تغییر از طریق لایه‌های زیرساختی جدید عملیاتی می‌شود. برای مثال، ابزارهایی مثل TokenOps به عنوان یک صفحه کنترل FinOps برای اعمال بودجه توکن‌ها و سیاست‌های حاکمیتی در درخت‌های تفویض عامل عمل می‌کنند و تخصیص هزینه در لحظه و اجرای ریسک را فراهم می‌کنند. در همین حال، ابزارهایی مثل Chronicle ردپاهای اجرا و سیگنال‌های رفتاری را از هر اجرای عامل ثبت کرده و داده‌های مشاهده‌پذیری را به بینش‌های عملی برای انطباق و بهبود تبدیل می‌کنند. این ابزارها در کنار هم به تیم‌ها اجازه می‌دهند عامل‌ها را در زمان توسعه بسنجند، سیاست‌ها را در زمان اجرا اعمال کنند و از رفتار واقعی یاد بگیرند.

گام بعدی شما

• گردش کارهای فعلی خود را برای شناسایی «اتلاف مسیر» (Trajectory Waste) تحلیل کنید تا نقاط ضعف استدلالی عامل را بیابید.
• برای معیارهای معنایی (مانند وفاداری به متن یا لحن)، به جای تأییدهای سخت، از مدل‌های داور (LLM-as-a-Judge) با آستانه نمره استفاده کنید.
• یک مجموعه تست رگرسیون بر اساس ردپاهای واقعی (Traces) محیط تولید ایجاد کنید تا اثر تغییرات پرامپت را بسنجید.

اما مدیریت هزینه‌های این استنتاج‌های پیچیده چالش بعدی است — به تحلیل ما درباره مدیریت بودجه توکن‌ها در سیستم‌های عامل‌محور مراجعه کنید.