Moottori, jossa oli kuusi napaa — Kymmenen koodirivin myytti

Kuusiosainen tutkinta syistä, joiden vuoksi sinulle myyty dokumenttipohjainen chatbot jatkaa keksintöjen tekemistä — ja erilaisesta suunnasta, jota joku alkoi kulkea vuoden 2026 alussa.

Kuusiosainen tutkinta syistä, joiden vuoksi sinulle myyty dokumenttipohjainen chatbot jatkaa keksintöjen tekemistä — ja erilaisesta suunnasta, jota joku alkoi kulkea vuoden 2026 alussa.

Intro — Moottori, jossa oli kahdeksan napaa (mutta niitä oli kuusi)

Milano, maaliskuu 2026. Manageri avaa yrityksen sisäisen chatbotin, sellaisen joita IT-osasto on pystyttänyt "kahdessa viikossa" suurella innolla ja vähäisellä epäluulolla. Hyvin yksinkertainen kysymys: "Kuinka monta napaa CMP40M-moottorissa on?". Chatbot vastaa kaikella sillä varmuudella, jota suuret kielimallit osaavat osoittaa: "CMP40M-moottorissa on kahdeksan napaa."

Väärin. Siinä on kuusi. Oikea vastaus ei ollut 422-sivuisessa luettelossa, jonka joku kuukausia aiemmin oli luottavaisesti syöttänyt vektoritietokantaan, vakuuttuneena siitä, että järjestelmä "tietäisi kaiken" siitä lähtien. Kyseinen tietoa ei ollut luettelossa lainkaan. Se oli SEW:n teknikkojen sähköpostin liitteenä olevassa PDF-tiedostossa, joka oli arkistoitu kansioon, jota kukaan ei ollut vaivautunut indeksoimaan.

Tämä kohtaus, jossa on vaihtelua toimialoittain ja murteittain, toistuu sadoissa italialaisissa toimistoissa. Lupaus oli yksinkertainen ja houkutteleva: anna kaikki yritysdokumentit tekoälyavustajallesi, ja se pystyy vastaamaan kaikkiin niihin liittyviin kysymyksiin. Todellisuus on paljon arkipäiväisempi: chatbot lukee, mutta ei ymmärrä, etsii, mutta ei löydä, ja kun se ei löydä – sen sijaan, että myöntäisi sen – se keksii. Se keksii sujuvasti, täydellisellä kieliopilla, uskottavilla luvuilla. Mikä on paljon pahempaa kuin vastaamattomuus.

Loppuvuoden 2024 ja vuoden 2026 alun vietimme kuukausia näiden epäonnistumisten ruumiinavauksessa. Emme pyrkineet lietsoamaan polemiikkia, vaan ymmärtämään yhden asian: miksi niin lineaarinen idea – "anna sille dokumentit ja kysy sitten asioita" – muuttuu niin vaikeaksi, kun se poistuu demon lavalta ja astuu oikeiden palvelimien huoneeseen.

Tämä kuusiosainen tutkinta kertoo, mitä löysimme: hiljaisia bugeja, jotka poistivat kokonaisia luetteloita, pilvipohjaisia uudelleenjärjestäjiä virheellisillä pisteytyksillä, hallusinaatioita, jotka eivät johtuneet mallista vaan vuosia aiemmin saastuneista tiedoista, lähteviä laskuja, jotka tekivät jokaisesta kyselystä kalliimman kuin sen arvon, ja "suosittuja" kehyksiä, jotka lupaavat kaiken kymmenellä koodirivillä, kunhan niiltä ei pyydetä liikaa. Ja viimeisessä luvussa eri suunta, jota joku alkoi kulkea hiljaa vuoden 2026 alussa – arkkitehtuuri, jossa hakustrategia lakkaa olemasta koodia ja muuttuu dokumentiksi, jota kuka tahansa yrityksessä voi lukea ja muokata.

Jokainen luku toimii itsenäisesti. Jos haluat aloittaa tarinasta 342 kadonneesta taulukosta tai valehtelevasta uudelleenjärjestäjästä, voit tehdä niin vapaasti. Mutta kokonaisuutena tarinalla on moraalinen opetus, joka nousee esiin vasta lopussa: yrityksen RAG – tuo tekninen lyhenne, joka tarkoittaa Retrieval-Augmented Generation, eli "generoi vastauksia hakemalla ensin dokumentteja" – ei ole vielä valmis tuote. Se on raja-alue. Ja kuten kaikki raja-alueet, sitä ovat toistaiseksi kertoneet pääasiassa myyjät. On aika kuunnella myös niitä, jotka ovat eläneet sen sisällä.

Luku 1 — Kymmenen koodirivin myytti

