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