پایگاه داده برداری چیست و چه وقت لازم است؟
اگر دربارهٔ ساخت یک دستیار هوشمند صحبت کرده باشید، احتمالاً این اصطلاح را شنیدهاید و شاید با آن بهعنوان یک خرید جدید مواجه شدهاید. ارزش دارد بدانید دقیقاً چه کاری میکند، چون در بسیاری از پروژهها به سرویس جداگانهاش نیازی نیست.
مسئلهای که حل میکند
جستجوی معمولی روی کلمه کار میکند. کاربری که میپرسد «چند وقت ضمانت داره؟» به متنی که نوشته «مدت گارانتی محصول» نمیرسد، چون هیچ کلمه مشترکی ندارند.
راهحل این است که متن به عددی تبدیل شود که معنایش را رمزگذاری کند. این عدد در واقع یک فهرست بلند از اعداد است — یک بردار — و ویژگیاش این است که دو متن هممعنا، بردارهای نزدیکی دارند حتی اگر کلمه مشترکی نداشته باشند.
پایگاه داده برداری، جایی است که این بردارها ذخیره میشوند و میشود پرسید «نزدیکترینها به این بردار کداماند؟»
چطور در عمل کار میکند
اسناد شما به قطعههای کوچک شکسته میشوند. هر قطعه به یک بردار تبدیل میشود و ذخیره میگردد. هنگام پرسش، سؤال کاربر هم به بردار تبدیل میشود و چند قطعه نزدیکترین بیرون کشیده میشود. آن قطعهها همراه سؤال به مدل زبانی میروند.
این همان چیزی است که RAG نامیده میشود، و پایگاه داده برداری فقط یکی از اجزای آن است — نه مهمترینش.
تصمیمهایی که کیفیت را میسازند
بیشتر از انتخاب پایگاه داده، این دو تصمیم روی کیفیت اثر میگذارند:
اندازه قطعه. قطعه خیلی کوچک، متن را از زمینهاش جدا میکند و جوابی میدهد که نصفه است. قطعه خیلی بزرگ، چند موضوع را قاطی میکند و بازیابی را کمدقت میکند. شکستن بر اساس ساختار سند — بند، بخش، ماده — تقریباً همیشه بهتر از شکستن بر اساس تعداد کاراکتر جواب میدهد.
مدل تبدیل متن به بردار. برای فارسی، مدلی که چندزبانه آموزش دیده یا روی فارسی تنظیم شده، تفاوت محسوسی میسازد. این انتخاب مهمتر از انتخاب پایگاه داده است.
و پیش از هر دوی اینها، نرمالسازی متن فارسی: نیمفاصله، «ی» و «ک» عربی، اعداد. بدون آن، دو متن هممعنا از نظر ماشین دور میافتند و هیچ پایگاه دادهای جبرانش نمیکند. تفصیلش در چالشهای پردازش زبان فارسی هست.
شاید به سرویس جدا نیاز نداشته باشید
این بخشی است که در جلسات فروش کمتر گفته میشود.
اگر تعداد قطعههای شما در حد چند ده هزار است — که برای مجموعه آییننامهها و مستندات یک سازمان متوسط کاملاً محتمل است — پایگاه دادهای که همین حالا دارید احتمالاً کافی است. PostgreSQL افزونهای برای جستجوی برداری دارد، و Elasticsearch هم اگر برای جستجوی محصول از قبل دارید، این کار را انجام میدهد.
مزیت این مسیر کم اهمیت نیست: یک سرویس کمتر برای نگهداشتن، پشتیبانگیری در همان جریان موجود، و مهمتر — امکان جستجوی ترکیبی.
جستجوی ترکیبی، که معمولاً بهتر از هر دو است
جستجوی برداری در معنا خوب است و در تطابق دقیق ضعیف. کاربری که شماره فرم یا کد قطعه را مینویسد، با جستجوی معنایی نتیجه دقیق نمیگیرد.
راهحل، ترکیب هر دو است: جستجوی کلیدواژهای برای تطابق دقیق، جستجوی برداری برای معنا، و ترکیب نتایج. در عمل، این ترکیب تقریباً همیشه از هرکدام بهتنهایی بهتر جواب میدهد.
و همین یکی از دلایلی است که نگهداشتن هر دو در یک سامانه ارزش دارد.
چه وقت سرویس اختصاصی توجیه دارد
نشانههایی که وقتش رسیده: تعداد قطعهها از چند میلیون گذشته، تأخیر جستجو محسوس شده، یا به قابلیتهایی نیاز دارید که پایگاه داده عمومی ندارد — مثل فیلترکردن پیچیده همراه با جستجوی برداری در مقیاس بالا.
اگر در این وضعیت نیستید، افزودن یک سرویس جدید، پیچیدگی عملیاتی میخرید بدون اینکه مزیتش را بگیرید.
آنچه باید در معماری پیشبینی شود
نگهداشتن نمایه بهروز. وقتی سندی عوض شود، بردارهایش باید دوباره ساخته شوند. اگر این جریان از ابتدا نباشد، سامانه چند ماه بعد از اسناد منسوخ جواب میدهد.
سطح دسترسی در بازیابی. جستجو باید از ابتدا فقط در اسنادی انجام شود که این کاربر حق دیدنشان را دارد، نه اینکه همه را بخواند و بعد پاسخ را فیلتر کند.
امکان تعویض مدل بردارسازی. مدلها بهتر میشوند و روزی میخواهید عوض کنید. آن روز همه بردارها باید از نو ساخته شوند، پس متن اصلی قطعهها باید نگه داشته شود، نه فقط بردارشان.
آن نکته آخر ساده است و نادیدهگرفتنش گران تمام میشود: بردار بدون متن اصلی، قابل بازسازی نیست.