Assistant-arkkitehtuuri, joka puhuu yritystietoihin

Voitot:

• Kokonaisvaltaisen yrityksen RAG-avustajan komponenttien ja tietovirran suunnittelu
• Yhdistämällä usean lähteen tiedot (wiki, lippu, PDF, tietokanta) yhdeksi avustajaksi
• Tee arkkitehtonisia päätöksiä skaalautuvuuden, välimuistin ja latenssin suhteen

Edellisissä jaksoissa opimme osat yksitellen: upottaminen, vektoritietokanta, paloittelu, haku. Yhdistetään nyt nämä ja rakennetaan päästä päähän -arkkitehtuuri avustajasta, joka puhuu omien yritystietojen kanssa. Tavoitteena on saada työntekijä kysymään: "Mikä on meidän lomapolitiikkamme?" Järjestelmä, jossa ihmiset voivat esittää kysymyksiä, vastaukset perustuvat oikeisiin sisäisiin asiakirjoihin, lainauksiin ja yhdistävät useita tietolähteitä. Tämä yksikkö käsittelee koko arkkitehtuurin, tietovirran ja tuotantotason päätökset.

Päästä päähän -komponentit

Yrityksen RAG-avustaja koostuu kahdesta erillisestä rivistä. Indeksointirivi (offline) valmistelee tiedot; Kyselyrivi (online) vastaa kysymykseen.

Indeksointirivin komponentit:

1. Liittimet: Liittimet, jotka hakevat tietoja lähteistä – wikistä, lippujärjestelmästä, tiedostosäilöstä, tietokannasta, sähköpostista.
2. Normalisointi: Eri tiedostomuotojen (PDF, HTML, DOCX) muuntaminen puhtaaksi tekstiksi; ylä-/alatunnisteen puhdistus.
3. Jakaminen + metatiedot: lohkominen ja merkitseminen (lähde, päivämäärä, auktoriteetti).
4. Upotus + lataus: Vektorien ja metatietojen kirjoittaminen vektoritietokantaan.

Kyselyputken komponentit:

1. Kyselyn esikäsittely: Uudelleenkirjoitus, hajauttaminen.
2. Haku: Hybridihaku + metatietosuodatin + uudelleensijoitus.
3. Kehotteen luominen: kontekstin + kysymyksen + ohjeiden sijoittaminen malliin.
4. Sukupolvi: Maadoitettu (kontekstuaalinen) vastaus mallista + lähteistä.
5. Jälkikäsittely: Sitaattien muotoilu, turvatarkastus, loki.

Vihje: Erota indeksointirivi fyysisesti kyselyrivistä. Indeksointi on hidasta ja säännöllistä (toimii erissä yön yli); Tiedustelulinjan tulee olla kevyt ja välitön. Kahden rivin sekoittaminen pakottaa raskaan käsittelyn käyttäjän odottaessa.

Tietovirran visualisointi

[INDEKSOINTI - offline]Resurssit → Normalisoi → Osa+Metadata → Upota → Vector DB (wiki, lippu, PDF, DB)[KYSYMYS - online]Käyttäjäkysymys → Esikäsittely → Haku (hybridi+suodatin+uudelleensijoitus) → Kehote (konteksti+kysymys+ohje) → Käyttäjä → Vastaus+lähde →

Usean lähteen datan yhdistäminen

Oikeissa yrityksissä vastaus ei pysähdy yhteen paikkaan. "Kuinka hyvittää asiakkaalle?" Vastaus kysymykseen löytyy sekä ohjeartikkelista (menettely), lippuhistoriasta (oikeat esimerkit) että käytäntö PDF:stä (säännöt). Assistentin tulee etsiä ne kaikki yhdestä poolista.

Kriittinen kohta: kun resursseja yhdistetään yhdeksi vektorisäilöön, jokaisen sirpaleen on sisällettävä "source_tour"-metatiedot. Voit siis etsiä niitä kaikkia ja suodattaa ne tarvittaessa, kuten "tuo vain viralliset käytännöt". Myös eri lähteillä on eri luotettavuustaso: virallinen käytäntö > ohjeartikkeli > työntekijän lippuhuomautus. Voit määrittää tämän prioriteetin uudelleensijoituksessa tai kehotteessa.

lähde

Sisällön tyyppi

luottaa

Päivitä taajuus

Käytäntö PDF

virallinen sääntö

korkea

kuukausittain

Ohjeartikkeli

Menettely

keskikorkea

viikoittain

Lippujen historia

todellinen näyte

keskikokoinen

Jatkuva

wiki

Sekalainen/nykyinen nuotti

Muuttuva

Jatkuva

Skaalautuvuus, välimuisti ja latenssi

Tuotannossa erottuu kolme asiaa. Latenssi: Käyttökokemus heikkenee, kun käyttäjä odottaa yli 2 sekuntia. Ratkaisu: näytä vastaus suoratoistomuodossa – se kaadetaan näytölle mallin kirjoittaessa. Välimuisti: Usein kysyttyjä kysymyksiä ja toistuvia yhteyksiä varten välimuisti sekä lisää nopeutta että alentaa kustannuksia. Skaalaus: Käyttäjän kasvaessa on tarpeen pystyä skaalaamaan haku ja mallintaa puhelut vaakasuunnassa.

Nyrkkisääntö kustannuspuolella: kallein askel on yleensä isompaan malliin menevien tokenien määrä. Siksi kontekstin vähentäminen neljään hyvään osaan luokittelulla uudelleen parantaa sekä laatua että kustannuksia. Yleinen malli on käyttää pienempää/nopeampaa mallia yksinkertaiseen luokitteluun tai reitittämiseen ja tehokkaampaa mallia lopulliseen vastaukseen (esim. claude-opus-4-8).

