مدل های زبانی بزرگ امکان ساخت سامانه هایی را فراهم کرده اند که می توانند به پرسش های کاربران پاسخ دهند، اسناد را تحلیل کنند، اطلاعات را از متن استخراج کنند و در فرایندهای سازمانی به کار گرفته شوند. با این حال، استفاده از یک مدل زبانی به تنهایی برای ساخت یک محصول قابل اتکا کافی نیست. در یک پروژه واقعی، انتخاب مدل فقط یکی از تصمیم های فنی است و معماری سیستم، کیفیت داده ها، روش بازیابی اطلاعات، مدیریت خطا، امنیت و ارزیابی خروجی نیز نقش تعیین کننده ای دارند.
برای مثال، فرض کنید یک شرکت می خواهد سامانه ای ایجاد کند که کارکنان بتوانند درباره آیین نامه های داخلی، مستندات فنی یا فرایندهای سازمانی از آن سوال بپرسند. یک مدل زبانی عمومی ممکن است پاسخ هایی مرتبط تولید کند، اما لزوما به آخرین نسخه اسناد شرکت دسترسی ندارد. اگر اطلاعاتی را نداند، ممکن است پاسخی نادرست بسازد یا جزئیاتی را از خود اضافه کند.
راهکار مناسب، طراحی یک سامانه است که مدل زبانی را به داده های معتبر متصل کند، اسناد مرتبط را بازیابی کند، پاسخ را بر اساس شواهد تولید کند و نتیجه را با معیارهای مشخص ارزیابی کند. این معماری می تواند هسته یک چت بات اختصاصی، دستیار سازمانی یا ابزار پردازش خودکار متن باشد.
در این مقاله، مراحل طراحی چنین سامانه ای را از تعریف مسئله و انتخاب مدل تا پیاده سازی، ارزیابی و استقرار بررسی می کنیم.
۱. پیش از انتخاب مدل، مسئله را دقیق تعریف کنید
یکی از اشتباهات رایج در پروژه های هوش مصنوعی، شروع کار با انتخاب یک مدل مشهور یا قدرتمند بدون تعریف روشن نیاز کسب و کار است. مدل مناسب برای خلاصه سازی اسناد لزوما بهترین انتخاب برای استخراج اطلاعات ساختاریافته یا پاسخ گویی به پرسش های تخصصی نیست.
در قدم اول باید مشخص شود سامانه قرار است چه کاری انجام دهد، چه کسانی از آن استفاده می کنند و خروجی قابل قبول چه ویژگی هایی دارد.
چند نمونه از مسائل رایج در پردازش متن عبارت اند از:
- پاسخ گویی به پرسش های کاربران بر اساس مستندات اختصاصی
- دسته بندی تیکت های پشتیبانی و ارجاع آنها به واحد مربوط
- استخراج نام، تاریخ، مبلغ و سایر فیلدهای مشخص از اسناد
- خلاصه سازی گزارش های طولانی
- تحلیل نظرات کاربران و شناسایی موضوعات پرتکرار
- جست وجوی معنایی در پایگاه اسناد
- تولید پیش نویس پاسخ برای کارشناسان پشتیبانی
- بررسی و مقایسه محتوای اسناد با مجموعه ای از قواعد مشخص
این وظایف از نظر معماری و معیار ارزیابی با یکدیگر تفاوت دارند. برای مثال، در استخراج مبلغ قرارداد، صحت مقدار استخراج شده اهمیت بیشتری از روان بودن متن خروجی دارد. در یک دستیار مکالمه نیز مرتبط بودن پاسخ، استفاده از اطلاعات معتبر و توانایی اعلام نداشتن اطلاعات کافی اهمیت زیادی دارند.
پیش از شروع توسعه، بهتر است مجموعه ای از پرسش ها و ورودی های واقعی تهیه شود. این مجموعه باید موارد ساده، پیچیده، مبهم و خارج از محدوده سامانه را پوشش دهد. بعدا از همین داده ها برای مقایسه مدل ها و ارزیابی نسخه های مختلف استفاده خواهد شد.
۲. انتخاب معماری مناسب برای پردازش متن
پس از مشخص شدن مسئله، باید تصمیم گرفت که راهکار با چه معماری ای پیاده سازی شود. در بسیاری از پروژه ها، سه رویکرد اصلی مطرح هستند: استفاده مستقیم از مدل زبانی، بازیابی اطلاعات همراه با تولید پاسخ و تنظیم دقیق مدل.
استفاده مستقیم از مدل زبانی
در ساده ترین حالت، ورودی کاربر به همراه یک دستور مشخص برای مدل ارسال می شود و خروجی آن به کاربر بازمی گردد. این روش برای تولید متن، بازنویسی، خلاصه سازی و برخی وظایف عمومی مناسب است.
مزیت اصلی این رویکرد، سادگی پیاده سازی است. نیازی نیست ابتدا یک پایگاه دانش اختصاصی ساخته شود یا فرایند بازیابی اسناد طراحی شود. در مقابل، اگر پاسخ به اطلاعات اختصاصی یا به روز نیاز داشته باشد، مدل ممکن است به داده های لازم دسترسی نداشته باشد.
تولید تقویت شده با بازیابی اطلاعات یا RAG
در معماری RAG، مدل زبانی پیش از تولید پاسخ به اطلاعات مرتبطی دسترسی پیدا می کند که از یک مجموعه اسناد بازیابی شده اند. به این ترتیب، دانش اختصاصی پروژه لازم نیست به طور کامل در پارامترهای مدل ذخیره شده باشد.
این روش برای ساخت دستیارهای سازمانی، چت بات های پاسخ گوی مستندات، جست وجوی هوشمند و سامانه های پرسش و پاسخ روی مجموعه اسناد کاربرد دارد.
تنظیم دقیق مدل یا Fine-tuning
در تنظیم دقیق، یک مدل از پیش آموزش دیده با داده های هدفمند دیگری آموزش داده می شود تا رفتار یا عملکرد آن برای یک وظیفه مشخص تغییر کند. این روش می تواند برای بهبود سبک پاسخ، پیروی از قالب خروجی یا انجام یک وظیفه تخصصی مفید باشد.
با این حال، تنظیم دقیق معمولا اولین انتخاب برای اضافه کردن اطلاعات متغیر سازمان نیست. اگر هدف، پاسخ گویی بر اساس نسخه جدید آیین نامه یا مستندات محصول باشد، بازیابی اطلاعات معمولا روش مناسب تری برای نگهداری دانش به روز و قابل بررسی است.
| نیاز پروژه | رویکرد اولیه پیشنهادی |
|---|---|
| بازنویسی و خلاصه سازی متن عمومی | مدل زبانی با دستور مناسب |
| پاسخ به سوالات درباره اسناد داخلی | RAG |
| استخراج اطلاعات با قالب مشخص | مدل زبانی همراه با اعتبارسنجی خروجی یا مدل تخصصی |
| تولید پاسخ با سبک ثابت | طراحی دستور و در صورت نیاز تنظیم دقیق |
| اطلاعاتی که مرتب تغییر می کنند | بازیابی از منبع به روز |
| طبقه بندی پرتعداد و مشخص متن | مقایسه مدل های کلاسیک و مدل های زبانی |
این جدول یک نقطه شروع برای طراحی است، نه نسخه ای یکسان برای تمام پروژه ها. تصمیم نهایی باید با توجه به کیفیت مورد نیاز، حجم درخواست ها، منابع محاسباتی، هزینه و الزامات امنیتی گرفته شود.
۳. انتخاب مدل زبانی بر اساس نیاز واقعی پروژه
انتخاب مدل فقط بر اساس اندازه یا شهرت آن، تصمیم دقیقی نیست. یک مدل بزرگ ممکن است پاسخ های باکیفیتی تولید کند، اما هزینه پردازش، زمان پاسخ و منابع سخت افزاری بیشتری نیاز داشته باشد. از طرف دیگر، یک مدل کوچک تر ممکن است برای یک وظیفه محدود و مشخص، سریع تر و اقتصادی تر باشد.
در انتخاب مدل باید چند معیار را بررسی کرد.
کیفیت پاسخ در زبان مورد نیاز: اگر سامانه برای کاربران فارسی زبان ساخته می شود، مدل باید با متن های واقعی فارسی ارزیابی شود. کیفیت یک مدل در آزمون های عمومی انگلیسی، تضمین کننده عملکرد مناسب آن در فارسی، به ویژه در متن های محاوره ای و تخصصی، نیست.
اندازه مدل و منابع محاسباتی: تعداد پارامترها، میزان حافظه مورد نیاز، نوع سخت افزار و روش اجرای مدل بر هزینه و سرعت تاثیر می گذارند. مدل های کوچک تر و کوانتیزه شده در بعضی سناریوها امکان اجرای محلی را فراهم می کنند، اما افت احتمالی کیفیت باید اندازه گیری شود.
پنجره زمینه یا Context Window: این ویژگی مشخص می کند مدل چه مقدار متن را در یک درخواست می تواند پردازش کند. با این حال، ظرفیت اسمی بزرگ تر همیشه به معنای استفاده دقیق از تمام اطلاعات یک سند طولانی نیست.
مجوز استفاده: در مدل های قابل دریافت و اجرای محلی باید شرایط مجوز، امکان استفاده تجاری، محدودیت های بازتوزیع و الزامات مربوط به مدل پایه بررسی شوند.
سرعت و هزینه استنتاج: برای سامانه ای که تعداد زیادی درخواست دریافت می کند، زمان تولید هر پاسخ و هزینه پردازش هر درخواست اهمیت عملیاتی زیادی دارد.
قابلیت استفاده از ابزارها و خروجی ساختاریافته: اگر سامانه باید اطلاعات را در قالب JSON برگرداند یا به سرویس های دیگر متصل شود، توانایی مدل در رعایت قالب و فراخوانی ابزارها باید در عمل سنجیده شود.
بهترین روش، انتخاب چند مدل نامزد و آزمایش آنها با یک مجموعه ورودی یکسان است. مقایسه باید بر اساس نتایج واقعی پروژه انجام شود، نه فقط ادعاهای سازندگان یا امتیازهای عمومی.
برای آشنایی بیشتر با جنبه های ساخت و آموزش مدل های زبانی فارسی، مقاله ساخت یک مدل زبانی مشابه ChatGPT برای زبان فارسی نیز می تواند نقطه شروع مناسبی باشد.
۴. طراحی خط لوله آماده سازی و پردازش اسناد
در پروژه های مبتنی بر اسناد، کیفیت داده ها می تواند به اندازه انتخاب مدل اهمیت داشته باشد. اگر فایل های ورودی ناقص، تکراری یا نادرست باشند، حتی یک مدل زبانی قوی نیز ممکن است پاسخ نامناسبی تولید کند.
فرض کنید قرار است یک چت بات به مجموعه ای از فایل های PDF، راهنماهای فنی، فایل های Word و صفحات داخلی شرکت دسترسی داشته باشد. پیش از استفاده از این داده ها باید یک خط لوله مشخص برای دریافت، استخراج، پاک سازی و نسخه بندی آنها طراحی شود.
مراحل معمول عبارت اند از:
۱. دریافت فایل ها از منابع مجاز
۲. استخراج متن و ساختار سند
۳. تشخیص و اصلاح مشکلات متداول در متن
۴. حذف بخش های تکراری و محتوای نامرتبط
۵. حفظ اطلاعاتی مانند عنوان، شماره صفحه، تاریخ انتشار و شناسه سند
۶. تقسیم محتوا به بخش های قابل بازیابی
۷. تولید نمایش برداری و ذخیره اطلاعات در مخزن مناسب
استخراج متن از PDF همیشه ساده نیست. بعضی فایل ها از متن قابل انتخاب تشکیل شده اند، اما برخی دیگر در واقع تصویر اسکن شده هستند و برای پردازش به OCR نیاز دارند. در اسناد جدولی نیز باید ساختار سطرها و ستون ها تا حد ممکن حفظ شود. تبدیل یک جدول به متنی نامنظم می تواند ارتباط میان مقادیر و عنوان ستون ها را از بین ببرد.
همچنین باید به تغییرات اسناد توجه کرد. اگر یک دستورالعمل جدید جایگزین نسخه قبلی شود، سامانه نباید بدون بررسی همچنان به نسخه منسوخ استناد کند. بنابراین، نگهداری نسخه سند، تاریخ اعتبار و وضعیت انتشار بخشی از طراحی فنی است، نه صرفا یک موضوع مدیریتی.
۵. تقسیم اسناد به بخش های مناسب یا Chunking
مدل های بازیابی اطلاعات معمولا به جای جست وجوی یک سند طولانی به صورت یکپارچه، روی بخش های کوچک تر آن کار می کنند. به این بخش ها Chunk گفته می شود.
اگر بخش ها بیش از حد بزرگ باشند، ممکن است متن نامرتبط زیادی همراه نتیجه بازیابی شود. اگر بیش از حد کوچک باشند، ارتباط میان تعریف، توضیح و استثناهای یک موضوع از بین می رود.
برای مثال، فرض کنید یک راهنمای فنی شامل تعریف یک قابلیت، مراحل استفاده از آن و محدودیت هایش باشد. اگر هر جمله به صورت مستقل ذخیره شود، بازیابی ممکن است فقط تعریف قابلیت را برگرداند و محدودیت مهم آن را از دست بدهد. در مقابل، ذخیره کل راهنما در یک بخش واحد می تواند دقت جست وجو را کاهش دهد.
اندازه مناسب بخش به نوع محتوا بستگی دارد. متن پیوسته، جدول، مستندات برنامه نویسی و قراردادهای حقوقی به روش های متفاوتی برای تقسیم نیاز دارند. بهتر است تقسیم محتوا تا حد امکان ساختار سند را رعایت کند و بخش های مرتبط، اطلاعات زمینه ای لازم را حفظ کنند.
در بعضی معماری ها، میان بخش ها همپوشانی در نظر گرفته می شود تا اطلاعات مرزی از بین نرود. میزان همپوشانی باید با آزمایش تعیین شود، زیرا افزایش آن می تواند حجم داده های ذخیره شده و تعداد نتایج تکراری را بالا ببرد.
علاوه بر متن هر بخش، باید فراداده هایی مانند شناسه سند، عنوان، شماره صفحه، دسته بندی و سطح دسترسی نیز ذخیره شوند. این اطلاعات برای فیلتر کردن نتایج، نمایش منبع و اعمال مجوزهای دسترسی ضروری هستند.
۶. Embedding و جست وجوی معنایی
در جست وجوی متنی سنتی، سیستم معمولا بر تطبیق واژه ها یا معیارهای آماری متن تکیه می کند. این روش برای بسیاری از جست وجوها مفید است، اما همیشه نمی تواند ارتباط معنایی میان عبارت های متفاوت را تشخیص دهد.
در جست وجوی معنایی، مدل Embedding متن را به یک بردار عددی تبدیل می کند. این بردار بازنمایی ای از ویژگی های آموخته شده متن است و می توان از آن برای مقایسه میزان شباهت میان پرسش و اسناد استفاده کرد.
برای نمونه، کاربر ممکن است بپرسد «چطور رمز حسابم را عوض کنم؟» در حالی که سند از عبارت «تغییر گذرواژه کاربری» استفاده کرده است. جست وجوی معنایی می تواند در صورت عملکرد مناسب مدل، ارتباط این دو عبارت را تشخیص دهد.
بردارهای اسناد معمولا در یک پایگاه داده برداری یا سامانه جست وجوی سازگار با بردارها ذخیره می شوند. گزینه هایی مانند FAISS، Qdrant و PostgreSQL همراه با افزونه pgvector در سناریوهای مختلف قابل بررسی هستند. انتخاب نهایی به حجم داده، نیازهای فیلترگذاری، مقیاس پذیری و شیوه استقرار بستگی دارد.
با این حال، شباهت معنایی به تنهایی کافی نیست. ممکن است یک سند از نظر موضوعی شبیه پرسش باشد، اما پاسخ دقیق را در بر نداشته باشد. به همین دلیل، بسیاری از سامانه ها از ترکیب جست وجوی واژگانی و معنایی استفاده می کنند تا هم تطبیق دقیق عبارت ها و هم ارتباط مفهومی در نظر گرفته شود.
برای زبان فارسی نیز باید مدل Embedding را با داده های واقعی ارزیابی کرد. تفاوت های نوشتاری، فاصله گذاری، شکل های محاوره ای و اصطلاحات تخصصی می توانند بر کیفیت بازیابی تاثیر بگذارند.
۷. طراحی معماری RAG برای یک چت بات اختصاصی
در یک سامانه RAG، مدل زبانی به تنهایی مسئول یافتن دانش نیست. بخش بازیابی، اسناد مرتبط را پیدا می کند و آنها را در اختیار مدل قرار می دهد تا پاسخ بر اساس محتوای بازیابی شده تولید شود.
یک معماری پایه را می توان به این شکل نمایش داد:
کاربر ← رابط چت ← سرویس برنامه ← بازیابی اسناد ← ساخت زمینه ← مدل زبانی ← اعتبارسنجی پاسخ ← نمایش نتیجه
هر بخش وظیفه مشخصی دارد.
رابط چت: پرسش کاربر را دریافت می کند و پاسخ را نمایش می دهد. در چت بات فارسی، پشتیبانی از راست چین بودن متن، نمایش درست کد و مدیریت پیام های طولانی نیز اهمیت دارد.
سرویس برنامه: درخواست ها را مدیریت می کند، هویت کاربر را بررسی می کند، تنظیمات لازم را اعمال می کند و اجزای مختلف سیستم را به هم متصل می سازد.
بازیابی اسناد: بخش های مرتبط را با استفاده از جست وجوی واژگانی، معنایی یا ترکیبی پیدا می کند.
ساخت زمینه: نتایج بازیابی شده را بر اساس میزان ارتباط و محدودیت طول ورودی مدل انتخاب و مرتب می کند.
مدل زبانی: با دریافت پرسش و اطلاعات مرتبط، پاسخ را تولید می کند.
اعتبارسنجی: ساختار پاسخ، وجود اطلاعات مورد نیاز و برخی محدودیت های تعریف شده را بررسی می کند. در صورت نیاز، سیستم می تواند پاسخ را رد کند، درخواست را به کارشناس ارجاع دهد یا از مدل بخواهد اطلاعات بیشتری ارائه شود.
ثبت رویدادها: اطلاعات لازم برای بررسی عملکرد، خطاها، زمان پاسخ و هزینه پردازش را ذخیره می کند. ثبت داده ها باید با سیاست های حفظ حریم خصوصی و محدودیت های دسترسی هماهنگ باشد.
در طراحی این معماری، بهتر است اجزا تا حد ممکن مستقل باشند. برای مثال، لایه اتصال به مدل زبانی می تواند طوری طراحی شود که تغییر ارائه دهنده یا جایگزینی مدل، نیازمند بازنویسی کل برنامه نباشد.
۸. طراحی دستور و تولید پاسخ قابل اتکا
کیفیت خروجی مدل تا حدی به نحوه تعریف دستور وابسته است. دستور باید نقش سامانه، نوع پاسخ مورد انتظار، محدودیت ها و نحوه استفاده از اطلاعات بازیابی شده را مشخص کند.
برای یک دستیار پاسخ گوی اسناد می توان قواعدی مانند این موارد تعریف کرد:
- پاسخ را بر اساس اسناد ارائه شده تولید کن.
- اگر اطلاعات کافی در دسترس نیست، صریحا اعلام کن.
- میان اطلاعات مستند و استنباط خود تفاوت بگذار.
- اگر منبع پاسخ مشخص است، شناسه یا ارجاع آن را ارائه کن.
- اطلاعات خارج از محدوده مجاز را افشا نکن.
- اگر درخواست به تصمیم تخصصی یا تایید انسانی نیاز دارد، آن را مشخص کن.
این دستورها به کاهش برخی خطاها کمک می کنند، اما به تنهایی تضمین کننده صحت نیستند. مدل ممکن است همچنان از اطلاعات نامرتبط استفاده کند یا ادعایی را به منبعی نسبت دهد که واقعا آن را پشتیبانی نمی کند.
به همین دلیل، ارجاع به منبع باید در سطح برنامه نیز بررسی شود. اگر پاسخ شامل شناسه سند یا شماره صفحه است، بهتر است سیستم اطمینان پیدا کند که این ارجاع به یک منبع واقعی و مرتبط اشاره می کند.
در کاربردهایی که خروجی باید قابل پردازش توسط نرم افزار دیگری باشد، بهتر است از قالب ساختاریافته استفاده شود. برای مثال، خروجی می تواند شامل فیلدهای answer، sources و needs_review باشد. سپس برنامه باید صحت ساختار و نوع داده های هر فیلد را اعتبارسنجی کند. صرف درخواست JSON از مدل برای تضمین خروجی معتبر کافی نیست.
۹. مدیریت تاریخچه مکالمه و حافظه چت بات
یکی از انتظارات کاربران از چت بات اختصاصی این است که بتوانند سوال های پی در پی بپرسند و لازم نباشد هر بار تمام زمینه را دوباره توضیح دهند. برای این کار باید میان تاریخچه مکالمه و دانش اختصاصی سیستم تفاوت قائل شد.
تاریخچه مکالمه شامل پیام های قبلی کاربر و پاسخ های سامانه است. این تاریخچه به مدل کمک می کند ارجاع هایی مانند «این مورد» یا «راه حل دوم» را در بافت گفت وگو تفسیر کند.
دانش اختصاصی، در مقابل، از اسناد یا منابع خارجی تامین می شود و لزوما بخشی از تاریخچه مکالمه نیست. برای مثال، یک کاربر ممکن است درباره شرایط گارانتی محصول سوال بپرسد. پاسخ باید از سند معتبر گارانتی استخراج شود، نه از گفت وگوی قبلی کاربر با چت بات.
ارسال تمام تاریخچه به مدل در هر درخواست نیز همیشه راهکار مناسبی نیست. با طولانی شدن مکالمه، مصرف توکن، زمان پاسخ و هزینه پردازش افزایش پیدا می کند. بنابراین، بسته به نیاز پروژه می توان از محدود کردن تاریخچه، خلاصه سازی مکالمه یا نگهداری ساختاریافته اطلاعات ضروری استفاده کرد.
اگر حافظه بلندمدت برای کاربر در نظر گرفته شود، باید مشخص باشد چه اطلاعاتی ذخیره می شوند، برای چه مدتی نگهداری می شوند و چگونه می توان آنها را مشاهده یا حذف کرد. این تصمیم ها باید با نیاز محصول و الزامات حریم خصوصی هماهنگ باشند.
۱۰. ارزیابی کیفیت سامانه پیش از انتشار
یکی از تفاوت های پروژه آزمایشی و محصول قابل استفاده، وجود فرایند ارزیابی منظم است. اگر تنها چند سوال را به چت بات بدهیم و پاسخ های ظاهرا خوبی دریافت کنیم، نمی توان نتیجه گرفت که سامانه در شرایط واقعی قابل اتکا خواهد بود.
برای ارزیابی اولیه باید مجموعه ای از پرسش ها تهیه شود که پاسخ مورد انتظار یا معیار بررسی مشخصی داشته باشند. این مجموعه بهتر است شامل موارد زیر باشد:
- سوال هایی که پاسخ آنها به طور واضح در اسناد وجود دارد
- سوال هایی که پاسخ آنها در چند سند پراکنده است
- پرسش های مبهم یا ناقص
- پرسش هایی که پاسخ آنها در منابع موجود نیست
- سوال هایی که به اطلاعات منسوخ یا متناقض مربوط می شوند
- درخواست هایی که کاربر مجاز به دریافت اطلاعات آنها نیست
- عبارت های محاوره ای، غلط های املایی و شکل های متنوع نوشتاری
سپس باید چند معیار مستقل اندازه گیری شوند.
کیفیت بازیابی: آیا بخش های مرتبط با پرسش در میان نتایج اولیه قرار گرفته اند؟ معیارهایی مانند Recall@k و MRR می توانند در ارزیابی بازیابی استفاده شوند.
صحت پاسخ: آیا پاسخ با اطلاعات معتبر مطابقت دارد؟ این معیار باید با توجه به نوع وظیفه و سطح حساسیت اطلاعات تعریف شود.
پشتیبانی پاسخ از منابع: آیا ادعاهای مهم پاسخ واقعا در اسناد ارائه شده وجود دارند؟ وجود یک پیوند به سند به تنهایی ثابت نمی کند که سند، ادعا را پشتیبانی می کند.
نرخ پاسخ نامعتبر: سامانه در چه تعداد از مواردی که اطلاعات کافی ندارد، پاسخی نادرست یا بدون پشتوانه ارائه می کند؟
زمان پاسخ و هزینه: هر درخواست چه مدت طول می کشد و به طور متوسط چه میزان منابع محاسباتی مصرف می کند؟
پایداری: آیا سیستم در برابر خطاهای موقت سرویس مدل، قطع ارتباط با پایگاه داده و ورودی های غیرمنتظره رفتار قابل پیش بینی دارد؟
ارزیابی خودکار می تواند برای مقایسه نسخه های مختلف مفید باشد، اما در کاربردهای حساس بهتر است بخشی از نمونه ها توسط انسان نیز بررسی شوند. اگر از یک مدل زبانی برای امتیازدهی به پاسخ مدل دیگر استفاده می شود، باید محدودیت های این روش را در نظر گرفت و نتایج آن را با نمونه های انسانی مقایسه کرد.
نکته مهم دیگر این است که مجموعه ارزیابی باید از داده های مورد استفاده برای تنظیم مدل جدا باشد. در غیر این صورت، ممکن است نتیجه ارزیابی بیش از حد خوش بینانه شود.
۱۱. امنیت و حریم خصوصی در چت بات های سازمانی
یک چت بات اختصاصی ممکن است به اسناد داخلی، اطلاعات مشتریان یا داده های محرمانه دسترسی داشته باشد. بنابراین، امنیت باید از ابتدای طراحی در نظر گرفته شود، نه اینکه پس از تکمیل برنامه به آن اضافه شود.
اولین اصل، کنترل دسترسی است. اگر دو کاربر مجوز مشاهده اسناد متفاوتی دارند، سیستم بازیابی نیز باید این تفاوت را رعایت کند. فیلتر کردن اسناد پس از تولید پاسخ کافی نیست، زیرا ممکن است اطلاعات غیرمجاز پیش از آن وارد زمینه مدل شده باشند.
اصل دوم، حفاظت از اطلاعات حساس است. ارسال داده به یک سرویس خارجی باید با سیاست سازمان، شرایط سرویس دهنده و الزامات قراردادی هماهنگ باشد. در پروژه هایی که محرمانگی اهمیت بالایی دارد، می توان اجرای محلی یا استقرار در زیرساخت کنترل شده را بررسی کرد. البته اجرای محلی نیز به مدیریت دسترسی، به روزرسانی، امنیت سرور و نظارت عملیاتی نیاز دارد.
اصل سوم، مقابله با تزریق دستور یا Prompt Injection است. ممکن است متن یک سند یا پیام کاربر حاوی دستورهایی باشد که تلاش می کنند رفتار مدل را تغییر دهند یا اطلاعات محافظت شده را افشا کنند. جدا کردن داده از دستورهای سیستم، محدود کردن دسترسی ابزارها و اعتبارسنجی عملیات حساس، بخشی از راهکار دفاعی هستند. هیچ روش منفردی تمام این خطرها را از بین نمی برد.
در نهایت، ثبت گزارش ها باید با دقت انجام شود. ذخیره کامل تمام مکالمات ممکن است برای عیب یابی مفید باشد، اما می تواند اطلاعات شخصی یا محرمانه را نیز در معرض خطر قرار دهد. باید مشخص شود چه داده ای ثبت می شود، چه کسانی به آن دسترسی دارند و چه زمانی حذف خواهد شد.
۱۲. استقرار سامانه و مدیریت عملکرد در محیط واقعی
پس از تکمیل نمونه اولیه، باید سامانه در محیطی اجرا شود که از نظر دسترس پذیری، امنیت و ظرفیت پردازش پاسخ گوی نیاز کاربران باشد.
معماری استقرار به این بستگی دارد که مدل از طریق API ارائه می شود یا روی زیرساخت اختصاصی اجرا خواهد شد. در حالت API، بخش مهمی از زیرساخت مدل بر عهده ارائه دهنده است، اما برنامه همچنان باید خطاها، محدودیت درخواست و تاخیر سرویس را مدیریت کند.
در اجرای محلی، علاوه بر سرویس برنامه، منابع لازم برای اجرای مدل نیز باید تامین شوند. مقدار حافظه، نوع پردازنده یا GPU، روش کوانتیزه سازی، اندازه مدل و تعداد درخواست های هم زمان بر ظرفیت سیستم تاثیر دارند.
برای محیط عملیاتی، موارد زیر باید در نظر گرفته شوند:
مدیریت درخواست های هم زمان: اگر چند کاربر هم زمان سوال بپرسند، سیستم باید درخواست ها را بدون مصرف بی رویه منابع مدیریت کند.
Timeout و تلاش مجدد: اگر سرویس مدل پاسخ ندهد، برنامه باید رفتار مشخصی داشته باشد و از تکرار بی پایان درخواست جلوگیری کند.
محدودیت مصرف: محدود کردن تعداد درخواست ها یا طول ورودی می تواند از مصرف غیرمنتظره منابع جلوگیری کند.
پایش عملکرد: زمان پاسخ، نرخ خطا، حجم درخواست و هزینه پردازش باید قابل مشاهده باشند.
ثبت نسخه ها: نسخه مدل، تنظیمات بازیابی، دستورهای اصلی و نسخه اسناد باید ثبت شوند تا در صورت افت کیفیت بتوان تغییرات را بررسی کرد.
آزمون پیش از انتشار: تغییر مدل یا تنظیمات بازیابی ممکن است کیفیت پاسخ را بهتر یا بدتر کند. بنابراین، نسخه جدید باید پیش از جایگزینی کامل با مجموعه ارزیابی ثابت بررسی شود.
همچنین باید به این نکته توجه کرد که عملکرد مدل در زمان توسعه لزوما با شرایط محیط واقعی یکسان نیست. افزایش طول پرسش ها، رشد تعداد کاربران، تغییر اسناد و بروز خطا در سرویس های وابسته می توانند رفتار سامانه را تغییر دهند.
۱۳. چه زمانی ساخت چت بات اختصاصی توجیه دارد؟
استفاده از یک ابزار عمومی برای بسیاری از نیازهای روزمره کافی است. اما در بعضی شرایط، سازمان به سامانه ای نیاز دارد که با فرایندها، داده ها و محدودیت های خودش هماهنگ باشد.
ساخت چت بات اختصاصی زمانی ارزش بیشتری پیدا می کند که یکی یا چند مورد از این نیازها وجود داشته باشد:
- پاسخ گویی بر اساس اسناد داخلی و اطلاعات اختصاصی
- اتصال به سامانه هایی مانند CRM، نرم افزار پشتیبانی یا پایگاه داده محصولات
- کنترل دسترسی کاربران به اطلاعات مختلف
- ثبت و تحلیل درخواست ها برای بهبود خدمات
- تولید خروجی در قالب مشخص برای استفاده در فرایندهای نرم افزاری
- اجرای مدل در زیرساخت مورد تایید سازمان
- طراحی گردش کارهایی که علاوه بر پاسخ متنی، عملیات مشخصی انجام می دهند
البته اختصاصی بودن به معنای آموزش مدل از ابتدا نیست. در بسیاری از پروژه ها، استفاده از مدل موجود و طراحی یک لایه نرم افزاری مناسب، همراه با بازیابی اطلاعات و اتصال به سرویس های مورد نیاز، راهکار عملی تری است.
برای تصمیم گیری باید هزینه توسعه، نگهداری، به روزرسانی، امنیت و ارزیابی در نظر گرفته شود. گاهی یک راهکار ساده مبتنی بر جست وجوی دقیق یا یک مدل کوچک تخصصی، بهتر از چت باتی پیچیده عمل می کند. هدف اصلی باید حل مسئله باشد، نه استفاده از مدل بزرگ تر یا فناوری پیچیده تر.
۱۴. چک لیست فنی پیش از شروع پروژه
پیش از آغاز پیاده سازی، پاسخ دادن به سوال های زیر می تواند از تغییرهای پرهزینه در ادامه کار جلوگیری کند.
درباره مسئله
- وظیفه اصلی سامانه چیست و چه خروجی ای باید تولید کند؟
- کاربران چه نوع پرسش ها و ورودی هایی ارسال می کنند؟
- کدام خطاها قابل قبول نیستند و کدام موارد باید به کارشناس ارجاع شوند؟
درباره داده
- منابع اطلاعاتی معتبر کدام اند؟
- آیا متن اسناد قابل استخراج است یا به OCR نیاز داریم؟
- چه اطلاعاتی محرمانه است و چه سطح دسترسی ای باید اعمال شود؟
- به روزرسانی و حذف اسناد چگونه انجام خواهد شد؟
درباره مدل
- کدام مدل ها با زبان و وظیفه مورد نظر سازگارترند؟
- آیا مدل از نظر مجوز برای کاربرد تجاری مناسب است؟
- آیا استفاده از API بهتر است یا اجرای محلی؟
- آیا مدل به تنهایی کافی است یا به RAG یا تنظیم دقیق نیاز داریم؟
درباره ارزیابی
- مجموعه آزمون اولیه شامل چه نمونه هایی است؟
- کیفیت بازیابی و صحت پاسخ چگونه سنجیده می شوند؟
- چگونه پاسخ های بدون پشتوانه را شناسایی می کنیم؟
- معیار قابل قبول برای زمان پاسخ و هزینه چیست؟
درباره استقرار
- چه تعداد کاربر هم زمان پیش بینی می شود؟
- سیستم چگونه خطاهای سرویس های وابسته را مدیریت می کند؟
- چه داده هایی ثبت و برای چه مدتی نگهداری می شوند؟
- نسخه مدل و اسناد چگونه کنترل و به روزرسانی خواهند شد؟
پاسخ این سوال ها کمک می کند دامنه پروژه، معماری اولیه و معیارهای موفقیت پیش از صرف منابع زیاد مشخص شوند.
جمع بندی
پیاده سازی یک سامانه هوش مصنوعی برای پردازش متن، صرفا به انتخاب یک مدل زبانی و اتصال آن به رابط چت محدود نمی شود. کیفیت نهایی به مجموعه ای از تصمیم ها وابسته است که از تعریف مسئله و آماده سازی داده آغاز می شوند و تا بازیابی اطلاعات، طراحی دستور، ارزیابی، امنیت و استقرار ادامه پیدا می کنند.
برای پاسخ گویی بر اساس اسناد اختصاصی، معماری RAG می تواند گزینه مناسبی باشد. در این رویکرد، اسناد به بخش های قابل بازیابی تقسیم می شوند، با مدل Embedding به نمایش برداری تبدیل می شوند و بخش های مرتبط پیش از تولید پاسخ در اختیار مدل قرار می گیرند. با این حال، کیفیت بازیابی، صحت ارجاع ها و توانایی سیستم در اعلام نبود اطلاعات کافی باید جداگانه ارزیابی شوند.
در پروژه های واقعی، بهتر است ابتدا یک نمونه محدود با داده های مشخص ساخته شود و با مجموعه ای از پرسش های واقعی مورد آزمون قرار گیرد. پس از اندازه گیری کیفیت، زمان پاسخ و هزینه، می توان درباره توسعه قابلیت ها، تغییر مدل یا استقرار در مقیاس بزرگ تر تصمیم گرفت.
همین اصول در ساخت چت بات اختصاصی نیز کاربرد دارند. یک چت بات قابل اتکا باید علاوه بر تولید پاسخ روان، به منابع معتبر دسترسی داشته باشد، محدودیت های دسترسی را رعایت کند، خطاهایش قابل بررسی باشند و در شرایط عملیاتی عملکرد پایداری ارائه دهد. انتخاب معماری مناسب و ارزیابی مستمر، مهم تر از استفاده از یک مدل مشهور یا پیچیده است.