Dela via

Dataplattform för AI-arbetsbelastningar i Azure

  • Artikel

En dataplattform är en integrerad uppsättning tekniker som är utformade för att hantera arbetsbelastningskrav genom att mata in källdata och sedan filtrera, aggregera och förbereda dem för förbrukning.

Data har distinkta egenskaper som baseras på dess avsedda användning. Vi rekommenderar starkt att du förstår principerna för god design av datapipelines innan du utforskar de tekniska funktioner som beskrivs i den här artikeln. Mer information finns i Träna datadesign och grunddatadesign.

Plattformen uppfyller också lagringsbehoven när data vilar på vissa platser i pipelinen. Om arbetsbelastningen är komplex och hanterar storskaliga data kan du distribuera pipelineuppgifter mellan olika komponenter. För enklare användningsfall bör du utvärdera om du kan använda källdata i ett lager som erbjuder dessa kombinerade funktioner.

Ställ dig själv följande frågor så att du kan undvika att utforma en alltför komplex arkitektur för din dataplattform. Det är alltid bäst att hålla saker enkla när du kan.

  • Kan ditt program ha den förväntade förutsägelsekraften genom att mata in data från en enda källa?
  • Har ditt första val av datalager stöd för datalagerfunktioner?
  • Är källdata redan optimerade för AI-sökningar?

Om du svarar ja på de här frågorna kan du förenkla arkitekturen genom att låta programmet komma åt datakällan direkt. Den här metoden eliminerar behovet av komponenter för stordataarkitektur som datainmatning, integrering av analyslager och extern databehandling. Om källdatabasen kan hantera de sökningar som krävs kan det vara praktiskt att integrera sökindexfunktionen direkt i källdatabasen. Se till att källan kan skalas kostnadseffektivt för att uppfylla nya krav.

Azure Cosmos DB stöder till exempel vektorsökning, så du kanske inte behöver något annat index. Ett annat användningsfall är att använda läsrepliker som slutpunkter för sökåtgärder. För SQL-databaser som har läsrepliker kan direkta sökningar till dessa repliker optimera prestanda. Dra nytta av databasens inbyggda funktioner för att förenkla arkitekturen så mycket som möjligt.

En dataplattformsarkitektur för storskaliga arbetsbelastningar är mer komplex.

Inmatning av data från flera datakällor och orkestrering av sökningar på olika plattformar kan bli komplext och ineffektivt. Dessutom behöver du fortfarande lite extrahering, transformering och inläsning (ETL); extrahera, läsa in och transformera (ELT); eller extrahera och läsa in (EL) processer för att omforma data i datalagret. Scenariot blir mer komplext eftersom data kräver mer bearbetning. Du måste lägga till många komponenter i arkitekturen för att hantera pipelinen från slutpunkt till slutpunkt från inmatning till betjänande frågor. Många stordatatekniker är mycket specialiserade och byggda för att hantera dessa bearbetningsuppgifter effektivt.

En sådan teknik är sökindexet. Den främsta fördelen med att lägga till ett separat index är dess förmåga att effektivt hantera frågor och bearbeta stora mängder data som har högt dataflöde. Den här funktionen avlastar AI-funktioner från den ursprungliga datakällan så att indexet kan fokusera på sin huvudfunktion, som betjänar frågor.

Välj en plattform baserat på dess specifika funktioner och syfte och beakta dina funktionella och tekniska krav. Om din arkitektur utvecklas för att hantera komplexa användningsfall fokuserar du på följande avsnitt om aggregerade datalager, bearbetning av pipelines och sökindex.

Rekommendationer

Här är sammanfattningen av rekommendationerna i den här artikeln.

Rekommendation beskrivning
Skapa säkra, högpresterande och kostnadseffektiva datalager. En viktig del av din dataplattform är ett datalager som aggregerar data från flera källor och möjliggör integrering med olika integreringsuppgifter. Detta hjälper din arbetsbelastning att utföra i stor skala. Se till att granska de olika funktionella och icke-funktionella kraven i ditt datalager för att säkerställa en kostnadseffektiv distribution.

▪ Överväganden för att lagra aggregerade data
Följ metodtipsen för datainmatning och bearbetning. Data av hög kvalitet bidrar till att förbättra tillförlitligheten för din arbetsbelastning och slutanvändarupplevelsen. Överväg kraven för din arbetsbelastning samt viktiga metodtips för att skapa effektiva inmatnings- och dataövergångsprocesser som bidrar till att upprätthålla en hög kvalitet.

