LightRAG سرعت استنتاج را ۲.۷ برابر کرد اما در برابر توهم شکست خورد

اگر امروز بین سرعت استقرار و دقت واقع‌بینانه در سیستم‌های بازیابی دانش مردد هستید، باید بدانید که هزینهٔ این سرعت در مدل‌های سبک، افزایش نرخ توهم است. در محکی که در ۱۴ اوت ۲۰۲۶ منتشر شد، LightRAG با تأخیر P90 معادل ۱۹,۴۳۰ میلی‌ثانیه، تقریباً ۲.۷ برابر سریع‌تر از QAnything (۵۲,۲۳۳ میلی‌ثانیه) عمل کرد.

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

پیچیدگی استقرار

LightRAG رویکردی مینیمال دارد. این سیستم با دستور pip install lightrag-hku نصب شده و گراف دانش (Knowledge Graph) و شاخص‌های برداری خود را در فایل‌های محلی در دایرکتوری rag_storage/ ذخیره می‌کند. این ساختار شامل چهار فایل کلیدی است:

• graph_chunk_entity_relation.graphml: هسته گراف دانش که روابط را ذخیره می‌کند.
• vdb_chunks.json: بردارهای مربوط به تکه‌های اسناد.
• vdb_entities.json: بردارهای مربوط به موجودیت‌ها.
• vdb_relationships.json: بردارهای مربوط به روابط.

به نقل از مستندات فنی، نبود نیاز به سرویس‌های خارجی، این مدل را برای نمونه‌سازی سریع ایده‌آل می‌کند. مقداردهی اولیه در LightRAG بسیار ساده است. توسعه‌دهندگان از کلاس LightRAG به همراه یک working_dir و یک EmbeddingFunc (که برای ۱۰۲۴ بُعد و حداکثر اندازه توکن ۸۱۹۲ پیکربندی شده است) استفاده می‌کنند. با این حال، در نسخه v1.5.x، فراخوانی await rag.initialize_storages() پیش از هر عملیاتی الزامی است، در غیر این صورت خطای PipelineNotInitializedError رخ می‌دهد.

در مقابل، QAnything v2 به یک پشته زیرساختی سنگین نیاز دارد. طبق گزارش dev.to، استقرار کامل آن مستلزم پنج سرویس داکر است:

• Elasticsearch: برای بازیابی کلمات کلیدی از طریق الگوریتم BM25.
• Milvus-standalone: به‌عنوان پایگاه‌داده برداری اصلی.
• etcd: ذخیره‌ساز متادیتای Milvus.
• Minio: ذخیره‌ساز اشیاء (Object Storage) برای Milvus.
• MySQL: مدیریت متادیتای اسناد و پایگاه دانش (KB).
• qanything_local: سرویس اصلی برای بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است تا همسایگی کلمات مشخص شود — بازرتبه‌بندی (Reranking) و مدیریت API.

تله‌های فنی در QAnything

استقرار QAnything بدون چالش نیست. این محک سه نقطه شکست بحرانی را در طول فرآیند راه‌اندازی شناسایی کرده است:

تله اول: عدم بهره‌برداری از GPU
به‌صورت پیش‌فرض، سرویس محلی حتی روی ماشین‌های دارای RTX 3060 روی CPU اجرا می‌شود. لاگ‌های استارت‌آپ ممکن است پیام "embedding和rerank服务将在CPU上运行" (سرویس‌های بردارساز و بازرتبه‌بندی روی CPU اجرا می‌شوند) را نشان دهند. این مشکل به این دلیل است که سرویس qanything_local در فایل docker-compose-linux.yaml فاقد پیکربندی منابع GPU است و پیام لاگ یک رشته سخت‌افزاری (hardcoded) در entrypoint.sh است که بدون توجه به در دسترس بودن سخت‌افزار چاپ می‌شود.

برای رفع این مشکل، سه گام لازم است:
۱. به‌روزرسانی Compose: اضافه کردن رزرو منابع GPU در فایل compose تحت بخش deploy: resources: reservations: devices با استفاده از driver: nvidia و capabilities: [gpu].
۲. نصب Toolkit: نصب NVIDIA Container Toolkit برای ایجاد پل ارتباطی بین داکر و GPU میزبان. این کار شامل افزودن کلید GPG انویدیا، به‌روزرسانی nvidia-docker.list و ری‌استارت سرویس systemctl داکر است.
۳. اصلاح اسکریپت: تغییر entrypoint.sh برای ارسال پرچم --use_gpu هنگام اجرای اسکریپت‌های embedding_server.py و rerank_server.py از طریق nohup.

