Eikö ole turvallista sanoa, että ajatus “ensisijaisen kyselyvastaus-/palvelupisteen korvaamisesta tekoälyllä” on nyt yleinen ajatus? Itse asiassa se, mitä haluan tehdä, on selvää. Haluamme lyhentää odotusaikaa, vähentää operaattorin taakkaa, vähentää henkilöstöä ja tasoittaa vastausten laatua. Tätä tarkoitusta ei vastusteta.

Yleinen virhe on, että menetelmäksi valitaan usein “anna RAG syödä kaikki”. Testasin henkilökohtaisesti kokoonpanoa, joka syöttää aiemmat lokit, sisäiset wikit ja chat-historian kerralla, mutta se, mitä sain, ei ollut odotettu tehokkuus, vaan näennäisesti roskaisten vastausten massatuotanto.

Päätelmä on selvä. Osittainen korvaaminen on mahdollista, mutta SD-korvaus ilman suunnittelua tietotoiminnan on suuri todennäköisyys epäonnistua. Ja suurin osa vioista ei johdu mallinvalintavirheistä. Syöttötietojen laatu ja operatiivisten vastuiden suunnittelu ovat riittämättömiä.

Palvelupistekentässä vaaditaan yhtä aikaa oikeita vastauksia ja auditoitavuutta. Näiden molempien tavoitteiden saavuttamiseksi ainoa tapa saavuttaa molemmat on saada “virallista tietoa, joka on hyväksytty ja oikea organisaatiolle”.

Johtopäätös ensin

  • Vaikka syötät koko aiemman lokin, jos laatu on heikko, se yksinkertaisesti etsii roskat suurella nopeudella ja palauttaa roskamaisia ​​vastauksia.
  • Vaikka kaikki organisaation sisäinen tieto syötetään, jos muodollisen ja epävirallisen raja on epäselvä, siitä tulee väline, jolla voidaan perustella väärät vastaukset ilman organisaation virallista kontekstia tai sääntöjä.
  • Rakenne, joka vastaa vain yleisellä tasolla, on organisaation sääntöjen vastainen, eikä sitä voida käyttää kentällä.
  • Todellinen ratkaisu on ajaa KCS (Knowledge-Centered Service) -silmukka tekoälyn avulla ja selvittää viitelähteen ja vastuuhenkilön laatu.
  • Tekoälyä, joka ei voi viitata hyväksyttyyn viralliseen tietoon, ei voida käyttää palvelupistetuotannossa.

Miksi “panna kaikki toistaiseksi” epäonnistuu?

1. Menneen kirjeenvaihdon lokit eivät ensinnäkään ole tietoa.

Monet kyselylokit kirjoitetaan sulkemaan lippuja kentällä. Vaikka tämä sinänsä on oikein liiketoiminnallisiin tarkoituksiin, se ei useinkaan riitä uudelleenkäytettäviksi tietoiksi.

  • Edellytykset puuttuvat (käytetty laite, auktoriteetti, yhteysreitti, ympäristön ero).
  • Tavoitteena on suorittaa lippu loppuun, ja äärimmäisissä tapauksissa se voi päättyä “kirjeenvaihto suoritettuna”. Ei tarkoitettu uudelleenkäyttöön.
  • Sekoitus lyhenteitä ja puhekieltä, ja se perustuu vastuuhenkilön hiljaiseen tietoon.
  • Perimmäistä syytä ja väliaikaista kiertotapaa ei eroteta.

Jos tässä tilassa oleva loki lähetetään RAG:lle, vaikka haku onnistuisi, vastaus ei ole tarkka. Tämä johtuu siitä, että tekoäly voi uskottavasti täydentää asiakirjoja, jotka ovat epäselviä tai käsittämättömiä jopa ihmisten lukemina, mikä johtaa epärealististen harhaanjohtavien vastausten luomiseen. Tämä luo hankalan tilanteen, jossa vastaus on nopea, mutta ongelma ei ratkea. Vaikka luulet kehotteen olevan huono ja yrität virittää sitä niin lujasti kuin pystyt, se todennäköisesti päätyy turhaan. Ainakin minulle kävi niin.

