پیش از فاین‌تیون فارسی، مسئله را دقیق کنیم

چه وقت آموزش دوباره لازم است، چه وقت بازیابی از سند بهتر جواب می‌دهد و چطور نتیجه را با مدل پایه مقایسه کنیم.

«مدل فارسی خوبی ندارد» برای شروع آموزش کافی نیست. مشکل دقیقاً کجاست؟ شاید جمله‌هایش ترجمه‌زده‌اند، شاید مقررات کسب‌وکار را نمی‌داند، یا شاید در فهم شرط‌های یک متن اشتباه می‌کند. هر کدام راه‌حل خودش را دارد.

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

خطا را به کار مشخص وصل کنیم

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

برای هر نمونه، ورودی، پاسخ مطلوب و دلیل نامناسب بودن پاسخ فعلی را ثبت کنید. «بد بود» برچسب مفیدی نیست؛ «مهلت مرجوعی را از خودش ساخت» به تصمیم بعدی کمک می‌کند.

آموزش یا بازیابی از سند؟

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

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

فارسی را یکدست کنیم، معنا را نه

شکل فارسی و عربی حروف، ارقام و نیم‌فاصله در متن تنوع دارند. بعضی تفاوت‌ها فقط نگارشی‌اند؛ بعضی در لینک، شناسه و کد اهمیت دارند. همه را یکسان نکنید. تبدیل سراسری رقم‌ها یا حذف فاصله‌های خاص می‌تواند دادهٔ سالم را خراب کند.

قاعدهٔ پاک‌سازی باید نوع متن را بشناسد. در نثر، یکدستی نگارش مفید است. در یک قطعهٔ کد، نام متغیر و رشتهٔ متنی باید مطابق کارکردشان حفظ شوند. خروجی پاک‌سازی را روی نمونه‌های واقعی بخوانید؛ کم شدن تعداد کاراکترها معیار موفقیت نیست.

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

مدل پایه را نگه داریم

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

کاهش خطای آموزش نشان می‌دهد مدل نمونه‌های آموزشی را بهتر یاد گرفته است. از آن نمی‌توان نتیجه گرفت که روی متن ناآشنا بهتر کار می‌کند. در تجربهٔ ما هم نسخه‌هایی با بهبود در کار هدف، در آزمون‌های دیگر افت داشتند و پذیرفته نشدند.

از نتیجه، به‌اندازهٔ شاهد حرف بزنیم

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

در دانا، هدهد v2.3 برای ترجمه و بازنویسی فارسی و قناری ایرانی v0.1 برای کارهای تصمیم مشخص سنجیده شده‌اند. هما، از خانوادهٔ مدل‌های زبانی هما، ققنوس و سیمرغ، در عرضهٔ عمومی «به‌زودی» است. نام یک خانواده، شاهد آماده بودن همهٔ مدل‌های آن نیست.

برای ادامه، چرا فارسی‌سازی گاهی به استدلال آسیب می‌زند سازوکار احتمالی این افت را توضیح می‌دهد.

ترجمه و تصمیم‌گیری با API دانا
روش استفاده از هدهد و سنجه را در مستندات بخوانید.