خط لوله RAG شما یک تست بار استاندارد را با موفقیت کامل پشت سر میگذارد. تأخیر p95 سالم به نظر میرسد. نرخ خطاها نزدیک به صفر است. با این حال، کاربران از پاسخهایی شکایت دارند که از پرسش طفره میروند، به اسنادی استناد میکنند که وجود ندارند، یا پاراگرافهای بیربطی را از یک سند فنی که شش ماه پیش آپلود شده، بیرون میکشند. داشبورد میگوید همه چیز خوب است، اما تجربه کاربری میگوید سیستم خراب است.
این عدم تطابق به این دلیل وجود دارد که تستهای عملکرد سنتی برای سیستمهای درخواست-پاسخ ساخته شدهاند، نه برای سیستمهایی که «فکر میکنند». وقتی هزار درخواست موازی را به یک نقطه پایانی (endpoint) REST میفرستید، متوجه میشوید که آیا سرورهای شما پایداری میکنند یا خیر. اما هیچ چیز درباره این نمیفهمید که آیا لایه بازیابی شما تکههای درست را استخراج میکند، آیا قالب پرامپت شما بافت (context) را حفظ میکند، یا اینکه وقتی ذخیرهساز برداری (vector store) خالی است، مدل از منابع خیالی استفاده میکند یا خیر. تست بار استاندارد، سرعت را میسنجد؛ اما برنامههای RAG از شما میخواهند که «درک» را بسنجید.
فراتر از کد وضعیت ۲۰۰
یک تست بار معمولی API سه مورد را بررسی میکند: در دسترس بودن، تأخیر و توان عملیاتی. این تست میپرسد که آیا سرور پاسخ داده است، چقدر طول کشیده و از پس چند کاربر همزمان برآمده است. برای یک برنامه RAG، این اعداد پیشنیاز هستند، نه نتیجه نهایی. یک پاسخ اشتباهِ سریع، همچنان یک پاسخ اشتباه است و پاسخهای اشتباه در مقیاس بالا، هزینهای بیشتر از پاسخهای کند دارند.
RAG دو مرحله متمایز به هر درخواست اضافه میکند. اول، سیستم سوال کاربر را به یک امبدینگ (embedding) تبدیل میکند، از یک ذخیرهساز برداری پرسوجو میکند و مجموعهای از تکههای بافت (context chunks) را بازمیگرداند. دوم، آن تکهها را در یک پرامپت میریزد، همه چیز را به یک مدل زبانی میفرستد و پاسخ را به صورت استریم (stream) بازمیگرداند. تستهای سنتی اغلب این مراحل را در یک معیار واحد به نام «زمان پاسخگویی» ادغام میکنند. آنها موتور بازیابی و مولد (generator) را به عنوان یک جعبه سیاه واحد در نظر میگیرند.
شما باید آن جعبه را باز کنید. اگر پایگاه داده برداری شما تحت بار کند شود، تأخیر بازیابی بالا میرود. مدل زبانی (LLM) ممکن است همچنان سریع پاسخ دهد، اما بر اساس بافتهای بیارزشی که با عجله بازیابی شدهاند، پاسخ میدهد. از سوی دیگر، جستجوی برداری میتواند سریع باقی بماند در حالی که صف LLM پر میشود و زمان تا اولین توکن (time-to-first-token) افزایش مییابد تا جایی که کاربران به یک نشانگر چشمکزن خیره میشوند. یک تایمر واحد برای کل فرآیند (end-to-end)، هر دو نوع شکست را پنهان میکند.
بازیابی را تست کنید، نه فقط پایگاه داده را
اکثر تیمها یک بنچمارک سریع برای جستجوی برداری اجرا میکنند و تصور میکنند لایه بازیابی تست شده است. آن بنچمارک معمولاً اندازهگیری میکند که پایگاه داده با چه سرعتی نزدیکترین همسایگان را برای یک پرسوجوی از پیش انتخاب شده بازمیگرداند. این تست به ندرت بررسی میکند که آیا آن همسایگان واقعاً حاوی پاسخ هستند یا خیر.
کیفیت بازیابی با تغییر بار، به روشهای ظریفی تغییر میکند. تحت فشار درخواستهای همزمان، ایندکسهای نزدیکترین همسایه تقریبی (ANN) میتوانند رفتاری متفاوت از حالت ایزوله داشته باشند. استراتژیهای تکهبندی (chunking) که در یک نوتبوک عالی به نظر میرسیدند، زمانی که ده هزار سند برای فضای امبدینگ یکسان رقابت میکنند، شروع به از دست دادن بافت در مرزها میکنند. پرسوجویی که در یک محیط آرام پاراگراف ایدهآل را برمیگرداند، ممکن است زمانی که ایندکس در حال بازسازی است یا زمانی که فیلتر کردن متادیتا تحت فشار درخواستها حذف میشود، یک اسلاید بازاریابی گمراهکننده را نمایش دهد.
برای تست صحیح این موضوع، به یک مجموعه داده مرجع (ground-truth) نیاز دارید. سوالاتی را انتخاب کنید که از قبل میدانید کدام اسناد منبع باید ظاهر شوند. آن سوالات را در سطوح مختلف همزمانی اجرا کنید و بررسی کنید که آیا تکههای مورد انتظار در نتایج top-k قرار میگیرند یا خیر. نرخ موفقیت (hit rate) را دنبال کنید، نه فقط مدت زمان پرسوجو را. اگر پنج تکه اول شما کلاً منبع حیاتی را از دست بدهند، خط لوله بازیابی شما حتی قبل از اینکه LLM بیدار شود، شکست خورده است.
همچنین باید حالتهای مرزی را تحت تست فشار قرار دهید. پرسوجوهایی را ارسال کنید که هیچ پاسخی در مجموعه داده ندارند. سوالات مبهمی را بفرستید که میتوانند به چندین حوزه مرتبط باشند. سوالات طولانیای را ارسال کنید که از محدودیت توکن مدل امبدینگ شما فراتر میروند و بیصدا قطع میشوند. مشاهده کنید که لایه بازیابی چه چیزی را برمیگرداند. در هر مورد، حالت شکست مهمتر از میلیثانیههای سپری شده است.
وقتی مدل بیصدا از کار میافتد
وقتی تکهها به LLM میرسند، تست بار استاندارد همچنان در حال دروغ گفتن است