Rakensin AI-liidiputken, joka ei saa lähettää mitään itse
Rakensin AI-liidiputken, joka ei saa lähettää mitään itse
Nabil Samari
10. elokuuta 20265 min lukuaika
Jaa
Mulla oli jo paikallinen RAG, joka osasi etsiä tietoa Obsidianista, Drivesta ja Nextcloudista. Kirjoitin sen rakentamisesta aiemmassa jutussa. Se oli käyttökelpoinen, mutta aika passiivinen: haku tapahtui vasta kun itse pyysin assistenttia etsimään jotain.
Seuraava kysymys oli paljon kiinnostavampi. Voisiko sama haku auttaa oikean asiakasliidin käsittelyssä?
Ei niin, että AI saisi vastata asiakkaalle omin päin. Se olisi mun mielestä aivan liian iso riski. Halusin putken, joka tunnistaa liidin, hakee oikeat Nice Events -tiedot, kirjoittaa luonnoksen ja jättää viimeisen päätöksen mulle.
Nyt se toimii n8n:ssä.
Putki alkaa Gmailista, mutta ei pääty Lähetä-nappiin
Nice Eventsin Gmailissa liidiksi merkitty viesti käynnistää työnkulun. Sen jälkeen tapahtuu tämä:
viesti siistitään koneellisesti käsiteltävään muotoon
DeepSeek luokittelee, onko kyseessä oikea myyntiliidi
paikallinen RAG hakee vain Nice Eventsin hyväksytyistä lähteistä
DeepSeek kirjoittaa vastausluonnoksen haetun tiedon ja asiakkaan viestin perusteella
yhteyshenkilö ja myyntimahdollisuus tarkistetaan Twenty CRM:stä
Telegramiin tulee ilmoitus
Gmailiin syntyy luonnos
Nice Eventsin liidiputki n8n:n editorissa. Luokittelu, paikallinen haku, CRM-päivitys ja Gmail-luonnos näkyvät omina vaiheinaan.
Siihen työnkulku loppuu.
Asiakkaalle ei lähde mitään automaattisesti. Ei edes silloin, kun luokittelu näyttää varmalta ja luonnos kuulostaa hyvältä.
Tää raja oli koko projektin tärkein päätös. Hyvä luonnos säästää aikaa. Väärälle asiakkaalle lähetetty varma mutta väärä vastaus syö luottamusta paljon nopeammin kuin AI sitä pystyy rakentamaan.
Luokittelija ja kirjoittaja ovat eri tehtäviä
Ensimmäisessä versiossa olisi ollut houkuttelevaa pyytää yhtä mallia lukemaan viesti ja tekemään kaikki. Luokittele liidi, päätä mitä tietoa tarvitaan, kirjoita vastaus ja päivitä CRM.
En tehnyt niin.
Luokittelu on oma vaiheensa. Vastauksen kirjoittaminen alkaa vasta sen jälkeen, kun viesti on tunnistettu liidiksi ja paikallinen haku on palauttanut rajatun tietopaketin. Tällä tavalla jokaisen vaiheen voi nähdä n8n:ssä erikseen. Jos jokin menee pieleen, ei tarvitse arvailla, oliko vika luokittelussa, haussa, kirjoittamisessa vai CRM-päivityksessä.
Tää on myös syy, miksi käytän tässä n8n:ää enkä yhtä vapaasti toimivaa agenttia. Graafinen työnkulku ei tee järjestelmästä automaattisesti turvallista, mutta se tekee rajat näkyviksi.
Paikallinen RAG ei saa penkoa kaikkea
Mun paikallisessa haussa on tuhansia chunkeja eri projekteista. Siellä on tapahtumatietoa, asiakasmuistiinpanoja, artistitietoa ja paljon sellaista, mikä ei kuulu Nice Eventsin myyntivastaukseen.
Liidiputki ei saa hakea koko tietovarastosta vapaasti.
Rakensin sille oman rajatun hakupinnan. Se hyväksyy lähteiksi vain ennalta määriteltyjä Nice Events -dokumentteja, kuten vuoden 2026 palveluhinnaston, myyntipaketit, palvelumallin ja hyväksytyt artistitiedot. Biletti, muut asiakkaat, päiväkirjat ja vanhat tarjouskansiot jäävät ulos.
Haku käyttää hybridiä: vektorihaku löytää samaa tarkoittavia ilmauksia, sanahaku nimiä ja tarkkoja termejä, ja paikallinen malli järjestää parhaat ehdokkaat uudelleen. Lopuksi mukaan pääsee enintään kolme lähdettä ja 4 000 merkkiä kontekstia.
Jos paikallinen rerankkaus ei toimi tai hyväksyttyä evidenssiä ei löydy, rajapinta palauttaa virheen. Se ei täytä aukkoa arvauksella.
Täysin paikallinen tää ei ole, eikä sitä pidä väittää
Tässä on yksi ero, jonka haluan sanoa suoraan.
Varsinainen tietovarasto, embeddingit, haku ja rerankkaus pysyvät mun omassa verkossa. n8n käyttää niitä tokenilla suojatun sisäverkon HTTP-rajapinnan kautta. Palomuuri sallii yhteyden vain TrueNAS-koneelta, jolla n8n pyörii. Rajapinta on vain lukua varten.
Mutta vastausluonnoksen kirjoittaa DeepSeek. Sille lähetetään asiakkaan viesti ja paikallisen haun valitsema rajattu konteksti.
Raaka Obsidian-holvi ei siis lähde pilveen, mutta valitut Nice Events -otteet lähtevät luonnoksen kirjoittamista varten. Tää ei ole täysin paikallinen AI-ratkaisu. Se on paikallinen ja rajattu tiedonhaku yhdistettynä pilvimalliin.
Mun mielestä tää ero pitää kertoa. "Paikallinen RAG" kuulostaa helposti siltä, ettei mitään dataa poistu omasta verkosta. Tässä toteutuksessa se ei olisi totta.
Malli ei saa luvata hintaa tai saatavuutta tyhjästä
Vastausohjeessa on muutama tiukka sääntö.
Luonnoksen pitää olla lämmin ja kirjoitettu asiakkaan kielellä. Sen ei pidä mainita RAGia tai sisäisiä lähteitä. Hintaa, saatavuutta tai kalustoa ei saa vahvistaa, jos sitä ei löydy palautetusta kontekstista. Jos asiakkaan viestistä puuttuu päivämäärä, paikka, henkilömäärä tai muu tarjouksen kannalta tärkeä tieto, luonnoksen pitää kysyä sitä.
Tää ei poista hallusinaatioita maagisesti. Se pienentää tilaa, jossa malli voi keksiä.
Vielä tärkeämpi suoja on se, että luonnos jää luonnokseksi. Mä näen lähteet ja viestin Telegram-ilmoituksessa, tarkistan Gmailin luonnoksen ja muokkaan sitä tarvittaessa ennen lähettämistä.
Vihreä health check ei tarkoittanut toimivaa hakua
Juuri ennen tän jutun julkaisua ajoin vielä yhden oikean kaltaisen kyselyn rajapinnan läpi: asiakas kysyy DJ-palvelua ja äänentoistoa 150 hengen yritysjuhlaan.
Rajapinta vastasi 503. Kaikki taustapalvelut olivat silti vihreänä. ChromaDB toimi, embedding-palvelu toimi ja rerankkeri toimi.
Vika oli ehdokashaussa. Yleinen asiakasviesti ei sisältänyt tarpeeksi Nice Events -kohtaisia termejä, joten hyväksytyt myyntidokumentit eivät nousseet 60 ensimmäisen ehdokkaan joukkoon. Rajaus teki juuri sen mitä pitikin ja hylkäsi muut lähteet. Lopputulos oli turvallinen missi, mutta ei hyödyllinen vastaus.
Kirjoitin ensin regressiotestin. Sen jälkeen lisäsin ehdokashakuun Nice Events -ankkurit, kuten palveluhinnaston ja myyntipaketit. Paikallinen rerankkeri arvioi tulokset edelleen asiakkaan alkuperäistä kysymystä vasten, ei lisättyjä hakusanoja vasten.
Kaikki 161 testiä menivät läpi. Sama live-kysely palautti sen jälkeen kolme hyväksyttyä lähdettä: palveluhinnaston, Nice Events -palvelumallin ja myyntipaketit. Kontekstia tuli 3 086 merkkiä.
Tää oli hyvä muistutus. Palvelun terveystarkistus kertoo, että osat vastaavat. Se ei kerro, että oikea työtilanne tuottaa oikean evidenssin.
CRM saa muistin, mutta ei päätösvaltaa
Putki tarkistaa Twenty CRM:stä, onko henkilö tai yritys jo olemassa. Tarvittaessa se luo tai päivittää myyntimahdollisuuden ja merkitsee, että vastausluonnos odottaa käsittelyä.
CRM on tässä työn jatkuvuutta varten. Sen tehtävä on estää liidiä katoamasta Gmailiin ja näyttää, mitä sille on tehty. Se ei päätä asiakkaan puolesta hintaa eikä muuta luonnosta hyväksytyksi vastaukseksi.
Telegram taas toimii huomiojonona. Mun ei tarvitse päivystää n8n:ää nähdäkseni, että uusi liidi on käsitelty. Ilmoituksesta näen, että luonnos on valmis tarkistettavaksi.
Mitä jätin tarkoituksella automatisoimatta
Putki ei lähetä sähköpostia. Se ei vahvista artistia vapaaksi. Se ei hyväksy tarjousta, lupaa lopullista hintaa tai päätä alennuksesta. Se ei myöskään käytä koko CRM-historiaa tai sähköpostilaatikkoa RAG-lähteenä.
Nää eivät ole puuttuvia ominaisuuksia. Ne ovat rajoja.
Automaation arvo tulee siitä, että kone hoitaa toistuvan pohjatyön: tunnistaa viestin, kerää oikean kontekstin, tekee ensimmäisen luonnoksen ja pitää CRM:n ajan tasalla. Ihmiselle jää kohta, jossa tarvitaan vastuuta, tilannetajua ja lupausten ymmärtämistä.
AI-liidiputken paras ominaisuus ei lopulta ole se, kuinka paljon se tekee.
Paras ominaisuus on se, että se tietää, mihin sen pitää pysähtyä.
