ارزیابی خطوط لوله RAG در برابر پنجره‌های زمینه میلیونی برای جستجوی سازمانی

کارایی یک سیستم هوش مصنوعی سازمانی دقیقاً در همان لحظه‌ای که کاربر دکمه اینتر را می‌زند، مشخص می‌شود؛ به‌طور خاص در طول محاسبه ماتریس توجه (attention matrix). وقتی از یک مدل زبانی خواسته می‌شود تا یک پیکره ۵۰۰,۰۰۰ کلمه‌ای را پردازش کند، مکانیزم توجه باید رابطه ریاضی بین تک‌تک کلمات را با تمام کلمات دیگر در آن متن محاسبه کند.

این مقیاس‌پذیری درجه دوم (quadratic scaling) همان جایی است که نتیجه کار — هم از نظر تاخیر و هم هزینه پردازش — واقعاً رقم می‌خورد و تعیین می‌کند که آیا برنامه شبیه یک موتور جستجوی سریع و چابک عمل می‌کند یا یک فرآیند دسته‌ای کند و پرهزینه.[1][2]

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

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

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

این سیستم متن را به امبدینگ‌های عددی (numerical embeddings) تبدیل کرده، فاصله بین پرس‌وجوی کاربر و اسناد ذخیره‌شده را محاسبه می‌کند و تنها نزدیک‌ترین تطابق‌ها را به مدل زبانی می‌فرستد. این کار، بار کاری مکانیزم توجه را به مجموعه کاملاً محدودی از توکن‌ها تقلیل داده و مشکل مقیاس‌پذیری درجه دوم را به کلی دور می‌زند.[3]

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

مدل‌های با زمینه طولانی این خط لوله را کاملاً حذف می‌کنند و یک راه‌حل بدون نیاز به راه‌اندازی ارائه می‌دهند که در آن متن خام به سادگی در API جای‌گذاری می‌شود. با این حال، آن‌ها تمام این بار را به فاز استنتاج منتقل می‌کنند، جایی که هر پرس‌وجو نیازمند پردازش کل سند از صفر است و حجم عظیمی از حافظه GPU را می‌بلعد.[4]

نرمال‌سازی هزینه‌ها در این دو رویکرد، اختلاف فاحشی را در اقتصاد واحد نشان می‌دهد. پردازش یک سند ۱ میلیون توکنی از طریق یک مدل پیشرفته، بسته به ارائه‌دهنده خاص و کوانتیزاسیون مدل، بین ۰.۵۰ تا ۲.۰۰ دلار به ازای هر پرس‌وجو هزینه دارد.

یک سیستم RAG که تنها ۴,۰۰۰ توکن بازیابی‌شده را همراه با پرامپت به مدل می‌فرستد، تقریباً ۰.۰۱ تا ۰.۰۵ دلار در هر پرس‌وجو هزینه برمی‌دارد. برای یک برنامه سازمانی که روزانه ده‌هزار پرس‌وجو را پردازش می‌کند، این تفاوت از یک هزینه عملیاتی ۵۰۰ دلاری در روز به یک قبض نجومی ۲۰,۰۰۰ دلاری می‌رسد.[2][3]

تاخیر نیز از منحنی مشابه و اجتناب‌ناپذیری پیروی می‌کند. زمان تا اولین توکن (TTFT) برای یک پنجره زمینه عظیم می‌تواند بین ۱۰ تا ۲۰ ثانیه طول بکشد، زیرا مدل در حال محاسبه ماتریس توجه در میان صدها هزار کلمه است. در مقابل، پایگاه‌های داده برداری قطعات مرتبط را در کسری از میلی‌ثانیه برمی‌گردانند.

از آنجا که مدل زبانی به جای یک رمان کامل، تنها باید چند پاراگراف را بخواند، می‌تواند استریم پاسخ را در کمتر از ۱.۵ ثانیه آغاز کند. در برنامه‌های کاربرمحور که کاربران رابط‌های کند را به سرعت رها می‌کنند، این شکاف ۱۵ ثانیه‌ای اغلب به معنای شکست کامل پروژه است.[2][3]

با این حال، خطوط لوله RAG در وظایف ترکیب و خلاصه‌سازی گسترده اساساً با شکست مواجه می‌شوند. اگر کاربری از مدل بخواهد «موضوعات مشترک در این ۴۰۰ گزارش حادثه را خلاصه کن»، یک جستجوی برداری نمی‌تواند هر ۴۰۰ گزارش را بدون تجاوز از محدودیت‌های قطعه‌بندی خود بازیابی کند.

این سیستم تنها پنج گزارش مرتبط‌تر را برمی‌گرداند و مدل را نسبت به ۳۹۵ گزارش دیگر کور نگه می‌دارد. مدل‌های با زمینه طولانی در اینجا می‌درخشند، زیرا کل مجموعه داده را در حافظه فعال خود نگه می‌دارند و می‌توانند ارتباطاتی را بین نقاط داده‌ای بسیار پراکنده پیدا کنند که یک جستجوی برداری هرگز آن‌ها را از نظر ریاضی مشابه تشخیص نمی‌دهد.[1]

با این وجود، قابلیت اطمینان این حافظه عظیم مطلق نیست. محققان در مطالعه «گمشده در وسط» (Lost in the Middle) در سال ۲۰۲۳ مشاهده کردند که «زمانی که اطلاعات مرتبط در وسط زمینه‌های طولانی قرار می‌گیرد، عملکرد به طور قابل‌توجهی افت می‌کند»، که این موضوع یک نقص پایدار در پنجره‌های حافظه عظیم را برجسته می‌کند.

مدل‌ها تمایل دارند به ابتدا و انتهای یک پرامپت وزن زیادی بدهند در حالی که از وسط آن سرسری می‌گذرند؛ این یعنی یک پنجره یک میلیون توکنی، یادآوری بی‌نقص یک میلیون توکن را تضمین نمی‌کند. حقایق حیاتی که در صفحه ۴۰۰ یک سند ۱,۰۰۰ صفحه‌ای دفن شده‌اند، اغلب دچار توهم (hallucination) شده یا به کلی نادیده گرفته می‌شوند.[1]

برای پر کردن این شکاف هزینه و تاخیر، ارائه‌دهندگان هوش مصنوعی مکانیزم‌های کش کردن پرامپت (prompt caching) را معرفی کرده‌اند. همان‌طور که مستندات مهندسی Anthropic اشاره می‌کند، «کش کردن پرامپت می‌تواند هزینه‌ها را تا ۹۰٪ و تاخیر را تا ۸۵٪ برای پرامپت‌های طولانی کاهش دهد.»

این امر معادلات را به نفع مدل‌های با زمینه طولانی تغییر می‌دهد و اجازه می‌دهد ماتریس توجه یک بار محاسبه شده و در RAM ذخیره شود. با این حال، این بهینه‌سازی تنها زمانی اعمال می‌شود که دقیقاً همان سند به طور مکرر در یک بازه زمانی کوتاه (معمولاً پنج تا ده دقیقه قبل از پاک شدن کش) مورد پرس‌وجو قرار گیرد.[2]

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

سیستم باید کل ماتریس را برای هر ترکیب منحصربه‌فرد از متون دوباره محاسبه کند، که این امر کاهش ۹۰ درصدی هزینه را از بین برده و جریمه تاخیر ۱۵ ثانیه‌ای را بازمی‌گرداند. بنابراین، معماران سازمانی باید قبل از تعهد به استراتژی کش، الگوهای پرس‌وجوی خود را به دقت بررسی کنند.[2][4]

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

در مقابل، خلاصه‌سازی یک انبار کاه بسیار پیچیده و یک‌باره، به حافظه خام یک پنجره زمینه طولانی نیاز دارد. برخورد با هر یک از این رویکردها به عنوان یک راه‌حل همه‌کاره، قطعاً به یک قبض ابری متورم یا سیستمی منجر می‌شود که توانایی پاسخگویی به سوالات پیچیده را ندارد.[4]