Kuinka rakentaa luotettava RAG: Syväanalyysi 7 epäonnistumispisteestä ja arviointikehyksistä

Hakutiedon korostettu generointi (RAG) on kriittinen modernille tekoälyarkkitehtuureille, toimien olennaisena kehyksenä kontekstiaavasteisten agenttien luomiseksi.

Mutta siirtymällä perusprototyypistä tuotantovalmiiseen järjestelmään on selvitettävä merkittäviä esteitä tiedon hakemisessa, kontekstin konsolidaatiossa ja vastausyhteenvedossa.

Tämä artikkeli tarjoaa syvän analyysin seitsemästä tyypillisestä RAG-epäonnistumispisteestä ja arviointimittareista käytännön koodiesimerkeillä.

RAG-romahduksen anatomia – 7 epäonnistumispistettä (FP)

Tutkijoiden Barnett et al mukaan, Hakutiedon korostettu generointijärjestelmät (RAG) kohtaavat seitsemän tiettyä epäonnistumispistettä (FP) putkessa.

Seuraava kaavio havainnollistaa nämä vaiheet:

Kuva A. Indeksointi- ja kyselyprosessit RAG-järjestelmän luomiseksi. Indeksointiprosessi tehdään kehitysaikana ja kyselyt suoritusaikana. Tässä tutkimuksessa tunnistetut epäonnistumispisteet on merkitty punaisilla ruuduilla (lähde)

Tutustumme jokaiseen FP:hen putken järjestyksessä, seuraten ylävasemman-ala-oikean etenemistä Kuvassa A.

FP1. Puuttuva sisältö

Puuttuva sisältö tapahtuu, kun järjestelmältä kysytään kysymystä, jota ei voida vastata, koska asiaankuuluvaa tietoa ei ole saatavilla vektortallennuksessa ensinnäkin.

Epäonnistuminen tapahtuu, kun LLM antaa uskottavan kuulostavan, mutta väärän vastauksen sen sijaan, että se ilmoittaisi ettei tiedä.

FP2. Ohitettu ylin sijoitettu asiakirja

Tämä on tilanne, jossa oikea asiakirja on vektortallennuksessa, mutta hakija epäonnistuu sijoittamassa sitä tarpeeksi korkealle joukossa, jotta se sisällytetään LLM:lle annettaviin ylin sijoitetuksi asiakirjoihin.

Seurauksena on, että oikea tieto ei koskaan pääse LLM:lle.

FP3. Ei kontekstissa (konsolidaatiestrategian rajoitukset)

Tämä on tilanne, jossa oikea asiakirja on olemassa ja haetaan vektortallennuksesta, mutta se poistetaan konsolidaatioprosessin aikana.

Tämä tapahtuu, kun liian monta asiakirjaa palautetaan ja järjestelmän on suodatettava ne sopimaan LLM:n kontekstirajoituksiin, tokenrajoituksiin tai nopeusrajoituksiin.

FP4. Ei purettu

Tämä on tilanne, jossa LLM epäonnistuu tunnistamasta oikeaa tietoa kontekstissa, vaikka oikea tieto oli vektortallennuksessa ja haettiin ja konsolidaati onnistui.

Tämä tapahtuu, kun konteksti on liian meluisa tai sisältää ristiriitaista tietoa, joka hämmennystää LLM:ää.

FP5. Väärä muoto

Tämä on tilanne, jossa tallennus, hakeminen, konsolidaatio ja LLM:n tulkinta käsitellään onnistuneesti, mutta LLM epäonnistuu noudattamasta tiettyjä muotoiluohjeita, jotka on annettu kyselyssä, kuten taulukko, luettelo tai JSON-skeema.

FP6. Virheellinen tarkkuus

LLM:n tuloste on teknisesti olemassa, mutta joko liian yleinen tai liian monimutkainen verrattuna käyttäjän tarpeisiin.

Esimerkiksi LLM generoi yksinkertaisia vastauksia käyttäjän kysymykseen, jolla on monimutkainen ammatillinen tavoite.

