Gevinster:
- Forstå at innebygging gjør teksten til en vektor i det semantiske rommet og lignende betydninger er nære vektorer
- Forklarer hvordan ANN-søk fungerer med cosinus- og punktlikhetsberegninger
- Velge vanlige vektordatabaser basert på kostnad, skala og behov for metadatafiltrering
I hjertet av RAG er et enkelt spørsmål: "Hvilket tekststykke ligner mest på brukerens spørsmål?" Datamaskinen behandler tekst med tall, ikke bokstavelig. Det er derfor vi først må konvertere teksten til tall som har dens betydning. Det er det som er innebygging: prosessen med å konvertere en tekst til en tallsekvens (vektor) som representerer betydningen av den teksten. Når du er ferdig med denne enheten, vil du vite hvordan innbygging fungerer, hvordan likhet måles og hvordan du velger riktig vektordatabase.
Innebygging: Oversette mening til koordinater
En innebyggingsmodell (en spesialtrent kunstig intelligens) konverterer teksten du oppgir til en vektor med for eksempel 1024 tall. Tenk på denne vektoren som en koordinat i et flerdimensjonalt rom. Magien er denne: tekster som er like i betydning faller inn i nære koordinater i dette rommet.
Et enkelt eksempel: «årlig permisjon», «ferierett» og «årlig betalt permisjon» bruker forskjellige ord, men betyr det samme - vektorene deres er nær hverandre. "Lønnskonto" er en annen sak - vektoren er fjern. Så brukeren spør "hvor mange dager ferie har jeg?" Når du spør, kan vi til og med finne et dokument som ikke inneholder ordet «ferie», men som sier «årlig permisjon er 14 dager». Dette er hva klassisk søkeordsøk (søk som samsvarer nøyaktig med ordet) ikke kan gjøre.
Tips: Tenk på innebygging som et "fingeravtrykk av mening." Fingeravtrykkene til to setninger med samme betydning ser like ut; Selv om ordene er forskjellige.
En viktig regel: modellen du bruker når du legger inn spørsmålet skal være den samme modellen du bruker når du legger inn dokumenter. Ulike modeller produserer forskjellige rom; koordinater blir uforlignelige.
Hvordan måle likhet?
Det finnes flere metoder for å måle hvor like to vektorer er. Den vanligste er cosinuslikhet: den måler vinkelen mellom to vektorer. Hvis vinkelen er liten (vektorer som peker i samme retning), er likheten stor. Verdien er mellom −1 og 1; Nær 1 = veldig likt.
kriterium
Hva måler det?
Når er det foretrukket?
Cosinus
Vinkel (retning) mellom vektorer
Den vanligste; standard i tekst semantisk likhet
Prikk produkt
Retning + størrelse sammen
Hvis vektorene er normalisert, gir det samme resultat som cosinus; er rask
Euklidisk (euklidisk avstand)
Rett avstand mellom koordinatene
I noen clustering-scenarier; mindre brukt i tekst
I praksis produserer de fleste innbyggingsmodeller normaliserte vektorer (størrelse satt til 1); I dette tilfellet gir cosinus og prikkprodukt samme rekkefølge. Ikke bli beslutningslammet: start med kosinus.
Blant millioner av vektorer går det sakte å sammenligne dem én etter én om gangen. Det er derfor vektordatabaser bruker ANN (Approximate Nearest Neighbor) algoritmer. ANN finner "nesten nøyaktig nærmest" i stedet for "nøyaktig nærmest" veldig raskt. For eksempel kan metoden kalt HNSW returnere resultater på noen få millisekunder selv for 10 millioner vektorer. Du får stor hastighet for et lite offer av nøyaktighet.
Hva gjør Vector Database?
En vektordatabase gjør tre ting samtidig: (1) lagrer vektorer, (2) finner raskt vektorer som ligner mest på en spørringsvektor, (3) filtrerer etter metadata ved siden av hver vektor. Metadata er taggene du fester til den delen: kildefil, dato, avdeling, personvernnivå osv. Metadatafiltrering er kritisk i enterprise RAG; fordi du må kunne sette begrensninger som «søk kun i Økonomiavdelingens 2025-dokumenter».
# Registrer deg i vektordatabasen (konseptuelt)vektor_db.add( id="izin-politikasi-parca-3", vektor=embed("Årlig lønnet permisjon er 14 dager..."), text="Årlig lønnet permisjon er 14 dager...", metadata={"kilde": "ik_el_kitabi.pdf", "department"-":020", "department"-:020 "privacy", " "ic")
# Metadatafiltrert søk (konseptuelt)resultat = vektor_db.search( vektor=embed("hvor mange dager permisjon har jeg?"), top_k=4, filter={"avdeling": "HR", "privacy": ["internt", "på"]})
Velge riktig database
kjøretøy
Utvalgt aspekt
Passende situasjon
Innebygd / filbasert (innebygd bibliotek)
Ingen installasjon, enkelt maskin
Prototype, lite sett (< noen hundre tusen deler)
Administrert skytjeneste
Skalering og vedlikehold er ikke ditt ansvar
Produksjon, raskt voksende data, lite team
Åpen kildekode på din egen server
Full kontroll, dataene dine forblir dine
Personvernplikt, eksisterende infrastruktur
Tillegg til eksisterende database
Du administrerer ikke separate systemer
Legger til vektorstøtte til DB-en du allerede bruker
Spør når du velger: Hvor mange stykker blir det? Hvor kritisk er metadatafiltrering? Kan data gå utenfor selskapet (konfidensialitet)? Kan teamet drive en infrastruktur? Det er ofte lurt å starte i det små og utvide etter behov.
Svak tilnærming / sterk tilnærming
Svak (lagrer vanlig innebygging, ingen metadata):
Bare lagre teksten og vektoren. Søk: returner de 4 mest like vektorene.# Problem: kan ikke filtrere som "bare gjeldende HR-dokumenter";# gamle/uautoriserte deler kan også inkluderes i svaret.
Kraftig (rike metadata + filtrert søk):
Legg til kilde, dato, avdeling og personvernmerke til hver del. Filtrer i henhold til brukerens autoritet og aktualitet under søket: filter = {"privacy": user_authority, "date_date": "2024-01"}# Dermed er resultatet både trygt og oppdatert.
Tre minivesker
Tilfelle 1 — Feil modellblanding. Et team innebygde dokumenter med modell A og spørsmål med modell B. Søkene ga meningsløse resultater, og riktig svarprosent holdt seg på 31 %. Da jeg byttet til en enkelt modell (begge den samme innebyggingsmodellen), hoppet raten til 88 %. Leksjon: spørsmål og dokument skal være på samme plass.
Tilfelle 2 — Personvernrisiko uten metadata. I et helseforetak ble alle avdelingsdokumenter kastet i en enkelt pool uten metadata. Når en salgsmedarbeider stilte et spørsmål, kontekstualiserte systemet et stykke pasientdata. Når metadata + filter ble lagt til (i henhold til autorisasjonsnivået), ble denne risikoen eliminert; Ved henting medbringes ikke 12 uautoriserte brikker i det hele tatt.
Tilfelle 3 — Flaskehals i størrelse. Et e-handelsselskap søkte etter 8 millioner produktbeskrivelser med en enkel «skann alt»-metoden; Hvert søk tok 6 sekunder. Da vi byttet til HNSW-basert ANN, gikk tiden ned til 45 millisekunder, med bare 1 % tap i nøyaktighet. Leksjon: ANN er obligatorisk i det store settet.
Vanlige feil
- Bygge inn spørsmålet og dokumentet med ulike modeller: Resultatene er meningsløse; alltid én modell.
- Hopp over metadata: Du kan ikke filtrere; Du mister kontroll over personvern og oppdaterthet.
- Mistaking Innebygging for kryptering: Innebygging har reversibel informasjon; Det er feil å anta at sensitive data er "skjult".
- Å bygge unødvendig stor infrastruktur på et lite sett: En gigantisk klynge administrert for 5000 deler er unødvendig kompleksitet.
- Ikke bekymre deg for mye om likhetskriteriet: Start med cosinus i teksten; Finjustering kommer senere.
Forsiktig: Innebygging legger inn betydningen av teksten i tall, men "ødelegger" ikke innholdet. Hvis en vektordatabase lekkes, blir også de originale lagrede tekstene (i de fleste installasjoner lagret) kompromittert. Hold vektorlageret like konfidensielt som dokumentene i det.
Oppsummert
- Innebygging gjør tekst til en vektor av tall som bærer dens betydning; Lignende betydninger er nære vektorer.
- Likhet måles ofte ved cosinus; For normaliserte vektorer gir punktprodukt samme resultat.
- I big data erstatter ANN (f.eks. HNSW) eksakt søk: stor hastighet med lite ofring av nøyaktighet.
- Vektordatabase utfører vektorlagring + likhetssøk + metadatafiltrering; metadata er avgjørende for enterprise RAG.
- Spørsmålet og dokumentet må oversettes med samme innbyggingsmodell; ellers kan ikke koordinatene sammenlignes.
Søknadsoppgave
Trekk ut 10 korte passasjer (3-6 setninger hver) fra dokumentet du valgte i forrige enhet. (1) Design minst tre metadata-tagger for hvert stykke (kilde, dato og en tredje som passer til din forretningskontekst: avdeling, produkt, personvern osv.). (2) Skriv hvilket metadatafilter som skal brukes for 3 forskjellige brukerspørsmål. (3) Finn 3 spørsmålsdelpar som uttrykker samme betydning i forskjellige ord (f.eks. «ferierett» ↔ «årlig permisjon») og forklar i én setning hvorfor de ikke vil samsvare med søkeordsøk, men vil samsvare med innebygging.
sjekkliste
- [ ] Jeg kan fortelle at innebygging gjør teksten til en vektor i det semantiske rommet og lignende betydninger er nærliggende.
- Jeg vet at [ ] Cosinus-likhet måler vinkel og er standardpreferansen i tekst.
- [ ] Jeg kan forklare hvorfor ANN er nødvendig i big data.
- [ ] Jeg vet hvorfor metadata er avgjørende for konfidensialitet og oppdateringskontroll.
- [ ] Jeg følger regelen om å oversette spørsmålet og dokumentet med samme innbyggingsmodell.