RAG چیست؟ تولید تقویت‌شده با بازیابی، توضیح ساده

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

چرا RAG وقتی با هوش مصنوعی می‌سازید مهم است

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

برای حل این مشکل سه گزینه‌ی کلی دارید:

مدل‌های امروزی پرامپت‌های بلند را می‌پذیرند، پس برای یک FAQ کوتاه گزینه‌ی اول اغلب کافی است. RAG وقتی ارزشش را نشان می‌دهد که متن بیشتری دارید از آنچه می‌خواهید هر بار بفرستید، چون هر کلمه‌ای که می‌فرستید هزینه و زمان دارد (ببینید LLM APIها چطور هزینه می‌گیرند).

اگر دارید قابلیت «گفتگو با اسنادمان» یا یک دستیار پشتیبانی یا ابزار دانش داخلی می‌سازید، تقریباً قطعاً یک نوع RAG می‌سازید.

یک تشبیه روزمره

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

• دانش‌آموز همان مدل زبانی است.
• کتاب درسی اسنادتان است.
• ورق زدن به صفحه‌های درست همان بازیابی است.
• نوشتن جواب از روی آن صفحه‌ها همان تولید است.

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

RAG چطور کار می‌کند، قدم‌به‌قدم

یک راه‌اندازی معمولی RAG دو مرحله دارد.

آماده‌سازی اسنادتان (از قبل انجام می‌شود):

1. جمع‌آوری منابع: مقاله‌های راهنما، PDFها، سیاست‌ها، داده‌ی محصولات.
2. تکه‌تکه کردن (Chunk): اسناد بلند را به قطعه‌های کوچک‌تر، معمولاً چند پاراگراف، تقسیم کنید تا جستجو فقط بخش مرتبط را برگرداند.
3. Embed کردن هر قطعه: آن را به یک مدل embedding بدهید که متن را به یک embedding تبدیل می‌کند؛ یک فهرست بلند از عدد که معنای متن را نگه می‌دارد. متن‌هایی درباره‌ی چیزهای مشابه، عددهای مشابه می‌گیرند.
4. ذخیره: قطعه‌ها و embeddingهایشان را در یک پایگاه داده که بر اساس شباهت جستجو کند ذخیره کنید (که اغلب پایگاه برداری یا vector index نامیده می‌شود).

پاسخ دادن به یک سؤال (هر بار انجام می‌شود):

1. Embed کردن سؤال با همان مدل embedding.
2. بازیابی قطعه‌هایی که embeddingشان به سؤال نزدیک‌تر است؛ مثلاً پنج تای برتر.
3. ساختن پرامپت: دستورها، قطعه‌های بازیابی‌شده و سؤال.
4. تولید: مدل پاسخ را بر اساس آن قطعه‌ها می‌نویسد و ترجیحاً می‌گوید از کدام‌ها استفاده کرده است.

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

یک مثال کامل: دستیار راهنمای یک باشگاه

فرض کنید یک باشگاه ورزشی ۴۰ مقاله‌ی راهنما دارد و می‌خواهد یک دستیار چت در وب‌سایتش داشته باشد. یک عضو می‌پرسد: «وقتی سفر هستم می‌توانم عضویتم را متوقف کنم؟»

اپلیکیشن سؤال را embed می‌کند و سه قطعه‌ی نزدیک را بازیابی می‌کند. یکی از آن‌ها این است:

توقف عضویت: اعضای پلن ماهانه می‌توانند عضویتشان را
حداکثر ۲ ماه در سال متوقف کنند. این درخواست را در پذیرش یا
در اپلیکیشن حداقل ۷ روز قبل از شروع توقف ثبت کنند.

پرامپتی که به مدل فرستاده می‌شود شبیه این است:

تو دستیار راهنمای باشگاه Northside Gym هستی.
فقط بر اساس منابع زیر جواب بده. اگر جواب در آن‌ها نیست،
بگو که نمی‌دانی و پیشنهاد کن با پذیرش تماس بگیرند.
بگو از کدام منبع استفاده کردی.

