پس از چهار ماه تلاش برای انتقال یک خط لوله RAG از یک Jupyter notebook به یک سرویس زنده، نویسنده پنج انتخاب ملموس را شناسایی کرد که یک دموی نمایشی را به سیستمی تبدیل کرد که کاربران واقعاً می‌توانند به آن تکیه کنند. تفاوت در اعداد مشهود است: یک تغییر ساده در نحوه تقسیم متن، نرخ موفقیت بازیابی را از ۶۱٪ به ۸۳٪ افزایش داد و یک مجموعه ارزیابی کوچک شامل ۲۰۰ پرسش واقعی، اکنون اکثر پسرفت‌ها را پیش از رسیدن به مشتریان شناسایی می‌کند.

چرا این موضوع اهمیت دارد

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

۱. از تکه‌بندی با اندازه ثابت دست بکشید

بسیاری از نمونه‌های اولیه هر سند را به بلوک‌های ۵۱۲ توکنی تقسیم می‌کنند. این روش برای متن‌های کوتاه جواب می‌دهد اما دفترچه‌های راهنمای فنی، رشته‌های پشتیبانی و قطعه‌کدهای برنامه‌نویسی را از هم می‌پاشد. جملات شکسته می‌شوند، عناوین ناپدید می‌شوند و موتور بازیابی نمی‌تواند زمینه‌ای را که کاربر انتظار دارد، مطابقت دهد.

به تکه‌بندی آگاه از ساختار (structure-aware chunking) – یعنی تقسیم در محل عناوین، مرزهای گفتگو یا محدوده‌های کد (code fences) – روی بیاورید تا واحدهای معنایی حفظ شوند. در سیستم نویسنده، این کار به تنهایی نسبت پرسش‌هایی که یک بخش مرتبط را پیدا می‌کردند از ۶۱٪ به ۸۳٪ افزایش داد. این بهبود از تغییر در فرمت داده‌ها حاصل شده است؛ مدل زیربنایی همان مدل قبلی باقی مانده است.

۲. از جستجوی ترکیبی استفاده کنید

جستجوی برداری خالص (شباهت مبتنی بر embedding) در یافتن بخش‌هایی با معنای مشابه عالی عمل می‌کند، اما در مواجهه با شناسه‌های دقیق مانند کدهای خطا، شماره نسخه‌ها یا اصطلاحات اختصاصی دچار مشکل می‌شود. کاربری که به دنبال یک کد خطا مانند “ERR-XXXX” است، ممکن است پاراگرافی با معنای مشابه دریافت کند که اصلاً حاوی آن کد نباشد.

جستجوی ترکیبی، یک شاخص برداری متراکم (dense vector index) را با یک شاخص سنتی BM25 (مبتنی بر فراوانی کلمات) ترکیب می‌کند. با وزن‌دهی به این دو امتیاز، سیستم مواردی را بازیابی می‌کند که هم از نظر معنایی نزدیک هستند و هم حاوی کلمات دقیقی هستند که کاربر تایپ کرده است. برای محیط عملیاتی، جستجوی ترکیبی یک نیاز اساسی است، نه یک قابلیت اضافی و اختیاری.

۳. با داده‌های قدیمی مقابله کنید

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

  • هر سند را با یک برچسب نسخه یا مهر زمانی (timestamp) علامت‌گذاری کنید.
  • در طول امتیازدهی، یک امتیاز تشویقی برای تازگی (recency boost) اعمال کنید تا موارد جدیدتر رتبه بالاتری نسبت به نسخه‌های قدیمی‌تر بگیرند.
  • بازسازی شاخص را به‌صورت افزایشی و شبانه اجرا کنید تا تغییرات سیستم‌های منبع را دریافت کند.

این اقدامات حفاظتی از ارائه قیمتی که در فصل گذشته معتبر بوده یا سیاستی که قبلاً جایگزین شده است، جلوگیری می‌کند.

۴. به‌جای ارتقای مدل‌ها، از بازرتبه‌سازی استفاده کنید

ارتقای یک مدل embedding تنها بهبود اندکی در کیفیت ایجاد می‌کند، در حالی که افزودن یک بازرتبه‌ساز cross-encoder جهش بسیار بزرگتری با هزینه کمتر ایجاد می‌کند.

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

۵. یک مجموعه ارزیابی واقعی بسازید

شما نمی‌توانید چیزی را که اندازه نمی‌گیرید، بهبود دهید. نویسنده یک مجموعه تست شامل ۲۰۰ پرسش واقعی کاربران را گردآوری کرد که هر کدام با یک پاسخ متخصصانه جفت شده است. هر تغییر در کد در برابر این مجموعه اجرا می‌شود؛ هرگونه پسرفت (regression) پیش از استقرار شناسایی می‌شود.

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

خط لوله عملیاتی در عمل

  • Ingest (دریافت): تکه‌بندی آگاه از ساختار، عناوین، بلوک‌های کد و مراحل گفتگو را حفظ می‌کند.
  • Index (شاخص‌سازی): هم امبدینگ‌های متراکم و هم آمار کلمات BM25 را ذخیره می‌کند.
  • Retrieve (بازیابی): جستجوی ترکیبی ۲۰ کاندیدا را برمی‌گرداند که بین شباهت معنایی و مطابقت دقیق کلمات تعادل برقرار می‌کند.
  • Rerank (بازرتبه‌سازی): یک cross-encoder لیست را به پنج بخش امیدوارکننده محدود می‌کند.
  • Generate (تولید): مدل LLM این تکه‌های برتر را به همراه متادیتای آن‌ها دریافت می‌کند تا پاسخ نهایی را بسازد.
  • Evaluate (ارزیابی): هر پاسخ ثبت می‌شود؛ شکست‌ها دوباره به مجموعه تست ۲۰۰ پرسشی بازگردانده می‌شوند.

پیامدها و موازنه ها

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

موضوعات بعدی برای بررسی

با تکامل امبدینگ‌های متن‌باز و پایگاه‌های داده برداری، مرز بین بازیابی «متراکم» (dense) و «پراکنده» (sparse) کمرنگ خواهد شد، اما اصلِ ترکیبِ تطبیق معنایی و دقیق همچنان پابرجا باقی می‌ماند.

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