شهریور
آموزش هوش مصنوعی
متادیتا و فیلتر؛ جستوجوی محدود به یک مشتری یا یک دوره
فرض کنید یک چتبات تخصصی ساختهاید که همزمان به چند مشتری یا چند سازمان سرویس میدهد و هر کدام مستندات محرمانهٔ خودشان را در همان وکتور دیتابیس مشترک دارند. اگر جستوجوی معنایی صرفاً بر اساس شباهت بردارها انجام شود، هیچ تضمینی وجود ندارد که سؤال یک مشتری، تصادفاً به یک chunk از دادهٔ مشتری دیگر گره نخورد. اینجا دقیقاً همان جایی است که متادیتا و فیلترکردن بر اساس آن، از یک ویژگی جانبی به یک مکانیزم امنیتی حیاتی تبدیل میشود.
لیست مطالب
متادیتا چیست؟
متادیتا اطلاعات ساختاریافتهای است که همراه هر بردار embedding ذخیره میشود اما خودش بخشی از محاسبهٔ شباهت معنایی نیست. برای مثال، در کنار بردار یک chunk از سند، میتوان شناسهٔ مشتری، نوع سند، تاریخ انتشار، سطح دسترسی یا زبان محتوا را هم بهعنوان فیلد جداگانه ذخیره کرد. اکثر وکتور دیتابیسها اجازه میدهند هنگام جستوجو، هم شباهت معنایی محاسبه شود و هم همزمان یک شرط دقیق روی این فیلدهای متادیتا اعمال شود.
| فیلد متادیتا | کاربرد در فیلتر |
|---|---|
| customer_id | محدودکردن جستوجو فقط به اسناد یک مشتری مشخص |
| document_type | جداسازی مثلاً قرارداد از راهنمای فنی یا سیاست داخلی |
| access_level | پنهانکردن اسناد محرمانه از کاربرانی که دسترسی ندارند |
| created_at / period | محدودکردن جستوجو به یک بازهٔ زمانی یا دورهٔ مشخص |
| language | بازیابی فقط محتوای همزبان با درخواست کاربر |
چطور فیلتر متادیتا جلوی نشت داده را میگیرد؟
مسئله اینجاست که شباهت کسینوسی هیچ مفهومی از «مالکیت داده» ندارد؛ اگر سؤال یک مشتری از نظر معنایی به یک chunk متعلق به مشتری دیگر نزدیک باشد (که کاملاً ممکن است، چون هر دو دربارهٔ موضوع مشابهی صحبت میکنند)، آن chunk میتواند در نتایج بازیابی ظاهر شود و در نهایت به مدل زبانی تزریق شود و در پاسخ نهایی به کاربر اشتباهی نشت کند. راهحل درست این نیست که امیدوار باشید شباهت معنایی «بهاندازهٔ کافی» دادهها را جدا نگه دارد؛ راهحل این است که در همان لایهٔ کوئری، پیش یا همزمان با محاسبهٔ شباهت، یک فیلتر سختگیرانه روی customer_id اعمال شود تا اصلاً هیچ chunk متعلق به مشتری دیگر وارد فهرست نامزدهای بازیابی نشود.
// مثال مفهومی از یک کوئری جستوجوی وکتور با فیلتر متادیتا
{
"vector": [0.021, -0.114, 0.087, ...],
"top_k": 5,
"filter": {
"must": [
{ "key": "customer_id", "match": { "value": "cust_1284" } },
{ "key": "access_level", "match": { "value": "public" } }
]
}
}نکتهٔ مهم این است که این فیلتر باید در سمت سرور و در همان مرحلهٔ جستوجوی وکتور دیتابیس اعمال شود، نه اینکه همهٔ نتایج بدون فیلتر بازیابی شوند و بعد در کد برنامه بهصورت دستی پاکسازی شوند؛ فیلترکردن بعد از بازیابی هم کندتر است و هم مستعد خطای انسانی — کافی است یک مسیر کد فراموش شود تا نشت داده رخ دهد.
فیلتر متادیتا برای دوره و زمان
همین منطق برای محدودکردن جستوجو به یک بازهٔ زمانی هم صادق است؛ مثلاً وقتی محتوای یک دورهٔ آموزشی یا یک نسخهٔ قدیمی از مستندات محصول باید کنار نسخهٔ جدید نگه داشته شود، ولی چتبات فقط باید از آخرین نسخه پاسخ بدهد. بدون فیلتر روی تاریخ یا شناسهٔ نسخه، مدل ممکن است بهطور تصادفی از سیاست یا قیمتی قدیمی و منقضیشده در پاسخش استفاده کند، فقط چون آن chunk از نظر معنایی به سؤال کاربر نزدیک بوده است.
یک قاعدهٔ عملی: هر فیلد متادیتایی که باید همیشه محدودکنندهٔ دسترسی باشد (مشتری، سطح دسترسی، نسخه) باید در لایهٔ کوئری وکتور دیتابیس اجباری شود، نه اینکه به دقت پرامپت یا حسننیت مدل زبانی واگذار شود.
فیلتر متادیتا و هزینهٔ کارایی
یک نکتهٔ عملی دیگر این است که فیلتر متادیتا نباید کاری باشد که سریعبودن ایندکس تقریبی وکتور دیتابیس را از بین ببرد. اگر فیلتر بعد از بازیابی همهٔ نتایج نزدیک اعمال شود، ممکن است پیش بیاید که همهٔ نتایج نزدیک بازیابیشده متعلق به مشتریان دیگر باشند و هیچ نتیجهٔ معتبری برای مشتری موردنظر باقی نماند. به همین دلیل، وکتور دیتابیسهای امروزی این فیلترها را در همان مرحلهٔ پیمایش ایندکس اعمال میکنند، نه بعد از آن؛ این طراحی هم دقت را تضمین میکند و هم از افت شدید کارایی جلوگیری میکند. هنگام انتخاب وکتور دیتابیس، ارزش دارد بهصراحت بررسی شود که فیلتر متادیتای آن ابزار، در سطح ایندکس اجرا میشود یا صرفاً یک پاکسازی بعد از بازیابی است.
این معماری در یک سیستم بزرگتر چه جایگاهی دارد؟
وقتی این مکانیزم فیلتر متادیتا را در کنار بازیابی معنایی قرار میدهید، عملاً یک لایهٔ کنترل دسترسی درون خود موتور جستوجو ساختهاید که مستقل از منطق مدل زبانی کار میکند. این طراحی، وقتی چتبات بخشی از یک سیستم بزرگتر با چند ایجنت و چند منبع داده باشد اهمیت بیشتری پیدا میکند. برای دیدن اینکه چطور این مؤلفهها — از فیلتر متادیتا تا هماهنگی چند ایجنت — در یک سیستم اتوماسیون واقعی کنار هم مینشینند، نقشهٔ راه ایجنتها و اتوماسیون را ببینید.
متادیتا بهتنهایی جایگزین کنترل دسترسی واقعی نیست
یک هشدار مهم این است که فیلتر متادیتا در وکتور دیتابیس، جایگزین لایهٔ احراز هویت و مجوزدهی برنامهٔ اصلی نیست؛ باید تضمین شود که مقدار customer_id یا access_level که در فیلتر استفاده میشود، از یک منبع قابلاعتماد در سمت سرور میآید (مثلاً از نشست ورود کاربر)، نه از پارامتری که مستقیماً از سمت کاربر یا کلاینت قابل تغییر باشد. اگر این مقدار از منبعی غیرقابلاعتماد گرفته شود، کل مکانیزم فیلتر متادیتا، هرقدر هم که در وکتور دیتابیس درست پیادهسازی شده باشد، دور زده میشود.
جمعبندی
- متادیتا اطلاعات ساختاریافتهای کنار هر بردار است که در محاسبهٔ شباهت معنایی دخالت ندارد اما در فیلترکردن نتایج حیاتی است.
- شباهت معنایی بهتنهایی هیچ مرزی بین مشتریها یا سطوح دسترسی نمیشناسد؛ این وظیفهٔ فیلتر متادیتاست.
- فیلتر روی customer_id یا access_level باید در همان کوئری وکتور دیتابیس اجرا شود، نه بهصورت پاکسازی دستی بعد از بازیابی.
- فیلتر بر اساس تاریخ یا نسخه از پاسخدادن با محتوای منقضیشده جلوگیری میکند.
- طراحی درست فیلتر متادیتا، پایهٔ امنیت داده در هر چتبات چندمشتریه یا چندسازمانی است.