▪ Överväganden för att bearbeta data
Utforma tillförlitliga och relevanta sökindex. Sikta på ett högpresterande, skriv-en gång, läs-många-datalager som effektivt hanterar improviserade och fuzzy-frågor och levererar relevanta resultat till din användarbas, även när frågor inte är exakta.

▪ Överväganden för ett sökindex
Se till att funktionella datalager fungerar i stor skala. Beroende på funktionskraven för din arbetsbelastning kan du behöva skapa funktionella datalager, till exempel för offline-slutsatsdragning. Det är viktigt att du skapar datalager med deras avsedda funktion i åtanke och tillämpar metodtips för funktionen.

▪ Överväganden för ett funktionslager
▪ Överväganden för ett datalager för offline-slutsatsdragning

Överväganden för att lagra aggregerade data

I AI-arbetsbelastningar flyttas data genom olika faser av lagring och bearbetning med hjälp av pipelines som samordnar arbetsflödet mellan dessa steg. Ett nyckelsteg är ett datalager som innehåller data som matas in och aggregeras från flera källor. Du behöver det här arkivet för att utföra bearbetning tills data når ett lämpligt tillstånd för träning eller indexering. Det primära fokuset ligger på att säkerställa att data korrekt återspeglar källan.

Kommentar

En annan metod är att komma åt datakällor direkt. Den här metoden kan dock leda till prestandaproblem eftersom den kan överbelasta källsystemen med AI-funktioner. Det kan också finnas problem med dataåtkomst. För att undvika dessa problem rekommenderar vi att du kopierar data till det här arkivet.

Dataplattformen för det här arkivet bör uppfylla de säkerhetsstandarder som tillämpas på datakällor, vara kostnadseffektiv och stödja integrering med ETL-, ELT- och EL-bearbetningsuppgifter. Alternativen varierar från grundläggande lagring till stordatatekniker baserat på datavolym. Välj ekonomisk lagring som hjälper dig att uppnå tillräckligt med tillförlitlighet och prestanda.

Följande avsnitt innehåller vägledning om vilka funktioner du bör tänka på när du väljer en datalagerteknik. Mer information finns i Pipelines för databearbetning.

Funktionskrav

  • Kan plattformen hantera olika dataformat?

    Datalagret bör kunna lagra olika dataformat och transformera dem till andra format om det behövs.

    Anta att din inmatningspipeline hämtar data från en relationsdatabas och en Parquet-fil, så att den stöder både strukturerade och halvstrukturerade data. Du vill konvertera relationsdata till Parquet-format i enlighet med dess schemadefinitioner. Dataplattformen bör ha inbyggda funktioner för att göra den omvandlingen utan att du skriver anpassad kod.

  • Förväntar du dig att lagra flera versioner av data?

    Datavärden och scheman kan ändras över tid, och det blir viktigt att hantera flera versioner av data.

    Källsystem lagrar vanligtvis endast aktuella data, inte historiska data. Om det är viktigt att behålla historiska data kan du behöva duplicera stora datamängder från källsystem. I det här fallet kan versionshantering skilja aktuella data från historiska data.

    I vissa fall kan du behöva underhålla kopior av data för olika användningsfall. För att stödja det här scenariot kan du behöva förgrena data. Varje förgrening kan självständigt mutera för att förbättra dess kvalitet och användbarhet. Din dataplattform bör kunna upprätthålla korrekt versionshantering av dessa förgreningar.

    Din dataplattform bör kunna lagra versioner av data över tid för att ge historisk kontext. Den här samtidiga metoden är fördelaktig för bearbetning och träning av AI-modeller eftersom den erbjuder flera observationer snarare än bara en enda tidpunkt.

  • Har plattformen inbyggda funktioner för datalivscykelhantering?

    Datalivscykelhantering (DLM) är en process för att hantera data från dess skapande till borttagning, med steg som datainsamling, lagring, användning, arkivering och bortskaffande.

    Utan DLM kan data växa okontrollerat, vilket ofta resulterar i flera kopior när de flyttas genom kvalitetsnivåer. Dataplattformen bör ha DLM-funktioner för att förhindra obundna datatillväxt.

    Tänk på det här scenariot. Förbearbetningssteget måste upprepas för att förfina data tills de når en acceptabel kvalitet i träningssyfte. Dataplattformen bör kunna ta bort mellanliggande kopior av data.

    I vissa fall kan du behöva behålla data för regelgranskningar. Dataplattformen bör ha funktioner för kall lagring för sällan använda data så att du kan arkivera dem till en lägre kostnad.

  • Stöder plattformen funktioner för datastyrning?

    Granskning är en viktig aspekt för AI-arbetsbelastningar. Datalagret bör underhålla spårningsloggar som kan spåra dataåtkomst, säkerställa sekretess och förstå data ursprung.

    Använd en dataordlistefunktion för att hantera metadata, datatyper, syften och ursprung. Den här funktionen är särskilt viktig när data matas in från flera källor.

  • Planerar du att träna med produktionsdata?

    Det finns två metoder för distributioner, modelldistribution och koddistribution. I modelldistribution används produktionsdata under utveckling, vilket kräver stränga säkerhetsåtgärder. I koddistributionen ser modellen inte produktionsdata förrän de är i produktion. Även om koddistribution förenklar säkerhetsproblemen i utvecklingsmiljön kan det öka beräkningskostnaderna. Oavsett vilken metod du väljer bör din dataplattform ha stöd för separata miljöer för utveckling och produktion.

  • Prioriterar du bekvämlighetsfunktioner framför viktiga funktionella funktioner?

    När du väljer en dataplattform för AI eller maskininlärning ska du inte bara förlita dig på dess notebook-funktioner. Även om notebook-filer är användbara för undersökande dataanalys bör de inte vara den avgörande faktorn. Beräkningsresurser för notebook-filer ligger vanligtvis utanför omfånget för aggregeringsdatalagret. De är vanligtvis integrerade med andra resurser, till exempel Azure Machine Learning.

