چطور ۶۸٪ کانتکست RAG رو دور بندازیم
هوش مصنوعیخلاصهٔ کاملتر
شرکت Kapa دستیارهای هوش مصنوعی میسازه که به سؤالهای پیچیده روی پایگاههای دانش بزرگ جواب میدن؛ داکیومنت فنی، رفرنس API، فرومها و تردهای پشتیبانی. نویسنده میگه تو این حوزه هنوز هیچی به RAG نمیرسه، و ساختار همهشون یکیه: یه retriever که تیکههای مرتبط رو پیدا میکنه و یه generator (همون مدل زبانی گرون) که جواب رو ازشون مینویسه.
مشکل اینه که generator بابت هر تیکهای که میخونه پول میگیره، حتی اونایی که نادیده میگیره. به گفتهٔ نویسنده تیکههای بازیابیشده حدود دوسوم هزینهٔ هر کوئری رو میسازن، بیشتر از خود جواب و تاریخچهٔ گفتگو و پرامپت سیستمی روی هم. هر تیکهٔ کمتر، حدود ۴٪ از هزینه رو کم میکنه، ولی خطرش recall هست: اگه تیکهای که جواب لازمش داشت رو بندازی بیرون، جواب غلط میدی.
راهحل بدیهی یعنی برش زدن روی امتیاز reranker جواب نمیده. نویسنده میگه امتیاز rerank یه ترتیبه، نه یه اندازهگیری، و بین کوئریهای مختلف کالیبره نیست، پس هیچ آستانهٔ ثابتی کار نمیکنه. مهمتر اینکه ربطداشتن، خاصیت یه تیکهٔ تنها نیست؛ rerankerهای pointwise هر تیکه رو جدا امتیاز میدن و نمیبینن که یه تیکه فقط کنار یه تیکهٔ دیگه معنی میده و نصف جواب توشه.
روش anchor documents رو هم امتحان کردن: کاشتن تیکههای مصنوعی با ربط مشخص توی رتبهبندی تا مقیاس مطلق بشه. این هم به همون دلیل شکست خورد؛ reranker بازم تیکههای نیمهمرتبط رو زیر تیکههای کاملاً بیربط میذاشت. درس این شکست این بود که هرچی قراره هرس کنه، باید سؤال و همهٔ تیکهها رو با هم ببینه، چون چیزی که قضاوت میشه یه مجموعهست.
چیزی که در نهایت ساختن یه فراخوانی listwise با یه مدل زبانی کوچیکه که بین reranker و generator قرار میگیره. این مدل سؤال و همهٔ تیکهها رو میگیره و هر تیکه رو روی یه مقیاس پنجسطحی که تو پرامپتش تعریف شده نمره میده. چون هر سطح با کلمات تعریف شده، آستانهٔ ثابت بالاخره کار میکنه. دو تا اهرم دیگه هم مهمه: خود آستانه (تعادل بین فشردهسازی و recall) و keep-top-k که چند تیکهٔ برتر رو بیتوجه به نمره نگه میداره تا از اشتباه نمرهدهی محافظت بشن.
نویسنده میگه مدل باید کوچیک و ارزون باشه چون هزینهش باید از صرفهجوییِ خودش دربیاد؛ مدلهای flagship از اول رد شدن. تو نقطهای که انتخاب کردن، حدود ۹۶٪ recall حفظ میشه و حدود ۶۸٪ تیکهها دور ریخته میشه، یعنی از هر ۲۵ سؤال یکی یه تیکه رو از دست میده ولی صورتحساب هر کوئری حدود ۳۴٪ کم میشه.
هزینهش یه تأخیر کوچیک و ثابته؛ روی تنظیماتی که فرستادن حدود ۰٫۷ ثانیه به هر کوئری اضافه میشه. نویسنده میگه اول این قابلیت رو جایی روشن کردن که بازیابی یکی از چند ابزاره: ایجنتهایی که مشتریها روی retrieval میسازن. اونجا خروجیِ سبکتر برای بقیهٔ ابزارها جا باز میکنه و از دسترفتن recall هم کمخطرتره، چون ایجنت میتونه دوباره سرچ کنه.
نکات کلیدی:
- تیکههای بازیابیشده حدود دوسوم هزینهٔ هر کوئری RAG رو میسازن، حتی اونایی که مدل نادیده میگیره.
- برشزدن روی امتیاز reranker جواب نمیده، چون امتیاز ترتیبیه و ربط، خاصیتِ یه مجموعه از تیکههاست نه یه تیکهٔ تنها.
- یه مدل زبانی کوچیک با فراخوانی listwise سؤال و همهٔ تیکهها رو با هم میبینه و روی یه مقیاس پنجسطحی نمره میده.
- تنظیمات نهایی: ۹۶٪ recall، حذف ۶۸٪ تیکهها و کاهش ۳۴٪ هزینهٔ هر کوئری.
- بهاش یه تأخیر ثابت زیر یک ثانیهست که تو ایجنتها ناچیزه ولی تو مسیر تکمرحلهای باید سبکسنگین بشه.
