شهریور
آموزش هوش مصنوعی
پروژهٔ پایانی: بات پشتیبانی روی مستندات شرکت خودتان
تا اینجای این مجموعه، هر مقاله یک لایه از ساخت یک بات پشتیبانی جدی را باز کرده: خط لولهٔ RAG، Hybrid Search و rerank، اتصال به کانالها، Tool Calling، و تحویل به انسان. این مقالهٔ پایانی همهٔ این لایهها را در یک پروژهٔ گامبهگام کنار هم میگذارد تا بتوانید همین حالا، روی مستندات واقعی شرکت خودتان، یک نسخهٔ اول کارکردی بسازید. اگر جایی در مسیر گیر کردید، به مقالهٔ مربوطه در همین مجموعه برگردید؛ نقطهٔ شروع کلی هم همیشه نقشهٔ راه ساخت چتبات تخصصی است.
لیست مطالب
مراحل پروژه
- جمعآوری و ارزیابی اسناد منبع. فهرست کاملی از مستنداتی که بات باید روی آنها جواب بدهد تهیه کنید: راهنمای محصول، سؤالات متداول، سیاست بازگشت کالا، مستندات فنی. هر سند را از نظر بهروز بودن بررسی کنید؛ سندی که خودتان به آن اعتماد ندارید، نباید وارد پایگاه دانش بات شود.
- پیادهسازی خط لولهٔ ingestion و chunking. فایلها را به متن ساختیافته تبدیل کنید، جدولها و عنوانها را حفظ کنید، و تکهبندی را بر اساس ساختار سند انجام دهید، نه تعداد کاراکتر خام. هر تکه باید ارجاع منبع خودش را همراه داشته باشد.
- ساخت نمایهٔ برداری و لایهٔ بازیابی. تکهها را embedding و در یک vector store ذخیره کنید. اگر پایگاه دانش شما پر از نام محصول، شمارهمدل یا کد خطاست، از همین مرحله جستوجوی کلیدواژهای را کنار جستوجوی برداری اضافه کنید.
- افزودن rerank در صورت نیاز. اگر جوابهای اولیه نامرتبط یا نادقیق بودند، یک لایهٔ rerank روی نتایج بازیابی اضافه کنید تا فقط بهترین تکهها به مدل زبانی برسند.
- نوشتن prompt سیستمی با قید ارجاع اجباری. مدل باید صریحاً موظف شود فقط بر اساس تکههای بازیابیشده جواب دهد و منبع هر ادعا را ذکر کند؛ اگر جواب در اسناد نیست، باید صادقانه بگوید نمیداند.
- تعریف ابزارهای لازم با حداقل دسترسی. فهرست کارهایی که بات باید واقعاً انجام دهد (استعلام سفارش، ثبت تیکت، بررسی موجودی) را مشخص کنید و برای هرکدام یک ابزار مجزا با طرحوارهٔ ورودی محدود بسازید؛ هیچ ابزار همهکارهای نسازید.
- اتصال به اولین کانال. یکی از تلگرام، واتساپ یا ویجت وب را انتخاب کنید و یک آداپتور نازک برای آن بنویسید که مسئول قالببندی پیام و مدیریت احراز هویت همان کانال است.
- طراحی منطق تحویل به انسان. سیگنالهای ارجاع (تکرار سؤال، خشم کاربر، موضوع مالی یا حقوقی، عدم اطمینان بات) را پیادهسازی کنید و مطمئن شوید زمینهٔ کامل گفتوگو در لحظهٔ انتقال به اپراتور منتقل میشود.
- تست با سؤالات واقعی کاربران. فهرستی از سؤالات واقعی (نه ساختگی) از تیم پشتیبانی یا تیکتهای قدیمی جمع کنید و بات را با آنها محک بزنید؛ بهخصوص سؤالات مرزی که باید به انسان تحویل داده شوند.
- راهاندازی لاگ و بازبینی دورهای. هر پرسش، هر تکهٔ بازیابیشده، هر فراخوانی ابزار و هر ارجاع انسانی را لاگ کنید تا بتوانید هفتگی یا ماهانه پایگاه دانش و prompt را بر اساس رفتار واقعی کاربران اصلاح کنید.
پیش از افزودن کانال دوم یا ابزار پیچیدهتر، نگاه دقیقتری به معماری کلی ایجنت لازم است؛ راهنمای کامل ایجنت هوش مصنوعی در این مرحله کمک میکند تا تصمیمهای بعدی روی پایهٔ درستی گرفته شوند، و اگر ابزارهایی با دسترسی نوشتنی اضافه میکنید، مرور نقشهٔ راه امنیت هوش مصنوعی پیش از انتشار عمومی توصیه میشود.
چکلیست خودارزیابی پیش از انتشار
| مورد بررسی | وضعیت مطلوب |
|---|---|
| هر جواب بات ارجاع منبع دارد | بله، بدون استثنا |
| مدل وقتی جواب را نمیداند، صادقانه اعلام میکند | بله، بهجای حدس زدن |
| سؤالات با نام محصول یا شمارهٔ مدل درست جواب داده میشوند | بله، با Hybrid Search در صورت نیاز |
| هر ابزار فقط به دادهٔ لازم برای همان کار دسترسی دارد | بله، بدون ابزار همهکاره |
| عملیات مالی یا حساس بدون تأیید انسانی اجرا نمیشود | بله |
| تکرار سؤال یا خشم کاربر بهموقع تشخیص داده میشود | بله، ارجاع خودکار به انسان |
| زمینهٔ کامل گفتوگو در handoff منتقل میشود | بله، بدون نیاز به تکرار کاربر |
| قالب پیام با محدودیتهای هر کانال سازگار است | بله، برای هر کانال جداگانه تستشده |
| لاگ کامل پرسش، بازیابی و فراخوانی ابزار فعال است | بله |
اشتباهات رایج در اجرای این پروژه
اولین اشتباه رایج، شروع همزمان با چند کانال و چند ابزار پیچیده است؛ این کار دیباگ را تقریباً غیرممکن میکند چون وقتی جوابی نادرست است، مشخص نیست مشکل از تکهبندی است، از بازیابی، از prompt، یا از آداپتور کانال. راه درست، ساختن یک نسخهٔ حداقلی روی یک کانال با یک زیرمجموعهٔ کوچک از اسناد است، و افزودن لایهها فقط بعد از اطمینان از پایداری لایهٔ قبلی. اشتباه دوم، اعتماد کورکورانه به جوابهای اولیهٔ بات بدون تست با سؤالات واقعی است؛ سؤالاتی که خودتان بهعنوان توسعهدهنده طراحی میکنید معمولاً «تمیزتر» از سؤالات واقعی کاربراناند و نمیتوانند مشکلات واقعی را نشان دهند. اشتباه سوم، فراموش کردن بهروزرسانی پایگاه دانش بعد از انتشار است؛ بسیاری از تیمها روز اول وقت زیادی برای ساخت خط لوله میگذارند اما هیچ فرایندی برای اضافه یا حذف کردن سند تعریف نمیکنند، و بعد از چند ماه بات روی اطلاعات کهنه جواب میدهد.
بعد از راهاندازی اول
راهاندازی نسخهٔ اول پایان پروژه نیست، شروع یک چرخهٔ بهبود دائمی است. لاگ سؤالاتی که بات نتوانست خوب جواب دهد یا مجبور به ارجاع انسانی شد را هفتگی مرور کنید؛ این لاگها دقیقاً میگویند کدام سند ناقص است، کدام ابزار کم است، یا کدام سؤال باید به پایگاه دانش اضافه شود. با همین روش، بات بهمرور از یک نسخهٔ اول محدود به یک ابزار واقعاً قابلاتکا برای پشتیبانی تبدیل میشود.
جمعبندی
- این پروژه را مرحلهبهمرحله جلو ببرید؛ اضافه کردن همزمان همهٔ لایهها (RAG، ابزار، چند کانال) از ابتدا ریسک دیباگ را بالا میبرد.
- هر مرحله را با سؤالات واقعی کاربران محک بزنید، نه سؤالات ساختگی که خودتان طراحی کردهاید.
- چکلیست خودارزیابی را پیش از هر انتشار عمومی جدی مرور کنید، نه فقط یکبار در ابتدای پروژه.
- ارجاع به منبع و تشخیص بهموقع تحویل انسانی، دو معیاری هستند که اعتماد کاربر به بات را میسازند یا از بین میبرند.
- لاگ و بازبینی دورهای را از روز اول فعال کنید؛ بدون آن، بهبود بات فقط حدسوگمان میماند.