Icke-funktionella krav

  • Hur mycket data förväntar du dig att lagra?

    AI-arbetsbelastningar genererar mycket data. Volymen kan öka avsevärt på grund av flera versioner och extra metadata.

    Skalbarhet för lagring och dataflöde är viktigt. Dataplattformen måste effektivt använda data från inmatningspipelinen medan den hanterar datavolym, hanterar samtidiga skrivningar och säkerställer individuella skrivprestanda utan försämring. Dessa kriterier gäller även för bearbetningspipelinen som läser, bearbetar och till och med skriver tillbaka till arkivet.

    När du fattar ett beslut bör du överväga hela processen eftersom inmatning och bearbetning ofta sker samtidigt. Designen måste kunna hantera frekvent dataförflyttning och bearbetning. Dataplattformen bör erbjuda hög parallellitet för att bearbeta data effektivt.

    Plattformstekniken bör generera telemetri som ger meningsfull insikt i dataflödet och prestandan för läs- och skrivåtgärderna.

  • Är det här datalagret en kritisk komponent som bidrar till arbetsbelastningens tillförlitlighetsmål?

    Välj ett datalager som förbättrar både tillförlitligheten och skalbarheten med hjälp av flera instanser. Stordatalager har ofta en inbyggd kontrollant som samordnar databehandling mellan instanser. Om en kopia misslyckas kan en annan användas.

    Tänk på att data inte tjänar sitt syfte om de inte är korrekta eller tillgängliga. Dataplattformen bör garantera hållbarhet och se till att data förblir intakta. Kontrollera att DE API:er som frågar efter data är tillgängliga. Överväg även datalager som har säkerhetskopieringsfunktioner.

    I allmänhet behöver du inte säkerhetskopiera dessa data. Men om kostnaden för att aggregera data varje gång från grunden är betydligt hög kan du överväga att extrahera data från en säkerhetskopia.

  • Har du några kostnadsbegränsningar?

    Om datatillförlitlighet och prestanda är tillräckliga bör du överväga kostnadspåverkan.

    Systemet bör optimeras för skrivning en gång, läsa många för att undvika överförbrukning på datalagring. Tränings- eller grunddata är viktiga men inte kritiska som en produktionsdatabas, vilket kräver omedelbar svarstid. Fokus ligger på att balansera kostnader med tillräckligt med effektivitet för att maximera avkastningen på investeringen.

Ovanstående krav kan naturligtvis leda till att du överväger att använda en datasjö eftersom den erbjuder DLM, kvalitetsnivåer, observerbarhet och stöd för olika filformat. Om din arbetsbelastning redan använder en datasjö kan du dra nytta av den resursen för att uppfylla dina AI-behov. Du kan också välja andra lagringsalternativ, till exempel Azure Blob Storage, som ger en viss nivå av DLM, övervakningsfunktioner och höga transaktionshastigheter.

Överväganden för att bearbeta data

