تصور کنید یک برنامه‌نویس بتواند تمام حافظهٔ یک مدل هوش مصنوعی را در یک فایل ساده ذخیره کند و بدون نیاز به اینترنت یا سرورهای گران‌قیمت، در کمتر از ۱۰ میلی‌ثانیه به پاسخ برسد. این رویایی است که حالا با استفاده از sqlite-vec به واقعیت تبدیل شده است.
طبق گزارش فنی TormentNexus، یک MacBook Air مدل ۲۰۲۰ با ۸ گیگابایت رم توانست پرس‌وجوهای معنایی را روی ۲۱۵,۰۰۰ بردار معنایی (Embedding) — شبیه به کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است — تنها در ۳.۲ میلی‌ثانیه اجرا کند. این دستاورد در حالی می‌آید که اکثر جریان‌های کاری فعلی هوش مصنوعی به ذخیره‌سازهای سنگینی مانند Pinecone یا Weaviate متکی هستند. این ابزارها نیازمند سرورهای اختصاصی و فراخوان‌های شبکه‌ای هستند که باعث ایجاد تأخیر (Latency)، هزینه‌های تکرار‌شونده API و ایجاد سطوح گسترده‌ای برای حملات امنیتی می‌شوند. در مقابل، برخی از راهکارهای صنعتی تلاش کرده‌اند با بهره‌گیری از سخت‌افزارهای گرافیکی تأخیر را در مقیاس‌های میلیاردی کاهش دهند، اما sqlite-vec بر روی بهینه‌سازی محلی متمرکز است. برای دستگاه‌های لبه (Edge)، سیستم‌های جاسازی‌شده و اپلیکیشن‌های دسکتاپ، این وابستگی‌ها باعث افزایش سربار حافظه و پیچیدگی در استقرار می‌شوند.
همان‌طور که در تحلیل قبلی ما درباره‌ی مدیریت شکست‌های RAG اشاره کردیم، هدف نهایی کاهش وابستگی به لایه‌های پیچیده است. این معماری جدید، کل لایهٔ هوشمند را به دیسک محلی منتقل می‌کند تا امنیت افزایش، هزینه‌ها حذف و پیچیدگی استقرار به شدت کاهش یابد.
معماری بدون وابستگی
این سامانه از sqlite-vec (نسخه ۰.۱.۰) استفاده می‌کند تا جست‌وجوی شباهت برداری را مستقیماً وارد SQLite کند؛ یعنی رایج‌ترین پایگاه‌داده رابطه‌ای موجود در جهان. به نقل از مستندات پروژه، این روش نیاز به Docker، نصب بسته‌های pip یا وابستگی‌های npm را به کلی حذف می‌کند؛ شما صرفاً یک فایل افزونه (Extension) را بارگذاری می‌کنید. این قابلیت به توسعه‌دهندگان اجازه می‌دهد تا بردارهای معنایی را در کنار داده‌های رابطه‌ای موجود، هر دو در قالب یک فایل واحد دیتابیس، ذخیره، ایندکس و پرس‌وجو کنند. این رویکرد ترکیبی مشابه تلاش‌های اخیر در دنیای متن‌باز است که در آن شتاب‌دهنده‌های گرافیکی بازدهی pgvector را افزایش دادند تا قدرت دیتابیس‌های رابطه‌ای را در پردازش برداری بالا ببرند.
مراحل خط لوله و داده‌های آزمایشی
برای اثبات این ادعا، خط لوله روی مجموعه‌ای از ۵۰,۰۰۰ شرح Synthetic در گیت‌هاب (حدود ۲۰۰ مگابایت متن خام) آزمایش شد. هدف این بود که ثابت شود یک سیستم کامل جست‌وجوی معنایی می‌تواند پس از دانلود اولیه مدل، کاملاً آفلاین و با صفر فراخوان شبکه کار کند. معماری این سیستم از چهار مرحله مجزا تشکیل شده است: جذب داده (Ingestion)، تکه‌بندی (Chunking)، تولید بردار (Embedding) و در نهایت پرس‌وجو (Querying).
پشته تکنولوژی هسته
برای رسیدن به این سرعت و کارایی، پیاده‌سازی از یک پشته نرم‌افزاری بسیار سبک و بهینه بهره می‌برد:
- ذخیره‌سازی: استفاده از sqlite-vec (v0.1.0) برای ذخیره بردارها و اجرای عملیات جست‌وجوی شباهت.
- مدل: بهره‌گیری از sentence-transformers از طریق زمان اجرای ONNX، به طور مشخص مدل
all-MiniLM-L6-v2با ۳۸۴ بُعد. - کتابخانه‌های پایتون: حداقل وابستگی‌های ممکن شامل
sqlite3برای دیتابیس،numpyبرای محاسبات عددی،onnxruntimeبرای اجرای مدل وtokenizersبرای پردازش متن. - پردازش متن: تکه‌بندی معنایی با استفاده از بخش‌بندی جملات NLTK همراه با قابلیت همپوشانی (Overlap).
تکه‌بندی معنایی و پردازش متن
متن‌های خام باید قبل از تبدیل به بردار، به تکه‌هایی منسجم و دارای معنا تبدیل شوند. این خط لوله از بخش‌بندی جملات NLTK و رویکرد «پنجره لغزان» (Sliding Window) استفاده می‌کند. هدف این است که هر تکه ۲۵۶ توکن — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — داشته باشد. برای حفظ زمینه (Context) و جلوگیری از قطع شدن مفاهیم در مرز تکه‌ها، ۶۴ توکن همپوشانی در نظر گرفته شده است تا تطبیق‌ها به دقت بیشتری انجام شوند.
- توکن‌ساز (Tokenizer): برای تخمین اندازه مدل از
cl100k_baseاز طریق کتابخانهtiktokenاستفاده می‌شود. - مکانیسم: تکه‌بند روی جملات حرکت می‌کند و پس از رسیدن به حد توکن‌ها، تکه فعلی را تخلیه کرده و با حذف قدیمی‌ترین جملات، همپوشانی را محاسبه می‌کند.
- کارایی: در تست‌ها، این عملیات توانست ۵۰,۰۰۰ مورد گیت‌هاب را در تنها ۴.۲ ثانیه به تقریباً ۲۱۵,۰۰۰ تکه تبدیل کند (با میانگین ۱۹۸ توکن برای هر تکه).
تولید بردار محلی
برای حذف کامل اثر شبکه و حفظ حریم خصوصی، سیستم با اجرای یک نسخه صادر شده از مدل all-MiniLM-L6-v2 در قالب ONNX، از فراخوان‌های API راه دور اجتناب می‌کند. این مدل سبک، بردارهای واحدی با ۳۸۴ بُعد تولید می‌کند.
- زمان اجرا (Runtime): سیستم از ONNX Runtime با بهینه‌سازی‌های Arm برای اجرای بهینه روی CPU استفاده می‌کند.
- دسته‌بندی (Batching): برای حداکثر کردن توان عملیاتی بدون فراتر رفتن از محدودیت‌های حافظه، از استنتاج دسته‌ای ایستا (Static Batch Inference) با اندازه دسته ۳۲ استفاده شده است.
- خط لوله: این فرآیند شامل توکن‌سازی و Padding ورودی‌ها تا حداکثر طول ۲۵۶، انجام استنتاج (Inference)، و سپس اجرای Mean Pooling و نرمال‌سازی است.
- سرعت: تبدیل تمام ۲۱۵,۰۰۰ تکه به بردار روی CPU مدل M1 تنها ۸.۳ ثانیه زمان برد.
بهینه‌سازی دیتابیس برای سرعت
این پیاده‌سازی از یک طرح (Schema) خاص در SQLite برای ایجاد تعادل بین متادیتا و بردارها استفاده می‌کند. جدول بردارها به عنوان یک جدول مجازی (Virtual Table) با استفاده از vec0 و معیار فاصله کسینوسی (Cosine Distance) برای بردارهای ۳۸۴ بعدی ایجاد شده است:
CREATE VIRTUAL TABLE issue_vectors USING vec0( id INTEGER PRIMARY KEY, embedding FLOAT[384] distance_metric=cosine );
یک جدول کمکی به نام issue_metadata نیز برای ذخیره متن خام، عناوین و شاخص تکه‌ها ایجاد شده است:
CREATE TABLE issue_metadata ( id INTEGER PRIMARY KEY, issue_title TEXT NOT NULL, issue_text TEXT NOT NULL, chunk_index INTEGER NOT NULL, chunk_text TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );
برای جلوگیری از گلوگاه‌های ورودی/خروجی (I/O) در هنگام درج انبوه داده‌ها، تنظیمات حیاتی PRAGMA اعمال شده است:
- حالت ژورنال: فعال‌سازی
PRAGMA journal_mode=WALبرای پشتیبانی از خواندن‌های همزمان. - اندازه حافظه پنهان (Cache): افزایش تا ۱۰ گیگابایت از طریق
PRAGMA cache_size=-10000000. - نگاشت حافظه: مقدار
PRAGMA mmap_sizeروی ۱۰,۷۳۷,۴۱۸,۲۴۰ بایت تنظیم شده است.
درج انبوه ۲۱۵,۰۰۰ بردار با استفاده از executemany و آرایه‌های numpy تنها ۲.۱ ثانیه زمان برد. فایل نهایی دیتابیس ۱۳۲ مگابایت حجم دارد. ایندکس برداری از یک ساختار درختی K-Means اصلاح شده برای فاصله کسینوسی بهره می‌برد که برای این مجموعه داده خاص، از ۱,۰۲۴ مرکز (Centroid) استفاده می‌کند. این ایندکس ۸۶ مگابایت فضای دیسک اضافی اشغال می‌کند.
بنچمارک عملکرد
تأخیر در پرس‌وجو، معیار اصلی موفقیت است. سیستم یک پرس‌وجوی خام کاربر را به بردار تبدیل کرده و سپس یک دستور MATCH در SQLite را برای یافتن نتایج top-k اجرا می‌کند. این فرآیند سرتاسری (End-to-End) شامل موارد زیر است:
- تولید بردار پرس‌وجو: حدود ۵ میلی‌ثانیه از طریق ONNX.
- جست‌وجوی شباهت برداری: میانگین ۳.۲ میلی‌ثانیه (با انحراف معیار ۰.۷ میلی‌ثانیه) در ۱,۰۰۰ جست‌وجوی تصادفی.
- تأخیر کل: کمتر از ۱۰ میلی‌ثانیه برای ۹۹٪ پرس‌وجوها.
با مقیاس‌پذیری مجموعه داده، عملکرد به صورت خطی نسبت به تعداد مراکز (Centroids) تغییر می‌کند. در سطح ۱ میلیون بردار، تأخیر پرس‌وجو به حدود ۲۵ میلی‌ثانیه و زمان درج به ۱۵ ثانیه می‌رسد. با این حال، سربار حافظه ثابت برای مدل ONNX (۸۰ مگابایت) و توکن‌ساز (۶۰ مگابایت) بدون توجه به اندازه دیتابیس، ثابت می‌ماند.
کاربردهای عملی و مقیاس‌پذیری
برای مجموعه داده‌هایی که از ۵ میلیون بردار فراتر می‌روند، نویسندگان پیشنهاد «ذخیره‌سازی لایه‌ای» (Tiered Storage) را می‌دهند: نگه داشتن بردارهای اخیر در sqlite-vec و آرشیو کردن داده‌های قدیمی‌تر در یک فایل SQLite ثانویه یا فضای ابری (Cloud Blob Storage). این معماری پیش‌فرض قدیمی مبنی بر نیاز RAG به یک بک‌اند ابری را می‌شکند.
این تغییر، دسترسی به دسته‌های جدیدی از اپلیکیشن‌ها را ممکن می‌کند:
- چت‌بات‌های محلی (Local-First): سیستم‌های حافظه‌ای که کاملاً روی دستگاه کاربر مقیم هستند. این رویکرد یادآور مدل‌های پیشرفته‌ای است که در درون EverOS برای تبدیل تجربیات به مهارت‌های قابل بازاستفاده به کار گرفته شده است.
- پیشنهاددهنده‌های حریم‌خصوصی‌محور: سیستم‌هایی که در آن‌ها هیچ داده‌ای از کاربر هرگز از دستگاه خارج نمی‌شود.
- جست‌وجوی آفلاین در IDE: جست‌وجوی معنایی برای مستندات که بدون دسترسی به اینترنت کار می‌کند.
برای توسعه‌دهندگان، این روش «لرزش تأخیر» (Latency Jitter) ذاتی در فراخوان‌های شبکه را حذف کرده و هزینه‌های API و نگرانی‌های مربوط به حاکمیت داده‌ها را از بین می‌برد. اکنون می‌توانید یک پایگاه دانش کاملاً کاربردی را به عنوان یک اثر ایستا (Static Artifact) توزیع کنید. این کار باعث می‌شود حافظه قدرت‌یافته با هوش مصنوعی، به جای یک سرویس مدیریت‌شده، به یک فایل قابل حمل تبدیل شود.
برای پیاده‌سازی این پشته حافظه محلی، الگوهای استقرار کامل و نمونه‌های کد را در TormentNexus بررسی کنید.
گام بعدی شما
- بررسی مستندات sqlite-vec برای جایگزینی دیتابیس‌های برداری ابری در پروژه‌های کوچک.
- آزمایش مدل all-MiniLM-L6-v2 روی سخت‌افزارهای لبه (Edge) برای ارزیابی تأخیر.
- پیاده‌سازی ذخیره‌سازی لایه‌ای (Tiered Storage) برای مدیریت داده‌های بیش از ۵ میلیون بردار.
اما چالش واقعی در اینجا، تعادل بین دقت بازیابی و سرعت جست‌وجو است — به تحلیل ما درباره‌ی اثر کوانتش وزن‌ها بر کیفیت پاسخ‌ها مراجعه کنید.
گفتگو