Embedding چیست؟ از بردار متن تا جست‌وجوی قابل‌سنجش در اسناد فارسی

Embedding چه چیزی را نمایش می‌دهد؟

وقتی کارمند می‌پرسد «هزینه مأموریت چه‌طور پرداخت می‌شود؟»، ممکن است سند مربوط با عنوان «دستورالعمل تسویه سفر اداری» ذخیره شده باشد. تطبیق واژه‌ها به‌تنهایی همیشه این فاصله را پر نمی‌کند. Embedding نمایش عددی متن است که در یک مدل مشخص، مقایسهٔ شباهت میان پرسش و قطعه‌های سند را امکان‌پذیر می‌کند. نزدیک‌بودن بردارها نشانه‌ای برای انتخاب نامزدهای مرتبط است، نه تأیید درستی محتوای آن‌ها.

پژوهش Dense Passage Retrieval نمونه‌ای از استفادهٔ جداگانه از رمزگذار پرسش و متن برای بازیابی است. این مقاله دربارهٔ همان روش و مجموعه‌داده‌های آزمایشی آن است؛ نتایجش تضمین کیفیت روی فارسی، اسناد اسکن‌شده یا مقررات داخلی یک شرکت نیست. در ادامه، مثال سفر اداری یک سناریوی آموزشی پیشنهادی برای سنجش سامانه است.

بازیابی را از تولید پاسخ جدا ببینیم

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

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

پرسش و سند باید در فضای سازگار قرار بگیرند

مستندات Microsoft بر استفاده از مدل سازگار برای بردارسازی پرسش و اسناد تأکید می‌کند. یکسان‌بودن تعداد ابعاد به‌تنهایی سازگاری معنایی دو مدل را ثابت نمی‌کند. تغییر مدل بردارساز را تغییر یک پارامتر ساده تلقی نکنید؛ نسخهٔ مدل و روش پیش‌پردازش باید کنار نمایه ثبت شود.

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

برای متن فارسی چه مجموعهٔ آزمایشی بسازیم؟

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

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

کیفیت را با چه معیاری بسنجیم؟

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

مقالهٔ MTEB نشان می‌دهد ارزیابی Embedding به یک نوع وظیفه محدود نیست و برتری یک روش در همهٔ کاربردها را نباید مفروض گرفت. کاربرد عملی برای تیم ما این است که جدول رتبه‌بندی عمومی فقط فهرست اولیهٔ نامزدها باشد. هزینهٔ بردارسازی، زمان جست‌وجو و نتیجهٔ آزمون فارسیِ خود سازمان باید تصمیم نهایی را تعیین کنند.

برای ادامهٔ این بحث، مقالهٔ «جست‌وجوی معنایی با PostgreSQL و pgvector؛ از مدل تا ایندکس» را در دانشنامهٔ لیان بخوانید.

چه زمانی شباهت معنایی کافی نیست؟

اگر کاربر کد «سفر-۱۴۰۵-۰۷» یا شمارهٔ دقیق یک قرارداد را می‌خواهد، شباهت موضوعی جای تطبیق شناسه را نمی‌گیرد. در نمونهٔ پیشنهادی، یک سند قدیمی و یک سند جدید ممکن است متن بسیار مشابهی داشته باشند، درحالی‌که سقف مجاز پرداخت در آن‌ها متفاوت است. نسخه و تاریخ اعتبار را با فیلدهای صریح کنترل کنید.

پرسش‌های شناسه‌محور را در آزمون جدا کنید و نتیجهٔ جست‌وجوی واژگانی و ترکیبی را نیز بسنجید. پاسخ «مدرک کافی پیدا نشد» باید یک نتیجهٔ مجاز باشد. هدف این نیست که برای هر ورودی حتماً چند همسایهٔ برداری پیدا شود؛ هدف یافتن شواهد مناسب برای همان سؤال، در همان دامنهٔ دسترسی است.

بردارسازی به‌معنای ناشناس‌سازی نیست

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

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

خروجی یک ارزیابی قابل‌تصمیم چیست؟

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

پذیرش نهایی باید مشخص کند چه کسی مسئول تأیید محتواست و چه تغییری آزمون را دوباره لازم می‌کند. انتشار بخشنامهٔ تازه، تغییر OCR یا تعویض مدل بردارساز می‌تواند این محرک باشد. چنین روالی Embedding را از یک اصطلاح فنی جذاب به جزء قابل‌اندازه‌گیری مدیریت دانش تبدیل می‌کند؛ نتیجه با شاهد سنجیده می‌شود، نه فقط با نمایشی از پاسخ‌های خوب.