جست‌وجوی محصول فارسی: نرمال‌سازی، مترادف و رتبه‌بندی نتایج

مشتری می‌نویسد «کفش ورزشی»، فروشگاه «کفش‌ورزشی» دارد؛ مشتری «موبایل» می‌زند ولی محصول با «گوشی» ثبت شده؛ مشتری با ارقام فارسی «۱۲۸ گیگ» می‌زند و کاتالوگ «128GB» دارد. نتیجه: «محصولی یافت نشد» در حالی که محصول هست. این مقاله مسئلهٔ جست‌وجوی فارسی را از نرمال‌سازی حروف تا ارقام، نیم‌فاصله، مترادف و رتبه‌بندی، به‌صورت چارچوبی قابل‌آزمون می‌چیند.

مرز منابع: رفتار تحلیل‌گر فارسی را از مستند رسمی Elasticsearch می‌گیریم؛ بخش «بدون نتیجه» از NN/G است. ما Elasticsearch را توصیه نمی‌کنیم و فقط چون مستند روشنی برای فارسی دارد نمونه گرفته‌ایم؛ موتورهای دیگر (OpenSearch، Meilisearch، PostgreSQL و غیره) ممکن است پشتیبانی یا نام‌های دیگری داشته باشند و بررسی نشده‌اند. نتیجهٔ دقیق هر فیلتر را روی داده و نسخهٔ خودتان با ابزار تحلیل (مثل ‎_analyze) آزمایش کنید. بخش‌های «توصیهٔ نویسنده» منبع مستقل ندارند.

مسئله: چرا «محصولی یافت نشد»؟

NN/G می‌گوید در جست‌وجوی داخلی سایت، کاربران اغلب به صفحهٔ «بدون نتیجه» می‌رسند، حتی وقتی محتوا هست اما با پرس‌وجو تطبیق نمی‌خورد؛ و این صفحه اغلب بن‌بست می‌شود. در فارسی چند منبع کلاسیک عدم‌تطبیق وجود دارد:

• دو شکل «ی» و «ک» (فارسی در برابر عربی) و شکل‌های مشابه نویسه‌ها.
• ارقام فارسی، عربی و لاتین.
• نیم‌فاصله (ZWNJ) در «کفش‌ورزشی» در برابر «کفش ورزشی» و «می‌روم/میروم».
• مترادف‌ها و نام‌های عامیانه («موبایل/گوشی»، «لپ‌تاپ/لپتاپ»).
• غلط املایی و تایپ با کیبورد انگلیسی.
• تلفیق فارسی و لاتین در نام برند و مدل (مثل «سامسونگ A54»).

گام ۱: نرمال‌سازی هنگام نمایه‌سازی و جست‌وجو

مستند Elasticsearch تحلیل‌گر فارسی را این‌گونه بازسازی می‌کند: یک char_filter که ZWNJ را با فاصلهٔ ASCII جایگزین می‌کند، tokenizer استاندارد، و فیلترها به‌ترتیب: lowercase، decimal_digit، arabic_normalization، persian_normalization، persian_stop و persian_stem. اسکلت پیکربندی (برگرفته از مستند):

"char_filter": { "zero_width_spaces": { "type": "mapping", "mappings": ["\u200C=>\u0020"] } },
"analyzer": { "rebuilt_persian": {
  "tokenizer": "standard",
  "char_filter": ["zero_width_spaces"],
  "filter": ["lowercase","decimal_digit","arabic_normalization","persian_normalization","persian_stop","persian_stem"] } }

چند نکتهٔ مهم برای محصول:

• فیلتر decimal_digit ارقام دستهٔ Unicode Decimal_Number را به 0-9 تبدیل می‌کند؛ مستند مثالی با ارقام دیواناگری و بنگالی دارد. پس برای «۱۲۸» و «128» در یک شاخص، تحلیل‌گر یکسان استفاده کنید. باید با ‎_analyze روی ارقام فارسی همین رفتار را راستی‌آزمایی کنید.
• نگاشت ZWNJ به فاصله باعث می‌شود «کفش‌ورزشی» دو توکن «کفش» و «ورزشی» شود. این همان چیزی است که اغلب می‌خواهیم، اما برای نام‌هایی که نیم‌فاصله بخشی از املا است باید بررسی شود.
• فیلتر persian_stem ریشه‌یابی می‌کند. مستند خودش یادآوری می‌کند این فیلتر باید حذف شود اگر واژه‌هایی هستند که نباید ریشه‌یابی شوند (مثل نام برند). برای کاتالوگ فروشگاه، معمولاً برند و مدل را در فیلد جدا بدون stem نگه دارید. (توصیهٔ نویسنده بر پایهٔ این یادآوری.)
• فهرست توقف (persian_stop) را بر داده‌های خودتان بسنجید؛ ممکن است واژه‌ای مهم برای محصول حذف شود.

