شهریور
آموزش هوش مصنوعی
خط لولهٔ کامل RAG؛ از فایل خام تا جواب با ارجاع
وقتی میگویند «چتبات ما روی مستندات شرکت جواب میدهد»، پشت این جمله یک خط لولهٔ چندمرحلهای پنهان است که هر مرحلهاش میتواند کل کیفیت جواب نهایی را خراب یا نجات دهد. RAG (Retrieval-Augmented Generation) فقط «وصل کردن مدل زبانی به یک پایگاه دانش» نیست؛ زنجیرهای از تبدیلهاست که فایل خام PDF یا Word را به جوابی قابلاتکا و قابلارجاع تبدیل میکند. اگر قبلاً نقشهٔ راه ساخت چتبات تخصصی را خوانده باشید، این مقاله همان مرحلهٔ فنی RAG را با جزئیات باز میکند: ورودی و خروجی هر گام، و اینکه چرا حذف هرکدام هزینه دارد.
لیست مطالب
مرحلهٔ اول: دریافت و پاکسازی سند (Ingestion)
ورودی این مرحله فایل خام است؛ فرقی نمیکند PDF اسکنشده باشد، صفحهٔ HTML، فایل Word، یا خروجی یک API داخلی. خروجی، متن تمیز و ساختیافته است: عنوانها از بدنه جدا شدهاند، جدولها به شکلی قابلپردازش تبدیل شدهاند (نه فقط متن پراکنده)، و متادیتایی مثل نام فایل، تاریخ انتشار، و شمارهٔ نسخه به هر سند چسبیده است. اشتباه رایج اینجاست که تیمها فرض میکنند «استخراج متن» یعنی فقط pdftotext زدن؛ اما جدول قیمت یا مشخصات فنی که در یک ستون درهم میریزد، در مراحل بعدی هم درهم میماند و هیچ مدلی نمیتواند آن را درست بخواند.
مرحلهٔ دوم: تکهبندی (Chunking)
ورودی، متن تمیزشدهٔ مرحلهٔ قبل است؛ خروجی، تکههای (chunk) کوچکتر با همپوشانی کنترلشده است. اندازهٔ هر تکه باید هم برای embedding معنادار باشد و هم در پنجرهٔ context مدل جا شود. تکهبندی بر اساس تعداد کاراکتر خام معمولاً جمله یا پاراگراف را وسط قطع میکند؛ روش بهتر، تکهبندی بر اساس ساختار سند (عنوان، زیرعنوان، پاراگراف) است تا هر تکه یک واحد معنایی کامل بماند. هر تکه باید ارجاع خود را — نام سند، شمارهٔ صفحه یا بخش — همراه داشته باشد؛ این ارجاع همان چیزی است که در مرحلهٔ آخر به کاربر نشان داده میشود.
مرحلهٔ سوم: embedding و نمایهسازی
ورودی، تکههای متنی است؛ خروجی، بردارهای عددی است که در یک پایگاه برداری (vector store) ذخیره میشوند. هر تکه با یک مدل embedding به یک بردار چندبعدی تبدیل میشود که «معنای» آن را در فضای عددی نگه میدارد. نکتهٔ مهم این است که مدل embedding باید همان مدلی باشد که در زمان جستوجو هم استفاده میشود؛ تغییر مدل embedding بدون نمایهسازی مجدد کل پایگاه، جوابها را بیربط میکند. جستوجوی برداری بهتنهایی البته محدودیتهایی دارد که در مقالهٔ بعدی همین مجموعه به آن میپردازیم.
مرحلهٔ چهارم: بازیابی (Retrieval)
ورودی، سؤال کاربر است؛ خروجی، فهرستی از تکههای مرتبط از پایگاه دانش. سؤال کاربر هم به بردار تبدیل میشود و نزدیکترین تکهها از نظر شباهت معنایی برگردانده میشوند. تعداد تکههای بازیابیشده (معمولاً بین سه تا ده مورد) یک تنظیم حساس است: خیلی کم باشد، اطلاعات کافی برای جواب نیست؛ خیلی زیاد باشد، نویز وارد context میشود و مدل ممکن است بخش نامرتبط را برجسته کند.
مرحلهٔ پنجم: ساخت prompt و تولید جواب
ورودی، تکههای بازیابیشده بههمراه سؤال کاربر است؛ خروجی، متنی است که به مدل زبانی فرستاده میشود. اینجا قالب prompt تعیین میکند مدل چگونه از منابع استفاده کند: باید صریحاً گفته شود «فقط بر اساس متنهای زیر جواب بده، و اگر جواب در متن نیست بگو نمیدانم». بدون این دستور، مدل به دانش عمومی خودش برمیگردد و همان چیزی اتفاق میافتد که RAG قرار بود جلویش را بگیرد: جواب قانعکننده اما نادرست یا قدیمی.
مرحلهٔ ششم: ارجاع به منبع
ورودی، جواب تولیدشده بههمراه متادیتای تکههای استفادهشده است؛ خروجی، پاسخی است که کنارش میگوید «طبق سند X، بخش Y». این مرحله اختیاری نیست؛ دلیلش ساده است. مدل زبانی همیشه احتمال دارد چیزی را اشتباه بفهمد یا ترکیب کند (hallucination)، و تنها راهی که کاربر یا اپراتور میتواند جواب را راستیآزمایی کند، دیدن منبع دقیق آن است. در حوزههایی مثل مالی، حقوقی، یا پشتیبانی محصول، جوابی که ادعا میکند از سند رسمی آمده اما ارجاعش را نشان نمیدهد، عملاً غیرقابلاتکاست — حتی اگر محتوایش درست باشد. ارجاع همچنین ابزار دیباگ تیم فنی است: وقتی جوابی غلط از آب درآمد، اولین سؤال «کدام تکه از کدام سند باعث این جواب شد؟» است، و بدون لاگ ارجاع، پاسخ به این سؤال غیرممکن میشود.
| مرحله | ورودی | خروجی |
|---|---|---|
| دریافت و پاکسازی | فایل خام (PDF، Word، HTML) | متن ساختیافته با متادیتا |
| تکهبندی | متن تمیزشده | تکههای معنادار با ارجاع منبع |
| embedding و نمایهسازی | تکههای متنی | بردار عددی در vector store |
| بازیابی | سؤال کاربر | فهرست تکههای مرتبط |
| ساخت prompt و تولید | تکهها + سؤال | پاسخ خام مدل |
| ارجاع به منبع | پاسخ + متادیتای تکهها | پاسخ نهایی با لینک/نام سند |
بهروزرسانی و تازهنگهداشتن پایگاه دانش
یک نکته که در طراحی اولیهٔ خط لوله اغلب فراموش میشود این است که اسناد شرکت ثابت نمیمانند: قیمتها تغییر میکنند، سیاست بازگشت کالا اصلاح میشود، مشخصات فنی محصول جدید اضافه میشود. اگر خط لولهٔ ingestion فقط یکبار در زمان راهاندازی اجرا شود، بات بهمرور روی اطلاعات کهنه جواب میدهد و همین باعث افت اعتماد کاربر میشود، حتی اگر مکانیزم ارجاع درست کار کند. راهحل، یک فرایند بهروزرسانی دورهای است: هر سند باید شمارهٔ نسخه و تاریخ آخرین تغییر داشته باشد، و وقتی نسخهٔ جدید یک سند جایگزین میشود، تکههای قدیمی مرتبط با آن باید از نمایه حذف یا غیرفعال شوند، نه اینکه کنار نسخهٔ جدید در پایگاه برداری باقی بمانند و باعث ابهام در بازیابی شوند.
تست انتهابهانتهای خط لوله
چون هر مرحله ورودی و خروجی مشخصی دارد، میتوان و باید هر مرحله را جداگانه تست کرد: آیا استخراج متن جدول قیمت را درست خوانده؟ آیا تکهبندی وسط یک جملهٔ مهم را قطع نکرده؟ آیا بازیابی برای یک سؤال نمونه، سند درست را برمیگرداند؟ اما تست تکتکِ مراحل کافی نیست؛ باید یک مجموعه سؤال واقعی (نه ساختگی) از کاربران یا تیم پشتیبانی جمع کرد و کل خط لوله را از ابتدا تا جواب نهایی روی آنها اجرا کرد. تفاوت بین تست مرحلهای و تست انتهابهانتها این است که خطاهای تجمعی — مثلاً تکهبندی نه چندان بد بهعلاوهٔ بازیابی نه چندان دقیق — میتوانند در کنار هم یک جواب کاملاً نادرست بسازند، درحالیکه هر مرحله بهتنهایی «قابل قبول» به نظر میرسید.
یک خط لولهٔ RAG را نباید مثل یک جعبهٔ سیاه ساخت؛ هر مرحله باید قابل تست و قابل جایگزینی مستقل باشد.
جمعبندی
- کیفیت جواب نهایی به ضعیفترین مرحلهٔ خط لوله وابسته است، نه فقط به قدرت مدل زبانی.
- تکهبندی بر اساس ساختار سند، نه تعداد کاراکتر خام، انجام شود.
- مدل embedding زمان نمایهسازی و زمان جستوجو باید یکسان بماند.
- در prompt صریحاً از مدل بخواهید فقط بر اساس منابع بازیابیشده جواب دهد.
- ارجاع به منبع را حذف نکنید؛ هم اعتماد کاربر و هم توان دیباگ تیم فنی به آن وابسته است.
