RAG eller finjustering är ett val som handlar om vad assistenten behöver göra. RAG, en förkortning av retrieval-augmented generation, tillhandahåller relevant källmaterial när modellen svarar. Finjustering innebär att en modell tränas vidare med exempel. Börja med att testa en tydlig uppgiftsinstruktion, eller prompt. Använd sedan resultatet för att avgöra om ni ska undersöka saknat källmaterial, inkonsekventa resultat eller båda delarna innan ni beställer ytterligare arbete.
En leverantör föreslår att ett AI-system ska tränas för företaget, medan en annan föreslår en sökbar kunskapsbas. Dessa beskrivningar definierar varken uppgiften som det färdiga systemet måste utföra eller vad som skulle räknas som ett misslyckat resultat. Vi börjar med att skriva ned uppgiften. Det ger er något konkret att jämföra när förslagen kommer.
Vad förändras med RAG eller finjustering?
RAG förändrar materialet som tillhandahålls för ett svar. Finjustering förändrar modellen genom träning. OpenAI:s guide om träffsäkerhet skiljer mellan brist på kontext och inkonsekvent beteende. Det är en användbar första åtskillnad för en inköpare, förutsatt att ni lämnar utrymme för överlappande behov. En dokumentbaserad assistent kan också behöva skriva sina svar på ett konsekvent sätt.
Enligt Amazon Bedrocks förklaring av kunskapsbaser väljer informationshämtningen ut relevant material och inkluderar det i indata för genereringen. Be att få se vilket godkänt avsnitt som stöder svaret när en föreslagen assistent ska besvara frågor om en returpolicy. En källhänvisning måste fortfarande kontrolleras mot det som står i svaret.
Finjustering använder exempel för att träna en modell vidare i hur den ska svara. OpenAI:s guide beskriver det som ett alternativ för att förbättra beteendet vid en uppgift. Tänk er en önskad överlämningsanteckning med en överenskommen struktur: leverantören behöver exempel på godtagbara anteckningar och de indata som ligger bakom dem. Det är en annan leverans än en mapp med policydokument.
Ingen av beteckningarna visar om demonstrationen uppfyller era krav. Be leverantören ange vad den föreslagna komponenten förändrar, visa materialet som används och förklara hur ni ska kontrollera resultatet. Håll diskussionen kopplad till det faktiska arbete som ni köper.
Börja med en uppgift och en enkel demonstration
Beskriv indata och det godtagbara resultatet innan ni väljer metod. Anthropics guide om promptar börjar med tydliga framgångskriterier, ett test med exempel och ett utkast till prompt. Vi använder den ordningen för att ta fram ett inköpsunderlag: skriv instruktionen, tillhandahåll godkänt material och granska vad den enklaste föreslagna lösningen kan göra. Detta är vår föreslagna utvärderingsmetod, inte ett rapporterat jämförelsetest.
För en illustrativ returassistent skulle indata kunna vara en kundfråga och den tillämpliga policyn. Ett godtagbart utkast besvarar endast det som policyn ger stöd för och lämnar över undantag till en person. För en illustrativ säljöverlämning skulle indata kunna vara en förfrågan och ett godkänt anteckningsformat. Resultatet ska bevara förfrågans innebörd och lämna uppgifter som saknas tomma.
Låt processägaren skriva vad som gör varje resultat godtagbart. Ta med en begäran som assistenten bör avvisa eller lämna över. Använd material som ni har tillåtelse att dela och ta bort onödiga personuppgifter. En demonstration som är beroende av information som ni inte kan tillhandahålla är ännu inte ett genomförbart förslag.
Om ni redan har en assistent som ger otillförlitliga svar kan ni använda den separata guiden för att kontrollera varför AI ger fel svar innan ni bestämmer vad ni ska beställa.
Välj nästa test utifrån den kvarstående bristen
Använd det observerade felet för att välja vad ni ska testa härnäst. AWS rekommenderar att börja med informationshämtning för frågor som hänvisar till anpassade dokument och påpekar svårigheten med att hålla träningen i linje med material som ofta ändras. AWS medger också att informationshämtning och finjustering används tillsammans. Tabellen nedan föreslår ett nästa test för den brist som ni hittade i demonstrationen.
| Vad demonstrationen fortfarande behöver | Vad ni bör testa härnäst |
|---|---|
| Information från godkända dokument som ändras | Informationshämtning som tillhandahåller relevant och aktuellt material |
| Ett repeterbart resultat som förblir inkonsekvent efter tydligare instruktioner och exempel | Träning med godtagna exempel, om den valda modellen stöder det |
| Källmaterial och ett mer konsekvent svar | En kombinerad lösning, med en kontroll för varje krav |
När den enklare demonstrationen redan uppfyller kraven ska ni behålla det alternativet i jämförelsen. Fråga vilket ytterligare problem ett föreslaget träningsarbete eller system för informationshämtning skulle lösa. Valet kan också förbli öppet medan ni förbereder det underlag som saknas.
AWS påpekar att finjustering inte är tillgänglig för alla modeller. Be leverantören ange leverantör och modell, förklara var och hur systemet ska köras samt bekräfta aktuellt stöd för den föreslagna träningen och driftsättningen.
Vem underhåller systemet efter lanseringen?
Jämför vilket ansvar varje förslag lämnar åt ert team. För informationshämtning ska ni utse den person som godkänner källdokument och kontrollerar att uppdateringar når assistenten. För träning ska ni utse den som förbereder godtagna exempel och granskar senare ändringar. Dokumentera vem som beviljar åtkomst, vem som hanterar fel och hur personalen återför uppgiften till den manuella processen när systemet är olämpligt.
Vi tar med dessa frågor i planeringen av AI-implementeringen innan vi väljer komponenter. Ett användbart underlag dokumenterar:
- Uppgiften, tillåtna indata och förväntat resultat.
- De auktoritativa källorna, deras ägare och deras uppdateringsprocess.
- Exempel på godtagbart arbete och oacceptabla utelämnanden eller tillägg.
- Villkoren för att avvisa en begäran eller lämna över den till en person.
- Acceptanskontrollerna, granskaren och materialet som ska överlämnas.
För arbete som omfattar en aktiv beställning eller kontaktpost bör ni fråga hur det föreslagna systemet ska få tillgång till den tillåtna aktuella posten. Ta med detta krav i delen om CRM-integration i underlaget. Ett förslag om att träna med exporterade poster måste fortfarande förklara hur senare ändringar ska hanteras.
Fråga var dokument, sökbara kopior, exempel och resultat ska lagras, vem som kan komma åt dem och hur borttagning hanteras. Dokumentera svaren för den faktiska driftsättningen. Betrakta inte någon av arkitekturbeteckningarna som ett beslut om värdtjänst eller behörighet.
Kontrollera förslaget med förfrågningar som inte setts tidigare
Håll testförfrågningar borta från materialet som används för att konfigurera eller träna det föreslagna systemet. Be varje leverantör köra dessa förfrågningar mot samma acceptanskriterier. Låt processägaren granska resultaten, de indata som användes för att producera dem och de korrigeringar som behövs. Detta kontrollerar förslaget för er uppgift. Det bevisar inte prestandan för varje framtida förfrågan.
- Behåll en referensnivå. Spara det som den manuella processen och den enklare prompten producerar, tillsammans med indata och granskningsanteckningar.
- Kontrollera en källuppdatering. Ändra ett godkänt testdokument och upprepa den berörda frågan. Be leverantören visa vilken version som användes och hur uppdateringen nådde den.
- Kontrollera reglerna för resultatet. Formulera om en förfrågan och utelämna information. Granska om anteckningen behåller den nödvändiga strukturen utan att hitta på en uppgift.
- Testa åtkomst och omfattning. Prova en förfrågan utanför den överenskomna omfattningen och en användare som inte ska få ett begränsat dokument. Granska den faktiska vägran eller överlämningen.
- Dokumentera arbetet som teamet måste fortsätta utföra. Notera korrigeringar, granskningstid och vem som måste underhålla materialet. Jämför detta med referensnivån innan ni utökar arbetet.
När en kontroll misslyckas ska ni dokumentera det krav som inte uppfylldes och be om en reviderad demonstration. Betala inte för en mer avancerad metod enbart för att dess namn låter mer kapabelt. Godta den omfattning som ni kan verifiera eller låt människor behålla uppgiften medan villkoren som saknas åtgärdas.
Så hjälper vi till
Vi börjar med att tillsammans skriva ned uppgiften, tillåtna data och acceptanskontrollerna. Sedan jämför vi föreslagna metoder mot detta underlag och dokumenterar vem som ska underhålla källorna, exemplen och utvärderingen. Ett användbart första steg är att skriva en verklig begäran och godkänna ett exempel på det resultat som ni behöver.