[منبع ۱: توقف عضویت] اعضای پلن ماهانه می‌توانند متوقف کنند...
[منبع ۲: لغو عضویت] ...
[منبع ۳: مهمان‌های دعوت‌شده] ...

سؤال: وقتی سفر هستم می‌توانم عضویتم را متوقف کنم؟

و مدل جواب می‌دهد: «بله؛ در پلن ماهانه می‌توانید عضویتتان را تا دو ماه در سال متوقف کنید. حداقل ۷ روز قبل، در پذیرش یا در اپلیکیشن درخواست بدهید (منبع: توقف عضویت).»

باشگاه هیچ‌چیزی را دوباره آموزش نداده است. وقتی سیاست توقف را عوض کند، مقاله را به‌روز می‌کند، اپلیکیشن آن قطعه را دوباره embed می‌کند، و پاسخ بعدی منعکس‌کننده‌ی آن است.

توضیح اصطلاحات کلیدی

برداشت‌های غلط رایج

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

هزینه‌اش چقدر است

یک قابلیت RAG معمولاً سه هزینه‌ی جاری دارد: embedding کردن اسناد (کم، و بیشتر یک‌باره)، embedding کردن هر سؤال (ناچیز)، و فراخوانی مدل زبانی (اصلی‌ترین هزینه، که با تعداد قطعه‌های ارسالی بیشتر می‌شود). به‌علاوه فضای ذخیره‌سازی در پایگاه داده. ارائه‌دهنده‌ی هوش مصنوعی این‌ها را به حساب خودتان می‌زند، پس یک سقف هزینه در داشبورد آن تنظیم کنید.

از ابزار ساخت اپلیکیشنتان چه بخواهید

• «قبل از ساختن RAG بررسی کن: آیا محتوای ما آنقدر کوچک است که بشود آن را مستقیم در پرامپت گذاشت؟»
• «مقاله‌های راهنما را به قطعه‌های چند پاراگرافی تقسیم کن، عنوان و لینک منبع هر قطعه را نگه دار، و embeddingها را در پایگاه داده‌ی ما ذخیره کن.»
• «از جستجوی ترکیبی استفاده کن، یعنی معنایی به‌علاوه‌ی کلیدواژه، تا کدهای محصول هم پیدا شوند.»
• «به مدل بگو فقط از منابع بازیابی‌شده جواب بدهد، بگوید وقتی نمی‌داند، و منابع را زیر هر پاسخ نشان دهد.»
• «فقط اسنادی را جستجو کن که کاربر واردشده اجازه‌ی دیدنشان را دارد.»
• «هر وقت سندی ویرایش شد، خودکار دوباره embed کن.»
• «کلید ارائه‌دهنده‌ی هوش مصنوعی را روی سرور و در یک secret نگه دار، نه در مرورگر.»
• «هر سؤال، قطعه‌های بازیابی‌شده و جواب را ثبت کن تا جواب‌های بد را بررسی کنم.»

RAG در Mythex

Mythex یک محصول آماده‌ی پایگاه دانش یا RAG ندارد. کاری که می‌کند این است که کدش را داخل اپلیکیشن شما می‌نویسد: اسنادتان و کلید ارائه‌دهنده‌ی هوش مصنوعی‌تان را می‌دهید، که به‌عنوان یک secret پروژه ذخیره می‌شود، و عامل بخش‌های بازیابی و چت را می‌سازد و از پایگاه داده‌ی Postgres پروژه برای ذخیره استفاده می‌کند. مصرف ارائه‌دهنده به حساب خود آن ارائه‌دهنده می‌رود، نه اعتبار Mythex. مستندات پیشنهاد می‌کنند با یک قابلیت ساده‌ی هوش مصنوعی شروع کنید و وقتی آن کار کرد RAG را اضافه کنید؛ به ساخت اپلیکیشن هوش مصنوعی مراجعه کنید، و راهنماهای ما درباره‌ی ساخت اپلیکیشن چت‌بات هوش مصنوعی و افزودن قابلیت‌های هوش مصنوعی به اپلیکیشن را ببینید.

پرسش‌ها