پلتفرم آزمون تطبیقی: سنجش مبتنی بر IRT برای حدود ۸۹ هزار دانش‌آموز

مهدی مولوی ۱۳ مهر ۱۴۰۵ ۵ دقیقه مطالعه

از اکتبر ۲۰۲۳ مهندس ارشد بک‌اند NovaTech هستم؛‏ شرکتی مستقر در تهران که به‌صورت دورکاری با آن کار می‌کنم. در این شرکت معماری یک پلتفرم آزمون تطبیقی را طراحی کردم که برای سنجش شخصی‌سازی‌شده و تحلیل نتایج از نظریهٔ سؤال–پاسخ (IRT) استفاده می‌کند. این پلتفرم به حدود ۸۹ هزار دانش‌آموز خدمت می‌دهد و توسعهٔ میکروسرویس‌های ‎.NET 6/8 را هم من رهبری می‌کنم.

زمینه

آزمون ثابت به همهٔ دانش‌آموزان سؤال‌های یکسان می‌دهد. برگزاری‌اش ساده است،‏ اما کارآمد نیست. دانش‌آموزان قوی وقتشان را پای سؤال‌هایی می‌گذارند که چیز تازه‌ای دربارهٔ آن‌ها نشان نمی‌دهند و دانش‌آموزان ضعیف‌تر با رشته‌ای از سؤال‌ها روبه‌رو می‌شوند که شانس چندانی برای پاسخ دادن به آن‌ها ندارند. آزمون تطبیقی این وضع را عوض می‌کند: هر سؤال بعدی را بر اساس پاسخ‌هایی انتخاب می‌کند که دانش‌آموز تا آن لحظه داده است.

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

مسئلهٔ مهندسی

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

اما همین ویژگی بک‌اند را از یک موتور آزمون معمولی سخت‌تر می‌کند. به‌طور کلی،‏ یک سیستم آزمون تطبیقی باید هم‌زمان از پس چهار چیز بربیاید:

  • وضعیت با هر پاسخ عوض می‌شود. بعد از هر پاسخ،‏ برآورد توانایی جابه‌جا می‌شود و سؤال بعدی به آن بستگی دارد. انتخاب سؤال مستقیماً سر راه دانش‌آموز است،‏ پس باید هر بار هم سریع باشد و هم درست.
  • ترافیک آزمون انفجاری است. دانش‌آموزان معمولاً با هم شروع می‌کنند و نزدیک به پایان مهلت تمام می‌کنند. سیستمی که بیشتر روزهای هفته آرام است،‏ ممکن است در عرض چند دقیقه زیر بار سنگین برود.
  • نمره‌ها باید قابل توضیح باشند. اگر به نتیجه‌ای اعتراض شود،‏ باید بتوانید نشان دهید چه سؤال‌هایی ارائه شده،‏ چه پاسخی داده شده و نمره چطور از آن به دست آمده است. برای همین،‏ ذخیرهٔ دقیق پاسخ‌ها بر میان‌برهای زیرکانه مقدم است.
  • تحلیل‌ها همان داده‌ها را می‌خوانند. گزارش‌ها باید داده‌های تعداد زیادی دانش‌آموز را تجمیع کنند و بهتر است این کار سرعت دانش‌آموزانی را که هنوز مشغول آزمون‌اند پایین نیاورد.

کاری که انجام دادم

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

  • ساخت آزمون،‏ برای تعریف آزمون‌ها و سؤال‌هایشان.
  • انتخاب سؤال،‏ که سؤال بعدیِ هر دانش‌آموز را برمی‌گزیند.
  • نمره‌دهی،‏ که پاسخ‌ها را به نتیجه تبدیل می‌کند.
  • گزارش‌گیری،‏ که از داده‌های نمره‌گذاری‌شده گزارش و تحلیل می‌سازد.

این گردش‌کارها در دوره‌های اوج آزمون هم پایدار می‌مانند.

در کنار کار معماری،‏ توسعهٔ میکروسرویس‌های ‎.NET 6/8 را رهبری می‌کنم. منتور بیش از ۵ توسعه‌دهنده هستم و استانداردهای بازبینی کد را برای قابلیت‌های پرترافیک تعیین می‌کنم. این استانداردها بیش از همه در مسیرهای پرتکرار اهمیت دارند: یک ناکارآمدی کوچک در کدی که با هر درخواست اجرا می‌شود،‏ در طول آزمون بارها و بارها تکثیر می‌شود.

نکته‌های طراحی

توضیحات زیر کلی‌اند. رویکرد را شرح می‌دهند و نقشه‌ای از ساختار داخلی NovaTech نیستند.

چرا IRT

