حذف سند از RAG؛ چگونه جلوی بازگشت اطلاعات باطل‌شده را بگیریم؟

مسئول پشتیبانی، یک دستورالعمل اشتباه را از مخزن دانش حذف می‌کند؛ اما دستیار شرکت چند دقیقه بعد همان پاسخ قبلی را می‌دهد. فایل دیگر در فهرست نیست، ولی تکه‌ای از آن در نمایه، خلاصه یا پاسخ ذخیره‌شده باقی مانده است. حتی ممکن است پردازشی که پیش از حذف آغاز شده، خروجی خود را دیرتر بنویسد و سند را دوباره به جست‌وجو برگرداند.

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

حذف چه زمانی تمام شده است؟

پیش از پیاده‌سازی، سه زمان را جدا تعریف کنید: ثبت درخواست حذف، ممنوع شدن استفاده در پاسخ و تکمیل پاک‌سازی ذخیره‌ها. برای محصول، زمان دوم حیاتی است؛ برای تیم نگهداری، زمان سوم هم باید قابل مشاهده باشد. پیام رابط می‌تواند ابتدا «استفاده از سند متوقف شد؛ پاک‌سازی در جریان است» باشد و پس از کنترل همهٔ مقصدها تغییر کند.

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

در مستندات Points نیز وضعیت‌های acknowledged و completed تفکیک شده‌اند: دریافت درخواست با اتمام پردازش برابر نیست. بنابراین در گزارش حذف، شناسهٔ عملیات، نتیجهٔ نهایی و آزمون پس از آن را نگه دارید؛ صرفاً کد HTTP را ثبت نکنید. ۲

یک دفتر وضعیت، مرجع اعتبار سند باشد

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

جدول زیر حداقل اطلاعات پیشنهادی برای این سناریو را نشان می‌دهد؛ نام ستون‌ها نمونه‌اند.

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

ابطال و ثبت کار پاک‌سازی را یکپارچه کنید

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

این همان مسئلهٔ نوشتن دوگانه‌ای است که شرح رسمی الگوی Outbox در Debezium بررسی می‌کند. آن منبع در ۱۹ فوریهٔ ۲۰۱۹ منتشر شده است؛ الگوی مورد استفاده در اینجا قدیمی و شناخته‌شده است و به‌عنوان نوآوری تازهٔ RAG معرفی نمی‌شود. تطبیق آن با حذف سند، پیشنهاد معماری این مقاله است. ۳

برای شرکت کوچک‌تر، خواندن دوره‌ای جدول خروجی می‌تواند نقطهٔ شروع باشد؛ زیرساخت دارای ثبت تغییرات نیز می‌تواند از ابزار متناسب خود استفاده کند. مهم این است که رویداد از دست نرود، تلاش ناموفق ثبت شود و اجرای دوباره بی‌خطر باشد. انتخاب این الگو، الزام به افزودن Kafka یا Debezium به هر پروژه ایجاد نمی‌کند.

پردازش عقب‌مانده چگونه سند را برمی‌گرداند؟

سناریوی توضیحی را با یک دستورالعمل خدمات دنبال کنیم. نسل ۶ سند KB-42 در حال تولید بردار و پرسش مصنوعی است. مسئول محتوا آن را باطل می‌کند و دفتر وضعیت به نسل ۷ می‌رسد. پاک‌سازی تمام می‌شود؛ سپس کار نسل ۶ از صف بیرون می‌آید و خروجی خود را می‌نویسد. جست‌وجو دوباره چیزی برای یافتن دارد، هرچند حذف قبلاً موفق گزارش شده بود.

برای کنترل این وضعیت، مسیر نوشتن باید ترتیب عملیات هر سند را رعایت کند. یک راه، داشتن نویسندهٔ واحد برای کلید سازمان و سند است که پس از ثبت ابطال، کارهای نسل قدیمی را رد می‌کند. اگر چند نویسنده دارید، بررسی نسل و پذیرش نوشتن باید با سازوکار هماهنگی یا شرط معتبر در مقصد محافظت شود. خواندن وضعیت در ابتدای یک کار طولانی کافی نیست؛ ابطال می‌تواند حین پردازش رخ دهد.

در مستندات Outbox Event Router، شناسهٔ رویداد برای تشخیص پیام تکراری و کلید موجودیت برای حفظ ترتیب در پارتیشن‌های Kafka توضیح داده شده است. این امکانات، اجزای مفید طراحی‌اند؛ ترتیب صف به‌تنهایی همهٔ نوشتن‌های خارج از آن را کنترل نمی‌کند. ۴