پس از این اصلاحات، مصرف VRAM از ۱.۴ گیگابایت به ۸.۶ گیگابایت رسید و سرعت پردازش اسناد از کمتر از ۱ سند در ثانیه به حدود ۱ تا ۲ سند در هر ۱۵ ثانیه بهبود یافت.

تله دوم: فشار حافظه
در حالت CPU، کانتینر QAnything حدود ۲۷ گیگابایت رم مصرف کرد. این فشار باعث انقضای اجاره (lease) در etcd استندالون Milvus شد و خطاهایی مانند "etcdserver: requested lease not found" و "connection lost detected, shuting down" را ایجاد کرد. در این حالت، اسناد در وضعیت خاکستری «در صف برداری» (queued for vectorization) گیر می‌کردند و هرگز پیشرفت نمی‌کردند.

راهکار این مشکل، پاک‌سازی کامل دایرکتوری‌های داده‌های ماندگار (volumes/milvus ، volumes/etcd و volumes/mysql) پیش از اجرای مجدد است. ورودی‌های قدیمی نشست‌های etcd باعث می‌شوند سیستم بلافاصله پس از دستور docker compose up -d دوباره کرش کند، مگر اینکه با rm -rf پاک شوند.

تله سوم: عدم تطابق شناسه کاربر
فایل handler.py در QAnything یک پسوند user_info (به‌صورت پیش‌فرض "1234") را به هر user_id اضافه می‌کند. منطق سیستم به این صورت است: user_id = user_id + '__' + user_info. اگر یک اسکریپت شناسه را به‌صورت user_id=zzp__1234 بفرستد، شناسه ذخیره شده به zzp__1234__1234 تبدیل می‌شود. چون رابط کاربری وب کاربر را به عنوان zzp__1234 شناسایی می‌کند، پایگاه دانش ایجاد شده توسط API نامرئی می‌گردد. راهکار این است که از اسکریپت فقط user_id=zzp ارسال شود تا شناسه نهایی الحاق شده با رابط کاربری مطابقت داشته باشد.

بنچمارک‌های عملکرد

هر دو چارچوب با مدل GLM-4-flash به‌عنوان LLM و مجموعه‌ای یکپارچه از ۸۹ پرسش (۵۰ مورد واقع‌گرایانه تک‌گام، ۲۰ مورد استدلالی چندگام و ۱۹ مورد امتناع مرزی) آزمایش شدند. در این تست از ۳۱ فایل Markdown استفاده شد.

تأخیر و سرعت
میانگین تأخیر LightRAG حدود ۱۴,۶۷۴ میلی‌ثانیه بود، با P50 معادل ۱۳.۹ ثانیه، حداقل ۸.۷ ثانیه و حداکثر ۳۰.۸ ثانیه. QAnything با میانگین ۴۰,۵۱۹ میلی‌ثانیه، P50 معادل ۳۹.۲ ثانیه، حداقل ۱۹.۶ ثانیه و حداکثر ۶۲.۹ ثانیه بسیار کندتر عمل کرد. کندی QAnything ناشی از دو عامل است:

• مرحله بازرتبه‌بندی: هر پرس‌وجو یک مرحله بازرتبه‌بندی cross-encoder را طی می‌کند که یک فراخوانی استنتاج مدل اضافی می‌افزاید.
• حجم بازیابی: QAnything در ۱۰۰٪ پرس‌وجوها اسناد منبع واقعی را بازیابی کرد که به دلیل طولانی‌تر شدن بافت (Context)، زمان پردازش LLM را افزایش می‌دهد.

حالت "mix mode" در LightRAG یک پرس‌وجوی گراف دانش و یک پرس‌وجوی برداری را اجرا کرده و سپس آن‌ها را ادغام می‌کند. این روش زمانی که پیمایش گراف محدود باشد سریع است، اما در پیمایش‌های گسترده می‌تواند کند شود.

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

