RAG زمان‌مند؛ پاسخ درست از کدام نسخهٔ آیین‌نامه؟

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

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

پیش از جست‌وجو، معنای سؤال زمانی را مشخص کنید

سه درخواست ظاهراً نزدیک، پاسخ یکسانی نمی‌خواهند. «اکنون مهلت گزارش چقدر است؟» به قاعدهٔ جاری مربوط می‌شود. «برای مأموریت پنجم اکتبر، با اطلاعات امروز چه مهلتی معتبر است؟» رویداد گذشته را با دانسته‌های فعلی بررسی می‌کند. اما «سامانه در ششم اکتبر برای همان مأموریت چه قاعده‌ای در اختیار داشت؟» بازسازی دانش ثبت‌شده در گذشته است.

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

عبارت‌هایی مانند «ماه قبل» را با تاریخ و منطقهٔ زمانی درخواست به بازهٔ مشخص تبدیل کنید. اگر دو تاریخ در سؤال آمده، پیش از بازیابی تعیین کنید کدام‌یک موضوع قاعده است. پرسش کوتاهِ «منظورتان تاریخ پایان مأموریت است؟» گاهی از جست‌وجوی گسترده‌تر مفیدتر است؛ چون اطلاعات مفقود را هیچ رتبه‌بندی‌ای تولید نمی‌کند.

پژوهش مرتبط چه چیزی را پشتیبانی می‌کند؟

مقالهٔ «TimelyRAG: Semantic-Temporal Hybrid Retrieval for Time-Critical Question Answering in Overlapping-Evolving Documents» با شناسهٔ arXiv:2609.11572v1 در ۱۰ سپتامبر ۲۰۲۶ منتشر شده است. روش آن، نامزدهای بازیابی اولیه را با ترکیب ارتباط معنایی و سازگاری زمانی دوباره رتبه‌بندی می‌کند. نسخه‌های نزدیک از نظر متن، ممکن است به‌علت اصلاح یک بند برای سؤال زمانی یکسان معتبر نباشند. ۱

در خواندن نتیجه، دامنهٔ آزمایش را حفظ کنید: مجموعهٔ اصلی، ساختگی و به زبان کره‌ای است و در حوزه‌هایی مانند سیاست شرکت و مقررات دانشگاه ساخته شده؛ شاهد مستقلی برای کیفیت فارسی نیست. این روش سند غایب از نامزدهای اولیه را نیز برنمی‌گرداند. بنابراین، پژوهش مبنایی برای آزمودن نقش زمان است؛ قرارداد اجرایی زیر پیشنهاد طراحی این مقاله است و پیاده‌سازی یا تضمین عملکرد TimelyRAG محسوب نمی‌شود. ۱

دو محور زمان را در دفتر اعتبار نگه دارید

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

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

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

پروندهٔ توضیحی: اصلاحیه‌ای که دیرتر از تاریخ اجرای خود می‌رسد

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

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

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

اعتبار را به بند وصل کنید، سپس چهار نمایه را هماهنگ کنید

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

شناسهٔ بند باید از شمارهٔ ظاهری آن مستقل باشد. اگر بند ۷ در ویرایش بعد به بند ۹ منتقل شد، رابطهٔ معنایی و سابقهٔ اصلاح نباید قطع شود. تقسیم یک بند به دو بند یا ادغام چند بند، نیازمند ثبت رابطهٔ روشن و بازبینی مالک محتواست. شباهت متن می‌تواند نامزد تطبیق پیشنهاد دهد؛ تصمیم نهایی دربارهٔ دامنهٔ اعتبار را از آن استنتاج نکنید.

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

مسیر پاسخ را به پنج تصمیم قابل بررسی تبدیل کنید

1. درخواست را ببندید. تاریخ پایان مأموریت، دامنهٔ کارکنان و حالت زمانی را مشخص کنید. ورودی نهایی باید میان «بررسی با دانش امروز» و «بازسازی دانش ثبت‌شده در گذشته» تفاوت بگذارد. ابهام حل‌نشده را به یک تاریخ حدسی تبدیل نکنید.

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

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

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

5. پاسخ را با مبنای زمانی نمایش دهید. پاسخ پیشنهادی این تمرین می‌گوید: «برای پایان مأموریت در ۵ اکتبر، بر اساس اصلاحیهٔ ثبت‌شده در ۱۰ اکتبر، مهلت هفت روز تقویمی است.» کنار آن، بند و نسخهٔ قابل بازکردن و حالت زمانی قرار می‌گیرد. محاسبهٔ آخرین روز مجاز، به قرارداد جداگانهٔ شمارش روزها نیاز دارد؛ آن را از روی عبارت مبهم حدس نزنید.

اگر دو بند هم‌زمان معتبر به نظر برسند چه کنیم؟

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

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

آزمون پذیرش را حول جابه‌جایی زمان بسازید

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

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

مرز توان سامانه و نخستین تحویل

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

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

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