چالشهای پردازش زبان فارسی در پروژههای هوش مصنوعی
پروژههای هوش مصنوعی فارسی که به نتیجه نمیرسند، معمولاً در انتخاب مدل اشتباه نکردهاند. در لایهای شکست خوردهاند که در هیچ راهنمای انگلیسیای دربارهٔ آن نوشته نشده، چون برای انگلیسی وجود ندارد.
یک متن، چند نوشتار
مسئله بنیادی این است که یک عبارت فارسی به چند شکل نوشته میشود و ماشین آنها را یکی نمیبیند.
نیمفاصله. «کتابها» با نیمفاصله، «کتاب ها» با فاصله کامل، و «کتابها» چسبیده. سه رشته متفاوت، یک کلمه.
«ی» و «ک» عربی در برابر فارسی. کاراکترهای متفاوتی با کدهای متفاوتاند. کاربران با صفحهکلیدهای مختلف هر دو را تایپ میکنند و اسناد قدیمی معمولاً پر از شکل عربیاند.
اعداد. «۱۲۰» فارسی، «١٢٠» عربی و «120» لاتین. در یک سند مالی معمولاً هر سه پیدا میشود.
اعراب و تشدید. گاهی در متن هست و در پرسش نیست.
«ه» پایانی و «هٔ». «خانهٔ» و «خانهی» و «خانه».
هیچکدام از اینها خطای کاربر نیست؛ همه نوشتار درستاند. مسئله این است که ماشین بدون یک لایه یکسانسازی، آنها را چند چیز متفاوت میبیند.
نرمالسازی، ارزانترین کاری که بیشترین اثر را دارد
راهحل، لایهای است که متن را پیش از هر پردازشی به یک شکل استاندارد تبدیل کند: یکسانکردن «ی» و «ک»، تبدیل اعداد به یک نوع، حذف اعراب، مدیریت نیمفاصله و پاکسازی فاصلههای اضافه و کاراکترهای نامرئی.
قاعدهای که رعایتش حیاتی است: نرمالسازی باید روی هر دو سمت اعمال شود — هم موقع نمایهکردن اسناد، هم موقع خواندن پرسش کاربر. اگر فقط یک طرف نرمال شود، عملاً هیچ کاری نکردهاید.
در تجربه ما، این لایه بیشتر از انتخاب مدل روی کیفیت نهایی اثر میگذارد. تیمهایی که ماهها صرف مقایسه مدلها کردهاند و به نتیجه نرسیدهاند، اغلب همین را نداشتهاند.
جهت متن و محتوای مخلوط
متن فارسی راستبهچپ است و تقریباً همیشه با محتوای چپبهراست مخلوط میشود: نام محصول انگلیسی، کد قطعه، آدرس ایمیل، عدد.
الگوریتم دوجهته مرورگر معمولاً درست عمل میکند، اما در چند جا خراب میشود که مستقیم به تجربه کاربر میخورد: عبارتی که با نقطه یا علامت شروع میشود مثل «.NET»، پرانتزی که سمت اشتباه بسته میشود، و بازه عددی که وارونه دیده میشود.
راهش جداسازی صریح بخشهای لاتین است، نه امید به اینکه خودش درست شود.
تشخیص موجودیت
استخراج نام و تاریخ و مبلغ از متن فارسی، مسائل خودش را دارد.
تاریخ شمسی. «۱۴۰۳/۰۵/۱۲» و «۱۲ مرداد ۱۴۰۳» و «دوازدهم مرداد». تبدیلشان به یک قالب واحد و بعد به میلادی، یک لایه جدا میخواهد.
مبلغ. تومان و ریال، «۵۰۰ هزار» و «نیم میلیون»، و جداکنندههای مختلف.
نام اشخاص. فاصله در نامهای مرکب، پیشوندهای احترام، و نامهایی که با کلمات عادی همشکلاند.
شماره ملی و شبا و کد اقتصادی. اینها الگوی مشخص دارند و بهتر است با قاعده استخراج شوند، نه با مدل — دقتشان بالاتر و هزینهشان صفر است.
قاعدهای که کلی صدق میکند: هر چیزی که الگوی قطعی دارد را با قاعده استخراج کنید، نه با مدل زبانی. مدل را برای چیزهایی نگه دارید که قاعده ندارند.
زبان محاوره در برابر زبان سند
این فاصله در فارسی محسوستر از انگلیسی است. مشتری مینویسد «چند وقت ضمانت داره؟» و سند نوشته «مدت زمان گارانتی محصول».
چند چیز که کمک میکنند: فهرست مترادف ساختهشده از پرسشهای واقعی کاربران — نه از حدس؛ جستجوی معنایی در کنار جستجوی کلیدواژهای، که در پایگاه داده برداری توضیحش دادهایم؛ و مهمتر از هر دو، استفاده از پرسشهای واقعی خودتان بهعنوان مجموعه آزمون.
اگر سامانه را با پرسشهایی بسنجید که خودتان نوشتهاید، نتیجه خوبی میگیرید که هیچ ربطی به واقعیت ندارد. تیکتهای واقعی، تنها معیار قابل اتکاست.
کیفیت داده منبع
مسائلی که در اسناد فارسی سازمانی تقریباً همیشه پیدا میشوند:
فایلهای اسکنشده بدون لایه متنی، که اول باید متنشان استخراج شود — و دقت این کار برای فارسی پایینتر از انگلیسی است، مخصوصاً برای اسناد قدیمی.
متن کپیشده از PDF که فاصلههایش به هم ریخته.
جدولهایی که ساختارشان در تبدیل به متن از بین میرود و اعداد بیمعنا میشوند.
و فایلهایی با کدگذاری قدیمی.
بخش قابل توجهی از زمان یک پروژه واقعی صرف همینها میشود، نه صرف کار با مدل. اگر برآوردی گرفتهاید که این بخش در آن دیده نشده، برآورد ناقص است.
چه چیزی را بپرسید
اگر راهکاری بر پایه هوش مصنوعی برای متن فارسی به شما پیشنهاد شده:
نرمالسازی متن فارسی دارید؟ روی هر دو سمت اعمال میشود؟
مدل بردارسازی روی فارسی چطور عمل میکند و با چه دادهای سنجیده شده؟
تاریخ شمسی و مبالغ ریالی چطور مدیریت میشوند؟
و کیفیت را با چه مجموعه پرسشی سنجیدهاید — پرسشهای واقعی کاربر یا نمونههای ساختهشده؟
جواب سؤال آخر معمولاً بیشترین اطلاعات را دربارهٔ جدیبودن کار میدهد.