ساخت چت بات با اسناد شرکت؛ برای استفادهٔ واقعی چه لازم است؟

ساخت چت بات با اسناد شرکت یعنی همکاران سؤال بپرسند و پاسخ را از منابع شرکت بگیرند؛ اما برای استفادهٔ روزانه، وصل‌کردن چند فایل به یک مدل کافی نیست. باید مطمئن شوید متن درست خوانده می‌شود، پاسخ به منبع تکیه دارد و هر فرد فقط اطلاعات مجاز خودش را می‌بیند.

این کار شبیه راه‌اندازی یک میز راهنمای داخلی است. کسی که پشت میز می‌نشیند باید پروندهٔ درست را پیدا کند، بداند کدام نسخه معتبر است و چه اطلاعاتی را می‌تواند به چه کسی بگوید. چت‌بات هم به همین نظم نیاز دارد؛ با این تفاوت که این نظم باید در نرم‌افزار و شیوهٔ ادارهٔ آن پیاده شود.

• مشخص‌کردن کاربران، سؤال‌ها و حدود پاسخ‌گویی
• خواندن درست فایل‌ها و آماده‌کردن آن‌ها برای جست‌وجو
• پیداکردن بخش مرتبط، حتی با بیان متفاوت سؤال
• پاسخ مستند و برخورد درست با اطلاعات ناقص
• ورود کاربران و رعایت دسترسی هر فرد به اسناد
• آزمایش کیفیت و پیدا‌کردن علت پاسخ‌های اشتباه
• انتخاب محل اجرا و مسیر پردازش اطلاعات
• به‌روزرسانی اسناد، کنترل هزینه و نگهداری سرویس

چت‌بات راهنمای کارکنان با چت‌بات پاسخ‌گویی به مشتری یکسان نیست. کاربران، اطلاعات قابل نمایش و حتی معنی «پاسخ درست» فرق می‌کند. برای مثال، دستیار منابع انسانی می‌تواند روش درخواست مرخصی را توضیح دهد، اما نباید از روی یک متن عمومی دربارهٔ پروندهٔ شخصی کارمند تصمیم بگیرد.

از ابتدا باید موضوع‌های مجاز، سؤال‌های خارج از محدوده و مسئول رسیدگی به موارد بی‌پاسخ روشن باشند. صفحهٔ گفتگو هم باید برای کاربران قابل استفاده باشد: بتوانند سؤال بپرسند، منبع پاسخ را ببینند و مورد اشتباه را به مسئول مربوط اطلاع دهند.

اطلاعات شرکت معمولاً در یک فایل تمیز جمع نشده است؛ بخشی در پی‌دی‌اف، بخشی در فایل‌های آفیس و گاهی در تصویر یا جدول است. بارگذاری موفق فایل به‌تنهایی نشان نمی‌دهد که متن، ترتیب صفحه‌ها یا ارتباط عدد با عنوان ستون درست خوانده شده است.

سامانه باید فایل‌ها را بخواند، متن را به بخش‌های مناسب تقسیم کند و آن‌ها را برای جست‌وجو آماده نگه دارد. هر بخش هم باید به فایل اصلی وصل بماند تا بعداً بتوان پاسخ را بررسی کرد. فایل ناخوانا یا پردازش ناموفق باید قابل پیگیری باشد؛ نباید بی‌سروصدا از منابع پاسخ حذف شود.

کاربر لزوماً با واژه‌های داخل سند سؤال نمی‌پرسد. ممکن است بگوید «برای دورکاری از کجا اجازه بگیرم؟» درحالی‌که عنوان سند «آیین‌نامهٔ حضور کارکنان» است. جست‌وجو باید بخش مرتبط با سؤال را پیدا کند، نه فقط فایلی که چند کلمهٔ مشترک دارد.

اگر متن اشتباه به مدل برسد، روان‌بودن جواب کمکی نمی‌کند. کیفیت جست‌وجو باید با سؤال‌های واقعی و بیان‌های متفاوت آن‌ها سنجیده شود. توضیح آنتروپیک دربارهٔ جست‌وجوی اسناد نشان می‌دهد که حتی شیوهٔ تقسیم متن و حفظ اطلاعات اطراف هر بخش، روی پیداکردن منبع اثر دارد.

پاسخ باید روشن کند به کدام سند تکیه دارد. اگر آیین‌نامه دربارهٔ مهلت ثبت درخواست چیزی نگفته است، دستیار نباید یک مهلت بسازد. اگر دو سند با هم تعارض دارند یا سؤال ناقص است، باید ابهام را نشان دهد و برای ادامه، اطلاعات لازم را بخواهد.

این رفتار به تنظیم دستیار و آزمون پاسخ‌ها نیاز دارد. نمایش منبع هم کافی نیست؛ باید بررسی شود که منبع واقعاً ادعای پاسخ را پشتیبانی می‌کند. مطلب پاسخ مستند هوش مصنوعی همین تفاوت را توضیح می‌دهد.

