وقتی شباهت معنایی کافی نیست
کارشناس تعمیرات ممکن است شماره دقیق یک تجهیز را جستوجو کند، اما کاربر دیگر همان نیاز را با شرح نشانه خرابی بنویسد. جستوجوی واژگانی برای عبارت و شناسه دقیق مفید است؛ جستوجوی برداری شباهت معنایی پرسش و متن را بررسی میکند. جستوجوی ترکیبی از هر دو مسیر نامزد میگیرد.
مستندات Azure AI Search ترکیب نتایج متن و بردار را توضیح میدهد و در پیادهسازی خود از روش ادغام رتبهها استفاده میکند. امتیاز عددی دو موتور لزوماً هممقیاس نیست؛ جمع ساده آنها بدون ارزیابی میتواند ترتیب نتایج را منحرف کند.
برای ادامهٔ این بحث، مقالهٔ «جستوجوی معنایی با PostgreSQL و pgvector؛ از مدل تا ایندکس» را در دانشنامهٔ لیان بخوانید.
مثال اجرایی: دستورالعمل تعمیر یک پمپ
پیشنهاد تحریریه این است که سؤال «آببندی پمپ P-204 را چگونه تعویض کنیم؟» را همراه با صورت بدون کد تجهیز آزمایش کنید. مسیر واژگانی باید کد را نگه دارد و مسیر معنایی به عبارتهای مرتبط با تعویض آببند برسد. سپس نسخه معتبر دستورالعمل و مجوز کاربر بر نتایج اعمال شود.
برای متن فارسی، یکسانسازی ی و ک، نیمفاصله و شکل ارقام را روی نسخه جستوجو انجام دهید، اما متن مرجع و کد فنی اصلی را حفظ کنید. تغییر بیقاعده خط تیره یا فاصله داخل شناسه ممکن است تجهیز دیگری را وارد نتیجه کند.
ادغام نتیجه، حذف تکرار و کنترل دسترسی
قطعههای تکراری از یک صفحه نباید همه جایگاههای نتیجه را اشغال کنند. شناسه سند، نسخه و شماره قطعه را برای حذف تکرار نگه دارید. به اندازه کافی متن پیرامون جدول یا هشدار ایمنی را بازیابی کنید تا پاسخ بر جمله جداافتاده تکیه نکند.
مجوز باید پیش از رسیدن محتوای غیرمجاز به مدل کنترل شود. اگر کاربر به گزارش واحد دیگری دسترسی ندارد، حذف لینک در انتهای پاسخ کافی نیست؛ متن آن گزارش نیز نباید وارد زمینه پاسخ شده باشد.
کیفیت را با سؤال واقعی بسنجید
سه تنظیم واژگانی، برداری و ترکیبی را روی مجموعه یکسان مقایسه کنید. برای هر سؤال، سند مورد انتظار، نسخه صحیح و موارد ممنوع را مشخص کنید. وجود سند درست میان چند نتیجه اول، زمان بازیابی و نرخ پاسخ مستند را جدا ثبت کنید.
اگر روش ترکیبی بهتر نشد، ابتدا کیفیت قطعهبندی و تشخیص شناسه را بررسی کنید. افزایش تعداد نتایج میتواند هزینه و متن نامرتبط را بالا ببرد. بهترین تنظیم به نوع اسناد شما وابسته است و از نام فناوری بهتنهایی به دست نمیآید.
یک مسئله واقعی را به مجموعه پرسش تبدیل کنید
فرض کنید واحد نگهداری میخواهد دستور تعویض آببند پمپ P-204 را پیدا کند. سه ورودی بسازید: جستوجوی مستقیم همین کد، عبارت محاورهای «نشتی پمپ خط بستهبندی» و پرسشی که کد مشابه P-240 را دارد. پاسخ مرجع فقط نام فایل نباشد؛ نسخه معتبر، بخش مناسب و محدوده تجهیز را مشخص کند. این مجموعه نشان میدهد روش جستوجو هم عبارت دقیق را میفهمد و هم بیان طبیعی کاربر را پوشش میدهد.
پرسشهایی هم اضافه کنید که هیچ سند مناسبی ندارند. اگر سامانه همیشه نزدیکترین دستور را نمایش دهد، کاربر ممکن است راهنمای تجهیز دیگری را مرتبط بداند. روی نتیجه، عنوان، کد تجهیز، تاریخ اعتبار و نشانی بخش را نشان دهید تا انتخاب قابلبررسی شود. این طراحی پیشنهادی مربوط به تجربه جستوجو است؛ لازم نیست از ابتدا پاسخ متنی تولید کنید. ابتدا مطمئن شوید سند درست به دست کاربر میرسد، سپس ارزش پاسخسازی را بسنجید.
پاکسازی فارسی بدون خراب کردن شناسهها
یک نسخه اصلی از متن و یک نسخه مناسب جستوجو داشته باشید. در نسخه جستوجویی میتوانید تفاوت ی و ک، فاصلههای اضافی و شکل رقمها را طبق قاعده روشن یکدست کنید. اما حذف همه نشانهها ممکن است تفاوت کدهایی مانند AB-12 و AB12 را پنهان کند؛ برای شناسه فنی یک فیلد مستقل با قاعده تطبیق مشخص بهتر قابلکنترل است. متن اصلی باید برای استناد و نمایش باقی بماند.
واژهنامه مترادف را با کمک کارشناس همان حوزه بسازید. «آببند» و «سیل» ممکن است در مجموعه شما به یک قطعه اشاره کنند، اما یک واژه عمومی در همه تجهیزات معنی یکسان ندارد. تغییر واژهنامه را نسخهدار کنید و چند پرسش ثابت را قبل و بعد اجرا کنید. اگر بهبود پرسشهای عمومی باعث افت جستوجوی کدها شد، مسئله را با یک امتیاز میانگین پنهان نکنید؛ دو گروه پرسش را جدا گزارش کنید.
ترکیب نتیجهها را قابلردیابی تنظیم کنید
در اجرای آزمایشی، نتیجه مسیر واژگانی و معنایی را جدا ذخیره کنید و کنار نتیجه نهایی ببینید هر سند از کدام مسیر آمده است. ممکن است یک سند در هر دو مسیر خوب باشد یا فقط بهخاطر تطبیق دقیق کد ارزش داشته باشد. برای ترکیب، روشی مبتنی بر رتبه را بهعنوان نقطه شروع بررسی کنید و تعداد نامزدها را با آزمون تعیین کنید؛ عدد ثابت برای همه مجموعهها نسخه عمومی مناسبی نیست.
نسخههای تکراری یک سند نباید تمام جایگاههای اول را بگیرند. برای نمونه، چند قطعه از یک دستور جاری را به یک نتیجه قابلگسترش تبدیل کنید و نسخه منسوخ را طبق سیاست اعتبار کنار بگذارید. فیلتر دسترسی باید پیش از رسیدن اطلاعات به تولیدکننده پاسخ اعمال شود. خالی شدن نتیجه پس از فیلتر علامت مجاز بودن جستوجو در اسناد محرمانه نیست؛ سامانه باید محدودیت پاسخ را روشن نشان دهد.
چطور بفهمیم روش ترکیبی واقعاً بهتر شده است؟
برای هر پرسش ثبت کنید آیا سند مرجع میان چند نتیجه اول آمده و آیا نسخه معتبر بالاتر از نسخه قدیمی است. مثلاً شمارش موفقیت در پنج نتیجه اول یک معیار آزمایشی ساده است، به شرط آنکه همین عدد و تعریف در همه روشها ثابت بماند. زمان پاسخ و تعداد کلیک تا سند مفید را هم ثبت کنید؛ یافتن سند در رتبه مناسب باید به کار کارشناس کمک کند.
اگر جستوجوی کد ضعیف است، اول متن استخراجشده و فیلد شناسه را بررسی کنید. اگر پرسش محاورهای جواب ندارد، پوشش اصطلاحات و کیفیت قطعهبندی را ببینید. اگر سند درست اصلاً در مجموعه نیست، تنظیم وزنها درمان مسئله نیست. نتیجه پایلوت را با نمونه موفق و ناموفق تحویل دهید و برای هر شکست یک اقدام مشخص بنویسید؛ این گزارش از اعلام کلی «جستوجو هوشمندتر شد» کاربردیتر است.
پرسشهای متداول
آیا Hybrid Search همیشه بهتر است؟
خیر. باید روی پرسشها و اسناد واقعی با جستوجوی واژگانی و برداری مقایسه شود.
آیا این روش جای مدل زبانی را میگیرد؟
این روش مرحله بازیابی را بهبود میدهد؛ تولید پاسخ، استناد و کنترل دسترسی همچنان اجزای جدا هستند.
منابع
- MicrosoftHybrid search overviewOfficial documentation
- Sentence TransformersRetrieve & Re-RankOfficial documentation
مطالعهٔ بیشتر در دانشنامهٔ لیان
- لیان داتا پارسجستوجوی معنایی با PostgreSQL و pgvector؛ از مدل تا ایندکسبرای ادامهٔ فنی بازیابی، راهنمای pgvector لیان نمونهٔ SQL، انتخاب فاصله و ایندکس، و سنجش کیفیت جستوجو را ارائه میکند.