RAG جادو نیست، لوله‌کشی است

هر وقت یک RAG در پروداکشن خراب می‌شود، اولین واکنش تیم این است که مدل را عوض کند. مدل بزرگ‌تر، مدل تازه‌تر، مدل گران‌تر. تقریباً هیچ‌وقت جواب آنجا نیست.

RAG یک معماری هوشمند نیست؛ یک خط لوله است. متن را برمی‌داری، تکه‌تکه می‌کنی، در یک پایگاه برداری می‌ریزی، و موقع سؤال چند تکه‌ی مرتبط را بیرون می‌کشی و جلوی مدل می‌گذاری. کیفیت جواب نهایی، سقفش را همین لوله‌کشی تعیین می‌کند — نه مدل.

جایی که واقعاً خراب می‌شود

در عمل، تقریباً همه‌ی خطاها به یکی از این سه برمی‌گردند:

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

هیچ‌کدام از این‌ها را عوض‌کردن مدل حل نمی‌کند.

قبل از مدل، بازیابی را درست کن

یک تمرین ساده: بیست سؤال واقعیِ کاربر را بردار، برای هرکدام دستی بنویس کدام تکه‌ها باید بازیابی شوند، و بعد ببین سیستمت چند درصدشان را می‌آورد. این عدد — recall@k — قبل از این‌که مدل حتی یک کلمه بنویسد اندازه گرفته می‌شود.

اگر این عدد پایین است، هیچ مدلی نجاتت نمی‌دهد؛ چون اطلاعاتی که لازم است اصلاً جلوی مدل نمی‌رسد. اول این را بالا ببر، بعد سراغ مدل برو.

مدل فقط به‌اندازه‌ی بدترین تکه‌ای که جلویش می‌گذاری خوب است.

پس مدل کِی مهم می‌شود؟

وقتی که بازیابی‌ات درست است و باز هم جواب‌ها ضعیف‌اند. آن‌وقت واقعاً به استدلال قوی‌تر نیاز داری و ارتقای مدل منطقی است. ولی این نقطه معمولاً خیلی دیرتر از چیزی می‌رسد که فکر می‌کنیم.

RAG کسل‌کننده است، و همین خوب است. لوله‌کشیِ خوب دیده نمی‌شود؛ فقط کار می‌کند.