A Community modul ket fo content-surface-szel indul: egy klasszikus, manualisan szerkeszthato Knowledge Base (KB), es egy LLM-generalt auto-FAQ, ami a hetente megerlt kerdesekbol szuli az uj cikkeket. A ket felulet eltero terjedelmu, eltero menedzsment-szabalyokkal, es eltero biztositekokkal.
A KB: tenant-admin altal szerkesztheto
A Knowledge Base a vendor-curated tudasanyag a tenant-spec atfedessel. A vendor kiadja a kozos baseline-t (~120 cikk a launch-kor: hogy mukodik a Finance NAV-integracio, hogyan vegez egy multi-warehouse stock-take-et, stb.). A tenant-admin ezeket kiterjesztheti tenant-specifikus cikkekkel: a sajat workflow-jaikat, sajat eljarasaikat, sajat onboarding-anyagat.
A KB cikkek markdown-ban iralodnak, version-controlled (minden mentes egy uj revision), es per-cikk szabalyozhato lathatosaggal (csak a tenant peer-jeinek, vagy cross-tenant publikus). Az ervenyeses, az ellenorzott valaszok ide kerulnek, nem a forum-thread-be.
Az auto-FAQ: harom forrasbol generalva
Az auto-FAQ heti egyszer fut, es harom forrasbol genera javaslatokat:
- Top support tickets. Az adott hetben legtobbszor felmerult support-temak. A ticket-szoveg anonymized (nevek, ceg-azonositok, szamlaszamok kicserelve placeholder-re), majd embed-elt es klaszterezve.
- Top chat-agent transkriptek. A chat-agent altal megvalaszolt kerdesek, ahol a customer-feedback ("hasznos volt" / "nem volt hasznos" gomb) explicit positive. Csak anonymized formaban.
- Megoldott community-kerdesek. A heten resolved-flag-gel jelolt thread-ek, ahol a megoldas markozott ("Accepted Answer").
A harom forrasbol ~20-40 javaslat jon ki hetente. Egy LLM (GPT-5-class) megfogalmaz minden javaslatot Q&A formatumba, jeloli a forrast ("based on 7 support tickets and 3 community threads"), es egy admin-jeloleshez kuldi.
Az approval-flow es az eval-kapu
A javaslatok egy admin-queue-ba kerulnek (heti digest emaillel). A vendor-staff approval-jenel harom dontes lehetseges: publish-as-is, publish-with-edits, vagy reject. Minden dontest a backend rogzit a auto_faq_decision tablaba.
A mertek-szam, amivel jellemezzuk az auto-FAQ minoseget: % of FAQs that the human approver edits. Target: <30%. Ha ez a szam 30% fele megy, az azt jelenti hogy a LLM-prompt regenoltani kell, vagy a forras-anyagok zsajossak; az iteracio addig megy amig a metric tarthato.
A publish-rejected FAQ-k egy negative-example-set-be mennek, amit a kovetkezi LLM-prompt iteracioja hasznal hint-kent.
Ket kategoria, amit szandekosan NEM auto-generalunk
-
Security advisories. Ha egy security-temaval kapcsolatos kerdes felmerul a support-ben, a vendor-securityteam azt mindig manualisan kezeli, mert egy LLM-generalt security-cikk hibasan all benne nemcsak hogy felrevezeti a felhasznalokat, hanem aktivan novelheti a tamadasi feluletet. A security-advisory egy kulon, manualisan szerkesztett KB-secio.
-
Pricing. A pricing-kerdesekre az auto-FAQ-nak nincs koze. Mind az aktualis arazas (amelyik valtozhat), mind a tenant-specifikus diszkontok (amik szerzodesektol fuggnek) erzekeny temak, amiket nem akarunk LLM-mediated formaban publikalni. A pricing-kerdesek a sales-team-hez routalodnak, automatikus kihagyassal az auto-FAQ-bol.
Mit jelent az approval-rate a gyakorlatban
A <30% edit-rate gyakorlatilag azt jelenti hogy 100 javaslatbol kb. 65-70 mehet at edit nelkul, 25-30 minimalis (1-2 mondat) editel, es csak nehany kerul kihajtasra. Ez fenntarthato heti workload: ~30 perc admin-time hetente, nem heromhetente ujraszervezett, embert tarto manualis FAQ-irasi sprint.
A frissites-kadencia es a stale-detect
A KB-cikkek nem statikusak. Minden cikkhez tartozik egy last_reviewed_at mezo, amit a tenant-admin manualisan frissithet. Ha egy cikk 6 honapnal regibb es kapcsolodo kerdesek erkeznek a chat-agent-en vagy a forum-on, egy heti reminder felulet jelzi az admin-nak, hogy a cikk frissitese eshetne. Ez nem auto-rewrite (lasd a security + pricing kihagyast lentebb a hasonlo elven), csak egy figyelmezteto digesz.
A stale-detect ket signal-bol erkezik: (a) chat-agent-tranzaktor amelyik a kerdest a KB-bel jol valaszolta meg, de a felhasznaloi visszajelzes "nem volt hasznos" volt; (b) forum-thread, amelyik az adott KB-cikkre eltero valaszt ad, es a thread "resolved" peer-mark-szal lezarult. Mindket signal egy stale-score-t emel, es 3 felett a digest-be kerul.
Multilanguage es a HU/EN parhuzam
A Netorigo platform mind HU mind EN nyelven mukodik. A KB-cikkek elsodleges nyelve a tenant-default-jara epul, de minden cikket ket nyelven tartunk fenn. A LLM-generalt auto-FAQ az osszekapcsolt forrasokbol (HU + EN ticket-anyag) szintetizalja a javaslatot, es egyszerre ket nyelven adja meg a human-approver-nak.
A human-approver-nak nem kell ket nyelven szerkesztenie egyenkent; a approve-on-en lehet "approve HU, retranslate EN", ami a HU-edited valtozatot fordittatja vissza a LLM-mel EN-re, kulon mini-approve-pal.