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