پاسخ‌گوی سازمانی ممکن است از نظر زبان روان باشد و همچنان از آخرین نسخهٔ دانش سازمان عقب بماند. تصور کنید زمان ارائهٔ یک خدمت تغییر کرده است، اما سامانه هنوز ساعت قبلی را به تماس‌گیرنده می‌گوید. در چنین وضعیتی، تعویض مدل الزاماً مشکل را حل نمی‌کند؛ باید روشن شود سند معتبر کدام است، چه زمانی وارد نمایه شده و پاسخ به کدام نسخه تکیه داشته است. این راهنما یک روش پیشنهادی برای مدیریت چرخهٔ عمر سند در سامانهٔ RAG ارائه می‌کند. مثال‌ها فرضی‌اند و گزارش عملکرد محصول یا مشتری مشخصی نیستند.
هدف این روش، ساختن ارتباط قابل بررسی میان سند، نمایه و پاسخ است. تیم باید بتواند دربارهٔ هر پاسخ مهم بپرسد: اطلاعات از کجا آمده، آیا در زمان درخواست معتبر بوده و بعد از تغییر سند چگونه دوباره آزموده شده است؟ این پرسش‌ها از انتخاب یک ابزار خاص مستقل‌اند و می‌توان آن‌ها را در یک نمونهٔ کوچک هم به کار برد.
۱. مرجع معتبر و نسخهٔ فعال را مشخص کنید
برای شروع، فهرست منابع را از فهرست فایل‌ها جدا کنید. یک موضوع سازمانی ممکن است چند فایل داشته باشد، اما باید صاحب و مرجع تصمیم روشن داشته باشد. برای مثال فرضی «ساعت ارائهٔ خدمت»، واحد مسئول باید تعیین کند کدام اطلاعیه معتبر است و از چه تاریخی اجرا می‌شود. اگر دو سند هم‌زمان پاسخ‌های متفاوت دارند، مسئله پیش از رسیدن به مدل، به تصمیم محتوایی نیاز دارد. مدل نباید مرجع سیاست داخلی را با حدس انتخاب کند.
پیشنهاد اجرایی این است که هر سند یک شناسهٔ پایدار و هر نسخه یک شناسهٔ جدا داشته باشد. کنار متن، مالک، وضعیت انتشار، شروع اعتبار و رابطهٔ نسخهٔ جدید با نسخهٔ قبلی ثبت شود. وضعیت‌هایی مانند «پیش‌نویس»، «فعال» و «بازنشسته» برای تصمیم برنامه مفیدند؛ صرفاً افزودن این کلمات داخل متن سند، کنترل نسخهٔ قابل اتکایی ایجاد نمی‌کند. فیلدهای وضعیت باید در مسیر انتخاب منبع نیز به کار روند.
در برگهٔ طراحی، تکلیف یک حالت مرزی را از ابتدا بنویسید: سندی که هنوز معتبر نشده، آیا برای کارشناس داخلی قابل مشاهده است؟ اگر بله، آیا پاسخ عمومی هم اجازه دارد از آن استفاده کند؟ جدا کردن مخاطب و بازهٔ اعتبار، از تبدیل یک اطلاعیهٔ آینده به پاسخ امروز جلوگیری می‌کند. این انتخاب باید متعلق به سازمان باشد و در آزمون‌ها نمونهٔ مشخص داشته باشد.
۲. تغییر سند را تا نمایه قابل پیگیری نگه دارید
مسیر به‌روزرسانی بهتر است به چند مرحلهٔ قابل مشاهده تقسیم شود: دریافت نسخه، بررسی محتوا، آماده‌سازی بخش‌ها، ورود به نمایه و فعال شدن برای جست‌وجو. در راهنمای بازیابی OpenAI، برخی عملیات افزودن فایل ناهمگام توصیف شده‌اند و تکمیل آن‌ها باید با وضعیت عملیات یا ابزار مناسب بررسی شود. بنابراین ارسال موفق یک درخواست را نباید بدون بررسی، معادل آماده بودن سند برای بازیابی دانست.
برای نمونهٔ پیشنهادی، یک رکورد عملیات نگه دارید که شناسهٔ سند، نسخه، مرحلهٔ جاری و نتیجهٔ آخرین تلاش را مشخص کند. اگر آماده‌سازی شکست خورد، نسخهٔ قبلی معتبر را خودکار کنار نگذارید. نخست بررسی کنید که نسخهٔ تازه کامل و قابل جست‌وجو شده است. تصمیم دربارهٔ حفظ نسخهٔ قبلی یا توقف پاسخ‌گویی به همان موضوع، به حساسیت کاربرد و قواعد سازمان بستگی دارد.
بخش‌های سند باید رابطهٔ خود با منبع کامل را حفظ کنند. بحث Contextual Retrieval در Anthropic به از دست رفتن زمینه هنگام جدا کردن بخش‌های متن می‌پردازد. در طراحی پیشنهادی این مقاله، شناسهٔ نسخه و عنوان مرتبط همراه بخش باقی می‌مانند تا تیم بتواند نتیجهٔ جست‌وجو را به سند اصلی برگرداند. این کار جای بازبینی معنای بخش‌ها را نمی‌گیرد؛ جدول شرایط و تبصرهٔ آن هنوز باید کنار هم قابل فهم باشند.
۳. سند بازنشسته را از مسیر پاسخ خارج کنید
حذف فایل، تغییر وضعیت و جلوگیری از استفاده در پاسخ سه تصمیم مرتبط اما متفاوت‌اند. راهنمای بازیابی OpenAI توضیح می‌دهد که حذف فایل از ذخیرهٔ برداری سازگاری نهایی دارد و برای مدتی کوتاه ممکن است محتوای حذف‌شده در نتیجهٔ جست‌وجو دیده شود. این ویژگی مربوط به همان سرویس است. برای یک سامانهٔ حساس، طراحی برنامه باید رفتار چنین فاصله‌ای را نیز مشخص کند؛ نباید نتیجهٔ هر جست‌وجو بدون بررسی اعتبار وارد پاسخ شود.
یک روش پیشنهادی، نگهداری فهرست نسخه‌های مجاز در لایهٔ برنامه است. پس از بازیابی، شناسهٔ نسخه با این فهرست تطبیق داده می‌شود و بخش متعلق به نسخهٔ بازنشسته کنار گذاشته می‌شود. دامنهٔ مجوز کاربر نیز باید مستقل بررسی شود. این الگو نیازمند هماهنگی با معماری واقعی سامانه است و ادعای حذف فوری اطلاعات از همهٔ لایه‌ها محسوب نمی‌شود.
کش پاسخ را نیز فراموش نکنید. اگر ساعت خدمت تغییر کرده، پاسخ ذخیره‌شدهٔ دیروز ممکن است با وجود نمایهٔ تازه دوباره ارائه شود. در نمونهٔ طراحی، نتیجهٔ ذخیره‌شده به نسخه‌های استفاده‌شده وابسته است؛ تغییر وضعیت آن نسخه‌ها، اعتبار نتیجه را برای استفادهٔ بعدی تغییر می‌دهد. مدت نگهداری، دامنهٔ کاربر و قواعد استفادهٔ مجدد باید قابل بررسی باشند. پاک کردن نمایه به‌تنهایی، تکلیف کش، گزارش‌ها و نسخه‌های پشتیبان را مشخص نمی‌کند.
۴. پرسش‌های حساس را پس از تغییر دوباره اجرا کنید
برای هر موضوع پرتکرار، مجموعه‌ای کوچک از سؤال‌های واقعی و پاسخ مورد انتظار بسازید. در مثال ساعت خدمت، سؤال مستقیم، پرسش محاوره‌ای، نام قدیمی خدمت و درخواست مربوط به یک تاریخ آینده را در نظر بگیرید. بعد از تغییر سند، فقط پاسخ نهایی را نگاه نکنید؛ بررسی کنید کدام بخش بازیابی شده و آیا همان نسخه برای همان مخاطب معتبر بوده است. خطای بازیابی و خطای نگارش پاسخ، مسیر اصلاح یکسانی ندارند.
یک آزمون مفید، وجود هم‌زمان نسخهٔ قدیمی و جدید در محیط آزمایشی است. سامانه باید بر اساس قواعد اعتبار، منبع درست را انتخاب کند. حالت دیگری بسازید که نسخهٔ جدید هنوز آماده نشده یا جست‌وجو شواهد کافی برنمی‌گرداند. پاسخ قابل قبول برای این حالت را پیشاپیش تعریف کنید؛ ممکن است توضیح کوتاه دربارهٔ نامعلوم بودن اطلاعات یا ارجاع به کارشناس مناسب باشد. نتیجهٔ این آزمون، وعدهٔ دقت همهٔ پاسخ‌ها نیست.
از ثبت اطلاعات اضافی تماس‌گیرنده برای عیب‌یابی خودداری کنید. معمولاً شناسهٔ آزمون، شناسهٔ نسخه و مرحلهٔ شکست برای بررسی اولیه کافی‌اند. اگر نگهداری نمونهٔ مکالمه لازم است، دامنهٔ استفاده و مدت نگهداری باید در طراحی روشن باشند. مجموعهٔ آزمون نیز به بازبینی نیاز دارد؛ سؤال‌های تکراری و بیش از حد تمیز، همهٔ شرایط مکالمهٔ واقعی را نشان نمی‌دهند.
۵. بازگردانی و مسئولیت به‌روزرسانی را تعریف کنید
پیش از انتشار نسخهٔ تازه، مسیر بازگردانی را مشخص کنید. بازگردانی باید شامل مرجع فعال، وضعیت نمایه و اعتبار نتایج ذخیره‌شده باشد. برگشتن به یک فایل قدیمی بدون دانستن اینکه چه پاسخی از آن ساخته می‌شود، تصمیم روشنی نیست. برای موضوعی که اطلاعات قبلی دیگر معتبر نیستند، توقف موقت پاسخ‌گویی ممکن است از فعال کردن دوبارهٔ نسخهٔ قدیمی مناسب‌تر باشد؛ انتخاب نهایی به قواعد همان سازمان وابسته است.
مالک محتوا و مسئول عملیات فنی بهتر است وظایف جدا و روشن داشته باشند. مالک محتوا اعتبار متن و زمان اجرا را تأیید می‌کند؛ مسئول فنی آماده شدن نمایه و نتیجهٔ آزمون‌ها را بررسی می‌کند. یک گزارش کوتاه تغییر، نام موضوع، نسخهٔ فعال، آزمون‌های انجام‌شده و محدودیت باقی‌مانده را ثبت می‌کند. این گزارش کمک می‌کند اختلاف دربارهٔ متن با خرابی مسیر فنی اشتباه نشود.
برای شروع، همین روش را روی یک موضوع محدود اجرا کنید. یک سند معتبر، چند نسخهٔ کنترل‌شده و مجموعهٔ کوچک سؤال‌ها کافی‌اند تا نقاط مبهم آشکار شوند. پس از روشن شدن مسئولیت‌ها و رفتار حالت‌های خطا، دامنه را گسترش دهید. به‌روزرسانی پایگاه دانش زمانی قابل اتکاتر می‌شود که تغییر سند، انتخاب شواهد و پاسخ نهایی در یک مسیر قابل پیگیری قرار بگیرند.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
