اگر دستیار هوش مصنوعی به سند قدیمی استناد کند، روان‌بودن پاسخ مشکل را حل نمی‌کند. برای مدیریت اسناد منقضی و پاسخ‌های متناقض، باید معلوم باشد کدام نسخه برای کدام زمان و دامنه معتبر است، تغییر چگونه به سامانه می‌رسد و در تعارض حل‌نشده چه کسی تصمیم می‌گیرد. این راهنما یک تمرین اجرایی برای همین سه پرسش است.
مخاطب، مسئول اسناد یا مدیر تیمی است که دستیار داخلی از راهنماها و دستورالعمل‌هایش پاسخ می‌دهد. مراحل پایهٔ آماده‌سازی منابع در راهنمای ساخت پایگاه دانش چت‌بات آمده است. در این مقاله بر چرخهٔ تغییر یک قاعده، تشخیص نسخهٔ قابل اجرا و گزارش خطا تمرکز می‌کنیم. تمام سندها، تاریخ‌ها و قواعد نمونهٔ زیر فرضی و آموزشی‌اند.
تاریخ ویرایش فایل، تاریخ اجرای قاعده نیست
یک فایل ممکن است امروز برای اصلاح نگارشی ذخیره شود، اما قاعدهٔ آن مربوط به سال قبل باشد. از طرف دیگر، دستورالعملی که امروز تصویب شده شاید از ماه آینده اجرا شود. انتخاب خودکار «جدیدترین فایل» این تفاوت را نادیده می‌گیرد. مالک محتوا باید زمان تصویب، شروع اعتبار، پایان اعتبار و دامنهٔ کاربرد را روشن کند؛ سامانه از روی نام فایل این تصمیم را حدس نزند.
برای تمرین، شناسهٔ پایدار DEMO-REQUEST را برای یک روال داخلی ساختگی در نظر بگیرید. نسخهٔ ۲ می‌گوید درخواست با فرم F-02 ثبت شود. نسخهٔ ۳، فرم F-03 را از اول آبان جایگزین می‌کند، ولی فایل آن بیست‌وپنجم مهر در مخزن قرار می‌گیرد. پاسخ به «امروز کدام فرم؟» در بیست‌وهشتم مهر باید با پاسخ همان پرسش در دوم آبان تفاوت داشته باشد.
| دادهٔ شناسنامه | نسخهٔ ۲ فرضی | نسخهٔ ۳ فرضی |
|---|---|---|
| شناسهٔ سند | DEMO-REQUEST | DEMO-REQUEST |
| شروع اعتبار | پیش از مهر در سناریوی تمرین | اول آبان در سناریوی تمرین |
| پایان اعتبار | پایان مهر | هنوز تعیین نشده |
| فرم مورد استفاده | F-02 | F-03 |
| وضعیت در بیست‌وهشتم مهر | جاری | مصوب برای آینده |
این جدول الگوی پیشنهادی مقاله است، نه یک استاندارد اجباری یا سیاست واقعی شرکت. در پیاده‌سازی، تاریخ‌ها باید سال و منطقهٔ زمانی مشخص داشته باشند. پاسخ به پرسش تاریخی نیز به تاریخ واقعه وابسته است؛ اگر کاربر فقط بگوید «برای درخواست قبلی کدام فرم لازم بود؟»، دستیار باید زمان درخواست را بپرسد و قاعدهٔ امروز را به گذشته تعمیم ندهد.
تعارض واقعی را از تفاوت دامنه جدا کنید
دو پاسخ متفاوت الزاماً تناقض نیستند. شاید یک سند برای دفتر مرکزی و دیگری برای شعبه باشد، یا یک قاعده دربارهٔ درخواست تازه و دیگری دربارهٔ پروندهٔ قدیمی. پیش از اعلام تعارض، موضوع، مخاطب، بازهٔ زمانی و دامنهٔ اجرا را مقایسه کنید. اگر این مشخصات در سؤال نیست، پرسش تکمیلی کوتاه از انتخاب حدسی بهتر است.
تعارض واقعی زمانی رخ می‌دهد که دو منبع معتبر، دربارهٔ یک وضعیت یکسان حکم ناسازگار داشته باشند و قاعدهٔ تقدم مصوبی وجود نداشته باشد. مدل نباید با توجه به لحن قاطع‌تر، طول بیشتر یا امتیاز بالاتر جست‌وجو یکی را مرجع کند. اولویت مرجع، مانند مصوبهٔ مالک فرایند در برابر راهنمای آموزشی، باید پیشاپیش توسط مسئول سازمان تعیین شده باشد.
در نمونهٔ فرضی، دو سند جاری و هم‌اعتبار برای همان واحد و همان تاریخ، فرم‌های F-03 و F-04 را معرفی می‌کنند. پاسخ مناسب می‌تواند بگوید: «در دو منبع مجاز، فرم متفاوت ثبت شده است؛ انتخاب فرم نیازمند تأیید مسئول فرایند است.» ارجاع فقط باید به منابعی نشان داده شود که کاربر حق دیدن آن‌ها را دارد؛ تشخیص تعارض مجوز نمایش سند محدود نیست. این مرز را با آزمون دسترسی کارکنان به اسناد جدا بررسی کنید.
جایگزینی سند را تا قطعه‌های بازیابی‌شده دنبال کنید
در معماری RAG، پاسخ از بخش‌هایی ساخته می‌شود که از نمایهٔ جست‌وجو بازیابی شده‌اند. شرح معماری RAG مایکروسافت مسیر آماده‌سازی و ذخیرهٔ قطعه‌ها را از بازیابی و تولید پاسخ جدا می‌کند. نتیجهٔ عملی برای نگهداری این است که اصلاح فایل اصلی باید در تمام نمایش‌های مشتق‌شدهٔ مورد استفادهٔ سامانه نیز بررسی شود.
برای هر قطعه، شناسهٔ سند و نسخه را نگه دارید. هنگام جایگزینی نسخهٔ ۲ با ۳، فهرست قطعه‌های نسخهٔ قبلی را با وضعیت جدید تطبیق دهید. ممکن است قطعهٔ مقدمه به‌روز شود ولی یک جدول قدیمی باقی بماند. آزمون فقط با یک سؤال کلی این وضعیت را آشکار نمی‌کند؛ پرسشی از متن، پرسشی از جدول و پرسشی دربارهٔ استثناهای تغییرکرده انتخاب کنید.
حذف فایل هم لزوماً به معنی حذف نتیجهٔ جست‌وجو نیست. برای مثال، مستند تشخیص تغییر و حذف در Azure AI Search برای منابع Storage میان تشخیص تغییر و حذف تفاوت می‌گذارد و حذف را وابسته به سازوکار مشخص می‌داند. روش دقیق در هر ابزار فرق دارد؛ از تیم فنی بخواهید نتیجهٔ حذف را روی نمایه و پاسخ نشان دهد، نه فقط روی پوشهٔ اصلی.
آزمون تغییر را با یک خط زمان ثبت کنید
در محیط آزمایشی، ابتدا پاسخ درستِ نسخهٔ ۲ را ثبت کنید. سپس نسخهٔ ۳ را با تاریخ شروع آینده اضافه کنید و سؤال «امروز کدام فرم؟» را تکرار کنید. بعد، زمان مرجع آزمون را به پس از شروع اعتبار ببرید و همان سؤال را اجرا کنید. اگر سامانه امکان تعیین زمان مرجع ندارد، این بخش باید در محیط مناسب یا با سناریوی تاریخ‌دار آزموده شود؛ ساعت سامانهٔ عملیاتی را برای تمرین تغییر ندهید.
| آزمون فرضی | انتظار | شاهدی که باید ثبت شود |
|---|---|---|
| نسخهٔ آینده پیش از زمان اجرا | حفظ قاعدهٔ جاری F-02 | تاریخ مرجع سؤال و نسخهٔ منبع |
| پس از شروع نسخهٔ ۳ | پاسخ F-03 بدون ترکیب مراحل قدیم | شناسهٔ قطعه و نسخهٔ پاسخ |
| تعارض دو منبع هم‌اعتبار | اعلام تعارض و ارجاع | هر دو منبع مجاز و تصمیم مسئول |
| بازنشستگی نسخهٔ ۲ | خروج از پاسخ جاری؛ تاریخچه طبق سیاست | نتیجهٔ جست‌وجو و پاسخ جاری |
| اختلال همگام‌سازی | اعلام نامعلوم بودن تازگی در دامنهٔ حساس | آخرین همگام‌سازی موفق و رفتار پاسخ |
برای سنجش تأخیر، زمان تأیید تغییر در مخزن، زمان ورود نسخه به نمایه و زمان نخستین پاسخ صحیح را جدا ثبت کنید. فاصلهٔ این زمان‌ها به یافتن محل مشکل در آماده‌سازی، همگام‌سازی یا پاسخ‌گویی کمک می‌کند. حد قابل قبول را مالک فرایند بر اساس حساسیت کار تعیین کند؛ یک عدد ثابت برای همهٔ شرکت‌ها مناسب نیست. تا زمانی که تازگی تأیید نشده، پاسخ حساس نباید با قطعیت «آخرین دستورالعمل» معرفی شود.
وقتی پاسخ قدیمی دیده شد، ابتدا محل خطا را مشخص کنید
اگر نمایه هنوز نسخهٔ ۲ دارد، تغییر دستور مدل راه‌حل اصلی نیست. اگر نسخهٔ ۳ بازیابی شده ولی پاسخ از سابقهٔ گفتگو یا پاسخ ذخیره‌شدهٔ قدیمی آمده، باید همان مسیر بررسی شود. اگر هر دو نسخه معتبر نمایش داده می‌شوند، ابتدا شناسنامه و قواعد دامنه را اصلاح کنید. وقتی علت پاسخ نامناسب، پیروی از فرمان داخل فایل است، مسئلهٔ دستور مخرب در سند را جدا از کهنگی نسخه بررسی کنید. در راهنمای ارزیابی پاسخ RAG مایکروسافت نیز اتکای پاسخ به منابع و کامل‌بودن آن معیارهای جدا هستند؛ صرف وجود یک ارجاع کافی نیست.
پس از اصلاح، فقط سؤال شکست‌خورده را تکرار نکنید. پرسش‌های مربوط به نسخهٔ جاری، پرسش تاریخی، حالت مبهم و تعارض حل‌نشده را دوباره اجرا کنید. در گزارش، «نسخهٔ قدیمی به‌عنوان قاعدهٔ امروز استفاده شد» را از «پاسخ ناقص بود» جدا نگه دارید. نتیجهٔ اجرا‌نشده هم باید باز بماند؛ نبود خطای ثبت‌شده، شاهد آزمون موفق نیست.
مالک سند و مسئول سامانه باید تحویل مشترک داشته باشند
مالک سند، اعتبار و تقدم منابع را تعیین می‌کند؛ تیم فنی، انتقال تغییر و رفتار دستیار را نشان می‌دهد. برای دستیار هوش مصنوعی اسناد سازمان، این تقسیم مسئولیت را همراه مسیر تأیید نسخه و برگشت ثبت کنید. در دستیار فعال، بازبینی منابع منقضی و اجرای آزمون پس از اصلاح می‌تواند بخشی از ارزیابی و نگهداری کیفیت دستیار باشد. فهرست منابع حل‌نشده باید صاحب تصمیم داشته باشد.
پرسش و پاسخ
خیر. تاریخ ذخیره یا انتشار فایل با تاریخ اجرای قاعده فرق دارد. نسخه، زمان اعتبار، دامنهٔ کاربرد و تأیید مالک محتوا باید مشخص باشند.
ابتدا تفاوت زمان و دامنه را بررسی کند. اگر تعارض واقعی و حل‌نشده است، آن را اعلام و به مسئول فرایند ارجاع دهد؛ انتخاب مرجع نباید بر اساس لحن یا رتبهٔ جست‌وجو حدس زده شود.
خیر. باید وضعیت نسخه و قطعه‌های آن در نمایه، ارجاع‌ها و پاسخ‌های ذخیره‌شدهٔ سامانه نیز بررسی شود. روش حذف و به‌روزرسانی به ابزار و معماری وابسته است.
گفتگو
دیدگاه‌ها و پرسش‌های شما
اگر درباره این نوشته تجربه، سوال یا نکته‌ای دارید، همین‌جا بنویسید تا گفتگو برای خوانندگان بعدی هم کامل‌تر شود.