2. Sisäisten tietojen täydellinen syöttäminen aiheuttaa “virallista laimentumista”

Kokoonpano, jonka avulla käyttäjät voivat lukea “kaikki sisäiset wikit”, “kaikki tiedostopalvelimet” ja “kaikki chat-lokit”, on ensi silmäyksellä kattava. Todellisuudessa tämä on kuitenkin samanlaista kuin eri luotettavuuden omaavien tietojen järjestäminen samalle hakunäytölle.

Yleensä tapahtuu seuraavaa:

  • Viralliset menettelyt (hyväksytty) ja henkilökohtaiset muistiinpanot (hyväksymättömät) haetaan samasta sarakkeesta
  • Vanhentuneet menettelyt ovat edelleen olemassa ja ovat ristiriidassa uusimpien menettelyjen kanssa
  • Tilapäinen osaaminen on väärin lainattu pysyväksi menettelyksi
  • Kääntö tapahtuu, kun artikkelin päivityspäivämäärä ja -aika on uusi, mutta sisältö on vanhaa.

RAG on hyvä “löytämään asiakirjoja”. Kuitenkin on luotava erillinen järjestelmä varmistamaan, että dokumentti on organisaatiolle oikea.

3. Yleistyksiä ilman organisaatiosääntöjen tuntemista ei voida käyttää, vaikka ne olisivat oikein.

Tekoälyt, joilla on riittämätön muodollinen tietämys, palauttavat usein vastauksia, jotka ovat teknisesti oikeita mutta toiminnallisesti mahdottomia.

  • Myönnä paikallisen järjestelmänvalvojan oikeudet
  • Turva-asetusten väliaikainen lieventäminen
  • Ulkoisen pilven käyttö henkilökohtaisen harkinnan mukaan
  • Suora pääsy poikkitoiminnallisiin tietoihin

Vaikka tekoäly palauttaisi yleisen ratkaisun, sitä ei voida toteuttaa, jos se rikkoo organisaatiosääntöjä. Tällä hetkellä service desk AI:sta voi tulla jopa laite, joka oikeuttaa sääntöjen rikkomisen. Sitä ei voida käyttää ratkaisuna yritysten ongelmiin.

Esimerkkejä paikan päällä tapahtuvista vioista

Virheesimerkki 1: Virheellinen suunta VPN-yhteyden epäonnistumisen vuoksi

  • Oire: “Ei voi muodostaa yhteyttä VPN:ään kotoa”
  • AI vastaus: “Alusta käyttöjärjestelmän verkkoasetukset ja käynnistä uudelleen.”
  • Todellinen: Syynä on varmenteen peruuttaminen todennusinfrastruktuurin puolella, eikä sitä voida ratkaista käyttäjäpuolella.

miksi heräsit? Tämä johtuu siitä, että aiemmat lokit sisälsivät monia “henkilökohtaisten laitteiden tilapäisiä toimintahäiriöitä”, ja tekoäly vedettiin niihin. Lisäksi menettely “palvelupuolen vikojen eristämiseksi” oli virallisena tietämyksenä heikko, joten sitä ei luokiteltu huippuehdokkaaksi. Lisäksi organisaatiokontekstia “Onko käyttäjien nollata NW-asetukset ilman lupaa?” ei oteta huomioon vastauksessa.

Virheesimerkki 2: Ohjelmistosovelluksen sääntöjen rikkomisen ehdottaminen

  • Oire: “Haluan käyttää analyysityökaluja”
  • AI vastaus: “Lataa kokeiluversio itse ja ala käyttää sitä.”
  • Käytännössä: Hankinnat, lisenssien hallinta ja käsimatkatavaroiden seulonta ovat tärkeitä organisaatioille.

miksi heräsit? Tämä johtuu siitä, että viralliset hankintavirta-asiakirjat haudattiin viittaamalla ulkoisiin yleisiin artikkeleihin ja henkilökohtaisiin muistioihin. Tämä on tyypillinen esimerkki siitä, että ei voida erottaa “mitä voidaan tehdä” ja “mitä on hyvä tehdä”.

