როგორ ავაშენოთ ცოდნის ბაზა: სტატიები, ძიება, უფლებები და AI პასუხები

ცოდნის ბაზა პასუხების საძიებო ბიბლიოთეკაა: როგორ გააკეთო რაღაც, როგორ გამოასწორო რაღაც, რა არის წესი. მის ასაშენებლად გჭირდებათ სტატიები რამდენიმე მკაფიო კატეგორიაში, რედაქტორი, რომელსაც თქვენი ავტორები რეალურად გამოიყენებენ, ძიება, რომელიც სწორ სტატიას იპოვის იმ სიტყვებით, რასაც ხალხი რეალურად წერს, და გადაწყვეტილება იმის შესახებ, ვინ რას წაიკითხავს — საზოგადოება, ავტორიზებული მომხმარებლები თუ მხოლოდ თანამშრომლები. AI აპ-ბილდერს შეუძლია სტრუქტურის, რედაქტორისა და ძიების შექმნა მოკლე სესიაში. ცოდნის ბაზას სასარგებლოს კი წერა და შენარჩუნება ხდის, ამიტომ დიზაინი თავიდანვე მოარგეთ მარტივ რედაქტირებას და მოძველებული სტატიების ამოცნობას.

ჯერ გადაწყვიტეთ, ვისთვისაა

იგივე ფუნქციები სრულიად განსხვავებულ საიტებს ემსახურება:

• საჯარო დახმარების ცენტრი — მომხმარებლებისა და პოტენციური კლიენტებისთვის. უნდა იყოს სწრაფი, ინდექსირებადი საძიებო სისტემებისთვის და დაწერილი მათი სიტყვებით.
• მხოლოდ მომხმარებელთა დოკუმენტაცია — ავტორიზაციით დაცული, ფასიანი მომხმარებლებისა და პარტნიორებისთვის.
• შიდა ცოდნის ბაზა — პოლიტიკები, პროცესები, ინსტრუქციები თანამშრომლებისთვის. უნდა იყოს კერძო; ძიება და სიახლე უფრო მნიშვნელოვანია, ვიდრე დიზაინი.

რაც უნდა საჯარო და შიდა სტატიები ერთ საიტზე ერია, იქ ყველაზე ხშირად გაჟონვა ხდება. თუ ორივე გჭირდებათ, თითოეულ სტატიას მკაფიო ხილვადობის პარამეტრი მიანიჭეთ ან გაუშვით ორი ცალკე საიტი.

რა სჭირდება აპლიკაციას

მონაცემები

ორი ველი ბევრ სამუშაოს ასრულებს: მფლობელი (ვინ ინარჩუნებს სტატიას ზუსტს) და ბოლოს შემოწმებული (როდის დაადასტურა ვინმემ, რომ ის ჯერ კიდევ მართალია). ერთად ისინი საშუალებას გაძლევთ, ნახოთ სტატიები, რომლებიც ექვსი თვის განმავლობაში არავინ შეამოწმა.

გვერდები

• მკითხველის მხარე: მთავარი გვერდი ძიებით და კატეგორიებით, კატეგორიის გვერდები, სტატიის გვერდები შინაარსის ცხრილით, დაკავშირებული სტატიებით და კითხვით „დაგეხმარათ?“.
• რედაქტორის მხარე: სტატიების სია ფილტრებით (დრაფტები, მოძველებული, დაბალი შეფასების), რედაქტორი გადახედვით და რევიზიების ისტორია.
• ადმინისტრატორი: კატეგორიები, მომხმარებლები და როლები და ანგარიშები იმ ძიებებზე, რომლებსაც შედეგი არ აქვს.

უფლებები

მკითხველი ხედავს გამოქვეყნებულ სტატიებს, რომელთა ნახვის უფლებაც აქვს. რედაქტორები ქმნიან და არედაქტირებენ სტატიებს, შესაძლოა მხოლოდ გარკვეულ კატეგორიებში. ადმინისტრატორები აქვეყნებენ, არქივირებენ და მართავენ მომხმარებლებს. შიდა ცოდნის ბაზისთვის ყველას სჭირდება ანგარიში; საჯარო დახმარების ცენტრისთვის — მხოლოდ ავტორებს.

გადაწყვეტილებები და კომპრომისები

რედაქტორი: Markdown თუ rich text

Markdown სწრაფია, გადატანადია და კარგად მუშაობს ვერსიების ისტორიასთან, მაგრამ ზოგ ავტორს არ მოსწონს. rich-text რედაქტორი სათაურებით, სიებით, სურათებით, მინიშნებებითა და კოდის ბლოკებით ნაცნობი შთაბეჭდილებას ტოვებს. რომელსაც არ უნდა აირჩიოთ, შეინახეთ კონტენტი ფორმატში, რომლის მერეც ექსპორტი შესაძლებელია.