همچنین تکرارپذیری عملیات با تشخیص پیام کهنه فرق دارد. Qdrant نوشتن دوباره با شناسهٔ یکسان را توضیح می‌دهد، اما همان نوشتن می‌تواند پس از حذف دوباره نقطه بسازد. مستندات دربارهٔ درج در به‌روزرسانی شرطیِ نقطهٔ ناموجود هم هشدار می‌دهند؛ شرط نسخه را بدون بررسی رفتار درج، کافی فرض نکنید. ۲

چهار نمایه را با یک شناسنامه پاک کنید

در الگوی چهار نمایهٔ RAGHUB، هر قطعه علاوه بر متن اصلی، زیرقطعه، پرسش مصنوعی و خلاصهٔ قابل جست‌وجو دارد. همهٔ این نماها باید سازمان، سند مادر و نسل را حمل کنند. در حذف، جست‌وجو روی نام فایل شکننده است؛ نام ممکن است عوض شود یا در دو سازمان یکسان باشد. دامنهٔ حذف را با همین شناسنامهٔ پایدار تعیین کنید.

فهرست مشتق‌ها را هنگام تولید ثبت کنید تا پاک‌سازی مجبور به حدس زدن نشود. علاوه بر چهار نما، متن استخراج‌شده، تصویر صفحه و هر خلاصهٔ مشترک باید در این فهرست تعیین تکلیف شوند. اگر خلاصه از چند سند ساخته شده، حذف یکی از آن‌ها می‌تواند بازتولید خلاصه از منابع باقی‌مانده را لازم کند؛ صرف برداشتن ارجاع، ادعای موجود در متن را اصلاح نمی‌کند.

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

در فاصلهٔ ابطال تا پاک‌سازی، پاسخ چه رفتاری دارد؟

مسیر پاسخ پیشنهادی، اعتبار نامزدهای بازیابی را پیش از فرستادن به مدل از دفتر وضعیت کنترل می‌کند. سند باطل‌شده یا نسل نامعتبر کنار گذاشته می‌شود و در صورت نیاز، نامزدهای بیشتری از منابع معتبر گرفته می‌شوند. وقتی دفتر وضعیت در دسترس نیست، برای این دامنهٔ حساس، پاسخ مستند را متوقف کنید؛ نبود امکان بررسی را معادل فعال بودن سند نگیرید.

تازگی همین بررسی هم مهم است. مستندات PostgreSQL توضیح می‌دهند که در Read Committed هر دستور نمایی از زمان آغاز خود می‌بیند، ولی Repeatable Read نمای تراکنش را حفظ می‌کند. تکرار یک خواندن در تراکنشی با نمای قدیمی الزاماً ابطال تازه را نمی‌بیند. مسیر بررسی را با سطح جداسازی و محل خواندن داده هماهنگ کنید. ۵

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

پاسخ ذخیره‌شده و نسخهٔ پشتیبان را فراموش نکنید

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

زمان انقضای کش، ساعت حذف سند نیست. مستند رسمی فرمان EXPIRE در مخزن Redis، حذف کلید پس از پایان مهلت را شرح می‌دهد؛ این مهلت از ابطال سند آگاه نیست. برای حذف فوریِ کاربردی، ابطال صریح یا بررسی وابستگی لازم است. ۶ خلاصهٔ گفت‌وگو و پاسخ قبلی نیز نباید بی‌بررسی به زمینهٔ درخواست بعدی برگردند.

نسخهٔ پشتیبان را با سیاست نگهداری جدا مدیریت کنید. آزمون بازگردانی باید نشان دهد پیش از باز شدن سرویس، ابطال‌های جدید دوباره اعمال می‌شوند. اگر پشتیبان قدیمی همراه با دفتر وضعیت قدیمی بالا بیاید، کنترل‌های سرویس زنده به‌تنهایی از بازگشت سند جلوگیری نمی‌کنند. در گزارش عملیات، «خارج از پاسخ‌گویی» و «پاک‌شده از همهٔ نسخه‌های نگهداری‌شده» دو وضعیت مستقل باشند.

یک تمرین حذف که خطاهای واقعی را آشکار کند

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

1. کار تولید مشتق را پس از خواندن سند متوقف نگه دارید؛ ابطال را ثبت کنید و مسیر عادی حذف را اجرا کنید.
2. همان سؤال و یک بازنویسی متفاوت را بپرسید؛ هم نامزدها و هم زمینهٔ واقعی مدل را بررسی کنید.
3. کار متوقف‌شده و یک رویداد تکراری را دوباره راه بیندازید؛ نسل قدیمی نباید قابل استفاده شود.
4. شکست یکی از مقصدهای پاک‌سازی را شبیه‌سازی کنید؛ وضعیت باید ناقص بماند و تلاش دوباره پیگیری شود.
5. کش و گفت‌وگوی قبلی را باز کنید و بازگردانی پشتیبان را در محیط جدا بیازمایید.

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

مرز تعهد محصول را قابل سنجش بنویسید

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

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