Dia on identtinen jokaisessa tekoälykonferenssissa vuodesta 2023 lähtien: "Yrityksesi dokumenttiavain avustaja 10 rivillä koodia." Otsikon alla on lohkokoodia pastellisävyissä, joka esittelee avoimen lähdekoodin kirjaston – tyypillisesti jonkin tunnetun amerikkalaisen, jonka nimi herättää mielikuvan puuketjuista tai tiibetiläisistä laamoista – joka lataa PDF-tiedostoja, pilkkoo ne, liittää ne vektoritietokantaan ja kysyy niitä kielimallilla. Viidessä minuutissa sinulla on chatbot. Viidessä minuutissa aplodit. Viidessä minuutissa italialainen keskisuuri yritys vakuuttuu siitä, että ongelma on ratkaistu ja että sen IT-osasto pystyy siihen kahdessa viikossa.

Ongelma – se, jota dia ei kerro – on, että demo on rakennettu kolmella hyvin muotoillulla PDF-tiedostolla, kysymyksellä, joka on räätälöity sopimaan sisältöön, lavastuksella ilman todellista viivettä ja esittelijällä, joka on harjoitellut kaiken 27 kertaa ennen lavalle nousemistaan. Todellisuudessa yritysdokumentit ovat geologinen katastrofi: skannauksien skannauksia, taulukoita, jotka menevät päällekkäin tekstin kanssa, alaviitteitä, jotka tunkeutuvat kappaleisiin, alfanumeerisia koodeja, kuten "RH1M", jotka pilkkoja katkaisee puolivälistä luullen niitä sanoiksi, kuvia, jotka sisältävät 70 % hyödyllisestä tiedosta, mutta joita kukaan ei todellisuudessa poimi, ja asetteluja, jotka vaativat arkeologia enemmän kuin jäsentäjän.

RAG – tämä on ajatuksen ydin – on loistava idea. Ota käyttäjän kysymys, etsi arkistostasi asiaankuuluvimmat dokumentit, syötä ne kielimallille ja pyydä vastaus, joka perustuu näihin dokumentteihin. Teoriassa se ratkaisee elegantisti hallusinaatio-ongelman: mallin ei enää tarvitse "tietää" vastausta, sen tarvitsee vain "lukea" se sinulle toimittamista pätkistä. Käytännössä jokaisella ketjun lenkillä – pilkkomisella, upotuksella, hakemisella, uudelleenjärjestämisellä, lopullisella generoinnilla – on omat tapansa rikkoutua, eikä rikkoutuminen harvoin ilmene näkyvänä virheenä. Se ilmenee hieman vääränä vastauksena. Sitten täysin vääränä vastauksena. Sitten johtajana, joka miettii, miksi hän maksaa järjestelmästä, joka tietää vähemmän kuin harjoittelija.

Avoimen lähdekoodin kehykset, jotka ovat popularisoineet RAG:n, on tehty osoittamaan, eivät tuottamaan. Ne ovat tyylikkäitä abstraktioiden ketjuja, joissa jokainen kerros piilottaa sanomattoman oletuksen: että PDF-tiedostoissasi on kunnollinen OCR-tunnistus, että kuvasi on jo kuvattu, että taulukot noudattavat sopimusta, että upotusmalli todella puhuu kieltäsi (spoileri: monet puhuvat hyvin vain englantia), että arkistosi on jo puhdistettu päällekkäisyyksistä. Kun jokin näistä oletuksista pettää – ja ainakin yksi pettää aina, usein kolme – järjestelmä ei lakkaa toimimasta. Pahimmillaan: se lakkaa toimimasta hyvin, mutta jatkaa vastausten antamista. Sulavia, varmoja, ja usein totuudesta irrotettuja vastauksia.

On lause, joka kiertää niiden keskuudessa, jotka rakentavat näitä järjestelmiä ammatikseen, ja jota et koskaan löydä tutoriaaleista: "RAG on helppo tehdä, mutta vaikea tehdä hyvin." Ensimmäisen demon ja tuotantopalvelun välillä on kuilu, jota ei voi täyttää lisäämällä GPU:ita tai vaihtamalla mallia. Se täytetään ymmärtämällä epämiellyttävä asia: kun rakennat yrityksen RAG:ia, et kirjoita koodia. Suunnittelet pienen, itsepintaisen hakukoneen, joka on räätälöity dokumenteillesi, ja kaikki siihen liittyvät toimitukselliset valinnat — mikä on kohinaa, mikä signaalia, mikä on indeksoitava kahdesti, mikä heitettävä pois. Vain tutoriaaleissa kymmenellä rivillä nämä valinnat tehdään sinun puolestasi kerran, jonkun toimesta, joka ei ole koskaan nähnyt dokumenttejasi. Ja ne ovat lähes aina väärät valinnat sinun tapauksessasi.