عامل‌های هوش مصنوعی در برابر موتورهای جست‌وجوی سنتی در پردازش الگوها

تصور کنید مدل‌های هوش مصنوعی به‌جای حل مسائل، صرفاً پاسخ‌های آزمون را حفظ کرده باشند. برای مقابله با این وضعیت فریبنده در ارزیابی‌ها، Keenable در ۲۷ اوت ۲۰۲۶ محک NEEDLE (ارزیابی اخبار، روزمره، تخصصی، دم‌دراز و حقوقی) را منتشر کرد. این ابزار یک نقص حیاتی در سامانه‌های فعلی را هدف قرار داده است: محک‌های ایستا (Static Benchmarks) که به مدل‌ها اجازه می‌دهند دچار بیش‌برازش (Overfitting) شوند یا حتی کلید پاسخ‌ها را در حین ارزیابی از HuggingFace دانلود کنند.

بسیاری از محک‌های موجود در زمان خاصی منجمد شده‌اند و همین موضوع آن‌ها را به هدفی آسان برای آلودگی داده‌ها تبدیل کرده است. طبق گزارش‌های فنی، این محک‌ها شامل مجموعه‌ای ثابت از پرسش‌ها هستند که تغییر نمی‌کنند و باعث می‌شوند سامانه‌ها به‌طور مستقیم یا غیرمستقیم روی داده‌های آزمون بیش‌برازش شوند. برای نمونه، مدل Qwen3-Max-Instruct در صدر جدول SimpleQA Verified قرار گرفت، اما Epoch AI نتایج آن را احتمالاً آلوده دانست. شواهد دیگر در آزمون MMLU دیده می‌شود؛ جایی که صرفاً با جابه‌جایی گزینه‌ها، صحت پاسخ‌دهی تمام مدل‌های آزمایش‌شده کاهش یافت.

در موارد شدیدتر، عامل‌های جست‌وجو در حین آزمون از ابزارهای وب برای یافتن برچسب‌های مرجع (Ground-truth) استفاده کرده‌اند. از آنجا که ارزیابی‌های عامل‌محور اجازه استفاده از ابزارهای جست‌وجو و واکشی را می‌دهند، مدل‌ها می‌توانند مستقیماً به مجموعه‌داده‌های HuggingFace دسترسی پیدا کنند. ابزارهای واکشی می‌توانند فایل‌های داده را دانلود و بخوانند؛ به این معنا که مدل در حین تست، کلید پاسخ را پیدا می‌کند. اجازه اجرای دستورات سفارشی پایتون یا Bash این کار را ساده‌تر می‌کند: یک دستور wget و یک grep کافی است تا «وظیفه جست‌وجو» برای حدود ۳٪ از پرسش‌های HLE به پایان برسد.

حتی بدون تقلب فعال در زمان تست، حفظ داده‌ها اندازه‌گیری‌ها را مخدوش می‌کند. گاهی مدل‌ها پاسخ‌ها را از داده‌های آموزش خود می‌دانند. در محک‌هایی مانند BrowseComp، پرسش‌ها به‌گونه‌ای طراحی شده‌اند که یافتن پاسخ سخت اما تأیید آن آسان باشد. با این حال، مدلی که پاسخ را حفظ کرده است، مرحله «سخت بودن یافتن» را به‌طور کامل حذف می‌کند. چنین مدلی دقیقاً می‌داند به دنبال چه باشد و مستقیماً پاسخ نهایی را می‌جوید و مسیر خود را به سمت یک پاسخ مبهم اما به‌یاد‌آورده‌شده تغییر می‌دهد.