Du måste bearbeta data i det aggregerade datalagret för att öka dess verktyg nedströms. ETL-pipelines utför den här uppgiften, vilket är viktigast på följande punkter:

  • Inmatningslager

    Pipelinen ansvarar för att samla in data från olika källor och flytta dem till det aggregerade datalagret. Under den här processen utför pipelinen vanligtvis grundläggande förbearbetning och kan till och med strukturera data i ett frågebart format.

    För att minimera behovet av anpassad kod rekommenderar vi att du avlastar mycket av det här ansvaret till en dataplattform. När du väljer en teknik bör du överväga de ETL-egenskaper som krävs för att stödja modellträning och förhöjdhet.

  • Bearbetningslager

    Data från det aggregerade datalagret genomgår omfattande bearbetning innan de kan användas för användningsfall för indexering eller modellträning. Bearbetningspipelinen kräver nivåer av tillförlitlighet och skalning som liknar inmatningspipelinen. Den största skillnaden är vilken typ av bearbetning som utförs på data.

    Processen innebär betydande omskolning och omstrukturering av data. Den här processen omfattar uppgifter som entitetsigenkänning, integrering av ytterligare data i datauppsättningen och sökning. Den här processen kan också omfatta att ta bort onödiga data och tillämpa datalogik via en dataorkestreringsplattform.

Databearbetningssteget kan generera olika utdata som hamnar på olika mål för olika avsikter. Huvudmålet är att förbereda och överföra data från det aggregerade datalagret för förbrukning av slutmålet. Konsumenten kan antingen hämta data när det behövs eller så kan bearbetningslagret skicka data när de är klara.

Kommentar

När det gäller maskininlärning och generativ AI är det viktigt att skilja mellan ETL-, ELT- och EL-processer. Traditionell ETL är avgörande för datalagerhantering och objektrelationsmappningar, där data på grund av schemabegränsningar måste transformeras innan du läser in dem i målsystemet. ELT innebär att extrahera data, läsa in dem i en datasjö och sedan transformera dem med hjälp av verktyg som Python eller PySpark. I generativ AI, särskilt för hämtning av utökad generering (RAG), innebär processen ofta att du extraherar och läser in dokument till lagring först, följt av transformeringar som segmentering eller bildextrahering.

Följande avsnitt innehåller vägledning att tänka på när du väljer en databehandlingsteknik som har ETL-funktioner.

Funktionskrav

  • Vad är stödet för att ansluta till datakällor?

    Data som behöver bearbetas kan lagras i relationsdatabaser, stordatakällor eller olika lagringslösningar.

    De flesta databehandlingstekniker stöder fördefinierade integreringar som gör att du kan ansluta till olika datakällor utan att skriva kod. Anslutningsapparna har funktioner som möjligheten att kopiera data från källa till mottagare, utföra sökningar och tillämpa någon form av datastyrning. Det finns verktyg som erbjuder dra och släpp-funktioner för att undvika onödig kodning.

    Välj en dataplattform som gör det enkelt att integrera med förväntade datakällor.

  • Kan plattformen bearbeta olika dataformat?

    Data kan komma i olika format, till exempel strukturerade data som databaser och JSON, ostrukturerade data som bilder och dokument eller strömma data som data från Sakernas Internet-enheter. Pipelines ska kunna hantera de förväntade filtyperna.

  • Erbjuder plattformen funktioner för dataförberedelse och omskolning?

    Du måste bearbeta data som du tänker använda för träning eller förhöjdhet tills de är lämpliga för träning, finjustering eller indexering. Dina strategier för datadesign bör uttryckligen beskriva kraven.

    Följande artiklar beskriver specifika överväganden:

    Som en del av grundläggande rensning tar plattformen bort dubbletter, fyller i saknade värden och eliminerar överflödigt brus under inmatning. För vissa användningsfall, till exempel implementering av ett RAG-mönster, rekommenderar vi att du använder gemener.

    Även om de här förbearbetningsstegen är nödvändiga måste plattformen också ha stöd för omfattande datamanipulering som är specifik för dina behov. Den här processen omfattar inläsning, omskolning och transformering av data. För vissa modeller måste plattformen kunna fråga externa källor om dokumentanalys, till exempel dokumentinformation eller andra AI-verktyg. Det här arbetet krävs för att förbereda data och för databerikning.

    Om datalagret stöder den här bearbetningsnivån kan du lokalisera det här steget i arkivet utan att flytta det någon annanstans. Annars behöver du en extern teknik som Azure Databricks eller Azure Data Factory. Dessa tekniker är lämpliga för att flytta data och utföra manipuleringar, till exempel filtrering, fyllning av saknade värden och standardisering av stränghölje. För mer komplexa uppgifter krävs vanligtvis en jobbvärdplattform. Du kan använda Spark-pooler för stordataorkestrering.

    I vissa användningsfall kanske du vill externalisera det här ansvaret till datakonsumenten. AI-modeller som använder maskininlärning erbjuder till exempel funktioner för jobbbearbetning för att läsa, manipulera och skriva data med hjälp av anpassad Python-kod.

    Ett annat exempel är RAG-implementering. Ett vanligt bearbetningssteg är segmentering, där ett dokument är uppdelat i flera segment och varje segment blir en rad i indexet. Den lagrar även inbäddningar, som en OpenAI-tjänst ofta genererar, för dessa segment. I AI-sökningar samordnas den här processen i arbetsflödet för indexering, oavsett om du använder OpenAI eller Azure AI Search.

  • Finns det en inbyggd orkestrerare för att hantera arbetsflöden?

    Bearbetningsuppgifterna är modulära och körs som jobb. Plattformen bör ha orkestreringsfunktioner som delar upp arbetsflödet i steg eller jobb. Varje jobb ska definieras, köras och övervakas separat.

    I komplexa arbetsflöden beror vissa steg på att de tidigare stegen har slutförts. Orkestreraren ska hantera jobbberoenden och se till att aktiviteterna har slutförts i rätt ordning.

    Datadesign är en iterativ process, så dirigeringsverktyget bör vara tillräckligt flexibelt för att enkelt ändra arbetsflöden. Du bör kunna mata in nya steg eller justera befintliga utan att skriva om stora delar av koden.

    Data Factory är ett populärt val eftersom det ger en omfattande funktionsuppsättning för hantering av dataarbetsflöden. Azure Databricks kan också hantera komplexa arbetsflöden och schemalägga och övervaka jobb. Du bör också ta hänsyn till kostnadskonsekvenserna. Azure Databricks-funktioner kan till exempel vara omfattande, men de är också kostsamma. Ett alternativ med öppen källkod, till exempel Apache NiFi, kan vara mer kostnadseffektivt.

    I slutändan beror vilket verktyg du väljer på vad din organisation tillåter och vilka kunskaper som arbetsbelastningsteamet är bekväma med.

