Filtered ANN چیست و چرا فیلتر ACL در Vector Search سخت است؟
Filtered ANN چیست و چرا اعمال ACL و metadata filter در جستجوی برداری یکی از سختترین مسائل معماری RAG است؟ برای پیادهسازی عملی.
- filtered vector search
- HNSW filtering
- ACL vector database

مقدمه
در نگاه اول، بهنظر میرسد اعمال ACL یا metadata filter روی Vector Search ساده است: اول nearest neighbors را پیدا کن، بعد نتایج غیرمجاز را حذف کن. اما در production این روش اغلب کافی نیست. چرا؟ چون ممکن است بعد از حذف نتایج غیرمجاز، عملاً چیزی مفید باقی نماند. اینجاست که مفهوم Filtered ANN اهمیت پیدا میکند.
مسئله اصلی چیست؟
فرض کنید top-20 nearest neighbors پیدا شدهاند، اما 15 تای آنها به tenant دیگر تعلق دارند یا مجوز دسترسی ندارند. اگر filtering را بعد از retrieval انجام دهید، candidate set واقعی خیلی کوچک و ضعیف میشود. در نتیجه:
- recall افت میکند
- ranking ضعیف میشود
- latency به خاطر retry یا fallback بالا میرود
- خطر نشت اطلاعات در معماری بد بیشتر میشود
Filtered ANN یعنی چه؟
Filtered ANN یعنی فیلترها بهنوعی در خود candidate generation دخیل باشند، نه فقط بعد از آن. این میتواند از طریق payload filtering در vector DBها، graph traversal آگاه از فیلتر، یا ساختارهای index مناسب انجام شود.
ACL چرا مسئله را سختتر میکند؟
ACL فقط یک filter ساده نیست. ممکن است شامل این موارد باشد:
- tenant_id
- allowed_groups
- allowed_users
- visibility
- access level
ترکیب این فیلدها query-time filtering را پیچیدهتر میکند.
تجربه ما در ماژول
در audit یکی از نسخهها متوجه شدیم که search engine همیشه predicate میفرستاد و همین باعث میشد HNSW backend به exact fallback برگردد. این یک lesson بزرگ بود: اگر filtering بهدرستی push down نشود، ANN مزیت خود را از دست میدهد.
معماری خوب چیست؟
معماری خوب برای filtered ANN باید این خصوصیات را داشته باشد:
- filter-aware candidate generation
- policy enforcement قبل از return result
- explainability برای اینکه چرا سندی حذف شد
- benchmark جداگانه برای recall under filter
چه backendهایی کمک میکنند؟
Backendهایی مثل Qdrant و OpenSearch در این حوزه امکانات بهتری دارند، چون payload filters یا hybrid query planning را در سطح engine ارائه میکنند.
اشتباه رایج
یکی از اشتباههای رایج این است که ACL را فقط در مرحله آخر UI یا application layer اعمال کنند. این از نظر security و retrieval quality هر دو خطرناک است. ACL باید به retrieval pipeline نزدیک باشد.
جمعبندی
Filtered ANN یکی از موضوعات تخصصی اما بسیار مهم در RAG و Semantic Search سازمانی است. اگر multi-tenancy و access control برای شما مهم است، نمیتوانید filtering را یک کار ساده بعد از retrieval در نظر بگیرید. معماری enterprise-grade باید از ابتدا برای filter-aware search طراحی شده باشد.
بهروزرسانی:
همهٔ نوشتهها