برای مقابله با این مشکل، NEEDLE به‌عنوان یک محک زنده (Live Benchmark) عمل می‌کند. اگر پرسش‌ها جدیدتر از مدل باشند و مدام تغییر کنند، چیزی برای حفظ کردن یا نشت دادن وجود ندارد. این رویکرد مشابه سایر حوزه‌ها است: LiveBench پرسش‌ها را ماهانه به‌روز می‌کند، LiveCodeBench مدل‌ها را فقط روی مسائلی که بعد از تاریخ قطع آموزش آن‌ها منتشر شده است می‌سنجد و SWE-bench-Live وظایف را از روی ایشوهای تازه گیت‌هاب بازسازی می‌کند. NEEDLE برای نخستین بار همین سخت‌گیری را در جست‌وجوی وب به کار می‌گیرد. این تلاش برای دقت بیشتر در ارزیابی، در راستای رویکردهایی است که پلتفرم Optima برای پر کردن شکاف‌های عملکردی مدل‌ها با محک‌های اختصاصی به کار گرفته است.

پنج ستون اصلی NEEDLE

این محک عملکرد را در پنج نوع پرس‌وجوی متمایز می‌سنجد که بازتاب‌دهنده نیت‌های واقعی جست‌وجوی عامل‌محور است و از منابع عمومی و جریان‌های داده تازه تغذیه می‌کند:

• اخبار (News): داستان‌های فوری و در حال توسعه که مردم همین حالا درباره آن‌ها می‌پرسند. این داده‌ها هر ساعت از فیدهای RSS منتخب و Google Trends تولید می‌شوند.
• مالی (Finance): جست‌وجوی روزمره شرکت‌ها و پرونده‌های SEC. پاسخ‌های مرجع از Wikidata، GLEIF و SEC XBRL استخراج می‌شوند.
• علمی (Scholar): جست‌وجوی متون تخصصی. وظیفه این است که یک مقاله خاص را با استفاده از عنوانی ناقص، جزئیاتی از متن یا توصیفی مبهم (مانند توصیفات «نوک زبان») پیدا کند. این بخش با الهام از ارزیابی‌های جست‌وجوی انتشارات Exa طراحی شده است.
• عامل‌های نادر (AgenticRare): موجودیت‌های مبهم و دم‌دراز (Long-tail). این پرس‌وجوهای کلمات نادر مستقیماً از لاگ‌های جست‌وجوی عامل‌محور در DeepResearchGym، LRAT و OpenResearcher نمونه‌برداری می‌شوند.
• حقوقی (Legal): یافتن یک نظریه دادگاه خاص یا بخشی مشخص از قوانین فدرال (Code of Federal Regulations).

هر وظیفه در این محک به‌صورت روزانه یا ساعتی روی برش‌های جدیدی از پرس‌وجوها با استفاده از APIهای مالی و علمی، فیدهای RSS و Google Trends بازاجرا می‌شود. همچنین یک جریان اختصاصی برای پرس‌وجوهای کلمات نادر وجود دارد که مستقیماً از لاگ‌های عمومی عامل‌ها استخراج می‌شود.

جزئیات پیاده‌سازی NEEDLE

• منابع داده: این محک از ترکیبی از جریان‌های بلادرنگ (RSS، Google Trends) و پایگاه‌های داده ساختاریافته (Wikidata، GLEIF، SEC XBRL) استفاده می‌کند.
• چرخه ارزیابی: وظایف ایستا نیستند؛ آن‌ها در چرخه‌های ساعتی یا روزانه به‌روز می‌شوند تا هرگونه احتمال حفظ داده‌ها توسط مدل به طور کامل حذف شود.
• تولید پرس‌وجو: پرس‌وجوهای کلمات نادر مصنوعی نیستند، بلکه از لاگ‌های واقعی جست‌وجوی عامل‌ها (DeepResearchGym، LRAT، OpenResearcher) نمونه‌برداری شده‌اند.
• شفافیت: تمام کدها، روش‌های جمع‌آوری پرس‌وجو و رویه‌های داوری در مخزن گیت‌هاب پروژه در دسترس است.

سنجش غول‌ها

Keenable از این چارچوب برای مقایسه موتور خود با Google (از طریق Serper)، Bing (از طریق SearchAPI)، Brave و استارتاپ‌های بومی هوش مصنوعی مانند Tavily، Parallel و Exa استفاده کرد. این رقابت در فضای ابزارهای جست‌وجوی تخصصی رخ می‌دهد، جایی که سرویس‌های پیشرویی مانند Parallel و Exa در ارزیابی‌های کیفیت و کارایی جایگاه خود را تثبیت کرده‌اند. برای تعیین سقف عملکرد، آن‌ها یک موتور مصنوعی «حد بالا» (Upper Bound) ساختند. این یک موتور واقعی نیست، بلکه سیستمی است که بهترین نتایج یافت‌شده توسط هر یک از موتورهای شرکت‌کننده را ذخیره کرده و توسط همان داوری رتبه‌بندی می‌کند که بقیه را می‌سنجد. این کار نشان می‌دهد که یک بازرتبه‌بندی (Reranker) ایده‌آل روی تمام موتورها چه نمره‌ای می‌گیرد.

یافته‌ها شکاف عمیقی را در پیچیدگی پرس‌وجوها نشان می‌دهد:

• وظایف حل‌شده: پرس‌وجوهایی که شامل عنوان مقاله یا واقعیت‌های شرکتی هستند، تقریباً توسط همه موتورها حل شدند.
• متادیتا در برابر بدنه: پرس‌وجوهای کلیدواژه‌ای مبتنی بر جزئیات متن، موتورهایی را که بدنه اسناد را ایندکس می‌کنند از موتورهایی که فقط متادیتا را می‌بینند، جدا کرد.
• شکست لغوی: در توصیفات زبان طبیعی و نیمه‌به‌یاد‌آورده‌شده، موتورهای لغوی (Lexical Engines) تقریباً به‌طور کامل از کار افتادند.
• شکاف موجودیت‌های نادر: سخت‌ترین مجموعه، پرس‌وجوهای AgenticRare است. حتی بهترین موتورها بخش زیادی از آنچه کل میدان می‌یابد را از دست می‌دهند. این دسته به ترافیک واقعی عامل‌ها نزدیک‌ترین است؛ هرچه پرس‌وجوها به نحوه واقعی جست‌وجوی عامل‌ها نزدیک‌تر می‌شود، شکاف بین کیفیت ارائه شده و کیفیت قابل دستیابی بیشتر می‌شود.

مسئله مالکیت ایندکس

بر اساس گزارش keenable.ai، توانایی بهبود کیفیت جست‌وجو کاملاً به مالکیت ایندکس زیربنایی وابسته است. فدراسیون (تجمیع) موتورهای دیگر سقفی دارد، زیرا شما نمی‌توانید بازیابی (Retrieval) چیزی را که مالک آن نیستید، اصلاح کنید. اگر ایندکس شخص دیگری را قرض بگیرید، فقط می‌توانید نتایج بازگشتی را بازرتبه‌بندی کنید یا تکه‌های متن (Snippets) را تغییر دهید؛ اما نمی‌توانید بازیابی هسته را به‌طور معناداری بهبود ببخشید.

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

این موضوع یادآور حسابرسی سال ۲۰۱۱ است که در آن Google نتایج تله‌ای (Honeypot) را برای ۱۰۰ پرس‌وجوی مصنوعی کاشت تا Bing را ردیابی کند. نشانه تقلب، اشتباه مشترک بود: برای غلط املایی "torsorophy"، بینگ نتیجه گوگل برای کلمه درست را ارائه می‌داد بدون اینکه غلط املایی را به کاربر گوشزد کند. دفاع مایکروسافت این بود که هم‌گرایی طبیعی است، اما گوگل استدلال کرد که هم‌گرایی روی نتایج درست طبیعی است، اما هم‌گرایی روی خطاها خیر.

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

مالکیت ایندکس همچنین اجازه بهینه‌سازی تهاجمی تأخیر (Latency) را می‌دهد. عامل‌ها در حلقه‌های تکرار عمل می‌کنند و اغلب ده‌ها فراخوانی متوالی دارند، به این معنی که میلی‌ثانیه‌ها روی هم جمع شده و به ثانیه‌ها تبدیل می‌شوند. Keenable در حال حاضر تأخیر p50 معادل ۲۰۰ میلی‌ثانیه را گزارش کرده است و هدفش رسیدن به ۲۰۰ میلی‌ثانیه برای p95 است.