Icke-funktionella krav

När du väljer en bearbetningspipeline är det viktigt att balansera dataflöde och observerbarhet. Pipelinen måste bearbeta på ett tillförlitligt sätt och landa nödvändiga data för modeller eller index inom en tillräcklig tidsram. Den bör vara tillräckligt lätt för att stödja dina nuvarande behov och vara skalbar för framtida tillväxt. Team måste bestämma hur mycket de behöver för att framtidssäkra plattformen för att undvika tekniska skulder senare. Viktiga överväganden är frekvensen och volymen av datainmatning, processens tillförlitlighet och behovet av observerbarhet för att övervaka och åtgärda problem snabbt.

  • Hur mycket data förväntar du dig att mata in?

    För inmatnings- och bearbetningsstegen bör du överväga plattformens skalbarhet och hastighet för att hantera uppgifter. Du förväntar dig till exempel att läsa in 10 terabyte data dagligen i ett index eller för modellträning. Din datainmatningsplattform bör kunna bearbeta så mycket volym och med det förväntade dataflödet. I det här fallet är det kanske inte möjligt att använda Azure Logic Apps eftersom det kan misslyckas under en sådan belastning. I stället passar Data Factory bättre för den här skalan av databehandling.

    Ett sätt att hantera stora volymer är genom parallellitet eftersom det möjliggör effektivare datahantering och bearbetning. Plattformar som Azure Databricks kan samordna uppgifter genom att skapa flera instanser för samma jobb och distribuera belastningen effektivt.

    Tänk också på den tolerabla svarstiden och komplexiteten i jobben. Datarensning innebär till exempel att verifiera och eventuellt ersätta ogiltiga fält eller maskera känslig information. Dessa uppgifter, även om de är grundläggande, kräver betydande resurser eftersom varje rad bearbetas individuellt, vilket ökar den totala tiden.

  • Vilka övervakningsfunktioner behöver du?

    Databearbetningspipelines bör ha övervakningsfunktioner och ge insikter om pipelinens prestanda och status för jobb.

    Du måste kunna spåra förloppet för jobben. Anta att pipelinen kör ett datarensningsjobb som inte slutförs eller slutförs delvis. Det kan finnas nedströmspåverkan på kvaliteten på data som modellen tränas med, vilket kan påverka förutsägelsekraften.

    Precis som andra komponenter i arbetsbelastningen bör du aktivera loggar, mått och aviseringar i datapipelinen för att förstå dess beteende. Samla in och analysera prestandamått för att förstå effektivitets- och tillförlitlighetsaspekterna.

    Identifiera eventuella luckor i den inbyggda telemetrin och ta reda på vilken ytterligare övervakning du behöver implementera. Den här övervakningen kan innebära att du lägger till anpassad loggning eller mått för att samla in specifik information om jobbstegen.

  • Hur mycket tillförlitlighet förväntar du dig av databehandlingsplattformen?

    Tillförlitligheten för en databehandlingspipeline varierar beroende på valet av plattform. Även om Logic Apps har orkestreringsfunktioner kanske det inte är lika tillförlitligt som Data Factory. Data Factory, som finns i ett AKS-kluster (Azure Kubernetes Service), kan ha olika tillförlitlighetsegenskaper.

    Installationer med en instans betraktas som felpunkter. Välj en plattform som stöder tillförlitlighetsfunktioner, till exempel flera instanser, för att uppfylla dina krav.

    Plattformen bör också ha stöd för återhämtningsfunktioner. Till exempel bör orkestreraren automatiskt försöka utföra en misslyckad uppgift igen, vilket minskar behovet av manuella omstarter.

    Batchbearbetning kan vara mindre tillförlitlig än slutsatsdragning, beroende på kraven på dataåterhämtning och svarstid. Om träningen sker varje vecka och bearbetningen tar en dag är tillfälliga fel acceptabla eftersom det finns tillräckligt med tid för att försöka igen.

  • Finns det några kostnadsbegränsningar?

    När du tänker på kostnadseffektiviteten för en databehandlingspipeline är det viktigt att välja en lösning som uppfyller dina behov utan onödiga utgifter. Om dina krav inte motiverar de avancerade funktionerna i Azure Databricks kan ett mer ekonomiskt alternativ som Data Factory vara tillräckligt. Dessutom kan verktyg med öppen källkod som Apache Airflow eller Apache NiFi ge robusta funktioner till en lägre kostnad. Nyckeln är att undvika överförbrukning på funktioner som du inte behöver och välja en plattform som balanserar funktioner och kostnadseffektivitet.

  • Vilka säkerhetskrav gäller för arbetsflödena och på de data som du bearbetar?

    Var tydlig med kraven på säkerhet, sekretess och datahemvist. Tänk till exempel på eventuella geografiska regelkrav. Följ kraven för datahemvist genom att se till att data lagras och bearbetas i specifika regioner. Du kan behöva köra separata pipelines för olika regioner, till exempel en för Europa och en annan för Amerika, för att uppfylla lokala efterlevnadsregler.

    Datapipelines plattform bör ha stöd för identitets- och åtkomsthantering för att säkerställa att endast auktoriserade identiteter har åtkomst till specifika jobb eller steg i arbetsflöden. Om din ETL-process till exempel består av flera arbetsflöden, och en av dem hanterar mycket konfidentiella data, bör plattformen tillåta dig att begränsa åtkomsten till arbetsflödet samtidigt som de andra hålls tillgängliga. Den här funktionen hjälper dig att uppfylla säkerhetskraven utan att behöva separata plattformar för olika datakänslighetsnivåer. Helst bör plattformen tillhandahålla inbyggt stöd för sådan isolering som möjliggör effektiv och säker datahantering.

