RAG دیگر قسمت سخت نیست؛ گردش کار اطرافش هنوز هست
بازیابی مهم است، ولی بیشتر محصول‌های ضعیف AI شکست می‌خورند چون گردش کار دورشان کم‌طراحی شده. تا مدتی جواب پیش‌فرض تقریباً هر «چطور AI اضافه کنیم» تولید تقویت‌شده با بازیابی بود. این یک مدت منطقی بود. نقطه کور تازه این شد که تیم بازیابی را خود محصول دانست نه یک ماده داخل سیستم بزرگ‌تر.
آنچه زیاد می‌بینم این است که لایه بازیابی اغلب قابل قبول است. مسئله جای دیگر است. درخواست مبهم است، رابط روشن نمی‌کند دستیار چه کاری از دستش برمی‌آید، خروجی برای اقدام ساخت‌یافته نیست، و وقتی مدل نامطمئن است مسیر جایگزین نیست. این طراحی گردش کار است، نه کیفیت جستجو.
بازیابی را ماده بدان نه خط پایان
وقتی دور RAG طراحی می‌کنم کمتر اهمیت می‌دهم که مدل بتواند یک قطعه را نقل کند و بیشتر اهمیت می‌دهم کاربر بعدش چه می‌تواند بکند. می‌تواند منبع را وارسی کند؟ می‌تواند روی جواب عمل کند؟ سیستم می‌تواند محدوده را تنگ کند، سؤال دنباله بپرسد، یا وقتی شواهد نازک است از حدس امتناع کند؟
این‌ها را embedding بهتر حل نمی‌کند. می‌توانی قطعه‌بندی، رتبه مجدد، و مدل بردار را مدت‌ها بهتر کنی و هنوز دستیاری داشته باشی که لیز حس می‌شود چون تجربه اطراف هرگز توجه کافی نگرفته.
از دید فول‌استک، قابلیت وقتی واقعی است که شکل اپ عوض شود. شاید مسیر همگام باید صف شود. شاید کار به گام قابل اعتماد کوچک‌تر بشکند. شاید مدل گران فقط جایی صدا زده شود که بازیابی چیزی برای گفتن دارد، نه روی هر بازدید صفحه.
شکل یک گردش کار قابل اعتماد
سؤال را قبل از بازیابی شکل بده. اگر محصول چند کار متفاوت را با یک جعبه متن قاطی کرده، مدل و جستجو هر دو حدس می‌زنند منظور کدام کار بوده. جستجو، بازیابی برای جواب، و مرور فهرست کار یکسان نیستند. اگر این سه را یک جعبه کرده‌ای، RAG تقصیر ناهماهنگی محصول را به دوش می‌کشد.
بعد از بازیابی، تصمیم صریح بگیر. اگر هیچ قطعه‌ای از آستانه رد نشد، جواب روان نساز. بگو چیزی پیدا نشد و بپرس کدام محدوده را تنگ کند یا کاربر را به مسیر غیرمدلی برگردان. اگر قطعه هست، جواب را به همان‌ها مقید کن و منبع را جایی نشان بده که کاربر بدون باز کردن trace داخلی ببیند.
خروجی را برای اقدام ساخت‌یافته کن وقتی اقدام وجود دارد. پیش‌نویس تیکت، فهرست گام، یا فرم پرشده با اعتبار schema مفیدتر از پاراگراف است که انسان باید دوباره تفسیر کند. اعتبار را اپ انجام دهد. اگر JSON با قرارداد نخواند، آن را به کاربر به‌عنوان حقیقت نشان نده.
مسیر گران را جدا کن. بازیابی و جواب کوتاه می‌توانند تعاملی بمانند. خلاصه بلند یا کاری که چند منبع را تلفیق می‌کند می‌تواند پس‌زمینه باشد با وضعیت قابل دیدن. استریم را برای جهت کاربر بگذار، نه برای اینکه انتظار را قایم کنی.
عملیاتی که آموزش‌ها جا می‌اندازند
تأخیر، شکست، و هزینه را به تفکیک همین گردش کار ببین نه یک شمارنده سراسری. بدون این نمی‌فهمی تغییر رتبه مجدد محصول را بهتر کرده یا فقط دمو را شلوغ‌تر. تعداد بازیابی صفر، تعداد امتناع، و تعداد جوابی که کاربر منبعش را باز کرده از نمره شباهت متوسط مفیدترند.
کش را فقط جایی بگذار که سؤال و مجموعه سند پایدارند و می‌دانی با ویرایش سند چه چیزی باطل می‌شود. کش جواب بدون داستان باطل‌سازی، جواب دیروز را با اعتماد امروز نشان می‌دهد.
مجوز را قبل از بازیابی اعمال کن نه بعد از تولید. اگر قطعه سند خصوصی وارد پرامپت شد، redact کردن جواب دیر است. فیلتر مجموعه با هویت کاربر بخشی از گردش کار است، نه افزونه امنیتی آخر.
وقتی نامطمئنی، دست‌به‌دست انسان را طراحی کن. بازبین باید منبع، سؤال، و خروجی پیشنهادی را با هم ببیند. رونوشت مدل به‌تنهایی برای پشتیبانی کافی نیست.
اشتباه‌ها
فکر کردن که بازیابی بهتر محصول بدون شکل عملیاتی را نجات می‌دهد. فرض اینکه مدل یا ایندکس تازه معماری دور آن را خودکار بهتر می‌کند. اگر کسی نمی‌تواند بگوید صدای گران کجا است، ابزار تازه راه سریع‌تر به‌هم‌ریختگی است.
و نادیده گرفتن تکه‌های کسل اعتماد: حالت خطا، زمان پاسخ، retry که کار دارای اثر را دوباره نزند، و مرز بین حدس مدل و داده تأییدشده. کاربر این‌ها را بیشتر از اسم الگوریتم بردار حس می‌کند.
ساخت پلتفرم RAG عمومی قبل از یک گردش کار تیز هم همان اشتباه همیشگی است. اول یک کار را تا حد «به اندازه کافی خوب» ببر با قرارداد خروجی روشن. تعمیم را وقتی درد تکرار شد دربیاور.
این هفته
یک گردش کار موجود را انتخاب کن که امروز به نقل قول قطعه تمام می‌شود و کاربر نمی‌داند بعدش چه کند. مرز کار را تنگ کن. امتناع وقتی شواهد نازک است را بنویس. منبع را در UI نشان بده. اعتبار خروجی را قبل از اقدام پایین‌دست بگذار. دید تأخیر و شکست و هزینه را اضافه کن.
بازیابی خوب مهم است و به‌ندرت خط پایان است. محصولی قابل اعتماد حس می‌شود که بازیابی، طراحی تعامل، و منطق اپ با هم کار می‌کنند به‌جای اینکه نوبتی مقصر باشند.
قطعه را به اقدام وصل کن
یک قطعه بازیابی‌شده به‌خودی‌خود تمام محصول نیست. کنار جواب بگو این منبع کدام تصمیم را پشتیبانی می‌کند و کدام را نه. اگر سند فقط سیاست کلی است، از آن قیمت حساب را نساز. اگر سند وضعیت یک سفارش است، از آن قاعده عمومی اختراع نکن. این تفکیک را در پرامپت تنها رها نکن. در شکل خروجی فیلدی بگذار که نوع استفاده مجاز را بگوید، و رابط همان را نشان دهد.
وقتی این فیلد نباشد، کاربر و مدل هر دو بیش از سند نتیجه می‌گیرند. بازیابی درست بوده و گردش کار دروغ گفته. این همان جایی است که بهتر کردن embedding هیچ علامتی در تیکت پشتیبانی عوض نمی‌کند.
پرسش‌های کوتاه
**پس روی کیفیت قطعه وقت نگذارم؟** بگذار، بعد از اینکه می‌دانی شکست فعلی از قطعه غلط است نه از سؤال مبهم یا نبود امتناع. اول چند مورد واقعی را نگاه کن.
**اگر کاربر جواب بدون منبع خواست؟** برای کار کم‌ریسک شاید بشود. برای سیاست، قیمت، یا وضعیت حساب، جواب بی‌منبع را نشان نده.
**RAG را با ایجنت عوض کنم؟** فقط اگر کار به ابزار و حالت نیاز دارد. عوض کردن اسم، طراحی گردش کار را حذف نمی‌کند.