ساخت سوالات متداول با هوش مصنوعی؛ آموزش تولید FAQ حرفهای برای سایت و محصول
در این راهنما یاد میگیرید چگونه با هوش مصنوعی برای سایت، محصول، فروشگاه و مرکز پشتیبانی FAQ دقیق بسازید؛ از استخراج سوالات واقعی تا ویرایش پاسخها، خروجی JSON و خودکارسازی با API درواره.
صفحه سوالات متداول یا FAQ یکی از کاربردیترین بخشهای یک وبسایت است. اگر این صفحه براساس نیاز واقعی کاربران نوشته شود، میتواند پیش از تماس مشتری به بسیاری از ابهامها پاسخ دهد، مسیر خرید را کوتاهتر کند و بار تکراری تیم پشتیبانی را کاهش دهد.
مشکل اینجاست که بسیاری از صفحات FAQ به فهرستی از سوالات عمومی، تکراری و کمارزش تبدیل میشوند. سوالاتی مانند «چرا ما را انتخاب کنید؟» یا پاسخهایی مانند «برای اطلاعات بیشتر با ما تماس بگیرید» معمولاً مشکل مشخصی از کاربر حل نمیکنند.
هوش مصنوعی میتواند در استخراج سوال از اسناد، دستهبندی پرسشهای کاربران، بازنویسی پاسخها، یکدستسازی لحن و تولید خروجی ساختاریافته کمک کند. بااینحال، پاسخ نهایی باید براساس اطلاعات واقعی کسبوکار نوشته و توسط مسئول مربوطه تأیید شود.
در این آموزش یاد میگیریم چگونه با هوش مصنوعی سوالات متداول دقیق، کوتاه، قابلجستوجو و مناسب سایت، محصول، فروشگاه اینترنتی، نرمافزار و مرکز پشتیبانی تولید کنیم.
FAQ چیست؟
FAQ مخفف Frequently Asked Questions و به معنی «سوالات متداول» است. این بخش مجموعهای از پرسشهای پرتکرار کاربران را همراه با پاسخهای مستقیم و قابلفهم نمایش میدهد.
سوالات متداول میتوانند در بخشهای مختلف سایت قرار بگیرند:
- صفحه اصلی
- صفحه محصول
- صفحه قیمتگذاری
- صفحه ثبتنام
- صفحه پرداخت
- مرکز راهنما
- مستندات فنی
- صفحه خدمات
- صفحه تماس
- فرایند ورود و بازیابی حساب
- داخل اپلیکیشن
- ربات پاسخگو
- پنل کاربری
- پیامهای خودکار پشتیبانی
یک FAQ خوب نباید جای مستندات کامل را بگیرد. هدف آن ارائه پاسخ سریع به سوالات مشخص و پرتکرار است.
تفاوت FAQ با پایگاه دانش چیست؟
FAQ و Knowledge Base هدف مشابهی دارند، اما از نظر عمق محتوا متفاوتاند.
| ویژگی | سوالات متداول | پایگاه دانش |
|---|---|---|
| طول پاسخ | کوتاه و مستقیم | مفصل و مرحلهبهمرحله |
| نوع سوال | پرتکرار و مشخص | آموزشی و عیبیابی |
| ساختار | سوال و جواب | مقاله، دستهبندی و راهنما |
| زمان مطالعه | کوتاه | متوسط یا طولانی |
| هدف | رفع سریع ابهام | آموزش کامل و حل مسئله |
| مثال | چگونه رمز عبور را تغییر دهم؟ | راهنمای مدیریت امنیت حساب |
اگر پاسخ یک سوال به چند مرحله، تصویر یا مثال نیاز دارد، بهتر است در FAQ خلاصه آن را بنویسید و به مقاله کامل پایگاه دانش لینک بدهید.
چرا ساخت FAQ با هوش مصنوعی کاربردی است؟
هوش مصنوعی میتواند فرایند پراکنده تولید سوالات متداول را ساختاریافته کند.
استخراج سوال از محتوای موجود
مدل میتواند صفحه محصول، مستندات، فایل راهنما یا متن قرارداد خدمات را بخواند و سوالات احتمالی کاربران را استخراج کند.
تحلیل گفتگوهای پشتیبانی
میتوانید متن تیکتها، ایمیلها یا مکالمات ناشناسسازیشده را دستهبندی و موضوعات پرتکرار را شناسایی کنید.
کوتاهسازی پاسخها
پاسخهای طولانی تیم پشتیبانی را میتوان به نسخه کوتاه و مناسب FAQ تبدیل کرد.
یکدستسازی لحن
اگر پاسخها توسط افراد مختلف نوشته شده باشند، ممکن است لحن آنها متفاوت باشد. هوش مصنوعی میتواند لحن را رسمی، دوستانه یا فنی و یکپارچه کند.
ساخت نسخه برای مخاطبان مختلف
یک پاسخ را میتوان برای کاربر عمومی، مدیر سازمان یا توسعهدهنده بازنویسی کرد.
تولید خروجی ساختاریافته
مدل میتواند سوالها را به شکل JSON تحویل دهد تا مستقیماً در وبسایت، CMS، اپلیکیشن یا پایگاه داده ذخیره شوند.
بهروزرسانی سریعتر
وقتی ویژگی یا فرایند جدیدی به محصول اضافه میشود، میتوان FAQهای مرتبط را شناسایی و برای بازبینی آماده کرد.
هوش مصنوعی چه کاری را نباید بهتنهایی انجام دهد؟
مدل نباید اطلاعات کسبوکار را حدس بزند. اگر درباره قیمت، شرایط بازگشت وجه، قابلیت محصول، زمان تحویل یا محدودیت سرویس اطلاعاتی در ورودی وجود نداشته باشد، ممکن است پاسخ ظاهراً منطقی اما نادرست تولید کند.
هوش مصنوعی نباید منبع نهایی تصمیم درباره این موارد باشد:
- قیمت و تعرفه
- شرایط پرداخت
- سطح خدمات
- محدودیت مصرف
- سیاست بازگشت وجه
- زمان تحویل
- شرایط لغو
- قابلیتهای فنی محصول
- اطلاعات حساب و امنیت
- قوانین و مقررات
- اطلاعات شخصی کاربران
روش درست این است که مدل فقط براساس منابع تأییدشده پاسخ دهد و در صورت نبود اطلاعات، سوال را با وضعیت needs_review علامتگذاری کند.
منابع مناسب برای استخراج سوالات متداول
بهترین FAQها از سوالات واقعی کاربران ساخته میشوند، نه از حدس نویسنده.
منابع مفید عبارتاند از:
تیکتهای پشتیبانی
تیکتها نشان میدهند کاربران دقیقاً در کدام مرحله با مشکل مواجه میشوند.
گفتوگوهای فروش
اعتراضها و ابهامهای پیش از خرید، منبع مناسبی برای FAQ صفحه قیمت و محصول هستند.
جستوجوی داخلی سایت
اگر کاربران در سایت عبارتهایی مانند «لغو اشتراک» یا «تغییر رمز» را زیاد جستوجو میکنند، احتمالاً باید برای آنها پاسخ روشنی ایجاد شود.
پیامهای شبکههای اجتماعی
سوالات تکراری دایرکت و کامنت میتوانند به FAQ تبدیل شوند.
مستندات محصول
هوش مصنوعی میتواند از یک راهنمای طولانی، سوالات کوتاه و کاربردی استخراج کند.
رفتار کاربران
صفحات دارای خروج بالا، فرمهای نیمهکاره و مراحل پیچیده ثبتنام میتوانند نشانه وجود ابهام باشند.
تیمهای داخلی
فروش، پشتیبانی، محصول و عملیات هرکدام مجموعه متفاوتی از سوالات کاربران را میشناسند.
اطلاعات حساس را قبل از تحلیل حذف کنید
اگر از تیکتها و مکالمات واقعی استفاده میکنید، قبل از ارسال محتوا به مدل اطلاعات شخصی و محرمانه را حذف یا جایگزین کنید:
- نام و نام خانوادگی
- شماره تلفن
- ایمیل
- آدرس
- شماره سفارش
- اطلاعات پرداخت
- کلید API
- رمز عبور
- شناسه حساب
- محتوای محرمانه سازمانی
برای مثال:
نام: [CUSTOMER_NAME]
ایمیل: [EMAIL]
شماره سفارش: [ORDER_ID]
نام شرکت: [COMPANY_NAME]
انواع سوالات متداول
برای پوشش کامل مسیر کاربر، سوالات را به چند دسته تقسیم کنید.
سوالات پیش از خرید
- این محصول برای چه کسانی مناسب است؟
- چه قابلیتهایی ارائه میشود؟
- تفاوت پلنها چیست؟
- آیا امکان آزمایش سرویس وجود دارد؟
- برای شروع به چه چیزی نیاز دارم؟
سوالات ثبتنام و حساب
- چگونه ثبتنام کنم؟
- چرا کد ورود دریافت نمیکنم؟
- چگونه اطلاعات حساب را تغییر دهم؟
- چگونه رمز عبور را بازیابی کنم؟
سوالات قیمت و پرداخت
- هزینه سرویس چگونه محاسبه میشود؟
- چه روشهای پرداختی وجود دارد؟
- فاکتور از کجا دریافت میشود؟
- وضعیت پرداخت ناموفق چگونه پیگیری میشود؟
سوالات استفاده از محصول
- چگونه اولین پروژه را ایجاد کنم؟
- از کجا تنظیمات را تغییر دهم؟
- چگونه اعضای تیم را اضافه کنم؟
- چه فرمتهایی پشتیبانی میشوند؟
سوالات فنی
- Base URL چیست؟
- احراز هویت چگونه انجام میشود؟
- محدودیت درخواستها چقدر است؟
- چه خطاهایی ممکن است برگردانده شوند؟
سوالات عیبیابی
- چرا درخواست من ناموفق است؟
- چرا فایل بارگذاری نمیشود؟
- چرا نتیجه ناقص است؟
- هنگام دریافت خطا چه کاری انجام دهم؟
سوالات سازمانی
- آیا قرارداد رسمی ارائه میشود؟
- آیا امکان مدیریت دسترسی اعضا وجود دارد؟
- گزارش مصرف چگونه دریافت میشود؟
- پشتیبانی سازمانی شامل چه مواردی است؟
ویژگیهای یک سوال متداول حرفهای
سوال باید با زبان کاربر نوشته شود
بهجای اصطلاحات داخلی شرکت، از عبارتی استفاده کنید که مخاطب واقعاً جستوجو یا بیان میکند.
نامناسب:
فرایند Settlement تراکنش ناموفق چگونه است؟
مناسبتر:
اگر پرداخت از حسابم کم شد اما کیف پول شارژ نشد چه کاری انجام دهم؟
هر سوال فقط یک موضوع داشته باشد
نامناسب:
چگونه ثبتنام کنم و پرداخت انجام دهم و فاکتور بگیرم؟
بهتر است این مورد به سه سوال جداگانه تبدیل شود.
پاسخ با جواب مستقیم شروع شود
نامناسب:
ما همواره تلاش میکنیم بهترین تجربه ممکن را برای کاربران ایجاد کنیم و فرایندهای مختلفی در سامانه در نظر گرفته شده است...
مناسب:
پس از ورود به پنل، از بخش «صورتحسابها» میتوانید فاکتور خود را دریافت کنید.
پاسخ باید کوتاه اما کامل باشد
برای FAQ عمومی، معمولاً یک تا سه پاراگراف کوتاه کافی است. اگر پاسخ طولانی شد، خلاصه را در FAQ نگه دارید و به راهنمای کامل لینک دهید.
پاسخ نباید وعده ناموجود ایجاد کند
اگر محصول قابلیتی ندارد، پاسخ نباید آن را بهصورت ضمنی تأیید کند.
پاسخ باید قابل نگهداری باشد
پاسخهایی که شامل عدد، تاریخ، قیمت یا نام قابلیت هستند باید منبع و زمان بازبینی داشته باشند.
فرایند کامل ساخت سوالات متداول با هوش مصنوعی
مرحله اول: هدف صفحه را مشخص کنید
برای یک صفحه قیمتگذاری، سوالهای مالی و مقایسهای مهمترند. برای مستندات API، سوالهای فنی و عیبیابی اهمیت بیشتری دارند.
نمونه هدف:
هدف این FAQ پاسخ دادن به ابهامهای توسعهدهندگان پیش از دریافت API Key و ارسال اولین درخواست است.
مرحله دوم: منابع معتبر را جمعآوری کنید
منابع را بهصورت مشخص دستهبندی کنید:
- صفحه محصول
- مستندات
- فایل راهنما
- تیکتهای پرتکرار
- توضیحات تیم فروش
- سیاستهای رسمی
- گزارش جستوجوی کاربران
مدل باید بداند کدام منبع در صورت تعارض اولویت دارد.
نمونه:
اولویت منابع:
1. مستندات رسمی نسخه جدید
2. صفحه محصول
3. پاسخهای تاییدشده پشتیبانی
4. محتوای قدیمی
مرحله سوم: سوالها را استخراج کنید
پرامپت پیشنهادی:
از محتوای زیر سوالات متداول کاربران را استخراج کن.
هدف صفحه:
پاسخ به سوالات کاربران پیش از ثبتنام
مخاطب:
کسبوکارهای کوچک و متوسط
شرایط:
- فقط سوالاتی را استخراج کن که پاسخ آنها در منبع وجود دارد.
- اطلاعات جدید حدس نزن.
- سوالات مشابه را ادغام کن.
- سوالها را با زبان طبیعی کاربر بنویس.
- هر سوال فقط یک موضوع داشته باشد.
- برای هر مورد، بخش منبع را نیز مشخص کن.
- اگر پاسخ مبهم است، وضعیت را needs_review قرار بده.
خروجی:
دستهبندی، سوال، پاسخ کوتاه، منبع و وضعیت بررسی
محتوا:
[محتوای تاییدشده را اینجا قرار دهید]
مرحله چهارم: سوالهای مشابه را ادغام کنید
ممکن است کاربران یک سوال را به شکلهای مختلف مطرح کنند:
- قیمت سرویس چقدر است؟
- هزینه استفاده چگونه محاسبه میشود؟
- تعرفهها را از کجا ببینم؟
- برای هر درخواست چقدر باید پرداخت کنم؟
این سوالها الزاماً یکسان نیستند، اما ممکن است در یک پاسخ جامع پوشش داده شوند.
پرامپت ادغام:
سوالات زیر را از نظر نیت کاربر خوشهبندی کن.
برای هر خوشه:
- عنوان نیت
- سوال اصلی پیشنهادی
- عبارتهای جایگزین
- تفاوتهای مهم میان سوالها
- پیشنهاد ادغام یا جدا نگه داشتن
هیچ تفاوت مهمی را برای کاهش تعداد سوالات حذف نکن.
مرحله پنجم: پاسخ را براساس منبع بنویسید
برای سوال زیر یک پاسخ FAQ بنویس.
سوال:
هزینه استفاده از سرویس چگونه محاسبه میشود؟
منبع تاییدشده:
[متن منبع]
شرایط:
- فقط از اطلاعات منبع استفاده کن.
- پاسخ را با جواب مستقیم شروع کن.
- حداکثر ۸۰ کلمه باشد.
- لحن حرفهای و قابلفهم باشد.
- اگر عدد یا اطلاعات لازم در منبع نیست، آن را حدس نزن.
- در صورت نیاز به صفحه دیگر، لینک پیشنهادی را جدا بنویس.
مرحله ششم: پاسخها را بازبینی کنید
هر پاسخ باید توسط مالک اطلاعات بررسی شود:
| موضوع | بازبین مناسب |
|---|---|
| قیمت و پرداخت | مالی یا مدیر محصول |
| قابلیت محصول | تیم محصول |
| راهنمای فنی | تیم توسعه یا مستندات |
| حساب کاربری | پشتیبانی |
| فروش سازمانی | تیم فروش |
| عملیات و تحویل | تیم عملیات |
مرحله هفتم: FAQ را منتشر و اندازهگیری کنید
بعد از انتشار، این شاخصها را بررسی کنید:
- کلیک روی هر سوال
- عبارتهای جستوجوشده در سایت
- نرخ تماس پس از مشاهده FAQ
- تعداد تیکتهای تکراری
- نرخ خروج صفحه
- لینکهای بیشتر کلیکشده
- سوالهایی که پاسخی برای آنها پیدا نشده است
- بازخورد مثبت یا منفی کاربران
پرامپتهای آماده ساخت FAQ
پرامپت ساخت FAQ صفحه محصول
براساس اطلاعات تاییدشده زیر، برای صفحه محصول ۱۵ سوال متداول بنویس.
مخاطب:
کاربرانی که محصول را میشناسند اما هنوز برای خرید تصمیم نگرفتهاند.
دستهها:
- کاربرد محصول
- قابلیتها
- شروع استفاده
- قیمت و پرداخت
- پشتیبانی
- محدودیتها
شرایط:
- هیچ ویژگی یا عددی را حدس نزن.
- سوالات بازاریابی و مصنوعی تولید نکن.
- سوالها با زبان واقعی مشتری نوشته شوند.
- پاسخ هر سوال بین ۳۰ تا ۸۰ کلمه باشد.
- پاسخ با جواب مستقیم شروع شود.
- اگر منبع کافی نیست، وضعیت needs_review بده.
- برای هر پاسخ، منبع مورد استفاده را ذکر کن.
اطلاعات محصول:
[متن تاییدشده]
پرامپت FAQ فروشگاه اینترنتی
از اطلاعات زیر سوالات متداول یک فروشگاه اینترنتی را تولید کن.
دستهها:
ثبت سفارش، پرداخت، ارسال، پیگیری، تغییر سفارش و پشتیبانی
قواعد:
- فقط براساس اطلاعات ارائهشده پاسخ بده.
- زمان ارسال یا شرایطی را که در متن نیست حدس نزن.
- سوالات مشابه را ادغام کن.
- پاسخها کوتاه و مرحلهبهمرحله باشند.
- هر پاسخ حداکثر ۱۰۰ کلمه باشد.
- پاسخهای نیازمند تایید انسانی را علامتگذاری کن.
اطلاعات:
[اطلاعات تاییدشده فروشگاه]
پرامپت FAQ نرمافزار SaaS
برای یک نرمافزار SaaS از متن زیر FAQ بساز.
مخاطب:
کاربر جدید و مدیر تیم
موضوعها:
ثبتنام، ساخت فضای کاری، دعوت اعضا، نقشها،
تنظیمات، گزارش مصرف، پرداخت و پشتیبانی
خروجی برای هر مورد:
- category
- question
- short_answer
- help_article_needed
- source
- review_status
فقط اطلاعات موجود در منبع را استفاده کن.
پرامپت FAQ مستندات API
براساس مستندات زیر، سوالات متداول توسعهدهندگان را تولید کن.
موضوعها:
- احراز هویت
- Base URL
- ارسال درخواست
- خطاها
- Rate Limit
- مدلها
- مدیریت کلید API
- ثبت مصرف
شرایط:
- پاسخها فنی اما کوتاه باشند.
- مثال کد را فقط در صورت وجود اطلاعات کافی بنویس.
- نام Endpoint یا Header را دقیقاً از منبع بردار.
- هیچ پارامتر یا قابلیت جدیدی اختراع نکن.
- برای هر سوال لینک بخش مرتبط مستندات را پیشنهاد بده.
- موارد مبهم را needs_review علامتگذاری کن.
پرامپت تبدیل تیکتها به FAQ
مکالمات ناشناسسازیشده پشتیبانی را تحلیل کن.
وظایف:
1. نیت هر تیکت را مشخص کن.
2. موضوعات مشابه را خوشهبندی کن.
3. تعداد تکرار هر موضوع را بنویس.
4. برای موضوعهای پرتکرار یک سوال FAQ پیشنهاد بده.
5. پاسخ را فقط از پاسخ تاییدشده اپراتور استخراج کن.
6. اطلاعات شخصی را در خروجی تکرار نکن.
7. موارد دارای پاسخ متناقض را needs_review علامتگذاری کن.
تیکتها:
[متن ناشناسسازیشده]
پرامپت کوتاهسازی پاسخ
پاسخ زیر را برای بخش سوالات متداول بازنویسی کن.
شرایط:
- پاسخ مستقیم در جمله اول قرار بگیرد.
- حداکثر ۷۰ کلمه باشد.
- هیچ اطلاعاتی حذف یا اضافه نشود.
- لحن حرفهای و روان باشد.
- جملههای تبلیغاتی حذف شوند.
- اگر انجام کار چند مرحله دارد، از فهرست شمارهدار استفاده کن.
پاسخ:
[متن پاسخ]
پرامپت کنترل کیفیت FAQ
سوالات متداول زیر را ارزیابی کن.
برای هر مورد از ۱ تا ۱۰ امتیاز بده:
- وضوح سوال
- مستقیم بودن پاسخ
- تطابق پاسخ با سوال
- کوتاهی
- قابلفهم بودن
- قابلیت اقدام
- وابستگی به اطلاعات متغیر
- خطر وجود اطلاعات حدسی
سپس مشکلات را توضیح بده و نسخه اصلاحشده پیشنهاد کن.
هیچ واقعیت جدیدی اضافه نکن.
نمونه عملی ساخت FAQ از یک متن
فرض کنید این اطلاعات درباره یک سرویس وجود دارد:
کاربران پس از ثبتنام میتوانند از پنل کاربری کلید API ایجاد کنند.
کلید فقط یک بار بهصورت کامل نمایش داده میشود.
کاربر میتواند کلید را غیرفعال یا حذف کند.
کلید API نباید در کد فرانتاند یا مخزن عمومی قرار بگیرد.
FAQ مناسب:
چگونه کلید API ایجاد کنم؟
پس از ورود به پنل کاربری، به بخش مدیریت کلیدهای API بروید و یک کلید جدید بسازید. کلید کامل فقط یک بار نمایش داده میشود؛ بنابراین آن را در محل امن ذخیره کنید.
آیا میتوانم کلید API را دوباره مشاهده کنم؟
خیر. مقدار کامل کلید فقط هنگام ساخت نمایش داده میشود. اگر آن را ذخیره نکردهاید، کلید قبلی را حذف و یک کلید جدید ایجاد کنید.
کلید API را کجا نگه دارم؟
کلید را در متغیر محیطی یا سامانه مدیریت Secret سمت سرور نگه دارید. آن را در کد فرانتاند، اپلیکیشن عمومی یا مخزن Git قرار ندهید.
در این مثال، هیچ اطلاعاتی خارج از متن منبع اضافه نشده و هر پاسخ یک موضوع مشخص دارد.
ساخت خروجی JSON برای سایت و اپلیکیشن
برای ذخیره FAQ در CMS یا پایگاه داده، خروجی ساختاریافته مفید است:
{
"faqs": [
{
"id": "api-key-create",
"category": "api_keys",
"question": "چگونه کلید API ایجاد کنم؟",
"answer": "پس از ورود به پنل کاربری، به بخش مدیریت کلیدهای API بروید و یک کلید جدید بسازید.",
"source": "api-key-documentation",
"review_status": "approved",
"last_reviewed_at": "2026-07-26"
}
]
}
وجود فیلدهای source، review_status و last_reviewed_at کمک میکند پاسخهای قدیمی یا تأییدنشده را شناسایی کنید.
ساخت FAQ با API هوش مصنوعی درواره
درواره زیرساخت API هوش مصنوعی است و میتوانید از طریق آن قابلیت تولید، طبقهبندی و بازنویسی FAQ را به نرمافزار یا فرایند محتوایی خود اضافه کنید.
برای شروع:
- در درواره ثبتنام کنید.
- کلید API بسازید.
- مدل متنی مناسب را انتخاب کنید.
- کلید را در متغیر محیطی قرار دهید.
- منبع تأییدشده را همراه با دستور تولید FAQ ارسال کنید.
- خروجی را اعتبارسنجی و برای بازبینی انسانی ذخیره کنید.
برای مشاهده مدلها، قابلیتها و هزینههای بهروز، صفحه مدلهای درواره را بررسی کنید.
نمونه Python برای تولید FAQ
نصب کتابخانه:
pip install openai python-dotenv
فایل .env:
DARVAREH_API_KEY=YOUR_API_KEY
DARVAREH_TEXT_MODEL=YOUR_MODEL_ID
YOUR_MODEL_ID باید با Model ID مدل متنی انتخابشده در درواره جایگزین شود.
کد:
import json
import os
from pathlib import Path
from dotenv import load_dotenv
from openai import OpenAI
load_dotenv()
api_key = os.getenv("DARVAREH_API_KEY")
model_id = os.getenv("DARVAREH_TEXT_MODEL")
if not api_key:
raise RuntimeError("DARVAREH_API_KEY is not configured")
if not model_id:
raise RuntimeError("DARVAREH_TEXT_MODEL is not configured")
client = OpenAI(
api_key=api_key,
base_url="https://api.darvareh.ir/v1",
)
source_text = """
کاربران پس از ثبتنام میتوانند از پنل کاربری کلید API ایجاد کنند.
کلید فقط یک بار بهصورت کامل نمایش داده میشود.
کاربر میتواند کلید را غیرفعال یا حذف کند.
کلید API نباید در کد فرانتاند یا مخزن عمومی قرار بگیرد.
""".strip()
prompt = f"""
براساس منبع زیر، سوالات متداول فارسی تولید کن.
قواعد:
- فقط از اطلاعات منبع استفاده کن.
- اطلاعات جدید حدس نزن.
- هر سوال فقط یک موضوع داشته باشد.
- پاسخ با جواب مستقیم شروع شود.
- پاسخ هر سوال حداکثر ۸۰ کلمه باشد.
- اگر پاسخ کافی وجود ندارد، review_status را needs_review قرار بده.
- خروجی فقط JSON معتبر باشد.
ساختار خروجی:
{{
"faqs": [
{{
"id": "english-kebab-case-id",
"category": "category_name",
"question": "سوال فارسی",
"answer": "پاسخ فارسی",
"review_status": "draft یا needs_review"
}}
]
}}
منبع:
{source_text}
""".strip()
response = client.chat.completions.create(
model=model_id,
messages=[
{
"role": "system",
"content": (
"تو ویراستار پایگاه دانش هستی و نباید "
"اطلاعات خارج از منبع تولید کنی."
),
},
{
"role": "user",
"content": prompt,
},
],
temperature=0.2,
)
content = response.choices[0].message.content
faq_data = json.loads(content)
output_path = Path("faqs.json")
output_path.write_text(
json.dumps(faq_data, ensure_ascii=False, indent=2),
encoding="utf-8",
)
print("FAQ file created:", output_path)
دمای پایینتر معمولاً برای پاسخهای مبتنی بر منبع مناسبتر است، اما صحت خروجی همچنان باید بررسی شود.
اعتبارسنجی خروجی مدل
صرف اینکه خروجی JSON معتبر است، به معنی صحیح بودن پاسخها نیست. بهتر است دو نوع اعتبارسنجی داشته باشید.
اعتبارسنجی ساختاری
بررسی کنید:
faqsیک آرایه است.- سوال و پاسخ خالی نیستند.
- شناسهها تکراری نیستند.
- وضعیت فقط یکی از مقادیر مجاز است.
- طول پاسخ از حد تعیینشده بیشتر نیست.
ALLOWED_STATUSES = {
"draft",
"needs_review",
"approved",
}
def validate_faq_data(data: dict) -> list[str]:
errors = []
faqs = data.get("faqs")
if not isinstance(faqs, list):
return ["faqs must be an array"]
seen_ids = set()
for index, item in enumerate(faqs):
faq_id = item.get("id")
question = item.get("question")
answer = item.get("answer")
status = item.get("review_status")
if not faq_id:
errors.append(f"Item {index}: missing id")
elif faq_id in seen_ids:
errors.append(f"Item {index}: duplicate id")
else:
seen_ids.add(faq_id)
if not question:
errors.append(f"Item {index}: missing question")
if not answer:
errors.append(f"Item {index}: missing answer")
if status not in ALLOWED_STATUSES:
errors.append(f"Item {index}: invalid status")
if answer and len(answer) > 700:
errors.append(f"Item {index}: answer is too long")
return errors
اعتبارسنجی محتوایی
بررسی محتوایی باید مشخص کند:
- آیا پاسخ در منبع وجود دارد؟
- آیا عدد یا ویژگی جدیدی اضافه شده است؟
- آیا پاسخ با سوال مرتبط است؟
- آیا اطلاعات قدیمی است؟
- آیا منبع قابلاعتماد است؟
- آیا پاسخ برای انتشار نیازمند تأیید متخصص است؟
استفاده از Structured Output
اگر مدل انتخابشده از خروجی ساختاریافته پشتیبانی میکند، میتوانید قالب JSON را با Schema محدود کنید. پشتیبانی از این قابلیت و ساختار دقیق پارامترها به مدل انتخابشده بستگی دارد.
یک Schema ساده:
{
"type": "object",
"properties": {
"faqs": {
"type": "array",
"items": {
"type": "object",
"properties": {
"id": {
"type": "string"
},
"category": {
"type": "string"
},
"question": {
"type": "string"
},
"answer": {
"type": "string"
},
"review_status": {
"type": "string",
"enum": [
"draft",
"needs_review"
]
}
},
"required": [
"id",
"category",
"question",
"answer",
"review_status"
],
"additionalProperties": false
}
}
},
"required": [
"faqs"
],
"additionalProperties": false
}
حتی با Structured Output نیز باید صحت محتوایی پاسخ بررسی شود؛ Schema فقط شکل داده را کنترل میکند.
نمایش FAQ در Ghost
در ویرایشگر Ghost میتوانید از Toggle یا HTML Card استفاده کنید. نمونه سازگار با HTML:
<section class="faq-section" dir="rtl">
<details>
<summary>چگونه کلید API ایجاد کنم؟</summary>
<p>
پس از ورود به پنل کاربری، به بخش مدیریت کلیدهای API
بروید و یک کلید جدید بسازید.
</p>
</details>
<details>
<summary>آیا میتوانم کلید را دوباره مشاهده کنم؟</summary>
<p>
مقدار کامل کلید فقط هنگام ساخت نمایش داده میشود.
اگر آن را ذخیره نکردهاید، یک کلید جدید ایجاد کنید.
</p>
</details>
</section>
استایل ساده:
<style>
.faq-section {
margin: 2rem 0;
}
.faq-section details {
border: 1px solid #e5e7eb;
border-radius: 12px;
margin-bottom: 12px;
padding: 0 18px;
background: #ffffff;
}
.faq-section summary {
cursor: pointer;
font-weight: 700;
padding: 18px 0;
line-height: 1.8;
}
.faq-section p {
margin: 0;
padding: 0 0 18px;
line-height: 2;
}
</style>
سوال و پاسخ باید در محتوای قابلمشاهده صفحه وجود داشته باشند؛ فقط قرار دادن آنها در کد یا داده ساختاریافته کافی نیست.
FAQ Schema چیست؟
FAQPage یکی از انواع داده ساختاریافته در Schema.org است و برای صفحهای تعریف شده که شامل یک یا چند سوال متداول و پاسخ آنهاست. تعریف FAQPage در Schema.org
نمونه JSON-LD:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "چگونه کلید API ایجاد کنم؟",
"acceptedAnswer": {
"@type": "Answer",
"text": "پس از ورود به پنل کاربری، به بخش مدیریت کلیدهای API بروید و یک کلید جدید بسازید."
}
},
{
"@type": "Question",
"name": "آیا میتوانم کلید API را دوباره مشاهده کنم؟",
"acceptedAnswer": {
"@type": "Answer",
"text": "مقدار کامل کلید فقط هنگام ساخت نمایش داده میشود. در صورت گم شدن کلید، یک کلید جدید ایجاد کنید."
}
}
]
}
</script>
محتوای Schema باید با سوال و پاسخی که کاربر روی همان صفحه مشاهده میکند مطابقت داشته باشد. براساس راهنمای عمومی Google، داده ساختاریافته نباید گمراهکننده یا مربوط به محتوای پنهان باشد و نمایش نتیجه ویژه نیز حتی با Markup صحیح تضمین نمیشود. راهنمای دادههای ساختاریافته Google
نکته مهم و بهروز درباره FAQ و سئو
نباید به کاربران وعده داد که افزودن FAQ Schema حتماً باعث نمایش سوالها زیر نتیجه گوگل یا افزایش رتبه میشود.
براساس گزارش رسمی Google Search Console، از ۷ مه ۲۰۲۶ نمایش FAQ Rich Results در نتایج Google Search متوقف شده است. بنابراین ایجاد FAQ همچنان میتواند برای تجربه کاربر، وضوح محتوا، پاسخگویی و فهم ساختار صفحه مفید باشد، اما نباید آن را راه تضمینی دریافت نتیجه ویژه FAQ در گوگل معرفی کرد. گزارش رسمی Google درباره توقف FAQ Rich Results
در نتیجه، اولویتهای درست عبارتاند از:
- پاسخ دادن به سوال واقعی کاربر
- کاهش ابهام پیش از خرید یا استفاده
- ایجاد محتوای واضح و قابلدسترسی
- پیوند دادن پاسخ کوتاه به راهنمای کامل
- استفاده صحیح از ساختار معنایی
- خودداری از ساخت FAQ فقط برای تکرار کلمات کلیدی
تفاوت FAQPage و QAPage
این دو نوع Schema کاربرد یکسان ندارند.
FAQPage
برای صفحهای مناسب است که ناشر سایت سوالها و پاسخهای رسمی را ارائه میکند و کاربران پاسخهای مختلف ثبت نمیکنند.
QAPage
برای صفحهای است که یک سوال اصلی دارد و کاربران میتوانند پاسخهای مختلفی برای آن ثبت کنند؛ مانند انجمن یا سایت پرسشوپاسخ. Google برای QAPage نیز دستورالعمل مستقل دارد. راهنمای QAPage در Google Search Central
برای بخش معمول سوالات متداول یک محصول، FAQPage از نظر معنایی انتخاب مناسبتری است؛ حتی اگر نمایش ویژه FAQ در گوگل متوقف شده باشد.
FAQ و سئوی محتوایی
سوالات متداول همچنان میتوانند به سئوی محتوایی کمک کنند، اما نه از طریق ترفند یا تکرار مصنوعی کلمات.
پوشش سوالات تکمیلی
FAQ میتواند ابهامهایی را پاسخ دهد که در متن اصلی صفحه پوشش داده نشدهاند.
استفاده از زبان طبیعی کاربر
پرسشهای واقعی کاربران معمولاً به شکل جستوجوهای طولانی و محاورهای نوشته میشوند.
بهبود لینکسازی داخلی
از پاسخ کوتاه میتوان به راهنمای جامعتر لینک داد.
افزایش کاربرد صفحه
کاربری که پاسخ خود را سریع پیدا میکند، احتمال کمتری دارد فوراً صفحه را ترک کند.
کمک به ساختار محتوا
سوالهای واضح باعث میشوند بخشهای مهم صفحه برای کاربران و سیستمهای پردازش محتوا قابلتشخیصتر باشند.
FAQ نباید فقط نسخه سوالی تیترهای قبلی صفحه باشد. اگر همان اطلاعات بدون ارزش جدید تکرار شوند، صفحه صرفاً طولانیتر خواهد شد.
تبدیل FAQ به پایگاه دانش
پس از مدتی، بعضی پاسخها طولانیتر میشوند. برای هر سوال یکی از این تصمیمها را بگیرید:
- پاسخ کوتاه در FAQ کافی است.
- پاسخ به مقاله آموزشی جداگانه نیاز دارد.
- سوال باید در صفحه محصول پاسخ داده شود.
- سوال مربوط به رابط کاربری است و باید همانجا توضیح داده شود.
- مشکل به اصلاح خود محصول نیاز دارد، نه نوشتن FAQ.
اگر کاربران مرتب میپرسند «دکمه پرداخت کجاست؟»، شاید راهحل اصلی بهتر کردن رابط کاربری باشد، نه افزودن یک سوال دیگر.
بهروزرسانی خودکار FAQ
میتوانید یک فرایند دورهای بسازید که:
- تیکتهای جدید را دریافت کند.
- اطلاعات شخصی را حذف کند.
- موضوعها را دستهبندی کند.
- فراوانی هر موضوع را محاسبه کند.
- موضوعهای جدید را شناسایی کند.
- پاسخ پیشنهادی بسازد.
- آن را برای بازبینی انسانی ارسال کند.
- پس از تأیید در CMS منتشر کند.
انتشار کاملاً خودکار پاسخهای مرتبط با قیمت، محصول یا شرایط سرویس توصیه نمیشود. مدل میتواند پیشنویس بسازد، اما تأیید باید بخشی از Workflow باشد.
ساخت سیستم کنترل نسخه FAQ
برای هر پاسخ این اطلاعات را ذخیره کنید:
{
"faq_id": "billing-calculation",
"question": "هزینه استفاده چگونه محاسبه میشود؟",
"answer": "پاسخ تاییدشده",
"source_ids": [
"pricing-page-v4"
],
"status": "approved",
"version": 3,
"owner": "product-team",
"last_reviewed_at": "2026-07-26",
"next_review_at": "2026-10-26"
}
این ساختار برای پاسخهایی که با تغییر محصول یا تعرفه قدیمی میشوند بسیار مفید است.
اشتباهات رایج در ساخت FAQ با هوش مصنوعی
تولید سوال بدون استفاده از داده واقعی
لیست حاصل ممکن است کامل به نظر برسد، اما با مشکلات واقعی کاربران ارتباط نداشته باشد.
اجازه دادن به مدل برای حدس پاسخ
مدل باید براساس منابع مشخص کار کند و نبود اطلاعات را اعلام کند.
پاسخهای تبلیغاتی
FAQ محل شعار تبلیغاتی نیست. پاسخ باید مستقیم و کاربردی باشد.
سوالهای ساختگی برای تکرار کلمه کلیدی
این روش کیفیت محتوا را کاهش میدهد و تجربه کاربر را خراب میکند.
پاسخ دادن به چند موضوع در یک سوال
هر سوال باید یک نیت مشخص داشته باشد.
پاسخهای بسیار طولانی
جزئیات را در مقاله مستقل قرار دهید و از FAQ به آن لینک بدهید.
نداشتن مسئول بازبینی
هر دسته از اطلاعات باید یک مالک مشخص داشته باشد.
درج اطلاعات متغیر بدون تاریخ بررسی
قیمت، قابلیتها و محدودیتها ممکن است تغییر کنند. منبع و زمان بازبینی را ثبت کنید.
انتشار داده ساختاریافته متفاوت با متن صفحه
محتوای JSON-LD باید با محتوای قابلمشاهده هماهنگ باشد.
انتظار تضمینشده از FAQ Schema
FAQ را برای کاربر بسازید، نه با وعده دریافت رتبه یا نمایش ویژه تضمینی در گوگل.
چکلیست نهایی سوالات متداول
پیش از انتشار بررسی کنید:
- سوالها از دادهها و نیازهای واقعی استخراج شدهاند.
- هر سوال یک موضوع مشخص دارد.
- سوال با زبان طبیعی کاربر نوشته شده است.
- پاسخ با جواب مستقیم شروع میشود.
- پاسخ بیش از حد طولانی نیست.
- اطلاعات خارج از منبع اضافه نشده است.
- قیمت و ویژگیها بهروز هستند.
- لینکهای داخلی صحیحاند.
- سوالات مشابه ادغام شدهاند.
- پاسخهای مبهم علامتگذاری شدهاند.
- هر پاسخ بازبین مشخص دارد.
- تاریخ آخرین بازبینی ثبت شده است.
- متن روی موبایل خوانا است.
- Accordion با کیبورد قابل استفاده است.
- سوال و پاسخ در صفحه قابلمشاهدهاند.
- داده ساختاریافته با محتوای صفحه یکسان است.
- انتشار Schema با وعده نمایش تضمینی همراه نیست.
- اطلاعات شخصی از ورودیها حذف شدهاند.
سوالات متداول
آیا میتوان FAQ یک سایت را کاملاً با هوش مصنوعی ساخت؟
هوش مصنوعی میتواند پیشنویس سوالها و پاسخها را تولید کند، اما اطلاعات نهایی باید براساس منابع رسمی و دادههای واقعی کاربران تأیید شوند. انتشار خودکار پاسخهای بررسینشده میتواند اطلاعات نادرست ایجاد کند.
برای ساخت FAQ چه اطلاعاتی به هوش مصنوعی بدهیم؟
مستندات محصول، صفحه قیمت، راهنمای استفاده، تیکتهای ناشناسسازیشده، سوالات تیم فروش و پاسخهای تأییدشده پشتیبانی منابع مناسبی هستند.
چند سوال متداول در یک صفحه قرار دهیم؟
عدد ثابتی وجود ندارد. فقط سوالهایی را قرار دهید که با هدف همان صفحه مرتبطاند. اگر تعداد سوالها زیاد شد، آنها را دستهبندی یا به مرکز راهنمای مستقل منتقل کنید.
آیا FAQ برای سئو مفید است؟
FAQ میتواند پوشش موضوع، تجربه کاربر و لینکسازی داخلی را بهتر کند؛ اما نباید آن را روش تضمینی افزایش رتبه دانست. همچنین از مه ۲۰۲۶، Google نمایش FAQ Rich Results را متوقف کرده است.
آیا هنوز باید FAQ Schema اضافه کنیم؟
FAQPage همچنان در Schema.org وجود دارد و میتواند برای بیان معنای ساختاری محتوا استفاده شود، اما نباید انتظار نمایش FAQ Rich Result در گوگل داشت. تصمیم استفاده باید براساس معماری محتوا و نیازهای سایت باشد.
آیا میتوان از تیکتهای پشتیبانی برای ساخت FAQ استفاده کرد؟
بله، اما ابتدا باید اطلاعات شخصی، اطلاعات حساب، جزئیات پرداخت و دادههای محرمانه حذف شوند.
چگونه جلوی پاسخ اشتباه هوش مصنوعی را بگیریم؟
منابع را در ورودی قرار دهید، مدل را به پاسخ براساس همان منابع محدود کنید، دما را کاهش دهید، موارد مبهم را needs_review علامت بزنید و بازبینی انسانی داشته باشید.
آیا درواره یک FAQ ساز آماده است؟
درواره زیرساخت API هوش مصنوعی است. توسعهدهندگان میتوانند با استفاده از آن قابلیت استخراج سوال، تولید پاسخ، دستهبندی تیکت و ساخت خروجی JSON را به نرمافزار خود اضافه کنند.
هزینه تولید FAQ با API چقدر است؟
هزینه به مدل، اندازه ورودی، تعداد توکنها و تعداد درخواستها بستگی دارد. برای مشاهده قیمتهای بهروز به صفحه مدلهای درواره مراجعه کنید.
جمعبندی
ساخت سوالات متداول با هوش مصنوعی زمانی ارزشمند است که مدل براساس منابع معتبر و سوالات واقعی کاربران کار کند. بهترین فرایند از جمعآوری تیکتها، مستندات و ابهامهای مشتری شروع میشود؛ سپس هوش مصنوعی سوالها را استخراج، ادغام و بازنویسی میکند و در نهایت یک بازبین انسانی صحت پاسخها را تأیید میکند.
برای ساخت دستی FAQ میتوانید از ابزارهای گفتوگومحور استفاده کنید. اگر قصد دارید استخراج سوال از تیکتها، تولید پاسخ، ساخت JSON و انتشار محتوا را در محصول یا فرایند سازمانی خود پیادهسازی کنید، API درواره امکان اتصال مدلهای هوش مصنوعی به این Workflow را فراهم میکند.
برای شروع، در درواره ثبتنام کنید، مدل مناسب را از صفحه مدلها انتخاب کنید و اولین سیستم تولید FAQ مبتنی بر منابع تأییدشده را بسازید.
مقالات مرتبط
- ابزارهای سئو با هوش مصنوعی
- آموزش خروجی ساختاریافته و JSON Schema
- هوش مصنوعی در پشتیبانی مشتری
- ساخت دستیار پشتیبانی مشتری با هوش مصنوعی
- چگونه ChatGPT را به وبسایت اضافه کنیم؟
- آموزش کامل پرامپتنویسی
- ساخت چتبات با API درواره
برای مطالعه شرایط استفاده و محدودیتهای مسئولیت، صفحه «سلب مسئولیت» را مشاهده کنید.