شخصیت غیرقابلبازی در بسیاری از پروژهها مجموعهای از دیالوگهای از پیش نوشتهشده و چند رفتار تکراری دارد. این روش برای بازیهای خطی مناسب است، اما در شبیهسازی آموزشی، بازی نقشآفرینی یا تجربه تبلیغاتی تعاملی، کاربر انتظار دارد شخصیت بتواند منظور او را بفهمد و پاسخی متناسب با شرایط ارائه کند.
مدلهای زبانی این امکان را گسترش دادهاند، ولی اتصال مستقیم یک مدل به کادر گفتگو راهحل کامل نیست. NPC باید نقش مشخص، اطلاعات محدود، حافظه کنترلشده و امکان اجرای اعمال معتبر داشته باشد. همچنین هزینه درخواست، زمان پاسخ، حریم خصوصی و احتمال تولید محتوای نامناسب باید از ابتدای طراحی در نظر گرفته شود.
ساخت NPC هوشمند در Unity چگونه انجام میشود؟
در ساخت NPC هوشمند در Unity معمولاً مدل زبانی مسئول تولید متن یا پیشنهاد تصمیم سطح بالا است و سیستم قطعی بازی کنترل نهایی را حفظ میکند. مدل میتواند تشخیص دهد بازیکن چه میخواهد، اما باز کردن در، تحویل جایزه یا تغییر مأموریت باید توسط کد بازی و پس از اعتبارسنجی انجام شود.
معماری مناسب از چند لایه تشکیل میشود: رابط دریافت متن یا صدا، سرویس واسط سمت سرور، مدل زبانی، حافظه گفتگو، پایگاه دانش، موتور رفتار و لایه ایمنی. جدا بودن این اجزا باعث میشود مدل، ارائهدهنده سرویس یا قواعد NPC بدون بازنویسی کامل پروژه تغییر کنند.
تفاوت گفتگو با تصمیمگیری
گفتگو یعنی تولید پاسخی طبیعی بر اساس نقش و اطلاعات موجود. تصمیمگیری یعنی انتخاب عملی مانند دنبال کردن بازیکن، رفتن به نقطه مشخص یا آغاز معامله. بهتر است خروجی تصمیم به شکل داده ساختاریافته دریافت شود و فقط اعمالی پذیرفته شوند که در فهرست مجاز بازی تعریف شدهاند.
برای مثال مدل میتواند عملی با مفهوم پیشنهاد مأموریت و شناسه مشخص برگرداند. سیستم Unity بررسی میکند مأموریت وجود دارد، شرایط آن برقرار است و بازیکن قبلاً آن را تکمیل نکرده است. تنها پس از این کنترلها وضعیت بازی تغییر میکند؛ بنابراین متن تولیدشده هیچ دسترسی مستقیمی به داده حساس یا API اجرایی ندارد.
حافظه کوتاهمدت و بلندمدت
ارسال تمام تاریخچه گفتگو در هر درخواست هم پرهزینه است و هم میتواند کیفیت پاسخ را کاهش دهد. حافظه کوتاهمدت چند پیام اخیر را نگه میدارد، درحالیکه خلاصهای از رویدادهای مهم مانند نام بازیکن، تصمیم قبلی یا نتیجه مأموریت در حافظه بلندمدت ذخیره میشود.
هر دادهای نباید به حافظه تبدیل شود. اطلاعات شخصی کاربر، متن نامناسب یا دستورات مخرب باید فیلتر شوند. برای بازی آنلاین، حافظه بهتر است در بکاند و متصل به شناسه حساب ذخیره شود. سیاست حذف داده و امکان پاک کردن سوابق نیز بخشی از طراحی حرفهای محصول است.
استفاده از RAG و پایگاه دانش
اگر NPC باید درباره داستان، محصول، تجهیزات صنعتی یا محتوای آموزشی پاسخ دقیق بدهد، میتوان اطلاعات معتبر را در پایگاه دانش قرار داد. سیستم ابتدا بخشهای مرتبط را بازیابی میکند و سپس آنها را همراه پرسش برای مدل میفرستد. این روش که معمولاً RAG نامیده میشود، وابستگی به حافظه عمومی مدل را کاهش میدهد.
پایگاه دانش باید نسخهبندی شود و منبع هر پاسخ قابل ردیابی باشد. در شبیهسازی پزشکی یا صنعتی بهتر است پاسخهایی که روی ایمنی اثر دارند از مسیرهای قطعی عبور کنند. مدل زبانی نباید جایگزین دستورالعمل تأییدشده، مربی یا سیستم هشدار رسمی شود.
ترکیب مدل زبانی با Behavior Tree
Behavior Tree، State Machine و Utility AI ابزارهای مناسبی برای کنترل رفتار لحظهای هستند. مدل زبانی میتواند هدفی مانند آرام کردن کاربر را انتخاب کند، اما حرکت، انیمیشن، فاصله مناسب و ترتیب اقدامات توسط Behavior Tree اجرا میشود. این جداسازی رفتار را قابل آزمایش و تکرارپذیر نگه میدارد.
فراخوانی مدل در هر فریم منطقی نیست. درخواست فقط هنگام رویداد مهم، پایان جمله یا نیاز به انتخاب جدید ارسال میشود. NPC در فاصله دریافت پاسخ میتواند از رفتارهای محلی مانند نگاه کردن، انتظار، گشتزنی یا پخش انیمیشن استفاده کند تا تجربه متوقف نشود.
گفتگوی صوتی و زبان فارسی
برای مکالمه صوتی سه مرحله نیاز است: تبدیل گفتار به متن، پردازش مدل و تبدیل پاسخ به صدا. زمان کل این زنجیره روی حس طبیعی بودن اثر مستقیم دارد. نمایش زیرنویس، پخش نشانه انتظار و امکان قطع کردن پاسخ طولانی میتواند تجربه کاربر را بهتر کند.
در زبان فارسی باید نیمفاصله، اعداد، نامهای خاص و لحن رسمی یا محاورهای آزمایش شوند. صدای تولیدی نیز باید با سن، نقش و فضای شخصیت هماهنگ باشد. اگر محصول برای کودک ساخته میشود، فیلتر محتوا و محدود کردن موضوعات گفتگو اهمیت بیشتری دارد.
امنیت در برابر Prompt Injection
بازیکن ممکن است تلاش کند نقش NPC را تغییر دهد، دستورهای داخلی را استخراج کند یا مدل را وادار به اجرای عمل غیرمجاز کند. دستور سیستمی بهتنهایی محافظ کافی نیست. دسترسی مدل باید حداقلی باشد و هر خروجی قبل از اجرا با Schema، فهرست مجاز و قوانین سمت سرور کنترل شود.
کلید سرویس مدل نباید داخل Build یونیتی قرار بگیرد، زیرا قابل استخراج است. درخواستها باید از بکاند عبور کنند تا احراز هویت، محدودیت نرخ، ثبت خطا و کنترل هزینه انجام شود. لاگها نیز نباید اطلاعات حساس را بدون رمزنگاری و سیاست نگهداری مشخص ذخیره کنند.
هزینه و تأخیر پاسخ
هزینه به تعداد کاربران، طول ورودی و خروجی، مدل انتخابی، صدا و میزان حافظه بستگی دارد. استفاده از مدل کوچک برای تشخیص نیت و مدل قویتر فقط برای مکالمات مهم، هزینه را کاهش میدهد. کش کردن پاسخهای عمومی و خلاصهسازی تاریخچه نیز مؤثر است.
برای کنترل تأخیر میتوان پاسخ را بهصورت Streaming نمایش داد یا بخش ابتدایی صدا را زودتر پخش کرد. بااینحال باید برای قطعی سرویس حالت جایگزین وجود داشته باشد؛ مثلاً NPC پاسخ ثابت بدهد یا مأموریت بدون گفتگو ادامه یابد. وابستگی کامل گیمپلی اصلی به سرویس بیرونی ریسک عملیاتی ایجاد میکند.
مراحل اجرای پروژه
- تعریف نقش، دانش، محدودیتها و هدف تجاری NPC
- ساخت Prototype متنی با یک سناریوی کوچک
- طراحی بکاند امن و خروجی ساختاریافته
- اتصال رفتارها، انیمیشن و سیستم مأموریت
- افزودن حافظه، RAG و در صورت نیاز صدا
- آزمایش هزینه، تأخیر، سوءاستفاده و کیفیت فارسی
نمونه اولیه محدود ممکن است در چند هفته ساخته شود، اما سیستم تولیدی دارای صدا، حافظه و مدیریت محتوا زمان بیشتری نیاز دارد. در JPGames ابتدا سناریوی اصلی و شاخص موفقیت تعیین میشود تا مشخص شود هوش مصنوعی واقعاً چه ارزشی ایجاد میکند. برای برآورد ساخت NPC هوشمند در Unity میتوان تعداد شخصیتها، زبانها و نوع تعامل را برای بررسی ارسال کرد.