• تطبیق تک‌گام: QAnything (۰.۱۱۱) کمی بهتر از LightRAG (۰.۰۸۲) بود.
• تطبیق چندگام: LightRAG (۰.۱۷۸) پیشتاز QAnything (۰.۱۶۲) شد.
• امتناع مرزی: QAnything در ۲۶.۳٪ (۵ از ۱۹) موارد به‌درستی امتناع کرد، اما این نرخ در LightRAG تنها ۱۰.۵٪ (۲ از ۱۹) بود.

شکاف توهم

وقتی درباره حریم خصوصی GDPR (که در اسناد ارائه شده نبود) سؤال شد، LightRAG با استفاده از دانش داخلی مدل LLM خود، پاسخی متقاعدکننده اما بدون پشتوانه مستند (ungrounded) تولید کرد. در مقابل، QAnything به‌درستی از پاسخ دادن امتناع کرد و به زبان چینی پاسخ داد: "抱歉，检索到的参考信息并未提供任何相关的信息，因此无法回答" (متأسفم، اطلاعات مرجع بازیابی شده هیچ اطلاعات مرتبطی ارائه نمی‌دهد، بنابراین نمی‌توان پاسخ داد).

در تست‌های تک‌گام، هر دو پاسخ درست دادند اما فرمت متفاوت بود. برای پرسشی درباره embedding نامتقارن، LightRAG موجز بود. QAnything پاسخ درست را در سرتیترهای ساختاریافته Markdown مانند "## Inferred Answer Section" قرار داد که خروجی را پرحجم‌تر می‌کرد.

حالت "mix mode" در LightRAG بازیابی موجودیت‌های مرتبط و استدلال را در اولویت قرار می‌دهد. در حالی که این امر به روابط پیچیده کمک می‌کند، اما مدل را تشویق می‌کند تا زمانی که اسناد ساکت هستند، حدس بزند و این منجر به نرخ توهم بالاتر در پرس‌وجوهای مرزی می‌شود. پرامپت سیستمی QAnything حاوی قوانین صریحی برای امتناع در صورت نامرتبط بودن بافت است.

انتخاب پشته مناسب

شما باید به سمت LightRAG بروید اگر:

• نیاز دارید سریعاً یک رویکرد RAG را بدون سربار زیرساختی اعتبارسنجی کنید.
• تیم شما توانایی مدیریت Milvus، Elasticsearch یا MySQL در محیط عملیاتی را ندارد.
• اسناد شما دارای روابط پیچیده بین‌سندی هستند که از پیمایش گراف سود می‌برند.
• تأخیر (Latency) یک شاخص کلیدی عملکرد (KPI) است (P90 حدود ۲.۷ برابر سریع‌تر است).

QAnything گزینه بهتری است اگر:

• دقت در امتناع مرزی غیرقابل مذاکره است (نرخ امتناع ۲.۵ برابر بالاتر در این تست).
• با اسناد زبان چینی سروکار دارید، زیرا BCE embedding به‌طور خاص برای متن چینی بهینه شده است.
• کاربران غیرفنی به یک رابط کاربری وب داخلی برای آپلود اسناد نیاز دارند.
• به یک سیستم بازیابی ترکیبی BM25 + برداری آماده برای محیط عملیاتی نیاز دارید. این ترکیب دقیقاً همان دلیلی است که جست‌وجوی ترکیبی در محیط‌های صنعتی عملکرد بهتری نسبت به جست‌وجوی برداری خالص دارد.

این ارزیابی بر روی فایل‌های Markdown متمرکز بود؛ فاز بعدی تست‌ها بررسی نحوه مدیریت مجموعه‌داده‌های مقیاس بزرگ (بیش از ۱۰,۰۰۰ سند)، کیفیت بازیابی اسناد چینی و قابلیت‌های تجزیه PDF و جدول در QAnything خواهد بود.

گام بعدی شما

• اگر از LightRAG استفاده می‌کنید، حتماً یک لایه اعتبارسنجی برای پاسخ‌های مرزی اضافه کنید تا نرخ توهم کاهش یابد.
• برای استقرار QAnything، ابتدا NVIDIA Container Toolkit را نصب کنید تا از اتلاف منابع GPU جلوگیری شود.
• در صورت مواجهه با خطای etcd در QAnything، دایرکتوری‌های volumes را به‌طور کامل پاک کنید.

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