FP7. Epätäydellinen vastaus

Tämä on tilanne, jossa LLM generoi tulosteen, joka ei välttämättä ole väärä, mutta joka puuttuu avainasioita, jotka olivat saatavilla kontekstissa.

Esimerkiksi, kun käyttäjä kysyy monimutkaista kysymystä, kuten “Mikä ovat avainkohdat asiakirjoissa A, B ja C?”, LLM käsittää vain yhden tai kaksi lähdettä.

FP:t vaikuttavat RAG-putken suorituskykyyn

Kukin näistä FP:istä vaikuttaa RAG-putken suorituskykyyn:

Tiedon eheys- ja luotettavuusvirheet

Kun puuttuva tai virheellinen tieto on läsnä, järjestelmä ei ole enää luotettava tietolähde. Ensimmäiset FP:t ovat:

• FP1 (Puuttuva sisältö): Vastaus ei ole asiakirjassa ensinnäkin.
• FP4 (Ei purettu): LLM päättää jättää oikea vastaus huomiotta asiakirjassa.
• FP7 (Epätäydellinen): LLM antaa puolivärisiä vastauksia, puuttuen tärkeitä osia.

Hakemisen ja tehokkuuden pullonkaulat

RAG-putki voi olla tehokas, kun se ohittaa tärkeät tiedot hakemis- ja konsolidaatioprosesseissa. Ensimmäiset FP:t ovat:

• FP2 (Ohitettu ylin sijoitettu): Upottamismalli epäonnistuu valitsemasta ylin sijoitetuista upotuksista.
• FP3 (Konsolidaatiestrategia): Käsikirjoitus, joka leikkaa asiakirjat LLM:n rajoituksiin, pudottaa tärkeimmät osat.

Käyttökokemus- ja muotoiluvirheet

Vaikka oikein, tuloste, jolla on huono lukukelpoisuus tai väärä muoto, voi vaikuttaa käyttökokemukseen. Ensimmäiset FP:t ovat:

• FP5 (Väärä muoto): LLM epäonnistuu seuraamasta tiettyä muotoiluohjeistusta, kuten JSON:ia.
• FP6 (Virheellinen tarkkuus): LLM generoi pitkän tulosteen yksinkertaiseen kyllä/ei-kysymykseen, tai päinvastoin (liian lyhyt vastaus monimutkaiseen kysymykseen).

Arviointipino: Kehykset FP:iden vähentämiseksi

Arviointimittarit on suunniteltu systemaattisesti vähentämään näitä FP:itä.

Tässä osiossa tutkimme tärkeitä arviointimittareita käytännön käyttötapauksilla.

Tärkeimmät RAG-arviointimittarit:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Yksikkötesti ennen käyttöönottoa

DeepEval laskee painotetun pisteytyksen kriteerien perusteella.

LLM-tuomari (esim. GPT-4o) arvioi kunkin kriteerin LLM:n tulostetta vasten:

DeepEval hyödyntää G-eval:ia, ketjuajattelumallia, joka arvioi tulosteen monivaiheisella lähestymistavalla:

1. Määritä kriteeri mitattavaksi (esim. “johdonmukaisuus”, “virtavirtaisuus” tai “merkitys”).
2. Generoi arviointivaiheet (käyttäen arviointi-LLM:ää).
3. Seuraa arviointivaihetta ja analyysi syötettä ja LLM:n tulostetta.
4. Laske odotettu painotettu summa kunkin kriteerin pisteytystä.

Yleinen tilanne käytännössä

• Tilanne: Teknisen asiakirjan avustaja (botti) monimutkaiselle ohjelmistotuotteelle näyttää toimivan joka kerta, kun insinööritiimi päivittää koodipohjaa.
• Ongelma: Ei kvantitatiivista näyttöä siitä, voitko bot vastata käyttäjän kysymyksiin (Vain “ajattelet”, että se toimii…).
• Ratkaisu: Integroi PyTest-funktio CI/CD-regressioputkeen, jossa DeepEval suorittaa G-Eval ja muita mittareita testitapauksessa:

