پردازش سؤال با هوش مصنوعی: از PDF آزمون تا سؤال‌های ساخت‌یافته در LaTeX

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

از ژانویه تا دسامبر ۲۰۲۴ به‌صورت قراردادی و دورکاری برای Noraco،‏ شرکتی مستقر در استرالیا،‏ کار کردم. خط پردازشی را خودکار کردم که آزمون‌های مکتوب را به شکل PDF می‌گیرد و به سؤال‌های ساخت‌یافته و آمادهٔ پایگاه‌داده در قالب LaTeX تبدیل می‌کند؛‏ در مجموع بیش از ۵٬۰۰۰ سؤال. APIهای مدل‌های زبانی بزرگ (LLM) فرادادهٔ موضوع،‏ مهارت و سختی را تولید می‌کنند و یک کنسول بازبینی ساخته‌شده با React اعتبارسنجی،‏ کنترل کیفیت و انتشار را پوشش می‌دهد.

زمینه

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

هدف این بود که این محتوا به یک بانک سؤال تبدیل شود. هر سؤال یک رکورد مستقل و ساخت‌یافته با فرادادهٔ خودش می‌شود که در پایگاه‌داده ذخیره شده و برای انتشار آنلاین آماده است.

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

تبدیل PDF آزمون‌ها به سؤال‌های تمیز سخت‌تر از آن است که به نظر می‌رسد،‏ و دلیل‌هایش به این پروژه محدود نمی‌شود:

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

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

  • خط پردازش سؤال. تبدیل PDF به LaTeX را خودکار کردم تا آزمون‌های مکتوب به سؤال‌های ساخت‌یافته و آمادهٔ پایگاه‌داده تبدیل شوند. خروجی آن بیش از ۵٬۰۰۰ سؤال بود.
  • فراداده با مدل زبانی. APIهای مدل زبانی را از طریق OpenRouter یکپارچه کردم تا برای سؤال‌ها فرادادهٔ موضوع،‏ مهارت و سختی تولید شود.
  • سرویس‌های بک‌اند. سرویس‌ها را به شکل اپلیکیشن‌های FastAPI تحویل دادم.
  • کنسول بازبینی. یک کنسول بازبینی با React برای اعتبارسنجی LaTeX،‏ کنترل کیفیت و انتشار آنلاین تحویل دادم.

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

نکته‌های زیر استدلال کلی پشت خط پردازشی مثل این را توضیح می‌دهند و توصیفی از زیرساخت داخلی Noraco نیستند.

LaTeX به‌عنوان قالب سؤال

LaTeX به هر سؤال یک شکل متنی می‌دهد که برای ریاضیات دقیق است و آدم‌ها هم می‌توانند آن را بخوانند. یک بررسی اولیهٔ ارزان هم فراهم می‌کند: اگر LaTeX یک سؤال کامپایل یا رندر نشود،‏ جایی اشتباه شده و سیستم می‌تواند پیش از آن‌که کسی نگاهش کند،‏ آن را علامت بزند. به این ترتیب بخشی از پرسشِ «آیا این تبدیل درست است؟» به یک آزمون مکانیکی تبدیل می‌شود.

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

مدل زبانی برای فراداده،‏ در حد پیش‌نویس

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

چرا OpenRouter

OpenRouter مدل‌های زیادی از ارائه‌دهنده‌های مختلف را پشت یک API قرار می‌دهد. برای خط پردازشی که روی هزاران سؤال اجرا می‌شود،‏ این یعنی کد یکپارچه‌سازی ثابت می‌ماند و انتخاب مدل باز است؛‏ چه دلیل عوض کردن مدل کیفیت در یک درس خاص باشد،‏ چه هزینه،‏ چه در دسترس بودن.

چرا کنسول بازبینی مهم است

حجم کار را خودکارسازی می‌کشد و قضاوت را آدم‌ها. کنسول بازبینی اهمیت دارد،‏ چون تبدیل و برچسب‌گذاری گاهی اشتباه می‌کنند و ارزان‌ترین جا برای گرفتن این اشتباه‌ها ابزاری است که برای همین کار ساخته شده؛‏ جایی که بازبین بتواند یک سؤال را بدون برگشتن سراغ فایل‌ها بررسی و اصلاح کند. وقتی انتشار هم در همان کنسول باشد،‏ دروازهٔ روشنی بین «تبدیل‌شده» و «منتشرشده» باقی می‌ماند: هیچ سؤالی فقط به این دلیل که یک اسکریپت کارش را تمام کرده،‏ آنلاین نمی‌شود.

FastAPI در بک‌اند

کتابخانه‌های پردازش سند و کلاینت‌های مدل زبانی در Python پشتیبانی خوبی دارند. FastAPI راهی سبک برای ارائهٔ کد Python به شکل سرویس HTTP است،‏ با مدل‌های تایپ‌شدهٔ درخواست و پاسخ و مستندات API که خودکار تولید می‌شود. این‌ها وقتی فرانت‌اند بازبینی و بک‌اندش کنار هم توسعه پیدا می‌کنند به کار می‌آیند،‏ چون قرارداد بین آن دو یک‌جا مکتوب است.

فناوری‌ها

  • Python و FastAPI
  • APIهای مدل زبانی از طریق OpenRouter
  • LaTeX
  • React برای کنسول بازبینی

نتیجه

آزمون‌های مکتوبی که فقط به شکل PDF وجود داشتند،‏ به بیش از ۵٬۰۰۰ سؤال ساخت‌یافته و آمادهٔ پایگاه‌داده تبدیل شدند که فرادادهٔ موضوع،‏ مهارت و سختی‌شان را مدل زبانی تولید کرده است. کنسول React برای اعتبارسنجی LaTeX،‏ کنترل کیفیت و انتشار آنلاین یک جای واحد در اختیار پروژه می‌گذارد.

مطالب مرتبط

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

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

خط پردازش سؤال Noraco چه کاری انجام می‌داد؟

آزمون‌های مکتوبی را که به شکل PDF بودند به سؤال‌های ساخت‌یافتهٔ LaTeX و آمادهٔ پایگاه‌داده تبدیل می‌کرد؛‏ در مجموع بیش از ۵٬۰۰۰ سؤال.

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

مهدی مولوی APIهای مدل زبانی را از طریق OpenRouter یکپارچه کرد تا برای سؤال‌ها فرادادهٔ موضوع،‏ مهارت و سختی تولید شود.

کنسول بازبینی برای چه بود؟

یک اپلیکیشن React برای اعتبارسنجی LaTeX،‏ کنترل کیفیت و انتشار آنلاین سؤال‌هاست و سرویس‌های FastAPI در بک‌اند آن کار می‌کنند.

در همین بخش

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