چطور یک مجموعه آزمون فارسی برای محصول هوش مصنوعی بسازیم؟
English
پاسخ کوتاه: برای سنجش کیفیت یک مدل، چتبات یا قابلیت هوش مصنوعی فارسی، چند پرسش ترجمهشده از انگلیسی کافی نیست. یک مجموعه آزمون مفید باید از کار واقعی محصول ساخته شود و جداگانه خط فارسی، نیمفاصله، عدد و تاریخ، متن ترکیبی فارسیـانگلیسی، تشخیص موجودیت، درک معنا، کیفیت شواهد، حریم خصوصی و توقف ایمن را بسنجد.
برای شروع میتوانید فایل CSV مجموعه آزمون فارسی را دانلود کنید. این فایل ۳۶ سناریوی مصنوعی و قابلویرایش دارد. راهنما و مجوز استفاده نیز همراه آن منتشر شده است. این دارایی یک benchmark علمی، رتبهبندی مدلها یا نمونه جامع همه گونههای فارسی نیست؛ یک نقطه شروع عملی برای تبدیل نیاز محصول به test case است.
«پشتیبانی از فارسی» با «عملکرد قابلقبول در فارسی» یکی نیست
ممکن است یک مدل بتواند متن فارسی روان تولید کند، اما در همان محصول نام دو نفر مشابه را یکی بداند، تومان را با ریال اشتباه بگیرد، تاریخ شمسی و میلادی را بدون اعلام فرض مخلوط کند یا نبود منبع را با یک پاسخ مطمئن پنهان کند. کیفیت زبانی فقط یکی از لایههاست؛ معیار نهایی این است که سیستم در کار واقعی چه تصمیمی میگیرد و آیا نتیجه قابلبررسی است.
خط فارسی نیز جزئیات فنی مهمی دارد. استاندارد Unicode 17 جهت راستبهچپ و نقش U+200C یا فاصله مجازی را توضیح میدهد. حذف یا جابهجایی این نویسه همیشه یک تغییر ظاهری بیاهمیت نیست. «بهروز» و «بهروز» نمونه سادهای است که نشان میدهد یک pipeline نامناسب normalization میتواند دو رشته متفاوت را یکسان ببیند یا نمایش را خراب کند.
پژوهشهای فارسی چه چیزی به تیم محصول یاد میدهند؟
ParsiNLU بیش از ۱۴٫۵ هزار نمونه در شش وظیفه فهم زبان فارسی ارائه کرد؛ از درک مطلب و استلزام متنی تا تحلیل احساس، بازنویسی پرسش و ترجمه. نکته مهم برای محصول فقط اندازه داده نیست. پژوهش بر نمونههای طبیعی، ارزیابی گویشوران بومی و محدودیت artifactهای ناشی از ترجمه ماشینی تأکید میکند.
پژوهش Advancing Persian LLM Evaluation در سال ۲۰۲۵ دو benchmark تازه، PeKA و PK-BETS، را برای دانش فرهنگی و زمینهای، تاریخ، ادبیات و سبک فارسی معرفی کرد و مسئله آلودگی داده را جدی گرفت. ELAB نیز ارزیابی فارسی را به ایمنی، انصاف و هنجارهای اجتماعی گسترش داد و داده ترجمهشده، مصنوعی و طبیعی را از هم تفکیک کرد.
FarSense شش نوع مسئله استدلال عرفی را با فرایند بازبینی انسانی چندمرحلهای پوشش میدهد. preprint سال ۲۰۲۶ با نام PARSE نیز ۱۰٬۸۰۰ پرسش استدلالی فارسی در قالب درست/نادرست، چندگزینهای و پاسخ کوتاه گزارش میکند. این منابع نشان میدهند «فارسی» یک ستون واحد در گزارش کیفیت نیست؛ زبان، فرهنگ، استدلال، ایمنی و نوع وظیفه باید به برشهای جدا تبدیل شوند.
اما benchmark پژوهشی جای آزمون پذیرش محصول را نمیگیرد. پژوهش برای مقایسه قابلبازتولید مدلها طراحی میشود؛ test set محصول باید خطاهایی را بسنجد که برای کاربر، درآمد، حریم خصوصی یا عملیات همان محصول اهمیت دارند.
فرق benchmark پژوهشی و مجموعه آزمون محصول
| موضوع | benchmark پژوهشی | مجموعه آزمون محصول |
|---|---|---|
| هدف | مقایسه روشها یا مدلها با یک پروتکل مشترک | تصمیم انتشار برای یک قابلیت و جریان مشخص |
| داده | نمونه ثابت، مستند و قابلبازتولید | نمونه نماینده از ورودی واقعی، مرزی و پرریسک محصول |
| معیار | معمولاً accuracy، F1 یا معیار تخصصی وظیفه | قبولی/رد، rubric، صحت وضعیت، شواهد و هزینه بازبینی |
| ریسک | تمرکز بر اعتبار علمی و آلودگی داده | تمرکز بر اثر واقعی خطا، قابلیت rollback و کنترل انسانی |
| خروجی | نتیجه آزمایش و مقایسه | تصمیم deploy، دامنه پایلوت و شرط توقف |
هشت برش ضروری برای آزمون محصول فارسی
۱. نویسه و املای فارسی
ی و ک فارسی و عربی، نیمفاصله، نشانه سؤال، فاصلهگذاری پسوندها و normalization را جدا آزمایش کنید. معیار را دقیق بنویسید: آیا سیستم باید متن را اصلاح کند، رشته را عیناً حفظ کند یا دو شکل را معادل بداند؟ یک قاعده ثابت برای همه کاربردها وجود ندارد.
۲. عدد، درصد و واحد پول
اعداد فارسی و لاتین، جداکننده هزارگان، ممیز، درصد، تومان و ریال را در ورودیهای ترکیبی قرار دهید. خروجی درست باید علاوه بر عدد نهایی، واحد و مسیر محاسبه را حفظ کند. برای کاربرد مالی، نتیجه را با یک محاسبه قطعی مستقل بررسی کنید.
۳. تاریخ، ساعت و تقویم
سال شمسی و میلادی، تاریخهای مبهم مانند 03/04/05، منطقه زمانی و موعدهای نسبی را پوشش دهید. رفتار مطلوب در ورودی مبهم اغلب «پرسیدن سؤال» است، نه حدسزدن. تبدیل تاریخ و منطقه زمانی باید با کتابخانه و داده رسمی انجام شود، نه حافظه مدل.
۴. متن راستبهچپ و محتوای ترکیبی
URL، ایمیل، نسخه نرمافزار، command، مسیر فایل و نام انگلیسی را داخل جمله فارسی آزمایش کنید. هم متن خام و هم خروجی رندرشده را ببینید؛ ممکن است رشته درست ذخیره شود اما در رابط کاربری ترتیب یا علامتگذاری آن ناخوانا باشد.
۵. نام و تشخیص موجودیت
نامهای مشابه، عنوانهای احترامآمیز، املای لاتین و فارسی یک برند و برخورد چند فرد همنام را بسنجید. سیستم نباید دو پروفایل را فقط با تشابه نام ادغام کند. برای انتساب هویت، شناسه و منبع تأییدکننده لازم است.
۶. معنا، قطعیت و کاربرد زبان
نفی، شرط، احتمال، کنایه ملایم و تعهد آینده را جدا کنید. جمله «ممکن است قیمت تغییر کند» خبر از تغییر قطعی نمیدهد. «فردا بررسی میکنم» نیز به معنی انجامشدن کار نیست. معیار خوب تفاوت بین متن روان و برداشت درست را آشکار میکند.
۷. شواهد، عدم قطعیت و وضعیت منبع
عمداً سؤالهایی بسازید که منبع کافی ندارند، دو منبعشان تعارض دارد یا تاریخشان مشخص نیست. مدل باید کمبود مدرک را اعلام کند. submission را publication، پیام Sent را delivery و Accepted را Published نامیدن، خطای زبانی ساده نیست؛ شکست در حفظ وضعیت واقعی است.
۸. ایمنی، حریم خصوصی و جریان محصول
سناریوهای داده شخصی، کد ورود، ادعای پزشکی، عنوان شغلی تأییدنشده و اقدام عمومی را با معیار توقف روشن بسنجید. در حوزه پرریسک، rubric باید با متخصص همان حوزه نوشته شود. فایل نمونه عمداً نتیجه پزشکی، حقوقی یا مالی تولید نمیکند.
مجموعه آزمون را در هفت مرحله بسازید
- کار و ریسک را تعریف کنید. بنویسید کاربر چه میخواهد، خروجی کجا مصرف میشود و خطای آن چه اثری دارد.
- ورودی واقعی و مصنوعی را جدا نگه دارید. نمونه واقعی باید ناشناس و مجاز باشد. نمونه مصنوعی برای حالت مرزی مفید است، اما نباید بهعنوان توزیع واقعی کاربران معرفی شود.
- برشهای ارزیابی را انتخاب کنید. هر محصول به هر هشت برش وزن یکسان نمیدهد. چتبات پشتیبانی، استخراج فاکتور و جستوجوی پژوهشی failure profile متفاوت دارند.
- معیار پذیرش را پیش از اجرا بنویسید. پاسخ exact، مجموعه requirement، rubric انسانی یا read-back سیستم را مشخص کنید. بعد از دیدن خروجی مدل، معیار را برای قبولکردن همان پاسخ عوض نکنید.
- حالت عادی، مرزی و توقف امن بسازید. نبود داده، تناقض، دستور غیرمجاز و ورودی بدقالب را عمداً وارد کنید.
- اجرای تکراری و قابلردیابی بگیرید. مدل، نسخه، system prompt، ابزارها، دما، تاریخ، تعداد retry و نتیجه reviewer را ثبت کنید. یک اجرای موفق، نرخ اطمینان نیست.
- نتیجه را به تفکیک برش گزارش کنید. میانگین کل میتواند شکست جدی در تاریخ یا حریم خصوصی را پنهان کند. حداقل هر دسته و هر سطح ریسک را جدا ببینید.
چطور از فایل CSV استفاده کنیم؟
فایل starter شامل شناسه، گونه زبان، دسته، ورودی کاربر، requirementهای مورد انتظار، رفتار ممنوع، سطح ریسک، روش امتیازدهی و تعداد تکرار پیشنهادی است. ابتدا ردیفهای نامرتبط را حذف کنید. سپس حداقل نیمی از مجموعه نهایی را از وظایف واقعی و ناشناسشده محصول خود بسازید. سناریوهای عمومی این فایل نباید جایگزین مشاهده رفتار کاربران شوند.
برای هر اجرا ستونهای تازهای مانند model_id، prompt_version، output، pass، reviewer، latency و evidence_url اضافه کنید. خروجیهای حساس را در فایل عمومی ذخیره نکنید. اگر مدل یا prompt تغییر کرد، فقط میانگین قدیمی را کپی نکنید؛ برشهای اثرپذیر را دوباره اجرا کنید.
این مجموعه با مجوز CC BY 4.0 منتشر شده است تا تیمها بتوانند آن را اقتباس کنند؛ نسبتدادن منبع لازم است. مثالها مستقل نوشته شدهاند و از benchmarkهای دانشگاهی کپی نشدهاند. برای پژوهش علمی، مستندات و مجوز همان dataset را مستقیماً بررسی کنید.
یک قانون ساده برای تصمیم انتشار
پیش از آزمایش، failureهای مانع انتشار را تعیین کنید. برای نمونه: افشای داده شخصی، ادغام اشتباه هویت، تبدیل وضعیت تأییدنشده به واقعیت و حدسزدن در اقدام برگشتناپذیر میتوانند حتی با میانگین کلی بالا، مانع deploy باشند. در مقابل، یک خطای جزئی نشانهگذاری شاید با اصلاح رابط و بازبینی محدود مدیریت شود.
برای ارزیابی کل سیستم—شامل ابزار، permission، recovery و کنترل انسانی—از چارچوب ارزیابی ایجنت هوش مصنوعی استفاده کنید. این مقاله فقط لایه زبان و پذیرش محصول فارسی را عمیقتر میکند. Phronesis Index نیز یک preprint عمومی درباره سازگاری در شبکهها و سیستمهای چندعاملی است؛ در اینجا صرفاً بهعنوان زمینه پژوهشی معرفی میشود و نتایج آن peer-reviewed نیست.
جمعبندی
کیفیت فارسی را با یک گفتوگوی نمایشی یا ترجمه benchmark انگلیسی تأیید نکنید. کار واقعی را به برشهای زبانی، عددی، زمانی، معنایی، شواهدی و ایمنی تبدیل کنید؛ معیار را قبل از اجرا بنویسید؛ نتیجه را تکرار و به تفکیک گزارش کنید. مجموعه آزمون کوچک اما صادقانه، برای تصمیم محصول ارزشمندتر از یک امتیاز بزرگ و مبهم است.
مقالههای فارسی سپهر بیات مسیرهای عملی دیگری درباره محصول و سیستمهای هوش مصنوعی ارائه میکنند.
منابع بررسیشده
- ParsiNLU: A Suite of Language Understanding Challenges for Persian
- Advancing Persian LLM Evaluation
- ELAB: Extensive LLM Alignment Benchmark in Persian Language
- FarSense: A Comprehensive Commonsense Benchmark for Farsi
- PARSE: An Open-Domain Reasoning QA Benchmark for Persian
- The Unicode Standard 17, Chapter 9