Virheesimerkki 3: Sama kysymys, vastaus vaihtuu joka kerta

  • Oire: “Millä vaiheilla sähköpostin edelleenlähetys määritetään?”
  • AI vastaus: Riippuu päivästä
  • Todellinen: Vanha toimenpidesivu ja uusi toimintosivu ovat rinnakkain

miksi heräsit? Tämä johtuu siitä, että “kelvollista versiota” osoittavia metatietoja (kelvollinen aloituspäivä, poistamispäivämäärä, hyväksyjä) ei ollut, ja vastaukset vaihtelivat hakusijoituksissa. Kun henkilökohtaiset sähköpostit ja chat-katkelmat yhdistetään, todennäköisyys, että epävirallinen selitys sijoittuu sattumalta korkeammalle, kasvaa.

Mitä tehdä: Suorita KCS-silmukka tekoälyn avulla

Todellinen ratkaisu ei ole korvata KCS:ää tekoälyllä. Kiihdytys KCS:n avulla AI.

Mikä on KCS?

KCS (Knowledge-Centered Service) on toimintakonsepti, joka tallentaa tiedusteluvastauksen alalla syntyneen tiedon, käyttää sitä uudelleen ja jatkaa sen parantamista. Tärkeintä ei ole kirjoittaa dokumenttia ongelman ratkaisemisen jälkeen, vaan upottaa tiedon päivitys itse ongelman ratkaisemiseen. Syy siihen, miksi KCS:ää arvioidaan uudelleen RAG-aikakaudella, on yksinkertainen: hakukohteen laatu määrää suurelta osin vastausten laadun.

Lyhyt tarina: Vanha tarina, mutta tehokas.

KCS on idea, joka alkoi vuonna 1992, paljon vanhempi kuin tekoäly. Syynä siihen, että se on tällä hetkellä tehokas, on kuitenkin se, että kentällä esiintyvät asiat eivät ole olennaisesti muuttuneet.

  • Siellä on loki, mutta en osaa lukea sitä.
  • Asiakirja on, mutta en tiedä virallista versiota.
  • Ei päivitetty ja mätää

Kun sisällytät sukupolven tekoälyn, nämä kolme asiaa pikemminkin vahvistuvat kuin katoavat. Siksi on järkevää palata tavalliseen mutta rikkoutumattomaan KCS-muottiin ennen näyttäviä uusia ominaisuuksia.

Vähimmäismääritys KCS-toiminnalle

  • “Kaappaa”: jäsentele ja tallenna oireet, syyt, vastatoimenpiteet ja sovellettavat ehdot, kun vastaat tiedusteluihin.
  • “Rakenne”: Luo malli ja tee ympäristöolosuhteet, tavoitealue ja kiellot pakollisiksi kohteiksi.
  • Uudelleenkäyttö: Katso seuraava kysely ja esitä vastaus ja perus-URL joukkona
  • “Paranna”: Heijastaa eroja todellisessa toiminnassa ja jatkaa moniselitteisten sanojen ja vanhojen menettelytapojen korjaamista

Tuotantosilmukka: Tekoälyvastausten vaaliminen virallisella tiedolla

Kentällä on realistista laajentaa asteittain käyttöaluetta seuraavassa silmukassa.

  1. Käyttäjä kysyy ensin tekoälyltä
  2. Jos tekoäly ei ratkaise ongelmaa, siirry Service Deskiin (SD)
  3. Muunna SD-vastaavuustietueet tiedoksi käyttämällä tekoälyn lukemiseen sopivia malleja
  4. Lisää vain hyväksytty ja tarkistettu virallinen tieto tekoälyn viitetietolähteisiin
  5. Tekoälyn ensisijainen vastausprosentti ja oikea vastausprosentti kasvavat samankaltaisten kyselyjen myötä

Tämän silmukan avainkohta on tiedon kertyminen, jota voidaan käyttää “hyväksymiseen” tai virallisiin vastauksiin “määrän” sijaan. Tee tekoälyn tietolähteeksi vain “hyväksytyt tiedot”, ei “tallennettuja tietoja”. Jos tämä rikotaan, vastausvalikoima laajenee, mutta tarkkuus ei.

