RAG eller finjustering er et valg, der handler om, hvad jeres assistent skal kunne. RAG, en forkortelse for retrieval-augmented generation, leverer relevant kildemateriale, når modellen svarer. Finjustering betyder, at en model trænes yderligere på eksempler. Start med at teste en klar opgaveinstruktion, også kaldet en prompt. Brug derefter resultatet til at beslutte, om I skal undersøge manglende kildemateriale, uensartet output eller begge dele, før I bestiller ekstra arbejde.
En leverandør foreslår at træne et AI-system til jeres virksomhed, mens en anden foreslår en søgbar vidensbase. Disse beskrivelser definerer ikke den opgave, det færdige system skal udføre, eller hvad der vil tælle som et mislykket resultat. Vi starter med den skriftlige opgave. Den giver jer noget konkret at sammenligne, når tilbuddene kommer.
Hvad ændrer RAG eller finjustering?
RAG ændrer det materiale, der leveres til et svar. Finjustering ændrer modellen gennem træning. OpenAI’s vejledning om nøjagtighed skelner mellem manglende kontekst og uensartet adfærd. Det er en nyttig indledende sondring for en køber, hvis I samtidig giver plads til overlappende behov. En dokumentbaseret assistent kan også have brug for en ensartet måde at formulere sit svar på.
Ifølge Amazon Bedrocks forklaring af vidensbaser udvælger hentning relevant materiale og inkluderer det i inputtet til genereringen. Ved en foreslået assistent, der besvarer spørgsmål om en returpolitik, bør I bede om at se, hvilket godkendt afsnit der understøtter svaret. En kildehenvisning skal stadig kontrolleres i forhold til det, svaret siger.
Finjustering bruger eksempler til at træne en model yderligere i, hvordan den skal svare. OpenAI’s vejledning beskriver det som en mulighed for at forbedre adfærden i en opgave. Tænk på en ønsket overdragelsesnote med en aftalt struktur: Leverandøren har brug for eksempler på acceptable noter og de input, der ligger bag dem. Det er en anden leverance end en mappe med politikdokumenter.
Ingen af betegnelserne fortæller jer, om demonstrationen opfylder jeres krav. Bed leverandøren om at angive, hvad den foreslåede komponent ændrer, vise det materiale, den bruger, og forklare, hvordan I skal kontrollere resultatet. Hold samtalen knyttet til det faktiske arbejde, I køber.
Start med en opgave og en enklere demonstration
Beskriv inputtet og det acceptable output, før I vælger en tilgang. Anthropics vejledning om prompting begynder med klare succeskriterier, en test med eksempler og et udkast til en prompt. Vi bruger denne rækkefølge til at udarbejde et indkøbsoplæg: Skriv instruktionen, lever godkendt materiale, og undersøg, hvad den enkleste foreslåede løsning kan. Det er vores foreslåede evalueringsmetode, ikke et rapporteret benchmark.
For en illustrativ returassistent kan inputtet være en kundes spørgsmål og den relevante politik. Et acceptabelt udkast besvarer kun det, som politikken understøtter, og overlader undtagelser til en person. For en illustrativ salgsoverdragelse kan inputtet være en forespørgsel og et godkendt noteformat. Outputtet bør bevare forespørgslens betydning og lade manglende oplysninger stå tomme.
Lad procesejeren beskrive, hvad der gør hvert output acceptabelt. Medtag en anmodning, som assistenten bør afvise eller overdrage. Brug materiale, I har tilladelse til at dele, og fjern unødvendige personoplysninger. En demonstration, der afhænger af oplysninger, I ikke kan levere, er endnu ikke et brugbart forslag.
Hvis I allerede har en assistent, der giver upålidelige svar, kan I bruge den særskilte vejledning til at undersøge, hvorfor AI giver forkerte svar, før I beslutter, hvad I vil bestille.
Vælg næste test ud fra det resterende hul
Brug den observerede fejl til at vælge, hvad I skal teste næste gang. AWS anbefaler at begynde med hentning ved spørgsmål, der henviser til tilpassede dokumenter, og bemærker vanskeligheden ved at holde træning i trit med materiale, der ændres ofte. AWS tillader også, at hentning og finjustering bruges sammen. Tabellen nedenfor foreslår en næste test for det hul, I fandt i demonstrationen.
| Hvad demonstrationen stadig mangler | Hvad I bør teste som det næste |
|---|---|
| Oplysninger fra godkendte dokumenter, der ændrer sig | Hentning, som leverer det relevante aktuelle materiale |
| Et gentageligt output, som fortsat er uensartet efter klarere instruktioner og eksempler | Træning på accepterede eksempler, hvis den valgte model understøtter det |
| Kildemateriale og et mere ensartet svar | En kombineret løsning med en kontrol af hvert krav |
Når den enklere demonstration allerede opfylder kravene, skal denne mulighed blive i sammenligningen. Spørg, hvilket yderligere problem et foreslået træningsforløb eller hentningssystem vil løse. Valget kan også forblive åbent, mens I forbereder de manglende input.
AWS bemærker, at finjustering ikke er tilgængelig for alle modeller. Bed leverandøren om at navngive udbyderen og modellen, forklare, hvor og hvordan systemet skal køre, og bekræfte den aktuelle understøttelse af den foreslåede træning og implementering.
Hvem vedligeholder systemet efter lanceringen?
Sammenlign det ansvar, som hvert forslag efterlader hos jeres team. Ved hentning skal I udpege den person, der godkender kildedokumenter og kontrollerer, at opdateringer når frem til assistenten. Ved træning skal I udpege den, der udarbejder accepterede eksempler og gennemgår senere ændringer. Registrer, hvem der giver adgang, hvem der håndterer fejl, og hvordan medarbejderne sender opgaven tilbage til den manuelle proces, når systemet ikke er egnet.
Vi indarbejder disse spørgsmål i planlægningen af AI-implementering, før vi vælger komponenter. Et nyttigt oplæg registrerer:
- Opgaven, tilladte input og forventet output.
- De autoritative kilder, deres ejer og deres opdateringsproces.
- Eksempler på acceptabelt arbejde og uacceptable udeladelser eller tilføjelser.
- Betingelserne for at afvise en anmodning eller overdrage den til en person.
- Acceptkontrollerne, den ansvarlige for gennemgang og det materiale, der skal overdrages.
Ved arbejde, der omfatter en aktiv ordre eller kontaktpost, skal I spørge, hvordan det foreslåede system får adgang til den tilladte aktuelle post. Medtag dette krav i oplæggets del om CRM-integration. Et forslag om at træne på eksporterede poster kræver stadig en forklaring på, hvordan senere ændringer bliver håndteret.
Spørg, hvor dokumenter, søgbare kopier, eksempler og output bliver opbevaret, hvem der kan få adgang til dem, og hvordan sletning håndteres. Registrer svarene for den faktiske implementering. Betragt ikke navnet på nogen af arkitekturerne som en beslutning om hosting eller tilladelser.
Kontroller forslaget på anmodninger, det ikke har set før
Hold testanmodninger ude af det materiale, der bruges til at konfigurere eller træne det foreslåede system. Bed hver leverandør om at køre disse anmodninger efter de samme acceptkriterier. Lad procesejeren gennemgå outputtene, de input, der blev brugt til at skabe dem, og de nødvendige rettelser. Det kontrollerer forslaget på jeres opgave. Det beviser ikke ydeevnen for alle fremtidige anmodninger.
- Bevar en baseline. Gem det, den manuelle proces og den enklere prompt producerer, sammen med deres input og noter fra gennemgangen.
- Kontroller en kildeopdatering. Rediger et godkendt testdokument, og gentag det berørte spørgsmål. Bed leverandøren om at vise, hvilken version der blev brugt, og hvordan opdateringen nåede frem til systemet.
- Kontroller reglerne for output. Omformuler en anmodning, og udelad nogle oplysninger. Undersøg, om noten bevarer den krævede struktur uden at opfinde en detalje.
- Test adgang og afgrænsning. Prøv en anmodning uden for det aftalte område og en bruger, som ikke bør modtage et begrænset dokument. Undersøg den faktiske afvisning eller overdragelse.
- Registrer det arbejde, jeres team fortsat skal udføre. Noter rettelser, tid til gennemgang, og hvem der skal vedligeholde materialet. Sammenlign dette med baselinen, før arbejdet udvides.
Når en kontrol mislykkes, skal I registrere det krav, der ikke blev opfyldt, og bede om en revideret demonstration. Betal ikke for en mere omfattende tilgang alene, fordi dens navn lyder mere kompetent. Accepter det omfang, I kan kontrollere, eller behold opgaven hos mennesker, mens de manglende betingelser bliver afklaret.
Her bidrager vi
Vi starter med sammen at skrive opgaven, de tilladte data og acceptkontrollerne. Derefter sammenligner vi de foreslåede tilgange med dette oplæg og dokumenterer, hvem der skal vedligeholde kilderne, eksemplerne og evalueringen. Et nyttigt første skridt er at skrive en reel anmodning og godkende et eksempel på det resultat, I har brug for.
