← Takaisin artikkeleihin
Quando l'AI aziendale non sa quello che sa Luku 3 osa 6
AI 2026-04-16 ProtoMedia

Valehteleva uudelleenjärjestäjä

Käännetty automaattisesti italiasta · lue alkuperäinen

Luku 3 — Valehteleva uudelleenjärjestäjä

RAG-tekniikan ammattikielessä on keskeinen, mutta vähän huomiota saava hahmo: uudelleenjärjestäjä. Kuvittele yrityksen haku kuin yökerhon sisäänkäynti. Vektoritietokanta on vartija: se katsoo nopeasti väkijoukkoa ja päästää sisään kolmekymmentä ehdokasta, jotka silmämääräisesti näyttävät etsimältäsi. Uudelleenjärjestäjä on sisäinen ovenvartija: se ottaa nuo kolmekymmentä, katsoo niitä huolellisesti, valitsee viisi — ne, jotka LLM todella lukee vastauksen rakentamiseksi — ja lähettää muut kaksikymmentäviisi takaisin. Se on pieni, mutta valtava toiminto: jos hän tekee virheen, kaikki tekevät virheen. Jos ovenvartija ei osaa lukea ihmisiä, paikka täyttyy vääristä ihmisistä, eikä kukaan ymmärrä koskaan, miksi ilta meni pieleen.

Vuonna 2025 markkinoille ilmestyi useita pilvipalveluita, jotka tarjosivat uudelleenjärjestäjiä API:na. Lähetät kysymyksen ja luettelon dokumenteista, ja ne palauttavat pisteitä. Kätevää, skaalautuvaa, ei GPU:ita ostettavaksi, ei malleja ladattavaksi. Yksi tunnettu eurooppalainen mallitoimittaja — nimeämättä, mutta tiedät mitkä nimet vältämme — esitteli lupaavan Qwen-perheen neljän miljardin parametrin mallin, joka oli merkitty "Uudelleenjärjestäjä". Hinta oli kohtuullinen, latenssi hyväksyttävä. Kuka tahansa olisi valinnut sen tuona hetkenä. Monet valitsivat sen.

Paitsi että pisteytykset olivat virheellisiä. Ei "hieman" virheellisiä, kuten missä tahansa mallissa voi tapahtua: virheellisiä rakenteellisesti. Ilmeisen relevantit dokumentit saivat 0.2, aiheesta poikkeavat dokumentit 0.8. Kuten aina näissä tapauksissa, ensimmäiset epäilykset kohdistuivat tuttuihin tekijöihin: embedding-malli, chunking, kyselyn muotoilu, dokumenttien esikäsittely. Viikkoja tutkimuksia väärien johtolankojen perässä. Vasta vertaamalla järjestelmällisesti pilvirerankerin vastauksia paikallisen vertailurankerin vastauksiin – sama syöte, samat dokumentit, pisteytykset vierekkäin Excel-taulukossa – paljastui epämiellyttävä totuus: API:n kautta paljastettu malli oli rikki. Ehkä virhe käyttöönotossa, ehkä väärä versio ladattu vahingossa, ehkä virhe pisteytysten serialisoinnissa. Palveluntarjoaja ei koskaan myöntänyt sitä virallisesti. Ongelma kuitenkin katosi yksinkertaisesti jonain päivänä hiljaisen päivityksen jälkeen, eikä muutostietoja ollut.

Tämän tarinan ydin ei ole "pilvipalvelut tekevät virheitä" — kaikki tekevät virheitä, myös paikalliset mallit. Piste on hienovaraisempi: vakavassa RAG-järjestelmässä reranker on osa, johon sinun täytyy pystyä kurkistamaan sisään. Jos se on maksullinen musta laatikko, ja sen tulokset ovat lukuja, jotka vaikuttavat uskottavilta vaikka ne olisivat sattumanvaraisia — ja rerankerin pisteytykset vaikuttavat aina uskottavilta, koska ne ovat lukuja nollasta yhteen muutamalla desimaalilla — sinulla ei ole keinoa selvittää, mikä järjestelmässäsi on vialla. Koska reranker on "putken lopussa", sen virhe saastuttaa kaikki ylävirran arvioinnit: haku vaikuttaa hitaalta, kysely virheelliseltä, upotukset huonoilta. Todellisuudessa kyse on ovimiehestä, joka ei osaa lukea kasvoja, ja sinä kyseenalaistat oven lasit.

Joidenkin tiimien vastavirtaan tehty valinta viime kuukausina — sen sijaan, että siirryttäisiin enemmän pilveen, on ollut palata takaisin ja tuoda reranker sisään. Avoin BGE-perheen malli, ei jättimäinen, joka pyörii paikallisella GPU:lla (myös Apple Siliconilla, joitain varoituksia ajureista). Enemmän hallinnointityötä, totta. Mutta mahdollisuus tehdä hallittuja kokeita, ymmärtää milloin se menee pieleen, vertailla versioita, pitää kirjaa historiasta. Ja — viimeisenä mutta ei vähäisimpänä — olla maksamatta API:lle murto-osa senttiä jokaisesta yksittäisestä käyttäjän hakukerrasta. Murto-osa, joka kerrottuna kymmenillä tuhansilla kyselyillä kuukaudessa lakkaa olemasta murto-osa ja muuttuu budjettikohdaksi.

Kun komponentti on niin kriittinen, että sen toimintahäiriö pilaa kaikki muut mittauskykysi, sen delegoiminen mustaan laatikkoon ei ole tehokkuutta. Se on uskon teko. Ja uskon teot tuotannossa maksavat korkoa korolle.

Lyhyt oppitunti: Kun komponentti on niin kriittinen, että sen toimintahäiriö pilaa kaiken muun, sen delegoiminen mustaan laatikkoon ei ole tehokkuutta. Se on uskon teko.

Onko palautetta? Kirjoita meille

Viesti lähetetään vain meille. Jos kommenttisi on kiinnostava, voimme julkaista sen artikkelin loppuun, mutta vasta arvioinnin jälkeen.

Kirjoittaessasi selaimesi ratkaisee pienen laskutoimituksen – näin pidämme roskapostin loitolla ilman ulkopuolisia palveluita tai semaforien tunnistamista. Et joudu tekemään mitään, eikä tietoja lähetetä tältä sivustolta.