Alueet, jotka voidaan jättää tekoälylle

  • Samankaltaisten kyselyjen klusterointi
  • vastausluonnosten luominen (todisteiden kanssa)
  • Osoita puuttuvat kohteet (“Kohdekäyttöjärjestelmä ei ole tiedossa”, “Valtuutuksen edellytyksiä ei ole ilmoitettu” jne.)
  • Ehdokkaiden esittely päällekkäisen tiedon yhdistämiseksi

Alueet, joilla ihmisten pitäisi olla vastuussa

  • Virallinen/epävirallinen tuomio
  • Menettelyjen hyväksyminen ja päätös niiden poistamisesta
  • Salli poikkeusten käsittely
  • Tietojen vanhenemisen hallinta

Vaikka yrittäisit jättää tämän tekoälylle, tekoäly ei pysty vastaamaan kunnolla.

Käytännön pointteja

Käytännössä on syytä pitää mielessä seuraavat seikat.

Tietotoiminnan puoli

  • Määrittele kuka ja milloin luo ja julkaisee millaista virallista tietämystä sekä päättää luomis- ja laadunvarmistusjärjestelmästä.
  • Määritä, kuka voi tarkastella tietoa ja päättää pääsyn hallinnasta.

AI-puoli

  • Neuvo oppilaita selkeästi perustelemaan vastauksiaan kehotteessa.
  • Älä salli epävirallisten/luvaton lähteiden käyttöä vastausten luomisessa.

Parannettu toiminta

  • Määritä keinot kerätä tekoälyn virheelliset vastaukset ja sisällyttää tiedon tuottaminen parannusta varten normaaliin toimintaan.

Nämä kolme kohtaa saattavat tuntua abstraktilta, mutta ne vaikuttavat toteutuessaan. Joukkueet, jotka päättävät “kuka on vastuussa”, kehittyvät ensin nopeasti, kun taas joukkueet, jotka eivät tee päätöksiä, tekevät toistuvasti samat virheet.

Vastaus kysymykseen “Voiko se korvata?”

Jos kysyt minulta, voidaanko palvelupiste 100-prosenttisesti korvata tekoälyagentilla, nykyinen vastaus on “ei”. Jos kuitenkin erittelet tiedustelutyypit ja perustat tietovastuita selventävän operaation, Ensisijaisten vastausten esittäminen, kiinteät ohjeet ja vakiomenettelyt voidaan korvata täysin.

Toisin sanoen kysymys ei ole itse tekoälyn älykkyydestä.

  • Mitä tietoja hyväksyä virkamieheksi?
  • Kuka takaa laadun?
  • Kuka estää sinua, kun teet virheen?

Vain organisaatiot, jotka voivat suunnitella nämä kolme pistettä, pystyvät muuttamaan tekoälyagentit “pelkästään pikakeskustelutyökalusta” “liiketoiminnaksi”. Toisaalta organisaatio, jolla ei ole hyväksyttyä virallista tietotoimintaa, ei pysty luomaan palvelupisteen laatua, olipa malli kuinka pitkälle kehitetty tahansa.

yhteenveto

Ajatus siitä, että “jos sisällytät kaikki lokit, sinusta tulee älykkäämpi” on illuusio. Todellinen syy siihen, miksi service desk AI on jumissa, ei ole tiedon määrä, vaan tiedon hallinnan puute.

Se, mitä meidän nyt tarvitsee tehdä, ei ole suurta täydellistä automaatiota. Tämä on hillitty operaatio, joka käyttää tekoälyapua KCS-silmukan suorittamiseen ja virallisen tiedon kehittämiseen.

Kun organisaatiot alkavat hyväksyä tämän vaatimattomuuden, niiden vastausten laatu muuttuu näkyvästi. Käytettäessä tekoälyä palvelupisteessä, tärkein prioriteetti on aina sama. ** Kehitä jatkuvasti hyväksyttyä ja institutionaalisesti oikeaa virallista tietoa. **

Viitemateriaalit