• Odotettu tulos: Jos mittarin pisteytys laskee alle kynnyksen (0,85), PyTest nostaa AssertionError:n – epäonnistuen CI-rakennuksessa ja estäen hiljaisen taantuman pääsyn tuotantoon.

Kehtiömuistiinpano – DeepEvalin testitapaus
Joukko LLMTestCase-olioita määrittää testitapauksen, jonka DeepEval suorittaa.

Käytännössä tämä testitapaus tulisi sisältää tärkeimmät käyttäjän kysymykset ja merkityt tulokset haetun kontekstin kanssa.

Nämä voidaan hakea JSON- tai CSV-tiedostosta.

RAGAS – Neulansilmän optimoija

RAGAS pyrkii arvioimaan RAG:ia ilman inhimillistä annotoituja tietoja luomalla synteettisiä testijoukkoja.

Sitten se laskee lippulaivamittaukset:

Kuva B. RAGAS-arviointitriadi, joka yhdistää Kysymyksen, Kontekstin ja Vastauksen täsmällisyys-, haun, uskollisuus- ja merkitysmalla mittauksilla (Kuriko IWAI)

Lippulaivamittaukset on jaettu kolmeen ryhmään:

• Hakuputki (musta, kiinteä viiva, Kuva B): Kontekstin täsmällisyys, kontekstin haun.
• Generointiputki (musta, pistekohtainen viiva, Kuva B): Uskollisuus, vastauksen merkitys.
• Todellinen (punainen ruutu, Kuva B): Vastauksen semanttinen samankaltaisuus, vastauksen oikeellisuus.

Yleinen tilanne käytännössä

• Tilanne: RAG-järjestelmä oikeudellisille sopimuksille puuttuu tärkeitä pykäliä. Et ole varma, onko ongelma Haussa (Hakija) vai Lukemisessa (Generaattori).
• Ongelma: Ei tietoa optimaalisesta ylin sijoitetun määrästä (top-k).
• Ratkaisu: Käytä RAGAS:ia luomaan synteettinen testijoukko, joka sisältää 100 kysymys- ja todisteparia. Sitten suorita RAG-putki testijoukkoa vastaan laskeaksesi kontekstin haun ja kontekstin täsmällisyyden:
• Odotettu tulos: Mittaustulosten perusteella toimenpide suunnitelma voi olla seuraava:

Taulukko 1. RAGAS-diagnoosi-toimenpidesuunnitelma – Mittausten kartoittaminen järjestelmän säätöihin.

TruLens – Palautekehän asiantuntija

TruLens keskittyy RAG-prosessin sisäisiin mekaniikkaan lopputuloksen sijaan käyttäen palautefunktioita.

Se käyttää myös LLM-pohjaista pisteytystä, joka heijastaa, kuinka hyvin vastaus tyydyttää kyselyn tarkoituksen, käyttäen 4-pisteen Likert-asteikkoa (0-3), mikä tekee siitä erinomaisen vastauksen laadun arvioinnissa.

Yleinen tilanne käytännössä

• Tilanne: Lääkintäneuvonantaja-botti vastaa käyttäjän kysymykseen oikein, mutta lisää vihjeen, jota ei ole tarkistettu PDF-pohjassa.
• Ongelma: Lisävihje saattaa olla hyödyllinen, mutta ei perustu tosiasioihin.
• Ratkaisu: Käytä TruLensia toteuttaaksesi perustuvuuspalautefunktion kynnyksellä, kuten pistemäärä > 0,8.

• Odotettu tulos: Kun LLM generoi vastauksen, joka sisältää tietoa, jota ei ole haetussa, TruLens merkitsee tiedon ruutuun.

Arize Phoenix – Hiljainen epäonnistumiskartta

Arize Phoenix on avoimen lähdekoodin havainnollistamis- ja arviointityökalu LLM-tulosteen arvioimiseksi, mukaan lukien monimutkaiset RAG-järjestelmät.