نمره‌دهی کلاسیک پاسخ‌های درست را می‌شمارد،‏ پس نمره به این بستگی دارد که دانش‌آموز اتفاقاً با کدام آزمون روبه‌رو شده است. IRT دانش‌آموزان و سؤال‌ها را روی یک مقیاس می‌برد؛‏ به همین دلیل دو دانش‌آموز که سؤال‌های متفاوتی دیده‌اند،‏ باز هم نتیجه‌های قابل مقایسه می‌گیرند. آزمون تطبیقی دقیقاً به همین تکیه دارد. یک قاعدهٔ رایج برای انتخاب این است که سؤالی ارائه شود که در برآورد فعلی توانایی دانش‌آموز بیشترین اطلاعات را می‌دهد،‏ البته در چارچوب محدودیت‌های عملی،‏ مثل پوشش محتوای لازم و پرهیز از استفادهٔ بیش از حد از سؤال‌های یکسان.

چرا میکروسرویس و به چه قیمتی

در یک سیستم سنجش،‏ بخش‌های مختلف الگوی بار بسیار متفاوتی دارند. طراحی آزمون سبک و یکنواخت است. انتخاب سؤال و نمره‌دهی در زمان آزمون جهش می‌کنند. گزارش‌گیری بیشتر بار خواندن دارد و اغلب تأخیر کوتاهی را تحمل می‌کند. میکروسرویس‌ها اجازه می‌دهند بخش‌هایی که بار متفاوتی دارند،‏ جداگانه مقیاس‌دهی شوند و هرکدام با برنامهٔ زمانی خودش مستقر شود.

بهای این کار هماهنگی است. سرویس‌ها به قراردادهای روشن نیاز دارند و هر داده‌ای که از مرز یک سرویس عبور می‌کند باید یک مالک مشخص داشته باشد. بخش بزرگی از این انضباط در بازبینی کد اعمال می‌شود؛‏ برای همین استانداردهای بازبینی برای قابلیت‌های پرترافیک جزئی از خود معماری‌اند و نباید آن‌ها را تشریفات تیمی دانست.

ذخیره‌سازی و کش

پشتهٔ فنی این پروژه SQL Server را،‏ که از طریق EF Core به آن دسترسی داریم،‏ کنار Redis به کار می‌برد. در سیستمی از این نوع،‏ پایگاه‌دادهٔ رابطه‌ای معمولاً مرجع نهایی هر چیزی است که روی نمره اثر می‌گذارد،‏ چون تراکنش و سابقهٔ ماندگار فراهم می‌کند. یک انبارهٔ درون‌حافظه‌ای مثل Redis معمولاً داده‌هایی را نگه می‌دارد که خیلی بیشتر از آن‌که تغییر کنند خوانده می‌شوند،‏ تا در زمان اوج،‏ همان مقدارها بارها و بارها از پایگاه‌داده خواسته نشوند. در عوض،‏ هر مقدار کش‌شده باید قاعدهٔ روشنی داشته باشد که بگوید کی منقضی یا تازه می‌شود.

فناوری‌ها

  • ‎.NET 8 و ‎.NET 6،‏ به شکل میکروسرویس
  • EF Core
  • SQL Server
  • Redis
  • Docker
  • Python

نتیجه

  • یک پلتفرم آزمون تطبیقی مبتنی بر IRT که به حدود ۸۹ هزار دانش‌آموز خدمت می‌دهد.
  • گردش‌کارهای ساخت آزمون،‏ نمره‌دهی،‏ گزارش‌گیری و انتخاب سؤال که در دوره‌های اوج آزمون پایدار می‌مانند.

مطالب مرتبط

اوج ترافیک آزمون‌ها موضوع نمونه‌کار Redis Sentinel هم هست که به کار قبلی‌ام در «گزینه دو» برمی‌گردد. اگر یک سیستم سنجش یا یک سیستم پرترافیک ‎.NET در دست برنامه‌ریزی دارید،‏ صفحهٔ همکاری را ببینید.

پرسش‌های رایج

مهدی مولوی در NovaTech چه چیزی ساخت؟

معماری یک پلتفرم آزمون تطبیقی را طراحی کرد که برای سنجش شخصی‌سازی‌شده و تحلیل نتایج از نظریهٔ سؤال–پاسخ (IRT) استفاده می‌کند. این پلتفرم به حدود ۸۹ هزار دانش‌آموز خدمت می‌دهد.

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

پشتهٔ فنی آن میکروسرویس‌های ‎.NET 8 و ‎.NET 6 است،‏ همراه با EF Core،‏ SQL Server،‏ Redis،‏ Docker و Python.

نقش او در تیم چیست؟

از اکتبر ۲۰۲۳ توسعهٔ میکروسرویس‌های ‎.NET 6/8 را رهبری می‌کند،‏ منتور بیش از ۵ توسعه‌دهنده است و استانداردهای بازبینی کد را برای قابلیت‌های پرترافیک تعیین می‌کند.

در همین بخش

اشتراک‌گذاری
نمونه‌کارها