Databearbetningspipelines kan mata ut data till antingen ett sökindex eller en modellträningspipeline. Beroende på användningsfallet kan du läsa avsnitten om sökindex eller funktionslager.

Överväganden för ett sökindex

Sökindexet är utformat för att lagra kontextbaserade data eller jordningsdata som ska skickas till modellens slutpunkt för slutsatsdragning, tillsammans med uppmaningen. Båda anropen, indexfrågan och slutpunktsanropet för slutsatsdragning sker i samband med att samma HTTP-klientbegäranden underhålls. Till skillnad från ETL-processer som hanterar offline- och batchjobb stöder det här indexet inferens i realtid, vilket kräver hög prestanda och tillförlitlighet. Det är specialiserat på AI-frågor och erbjuder funktioner som nyckelordsindexering och filtrering, vilket inte är typiskt för stordatalager. Målet är att ha ett högpresterande, skriv-en gång, läs-många-datalager som stöder improviserade och fuzzy-frågor. Det här datalagret kan ge relevanta resultat utan exakta frågor.

Funktionskrav

  • Vilka söktyper stöder sökindexet?

    Frågor som systemet tar emot är i huvudsak sökningar och indexet måste ha stöd för omfattande sökfunktioner. För RAG är vektorsökning inte förhandlingsbar eftersom data lagras som beräknade vektorer eller inbäddningar som används för sökning.

    Vektorsökningen är kraftfull och genom att kombinera den med filtrering och fulltextsökning ökar sökindexets effektivitet. Din datadesign bör ta hänsyn till att kombinera dessa typer av sökningar, till exempel vektor, fulltextsökning, filtrering och särskilda datatyper som geo-plats.

    Din datadesign bör uttryckligen ange dessa krav. Mer information finns i Effektiv frågekörning i datadesignen.

  • Stöder indexet multimodala data?

    Välj indextekniker som stöder multimodala data. AI-sökningar kan till exempel analysera ett e-postmeddelande, konvertera en bild i det till vektorer och lagra beskrivningen i indexet. Använd den här funktionen för att söka bland olika innehållsmodaliteter, inklusive bilder, videor och ljudfiler.

  • Stöder indexet funktioner för automatisk uppdatering när data i datakällorna ändras?

    Välj ett index som har funktioner för automatisk uppdatering. Om en inte är tillgänglig måste du manuellt identifiera och skicka ändringar till indexet. Med dessa funktioner kan indexeraren identifiera ändringar i datakällor och hämta uppdateringar automatiskt. Genom att avlasta det här ansvaret till plattformen kan du minska driftkostnaderna och förenkla underhållsprocessen.

