RAG برای داده‌های سازمانی فارسی

چرا RAG؟

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

RAG (مخفف Retrieval-Augmented Generation، «تولید تقویت‌شده با بازیابی») این شکاف را با ترکیب دو بخش پر می‌کند: نخست، بازیابی اسناد مرتبط با پرسش کاربر از پایگاه دانش سازمان؛ دوم، تولید پاسخ بر اساس همان اسناد. در عمل، هر پرسش به یک عبارتِ جستجو تبدیل می‌شود، اسناد نزدیک به آن از میان متن‌های سازمان بیرون کشیده می‌شوند و مدل زبانی پاسخ را با تکیه بر همین زمینه (context) می‌نویسد.

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

• دسترسی به دانش به‌روز بدون بازآموزی مدل؛
• امکان ارجاع به منبع و شفافیت در پاسخ؛
• جداسازی «ذخیره دانش» (اسناد) از «موتور تولید» (مدل) که نگهداری را ساده‌تر می‌کند.

خط لوله آماده‌سازی اسناد

کیفیت یک سیستم RAG به کیفیت اسناد ورودی وابسته است؛ سندی که از آن چیزی استخراج نشود، در عمل در پایگاه دانش وجود ندارد. نخستین گام، استخراج متن از قالب‌های مختلف است: متون PDF، اسناد Word و کاربرگ‌های Excel. برای اسناد اسکن‌شده و تصویری هم باید پیش از استخراج متن، سامانه تشخیص کاراکتر نوری (OCR) به کار گرفته شود.

پس از استخراج، نوبت پاک‌سازی است. در متون فارسی ناهماهنگی نویسه‌ها یکی از چالش‌های رایج است: برخی اسناد «ی» را با «ي» عربی می‌نویسند، «ک» را با «ك»، و نیم‌فاصله (ZWNJ) در برخی متن‌ها حذف یا به فاصله کامل تبدیل می‌شود. اعداد نیز گاه فارسی‌اند و گاه لاتین. اگر این ناهماهنگی‌ها نرمال‌سازی نشوند، بازیابی اسنادِ هم‌معنا در عمل شکست می‌خورد؛ چون توکن‌ها یکسان دیده نمی‌شوند.

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

بازیابی

در ساده‌ترین شکل، اسناد به بردارهای عددی (embedding) تبدیل می‌شوند و پرسش کاربر نیز بردار می‌شود؛ سپس نزدیک‌ترین بردارها به پرسش پیدا می‌شوند. این «جستجوی معنایی» شباهت مفهومی را درمی‌یابد، حتی اگر واژه‌های پرسش عیناً در سند نیامده باشند.

اما جستجوی معنایی به‌تنهایی برای اصطلاحات دقیق و کدها کافی نیست؛ مثلاً در جستجوی «شماره بخشنامه ۱۴۰۲/۱۲»، تطابق واژه‌ای (lexical) مهم‌تر از شباهت مفهومی است. به همین دلیل در عمل، نتایج جستجوی معنایی با نتایج روش کلاسیک BM25 ترکیب می‌شود تا نقاط ضعف یکدیگر را پوشش دهند؛ این ترکیب به «بازیابی ترکیبی» یا hybrid معروف است. در نهایت، یک مدل بازچینی (reranker) نتایج ترکیبی را با دقت بیشتری مرتب می‌کند تا متن‌های واقعاً مرتبط در صدر قرار گیرند.

برای متون فارسی، کیفیت مدل embedding عامل تعیین‌کننده است؛ مدل‌هایی که روی زبان فارسی خوب آموزش دیده‌اند، تفاوت «ی/ي» و نیم‌فاصله را بهتر مدیریت می‌کنند. در سازمان‌های فنی که اصطلاحات دوزبانه فارسی-انگلیسی پرکاربرد است نیز باید رفتار مدل با چنین ترکیب‌هایی آزموده شود تا جستجوی «دستیار هوشمند» و «AI Assistant» به نتیجه یکسان برسد.

تولید پاسخ با ارجاع

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

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

کنترل دسترسی و حریم خصوصی

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

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

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

ارزیابی سیستم RAG

یک سیستم RAG باید در دو سطح ارزیابی شود. اول، بازیابی: آیا برای هر پرسش، سند یا قطعه مرتبط واقعاً پیدا شده است؟ معیار رایج «نرخ اصابت» (hit rate) سهم پرسش‌هایی را می‌سنجد که دست‌کم یک سند مرتبط برای آن‌ها بازیابی شده است. دوم، تولید: آیا پاسخ تولیدشده به متن‌های بازیابی‌شده وفادار است و از آن‌ها بیرون نمی‌زند؟ این معیار «وفاداری» (faithfulness) است و در عمل باید به‌صورت دستی یا با کمک یک مدل دیگر روی نمونه‌ها بررسی شود.

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

جمع‌بندی

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

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