گام ۲: فیلدهای جدا برای نیازهای مختلف

توصیهٔ نویسنده: یک فیلد متنی برای همهٔ نیازها کافی نیست. ساختار پیشنهادی:

گام ۳: مترادف و واژگان مشتری

فهرست مترادف را از دادهٔ واقعی بسازید: پرس‌وجوهای بی‌نتیجه و پرتکرار، پرسش‌های پشتیبانی و نام‌هایی که مشتری برای محصول می‌گوید. فهرست را قدم‌به‌قدم افزایش دهید، نه یک‌باره. هر مترادف جدید را روی چند پرس‌وجوی نمونه امتحان کنید که نتیجهٔ نامرتبط نیاورد (مثلاً «موبایل» ممکن است قاب موبایل را هم بیاورد). (روش توصیهٔ نویسنده است.)

گام ۴: رتبه‌بندی نتایج

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

گام ۵: وقتی واقعاً نتیجه‌ای نیست

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

• پیام اول صفحه: «برای “عبارت” نتیجه‌ای پیدا نشد» با فونت خوانا.
• راه ادامه: پیشنهاد تصحیح املا، دسته‌های پرطرفدار، و راه تماس.
• تلاش خودکار با پرس‌وجوی سبک‌تر (مثلاً حذف یک واژه) و نمایش شفاف آنکه این کار انجام شده.
• ثبت پرس‌وجوی بی‌نتیجه برای بازبینی هفتگی؛ هر مورد پرتکرار یا مترادف جدید است، یا محصول ناموجودی که باید تهیه شود، یا باگ تحلیل.

طراحی بصری حالت خالی در Empty State، Error State و Loading State آمده است.

گام ۶: مجموعهٔ آزمون

یک جدول آزمون بسازید و هر بار تحلیل‌گر یا مترادف عوض می‌شود دوباره اجرا کنید:

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

اشتباهات رایج

• نرمال‌سازی فقط هنگام جست‌وجو و نه هنگام نمایه‌سازی (یا برعکس).
• stem‌کردن نام برند و مدل.
• مترادف‌های کلی که نتیجهٔ نامرتبط می‌آورند.
• نادیده گرفتن ارقام فارسی.
• صفحهٔ «بدون نتیجه» بدون راه ادامه.
• نمایه‌سازی مجدد بدون اجرای مجموعهٔ آزمون.

چک‌لیست

1. تحلیل‌گر فارسی (ZWNJ، ارقام، نرمال‌سازی) هنگام نمایه‌سازی و جست‌وجو یکسان است و با ‎_analyze راستی‌آزمایی شده است.
2. برند، مدل و SKU فیلد جدا و بدون stem دارند.
3. مترادف‌ها از داده‌ٔ واقعی ساخته می‌شوند و آزمون می‌شوند.
4. رتبه‌بندی با پرس‌وجوهای واقعی سنجیده شده است.
5. صفحهٔ بدون نتیجه سه رهنمود NN/G را رعایت می‌کند.
6. پرس‌وجوهای بی‌نتیجه ثبت و هفتگی بازبینی می‌شوند.
7. مجموعهٔ آزمون خودکار برای هر تغییر اجرا می‌شود.

برای تصمیم‌های معماری بزرگ‌تر، انتخاب معماری اپلیکیشن وب و برای دید کلی تجربهٔ کاربری UX چیست؟ را ببینید.

منابع و مراجع

• Language analyzers (Persian analyzer) — Elastic (Elasticsearch Reference).
• Decimal digit token filter — Elastic (Elasticsearch Reference).
• 3 Guidelines for Search Engine "No Results" Pages — Nielsen Norman Group (Kathryn Whitenton)، 2014-01-05.