Varoitus: Älä määritä indeksointia "tee se kerran, unohda se". Asiakirjoja muutetaan, poistetaan, lisätään. Luo uudelleenindeksointistrategia: havaitse muuttuneet asiakirjat ja käsittele vain ne uudelleen. Vanhentunut indeksi tuottaa vastauksen, joka näyttää ajankohtaiselta, mutta on väärä.

Heikko arkkitehtuuri / vahva arkkitehtuuri

Heikko (yksi käsikirjoitus, kaikki sekaisin):

Kun käyttäjä kysyy: lue asiakirjat sillä hetkellä, silppua ne, upota, etsi, vastaa niihin.# Ongelma: kaikki indeksointi toistetaan jokaiselle kysymykselle; sekunnin viive, # ei lähteen erotusta, ei suodatinta, ei päivitystä.

Tehokas (jaetut putket + metatiedot + välimuisti + suoratoisto):

Indeksointi: erä ajetaan yöllä, päivitetään muutettuja asiakirjoja. Kysely: kevyt rivi — esikäsittely → hybridihaku+suodatin → uudelleensijoitus → kehote → malli (suoratoisto) → lainaus → loki. Usein kysytyt kysymykset ja lähde tallennetaan välimuistiin.

Kolme minikoteloa

Tapaus 1 – Sekava linja, suuri viive. Käynnistysyritys kirjoitti skriptin, joka käsittelee PDF-tiedostot uudelleen jokaisen kysymyksen yhteydessä; Jokainen vastaus kesti keskimäärin 11 sekuntia. Kun indeksointirivi erotettiin ja tiedot siirrettiin aiemmin vektorivarastoon, kyselyaika lyheni 1,3 sekuntiin ja suoratoistolla "ensimmäinen sana" ilmestyi 400 ms:ssa.

Tapaus 2 – Liikaa resursseja, väärä prioriteetti. Tukiassistentti antoi yhtäläisen painoarvon politiikan PDF-tiedostolle ja vanhoille lippulapuille; Joskus malli esitti virallisena sääntönä työntekijän virheellisen arvioinnin kahden vuoden takaa. Kun source_tour-metadata ja "harkitse virallista käytäntöä ristiriitatilanteessa" -ohje kehotteeseen lisättiin, väärän prioriteetin virheet vähenivät 89 %.

Tapaus 3 — Vanhentunut indeksi. HR-assistentti työskenteli indeksin parissa, jota ei ole päivitetty 3 kuukauteen; Lomapolitiikka on muuttunut, mutta assistentti sanoi vanhoja aikoja. Kun päivittäinen päivitys asennettiin, joka havaitsee muuttuneet tiedostot, nykyinen vastausnopeus nousi 70 prosentista 99 prosenttiin.

Yleisiä virheitä

• Indeksointi- ja kyselyrivien yhdistäminen: Raskas käsittely suoritetaan käyttäjän odottaessa; viive räjähtää.
• Lähdetyyppiä ei lisätä metatietoihin: Ei priorisointia ja suodatusta; Epäluotettava lähde näyttää olevan virallinen.
• Päivitysstrategian luomatta jättäminen: Hakemisto vanhenee; Tuotetaan vääriä vastauksia, jotka vaikuttavat ajankohtaisilta.
• Ohita suoratoisto: Käyttäjä katsoo tyhjää näyttöä; Havaittu viive kasvaa suureksi.
• Suurimman mallin käyttäminen jokaisessa vaiheessa: Kustannukset kasvavat tarpeettomasti; Jätä ohjaus pienemmälle mallille.

Yhteenvetona

• Yritysten RAG-avustaja koostuu kahdesta erillisestä rivistä: offline-indeksointi ja online-kysely; erottaa ne fyysisesti.
• Indeksointi = liitin + normalisointi + kappale/metatiedot + upotus/lataus; kysely = esikäsittely + haku + kehote + generointi + jälkikäsittely.
• Usean lähteen tiedot yhdistetään yhdeksi arkistoon, mutta lähdetyypin metatiedot ja luottamusprioriteetti säilyvät.
• Suoratoisto ja välimuisti viivettä varten, kontekstin säätö ja mallin valinta kustannuksia varten ovat kriittisiä.
• Ilman uudelleenindeksointia indeksi vanhenee; Käsittele vaihtuvia asiakirjoja säännöllisesti.

Sovellustehtävä

Piirrä omalle tiimillesi arkkitehtoninen kaavio avustajasta. (1) Tunnista vähintään kolme todellista tietolähdettä ja kirjoita muistiin kunkin liittimen tarve, päivitystiheys ja luottamustaso. (2) Piirrä indeksointi- ja kyselyrivit erikseen laatikko-nuolikaaviolla. (3) "Missä voin vähentää viivettä ja kustannuksia tässä avustajassa?" Kirjoita kysymykseen vähintään kaksi konkreettista päätöstä. (4) Kuvaile virkistysstrategiaasi yhdellä lauseella: mikä resurssi indeksoidaan uudelleen ja kuinka usein?

tarkistuslista

• [ ] Pystyn piirtämään indeksointi- ja kyselyrivit erikseen ja oikeilla komponenteilla.
• [ ] Pystyn yhdistämään usean lähteen tiedot lähdetyyppi- ja luottamusprioriteettiin.
• [ ] Voin tehdä suoratoisto-/välimuistipäätöksiä viiveen ja mallin valinnan perusteella.
• [ ] Tiedän, miksi uudelleenindeksointistrategia on välttämätöntä.
• [ ] Pidän mielessä, että kallein askel arkkitehtuurissani on yleensä isompaan malliin menevä token.