Gevinster:
- Forstå, at indlejring gør teksten til en vektor i det semantiske rum, og lignende betydninger er tætte vektorer
- Forklarer, hvordan ANN-søgning fungerer med cosinus- og prik-lighedsmetrikker
- Valg af almindelige vektordatabaser baseret på omkostninger, skala og behov for metadatafiltrering
I hjertet af RAG er et enkelt spørgsmål: "Hvilket stykke tekst minder mest om brugerens spørgsmål?" Computeren behandler tekst med tal, ikke bogstaveligt. Det er derfor, vi først skal konvertere teksten til tal, der bærer dens betydning. Det er, hvad indlejring er: processen med at konvertere en tekst til en sekvens af tal (vektor), der repræsenterer betydningen af den tekst. Når du er færdig med denne enhed, vil du vide, hvordan indlejring fungerer, hvordan lighed måles, og hvordan du vælger den rigtige vektordatabase.
Indlejring: Oversættelse af mening til koordinater
En indlejringsmodel (en specialtrænet kunstig intelligens) konverterer den tekst, du giver, til en vektor med f.eks. 1024 tal. Tænk på denne vektor som en koordinat i et multidimensionelt rum. Magien er denne: tekster, der ligner hinanden i betydning, falder i tætte koordinater i dette rum.
Et simpelt eksempel: "årlig orlov", "ferieret" og "årlig betalt orlov" bruger forskellige ord, men betyder det samme - deres vektorer er tæt på hinanden. "Lønkonto" er en anden sag - dens vektor er fjern. Så brugeren spørger "hvor mange dages ferie har jeg?" Når du spørger, kan vi endda finde et dokument, der ikke indeholder ordet "ferie", men som siger "årlig ferie er 14 dage". Dette er, hvad klassisk søgeordssøgning (søgning, der matcher ordet nøjagtigt) ikke kan.
Tip: Tænk på indlejring som et "fingeraftryk af mening." Fingeraftrykkene af to sætninger med samme betydning ligner hinanden; Også selvom ordene er anderledes.
En vigtig regel: Den model, du bruger, når du indlejrer spørgsmålet, skal være den samme model, som du bruger, når du indlejrer dokumenter. Forskellige modeller producerer forskellige rum; koordinater bliver uforlignelige.
Hvordan måler man lighed?
Der er flere metoder til at måle, hvor ens to vektorer er. Den mest almindelige er cosinus-lighed: den måler vinklen mellem to vektorer. Hvis vinklen er lille (vektorer peger i samme retning), er ligheden stor. Værdien er mellem −1 og 1; Tæt på 1 = meget ens.
kriterium
Hvad måler det?
Hvornår foretrækkes det?
Cosinus
Vinkel (retning) mellem vektorer
Den mest almindelige; standard i tekst semantisk lighed
Prik produkt
Retning + størrelse tilsammen
Hvis vektorerne er normaliserede, giver det samme resultat som cosinus; er hurtig
Euklidisk (euklidisk afstand)
Lige afstand mellem koordinaterne
I nogle klyngescenarier; mindre brugt i tekst
I praksis producerer de fleste indlejringsmodeller normaliserede vektorer (størrelse sat til 1); I dette tilfælde giver cosinus og prikprodukt samme rækkefølge. Bliv ikke beslutningslammet: start med cosinus.
Blandt millioner af vektorer er det langsomt at sammenligne dem én efter én ad gangen. Det er derfor, vektordatabaser bruger ANN (Approximate Nearest Neighbor) algoritmer. ANN finder "næsten nøjagtigt tættest" snarere end "nøjagtig tættest" meget hurtigt. For eksempel kan metoden kaldet HNSW returnere resultater på få millisekunder selv for 10 millioner vektorer. Du opnår stor hastighed for et lille offer af nøjagtighed.
Hvad gør Vector Database?
En vektordatabase gør tre ting på én gang: (1) gemmer vektorer, (2) finder hurtigt vektorer, der ligner en forespørgselsvektor, (3) filtrerer efter metadata ved siden af hver vektor. Metadata er de tags, du knytter til det stykke: kildefil, dato, afdeling, privatlivsniveau osv. Metadatafiltrering er kritisk i virksomhedens RAG; fordi du skal kunne sætte restriktioner som "søg kun i Økonomiafdelingens 2025 dokumenter".
# Tilmeld dig vektordatabasen (konceptuelt)vektor_db.add( id="izin-politikasi-parca-3", vektor=embed("Årlig betalt orlov er 14 dage..."), text="Årlig betalt orlov er 14 dage...", metadata={"kilde": "ik_el_kitabi.pdf", "department"-":020", "department"-:020 "privatliv", " "ic")
# Metadatafiltreret søgning (konceptuelt)resultat = vektor_db.search( vektor=embed("hvor mange dages orlov har jeg?"), top_k=4, filter={"department": "HR", "privacy": ["internt", "on"]})
Valg af den rigtige database
køretøj
Udvalgt aspekt
Passende situation
Indbygget / filbaseret (indlejret bibliotek)
Ingen installation, enkelt maskine
Prototype, lille sæt (< få hundrede tusinde dele)
Administreret cloud-tjeneste
Skalering og vedligeholdelse er ikke dit ansvar
Produktion, hurtigt voksende data, lille team
Open source på din egen server
Fuld kontrol, dine data forbliver dine
Privatlivsforpligtelse, eksisterende infrastruktur
Tilføjelse til eksisterende database
Du administrerer ikke separate systemer
Tilføjelse af vektorunderstøttelse til den DB, du allerede bruger
Spørg, når du vælger: Hvor mange stykker bliver der? Hvor kritisk er metadatafiltrering? Kan data gå uden for virksomheden (fortrolighed)? Kan teamet drive en infrastruktur? Det er ofte klogt at starte i det små og udvide efter behov.
Svag tilgang / stærk tilgang
Svag (lagrer almindelig indlejring, ingen metadata):
Gem blot teksten og vektoren. Søg: returner de 4 mest lignende vektorer.# Problem: kan ikke filtrere som "kun nuværende HR-dokumenter";# gamle/uautoriserede dele kan også inkluderes i svaret.
Kraftfuld (rige metadata + filtreret søgning):
Tilføj kilde, dato, afdeling og privatlivsmærke til hvert stykke. Filtrer efter brugerens autoritet og aktualitet under søgningen: filter = {"privacy": user_authority, "date_date": "2024-01"}# Resultatet er således både sikkert og up-to-date.
Tre mini etuier
Tilfælde 1 — Forkert modelblanding. Et team indlejrede dokumenter med model A og spørgsmål med model B. Søgningerne gav meningsløse resultater, og den korrekte svarprocent forblev på 31 %. Da jeg skiftede til en enkelt model (begge den samme indlejringsmodel), sprang satsen til 88%. Lektion: Spørgsmål og dokument skal være på samme plads.
Case 2 — Privatlivsrisiko uden metadata. I en sundhedsvirksomhed blev alle afdelingsdokumenter smidt i en enkelt pulje uden metadata. Når en salgsmedarbejder stillede et spørgsmål, kontekstualiserede systemet et stykke patientdata. Da metadata + filter blev tilføjet (i henhold til autorisationsniveauet), blev denne risiko elimineret; Ved apportering medbringes 12 uautoriserede brikker slet ikke.
Case 3 — Flaskehals i omfang. En e-handelsvirksomhed søgte efter 8 millioner produktbeskrivelser med en simpel "scan alle"-metode; Hver forespørgsel tog 6 sekunder. Da vi skiftede til HNSW-baseret ANN, faldt tiden til 45 millisekunder, med kun 1 % tab i nøjagtighed. Lektion: ANN er obligatorisk i det store sæt.
Almindelige fejl
- Indlejring af spørgsmål og dokument med forskellige modeller: Resultaterne er meningsløse; altid én model.
- Spring over metadata: Du kan ikke filtrere; Du mister kontrollen over privatlivets fred og opdaterethed.
- Mistaking Embedding for kryptering: Embedding bærer reversibel information; Det er forkert at antage, at følsomme data er "skjult".
- At bygge unødvendigt stor infrastruktur på et lille sæt: En kæmpe klynge administreret til 5.000 dele er unødvendig kompleksitet.
- Du skal ikke bekymre dig for meget om lighedskriteriet: Start med cosinus i teksten; Finjustering kommer senere.
Forsigtig: Indlejring indlejrer tekstens betydning i tal, men "ødelægger" ikke indholdet. Hvis en vektordatabase er lækket, kompromitteres de originale lagrede tekster (i de fleste installationer også gemt). Hold vektorlageret lige så fortroligt som dokumenterne i det.
Sammenfattende
- Indlejring gør tekst til en vektor af tal, der bærer dens betydning; Lignende betydninger er tætte vektorer.
- Lighed måles ofte ved cosinus; For normaliserede vektorer giver prikprodukt det samme resultat.
- I big data erstatter ANN (f.eks. HNSW) eksakt søgning: stor hastighed med lille ofring af nøjagtighed.
- Vektordatabasen udfører vektorlagring + lighedssøgning + metadatafiltrering; metadata er afgørende for virksomhedens RAG.
- Spørgsmålet og dokumentet skal oversættes med samme indlejringsmodel; ellers kan koordinaterne ikke sammenlignes.
Ansøgningsopgave
Uddrag 10 korte passager (3-6 sætninger hver) fra det dokument, du valgte i den forrige enhed. (1) Design mindst tre metadata-tags for hver brik (kilde, dato og en tredje passende til din forretningskontekst: afdeling, produkt, privatliv osv.). (2) Skriv hvilket metadatafilter der skal anvendes til 3 forskellige brugerspørgsmål. (3) Find 3 spørgsmålsdelpar, der udtrykker den samme betydning i forskellige ord (f.eks. "ferieret" ↔ "årlig orlov") og forklar i én sætning, hvorfor de ikke vil matche søgeordssøgning, men vil matche indlejring.
tjekliste
- [ ] Jeg kan se, at indlejring gør teksten til en vektor i det semantiske rum, og lignende betydninger er tæt på.
- Jeg ved, at [ ] Cosinus-lighed måler vinkel og er standardpræferencen i tekst.
- [ ] Jeg kan forklare, hvorfor ANN er nødvendig i big data.
- [ ] Jeg ved, hvorfor metadata er afgørende for fortrolighed og kontrol af friskhed.
- [ ] Jeg følger reglen om at oversætte spørgsmålet og dokumentet med den samme indlejringsmodel.