Icke-funktionella krav

  • Kan indexet utföras med stora datavolymer?

    Indexet ska kunna hantera stora mängder data, vara skalbar och fungera bra för tunga sökarbetsbelastningar. Indexet lagrar rådata och alla metadata, berikanden och entiteter som är associerade med dem. I samband med RAG-mönstret kan ett enskilt dokument som delas upp i flera segment leda till en betydande ökning av datavolymen.

  • Har indexet inbyggda tillförlitlighetsfunktioner?

    Överväg justeringen mellan tillförlitligheten för slutpunkten för slutsatsdragning eller modellen och datalagret eftersom de är beroende av varandra.

    Sökprocessen omfattar två steg: att köra frågor mot datalagret och sedan köra frågor mot slutpunkten för slutsatsdragning. Båda stegen måste ha liknande tillförlitlighetsegenskaper. Balansera dina tillförlitlighetsmål mellan båda komponenterna för att säkerställa sökningens effektivitet.

    För att säkerställa återhämtning bör arbetsbelastningen stödja det förväntade antalet samtidiga användare och ha tillräckligt med bandbredd för att hantera trafiktoppar. Helst bör plattformen överleva zonindeliga avbrott.

    Dataplattformen bör utformas för att förhindra användning av ett skadat index för slutsatsdragning. I sådana fall bör du enkelt kunna återskapa indexet. Indexet bör också ha stöd för tillförlitlig växling mellan index med hjälp av funktioner som alias för att minimera stilleståndstiden under indexväxlingar. Utan den här funktionen kan du behöva förlita dig på en säkerhetskopia av indexet. Att hantera en säkerhetskopia är mer komplext.

    Ur ett arbetsbelastningsperspektiv kan du förstå de potentiella fellägena eller stressindikatorerna, till exempel begränsning. Även om systemet normalt stöder 50 samtidiga användare kanske det bara stöder 30 användare under en omindexeringsprocess som körs som ett bakgrundsjobb. I så fall blir tidpunkten för bakgrundsjobbet viktig. När du utvärderar dataflödet för ett index ska du inkludera både klientdelsfrågor och serverdelsjobb.

  • Vilka är de viktigaste kostnadsfaktorerna för den här tekniken?

    När du modellerar kostnader beräknar du de utgifter som är associerade med datavolymen, antalet frågor och indexets förväntade dataflöde. Tänk på att index mestadels är plattform som en tjänst (PaaS), där prissättningen är abstrakt. Forskningsnivåer och deras funktioner för att undvika överbetalning för outnyttjad kapacitet eller funktioner.

    AI Search fakturerar till exempel som enheter, som kan innehålla kapacitet, dataflöde och lagring. Extra funktioner kan leda till fler avgifter. Till exempel kan omfattande användning av bildextraheringsfunktioner resultera i en hög faktura. Beroenden, till exempel funktionen för kompetensuppsättningar, som ligger utanför indexets omfång men som ingår i databehandlingen kan medföra extra kostnader.

    Att betala för en nivå utan att använda hela kapaciteten kan leda till överbetalning. På samma sätt påverkar antalet tabeller i ditt index och möjligheten att hantera samtidig trafik kostnaderna.

    Information om kostnaderna för AI Search finns i Planera och hantera kostnader för en AI-tjänsten Search.

  • Uppfyller säkerhetsfunktionerna i indexet din design av säkerhetsdata?

    Din datadesign bör tydligt ange säkerhets- och sekretesskraven. I utvecklings- och testmiljöer där verkliga produktionsdata används bör indexet ha stöd för funktioner som uppfyller alla åtkomstkontroller och spårningsåtgärder. Granska säkerhetsfunktioner som datamaskering och borttagning av personlig information i indexet.

    Välj ett index som har möjlighet att unikt identifiera klienter via Microsoft Entra-ID. Sökindexet bör också ha stöd för åtkomstkontroller på dokumentnivå för att tillåta frågor om relevans efter identiteter. Om indexet inte erbjuder dessa funktioner justerar du din design för att uppnå liknande funktioner med frågefilter. Mer information finns i Säkerhetsfilter för att trimma resultat i AI Search.

    Helst bör sökindexet överensstämma med nätverkssäkerhetskraven. Om du till exempel behöver filtrera utgående trafik till icke-Microsoft-webbplatser och upprätthålla observerbarheten bör indexet erbjuda utgående kontroller. Det bör också ha stöd för nätverkssegmentering. Om serverdelsberäkningen finns i ett virtuellt nätverk är privat anslutning för nyckelkomponenter, inklusive indexet, nödvändig för att undvika exponering för det offentliga Internet. Indexet bör enkelt integreras med privata nätverk och stödja hanterade identiteter för autentisering via Microsoft Entra-ID.

