Grunddatadesign för AI-arbetsbelastningar i Azure
För AI-program måste den välarkitekterade ramverksmetoden för datadesign hantera icke-funktionella krav som driftbarhet, kostnad och säkerhet och följa huvudprinciperna i grundpelarna i Azure Well-Architected Framework. Den bör också ta hänsyn till funktionella krav som datainmatning, förberedelse och validering.
Den AI-modell som du väljer påverkar efterföljande beslut om datadesign. I den här artikeln beskrivs viktiga arkitektoniska överväganden för grundmodeller som behöver utökas för att förbättra resultatrelevansen. Dessa modeller är vanligtvis generativa.
Generativa AI-modeller är fördefinierade eller förtränad, vilket gör att du omedelbart kan använda dem utan att göra ändringar. Färdiga modeller uppfyller dock ofta inte specifika arbetsbelastningskrav. För att lösa det här problemet utökas modeller med kontextspecifika data för att förbättra deras prestanda. Du kan till exempel använda GPT-modellen i olika användningsfall. Dessa program omfattar hämtning av information från dokument, support för IT-support och sammanfattning av komplex information. Om du vill använda grundmodeller för att uppfylla dina specifika behov är det viktigt att förstå dessa överväganden.
Viktigt!
Datadesign är en iterativ process som baseras på statistiska experiment. Generativa AI-program skickar frågor till modellen som innehåller prompt- och kontextdata. För att förfina datadesignen bör både prompt- och kontextdata itereras. Den iterativa processen bör omfatta förbearbetning, val av inbäddningar och segmentering. De här stegen hjälper dig att skapa data som är lämpliga för ett index. Mer information finns i Designa och utveckla en lösning för hämtningsförhöjd generation (RAG).
När du experimenterar och itererar bör du ha användningsfallen i åtanke. Justera datadesignen baserat på faktiska frågemönster. Fastställ vad som är acceptabelt genom förfining och testning.
I en lösning kan du använda en kombination av generativ AI och diskriminerande AI-modeller för att uppfylla arbetsbelastningskraven. Mer information om träningsdata finns i Design av träningsdata.
Rekommendationer
Här är sammanfattningen av rekommendationerna i den här artikeln.
Rekommendation | beskrivning |
---|---|
Förutse användarfrågor. | Förstå de förväntade typerna av frågor som rör dina källdata och deras förväntningar på färskhet. Den här förståelsen hjälper dig att utforma dina datapipelines och index för att tillhandahålla relevanta grunddata. |
Externalisera data till ett sökindex. | Använd ett sökindex i stället för att fråga direkt från källsystemet. Utvärdera olika indextekniker baserat på arbetsbelastningskrav. Skapa en kapacitetsmatris för att utvärdera den bästa passformen för dina behov. Överväg kraftfulla sökindextekniker som Elasticsearch eller AI Search. ▪ Indexering |
Utveckla en inmatningsstrategi. | Utveckla en omfattande strategi för indexhantering som omfattar datainmatning och förbearbetning. Ta bort brus eller irrelevanta data genom att åtgärda inkonsekvenser och dubbletter och standardisera till ett gemensamt schema. Konvertera källformat och typer till datatyper som underlättar frågor och analys. ▪ Förberedelse av data ▪ Omskolning av datavolym |
Utforma ditt index för maximal relevans. | Aktivera funktioner som filtrering, sortering och metadatahantering för specifika fält för att förbättra frågeeffektiviteten. Du kan till exempel bara ange etikettfält som sökbara om du vill söka efter dem. Undvik onödiga lagringskostnader genom att inte göra varje fält hämtningsbart utan ett specifikt användningsfall. ▪ Schemadesign ▪ Indexfunktioner ▪ Effektiv frågekörning |
Uppdatera ditt index för att förhindra slutsatsdragning av inaktuella data. | När du uppdaterar ett index bör du överväga att använda en distributionsstrategi sida vid sida för underhåll. Om du återskapar indexet ser du till att borttagningar och uppdateringar hanteras eftersom indexet blir en ny datauppsättning. Med den här metoden kan du testa data noggrant innan du gör indexet live. När du gör ändringar i index samordnar du schemaändringar med koduppdateringar. Den här metoden säkerställer sömlösa övergångar. ▪ Indexunderhåll |
Typer av data
Du kan utöka generativa AI-modeller med hjälp av kontextdata under slutsatsdragningen eller optimera dem ytterligare genom en finjusteringsprocess. Båda metoderna behöver kompletterande data som ger modellen mer kontext. Modellen använder den kontexten för att besvara användarfrågan och utgör svaret enligt förväntningarna. Vanligtvis använder du följande datatyper:
Källdata är befintliga data i produktion. Dessa data kan struktureras, till exempel data i databaser eller halvstrukturerade, till exempel JSON-filer. Den kan också vara ostrukturerad, till exempel dokument, bilder och ljudfiler.
Grunddata kommer från källdata som innehåller information om ämnen som inte omfattas av modellens inledande träningsdata. Grunddata kombineras med användarfrågan för att bilda uppmaningen som skickas till den stora språkmodellen i samband med ett specifikt slutsatsdragningsanrop. Andra data som du kan inkludera i inferensanropet är systemprompten, exempel med ett skott eller några skott och kontextuella data som tidigare interaktioner.
Dessa data bör vara enkla att söka efter och snabbt hämta. På grund av det här kravet bör du lagra data i ett index som är optimerat för sökning. Det här indexet nås i realtid medan användaren väntar på svaret. Utan dessa data kan modellen ge felaktiga resultat eller inte vara tillämplig på vad användaren specifikt söker.
Finjusteringsdata är information som används för att påverka modellen så att den kan anpassas till specifika uppgifter, domäner eller svarsformat för framtida slutsatsdragningsbegäranden. Om modellen till exempel förväntas ge svar i ett specifikt grammatiskt format fungerar stilguiden som finjusteringsdata.
Användardata innehåller information som tillhandahålls av användare under interaktioner med programmet. När du interagerar med generativa modeller sker tillståndskänsliga interaktioner. Dessa modeller saknar inbyggt minne och behandlar varje interaktion som atomisk.
När du hanterar tillståndskänsliga interaktioner, även kallade TURN-data i chattprogram, är det viktigt att lagra data under kortast möjliga tid. Helst bör dessa data förstöras när sessionen är slut. Det kan dock finnas drift- eller efterlevnadsskäl som kräver att du behåller vissa data, till exempel den ursprungliga frågan eller modellens svar, utöver sessionens varaktighet. Undvik att lagra dessa data efter sessionen när det är möjligt.
Indexering
Kärnan i datadesignen omfattar effektiv lagring och hantering av grundläggande data. Den här metoden säkerställer att data kan utökas för att uppnå den högsta relevansnivån.
En enkel AI-strategi kan innebära att fråga källdata för varje användarinteraktion. Den här metoden är dock inte praktisk på grund av de höga kostnaderna och komplexiteten i direkta datakällinteraktioner. I stället bör du återanvända källdata som en kopia i ett index som är optimerat för sökning och hämtning. Målet med den här metoden är att förbättra modellens förståelse och dess förmåga att generera relevanta svar.
Överväg en bankarbetsbelastning som lagrar information om användarkonton, inställningar och finansiella transaktioner i ett datalager. I ett generativt AI-scenario som använder ett RAG-mönster skapas och indexeras jordningsdata med kontext så att modellen kan ge relevanta svar. Genom att till exempel tillhandahålla relevanta data om användartransaktioner för kontext under slutsatsdragningen kan modellen svara på frågor som rör användarens utgiftsmönster under det senaste kvartalet.
Specialiserad indexteknik
Överväg att externalisera grunddata till ett sökindex. Använd den här metoden i stället för att fråga direkt från källsystemet.
Det finns fördelar med att använda sökindexet. Du kan modellera och transformera kopian av data enligt de förväntade frågorna. Direkta frågor till den primära källan är problematiska eftersom det finns en möjlighet att källdata inte är tillgängliga. Ett index säkerställer att data förblir tillgängliga så länge du anser att de är relevanta för programmet. Du undviker också att betona källdatasystemet. Den här strategin säkerställer att AI-relaterade frågor inte påverkar dess primära användningsfall.
Vissa teknikalternativ har självindexeringsfunktioner. Index kan nå ut till datakällor och införliva sina data. För det här alternativet är nätverksöverväganden viktiga. Om indexet behöver ansluta till databaser finns det potentiella problem, till exempel svarstid och tillförlitlighet i nätverket.
Det finns en initial kostnad för att importera data. När data finns i ditt index behöver du inte flytta dem igen om det inte finns ändringar eller uppdateringar. Datahantering över tid är en viktig aspekt av indexdesignen. Mer information finns i Indexunderhåll.
Standardindex eller anpassat index
Vissa tekniker stöder automatiskt skapandet av ett standardindex för dina data. Det här indexet genereras vid datainmatning med minimal indata. Indexet har färdiga funktioner. Ett standardindex kan vara acceptabelt för konceptbevis och vissa produktionsscenarier.
Vissa scenarier kan kräva att du har ett anpassat indexschema för att förbättra relevansen baserat på specifika arbetsbelastningskrav. Dessa krav avgör hur du utformar schemat, aktiverar indexfunktioner och inkluderar relevanta metadata.
Schemadesign
Du kan se index som strukturer som organiserar och optimerar data för hämtning. Mer specifikt organiserar de data i dokument och fält i en tabell. Tänk också på följande faktorer:
Indextopologi. Utvärdera om du vill samplacera alla data i ett enda index eller distribuera över flera index. Det här beslutet påverkar avsevärt frågeprestanda, indexunderhåll, fråge enkelhet och olika fältkonfiguration (eller schema) mellan dokument.
Överväg till exempel användarfrågor som begär innehåll på ett visst språk. Det enklaste valet för datadesign är att översätta alla språk till ett språk och lagra det i ett enda index. Eller så kan data lagras på alla språk i ett enda index. Det här valet resulterar i flera dokument för varje språk. Indexets filtreringsfunktion kan användas för att begränsa resultatet till önskat språk. Alternativt kan varje index innehålla de översatta versionerna för ett visst språk som förväntat i frågan.
I vissa situationer kan du behöva flera sökindex. Med den här metoden kan du oberoende optimera varje index för maximal relevans från dina sökfrågor. En HR-personalhandbok och en produktunderhållshandbok har till exempel olika syften och målgrupper. Genom att indexera dem separat kan du skräddarsy schemat och sökfrågorna för var och en, vilket förbättrar användarupplevelsen. Den här metoden kan vara komplex att implementera och kräver en orkestrerare för att underlätta anrop till varje index. Orkestreringskomponenten beskrivs i Programdesign för AI-arbetsbelastningar i Azure.
Kommentar
Valet mellan de två topologierna och datasegmenteringsstrategin beror på arbetsbelastningskrav, användningsfall och användarens förväntningar.
Det kan vara svårt att köra korsindexfrågor och påverka söklevnad. I värsta fall kan det finnas manuell sållning genom resultat och bestämma vilka som passar kriterierna. Den här processen introducerar svarstid och ökar komplexiteten. En enkel indexmetod är däremot enklare och enklare. Relevansen kan förbättras med hjälp av indexfunktioner som filtrering.
I vissa fall leder efterlevnadsöverväganden till behovet av separata index. Om affärskraven till exempel kräver att data isoleras mellan Europa och Amerika kan flera index vara oundvikliga.
Dokumentdesign. Justera datadesignen med förväntade användarfrågor för att optimera relevansen. Fundera på hur varje dokument ska hantera frågor. För sökindex prioriterar du relevanta dokument och förfinar resultatet till en koncis uppsättning som är tätt packad med relevant information.
Fältdesign. Konfigurera dina indexfält för att stödja sökprestanda och relevans. Indexfälten ska mappas till de dokumentattribut som du vill göra sökbara, hämtningsbara, filterbara och sorterbara. De omfattar inbäddningar, ID:er eller andra data som kan öka sökningen.
Indexfunktioner
Konfigurera sökindexfälten så att de returnerar den mest relevanta uppsättningen dokument. Beslutet beror på de funktioner som sökindextekniken och arbetsbelastningskraven stöder.
Filter-, sök- och sorteringsalternativ. Överväg de här alternativen eftersom de är direkt relaterade till användningsfall för förhöjd användning. Till exempel avgör filterbar sant eller falskt mot ett värde som anges i frågan och returnerar relevanta dokument. För sökbarhet anger attributet om sökfrågan kan referera till fältet. Du kan till exempel kontrollera om ett textfält innehåller specifik text eller om det är matematiskt relaterat till en annan vektor. Du kan också tilldela fältet en relativ vikt som en del av sökfrågan. Du kan också göra resultatuppsättningar sorterbara, vilket visar resultatet efter relevans.
Avvägning. Om du aktiverar funktioner för indexfält ökar utrymmeskraven, vilket påverkar kostnaderna. Lägg bara till funktioner som du tänker använda.
Metadata. Index har vanligtvis metadata som är associerade med indexfält. Metadata hjälper oss att förstå och hantera data genom att ge relevant information om dem. När du utformar index bör du överväga om metadata kan hämtas eller endast användas för relevansbestämning. Beslutet påverkar beräkningskostnaderna eftersom den underliggande indexeringsprocessen skiljer sig. Överdrivna metadata kan i onödan öka indexets storlek.
Det finns många teknikval för indexering. Många har liknande egenskaper, till exempel de som angavs tidigare. Vissa index kan ha extra funktioner, till exempel bearbetning av text- och språkanalys under indexering. Om du vill göra texten mer lämplig för indexering och sökning kan du dela upp text i token, konvertera den till gemener eller ta bort stoppord.
Effektiv frågekörning
Grunddata används i generativa AI-program för att öka noggrannheten och relevansen för svaren på användarfrågor. Överväg användarfrågor i förväg. Förstå vilka frågor som kan ställas, vem som frågar dem och hur ofta de tillfrågas. Den här informationen hjälper programformulärkontexten och förstår vilket resultat som kan vara relevant.
Vanliga typer av sökningar är:
Vektorfrågor söker efter liknande objekt baserat på deras vektorrepresentationer eller datapunkter i ett högdimensionellt utrymme.
Nyckelordssökningar i hela innehållet i textdokument. Den indexerar och frågar stora mängder textdata och används ofta i sökmotorer, databaser och dokumenthanteringssystem.
Semantisk rangordning förbättrar sökresultatens relevans genom att ordna om dem baserat på deras semantiska relevans för frågan och främja de mest semantiskt relevanta matchningarna överst i listan.
Hybridsökning kombinerar olika söktyper, till exempel vektorsökning, fulltextsökning och semantisk rangordning, för att ytterligare förbättra sökresultatens relevans.
Kombinera söktyper för att ytterligare förbättra modellprestandan.
Det sätt på vilket data lagras och bearbetas påverkar frågeeffektiviteten. Varje gång data läggs till i ett index behövs beräkningscykler för indexering. Om indexering och svar på frågor görs på samma beräkningsresurser kan det uppstå konkurrens. Helst bör ett index fokusera på det primära målet att besvara frågor effektivt och hitta relevanta dokument i stället för överdriven indexering.
Kostnad och prestanda är viktiga faktorer för indexdesign. Tekniker som att skapa skuggkopior kan påskynda frågor. Dataduplicering sker dock via index, vilket medför kostnader.
Avvägning. Indexdesign bör ta hänsyn till både kostnad och prestanda. Hitta en balans genom att optimera lagringen och prioritera effektiva frågesvar och relevant dokumenthämtning framför överdriven indexering.
För teknikval för datalagret ger sökindex, till exempel Elasticsearch eller AI Search, kraftfulla sökfunktioner, inklusive vektoriserade och relevansbaserade sökningar. Alternativt kan du överväga databasalternativ som stöder den typ av data som du har och de typer av frågor som du behöver eftersom de är optimerade för frågor. I slutändan handlar det om de funktioner som erbjuds av alternativen och investeringen av att bygga nya färdigheter i teamet.
Dataförberedelse
Grunddata baseras på befintliga data, som måste vara lämpliga för semantisk frågekörning. Vissa frågor för att hitta relevanta dokument i indexet kan vara literalmatchning. Andra frågor kräver fuzzy-matchning.
Innan kontextuella data är redo att stödja slutsatsdragningsbegäranden till modellen finns det ett inledande förbearbetningssteg som syftar till att rensa, transformera och strukturera data. Målet är att minska brus och bias, söka effektivt och maximera relevansen för indexsökningarna. Valverktygen eller logiken för förbearbetning beror på arbetsbelastningsteamet, men det finns några breda överväganden.
Omskolning av datavolym
Omskolning av datavolymer innebär att justera dataomfånget genom att expandera eller begränsa dem för att skapa ett tätt index så att relevansen ökar. Frågeeffektivitet är ett annat viktigt problem. Lagring av onödiga data påverkar båda dessa mål negativt. Överväg till exempel platsdata för en användare. Om endast stadsdelen är relevant optimerar du genom att bara lagra stadstexten i stället för den fullständiga text som representerar adressen.
Här är några breda överväganden.
Dataeliminering. Behåll endast det som är viktigt för produktens funktioner och ta bort onödig information. Här är några vanliga exempel.
Kvalitativ eliminering. Ett sätt att övergå från ett brett omfång till en smalare mer relativ är att eliminera data av låg kvalitet genom att selektivt bara välja att indexera relevanta källdata. Utmaningen ligger i att programmatiskt identifiera innehåll som inte är relevant för AI-scenarier. Innehållet kan vara användbart för andra avsikter, till exempel granskning eller fullständighet, men även i AI-arbetsbelastningen riskerar det att minska relevansen. Ett sätt att flagga sådant innehåll är att använda metadata som kan användas vid indexpopulationens tid om innehållet måste läggas till i indexet.
Känsliga data. Kopiering av data från källdata till ett index kan också medföra känslig information. Respektera de dataklassificeringsetiketter som används vid källan och bibehåll samma känslighetsnivå för den här datauppsättningen. När du hanterar data som har personlig information ska du inte lagra personliga data om du inte behöver dem för att svara på frågan. Du kan till exempel tillämpa dataklassificering vid indexering av e-postmeddelanden. Om ett e-postmeddelande flaggas som känsligt bör du undvika att lagra det i ett allmänt känslighetsdatalager.
Normalisera och standardisera text. Att ta itu med skrivfel och standardisera text är avgörande för nyckelordsbaserade index. Ett potentiellt användningsfall är översättningar, särskilt när det gäller flerspråkigt innehåll.
Den här typen av förbearbetning behövs också för inbäddningar, vilket gör att du kan jämföra ord baserat på deras kontext och betydelse. En utmaning uppstår dock från skiftlägeskänsligheten för ord. Kontexten är viktig, och det kan finnas nyanser, till exempel de semantiska skillnaderna mellan adjektivet "medborgerlig" och det rätta substantivet "(Honda) Civic".
Datatillägg. Förhöjd kontext förlitar sig ofta på metadata, som vanligtvis inte finns i källdata. Överväg till exempel ett textfragment. En människa i loopen eller AI skapar relevanta frågor som kan besvaras med hjälp av kontexten för kodfragmentet. När du lagrar dessa frågor tillsammans med grunddata kan användarfrågor jämföras med de genererade frågorna för att utvärdera dokumentrelevans. Samlokalisering av dessa nya data med jordningsdata är ett kraftfullt sätt att utöka segmenterade data.
Ett annat användningsfall är tilläggsentiteter som hittades vid analys av ostrukturerade data. Dessa entiteter kan läggas till i indexet och användas för att söka efter och filtrera externa system eller användas för att utföra komplexa beräkningar. Om vi till exempel identifierar ett företagsnamn kan vi leta upp dess bransch eller annan relevant information från en extern databas och lägga till den i vårt index.
Överväg att underhålla data härstamning. Det är viktigt för AI-arbetsbelastningar att spåra datakällan eftersom den informationen kan gå förlorad när ett system aggregerar olika komponenter i ett index. Den här informationen kanske aldrig exponeras för användare, men information om data ursprung är avgörande för interna datastyrningsteam. Dessa metadata är inte nödvändigtvis för modellen. Det bidrar till att upprätthålla transparens och ansvarsskyldighet.
Avvägning. Å ena sidan ökar möjligheten att hitta relevans i datauppsättningen genom att lägga till nya data. Den här förmånen kommer dock till en kostnad. Mer specifikt de beräkningsresurser som krävs för att bearbeta och hantera fältet. Tiden det tar att samla in och lagra data kan vara betydande. Tänk på att överlagring med onödiga fält kan belasta resurser.
Bearbeta textdata. Överväg tekniker som synonymer, härstamning och semantisk närhet för att förbättra relevansen. Delegera dessa tekniker till verktyg om möjligt. Vissa tekniker, till exempel Elasticsearch eller AI-sökning, erbjuder sådana funktioner för förbearbetning av data när index skapas.
Morfning av datatyp
Indexfält i ett datalager är datatypade för att tjäna ett specifikt syfte. Numeriska fält underlättar effektiv frågekörning, textfält möjliggör textbaserade sökningar och booleska fält hanterar binär information.
Källdata finns vanligtvis i olika typer av data, till exempel text, bilder och tabeller, och bearbetningen av dessa data kan vara komplex. Du kan behöva extrahera nyckel/värde-par, identifiera avsnittsrubriker för semantisk segmentering, identifiera specifika identifierare och så vidare.
Om dina källdata till exempel innehåller bilder är de inte sökbara i sig. De måste konverteras till vektorrepresentationer för att möjliggöra effektiva semantiska sökningar och jämförelser. Om relevansen är kopplad till data bakom dessa format investerar du i extrahering av data. Transformera källdatatyper till funktionella datatyper som hjälper dig att fråga och analysera.
Segmentering och inbäddning
Jordningsdata innehåller ofta en stor mängd information, men modellen kan bara tokenisera en viss mängd. Segmentering är en viktig strategi för datadesign eftersom det innebär att dela upp ett dokument i mindre delar som kan bearbetas individuellt och indexeras. Den här strategin möjliggör effektiv sökning och hämtning trots tokenbegränsningar. Kontrollera det maximala antalet token som ditt val av stor språkmodell kan hantera. Dina segment får inte överskrida den gränsen.
Det finns många metoder för att implementera segmentering. Mer information finns i Segmenteringsmetoder.
Inbäddningar är också en annan designstrategi som möjliggör vektorsökningsfunktioner. Inbäddningar är en matematisk representation av ett objekt som genereras av AI-modeller baserat på jordningsdata. De lagras i indexet och lägger till mer kontext som hjälper komplexa frågor att ge resultat med bättre relevans. Mer information finns i Generera inbäddningar.
Underhåll av index
Underhåll över tid är en viktig aspekt av indexdesignen. För statiska data, där dokument förblir oförändrade, är indexunderhåll enkelt. Men de flesta index är dynamiska. Över tid kan nya data läggas till och indexschemat kan behöva nya fält. Omvänt kan vissa data och fält behöva tas bort om de inte längre är relevanta. Vanliga teknikalternativ för indexerare har funktioner för att hantera uppdateringar automatiskt. Information om de rekommenderade indexegenskaperna finns i Överväganden för ett sökindex.
Underhållskriterier
Funktionsuppdateringar. Indexet kan behöva uppdateras om programfunktionerna ändras. Den här situationen inträffar när nya frågor ställs. För att hantera dessa ändringar kan du behöva lägga till nya fält i indexet eller ändra alternativen för filtrering, sökning eller textbearbetning i befintliga fält.
Borttagning av data. Det är svårt att ta bort data eftersom du behöver analysera tillgängliga och saknade data för att avgöra vad som är irrelevant. Om du vill undanta inaktuellt innehåll från ett index bör du överväga att använda metadata som förhindrar sökmotorer från att indexera specifika sidor eller innehåll. När du väljer lagringsalternativ väljer du också en teknik som stöder borttagningar effektivt. Blob storage stöder till exempel mjuk borttagning. Om du använder AI-sökning och inläsning av dokument från lagring kan bloblagring identifiera borttagna dokument och ta bort motsvarande poster. Den här metoden är inte idealisk, men det är nödvändigt när omindexeringen är kostsam på grund av en stor indexstorlek.
Begreppet rätt att bli bortglömd avser en individs rätt att få sina personuppgifter borttagna från onlineplattformar eller databaser. Se till att du har principer för att ta bort personliga data om de användes för träning. Du kan åtgärda det här kravet genom att indexera om datamängden. Om data tas bort från transaktionsdatabasen återspeglar efterföljande indexuppdateringar dessa ändringar.
Upprätthålla kompatibilitet. Program kräver ofta specifika datastrukturer, och alla avvikelser kan störa deras funktioner. Om ett fält till exempel tas bort och programmet begär det fältet kan ett feltillstånd inträffa. Precis som för en traditionell databas bör du använda ett framåtblickande kompatibilitetstänk för index och upprätthålla en stränghetsnivå. När du gör ändringar i indexet, som att lägga till eller ta bort fält, samordnar du schemaändringar med koduppdateringar.
Avvägning. Det är dyrt att lägga till, uppdatera och ta bort åtgärder mot ett index. Överväg uppdateringsfrekvensen och kostnaden för prestanda baserat på datalagringens storlek och effektivitet. Att behålla föråldrade dokument i indexet medför kostnader för lagring, underhåll och frågor.
Distributionsstrategi
Distributionsstrategi. Det finns två huvudsakliga strategier för att uppdatera indexet.
Distributioner sida vid sida. I den här metoden lever ett nytt index som har uppdateringar vid sidan av det befintliga. När det nya indexet har testats och fungerar fullt ut växlas frågor för att använda det uppdaterade indexet. Programmet förblir omedvetet om den här växeln eftersom det bara interagerar med det nya indexet. Om du upptäcker andra problem när det nya indexet har distribuerats till produktionsanvändning kan du återgå till det gamla indexet. Den här metoden minimerar stilleståndstiden och säkerställer kontinuerlig tillgänglighet.
Uppdateringar sida vid sida fungerar bra när kostnaden för att återskapa indexet är rimlig och kan slutföras inom en rimlig tidsram. I allmänhet bör du sträva efter att hålla indexen så effektiva som möjligt eftersom större index förbrukar mer resurser. Övervaka och underhålla index regelbundet för att undvika onödig tillväxt.
Dricks
När du utför resursintensiva dataförbearbetningsuppgifter som entitetsigenkänning, uppslag och beräkningar bör du överväga att spara en kopia av resultatet. Den här metoden säkerställer att du kan undvika att göra om alla beräkningar när du behöver återskapa indexet. Vissa beräkningar kanske inte längre gäller på grund av borttagningar eller uppdateringar, men många förblir relevanta.
Uppdateringsdistributioner på plats. Den här metoden ändrar direkt det befintliga indexet. Att spara på kostnaden för duplicering kan vara fördelaktigt, men det medför också risker på grund av potentiell stilleståndstid och resursintensiva åtgärder. Om ditt index är stort och om du återskapar det från grunden överskrider den önskade uppdateringsfrekvensen kan du överväga att använda uppdateringar på plats. Den här metoden är dock utmanande och medför risk för att ditt servicenivåmål (SLO) överskrids.
Avvägning. Utvärdera kostnaden för att göra distributioner sida vid sida av index mot att göra uppdateringar på plats som distribuerar tillägg, uppdateringar och borttagningar. I de flesta fall bör du använda uppdateringar sida vid sida i stället för uppdateringar på plats. När ett index återskapas hanterar processen effektivt borttagningar och uppdateringar eftersom det skapar en helt ny datauppsättning. Den här strategin ger möjlighet att testa data. Även om distributioner sida vid sida tillfälligt duplicerar data och medför ytterligare kostnader, motiverar fördelarna med testning och prestandautvärdering ofta detta lagringskrav. Innan du gör ett index live bör du undersöka data för att säkerställa att de överensstämmer med dina förväntningar.
Schemalagda uppdateringar. I stället för att upprätthålla kontinuerlig realtidskommunikation med datakällor kan du uppdatera jordningsdata med jämna mellanrum. Den här metoden säkerställer att data förblir relevanta via schemalagda uppdateringar, vilket eliminerar behovet av konstant interaktion.
Nöduppdateringar. Oväntade situationer kan inträffa, till exempel oönskade data som oavsiktligt läcker ut i sökindexet. Om det här problemet uppstår kan du behöva vidta omedelbara åtgärder, till exempel att ta bort specifika dokument eller justera data i indexet. Oavsett vilken distributionsstrategi du väljer, till exempel sida vid sida-uppdateringar eller uppdateringar på plats, bör du alltid planera för möjligheten till nödåtgärder.
Index för självuppdatering. Om indexeringstekniken stöder automatisk uppdatering av indexet för att hålla det synkroniserat med en extern datakälla kan det kanske automatiskt bearbeta ändringar i data. Dataändringar inkluderar tillägg eller borttagningar, utan manuella åtgärder. Tänk på att varje ändring utlöser en åtgärd i indexet, som förbrukar resurser. Indexet kan förbli responsivt för frågor, men dess kapacitet för att hantera dem kan minskas under uppdateringsprocessen.
Åtgärder för färskhet
Mät tidsperioden mellan skapande eller ändring av källdata och dess tillägg till indexet som en indikator och spåra det mot SLO:er. Den här indikatorn styr databeslut kring uppdatering av din datapipelinedesign för att säkerställa att data är tillgängliga i ditt index när du behöver det. Ett index ska bara vara så färskt som krävs.
Om du vill behålla färskhet kan du antingen återskapa indexet helt eller stegvis uppdatera det så att det förblir synkroniserat med de ursprungliga datakällorna. Båda metoderna säkerställer att indexet förblir aktuellt och korrekt.
Initiala investeringar i finjustering av modellen kan vara billigare än att implementera ett RAG-mönster, snabbteknik och dataförstoringsmetoder.