یادمه اولین باری که خواستم یه RAG بسازم، اصلاً چیزی شبیه این فصل رو نخوندم. مستقیم رفتم سراغ کد. یه کتابخونه نصب کردم، ده خط پایتون نوشتم، یه PDF دادم بهش، دمو کار کرد. ذوق هم کردم. بعد وقتی خواستم ببرمش پروداکشن و با دادهی واقعی همون شرکت پرش کنم، همهچیز پاشید. جوابها بیربط بودن، سرعت افتضاح بود، و من نمیدونستم از کدوم پیچ باید بگیرم. مشکل از کد نبود. مشکل این بود که نقشه نداشتم. داشتم بدون اینکه بدونم خونه قراره چند اتاق داشته باشه، آجر میچیدم.
فصل قبل فهمیدیم RAG چیه و چرا حتی با پنجرههای کانتکست میلیونتوکنی هنوز بهصرفهست. ولی دونستنِ اینکه RAG چیه، با فهمیدنِ اینکه چطور از دلش یه سیستم واقعی در میاد، دو تا چیز کاملاً متفاوته. قبل از اینکه یه خط کد دیگه بنویسیم، یه قدم عقب میایستیم و کل مسیر رو، از همون PDF کثیف سیاست مرجوعی تا جوابی که مشتری توی چت میبینه، بهصورت یه نقشهی واحد میکشیم. دقیقاً همون نقشهای که اگر اون روز داشتم، اون تیکت بحران اصلاً ساخته نمیشد.
تصویر ۱: معمار پیش از آنکه یک آجر بچیند، نقشه را باز میکند. ساختن RAG بدون دیدن کل معماری، دقیقاً همان اشتباهی است که من بار اول مرتکب شدم: آجر چیدن بدون نقشه.
پنج کلمهای که کل پایپلاین رو توصیف میکنن
هر پیادهسازی RAG، از سادهترین دموی دهخطی تا سنگینترین سیستم سازمانی، از همین پنج مرحله رد میشه. هیچ جادویی پشتش نیست:
Ingestion، یعنی دریافت. اسناد خام، یعنی همون PDF سیاست مرجوعی، صفحهی وب محصولات، یا ردیفهای دیتابیس، وارد سیستم میشن. هنوز هیچ هوشی در کار نیست، فقط آوردنِ داده از هر جا که هست به یه جای واحد.
Indexing، یعنی نمایهسازی. اون اسناد تکهتکه میشن، هر تکه تبدیل به یه بردار عددی میشه، و توی یه پایگاه دادهی قابلجستوجو ذخیره میشه. این همون مرحلهایه که دانش شما رو «قابل پیدا کردن» میکنه.
Retrieval، یعنی بازیابی. وقتی مشتری میپرسه «سیاست مرجوعی چیه»، سیستم میره توی اون پایگاه و مرتبطترین تکهها رو بیرون میکشه.
Augmentation، یعنی تزریق. اون تکهها توی پرامپت نهایی، درست کنار سوال کاربر، چیده میشن.
Generation، یعنی تولید. مدل، با سند واقعی جلوی چشمش، جواب رو مینویسه. دیگه حدس نمیزنه.
تصویر ۲: پایپلاین پنجمرحلهی RAG بهصورت یک نوار افقی. دو جعبهی نارنجی سمت چپ (Ingestion و Indexing) فاز آفلایناند و سه جعبهی فیروزهای سمت راست (Retrieval، Augmentation، Generation) فاز آنلاین؛ خطچین عمودی مرز این دو فاز است.
دو فاز، دو دنیای کاملاً متفاوت
اگه به دیاگرام بالا نگاه کنی، یه خطچین عمودی وسطش میبینی که پنج مرحله رو به دو گروه تقسیم میکنه. این خطچین فقط یه دستهبندی خوشگل روی کاغذ نیست؛ مستقیم روی تصمیمات مهندسیای که میگیری اثر میذاره، و فهمیدنش نصف راه فهمیدن کل RAGه.
دو مرحلهی اول، یعنی Ingestion و Indexing، یه گروه مستقل تشکیل میدن که بهش میگیم فاز آفلاین. سه مرحلهی بعدی، یعنی Retrieval، Augmentation و Generation، گروه دومن: فاز آنلاین.
فاز آفلاین، هزینهی یکبارهست. ایندکس کردن دههزار سند میتونه چند ساعت طول بکشه، و این مشکلی نیست، چون هیچ کاربری پشت خط منتظرش نیست. اینجا اولویت با صحت و کامل بودن دادهست، نه سرعت. هرچقدر بخوای میتونی وقت بذاری، مدل embedding قویتر بندازی، chunking رو دقیقتر تنظیم کنی، چون کسی عجله نداره.
فاز آنلاین، هزینهی هر کوئریه. هر میلیثانیهای که اینجا اضافه بشه، مستقیم روی تجربهی کاربر واقعی اثر میذاره. این همون جاییه که مشتری داره توی چتبات نگاش به صفحهی خالی دوخته شده و منتظره.
تصویر ۳: فضای برداری؛ هر نقطهی درخشان یک تکه از سند شماست که بهصورت بردار ذخیره شده، و نقطهی سفید وسط همان سوال کاربر است که با خط به نزدیکترین تکهها وصل میشود. وکتور استور، پلی است که فاز آفلاین را به فاز آنلاین وصل میکند.
تصویر ۴: بازنمایی برداری 2 سند و یک پرسجو که میزان شباهت آنها در فضای برداری مشخص است.
به همین خاطره که توی پروداکشن واقعی، تیمها معمولاً برای خودِ مرحلهی بازیابی یه بودجهی سختگیرانه، چیزی در حد چند صد میلیثانیه، در نظر میگیرن، تا کل مسیر رفتوبرگشت، یعنی بازیابی بهعلاوهی تولید، زیر ۲ تا ۳ ثانیه بمونه. جزئیات کامل این بودجهبندی، همراه با اعداد دقیقتر برای هر مرحله، توی فصل ۱۱ (بردن به پروداکشن) باز میشه؛ الان فقط لازمه بدونی این خطکش کجاست و چرا اون خطچین وسط دیاگرام اینقدر مهمه.
یه نکتهی دیگه هم هست که خیلیا اولش بهش فکر نمیکنن: این دو فاز چرخهی زمانی متفاوتی دارن. فاز آنلاین برای هر سوال کاربر، بارها و بارها در روز اجرا میشه. فاز آفلاین اما فقط وقتی اجرا میشه که دادهی جدیدی اضافه بشه یا سند قدیمی آپدیت بشه، و این خودش یه سوال باز میکنه: چند وقت یهبار باید دوباره ایندکس کنیم، و چطور بدون اینکه سرویس حتی یه لحظه قطع بشه این کار رو انجام بدیم؟ جواب کاملش رو توی فصل ۱۱ میبینیم، ولی خوبه از همین الان بدونی که «ایندکس کردن» یه رویداد یکباره نیست، یه فرآیند تکرارشوندهست. همونطور که مستندات شرکتت زندهست و عوض میشه، ایندکست هم باید زنده بمونه.
پس الان کجاییم؟
حالا نقشهی کلی رو جلومون داریم. میدونیم پنج مرحله چیه، میدونیم کدومهاشون قبل از رسیدن کاربر اجرا میشن و کدومهاشون موقع پرسش، و میدونیم چرا این تفکیک روی هر تصمیمی که از اینجا به بعد میگیریم اثر میذاره. از فصل بعد به بعد، هر فصل دقیقاً یه دونه از این جعبههای دیاگرام رو باز میکنه و تا تهش میره.
و اولین جعبهای که باز میکنیم، همونیه که ۶۰ درصد وقت یه پروژهی RAG واقعی صرفش میشه و تازهکارها تقریباً همیشه دستکم میگیرنش: تمیز کردن و آماده کردن اسناد کثیف دنیای واقعی، قبل از اینکه حتی فکر تبدیل شدن به بردار رو بکنن. فصل بعد، مستقیم میریم سراغ همون PDF سیاست مرجوعی و میبینیم چطور باید آمادهش کنیم که بعداً توی بازیابی به دردمون بخوره، نه به ضررمون.
دیدگاهتان را بنویسید