ძიება

ბაზისური ტექსტური ძიება საკმარისია რამდენიმე ასეული სტატიისთვის, თუ ეძებთ სათაურებში, შეჯამებებსა და ტექსტში და სათაურების დამთხვევას მაღალ რანგს აძლევთ. მეტისთვის, ან თუ მნიშვნელოვანია ტიპოგრაფიული შეცდომები და სინონიმები („ინვოისი“ და „ანგარიში“), გამოიყენეთ სრული ტექსტური ძიება ან ჰოსტირებული საძიებო სერვისი. ჩვენი ძიების დამატების გზამკვლევი ვარიანტებს განიხილავს. ყოველი მოთხოვნა, რომელსაც შედეგი არ აქვს, შეინახეთ: ეს უფასო სია არის სტატიებისა, რომლებიც უნდა დაწეროთ.

AI პასუხები

„დასვი კითხვა“ ველი, რომელიც პასუხს თქვენი სტატიებიდან იღებს, ახლა გავრცელებულია. ის მუშაობს შესაბამისი ფრაგმენტების მოძებნით და ენის მოდელისთვის იმის თხოვნით, რომ მხოლოდ მათ დაეყრდნოს — იხილეთ რა არის RAG. ყოველთვის აჩვენეთ წყარო სტატიები, დაუშვით პასუხი „არ ვიცი“ და გახსოვდეთ, რომ მოდელი სანდოდ გაიმეორებს ყველაფერს, რაც სტატიებში მოძველებულია. ააწყვეთ ის მას შემდეგ, რაც სტატიები კარგ მდგომარეობაში იქნება, და არა მანამდე.

ვერსიები და შემოწმება

შეინახეთ რევიზიები, რომ დაინახოთ, ვინ რა შეცვალა და შეძლოთ უკან დაბრუნება. მარეგულირებელი კონტენტისთვის (HR პოლიტიკა, უსაფრთხოების პროცედურები) დაამატეთ დამტკიცების ეტაპი გამოქვეყნებამდე.

პირველი მოთხოვნა, რომელიც მუშაობს

ააშენე საჯარო დახმარების ცენტრი Parcelly-სთვის, მცირე ონლაინ მაღაზიებისთვის განკუთვნილი გადაზიდვის ეტიკეტების აპისთვის. მთავარი გვერდი დიდი ძიების ველით და ექვსი კატეგორიით (დაწყება, ეტიკეტების ბეჭდვა, გადამზიდავები, ანგარიშსწორება, დაბრუნებები, პრობლემების მოგვარება). სტატიებს აქვს სათაური, შეჯამება, ტექსტი Markdown ფორმატში სურათებითა და მინიშნებებით, კატეგორია, ტეგები, სტატუსი (დრაფტი, გამოქვეყნებული, არქივირებული), მფლობელი და ბოლო შემოწმების თარიღი. სტატიის გვერდებზე ჩანს შინაარსის ცხრილი, დაკავშირებული სტატიები და კითხვა „დაგეხმარათ?“ კი/არა ვარიანტით და არასავალდებულო კომენტარით. ძიება ეძებს სათაურებში, შეჯამებებსა და ტექსტში, სათაურების დამთხვევა პირველ რიგშია, და ყოველ მოთხოვნას და იმას, დააბრუნა თუ არა შედეგი, ინახავს. რედაქტორის არე (საჭიროა ავტორიზაცია, როლები editor და admin) ჩამოთვლის დრაფტებს, სტატიებს, რომლებიც 180 დღის განმავლობაში არ შემოწმებულა, და სტატიებს დაბალი დახმარების შეფასებით, და ინახავს რევიზიების ისტორიას. თითოეულ სტატიას აქვს საკუთარი გვერდის სათაური და meta აღწერა საძიებო სისტემებისთვის. სუფთა, მშვიდი, კითხვადი დიზაინი. ჯერ მობილურისთვის.

აშენების ეტაპები

1. ჩამოწერეთ პირველი 20–30 სტატია რეალური მხარდაჭერის შეკითხვებიდან, სანამ რამეს ააშენებთ. ეს სია კატეგორიებს განსაზღვრავს.
2. დააგენერირეთ საიტი და შეამოწმეთ კითხვადობა ტელეფონზე — ხაზის სიგრძე, სათაურები, სურათები.
3. რედაქტორი და როლები. ავტორებმა უნდა შეძლონ სტატიების დამატება და გასწორება დეველოპერის დაკითხვის გარეშე.
4. ძიება, შემდეგ ტესტირება იმ სიტყვებით, რასაც მომხმარებლები რეალურად წერენ, მათ შორის მართლწერის შეცდომებით.
5. უკუკავშირი და ძიების ჟურნალი.
6. მოძველებული სტატიების ანგარიში მფლობელისა და ბოლო შემოწმების თარიღის მიხედვით.
7. SEO-ს საფუძვლები საჯარო საიტისთვის: უნიკალური სათაურები, აღწერები, სუფთა URL-ები, საიტის რუკა. იხილეთ SEO AI-ით აშენებული საიტებისთვის.
8. დააკავშირეთ თქვენს პროდუქტს და მხარდაჭერის პასუხებს, შემდეგ ყოველკვირეულად შეამოწმეთ ძიების ჟურნალი შედეგების გარეშე.
9. AI პასუხები, როცა კონტენტი მყარია.

