جست‌وجوی کلیدواژه‌ای در داده‌های علمی ۷۶ برابر سریع‌تر از برداری است

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

یک «رویای معنایی» درباره‌ی امبدینگ‌ها (Embeddings) وجود دارد که با روندهای اخیر، مانند مدیریت بافت مبتنی بر فایل در Claude CoWork، تقویت شده است. در حالی که صنعت به دنبال تحقق این چشم‌انداز بوده، بنچ‌مارکی که در ۱۴ ژانویه ۲۰۲۶ انجام شد، واقعیت مهندسی متفاوتی را آشکار کرد: جست‌وجوی کلیدواژه‌ای در اکتشافات علمی و کارهای نیازمند دقت بالا، عملاً بر بازیابی برداری غلبه می‌کند. این یافته ثابت می‌کند که تطبیق دقیق (Exact Match) برای انواع خاصی از داده‌ها، نه تنها قابل‌اعتمادتر است، بلکه به‌طور قابل‌توجهی سریع‌تر عمل می‌کند.

این چرخش دیدگاه در حالی رخ می‌دهد که توسعه‌دهندگان هوش مصنوعی با چالش‌های توازن (Trade-offs) در تولید بازیابی-افزا (RAG) دست‌وپنجه نرم می‌کنند. RAG شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد. در واقع، استفاده از خط‌لوله‌های RAG برای اتصال مدل‌ها به دانش خارجی یکی از موثرترین روش‌ها برای کاهش توهمات LLM است. بسیاری از سامانه‌های فعلی برای پر کردن شکاف میان نحوه پرسش انسان‌ها و نحوه ذخیره‌سازی داده‌ها، به‌شدت به پایگاه‌داده‌های برداری (Vector Databases) تکیه می‌کنند. اما فرض کلی مبنی بر اینکه جست‌وجوی «معنا-محور» همیشه بهتر است، توسط داده‌های خام عملکردی به چالش کشیده شده است. پژوهشگر این مورد را هنگام اجرای تست‌ها روی یک مک‌بوک پرو مشاهده کرد که چنان داغ شده بود که «شبیه یک نیروگاه هسته‌ای» عمل می‌کرد؛ این موضوع نشان‌دهنده‌ی گسست میان تئوری‌های معنایی و واقعیت‌های سخت‌افزاری است.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی حافظه مدل‌های زبانی اشاره کردیم، توازن میان دقت و هزینه کلید موفقیت در مقیاس واقعی است. برای تست این فرضیه، آزمایشی طراحی شد که در آن ۵۰ هزار سند در پنج حوزه متمایز — از کدهای پایتون گرفته تا مقالات علمی — وارد سیستم شدند. سپس ۵ هزار پرسش با استفاده از Tantivy (نسخه ۰.۲۲.۰) برای جست‌وجوی کلیدواژه‌ای و ChromaDB (نسخه ۰.۴.۰ به بالا) برای جست‌وجوی برداری اجرا شد. معیار سنجش، MRR@10 بود که رتبه سند درست را در ۱۰ نتیجه اول می‌سنجد؛ به این صورت که امتیاز ۱.۰ نشان می‌دهد سند صحیح در هر بار اجرا، در رتبه اول قرار گرفته است.

تحلیل سازوکارها

این دو سیستم بر اساس منطق‌های بنیادین متفاوتی عمل می‌کنند. جست‌وجوی کلیدواژه‌ای یک «نمایه معکوس» (Inverted Index) می‌سازد تا کلمات را دقیقاً تطبیق دهد. این سیستم هیچ مدل معنایی ندارد. برای مثال، اگر کاربر عبارت «مرتب کردن لیست» (sort a list) را جست‌وجو کند اما در سند از اصطلاح فنی «bubble_sort» استفاده شده باشد، جست‌وجوی کلیدواژه‌ای چیزی پیدا نمی‌کند، زیرا رشته‌های متنی با هم متفاوت هستند. اما در مقابل، این روش دقت مطلقی ارائه می‌دهد: وقتی یک عبارت دقیقاً تطبیق یابد، هیچ نتیجه‌ی دیگری نمی‌تواند رتبه‌ای بالاتر از آن داشته باشد.

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

شکاف عملکردی بر اساس دامنه

یافته‌ها نشان می‌دهند که انتخاب روش بازیابی کاملاً به ماهیت داده‌ها بستگی دارد:

CodeXGLUE (زبان طبیعی به کد): جست‌وجوی برداری با امتیاز ۰.۹۱۴۳ در برابر ۰.۲۹۰۱ کلیدواژه‌ای پیروز مطلق بود (با حاشیه‌ی ۶۲.۴۲+). این خالص‌ترین تسک «شکاف معنایی» است، زیرا توصیفات زبان طبیعی از کد، تقریباً هیچ واژگان مشترکی با خودِ کد پیاده‌ساز ندارند.
SciQ (آزمون‌های علمی): جست‌وجوی کلیدواژه‌ای به‌طور قاطع برنده شد (۰.۸۱۴۵ در برابر ۰.۶۱۴۲). در علوم، موجودات خاص به عنوان «کلید» عمل می‌کنند و نه «تقریب»؛ «میتوکندری» یک کلید خاص است و نه صرفاً چیزی که «شبیه به سلول» باشد.
HotpotQA (استدلال چندمرحله‌ای): جست‌وجوی کلیدواژه‌ای برتری اندکی داشت (۰.۵۴۹۴ در برابر ۰.۴۹۵۳). این مجموعه داده نیازمند پیوند دادن چندین سند است؛ تسکی که هر دو سیستم در آن مشکل دارند زیرا اسناد را به‌طور مستقل رتبه‌بندی می‌کنند.
MS MARCO (پرس‌وجوهای واقعی بینگ): جست‌وجوی برداری پیشتاز شد (۰.۵۲۲۵ در برابر ۰.۴۰۳۵).
SQuAD (پرسش‌وپاسخ ویکی‌پدیا): نتیجه یک تساوی آماری بود (۰.۶۱۳۶ در برابر ۰.۶۰۴۸). با اختلاف ناچیز ۰.۰۰۸۸ در یک اجرای واحد بدون میانگین‌گیری بذر، نویسنده اشاره می‌کند که گزارش این مورد به عنوان پیروزی بردارها، غیرصادقانه خواهد بود.

با بررسی میانگین در هر پنج حوزه، جست‌وجوی برداری حدود ۱۰ امتیاز جلو است (۰.۶۳۲۰ در برابر ۰.۵۳۲۵). اما نکته حیاتی اینجاست: اگر CodeXGLUE را حذف کنیم، رتبه‌بندی کاملاً وارونه می‌شود و جست‌وجوی کلیدواژه‌ای با ۳ امتیاز پیشتاز می‌گیرد (۰.۵۹۳۱ در برابر ۰.۵۶۱۴). این ثابت می‌کند که جست‌وجوی برداری به‌طور کلی بهتر نیست؛ بلکه صرفاً در یک جایگاه خاص (CodeXGLUE) ۳.۱۵ برابر بهتر عمل کرده و میانگین کل را بالا برده است.

مقایسه فایل و بردار در سیستم RAG

مالیات برداری و هزینه محاسباتی

علاوه بر دقت، هزینه محاسباتی جست‌وجوی برداری — که نویسنده آن را «مالیات برداری» (Vector Tax) می‌نامد — بسیار شدید است. تولید امبدینگ ۷۶.۴ برابر کندتر از نمایه‌سازی کلیدواژه‌ای است. این بنچ‌مارک روی تراشه Apple M4 با ۱۶ گیگابایت رم اجرا شد:

پردازش کلی: نمایه‌سازی کلیدواژه‌ای برای ۵۰ هزار سند تنها ۲.۱۱ ثانیه زمان برد، در حالی که تولید بردارها ۱۶۱.۶ ثانیه به طول انجامید.
توان عملیاتی (Throughput): روش کلیدواژه‌ای ۲۳,۶۵۰ سند در ثانیه را پردازش کرد، اما روش برداری تنها ۳۰۹ سند را مدیریت توانست.
تفکیک داده‌ها بر اساس سرعت:
- CodeXGLUE: کلیدواژه‌ای ۴۴۵.۷۵ میلی‌ثانیه در برابر برداری ۴۳,۰۹۸.۹۳ میلی‌ثانیه (۹۶.۷ برابر)
- SQuAD: کلیدواژه‌ای ۴۱۰.۶۰ میلی‌ثانیه در برابر برداری ۳۵,۹۲۰.۰۱ میلی‌ثانیه (۸۷.۵ برابر)
- HotpotQA: کلیدواژه‌ای ۳۹۴.۹۸ میلی‌ثانیه در برابر برداری ۲۹,۵۳۸.۱۴ میلی‌ثانیه (۷۴.۸ برابر)
- MS MARCO: کلیدواژه‌ای ۴۱۸.۵۶ میلی‌ثانیه در برابر برداری ۲۶,۳۳۵.۶۱ میلی‌ثانیه (۶۲.۹ برابر)
- SciQ: کلیدواژه‌ای ۴۴۴.۳۰ میلی‌ثانیه در برابر برداری ۲۶,۶۷۰.۰۱ میلی‌ثانیه (۶۰.۰ برابر)

برای یک عامل (Agent) که باید در همان نوبتِ پاسخ، یک مخزن کد جدید یا سندی صدصفحه‌ای را بخواند و بر اساس آن عمل کند، نمایه‌سازی تطبیق-دقیق عملاً آنی است، در حالی که تولید امبدینگ شبیه به یک «وقفه برای نوشیدن قهوه» است.

شکست‌های ساختاری و نیاز به گراف‌ها

