Sådan har vi samlet websøgning og AI-chat-agent i ét felt

Nogle gange har du bare brug for at finde en kontaktperson eller en bestemt side, andre gange leder du efter mere komplekse svar.

På mange websites forsøger man at løse denne udfordring ved at tilbyde brugerne både en klassisk søgefunktion og en AI-agent. Men for brugerne kan det være svært at vide, hvornår de skal bruge den ene eller den anden funktion.

Den problematik blev udgangspunkt for, at vi udviklede Illumi Agent – en løsning, der samler traditionel websøgning og AI-rådgivning i ét felt. På den måde skal brugerne ikke selv vælge mellem de to funktioner. Bliv klogere på vores tanker og teknologien bag løsningen.

AI skal være en hjælp – ikke bare tilføje kompleksitet

På illumi.dk ville vi gerne udnytte AI-mulighederne til at hjælpe vores besøgende rundt på websitet. Vi havde i forvejen en traditionel, velfungerende søgefunktion, som i mange tilfælde dækkede søgebehovene, men vi øjnede en mulighed for at hjælpe vores besøgende endnu bedre, i de tilfælde hvor de havde mere komplekse spørgsmål til os og vores ydelser.

Vi ønskede dog ikke at forvirre vores besøgende med to forskellige måder at søge på. Ofte er man jo ikke længere bevidst om, hvorvidt man søger på den ene eller den anden måde – man skriver bare det ord eller spørgsmål, der falder en mest naturligt.

Derfor ønskede vi at lave en løsning der kunne håndtere begge intentioner i samme interaktion. På den måde skal vores besøgende ikke vælge, om de vil søge på ”gammeldags” manér eller chatte med en AI-agent. Løsningen vurderer selv, hvad de er ude efter: en side, en person, en formular eller et mere omfattende svar. Og agenten bliver kun startet, når der er brug for rådgivning.

Grundlaget for Illumi Agent er en standardiseret vurdering af brugerens intention, et fælles videnslag i Algolia og Algolia Agent Studio. Vi havde allerede en stor del af det vidensgrundlag, agenten skulle bruge: websiteindhold, cases og medarbejdere, struktureret i Umbraco CMS og gjort søgbart i Algolia. Derfor byggede vi agenten oven på den eksisterende søgning frem for ved siden af den.

Som du måske kan fornemme, bliver det nu lidt teknisk, så hæng på. Jeg vil både komme ind på hvordan Illumi Agent er bygget op, hvilke valg vi har truffet undervejs, og hvor vi stadig har åbne spørgsmål.

Besøgende skal ikke vælge mellem at søge og spørge

En klassisk samtaleoplevelse fungerer godt til spørgsmål som ”Kan I udvikle en kundeportal, der taler med vores ERP?”. Men mange besøgende skriver ikke spørgsmål. De skriver ”kontakt”, et navn eller et par søgeord og forventer at komme direkte videre.

Når søgning og agent ligger hver for sig, er det den besøgende, der skal forstå forskellen. Vi ville i stedet have én indgang, der opfører sig fornuftigt, uanset hvad der bliver skrevet i den.

Løsningen skelner mellem fem intentioner, som kan udvides over tid:

• Navigation: Den besøgende leder efter en side eller et emne og får søgeresultaterne med det bedste træf først.

• Person: Den besøgende leder efter en medarbejder eller en rolle og får kontaktkort.

• Support: En eksisterende kunde beskriver en fejl og får supportformularen, udfyldt med det, kunden allerede har skrevet.

• Kontakt: Den besøgende vil kontaktes og får kontaktformularen på samme måde som beskrevet i support-scenariet.

• Rådgivning: Den besøgende stiller et spørgsmål eller beskriver et behov og får agentens tekstsvar ved siden af søgeresultaterne.

Den samlede løsning ser i hovedtræk sådan ud:

En lille vurdering foran den store model

Valget mellem de fem grene/intentioner bliver ikke truffet af sprogmodellen i Agent Studio. Det bliver truffet, før agenten overhovedet er involveret, af Jev fra TypeSafe.

Jev er en lille model, der svarer på et afgrænset spørgsmål med et typet svar. Det vil sige et svar, der er baseret på de fem intentioner, vi har defineret. Med andre ord stiller vi Jev ét spørgsmål: Hvad vil den besøgende, der skrev dette i søgefeltet? Svaret er en af de fem intentioner sammen med en vurdering af, hvor sikker Jev er.

Vurderingen kører samtidig med søgningen, så den besøgende ikke venter ekstra på den. Er Jev i tvivl, eller svarer den ikke i tide, falder løsningen tilbage til rådgivning, som viser både et tekstsvar og relevante søgeresultater. Et navn, som medarbejdersøgningen genkender, giver altid kontaktkort, uanset hvad Jev svarer.

Vi kunne have ladet den store model i Agent Studio afgøre, om den skulle åbne en formular eller lede efter en person. I stedet er beslutningen applikationens, og den bliver truffet med et værktøj, der er bygget til netop den slags vurderinger.

Vores vigtigste læring her var, at ikke alle beslutninger i en AI-løsning behøver en sprogmodel, der ræsonnerer og kalder værktøjer. En typet vurdering er hurtigere, billigere og lettere at teste. Den gør også agenten mere fokuseret, fordi den kun bliver brugt, når der faktisk er brug for rådgivning.

Søgningen er agentens første opslag

Når en besøgende får rådgivning, har søgningen allerede kørt. Det udnytter vi. De sider, søgningen fandt, sendes med til agenten som skjult kontekst sammen med uddrag af den tekst, der matchede.

Vi har instrueret agenten i at svare ud fra disse resultater, når de dækker spørgsmålet, og kun søge selv, når der mangler noget. Det sparer værktøjskald, giver kortere svartid og giver en bedre sammenhæng mellem tekstsvaret og de søgeresultater, den besøgende kan se ved siden af.

Konteksten fortæller også, hvad siden allerede har gjort: hvilke formularer der er sendt eller fravalgt, og hvilke kontaktkort der er vist. Så tilbyder agenten ikke en formular, den besøgende lige har takket nej til. Konteksten bliver eksplicit behandlet som upålidelige data. Agenten må bruge oplysningerne, men aldrig følge instruktioner i dem.

I brugerfladen bliver links i svaret til kilder, og de sider, agenten selv finder, glider ind i listen over relevante sider. Svar og resultater er dermed én samlet visning frem for to separate oplevelser.

Ét videnslag til både søgning og agent

Søgningen og agenten bruger de samme indeks i Algolia: i vores tilfælde sider og medarbejdere på dansk og engelsk. Det, den besøgende ser i resultaterne, og det, agenten svarer ud fra, kommer dermed fra samme kilde.

Sideindekset rummer ydelser, teknologier, cases, artikler og oplysninger om Illumi. Cases er vores dokumentation: De er kategoriseret i forhold til brancher, teknologier, løsninger og de kompetencer vi har i huset. Teknologier, tags og kompetencer er fælles elementer i Umbraco, så den samme værdi går igen på tværs af sider. Det gør det muligt for agenten at finde netop de cases, der handler om fx integrationer i en bestemt branche.

Vi har også selv formuleret de beskrivelser af indeksene, som agenten læser sammen med søgeværktøjet, i stedet for at bruge de automatisk genererede. Vores beskrivelser forklarer, hvad en post er, og hvordan indeksene hænger sammen – ikke hvilke interne felter der findes.

Indeksdesign er en del af agentarkitekturen. Når et svar mangler præcision, undersøger vi projektionen fra Umbraco, felterne og relationerne – ikke kun agentens instruktion.

Agent Studio driver samtalen – vi sætter grænserne

AI-rådgivningen kører på Algolia Agent Studio. Agent Studio forbinder sprogmodellen med Algolia Search, håndterer værktøjskald og streaming og giver os feedback, forslag til opfølgende spørgsmål og guardrails, der kan stoppe et svar undervejs.

Agentens systeminstruktioner er bevidst korte. Agenten har kun én rolle: Illumis konsulent på illumi.dk. Instruktionerne er delt i nogle få afsnit, som hver styrer én ting:

• Stemme

• Forankring

• Kilder

• Kontekst.

Instruktuktionerne bliver løbende justeret som en del af agentens evaluering.

Brugerfladen er vores egen. Den er bygget med Lit-webkomponenter, mens Vercel AI SDK fungerer som transport- og tilstandslag under dem. Agent Studio leverer et kompatibelt streamformat, så vi undgår en særskilt protokoladapter mellem agenten og browseren.

En pris ved en administreret runtime er, at agentens instruktion, værktøjer og indeksbeskrivelser bor i Algolias dashboard frem for i vores kode. De bliver ikke gennemgået i pull requests på samme måde som resten af løsningen. Vi har derfor en intern beskrivelse af alle indstillingerne, som vi holder opdateret, når den ene eller den anden side ændrer sig.

Browseren taler kun med vores egen server

Browseren kalder ikke Agent Studio direkte. Alle kald går gennem Illumis egen backend, som sender dem videre til Algolia. Nøglerne forlader aldrig serveren, og backenden afviser kald fra andre oprindelser og begrænser, hvor store forespørgsler og samtaler må være.

Proxyen begrænser ikke antallet af kald pr. besøgende. Den beskyttelse ligger i de begrænsninger, vi har sat på nøglen hos Algolia.

Besøgende får en pseudonym identitet, så Agent Studio kan knytte samtaler til den samme besøgende uden at vide, hvem det er. Cookieklassifikation og den overordnede privacy-model er fortsat governance-spørgsmål. Pseudonymitet afgør dem ikke alene.

Formularer følger samme princip. Agenten kan bede om at få vist kontakt- eller supportformularen, men det er den besøgende, der udfylder og sender den, og backenden validerer indsendelsen efter de samme regler som resten af sitets formularer. Agenten får kun at vide, om formularen blev sendt, og de indtastede persondata bliver ikke sendt med i senere beskeder.

Et værktøj som dette ser lille ud i agentens grænseflade, men er stadig input fra en ekstern klient. Validering og udførelse skal derfor følge applikationens eksisterende sikkerhedsgrænser.

Vi måler både søgningen og samtalen

Før og efter hver ændring til agentens parametre kører vi et fast sæt søgninger og sammenligner, hvilken gren de lander i, og hvilke sider der ligger øverst. Sættet dækker navigation, spørgsmål, fejlmeldinger, personer, sammensatte ord, synonymer og spørgsmål, hvor svaret skal underbygges af cases.

Det har gjort forbedringerne konkrete. Med synonymer finder ”hjemmeside” og ”website” nu de samme sider. Med dansk orddeling finder ”medarbejderhåndbog” siden ”Håndbog for medarbejdere”.

I samtalen sender frontenden visnings-, klik- og konverteringshændelser til Algolia, knyttet til den besked og det søgekald, der viste resultatet. Søgningens egne forespørgsler og agentens søgninger er mærket forskelligt, så de kan holdes adskilt i analytics, selvom de bruger de samme indeks.

Det, vi endnu ikke måler systematisk, er kvaliteten af selve svarene. Et testsæt for routing og søgning fortæller, om den besøgende lander det rigtige sted. Det fortæller ikke, om agentens råd var godt. Det er den læring, vi stadig arbejder med: En målbar handling er ikke nødvendigvis det samme som et godt svar.

Kontrol er ikke et enten-eller

Valget af en administreret agentplatform bliver ofte beskrevet som et spørgsmål om, hvem der skal styre agenten: platformen eller os selv. I praksis er billedet mere nuanceret.

Illumi Agent består af tre lag med hver sin ejer. Den klassiske søgning og videnslaget er vores. Vurderingen af den besøgendes intention er også vores beslutning, truffet med et specialiseret værktøj. Selve agenten, der giver rådgivningen, kører i Agent Studio.

Det giver os kontrol der, hvor den betyder mest for den besøgende: Hvad der sker, når de skriver noget i feltet, hvilke data der forlader vores server, og hvordan formularer bliver håndteret. Agent Studio tager sig af det, der er dyrt at bygge og drive selv.

Vi ville overveje en mere applikationsejet runtime, hvis agenten skulle koordinere flere interne systemer, køre langvarige processer eller håndtere eksplicitte godkendelser. Behovet er dog mindre, fordi de vigtigste beslutninger allerede ligger i applikationen.

Det afgørende arbejde med en løsning som Illumi Agent ligger ikke i at få modellen til at lyde intelligent. Det ligger i at forstå, hvad den besøgende er ude efter, og kun bruge agenten, når den faktisk kan hjælpe.