نمایه‌سازی افزایشی در RAG؛ به‌روزرسانی و حذف دانش بدون بازسازی کامل

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

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

مستندات Azure AI Search برای تغییر و حذف داده، سیاست‌های مشخصی معرفی می‌کند. جزئیات به منبع داده وابسته است. نباید صرفاً از موفق بودن اجرای نمایه‌ساز نتیجه گرفت که سندهای حذف‌شده نیز از نتایج پاک شده‌اند.

پیشنهاد اجرایی: دفتر وضعیت هر سند

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

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

حذف و جابه‌جایی را صریح طراحی کنید

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

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

برای ادامهٔ این بحث، مقالهٔ «چطور پاسخ هوش مصنوعی را به اسناد سازمان متصل کنیم؟» را در دانشنامهٔ لیان بخوانید.

آزمون عملی چرخه عمر

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

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

مثال گردش یک بخش‌نامه از ایجاد تا حذف

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

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

دفتر همگام‌سازی چه اطلاعاتی لازم دارد؟

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

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

تعویض نسخه بدون باقی ماندن قطعه‌های قدیمی

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

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

گزارش عملیاتی و رسیدگی به عقب‌ماندگی

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

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