Överväganden för ett funktionslager

För diskriminerande modeller kan din datadesign innehålla ett mellanliggande datalager som cachelagrar data för extra förfining. Det här arkivet, som kallas för ett funktionslager, gör det möjligt för dataexperter att lagra funktioner som ett sista steg, utanför det aggregerade datalagret.

Funktionsarkivet hjälper till att katalogisera data för flera användningsområden genom att lägga till metadata som generationstid och ursprung. Den här mellanliggande landningsplatsen är perfekt för gyllene träningsdata.

Hanterad funktionsbutik i Machine Learning är ett datalagringsalternativ som integreras med MLflow och andra verktyg. Den hämtar och tränar data från det aggregerade datalagret och lägger till ett återanvändbart lager för bättre data härkomst och formell identifiering i Machine Learning.

När du använder ett funktionslager behandlar du det som ett datalager med säkerhets- och åtkomstöverväganden.

Överväganden för ett datalager för offline-slutsatsdragning

I vissa scenarier är användning av ett separat arkiv lämpligt för snabbare framtida sökningar eftersom slutsatsdragning görs på förinsamlade och förberäknade data i förväg. I den här processen når användarbegäran aldrig AI-modellen. Det finns flera fördelar:

  • Förbättrad effektivitet och användarupplevelse genom att minska svarstiden. Resultaten hanteras snabbare för frekventa frågor, till exempel att generera vanliga frågor och svar som resultat.
  • Slutsatsdragningsanrop kan skalas ut enklare som en batchprocess utan begränsningar för realtidsbearbetning.
  • Tillåter förvalidation för att säkerställa noggrannhet före produktion.
  • Eftersom begäran inte dirigeras till interferensslutpunkten minskar belastningen, vilket bidrar till arbetsbelastningens tillförlitlighet.
  • Kan vara mer kostnadseffektivt eftersom det minskar behovet av maskinvara med höga prestanda som krävs för realtidsbearbetning.

Den här metoden är dock bara effektiv om du kan förutsäga möjliga begäranden och en betydande del av förutsägelserna förväntas begäras av användarna. För scenarier med färre upprepade begäranden kan ett offline-slutsatsdragningslager vara mindre effektivt.

Datalagret för det här scenariot bör optimeras för läsåtgärder, måste kunna hantera stora mängder data och tillhandahålla effektiv hämtning. Den bör också kunna integreras i det aggregerade datalagret. Alla butiker med dessa funktioner kan övervägas, till exempel Azure Cosmos DB eller till och med en tabelllagring.

Resurser

De här artiklarna innehåller mer information om Azure-produkter som vi rekommenderar som teknikalternativ för de överväganden som beskrivs i den här artikeln.

Nästa steg

Designområde: MLOps och GenAIOps