ساخت پایگاه دانش با هوش مصنوعی؛ راهنمای پشتیبانی

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

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

پایگاه دانش را حول کار کاربر طراحی کنید#

نقطه شروع، کارهایی است که کاربر می‌خواهد انجام دهد: ورود، دریافت فایل، پیدا کردن سفارش یا تغییر تنظیمات. ساختار مبتنی بر نام تیم‌ها برای کاربر بیرونی همیشه روشن نیست. او ممکن است نداند مشکلش مربوط به تیم فنی است یا عملیات؛ اما می‌داند «لینک دریافت فایل را پیدا نمی‌کنم».

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

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

سؤال‌های واقعی را به بریف محتوا تبدیل کنید#

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

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

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

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

برای هر مقاله یک مجموعه منبع تأییدشده بسازید#

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

یک جدول کوچک کافی است: «اطلاعات»، «منبع»، «وضعیت» و «محدوده انتشار». مثلاً نام دقیق دکمه از رابط فعلی گرفته می‌شود؛ مهلت دریافت فایل از سیاست تأییدشده می‌آید. اگر مهلت هنوز معلوم نیست، جمله «همیشه می‌توانید دانلود کنید» نباید در مقاله ظاهر شود.

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

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

قالب ثابت مقاله پشتیبانی را تعریف کنید#

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

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

نمونه مقاله برای سرویس فرضی فایل آموزشی#

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

عنوان: لینک فایل آموزشی را از کجا پیدا کنم؟

این راهنما برای شماست اگر: فایل در سرویس نمونه برای حساب شما فعال شده اما لینک دریافت آن را پیدا نمی‌کنید.

پیش‌نیاز: با همان حسابی وارد شوید که فایل برای آن فعال شده است.

مراحل: بخش «فایل‌های من» را باز کنید؛ عنوان فایل را پیدا کنید؛ گزینه دریافت کنار همان عنوان را انتخاب کنید.

نتیجه مورد انتظار: فرایند دریافت فایل شروع می‌شود.

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

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

مقاله‌ها را برای جستجوی فارسی قابل پیدا کردن کنید#

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

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

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

لحن، طول و تصویر راهنما را کنترل کنید#

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

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

پیش‌نویس مقاله را از نظر زبان پشتیبانی بازبینی کن. جمله‌های مبهم، سرزنش‌کننده یا دارای چند اقدام را پیدا کن. نام دکمه‌ها، سیاست‌ها و ترتیب مراحل را تغییر نده. برای هر مورد، جمله اصلی، دلیل مشکل و پیشنهاد جایگزین بده. اگر برای اصلاح به اطلاعات محصول نیاز است، سؤال بنویس.

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

ارزیابی را با انجام کار و سؤال‌های تازه انجام دهید#

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

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

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

اتصال پایگاه دانش به چت‌بات را جداگانه ارزیابی کنید#

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

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

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

مالکیت و برنامه به‌روزرسانی را از روز اول ثبت کنید#

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

مرکز راهنماهای موجود نیز اغلب امکان ساخت مقاله و مدیریت انتشار دارند؛ برای نمونه راهنمای رسمی مقاله پایگاه دانش Atlassian فرایند ایجاد مقاله را توضیح می‌دهد. امکانات و دسترسی ابزار انتخابی خودتان را جداگانه بررسی کنید. داشتن یک محل انتشار، جای فرایند تأیید محتوا را نمی‌گیرد.

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