این بنچ‌مارک یک نقص بحرانی در مواجهه با داده‌های متصل در HotpotQA را فاش کرد. برای پرسش‌هایی که نیاز به پیوند دادن دو سند دارند — برای مثال تشخیص اینکه از میان دو مجله، کدام‌یک زودتر تأسیس شده است — جست‌وجوی برداری به‌طور قابل‌اعتمادی موجودیت اول را بازیابی می‌کند، اما «سند پل» (Bridge Document) برای رسیدن به موجودیت دوم را گم می‌کند.

چون سند پل به‌طور تعریف، سندی است که شبیه به پرسش کاربر نیست، بنابراین نه شباهت معنایی و نه تطابق دقیق قادر به یافتن آن نیستند. این مشکلی نیست که یک بازرتبه‌بندی (Reranker) بتواند آن را حل کند. پاسخ به این نیاز به ذخیره خودِ «رابطه» دارد، و به همین دلیل است که ساختارهای گراف در سیستم‌های حافظه طراحی شده‌اند. بدون گراف‌ها، یک عامل ممکن است پاسخی ناقص بازیابی کند و به‌جای اعلام خطا، خروجی‌هایی با اعتمادبه‌نفس اما بدون پشتوانه (Unsupported) تولید کند. در واقع، بسیاری از شکست‌های RAG ریشه در همین خطاهای بازیابی دارند و نه در ضعف درک زبانی مدل.

محدودیت‌های متدولوژی

نویسنده برای شفافیت، شش محدودیت را ذکر کرده است. ارزیابی‌ها به‌صورت برنامه‌نویسی شده از طریق تطبیق دقیق ID سند در فایل src/evaluation/metrics.py انجام شده و برای جلوگیری از سوگیری در قضاوت، از هیچ مدل زبانی (LLM) یا فایل پرامپتی به عنوان داور استفاده نشده است.

۱. میانگین‌گیری بذر (Seed Averaging): این آزمایش تنها یک بار اجرا شد؛ بنابراین حاشیه کم در SQuAD باید به عنوان تساوی تلقی شود.
۲. انتخاب مدل: استفاده از مدل all-MiniLM-L6-v2 (با ۳۸۴ بعد) یک پیش‌فرض رایج است و لزوماً بهترین مدل بردارساز موجود نیست؛ مدل‌های قوی‌تر ممکن است امتیازات برداری را بهبود بخشند.
۳. تنظیمات: از تحلیلگر پیش‌فرض Tantivy بدون هیچ‌گونه تنظیمات خاص یا شخصی‌سازی استفاده شد.
۴. تکه‌بندی (Chunking): هیچ تکه‌بندی صورت نگرفت، موضوعی که معمولاً در اسناد بلندتر، باعث جریمه شدن بازیابی برداری می‌شود.
۵. سخت‌افزار: سرعت‌های نمایه‌سازی محلی و مختص تراشه M4 هستند؛ استفاده از APIهای میزبانی شده، اعداد را بر اساس رفت‌وبرگشت‌های شبکه و استنتاج‌های دسته‌ای (Batch Inference) تغییر می‌دهد.
۶. دامنه معیار: MRR@10 تنها رتبه بازیابی را می‌سنجد، نه اینکه آیا عامل در نهایت توانسته پاسخ صحیح را تولید کند یا خیر.

این داده‌ها تایید می‌کنند که برای حوزه‌هایی با دقت بالا مثل علوم یا محیط‌های پرسرعت که عامل‌ها باید در لحظه یاد بگیرند، جست‌وجوی کلیدواژه‌ای «بدوی» در واقع انتخاب مهندسی برتر است. هرچند این بحث برای مجموعه‌های داده ثابت (Fixed Corpora) فیصله یافت، اما حافظه عامل‌ها — جایی که تاریخچه گفتگو پویاً رشد می‌کند و حقایق ممکن است با یکدیگر تضاد داشته باشند — هنوز نیازمند بررسی است. تحلیل‌ها نشان می‌دهند که چرا جست‌وجوی برداری خالص در محیط‌های صنعتی شکست می‌خورد و ترکیب آن با روش‌های سنتی، راهکاری بهینه‌تر است. این اکتشافات، به همراه مباحث اقتصاد توکن‌ها و استخراج گراف، در مقاله نویسنده با عنوان «مدیریت بافت عامل‌محور» (Agentic Context Management) با جزئیات شرح داده شده است.

گام بعدی شما

اگر با داده‌های علمی یا فنی سروکار دارید، از جست‌وجوی ترکیبی (Hybrid Search) به‌جای تکیه مطلق بر Vector DB استفاده کنید.
در طراحی RAG، برای اسنادی که نیاز به پیوند میان مفاهیم دارند، لایه گراف دانش را جایگزین یا مکمل بردارها کنید.
برای محیط‌های Edge با محدودیت پردازشی، نمایه‌سازی کلیدواژه‌ای را برای کاهش تأخیر (Latency) اولویت دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.

این گزارش با خط‌لولهٔ خودکار دات‌هوش از منابع معتبر جهانی تدوین و زیر نظر تحریریه منتشر شده است. روش کار ما