اگر امروز یک سیستم RAG را برای سازمان خود پیاده کرده‌اید، احتمالاً متوجه شده‌اید که تفاوت بین یک دموی جذاب و یک محصول امنیتی، در نحوه مدیریت دسترسی به داده‌هاست. باید بدانید که در مقیاس سازمانی، چالش اصلی دیگر کیفیت مدل نیست، بلکه زیرساخت و کنترل دسترسی است. در واقع، گذار از اسکریپت‌های ساده‌ی «Hello World» به یک معماری سازمانی امن و مقیاس‌پذیر، نیازمند تغییر دیدگاه است.
به گزارش راهنمای فنی منتشر شده در وب‌سایت dev.to در تاریخ ۱۴ سپتامبر ۲۰۲۶، سیستم‌های تولیدی باید از رویکرد «تلاش و خطا» در پرامپت‌ها فاصله بگیرند. درک بنیادین این است که یک سیستم RAG در سطح تولید، نه یک چالش مدل‌سازی، بلکه یک مسئله‌ی زیرساختی و کنترل دسترسی است. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش ۸۰ درصدی هزینه‌های RAG با زیرساخت‌های Bare Metal اشاره کردیم، اکنون تمرکز از لایه سخت‌افزار به لایه داده‌ها منتقل شده است. برای اکثر کسب‌وکارها، ریسک اصلی کیفیت مدل نیست، بلکه پدیده‌ای به نام «گم‌شدن در میانه» (Lost in the Middle) است؛ وضعیتی که در آن مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اطلاعات حیاتی را وقتی در میان پرامپت‌های طولانی دفن شده باشند، نادیده می‌گیرد. علاوه بر این، خطر دسترسی کاربران غیرمجاز به داده‌های حساس مانند لیست حقوق یا اطلاعات منابع انسانی (HR)، یک تهدید جدی برای سازمان‌هاست.
ذهنیت معماری
برای عبور از اسکریپت‌های آزمایشی، سیستم باید بر دو ستون استوار باشد:
- دانه‌ریزی داده‌ها و استراتژی بازیابی: هدف این بخش، تبدیل اسناد به واحدهای دقیق برای افزایش نسبت سیگنال به نویز است. به‌جای ارسال یک PDF ۵۰ صفحه‌ای به LLM، سیستم به‌صورت «جراحی‌گونه» تنها ۳ تا ۴ پاراگراف مرتبط را بازیابی می‌کند. این کار مانع از سردرگمی مدل در استخراج اطلاعات از مرکز پرامپت‌های طولانی شده و به‌طور مستقیم تأخیر (Latency) و هزینه‌های کلی را کاهش می‌دهد.
- کپسوله‌سازی داده‌ها و کنترل دسترسی ترکیبی: دسترسی به داده‌ها نباید «صفر و یکی» یا کلی باشد. سیستم باید از کنترل دسترسی مبتنی بر نقش (RBAC) به کنترل دسترسی مبتنی بر ویژگی (ABAC) حرکت کند. در این مدل، LLM هرگز داده‌هایی را که کاربر به‌طور صریح اجازه دسترسی به آن‌ها را ندارد، «نمی‌بیند» و به آن‌ها دسترسی ندارد.
پشته فناوری (Tech Stack)
طبق مستندات فنی این معماری، برای حل این چالش‌ها از یک پشته ناهمگام (Asynchronous) مدرن استفاده شده است:
- FastAPI و SQLModel: ایجاد لایه وب با کارایی بالا. SQLModel شکاف بین کلاس‌های پایتون و «منبع حقیقت» (Source of Truth) رابطه‌ای را پر می‌کند.
- PostgreSQL: مدیریت هویت کاربران، حقوق دسترسی و متادیتای فایل‌ها.
- Qdrant: یک پایگاه‌داده برداری (Vector Database) — شبیه به یک بایگانی هوشمند که مفاهیم را به‌جای کلمات ذخیره می‌کند — که به‌دلیل توانایی در فیلترینگ پیچیده Payload در مرحله بازیابی انتخاب شده است.
- LangChain: استفاده از ابزارهای قدرتمند این کتابخانه به‌طور خاص برای بارگذارهای اسناد (Document Loaders) و ابزارهای تکه‌بندی متن.
- PyJWT: مدیریت احراز هویت بدون وضعیت (Stateless) و امن، هرچند داده‌های حیاتی مجوزده (Authorization) در سمت سرور تأیید می‌شوند.
از نظر معماری، یک جداسازی سخت‌گیرانه بین پایگاه‌داده رابطه‌ای (PostgreSQL) و ذخیره‌ساز برداری (Qdrant) وجود دارد. این تفکیک تضمین می‌کند که مدیریت هویت و جست‌وجوی ابعادی بالا به‌صورت مجزا باقی بمانند و روی یکدیگر اثر نگذارند.
ورود دقیق داده‌ها
برای بهینه‌سازی نسبت سیگنال به نویز، سیستم از ارسال کل اسناد به مدل پرهیز می‌کند تا از افزایش هزینه‌ها و تأخیر جلوگیری شود. به‌جای آن، از ابزار RecursiveCharacterTextSplitter برای تکه‌بندی (Chunking) — مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — استفاده می‌شود. در این فرآیند، PDFها به تکه‌های قابل مدیریت ۱۰۰۰ کاراکتری با هم‌پوشانی ۱۵۰ کاراکتر تقسیم می‌شوند. این هم‌پوشانی تضمین می‌کند که تکه‌ها مرزهای پاراگراف را رعایت کنند تا زمینه (Context) متن از بین نرود.
هنگام ذخیره‌سازی (Upserting) در Qdrant، تنها بردارها ذخیره نمی‌شوند، بلکه یک «Payload» غنی ثبت می‌شود. این Payload شامل موارد زیر است:
- یک
postgres_idبرای حفظ یکپارچگی ارجاعی (Referential Integrity) بین دیتابیس رابطه‌ای و ذخیره‌ساز برداری. - یک
chunk_indexبرای حفظ ترتیب منطقی اسناد. - ویژگی‌های امنیتی مانند
department_idبرای فعال‌سازی فیلترینگ قطعی (Deterministic Filtering).
امنیت قطعی (Deterministic Security)
امنیت در این معماری در سطح موتور ذخیره‌سازی اعمال می‌شود، نه در پرامپت اپلیکیشن. سیستم از کنترل دسترسی مبتنی بر ویژگی (ABAC) استفاده می‌کند تا تضمین کند مدل هرگز داده‌های غیرمجاز را نمی‌بیند.
در مرحله اول، سیستم هویت را از توکن PyJWT استخراج می‌کند، اما department_id را مستقیماً از پایگاه‌داده PostgreSQL بازیابی می‌کند. تکیه بر ذخیره‌ساز رابطه‌ای به‌جای استفاده از ادعاهای (Claims) قدیمی داخل توکن، اجازه می‌دهد حقوق دسترسی به‌صورت آنی لغو شوند؛ این یک الزام حیاتی برای امنیت در سطح سازمان است.
در مرحله دوم، Qdrant یک ایندکس Payload روی فیلد department_id با استفاده از اسکیمای «keyword» ایجاد می‌کند. این موضوع برای مقیاس‌پذیری حیاتی است؛ زیرا بدون این ایندکس، موتور جست‌وجو مجبور به اسکن کامل (Full-scan) تمام Payloadهای ذخیره شده می‌شود که در حجم بالای بردارها، باعث جهش شدید تأخیر در پاسخ‌دهی می‌گردد.
در نهایت، منطق get_context یک فیلتر ترکیبی اعمال می‌کند. این منطق هم‌زمان که شباهت معنایی را محاسبه می‌کند، فضای جست‌وجو را به‌طور سخت‌گیرانه به اسنادی محدود می‌کند که با دپارتمان تأیید شده کاربر یا منابع عمومی (که با department_id: 0 علامت‌گذاری شده‌اند) مطابقت داشته باشند.
این تغییر رویکرد به این معناست که مرزهای مجوزده دیگر به استدلال مدل واگذار نشده‌اند؛ چرا که استدلال مدل را می‌توان با تزریق پرامپت (Prompt Injection) دور زد. با اعمال مرزها در سطح دیتابیس، یک معماری «اعتماد صفر» (Zero-Trust) شکل می‌گیرد.
برای توسعه‌دهندگان، این بدان معناست که اولویت از تغییر پرامپت‌ها به بهینه‌سازی خط لوله ورود داده‌ها (Ingestion Pipeline) تغییر می‌کند. اگر امنیت در سطح ذخیره‌سازی قطعی نباشد، سیستم RAG سازمانی به‌جای دارایی، به یک ریسک و تهدید تبدیل می‌شود.
برای مشاهده این مدل در عمل، می‌توانید پیاده‌سازی کامل مرجع و تنظیمات استقرار را در مخزن GitHub پروژه company-wiki-ai بررسی کنید.
گام بعدی شما
- بررسی پیاده‌سازی کامل این معماری در مخزن GitHub پروژه company-wiki-ai.
- جایگزینی فیلترهای متنی در پرامپت با فیلترهای Payload در سطح پایگاه‌داده برداری.
- پیاده‌سازی لایه اعتبارسنجی هویت در PostgreSQL پیش از ارسال درخواست به Vector Store.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو