معماری RAG سازمانی: پایگاه دانش مبتنی بر دسترسی با PostgreSQL و pgvector

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

چرا PostgreSQL؟

به جای راه‌اندازی یک پایگاه داده برداری جداگانه، افزونه pgvector جستجوی برداری را به همان PostgreSQL که در حال حاضر استفاده می‌کنید اضافه می‌کند. این از نظر سازمانی دو مزیت بزرگ دارد: دسترسی‌های اسناد و بردارها در یک تراکنش (transaction) و همان مدل دسترسی (امنیت سطح سطر یا Row Level Security) قرار دارند؛ همچنین نیازی به یادگیری یک سیستم جدید برای پشتیبان‌گیری و پایش نیست.

گام ۱: تقسیم اسناد به بخش‌های کوچک (Chunking)

اسناد (قراردادها، رویه‌ها، مستندات فنی) به قطعاتی تقسیم می‌شوند که در زمینه مدل بگنجد. استراتژی قطعه‌بندی مستقیماً بر کیفیت نتایج تأثیر می‌گذارد: رویکردی که به مرزهای سرتیترها احترام می‌گذارد و همپوشانی کوتاهی با قطعات مجاور باقی می‌گذارد، معمولاً بهتر از تقسیم بر اساس تعداد نویسه (کاراکتر) ثابت عمل می‌کند. هر قطعه باید به سند منبع و محدوده دسترسی سند (دپارتمان، شرکت، سطح محرمانگی) متصل شود.

create extension if not exists vector;

create table doc_chunks (
  id          bigserial primary key,
  document_id uuid not null references documents (id) on delete cascade,
  company_id  uuid not null,
  scope       text not null,          -- örn. 'hr', 'finance', 'public'
  content     text not null,
  embedding   vector(768) not null,   -- boyut, kullanılan gömme modeline göre değişir
  created_at  timestamptz not null default now()
);

create index on doc_chunks using hnsw (embedding vector_cosine_ops);

گام ۲: تولید جاسازی (Embedding)

یک مدل جاسازی برای هر قطعه، بردار عددی تولید می‌کند. در نصب محلی، می‌توان از مدل‌های جاسازی با وزن باز استفاده کرد؛ انتخاب مدل بستگی به پشتیبانی زبان (کیفیت در متون ترکی مهم است)، ابعاد بردار و سخت‌افزار دارد. قانون مهم: مدلی که در زمان پرسجو استفاده می‌شود و مدلی که هنگام نمایه‌سازی قطعات استفاده شده است باید یکسان باشند؛ اگر مدل تغییر کند، تمام قطعات باید دوباره نمایه‌سازی شوند.

گام ۳: جستجوی فیلترشده بر اساس دسترسی

این گام اصلی و حیاتی است. پرسجوی شباهت برداری همراه با محدوده دسترسی کاربر اجرا می‌شود. در جدولی که RLS در آن فعال است، شرط خط‌مشی به طور خودکار به پرسجو اضافه می‌شود؛ بنابراین حتی اگر کد برنامه فیلتر را فراموش کند، پایگاه داده قطعه غیرمجاز را برنمی‌گرداند.

alter table doc_chunks enable row level security;

create policy chunks_read on doc_chunks for select using (
  company_id = current_company_id()          -- oturumdaki şirket
  and scope = any (current_user_scopes())    -- kullanıcının erişim kapsamları
);

-- Sorgu (politika otomatik uygulanır)
select id, document_id, content
from doc_chunks
order by embedding <=> $1    -- $1: sorunun gömme vektörü
limit 8;

خطرناک‌ترین خطا در سیستم‌های RAG این است که دستیار، سندی را که کاربر مجاز به باز کردن آن نیست، «خلاصه کند» و به او ارائه دهد. فیلتر باید درون داده‌ها باشد نه جلوی مدل.

گام ۴: ایجاد زمینه و استناد به منابع

قطعات پیدا شده به همراه پرسجو به مدل داده می‌شوند. هنگامی که پاسخ تولید می‌شود، مشخص می‌شود که از کدام قطعات استفاده شده و به عنوان منبع به کاربر نشان داده می‌شود: نام سند، بخش و پیوند. استناد به منابع دو کارایی دارد: کاربر می‌تواند پاسخ را راستی‌آزمایی کند و تشخیص زمان‌هایی که مدل «از خود چیزی می‌بافد» (hallucination) آسان‌تر می‌شود.

گام ۵: ثبت گزارش‌های حسابرسی (Audit Trail)

برای هر پرسجو، کاربر، زمان، سوال، شناسه‌های قطعه بازگردانده شده و پاسخ مدل در جدول حسابرسی ثبت می‌شوند. این رکوردها هم برای بررسی‌های امنیتی و هم برای بهبود کیفیت استفاده می‌شوند. از آنجا که خود رکوردها ممکن است حاوی داده‌های شخصی باشند، باید مدت زمان نگهداری و سطح دسترسی آن‌ها تعریف شود.

کیفیت: بدون مجموعه ارزیابی، بهبودی حاصل نمی‌شود

قبل از تولید، یک مجموعه ارزیابی کوچک متشکل از سوالات واقعی کاربران آماده کنید: سوال، سند منبع مورد انتظار و پاسخ قابل قبول. وقتی استراتژی قطعه‌بندی، تعداد قطعات یا مدل تغییر می‌کند، این مجموعه دوباره اجرا می‌شود. ما هدف عددی خاصی تعیین نمی‌کنیم؛ اسناد و انتظارات هر سازمانی متفاوت است. نکته مهم این است که تغییرات با اندازه‌گیری انجام شوند.

نکات اجرای محلی

• مدل و سرویس جاسازی باید در کانتینرهای جداگانه اجرا شوند و فقط از طریق شبکه داخلی قابل دسترسی باشند.
• هنگامی که اسناد نمایه‌سازی می‌شوند، محتوا باید بر اساس سطح محرمانگی برچسب‌گذاری شود؛ برچسب «عمومی برای همه» نباید پیش‌فرض باشد.
• خروجی مدل نباید مستقیماً یک تراکنش را راه‌اندازی کند (به عنوان مثال حذف رکورد)؛ تأیید انسانی باید در میان باشد.

جستجوی ترکیبی (Hybrid Search): بردار به تنهایی کافی نیست

شباهت برداری، نزدیکی معنایی را ثبت می‌کند اما ممکن است در پرسجوهایی که نیاز به تطابق دقیق دارند (مانند شماره قرارداد، کد محصول، نام شخص) ضعیف عمل کند. ترکیب قابلیت جستجوی تمام متن PostgreSQL (tsvector) با جستجوی برداری و ترکیب نتایج دو روش، در بیشتر سناریوهای سازمانی نتایج دقیق‌تری به دست می‌دهد. پیکربندی مناسب لغت‌نامه برای زبان ترکی (ریشه‌یابی و کلمات توقف) کیفیت سمت تمام متن را تعیین می‌کند.

-- Örnek: tam metin + vektör harmanı (kavramsal)
with lexical as (
  select id, ts_rank(search_vector, plainto_tsquery('turkish', $q)) as score
  from doc_chunks where search_vector @@ plainto_tsquery('turkish', $q)
  order by score desc limit 20
), semantic as (
  select id, 1 - (embedding <=> $qvec) as score
  from doc_chunks order by embedding <=> $qvec limit 20
)
select coalesce(l.id, s.id) as id,
       coalesce(l.score, 0) * 0.4 + coalesce(s.score, 0) * 0.6 as combined
from lexical l full outer join semantic s on s.id = l.id
order by combined desc limit 8;

وزن‌ها (0.4 / 0.6) نمونه هستند؛ باید با مجموعه ارزیابی کالیبره شوند.

وقتی سندی به‌روزرسانی می‌شود چه اتفاقی می‌افتد؟

اسناد سازمانی تغییر می‌کنند: رویه‌ها به‌روزرسانی می‌شوند، قراردادها تمدید می‌شوند. نمایه باید این تغییر را پیگیری کند؛ در غیر این صورت، دستیار نسخه قدیمی را به عنوان نسخه «به‌روز» ارائه می‌دهد. روش کاربردی: برای هر نسخه سند یک مقدار هش (hash) نگهداری می‌شود، قطعات سند تغییریافته حذف شده و دوباره تولید می‌شوند، نسخه قدیمی در آرشیو باقی می‌ماند اما وارد جستجو نمی‌شود. قطعات سند حذف شده نیز باید بلافاصله از نمایه پاک شوند؛ «سندی که دیگر به آن دسترسی ندارید» و «سندی که دیگر وجود ندارد» به یک شکل مدیریت می‌شوند.

انتخاب مدل و سخت‌افزار

در راه‌اندازی محلی، اندازه مدل تعادلی بین کیفیت پاسخ و هزینه سخت‌افزار است. مدل‌های وزن باز کوچک و متوسط ممکن است برای بیشتر نیازهای سازمانی در وظایف خلاصه‌سازیِ منبع‌دار و پرسش و پاسخ کافی باشند؛ سناریوهای نیازمند استدلال چندمرحله‌ای پیچیده به مدل‌های بزرگتری نیاز دارند. تصمیم‌گیری با سوالات واقعی در مجموعه ارزیابی گرفته می‌شود نه با جدول‌های مقایسه عمومی. در سمت سخت‌افزار، حافظه GPU تعیین‌کننده است و با افزایش تعداد کاربران همزمان، مدیریت صف لازم است.

قوانین سازمانی در طراحی دستور (Prompt)

• مدل باید فقط بر اساس زمینه داده شده پاسخ دهد؛ اگر در زمینه وجود ندارد باید بگوید «من این اطلاعات را ندارم».
• هر پاسخ باید شناسه‌های قطعه استفاده شده را برگرداند؛ استناد به منابع در سمت برنامه از این شناسه‌ها تولید می‌شود.
• زمینه‌های حاوی داده‌های شخصی باید فقط به کاربر مجاز و فقط به میزان لازم برای سوال ارائه شوند.
• ورودی کاربر باید به عنوان «داده» و نه به عنوان «دستور» به زمینه اضافه شود؛ متون داخل اسناد نیز نباید دستور تلقی شوند (تزریق پرامپت).

تجربه کاربری: اعتماد در رابط کاربری ساخته می‌شود

پیوندهای منابع باید قابل کلیک باشند و بخش مربوطه سند را باز کنند؛ ذکر شود که پاسخ یک «تفسیر مدلی» است؛ کاربر باید بتواند به پاسخ امتیاز دهد و این بازخورد وارد مجموعه ارزیابی شود. سیستم‌های RAG سیستم‌هایی نیستند که یک بار راه‌اندازی شوند و به حال خود رها گردند، بلکه با بازخورد به طور مداوم تنظیم می‌شوند.

در خدمات هوش مصنوعی و اتوماسیون شرکت Cy Logic، راه‌اندازی‌های RAG با این اصول انجام می‌شود: دسترسی در داده، منبع در پاسخ و ثبت گزارش در حسابرسی.