تصور کنید وب‌سایتی را که هزاران صفحه محتوا دارد، اما برای جست‌وجوی هوشمند آن‌ها حتی یک درخواست به سرور نمی‌فرستد. تیم artwaste.land در ۱۴ اوت ۲۰۲۶ جزئیات سیستمی را افشا کرد که در آن جست‌وجوی معنایی به‌جای تکیه بر زیرساخت‌های ابری، تنها با سه فایل JSON و ۴۰۱ خط کد جاوااسکریپت در مرورگر کاربر رخ می‌دهد.
این سیستم از هیچ کتابخانه خارجی، DOM یا Buffer استفاده نمی‌کند و تمام عملیات را با توابع پایه ریاضی و آرایه‌های تایپ‌شده انجام می‌دهد. در واقع، کل موتور جست‌وجو در سه فایل کوچک خلاصه شده است.
بیشتر سیستم‌های جست‌وجوی معنایی (Semantic Search) — که شبیه به کتابخانه‌داری است که به‌جای گشتن دنبال کلمات دقیق، مفهوم سوال شما را می‌فهمد — مسیری هزینه‌بر دارند: تبدیل متن به بردار از طریق API، ذخیره در پایگاه‌داده برداری (Vector Database) و پردازش هر پرس‌وجو در زمان اجرا. اما برای artwaste.land، قانون سخت‌گیرانه عدم ارسال داده‌های کاربر به شخص ثالث، این مسیر را مسدود کرده بود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی حریم خصوصی در مدل‌های لبه اشاره کردیم، محدودیت‌های زیرساختی گاهی منجر به نوآوری‌های مهندسی می‌شوند. این سایت که روی دارایی‌های استاتیک Cloudflare اجرا می‌شود، هیچ سروری برای پردازش جست‌وجو نداشت و استفاده از APIهای خارجی نیز با قوانین حریم خصوصی آن‌ها در تضاد بود. این رویکرد یادآور تلاش‌های مشابه برای جایگزینی جست‌وجوی سنتی است، مشابه آنچه BizNode Pulse با بهره‌گیری از مدل Qwen3.5 برای تبدیل جست‌وجوی کلیدواژه‌ای به معنایی انجام داد.
برای حل این چالش، توسعه‌دهندگان از مفهوم Model2Vec استفاده کردند. به‌جای اجرای یک مدل سنگین ترنسفورمر (Transformer) — که مثل مغز مصنوعی پیچیده‌ای است و برای هر کلمه باید میلیون‌ها محاسبه انجام دهد — آن‌ها مدل را فقط یک‌بار در زمان ساخت سایت (Build Time) روی ۸۹۰۰ کلمه اجرا کردند. نتیجه این فرآیند، یک جدول استاتیک از بردار معنایی (Embedding) — شبیه به کارت معرفی عددی برای هر واژه که جایگاه معنایی آن را مشخص می‌کند — بود. این متدولوژی تقطیر مدل برای بهینه‌سازی عملکرد، با رویکرد مدل‌های کوچک‌شده‌ای که از طریق تقطیر محلی به صحت ۱۰۰٪ رسیدند هم‌سو است. حالا استنتاج (Inference) — یعنی همان لحظه تولید جواب، مثل خودِ آشپزی و نه یادگیری دستور پخت — به یک جست‌وجوی ساده در دیکشنری و میانگین‌گیری تبدیل شده است.
معماری سه کاناله
از آنجا که جداول استاتیک فاقد بستر (Context) هستند و کلمات جدید را نمی‌شناسند، این سیستم از سه کانال ترکیبی استفاده می‌کند که همگی به‌صورت فایل‌های JSON فشرده‌شده ارسال می‌شوند:
- کانال معنایی (
index.jsonبا حجم ۳.۳۹ مگابایت): از جدول برداری تقطیرشده استفاده می‌کند. بردارهای اسناد را به‌صورت میانگین نرمال‌شده (L2) ذخیره کرده و برای کاهش حجم، آن‌ها را به int8 کوانتیزه (Quantization) کرده است. این ایندکس در هر بار ساخت سایت به‌روز می‌شود و اگر کلمات جدیدی شناسایی شوند که در جدول نباشند، هشدار می‌دهد تا مدل دوباره تقطیر شود. - کانال لغت‌شناختی (
lex.jsonبا حجم ۵۸۸ کیلوبایت): از الگوریتم Okapi BM25 برای جست‌وجوی کلمات در عناوین و تگ‌ها استفاده می‌کند. این کانال برای یافتن اسامی خاص یا اصطلاحات تخصصی که در جدول برداری نیستند، حیاتی است. - کانال متنی (
body.jsonبا حجم ۱.۳۹ مگابایت): لایه دوم BM25 است که تمام متن صفحات را پوشش می‌دهد. تیم متوجه شد ۱۴۵۲۶ کلمه منحصر‌به‌فرد فقط در بدنه صفحات هستند و در عناوین تکرار نشده‌اند؛ بدون این کانال، این کلمات کاملاً نامرئی بودند.
اندازه‌گیری‌هایی که لایه متن را اجباری کرد
طبق گزارش تیم توسعه، آن‌ها برای تست سیستم بررسی کردند که چه پرس‌وجوهایی هیچ نتیجه‌ای ندارند. آن‌ها دریافتند که در متن صفحات، کلماتی وجود دارد که فقط در یک صفحه ظاهر شده‌اند. این کلمات بهترین کلیدها برای رسیدن به یک صفحه خاص هستند، اما در ابتدا ۲۰۰ مورد از این پرس‌وجوها در هر ۲۰۰ بار، هیچ نتیجه‌ای برنمی‌گرداندند.
پس از افزودن کانال متنی، نتایج تغییر کرد:
- کلمات تک-صفحه‌ای: نرخ بازیابی (Recall@1) از ۰٪ به ۱۰۰٪ رسید.
- عبارات سه کلمه‌ای: نرخ Recall@1 از ۲۱.۳٪ به ۳۱.۹٪ بهبود یافت.
ادغام نتایج و گارد «تطابق دقیق»
ترکیب نتایج شباهت کسینوسی (Cosine Similarity) و BM25 دشوار است چون مقیاس نمرات آن‌ها متفاوت است. برای حل این مشکل، آن‌ها از ادغام رتبه متقابل (Reciprocal Rank Fusion یا RRF) استفاده کردند. در RRF، نمره خام نادیده گرفته می‌شود و فقط رتبه سند در هر کانال ملاک است. این روش باعث می‌شود نتایج در مرورگر، Cloudflare Workers و Node.js دقیقاً یکسان باشد. در حالی که این سیستم در مقیاس کوچک عالی عمل می‌کند، در ابعاد بزرگتر باید مراقب چالش‌های مشابهی بود که در سقوط دقت بازیابی pgvector در مرز ۱۰ هزار بردار مشاهده شد.
اما یک نقص در RRF وجود داشت: «میان‌رتبه‌های ثابت» گاهی بر «برنده مطلق» غلبه می‌کردند. مثلاً سندی که در دو کانال رتبه دوم بود، از سندی که در یک کانال رتبه اول و در دیگری رتبه آخر بود، نمره بیشتری می‌گرفت. این یعنی اگر کاربر عنوان دقیق یک صفحه را تایپ می‌کرد، باز هم ممکن بود آن صفحه در رتبه ششم قرار بگیرد.
برای رفع این مورد، یک قانون ساده اضافه شد: اگر توکن‌های پرس‌وجو دقیقاً با عنوان یک صفحه مطابقت داشت، آن صفحه بدون توجه به نمره RRF به رتبه اول منتقل می‌شود.
عملکرد و نقاط ضعف
این سیستم به‌صورت لایه‌ای بارگذاری می‌شود؛ ابتدا لایه لغت‌شناختی (۵۸۸ کیلوبایت) لود می‌شود تا جست‌وجو فوراً فعال شود و سپس بردارهای سنگین‌تر اضافه می‌شوند. سرعت پاسخ‌دهی در یک سیستم معمولی بین ۴ تا ۱۰ میلی‌ثانیه است. با این حال، محدودیت‌های جدی وجود دارد:
- فقط ASCII: توکن‌ساز (Tokenizer) فقط حروف انگلیسی را می‌شناسد. بنابراین زبان‌های غیرلاتین یا حروف دارای علامت (مثل Gödel) به‌درستی پردازش نمی‌شوند.
- فقدان بستر: چون از میانگین بردارها استفاده می‌شود، ترتیب کلمات حذف می‌شود. برای این مدل، «سگ مرد را گاز گرفت» و «مرد سگ را گاز گرفت» یکسان هستند.
- حجم داده: ۵.۴ مگابایت برای یک صفحه جست‌وجوی اختصاصی مناسب است، اما برای صفحه اصلی سایت سنگین است.
انضباط مهندسی
تیم برای تضمین تست‌پذیری، تمام منطق را در یک فایل search-core.mjs متمرکز کرده است. این کد هم در HTML کاربر تزریق می‌شود، هم در سرور MCP (Model Context Protocol) استفاده می‌شود و هم در Node.js برای بنچمارک. این رویکرد، بار پردازشی AI را از زمان درخواست (Request-time) به زمان ساخت (Build-time) منتقل می‌کند.
گام بعدی شما
- اگر مجموعه‌ای از ۱۰۰ تا چند هزار سند دارید، به‌جای استفاده از Vector DBهای ابری، مدل خود را در زمان Build تقطیر کرده و به صورت JSON توزیع کنید.
- برای بهبود دقت در اسناد طولانی، از استراتژی تکه‌بندی (Chunking) استفاده کنید تا کلمات نادر در میانگین‌گیری گم نشوند.
- برای پشتیبانی از زبان‌های غیرانگلیسی، توکن‌ساز خود را به مدل‌های Folding ارتقا دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو