RAG-chatbot asiakkaalle ja henkilöstölle

Mikä on RAG?

Retrieval Augmented Generation — tiedon­haun ja tekstin­generoinnin yhdistelmä. LLM ei vastaa muistinsa varassa vaan hakee ensin relevantit lähde­katkelmat ja kirjoittaa vastauksen niiden pohjalta. Merkittävä ero vs. “puhdas” LLM:

• Vastaus on jäljitettävissä — joka väite voidaan kytkeä lähteeseen
• Tuore data — päivittyy kun dokumentit päivittyvät, ei vaadi mallin uudelleen­koulutusta
• Organisaation oma tieto — LLM ei ole koskaan “nähnyt” sitä mallin­koulutuksessa, mutta hakee sen haku­ajoissa
• Hallusinaatiot minimoituvat — kun konteksti tulee haetuista lähteistä, malli ei keksi tietoa tyhjästä

RAG on nykyisen “tekoälyä tieto­varasta” -käyttötapauksen perusta, ja toteutin sen kahdessa rinnakkaisessa muodossa samalle asiakkaalle.

Lähtötilanne

Organisaatiossa oli kaksi erillistä tieto­tarvetta:

1. Ulkoiset asiakkaat kysyivät yhä useammin samanlaisia peruskysymyksiä — jäsenyys, palvelut, edut, yhteys­tiedot. Verkkosivun FAQ vastasi osaan, mutta ei löytänyt monisanaisille luonnollisen kielen kysymyksille.
2. Oma henkilöstö tarvitsi nopeamman pääsyn sisäisiin ohjeisiin, säännöstöihin, työohjeisiin, prosessi­kuvauksiin — asioita joita ei voinut eikä saanut näyttää julkisesti, mutta joita etsittiin päivittäin ja joista tulkittiin eri tavoin eri henkilöiden kesken.

Molempiin olisi voitu tehdä erillinen ratkaisu, mutta arkkitehtuuri­tasolla ne ovat sama ongelma eri oikeuksilla.

Tehty ratkaisu

Rakensin pohjan, joka palvelee molempia käyttö­tapauksia:

• Dokumentti-indeksointi Azure AI Searchiin — sekä tekstihaku että vektori­haku (hybrid). Asiakirjat segmentoidaan sopivan kokoisiksi katkelmiksi ja ajetaan embedding-mallin läpi.
• Orkestrointi­kerros FastAPI:lla — ottaa käyttäjän kysymyksen, tekee haut AI Searchiin, rakentaa kontekstin, kutsuu Azure OpenAI:n chat-mallia, streamaa vastauksen SSE:llä takaisin käyttö­liittymään.
• Two-deployment -malli. Sama sovellus deployattuna kaksi kertaa: julkinen ilman tunnistusta ja rajoitettu ulkoiselle datalle; sisäinen Entra ID Easy Authin takana ja pääsee sisäiseen indeksiin. Käyttäjän oikeudet ratkaisevat mitä dataa haku voi ylipäätään nähdä.
• Lähde­viitteet aina näkyvissä. Jokainen vastaus sisältää linkit niihin dokumentti­kohtiin joiden pohjalta se muodostui. Hallusinaatio­riski pienenee, ja käyttäjä voi aina tarkistaa.
• Streaming UI. Vastaukset muotoutuvat ruudulle sanana kerrallaan — sama tuttu kokemus kuin ChatGPT:ssä, mutta organisaation omalla datalla ja sisäisen chatbotin osalta oman tietoturva­rajan sisällä.

Ero kahden deploymentin välillä

	Julkinen chatbot	Sisäinen chatbot
Tunnistautuminen	Ei (tai kevyt rate limit)	Entra ID Easy Auth
Data­lähde	Julkinen tieto­pankki	Sisäinen dokumentaatio
Käyttö­tapaus	Asiakkaiden peruskysymykset	Henkilöstön sisäinen tieto­haku
Käyttö­liittymä	Upotettu nettisivulle	Sisäinen portaali

Lopputulos

• Asiakas sai kaksi tuote­maista chat­kokemusta yhdellä kehitys­projektilla — arkkitehtuurin uusio­käyttö teki toisesta deploymentista nopean rakentaa kun ensimmäinen oli pystyssä.
• Tietoturva kestävällä pohjalla. Sisäinen chatbot toimii vain kirjautuneelle henkilöstölle, sen data ei koskaan vuoda julkiselle puolelle, ja koko pino pysyy EU-alueella.
• Hallusinaatio­riski minimoitu lähde­viitteillä ja groundingilla — käyttäjä näkee mistä vastaus tulee, organisaatio voi päivittää vastausta päivittämällä dokumenttia eikä muuttamalla promptteja.
• Skaalautuva pohja. Saman arkkitehtuurin päälle voi rakentaa kolmannen, neljännen, viidennen chatbotin — kukin omalla data­lähteellään ja oikeus­rajauksellaan. Teknologia­valinta oli tuotteistuksen, ei yksittäisen projektin.

Tämä oli oma esi­työni myöhemmille projekteille — erityisesti omalle raportointi­alustalle jossa sama RAG-logiikka on osana suurempaa kokonaisuutta. RAG ei ole lopputuote vaan menetelmä, joka sopii moneen tilanteeseen.