راهنمای مرخصی ممکن است برای همهٔ کارکنان باز باشد، اما پروندهٔ حقوق و مزایا نه. برای استفادهٔ واقعی، ورود کاربر، عضویت او در سازمان و واحد مربوط باید مشخص باشد. دسترسی هم باید هنگام جست‌وجو و خواندن فایل بررسی شود، نه فقط هنگام نمایش فهرست فایل‌ها.

نوشتن «اطلاعات محرمانه را نگو» در دستور دستیار جای این کنترل را نمی‌گیرد. با تغییر سمت یا خروج یک همکار، دسترسی او هم باید به‌روز شود. مسیر نگهداری گفتگوها و فایل‌ها و دسترسی به گزارش‌ها نیز بخشی از همین تصمیم است. در راهنمای امنیت هوش مصنوعی سازمانی این خطرها را جدا بررسی کرده‌ایم.

آزمون باید سؤال‌های معمولی و حالت‌های دشوار را پوشش دهد: جواب در اسناد نیست، دو نسخه با هم فرق دارند، جدول بد خوانده شده یا کاربر به سند موردنیاز دسترسی ندارد. پیش از راه‌اندازی باید معلوم باشد چه نتیجه‌ای پذیرفتنی است و چه خطایی مانع استفاده می‌شود.

وقتی جواب اشتباه است، باید بتوان علت را پیدا کرد: متن فایل بد خوانده شده، بخش نامرتبط پیدا شده یا مدل از متن درست نتیجهٔ اشتباه گرفته است؟ بعد از تغییر مدل، اسناد یا تنظیمات جست‌وجو هم لازم است این سؤال‌ها دوباره آزموده شوند.

برای بعضی شرکت‌ها سرویس ابری مناسب است؛ بعضی دیگر باید اطلاعات را داخل شبکهٔ خود نگه دارند. انتخاب فقط دربارهٔ محل نصب صفحهٔ گفتگو نیست. مدل، پردازش اسناد، محل ذخیرهٔ فایل‌ها و اتصال‌های بیرونی هم باید با شرایط سازمان هماهنگ باشند.

اگر اجرای کاملاً محلی لازم است، مدل و منابع پردازشی آن هم بخشی از طراحی‌اند. نصب برنامه روی سرور شرکت، درحالی‌که درخواست‌ها به مدل بیرونی می‌روند، به معنی اجرای کاملاً محلی نیست.

آیین‌نامه تغییر می‌کند، سند تازه می‌آید و دسترسی افراد عوض می‌شود. باید مسئول نسخهٔ معتبر مشخص باشد و متن قدیمی از منابع پاسخ کنار برود. همچنین باید معلوم باشد خرابی پردازش فایل یا قطع سرویس را چه کسی پیگیری می‌کند و پشتیبان‌گیری و بازیابی چطور انجام می‌شود.

با بیشترشدن کاربران، زمان پاسخ و هزینه هم اهمیت بیشتری پیدا می‌کند. ثبت خطاها، بررسی عملکرد زیر بار هم‌زمان و دیدن مصرف اعضا برای ادامهٔ کار لازم‌اند. بودجه باید خواندن و آماده‌سازی اسناد، جست‌وجو و پاسخ‌گویی را در نظر بگیرد؛ نه فقط هزینهٔ یک پیام آزمایشی. هزینهٔ هوش مصنوعی سازمانی این مسیر را بیشتر توضیح می‌دهد.

در کانوکس، فضای گفتگو و تعریف دستیار، بارگذاری و پردازش اسناد، جست‌وجو در فایل‌های مجاز و ارجاع به منابع در یک محصول قرار دارند. دسترسی‌های شخصی، واحدی و سازمانی هم به ساختار تیم وصل‌اند. برای راه‌اندازی چت‌بات اسناد، لازم نیست هرکدام از این بخش‌ها را جدا بسازید و بعد به هم متصل کنید.

گزارش مصرف و سهمیهٔ اعضا برای مدیریت هزینه در دسترس است. بر اساس شرایط اطلاعاتتان هم می‌توانید سرویس ابری، نصب در زیرساخت سازمان یا اجرای کاملاً محلی با مدل محلی را بررسی کنید. به این ترتیب، انتخاب محل اجرا و مدیریت کاربران جدا از ابزار پاسخ‌گویی رها نمی‌شود.

کار تیم شما روی چیزهایی متمرکز می‌شود که مخصوص شرکت خودتان است: اسناد معتبر کدام‌اند، چه کسی اجازهٔ دیدنشان را دارد و چه پاسخی برای کارتان قابل قبول است. در دموی سازمانی، این نیازها را کنار امکانات آمادهٔ کانوکس بررسی می‌کنیم و مسیر راه‌اندازی و مسئولیت‌های نگهداری را روشن می‌کنیم.