გავრცელებული შეცდომები

• ორგანიზაცია დეპარტამენტების მიხედვით მკითხველის მიზნის მაგივრად.
• გრძელი სტატიები, რომლებიც ხუთ დავალებას ფარავს. ერთი დავალება ერთ სტატიაში, სათაურით, რომელიც ამბობს, რას წყვეტს.
• მფლობელის გარეშე. ვერავინ განაახლებს არაფერს, და ნდობა პირველი არასწორი პასუხის შემდეგ ეცემა.
• შიდა შენიშვნები საჯარო სტატიებში. გამოიყენეთ ცალკე ხილვადობა და შეამოწმეთ გამოქვეყნებამდე.
• ძიება, რომელიც მხოლოდ სათაურებს ამოწმებს. მკითხველი სიმპტომებს წერს, სტატიების სახელებს არა.
• ეკრანის ანაბეჭდები alt ტექსტისა და კონტექსტის გარეშე. ისინი სწრაფად ძველდება; ნაბიჯი სიტყვებითაც აღწერეთ.

როდის სჯობს მზა პროდუქტი

თუ თქვენი გუნდი უკვე დოკუმენტაციის ან ვიკის ინსტრუმენტში მუშაობს, შიდა ცოდნის ბაზა იქ ყველაზე ადვილი გზაა — ჩვენი Notion vs Confluence შედარება ორ გავრცელებულ არჩევანს განიხილავს. თუ იყენებთ helpdesk პროდუქტს, მისი ჩაშენებული დახმარების ცენტრი სტატიებს ბილეთებს უკავშირებს და მომხმარებლებს სტატიებს სთავაზობს, რაც რთულია სხვაგან გაიმეოროთ. დოკუმენტაციის საიტების გენერატორები იდეალურია კოდთან ერთად შენახული დეველოპერული დოკუმენტაციისთვის.

საკუთარი აშენება მაშინ გჭირდებათ, როცა გჭირდებათ საკუთარი სტრუქტურა ან უფლებები (სტატიები თითო კლიენტზე, ლოკაციაზე ან როლზე), როცა ცოდნის ბაზა თქვენს პროდუქტის შიგნით უნდა იყოს და არა ცალკე საიტზე, როცა გჭირდებათ მიმოხილვისა და დამტკიცების ეტაპები, რომლებსაც ვიკი არ ახორციელებს, ან როცა AI პასუხები გინდათ თქვენს კონტენტზე სხვა გამოწერის გარეშე. ის ბუნებრივად ერწყმის მორგებულ helpdesk-ს.

აშენება Mythex-ით

Mythex-ზე ცოდნის ბაზას ჩატში აღწერთ და ცოცხალ გადახედვაში აშენდება; სტატიები, რევიზიები და უკუკავშირი შეინახება Postgres მონაცემთა ბაზაში, რომელსაც აგენტი საჭიროებისას დაამატებს, სურათები კი პროექტის ფაილურ საცავში მოხვდება. რედაქტორის შესვლა იყენებს ავტორიზაციის მიდგომას, რომელსაც თქვენ ირჩევთ, რადგან Mythex-ს ბოლო მომხმარებლის შესვლა ჩაშენებული არ აქვს. AI პასუხებისთვის იყენებთ თქვენი AI პროვაიდერის API გასაღებს, რომელიც პროექტის საიდუმლოებად ინახება, და გამოყენება თქვენი პროვაიდერის ანგარიშზე ირიცხება და არა Mythex-ის კრედიტებში (AI რეცეპტი). Mythex-ის ახალი აპლიკაციები ნაგულისხმევად არის კლიენტ-მხარის React single-page აპი, რომელიც საძიებო სისტემებისთვის სუსტია, ამიტომ საჯარო დახმარების ცენტრისთვის სთხოვეთ სტატიკურად მოსახერხებელი ან სერვერზე რენდერებული გამართვა, მაგალითად Next.js (SEO რეცეპტი).

პირველი მოთხოვნისთვის სცადეთ პროდუქტის ცოდნის ცენტრის ან გუნდის დოკუმენტაციის აპის შაბლონები.

კითხვები