नॉलेज बेस कैसे बनाएं: आर्टिकल, सर्च, परमिशन और AI जवाब
नॉलेज बेस जवाबों की एक खोजी जा सकने वाली लाइब्रेरी है: कोई काम कैसे करें, कोई समस्या कैसे ठीक करें, नियम क्या है। इसे बनाने के लिए आपको कुछ साफ़ categories में बंटे आर्टिकल्स चाहिए, एक editor जिसे आपके लिखने वाले सच में इस्तेमाल करें, ऐसी सर्च जो लोगों के असली शब्दों से सही आर्टिकल ढूंढे, और यह तय करना कि कौन क्या पढ़ सकता है: सार्वजनिक लोग, लॉगिन किए हुए ग्राहक, या सिर्फ़ स्टाफ़। एक AI app builder कुछ ही सत्र में structure, editor और search बना सकता है। नॉलेज बेस को उपयोगी बनाने वाली चीज़ लिखाई और उसका रख-रखाव है, इसलिए पहले दिन से आसान editing और पुराने आर्टिकल पहचानने की सुविधा का डिज़ाइन बनाएं।
पहले तय करें कि यह किसके लिए है
एक ही फ़ीचर-सेट कई अलग साइटों पर काम आता है:
- Public help centre: ग्राहकों और संभावित ग्राहकों के लिए। तेज़ हो, search engines के लिए indexable हो, और उनकी अपनी भाषा में लिखी हो।
- सिर्फ़ ग्राहकों के लिए docs: login के पीछे, पेड ग्राहकों या partners के लिए।
- आंतरिक नॉलेज बेस: staff के लिए नीतियाँ, प्रक्रियाएँ, how-tos। यह निजी होना चाहिए; design से ज़्यादा search और ताज़गी मायने रखती है।
सार्वजनिक और आंतरिक आर्टिकल्स को एक ही साइट में मिलाना ही ज़्यादातर लीक की जड़ है। अगर आपको दोनों चाहिए, तो हर आर्टिकल को एक साफ़ visibility setting दें, या दो अलग साइटें चलाएं।
ऐप को क्या चाहिए
डेटा
| Table | मुख्य fields |
|---|---|
| Articles | Title, slug, summary, body, category, tags, status (draft, published, archived), visibility, owner, last reviewed at, updated at |
| Categories | Name, slug, description, order, parent (वैकल्पिक) |
| Revisions | Article, body, author, saved at |
| Feedback | Article, helpful yes/no, comment, created at |
| Search log | Query, results count, clicked article, created at |
दो fields बहुत काम करते हैं: owner (कौन इस आर्टिकल को सही रखता है) और last reviewed at (किसी ने आख़िरी बार कब पुष्टि की कि यह अभी भी सच है)। इन दोनों से आप ऐसे आर्टिकल्स की सूची बना सकते हैं जिन्हें छह महीने से किसी ने नहीं जाँचा।
पेज
- Reader: search और categories वाला home पेज, category पेज, आर्टिकल पेज जिनमें table of contents, संबंधित आर्टिकल्स और “क्या यह मददगार था?” का सवाल हो।
- Editor: फ़िल्टर वाली आर्टिकल सूची (drafts, पुराने, कम रेटिंग वाले), preview के साथ editor, और revision history।
- Admin: categories, users और roles, और उन searches की रिपोर्ट जिनका कोई नतीजा नहीं आया।
Permissions
Readers वही published आर्टिकल देखते हैं जिन्हें देखने की उन्हें अनुमति है। Editors आर्टिकल बनाते और edit करते हैं, शायद कुछ categories तक सीमित। Admins publish, archive और users मैनेज करते हैं। आंतरिक नॉलेज बेस के लिए हर किसी को login चाहिए; सार्वजनिक help centre के लिए सिर्फ़ लिखने वालों को।
फ़ैसले और trade-offs
Editor: Markdown या rich text
Markdown तेज़, portable है और version history के साथ अच्छा चलता है, लेकिन कुछ लिखने वालों को यह अटपटा लगता है। Rich-text editor में headings, lists, images, callouts और code blocks होते हैं और यह परिचित लगता है। जो भी चुनें, कंटेंट ऐसे format में स्टोर करें जिसे बाद में export किया जा सके।
सर्च
अगर आप title, summary और body में खोजते हैं और title के मिलान को ऊपर रखते हैं, तो कुछ सौ आर्टिकल्स के लिए बुनियादी database text search काफ़ी है। उससे आगे, या अगर typos और समानार्थी शब्द मायने रखते हैं (जैसे “invoice” बनाम “bill”), तो proper full-text search या hosted search service इस्तेमाल करें। हमारी search जोड़ने की गाइड विकल्प समझाती है। हर ऐसी query लॉग करें जिसका कोई नतीजा न आए: वह उन आर्टिकल्स की मुफ़्त सूची है जो आपको लिखने चाहिए।
AI जवाब
आर्टिकल्स से जवाब देने वाला “सवाल पूछें” बॉक्स अब आम है। यह सबसे प्रासंगिक हिस्से खोजकर एक language model से कहता है कि सिर्फ़ उन्हीं से जवाब दे; देखें RAG क्या है। हमेशा स्रोत आर्टिकल्स दिखाएं, “मुझे नहीं पता” कहने की अनुमति दें, और याद रखें कि यह आपके आर्टिकल्स में पुरानी बात को भी पूरे विश्वास से दोहराएगा। इसे आर्टिकल्स ठीक हो जाने के बाद बनाएं, उससे पहले नहीं।
Versioning और review
Revisions रखें ताकि आप देख सकें कि किसने क्या बदला और वापस कैसे लौटें। नियमों से बंधे कंटेंट (HR नीति, सुरक्षा प्रक्रियाएँ) के लिए publish से पहले एक approval step जोड़ें।
एक काम करने वाला पहला prompt
Parcelly के लिए एक public help centre बनाएं, जो छोटे ऑनलाइन दुकानों के लिए शिपिंग लेबल ऐप है। Home पेज पर एक बड़ा search बॉक्स और छह categories हों (Getting started, Printing labels, Carriers, Billing, Returns, Troubleshooting)। आर्टिकल्स में title, summary, Markdown में body जिसमें images और callouts हों, category, tags, status (draft, published, archived), owner और last-reviewed date हो। आर्टिकल पेजों पर table of contents, संबंधित आर्टिकल्स और “क्या यह मददगार था?” का हाँ/नहीं, वैकल्पिक comment के साथ दिखे। Search titles, summaries और bodies में हो, title के मिलान सबसे ऊपर हों, और हर query और उसके नतीजे की स्थिति लॉग हो। एक editor area (login ज़रूरी, roles editor और admin) drafts, 180 दिनों से review न हुए आर्टिकल्स, और कम helpful score वाले आर्टिकल्स की सूची दिखाए, और revision history रखे। हर आर्टिकल का अपना page title और meta description हो। साफ़, शांत और पढ़ने में आसान design। Mobile-first।
Build steps
- पहले 20–30 आर्टिकल्स की सूची बनाएं असली support सवालों से, कुछ भी बनाने से पहले। वही सूची categories तय करती है।
- साइट बनाएं और फ़ोन पर पढ़ने की जाँच करें: line length, headings, images।
- Editor और roles। लिखने वालों को developer से पूछे बिना आर्टिकल जोड़ने और ठीक करने की सुविधा होनी चाहिए।
- Search, फिर उसे उन्हीं शब्दों से टेस्ट करें जो ग्राहक असल में लिखते हैं, गलत spelling समेत।
- Feedback और search logging।
- पुराने आर्टिकल्स की रिपोर्ट, owner और last-reviewed date के आधार पर।
- SEO basics सार्वजनिक साइट के लिए: unique titles, descriptions, साफ़ URLs, एक sitemap। देखें AI से बनी वेबसाइट्स के लिए SEO।
- अपने product और अपने support जवाबों से इसका लिंक दें, फिर हर हफ़्ते no-results लॉग देखें।
- AI जवाब, जब कंटेंट ठोस हो जाए।
आम गलतियाँ
- विभाग के आधार पर व्यवस्थित करना उसकी जगह कि पाठक क्या करने की कोशिश कर रहा है।
- एक ही लंबे आर्टिकल में पाँच काम। एक आर्टिकल में एक काम, और ऐसा शीर्षक जो बताए कि वह क्या हल करता है।
- हर आर्टिकल का owner न होना। कोई कुछ अपडेट नहीं करता, और पहले गलत जवाब के बाद भरोसा गिर जाता है।
- सार्वजनिक आर्टिकल्स में आंतरिक नोट्स। अलग visibility रखें और publish से पहले review करें।
- ऐसी सर्च जो सिर्फ़ titles से मेल खाए। पाठक लक्षण टाइप करते हैं, आर्टिकल के नाम नहीं।
- Screenshots बिना alt text या संदर्भ के। वे जल्दी पुराने हो जाते हैं; कदम को शब्दों में भी लिखें।
जब तैयार product बेहतर विकल्प हो
अगर आपकी टीम पहले से किसी documentation या wiki tool में काम करती है, तो वहीं आंतरिक नॉलेज बेस बनाना आम तौर पर सबसे आसान रास्ता होता है; हमारी Notion बनाम Confluence तुलना दो आम विकल्पों को देखती है। अगर आप helpdesk product इस्तेमाल करते हैं, तो उसकी built-in help centre आर्टिकल्स को tickets से जोड़ती है और ग्राहकों को आर्टिकल सुझाती है, जिसे दोहराना मुश्किल है। Docs-site generators developer documentation के लिए आदर्श हैं, जो कोड के साथ रखा जाता है।
अपना बनाएं जब आपको अपनी संरचना या permissions चाहिए (हर ग्राहक, हर लोकेशन या हर role के लिए आर्टिकल्स), नॉलेज बेस को अलग साइट के बजाय अपने product के अंदर चाहिए, review और approval steps चाहिए जिन्हें wiki लागू नहीं करता, या बिना एक और subscription के आपके कंटेंट पर AI जवाब चाहिए। यह custom helpdesk के साथ अच्छी तरह जुड़ता है।
Mythex से बनाना
Mythex पर आप चैट में नॉलेज बेस का वर्णन करते हैं और वह live preview में बन जाता है; आर्टिकल्स, revisions और feedback एक Postgres database में स्टोर होते हैं जिसे ज़रूरत पड़ने पर agent जोड़ता है, और images प्रोजेक्ट की file storage में जाती हैं। Editor logins उस auth approach से होते हैं जो आप चुनते हैं, क्योंकि Mythex में end-user login बिल्ट-इन नहीं है। AI जवाबों के लिए आप अपने AI provider की API key इस्तेमाल करते हैं, जो project secret के रूप में रहती है, और उसका खर्च आपके provider के खाते पर जाता है, Mythex credits पर नहीं (AI recipe)। नए Mythex apps डिफ़ॉल्ट रूप से client-rendered React single-page app होते हैं, जो search engines के लिए कमज़ोर है, इसलिए सार्वजनिक help centre के लिए static-friendly या server-rendered setup, जैसे Next.js, माँगें (SEO recipe)।
शुरुआती prompt के लिए product knowledge hub या team docs app templates देखें।
सवाल
नॉलेज बेस और wiki में क्या फ़र्क है?
नॉलेज बेस आम तौर पर curated होता है: एक छोटी टीम किसी तय audience, अक्सर ग्राहकों, के लिए जवाब लिखती और उन्हें संभालती है। Wiki में हर कोई edit कर सकता है, और वह आम तौर पर ज़्यादा फैलता और अव्यवस्थित हो जाता है। दोनों के लिए एक ही सॉफ़्टवेयर इस्तेमाल हो सकता है; फ़र्क इस बात का है कि कौन लिखता है और कौन review करता है।
नॉलेज बेस को कैसे व्यवस्थित करें?
इस आधार पर कि पाठक क्या करने की कोशिश कर रहे हैं, न कि आपके org chart के आधार पर। कुछ top-level categories, छोटे और काम पर केंद्रित आर्टिकल जिनके शीर्षक साफ़ हों, और संबंधित आर्टिकल्स के बीच links, गहरे folder trees से बेहतर काम करते हैं।
क्या नॉलेज बेस में AI जवाब जोड़े जा सकते हैं?
हाँ। आम तरीका, जिसे retrieval-augmented generation कहते हैं, आपके आर्टिकल्स में प्रासंगिक हिस्से खोजता है और एक language model से कहता है कि सिर्फ़ उन्हीं हिस्सों का इस्तेमाल करके जवाब दे, स्रोत आर्टिकल्स के links के साथ। यह तब सबसे अच्छा काम करता है जब आर्टिकल खुद सटीक और ताज़ा हों।
क्या public help centre को search engines index करें?
आम तौर पर हाँ। लोग support से संपर्क करने से पहले खोजते हैं कि कोई समस्या कैसे ठीक करें, इसलिए हर आर्टिकल का अपना पेज, शीर्षक और description होना चाहिए। आंतरिक आर्टिकल्स को एक अलग, login से सुरक्षित साइट पर रखें।