چرا موتورهای جست‌وجوی انسانی برای عامل‌ها شکست می‌خورند؟

موتورهای جست‌وجوی سنتی برای روان‌شناسی انسان — به‌ویژه تنبلی انسان — بهینه شده‌اند. برای مثال، Google ویدیوها را اولویت می‌دهد چون زمان توقف (Dwell Time) و کلیک بیشتری ایجاد می‌کنند. برای انسان، ویدیو یک خلاصه راحت است؛ اما برای یک عامل هوش مصنوعی، ویدیو یک توده کدر با یک عنوان و شاید یک متن پیوست است.

جست‌وجوی یک گزارش پارگی مینیسک (torn meniscus) را در نظر بگیرید. یک عامل به دنبال واقعیت‌های خاص است: تشخیص و جدول زمانی بهبودی. گوگل ممکن است چهار صفحه ویدیو از mlb.com و یک لینک یوتیوب را در هفت نتیجه اول بیاورد، در حالی که گزارش متنی واقعی در سمت راست صفحه غایب باشد. این نتیجه دو دهه بهینه‌سازی برای جلب توجه انسان است که به گوگل آموخته ویدیو یک پاسخ «خوب» است.

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

عامل‌ها در دسته‌های سریع جست‌وجو می‌کنند و اغلب چندین فراخوانی ابزار را به‌طور موازی در فاصله چند ثانیه انجام می‌دهند. مطالعه‌ای روی ۱۴ میلیون درخواست عامل‌محور (SIGIR'26) نشان داد که عامل‌ها از یک حلقه پیروی می‌کنند: جست‌وجو، بررسی، اصلاح و جست‌وجوی مجدد. در یک بازه ۲۴ ثانیه‌ای، یک عامل ممکن است نام شرکت و ارزش معامله را از یک نتیجه بگیرد، وب‌سایت هر دو شرکت را چک کند و سپس بازه زمانی انتشار را محدودتر کند. هر پرس‌وجو از اطلاعاتی استفاده می‌کند که توسط پرس‌وجوی قبلی یافت شده است.

آن‌ها از عملگرهای پیشرفته‌ای استفاده می‌کنند که انسان‌ها تا حد زیادی رهایشان کرده‌اند، مانند:

• فیلترهای site:
• نقل‌قول‌های عبارت دقیق (Exact phrase quotes)
• بازه زمانی محدود (Narrowed date ranges)
• حذف کلمات خاص (Term exclusion)
• گروه‌بندی جایگزین‌ها با OR

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

چرخش در زیرساخت

این تغییر نشان می‌دهد که لایه جست‌وجو به یک ماشین یادگیرنده تبدیل خواهد شد. Keenable دقیقاً با همین هدف ساخته شد: آن‌ها اولین ایندکس خود را شش ماه پیش راه‌اندازی کردند، پوشش اخبار را چهار ماه پیش، سینتکس پرس‌وجو را سه ماه پیش و تکه‌های متن (Snippets) مناسب را دو ماه پیش عرضه کردند. اکنون آن‌ها در نمودارهایی قرار دارند که موتورهای رقیب ۳۰ سال پیش‌قدم بودند.

چون عامل‌ها می‌توانند تمام منابع معتبر را بدون خستگی بخوانند، «هزینه» تحقیق درست به‌شدت کاهش یافته است. تحقیق درست برای انسان‌ها گران است اما برای عامل‌ها ارزان است.

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

برای مشاهده عملکرد عامل‌های خود در برابر این استانداردها، می‌توانید کدها و رویه‌های داوری NEEDLE را در مخزن گیت‌هاب آن‌ها در آدرس https://keenableai.github.io/needle/ بررسی کنید.