پردازش زبان طبیعی یا NLP به روش‌هایی گفته می‌شود که متن و گفتار را برای کارهایی مانند دسته‌بندی، جست‌وجو، استخراج اطلاعات و تولید پاسخ پردازش می‌کنند. در فارسی، نیم‌فاصله، شکل‌های متفاوت حروف، زبان محاوره و املای متنوع مسئله را پیچیده‌تر می‌کنند. بنابراین استفاده از یک مدل آماده یا چند قانون پاک‌سازی، بدون شناخت داده، لزوماً به سامانه‌ای دقیق و قابل‌اعتماد نمی‌رسد.
در این مقاله، پروژهٔ تحلیل نظرهای فارسی را دنبال می‌کنیم: آیا یک نظر مثبت، منفی یا خنثی است؟ هدف ساختن روندی قابل‌آزمون از متن خام تا گزارش است. از خط مبنای ساده شروع می‌کنیم و سپس جایگاه Hazm و مدل‌های زبانی را توضیح می‌دهیم. دادهٔ چندجمله‌ای آموزشی برای فهم کد کافی است، اما برای اعلام کیفیت واقعی باید مجموعه‌ای مستقل، نماینده و با مجوز مناسب داشته باشید.
مسئلهٔ NLP را دقیق‌تر از نام آن تعریف کنید
«تحلیل احساسات» می‌تواند چند معنا داشته باشد: رضایت از محصول، احساس نویسنده یا نظر دربارهٔ یک ویژگی خاص. جملهٔ «ارسال عالی بود ولی کیفیت بد بود» در سطح کل جمله و در سطح ویژگی پاسخ متفاوتی دارد. پیش از برچسب‌گذاری، تعیین کنید واحد نمونه چیست و با نظر چندموضوعی چه می‌کنید. اگر تعریف مبهم باشد، اختلاف برچسب‌گذاران به مدل منتقل می‌شود.
مخاطب و دامنه نیز اهمیت دارند. زبان نظر فروشگاهی با متن خبر و پیام پشتیبانی فرق دارد. مدلی که در یک دامنه خوب عمل می‌کند، الزاماً در دامنهٔ دیگر مناسب نیست. دستهٔ خنثی را هم روشن تعریف کنید؛ نبود واژهٔ مثبت به معنای منفی‌بودن نیست. نمونه‌های مرزی را پیش از جمع‌آوری گسترده بررسی کنید تا قرارداد برچسب‌ها از آغاز قابل‌فهم و قابل‌اجرا باشد.
چالش‌های ویژهٔ متن فارسی
یک واژه ممکن است با ی یا ک عربی، فاصله یا نیم‌فاصله و شکل محاوره نوشته شود. رقم‌ها نیز می‌توانند فارسی یا لاتین باشند. غلط تایپی، کشیدگی حرف و نشانه‌های هیجانی در متن کاربران رایج است. نرمال‌سازی می‌تواند پراکندگی غیرضروری را کم کند، اما اگر همهٔ تفاوت‌ها را حذف کند شاید اطلاعات مرتبط با لحن یا هویت یک کد از بین برود.
ترکیب فارسی و لاتین نیز مهم است؛ نام محصول، نسخه و کد خطا اغلب لاتین‌اند. حذف همهٔ کاراکترهای غیرحرفی می‌تواند همین اطلاعات را نابود کند. همچنین نشانهٔ تعجب، شکلک یا تکرار حرف ممکن است برای تحلیل احساسات مفید باشد. سیاست پیش‌پردازش باید برای وظیفهٔ مشخص آزمایش شود، نه اینکه فهرستی عمومی از «پاک‌سازی کامل» را بدون سنجش روی هر متن اجرا کنید.
جمع‌آوری و حفاظت از داده
از داده‌ای استفاده کنید که مجوز دریافت و استفاده‌اش روشن است. در نظر مشتری ممکن است نام، شمارهٔ تماس یا نشانی نوشته شده باشد. حذف یا پوشاندن این اطلاعات را پیش از اشتراک‌گذاری و آموزش بررسی کنید. انتقال متن به سرویس بیرونی نیازمند مجوز و شناخت سیاست داده است. عمومی‌بودن ظاهری یک صفحه، همهٔ محدودیت‌های حقوقی و اخلاقی استفاده را از بین نمی‌برد.
برای برچسب‌گذاری، راهنما و نمونهٔ مرزی بسازید و بخشی از داده را به چند نفر بدهید. اختلاف‌ها می‌توانند نقص تعریف یا ابهام ذاتی متن را نشان دهند. برچسب را صرفاً از ستارهٔ امتیاز استخراج نکنید مگر این فرض را سنجیده باشید؛ متن و امتیاز همیشه هم‌سو نیستند. کیفیت برچسب پایهٔ ارزیابی است و با بزرگ‌ترکردن مدل، خودبه‌خود اصلاح نمی‌شود.
نرمال‌سازی با Hazm چه کاری می‌کند؟
Hazm ابزارهایی برای پردازش فارسی مانند نرمال‌سازی و توکن‌سازی فراهم می‌کند. پیش از استفاده، نسخه و تنظیمات را بشناسید و چند جملهٔ واقعی از دامنهٔ خود را قبل و بعد مقایسه کنید. نرمال‌ساز قرار نیست معنای جمله را بفهمد یا تمام غلط‌های املایی را اصلاح کند. خروجی آن باید بخشی از فرایند آزمون باشد، نه حقیقت قطعی دربارهٔ شکل درست هر متن.
from hazm import Normalizer, word_tokenize
normalizer = Normalizer()
text = "اين محصول خوب بود، اما بسته بندی مناسبی نداشت."
normalized = normalizer.normalize(text)
tokens = word_tokenize(normalized)
print(normalized)
print(tokens)برای این عملیات ساده معمولاً لازم نیست همهٔ مدل‌های پیشرفتهٔ ابزار را دریافت کنید. بعضی قابلیت‌های دیگر مانند برچسب‌گذاری دستوری به منابع و مدل جدا نیاز دارند. فقط چیزی را نصب و بارگذاری کنید که مسئله لازم دارد. همچنین خروجی نرمال‌سازی را در چند حالت شامل نیم‌فاصله، عدد، شکلک و عبارت منفی آزمایش کنید تا تغییر ناخواسته زود آشکار شود.
توکن‌سازی، ریشه‌یابی و حذف واژه‌ها
توکن‌سازی متن را به واحدهایی مثل واژه یا زیرواژه تقسیم می‌کند. ریشه‌یابی شکل‌های مرتبط را کاهش می‌دهد، اما می‌تواند تمایزهای مفید را هم از بین ببرد. برای مدل‌های زبانی آماده معمولاً باید از tokenizer همان مدل استفاده کنید؛ جایگزین‌کردن آن با ابزار دیگر، قرارداد ورودی را می‌شکند. پیش‌پردازش مناسب یک مدل کلاسیک الزاماً برای یک Transformer مناسب نیست.
حذف ایست‌واژه‌ها هم همیشه سودمند نیست. واژه‌هایی مانند «نه» و «نیست» برای تحلیل احساسات تعیین‌کننده‌اند. جملهٔ «خوب نیست» با حذف نفی ممکن است مثبت دیده شود. حتی واژه‌های ظاهراً کم‌اطلاع در ترکیب‌ها معنا دارند. هر حذف را با آزمایش مقایسه‌ای و نمونه‌های مرزی بسنجید. هدف کم‌کردن تعداد توکن نیست؛ هدف حفظ اطلاعات لازم برای وظیفه است.
خط مبنای TF-IDF هنوز ارزش دارد
TF-IDF متن را به نمایش عددی بر اساس حضور و اهمیت نسبی واژه‌ها تبدیل می‌کند. همراه یک دسته‌بند خطی، خط مبنایی کم‌هزینه و قابل‌مقایسه می‌سازد. استفاده از n-gram می‌تواند بخشی از ترکیب‌هایی مانند «خوب نیست» را ثبت کند. این روش فهم کامل زبان ندارد، اما برای بعضی مسئله‌های محدود کاربردی است و هزینهٔ اجرای آن نسبت به مدل بزرگ کمتر است.
واژگان و وزن‌ها باید فقط روی آموزش یاد گرفته شوند. اگر ابتدا TF-IDF را روی همهٔ متن‌ها بسازید و بعد تقسیم کنید، آزمون بر نمایش آموزش اثر گذاشته است. Pipeline این مرز را روشن‌تر می‌کند. برای فارسی، n-gram نویسه‌ای هم می‌تواند در برابر بعضی تفاوت‌های املایی مفید باشد، ولی تنظیم مناسب را باید روی اعتبارسنجی انتخاب کنید و اثر آن بر حافظه و خطا را بسنجید.
from sklearn.pipeline import make_pipeline
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.linear_model import LogisticRegression
model = make_pipeline(
TfidfVectorizer(ngram_range=(1, 2), min_df=1),
LogisticRegression(max_iter=500)
)
texts = ["محصول عالی بود", "کیفیت خوبی داشت", "خیلی بد بود", "اصلا راضی نیستم"]
labels = ["positive", "positive", "negative", "negative"]
model.fit(texts, labels)
print(model.predict(["راضی نیستم"]))این چهار جمله صرفاً برای نمایش API هستند. هیچ نتیجهٔ ارزیابی از آن‌ها اعلام نمی‌شود و پیش‌بینی یک جملهٔ نزدیک به آموزش، شاهد تعمیم نیست. برای آزمایش واقعی باید متن‌های مستقل داشته باشید و برچسب‌ها را با راهنمای ثابت بسازید. اگر داده کم است، دامنهٔ مسئله را محدود و عدم‌قطعیت را صریح کنید؛ افزایش مصنوعی تعداد جمله‌های مشابه، جای نمونه‌های متنوع را نمی‌گیرد.
تقسیم داده و جلوگیری از نشت متن
نظرهای تکراری، نقل‌قول‌شده یا بسیار نزدیک را بررسی کنید. یک متن با تغییر جزئی نباید هم در آموزش و هم آزمون باشد. اگر چند نظر از یک کاربر یا دربارهٔ یک محصول بسیار خاص دارید، بسته به هدف ممکن است تقسیم گروهی لازم باشد. اگر آیندهٔ زبان و محصولات مهم است، آزمون زمانی نیز ارزش دارد. روش تقسیم باید دقیقاً نشان دهد کدام نوع تازگی را می‌سنجید.
اطلاعات جانبی مثل امتیاز ستاره، پاسخ اپراتور یا نام دسته می‌توانند هدف را لو بدهند. اگر در زمان پیش‌بینی در دسترس نیستند، استفاده از آن‌ها مجاز نیست. در گزارش، ویژگی‌های ورودی را به‌طور روشن بنویسید. نتیجهٔ مدلی که متن و امتیاز را دارد با مدل فقط متن قابل‌مقایسهٔ مستقیم نیست؛ تفاوت ورودی باید پیش از مقایسهٔ معیار اعلام شود.
ارزیابی تحلیل احساسات فارسی
توزیع کلاس‌ها، Precision و Recall هر کلاس و macro-F1 را بررسی کنید. Accuracy در مجموعه‌ای با اکثریت نظر مثبت می‌تواند گمراه‌کننده باشد. ماتریس درهم‌ریختگی نشان می‌دهد خنثی‌ها بیشتر با کدام گروه اشتباه می‌شوند. نمونه‌های خطا را با حفظ حریم خصوصی بخوانید و دسته‌بندی کنید: نفی، کنایه، چندموضوعی، غلط املایی یا اشاره به تجربه‌ای که بدون زمینه مبهم است.
برای هر دستهٔ خطا، تصمیم عملی بگیرید. شاید تعریف خنثی نیاز به اصلاح دارد یا متن‌های طولانی به سطح جمله نیاز دارند. شاید مدل باید در خروجی نامطمئن به بازبینی انسانی برود. تغییر الگوریتم فقط یکی از گزینه‌هاست. گزارش خوب توضیح می‌دهد کدام ضعف با دادهٔ بیشتر، کدام با برچسب بهتر و کدام با تغییر صورت مسئله قابل‌رفع است.
چه زمانی سراغ مدل زبانی آماده برویم؟
وقتی خط مبنا ساخته و خطاهایش شناخته شد، می‌توانید نمایش‌های عمیق یا مدل زبانی فارسی را مقایسه کنید. سازگاری tokenizer، طول ورودی، مجوز مدل و دامنهٔ آموزش را بررسی کنید. برش متن بلند ممکن است بخش تعیین‌کننده را حذف کند. نتیجه را با همان تقسیم و معیار خط مبنا بسنجید تا بهبود به تغییر داده یا آلودگی آزمون نسبت داده نشود.
تنظیم مدل آماده هزینهٔ حافظه و زمان دارد و همیشه لازم نیست. استفاده از embedding ثابت یا روش کلاسیک می‌تواند برای دامنه‌ای محدود کافی باشد. اگر مدل بزرگ اندکی بهتر است اما سرویس چند برابر کندتر می‌شود، تصمیم باید با نیاز محصول گرفته شود. همچنین احتمال‌نمایی خروجی را بدون بررسی کالیبراسیون، احتمال دقیق درست‌بودن نظر ننامید. زبان طبیعی ابهام واقعی دارد و بعضی متن‌ها پاسخ قطعی ندارند.
استقرار و پایش زبانِ در حال تغییر
در سرویس واقعی، ورودی خالی، متن بسیار بلند، نویسهٔ نامعتبر و ترکیب چند زبان را کنترل کنید. نرمال‌ساز، tokenizer و نگاشت برچسب باید همان نسخهٔ ارزیابی‌شده باشند. محدودیت طول را روشن اعلام کنید و متن را بی‌سروصدا به بخشی نامعلوم نبرید. گزارش رخدادها نیز نباید متن محرمانهٔ کاربران را بی‌دلیل ذخیره کند؛ برای پایش اغلب شاخص‌های تجمیعی کافی‌اند.
زبان و محصولات تغییر می‌کنند. واژهٔ تازه، شوخی رایج یا اصطلاح یک جامعه می‌تواند رفتار مدل را عوض کند. نمونهٔ بازبینی‌شدهٔ دوره‌ای تهیه و کیفیت را با معیار ثابت بسنجید. افت یک شاخص ورودی به‌تنهایی اثبات افت دقت نیست، اما نشانهٔ بررسی است. بازآموزی باید با دادهٔ مجاز، آزمون مستقل و معیار پذیرش انجام شود، نه صرفاً چون زمان مشخصی گذشته است.
مجموعهٔ آزمون مرزی فارسی بسازید
کنار آزمون آماری، مجموعه‌ای کوچک از رفتارهای موردانتظار نگه دارید. جملهٔ مثبت و شکل منفی همان جمله، واژه با فاصله و نیم‌فاصله و یک نمونهٔ دارای ک و ی عربی را مقایسه کنید. این موارد قرار نیست کل تنوع زبان را پوشش دهند؛ نقششان آشکارکردن شکست‌های شناخته‌شده پس از تغییر پیش‌پردازش است. هر نمونه باید علت حضور مشخصی داشته باشد تا مجموعه به انبوهی از جمله‌های تکراری تبدیل نشود.
نمونهٔ چندموضوعی را جدا تعریف کنید. اگر قرارداد شما فقط یک برچسب برای کل نظر می‌خواهد، توضیح دهید کدام بخش اولویت دارد یا چه زمانی برچسب مبهم می‌شود. برای کنایه نیز انتظار قطعیت بیش از داده نداشته باشید. بعضی جمله‌ها بدون زمینه برای انسان هم روشن نیستند. امکان برچسب «نیازمند بازبینی» یا خودداری از تصمیم می‌تواند از مجبورکردن مدل به پاسخ قطعی، طراحی مسئولانه‌تری باشد.
با هر تغییر tokenizer یا نرمال‌ساز، هم معیار مجموعهٔ مستقل و هم آزمون‌های مرزی را اجرا کنید. ممکن است میانگین کمی بهتر شود ولی جمله‌های منفی بیشتر اشتباه شوند. اگر آن گروه برای محصول مهم است، این معامله باید در تصمیم انتشار دیده شود. بهبود یک عدد کلی مجوز نادیده‌گرفتن شکست‌های پرهزینه نیست. گزارش نتیجه را به رفتار قابل‌مشاهده و نیاز استفاده‌کننده وصل کنید.
در نهایت، نسخهٔ آزمون مرزی را همراه قرارداد برچسب نگه دارید. اگر تعریف مثبت یا خنثی عوض شد، انتظارها نیز باید آگاهانه بازبینی شوند. تغییر آزمون صرفاً برای عبور نسخهٔ جدید، ارزش حفاظتی آن را از بین می‌برد. دلیل هر تغییر را روشن کنید تا بعدها معلوم باشد تفاوت نتیجه ناشی از بهبود مدل بوده یا تغییر معنای مسئله. همین شفافیت، نگهداری سامانهٔ زبانی را ممکن می‌سازد.
تمرین و پرسش‌های متداول
مجموعه‌ای کوچک با تعریف روشن برچسب تهیه کنید و پنج نمونهٔ مرزی برای نفی، کنایه، متن چندموضوعی، نیم‌فاصله و املای متفاوت بسازید. ابتدا خط مبنا را اجرا کنید، سپس فقط یک تغییر پیش‌پردازش را بسنجید. گزارش کنید کدام نمونه‌ها بهتر و کدام بدتر شدند. یک بهبود میانگین ممکن است خطای گروه مهمی را بیشتر کند؛ این معامله باید دیده شود.
آیا Hazm خودش تحلیل احساسات انجام می‌دهد؟
نقش اصلی آن ابزارهای پردازش زبان فارسی است و نباید نرمال‌سازی را با یک دسته‌بند آمادهٔ احساسات یکسان دانست. برای تحلیل احساسات به تعریف هدف، داده، نمایش متن و مدل نیاز دارید. ابزار پیش‌پردازش تنها یک جزء از این زنجیره است و کیفیت نهایی را به‌تنهایی تضمین نمی‌کند.
آیا حذف همهٔ نشانه‌ها متن را بهتر می‌کند؟
نه. شکلک، علامت و نفی ممکن است اطلاعات مهمی داشته باشند. سیاست حذف را براساس وظیفه و آزمایش تعیین کنید. برای ادامه، مقالهٔ ارزیابی مدل و استقرار FastAPI کمک می‌کنند همین روند متنی را با مرز آزمون سالم و قرارداد ورودی روشن به یک سرویس قابل‌نگهداری تبدیل کنید.
منابع و مطالعهٔ بیشتر
برای بررسی جزئیات و ادامهٔ مطالعه؛ متن این راهنما مستقلاً برای نوونتیکس نوشته شده است.