Rakennettu OpenTelemetry:lle Arize AI:lla, se keskittyy havainnollistamiseen käsittelemällä LLM-arviointia MLOps:n alajärjestelmänä.

RAG-arviointikontekstissa Phoenix erottuu upotusanalyysillä, käyttäen Yhdenmukaisen manifold-approksimaatiota ja projektiota (UMAP) vähentämään korkeaulotteisia vektoriupotuksia 2D/3D-avaruuteen.

Tämä upotusanalyysi paljastaa matemaattisesti, ovatko epäonnistuneet kyselyt semanttisesti ryhmiteltyjä yhdessä, mikä osoittaa aukon vektortietokannassa.

Yleinen tilanne käytännössä

• Tilanne: Asiakastukibotti toimii hyvin hyvityksistä, mutta antaa järjettömiä vastauksia takuukysymyksiin.
• Ongelma: Tietohuone vektortietokannassa (Ei voida löytää lokista).
• Ratkaisu: Käytä Arize Phoenixia luomaan UMAP- upotusvisualisointi (UEV), 3D-kartta vektortietokantaan – yhdistääkseen käyttäjän kyselyt asiakirjapalasiin.
• Odotettu tulos: Nähdä visuaalisesti ryhmä käyttäjän kyselyjä, jotka laskeutuvat pimeään alueeseen, jossa ei ole asiakirjoja, osoittaen, että jotkut asiakirjat on unohtunut ladata vektortietokantaan.

Braintrust – Ohjekirjan regressioturva

Braintrust on suunniteltu korkeataajuisille iterointikierroksille käyttäen mallien välistä vertailua.

Yleinen tilanne käytännössä

• Tilanne: Insinööritiimi päivittää ohjeistuksen “Vastaa kysymykseen” (Tapaus A) monimutkaisempaan 500-sanaisen järjestelmäohjeeseen (Tapaus B).
• Ongelma: Parantaminen ohjeistusta Tapaukseen B saattaa vahingossa rikkoa Tapaus A:n.
• Ratkaisu: Käytä Braintrustia luomaan kultainen tietojoukko, joka sisältää joukon N täydellisiä esimerkkejä (esim. N = 50). Anna Braintrustin suorittaa rinnakkain (SxS) vertailun joka kerta, kun tiimi päivittää yksittäisen sanan ohjeistuksessa:

• Odotettu tulos: Eroraportti, joka näyttää tarkalleen, mitkä tapaukset paranevat tai heikkenevät kunkin kultaisen tietojoukon (N = 50) kohdalla.

Yhteenveto

Kun käsitellään oikein arviointikehyksillä, RAG voi olla kilpailukykyinen työkalu tarjoamaan LLM:lle konteksti, joka on kaikkein relevantimmillaan käyttäjän kysymykselle.

Toteutusstrategia: Mittausten kartoittaminen epäonnistumispisteisiin

Vaikka ei ole yhtä kaikkia sopivaa ratkaisua, Taulukko 2 näyttää, mitä arviointimittauksia sovelletaan kullekin FP:lle, jotka käsiteltiin tässä artikkelissa:

Taulukko 2. Epäonnistumispisteen lieventämisatriksi – Kuka työkalu ratkaisee kunkin FP:n?

DeepEval ja RAGAS voivat hyödyntää uskollisuusmittauksiaan arvioidakseen tiedon eheysvirheitä (FP1, FP4, FP7).

TruLens hyödyntää kontekstin täsmällisyyttä ja -haun mittauksiaan arvioidakseen kontekstin merkitystä tulosteelle – tehokkaasti arvioiden FP2:n.

Arize Phoenix tarjoaa visualisaation hakuprosessista, josta on helppo nähdä, jos haettu asiakirja hävisi konsolidaatioprosessissa (FP3).

Käyttökokemusvirheiden kohdalla DeepEval luo mukautettuja mittauksia arvioidakseen käyttökokemusvirheitä, kun taas Braintrust erottuu todellisen tietojoukon vertailussa.